From jouni.ryno@REDACTED  Wed May  3 10:28:28 2000
From: jouni.ryno@REDACTED (Jouni Ryno)
Date: Wed, 03 May 2000 11:28:28 +0300
Subject: IC and C out-parameter to Erlang
Message-ID: <m12muWD-002608C@onki.fmi.fi>


I have some difficulties in understanding how to pass an object from
C-server to Erlang-client.

Currently I have 

module tmsystem
    typedef sequence<char> message;
    interface telemetry {
        void write(in message telecommand);
        message read_tm(in message telecommand);
    };
};
	
I can nicely send an Erlang list (from Erlang) with the write-procedure 
to a C-server.

But I'm not really understanding how I should implement the counterpart
read_tm, which is called from Erlang in order to receive a list as a result.
I know that I should somehow provide the allocated object to C_server to but
the result in. So now I send large enough (12*1024 list elements!) 
in-parameter and make the result to point to that list-structure.

What is the correct way to this (the allocation for the result) ?

  Jouni Ryn?                     	Tel. (+358)-9-19294656
  Finnish Meteorological Institute      TLX 124436 EFKL FI
  Geophysical Research                  TFAX (+358)-9-19294603
  P.O.BOX 503                           Internet: Jouni.Ryno@REDACTED
  FIN-00101 Helsinki                    X-400: /G=Jouni/S=Ryno
  Finland                                      /O=il/P=il/A=mailnet/C=fi/

  WWW: http://www.geo.fmi.fi/           WWW: http://www.geo.fmi.fi/~ryno/

  "It's just zeros and ones, it cannot be hard"



From bjowi@REDACTED  Wed May  3 11:01:48 2000
From: bjowi@REDACTED (=?ISO-8859-1?Q?Bj=F6rn Wingman?=)
Date: Wed, 3 May 2000 11:01:48 +0200 (MET DST)
Subject: Orber
Message-ID: <200005030901.LAA22224@sture.lysator.liu.se>

If I'm not mistaken, orber 3.0.1 is a corba 2.0 orb, and uses BOA and
not POA. My guess is that this will give problems if I try to use
orber with newer orbs, such as JacOrb, which use POA.  Do I guess correctly?

Is there a new version of orber that I haven't found, or is there one
forthcoming soon?


	    /Bj?rn Wingman


From luke@REDACTED  Wed May  3 19:12:21 2000
From: luke@REDACTED (Luke Gorrie)
Date: 03 May 2000 19:12:21 +0200
Subject: Orber
In-Reply-To: "=?iso-8859-1?q?Bj=F6rn?= Wingman"'s message of "Wed, 3 May 2000 11:01:48 +0200 (MET DST)"
References: <200005030901.LAA22224@sture.lysator.liu.se>
Message-ID: <87u2gfv9qi.fsf@cockatoo.bluetail.com>

"Bj?rn Wingman" <bjowi@REDACTED> writes:

> If I'm not mistaken, orber 3.0.1 is a corba 2.0 orb, and uses BOA and
> not POA. My guess is that this will give problems if I try to use
> orber with newer orbs, such as JacOrb, which use POA.  Do I guess correctly?
> 
> Is there a new version of orber that I haven't found, or is there one
> forthcoming soon?

Actually the POA is an ORB-local issue, it doesn't change the way that
ORBs interoperate. So, it's quite OK to use Orber to talk with ORBs
that use the POA. Infact I've used Orber and JacOrb (using POA)
together without a problem, so you should be okay.

Cheers,
Luke



From bud@REDACTED  Wed May  3 12:20:44 2000
From: bud@REDACTED (Bud P. Bruegger)
Date: Wed, 03 May 2000 12:20:44 +0200
Subject: requirements of health care apps
In-Reply-To: <Pine.GSO.4.10.10004281314110.27256-200000@avc303>
References: <Pine.GSO.4.05.10004280843550.1441-100000@boddington>
Message-ID: <3.0.6.32.20000503122044.00998560@mail.sistema.it>

Many thanks for the highly interesting responses.  I very much appreciate
your help.  I'll be unavailable for 2 weeks and will followup then.

best cheers
--bud
/------------------------------------------------------------------------\
| Bud P. Bruegger, Ph.D.  |  mailto:bud@REDACTED                       |
| Sistema                 |  http://www.sistema.it                       |
| Information Systems     |  voice general: +39-0564-418667              |
| Via U. Bassi, 54        |  voice direct:  +39-0564-418667 (internal 41)|
| 58100 Grosseto          |  fax:           +39-0564-426104              |
| Italy                   |  P.Iva:         01116600535                  |
\------------------------------------------------------------------------/


From babbis@REDACTED  Wed May  3 16:42:14 2000
From: babbis@REDACTED (Babbis Xagorarakis)
Date: Wed, 03 May 2000 16:42:14 +0200
Subject: IC and C out-parameter to Erlang
Message-ID: <39103AC6.B317A8F9@erix.ericsson.se>

Hi,

there are many ways to solve this,
please consider the following simple case :

* a global variable case used to save the incoming message by write
function.
    This message has an oversized buffer to hold every message from
erlang.

* each time write is called, the contents of the incoming message are
copied
    to the global message variable by use of set_message().
    Afterwards, the incoming message is deleted by CORBA_free ( You are
    not allowed to modify input, by OMG-spec ). This is done by defining
the
    proper restore function to be called by server loop,
simple_restore().

* each time read is called, the contents of the current global message
are
    accessed by get_message and sent to erlang.

The idl spec should be like this :

module tmsystem {
    typedef sequence<char> message;
    interface telemetry {
        void write(in message telecommand);
        message read_tm();
    };
};


And the code for server callback file could be like this :


#define MAXLENGTH = 10240;

char buf[LEN];
tmsystem_message message;


/* Copy the contents of a message to
   the default message storage */
int set_message(tmsystem_message *in) {
    int i;

    if (in->_length > MAXLENGTH)
      return -1;

    message._length = in._length;

    for(i = 0; i < in->_length; i++)
      message._buffer[i] = in->_buffer[i];

    return 0;
}


/* Access the stored message */
tmsystem_message* get_message() {
    return message;
}


/* A simple restore function */
void simple_restore(tmsystem_telemetry oe_obj, tmsystem_message* in,
CORBA_Environment *oe_env) {
    CORBA_free(in);
}


/* The write callback function */
tmsystem_telemetry_write__rs*
tmsystem_telemetry_write__cb(tmsystem_telemetry oe_obj,
tmsystem_message* in, CORBA_Environment *oe_env) {

    /* Set the global message */
    set_message(in);

    /* Define the restore funtion */
    return (tmsystem_telemetry_write__rs*) (simple_restore);
}


/* The read callback function */
tmsystem_telemetry_read_tm__rs*
tmsystem_telemetry_read_tm__cb(CORBA_Object oe_obj, tmsystem_message**
ret, CORBA_Environment *oe_env){

    /* Access and send the message */
    *ret = get_message();

   /* No restore is needed here */
  return (tmsystem_telemetry_read_tm__rs*) NULL;
}



I hope this will help

BR

Babbis


> I have some difficulties in understanding how to pass an object from
> C-server to Erlang-client.
>
> Currently I have
>
> module tmsystem
>     typedef sequence<char> message;
>     interface telemetry {
>         void write(in message telecommand);
>        message read_tm(in message telecommand);
>    };
> };
>
> I can nicely send an Erlang list (from Erlang) with the
write-procedure
> to a C-server.
>
> But I'm not really understanding how I should implement the
counterpart
> read_tm, which is called from Erlang in order to receive a list as a
result.
> I know that I should somehow provide the allocated object to C_server
to but
> the result in. So now I send large enough (12*1024 list elements!)
> in-parameter and make the result to point to that list-structure.
>
> What is the correct way to this (the allocation for the result) ?



--
Babbis Xagorarakis, Ericsson Network Core Products





From Jouni.Ryno@REDACTED  Wed May  3 17:48:56 2000
From: Jouni.Ryno@REDACTED (Jouni.Ryno@REDACTED)
Date: Wed, 03 May 2000 18:48:56 +0300
Subject: IC and C out-parameter to Erlang 
In-Reply-To: Message from Babbis Xagorarakis <babbis@erix.ericsson.se> 
   of "Wed, 03 May 2000 16:42:14 +0200." <39103AC6.B317A8F9@erix.ericsson.se> 
Message-ID: <m12n1OS-002642C@onki.fmi.fi>


Thank you, using a global worked nicely. I had the impression from the docs,
that the client should provide the data allocation.

All the examples in the IC-document have only in-parameters for complex data
types. Might be nice to add this type of data transfer as example ? i.e.
transfer of bigh chunks of different type of data between C and Erlang.

Anyway, now we don't have to carry an one cubic meter spacecraft simulator
to EMC-test on Friday, instead we can use one single PCI-board to test our
instrument :-)

With best regards


  Jouni Ryn?                     	Tel. (+358)-9-19294656
  Finnish Meteorological Institute      TLX 124436 EFKL FI
  Geophysical Research                  TFAX (+358)-9-19294603
  P.O.BOX 503                           Internet: Jouni.Ryno@REDACTED
  FIN-00101 Helsinki                    X-400: /G=Jouni/S=Ryno
  Finland                                      /O=il/P=il/A=mailnet/C=fi/

  WWW: http://www.geo.fmi.fi/           WWW: http://www.geo.fmi.fi/~ryno/

  "It's just zeros and ones, it cannot be hard"



From bjowi@REDACTED  Thu May  4 11:36:19 2000
From: bjowi@REDACTED (=?ISO-8859-1?Q?Bj=F6rn Wingman?=)
Date: Thu, 4 May 2000 11:36:19 +0200 (MET DST)
Subject: Orber
In-Reply-To: <87u2gfv9qi.fsf@cockatoo.bluetail.com> (message from Luke Gorrie
	on 03 May 2000 19:12:21 +0200)
References: <200005030901.LAA22224@sture.lysator.liu.se> <87u2gfv9qi.fsf@cockatoo.bluetail.com>
Message-ID: <200005040936.LAA02995@sture.lysator.liu.se>

> Actually the POA is an ORB-local issue, it doesn't change the way
> that ORBs interoperate. So, it's quite OK to use Orber to talk with
> ORBs that use the POA. Infact I've used Orber and JacOrb (using POA)
> together without a problem, so you should be okay.

Aha. Ok, but there must be something I haven't understood. I want to
write an erlang client, and read the IOR from a file.

When I use the corba:string_to_object I get an error message.

Simplified:

corba:string_to_object(<jacorb-generated IOR>)  gives:

** exited: {{nocatch,{'EXCEPTION',{'NO_IMPLEMENT',[],0,undefined}}},
            [{erlang,throw,[{'EXCEPTION',{'NO_IMPLEMENT',[],0,undefined}}]},
             {corba,raise,1},
             {iop_ior,decode_profiles,2},
             {iop_ior,decode,4},
             {corba,string_to_object,1},
             {gisclient,blarg,0},
             {erl_eval,expr,3},
             {erl_eval,exprs,4},
             {shell,eval_loop,2}]} **



while

corba:string_to_object(<erlang-generated IOR>) works ok and gives this
object:

Obj: {'IOP_IOR',[73,68,76,58,109,97,116,104,115,47,65,100,100,65,110,100,77,117,108,116,105,112,108,121,58,49,46,48],[{'IOP_TaggedProfile',0,{'IIOP_ProfileBody_1_0',{'IIOP_Version',1,0},[98,97,107,101,100,46,118,101,103,101,116,97,98,108,101,46,111,114,103],4001,{#Bin<28>,key,#Bin<35>,#Bin<13>}}}]}


     /Bj?rn Wingman


From luke@REDACTED  Thu May  4 20:02:31 2000
From: luke@REDACTED (Luke Gorrie)
Date: 04 May 2000 20:02:31 +0200
Subject: Orber
In-Reply-To: "=?iso-8859-1?q?Bj=F6rn?= Wingman"'s message of "Thu, 4 May 2000 11:36:19 +0200 (MET DST)"
References: <200005030901.LAA22224@sture.lysator.liu.se> <87u2gfv9qi.fsf@cockatoo.bluetail.com> <200005040936.LAA02995@sture.lysator.liu.se>
Message-ID: <8766suurbc.fsf@cockatoo.bluetail.com>

"Bj?rn Wingman" <bjowi@REDACTED> writes:

> Aha. Ok, but there must be something I haven't understood. I want to
> write an erlang client, and read the IOR from a file.
> 
> When I use the corba:string_to_object I get an error message.
> 
> Simplified:
> 
> corba:string_to_object(<jacorb-generated IOR>)  gives:

Could you quote the jacorb-generated IOR please?

Cheers,
Luke



From bjowi@REDACTED  Thu May  4 12:22:26 2000
From: bjowi@REDACTED (=?ISO-8859-1?Q?Bj=F6rn Wingman?=)
Date: Thu, 4 May 2000 12:22:26 +0200 (MET DST)
Subject: Orber
In-Reply-To: <8766suurbc.fsf@cockatoo.bluetail.com> (message from Luke Gorrie
	on 04 May 2000 20:02:31 +0200)
References: <200005030901.LAA22224@sture.lysator.liu.se> <87u2gfv9qi.fsf@cockatoo.bluetail.com> <200005040936.LAA02995@sture.lysator.liu.se> <8766suurbc.fsf@cockatoo.bluetail.com>
Message-ID: <200005041022.MAA03318@sture.lysator.liu.se>

JacORB IOR:

IOR:000000000000001949444c3a68656c69312f48656c695365727665723a312e3000000000000000030000000000000036000100000000000f3133302e3233362e3137362e35370000ac45000000000016333337323130393731312f000f493514360c4a0116320000000000000000003c000101000000000f3133302e3233362e3137362e35370000ac45000000000016333337323130393731312f000f493514360c4a01163200000000000000000001000000080000000000000000


Erlang IOR (from the
http://wikie.vegetable.org/get?node=orber+quickstart example files):

IOR:000000000000001d49444c3a6d617468732f416464416e644d756c7469706c793a312e300000000000000001000000000000007c000100000000001462616b65642e766567657461626c652e6f7267000fa10000000000584f524245523a49444c3a6d617468732f416464416e644d756c7469706c793a312e303a6b65793a836802680362000003ac620007759b620008215b64000c6164646d756c4062616b65643a83640009756e646566696e6564


They do not describe the same object, but the erlang one goes through
corba:string_to_object ok, the other gives the error I quoted in the
previous mail.

	/Bj?rn Wingman


From nick@REDACTED  Thu May  4 13:18:55 2000
From: nick@REDACTED (Niclas Eklund)
Date: Thu, 4 May 2000 13:18:55 +0200 (MET DST)
Subject: Orber
In-Reply-To: <200005041022.MAA03318@sture.lysator.liu.se>
Message-ID: <Pine.GSO.3.96.1000504125036.20032E-100000@shagrat>


Hi!

The problem is that JacORB adds the tag profile 'TAG_MULTIPLE_COMPONENTS',
i.e., {'IOP_TaggedProfile',1,[0,0,0,0,0,0,0,0]}.
Orber did not ignore unrecognized TaggedProfiles before, which have been
updated in Orber-3.0.3. Since JacORB add this to the IOR you get the
exception you mentioned.

How to fix it:

In iop_ior.erl change:

decode_profile(_, #'IOP_TaggedProfile'{tag=1, profile_data=ProfileData}) ->
    %exit({'decode_profile_data', 'multiple components not supported'}).
    corba:raise(#'NO_IMPLEMENT'{}).
 
to:

decode_profile(_, #'IOP_TaggedProfile'{tag=N, profile_data=ProfileData}) ->
    #'IOP_TaggedProfile'{tag=N, profile_data=ProfileData};
decode_profile(_, _) ->
    corba:raise(#'INV_OBJREF'{completion_status=?COMPLETED_NO}).


change (in iop_ior.erl):

code_profile_datas(_, [#'IOP_TaggedProfile'{tag=1, profile_data=P} | Profiles]) ->
        exit({'code_profile_datas', 'multiple components not supported'}).
 
to:

code_profile_datas(Version, [#'IOP_TaggedProfile'{tag=N, profile_data=P} |  Profiles]) ->
        [#'IOP_TaggedProfile'{tag=N, profile_data=P} | code_profile_datas(Version, Profiles)];
code_profile_datas(_, _) ->
    corba:raise(#'INV_OBJREF'{completion_status=?COMPLETED_NO}).

/Nick

On Thu, 4 May 2000, =?ISO-8859-1?Q?Bj=F6rn Wingman?= wrote:

> JacORB IOR:
> 
> IOR:000000000000001949444c3a68656c69312f48656c695365727665723a312e3000000000000000030000000000000036000100000000000f3133302e3233362e3137362e35370000ac45000000000016333337323130393731312f000f493514360c4a0116320000000000000000003c000101000000000f3133302e3233362e3137362e35370000ac45000000000016333337323130393731312f000f493514360c4a01163200000000000000000001000000080000000000000000

The IOR above decoded:

{'IOP_IOR',"IDL:heli1/HeliServer:1.0",
           [{'IOP_TaggedProfile',0,
                                 {'IIOP_ProfileBody_1_0',
                                     {'IIOP_Version',1,0},
                                     "130.236.176.57",
                                     44101,
                                     [51,
                                      51,
                                      55,
                                      50,
                                      49,
                                      48,
                                      57,
                                      55,
                                      49,
                                      49,
                                      47,
                                      0,
                                      15,
                                      73|...]}},
            {'IOP_TaggedProfile',0,
                                 {'IIOP_ProfileBody_1_1',
                                     {'IIOP_Version',1,1},
                                     "130.236.176.57",
                                     44101,
                                     [51,
                                      51,
                                      55,
                                      50,
                                      49,
                                      48,
                                      57,
                                      55,
                                      49,
                                      49,
                                      47,
                                      0,
                                      15|...],
                                     []}},
            {'IOP_TaggedProfile',1,[0,0,0,0,0,0,0,0]}]}



> 
> Erlang IOR (from the
> http://wikie.vegetable.org/get?node=orber+quickstart example files):
> 
> IOR:000000000000001d49444c3a6d617468732f416464416e644d756c7469706c793a312e300000000000000001000000000000007c000100000000001462616b65642e766567657461626c652e6f7267000fa10000000000584f524245523a49444c3a6d617468732f416464416e644d756c7469706c793a312e303a6b65793a836802680362000003ac620007759b620008215b64000c6164646d756c4062616b65643a83640009756e646566696e6564
> 
> 
> They do not describe the same object, but the erlang one goes through
> corba:string_to_object ok, the other gives the error I quoted in the
> previous mail.
> 
> 	/Bj?rn Wingman
> 

_____________________________________________________________
Niclas Eklund, Ericsson Network Core Products, +46-8-72 75765





From luke@REDACTED  Thu May  4 21:48:51 2000
From: luke@REDACTED (Luke Gorrie)
Date: 04 May 2000 21:48:51 +0200
Subject: Orber
In-Reply-To: Niclas Eklund's message of "Thu, 4 May 2000 13:18:55 +0200 (MET DST)"
References: <Pine.GSO.3.96.1000504125036.20032E-100000@shagrat>
Message-ID: <87zoq6t7to.fsf@cockatoo.bluetail.com>

Niclas Eklund <nick@REDACTED> writes:

> The problem is that JacORB adds the tag profile 'TAG_MULTIPLE_COMPONENTS',
> i.e., {'IOP_TaggedProfile',1,[0,0,0,0,0,0,0,0]}.
> Orber did not ignore unrecognized TaggedProfiles before, which have been
> updated in Orber-3.0.3. Since JacORB add this to the IOR you get the
> exception you mentioned.

Aha.

Worth noting this URL for debugging purposes:
http://www.parc.xerox.com/istl/projects/ILU/parseIOR/ - it's a CGI
that parses IORs and tells you what profiles they contain, etc. Very
handy!

-Luke



From m.hernandez@REDACTED  Fri May  5 11:47:05 2000
From: m.hernandez@REDACTED (Matias Hernandez)
Date: Fri, 5 May 2000 09:47:05 -0000
Subject: Erlang as Functional Language
Message-ID: <71E95C0E01BED311A2C70080AD0068437F7E@SERVIDORNT>

Hello. 

I am really new to Erlang/OTP. In a "Languages and Compilers" course at
the University we've been told to work with a few functional languages,
Erlang among them. I would like to know whether it has some of the
functionalities present in other functional languages, such as Haskell,
ML, etc. We can't jump ship now, anyway, so I hope it is a good pick :)

I know the main focus of Erlang and its "core" design is communications
and real-time processes, so I understand this could be considered a bit
off-topic... I hope I'm not pestering you.

So, on to the questions:

1. In most functional languages there is a "map" function used for
applying a certain operation on all the elements of a list. 
Like, map(*2, L) doubles all the members of list L. Is there an
equivalent for this in Erlang? How is it used?

2. Does Erlang support lazy evaluation?

3. Parsing. Erlang has something similar to yacc, from what I've seen. I
could really use something like that. Is it well developed?

Thanks for your comments.

Best regards,
- Matias Hernandez




From thomas@REDACTED  Fri May  5 15:01:06 2000
From: thomas@REDACTED (Thomas Arts)
Date: Fri, 05 May 2000 15:01:06 +0200
Subject: Erlang as Functional Language
References: <71E95C0E01BED311A2C70080AD0068437F7E@SERVIDORNT>
Message-ID: <3912C612.69C38353@cslab.ericsson.se>

Matias Hernandez wrote:

> 1. In most functional languages there is a "map" function used for
> applying a certain operation on all the elements of a list.
> Like, map(*2, L) doubles all the members of list L. Is there an
> equivalent for this in Erlang? How is it used?

it is called map in Erlang as well and used in the same way as for other
functional languages. Is your question probably: does Erlang support
higher order functions? The answer is yes.

> 2. Does Erlang support lazy evaluation?

No.

> 3. Parsing. Erlang has something similar to yacc, from what I've seen. I
> could really use something like that. Is it well developed?

Yes. There's a module called yecc that is inspired by yacc and builds
a parser for you. See documentation for details

www.erlang.org

Regards
Thomas


From Matthias.Lang@REDACTED  Fri May  5 15:34:37 2000
From: Matthias.Lang@REDACTED (Matthias.Lang@REDACTED)
Date: Fri, 5 May 2000 15:34:37 +0200 (MET DST)
Subject: Erlang as Functional Language
In-Reply-To: <71E95C0E01BED311A2C70080AD0068437F7E@SERVIDORNT>
References: <71E95C0E01BED311A2C70080AD0068437F7E@SERVIDORNT>
Message-ID: <14610.52717.210026.169858@gargle.gargle.HOWL>

I know Thomas already answered...

 > 1. In most functional languages there is a "map" function used for
 > applying a certain operation on all the elements of a list. 
 > Like, map(*2, L) doubles all the members of list L. Is there an
 > equivalent for this in Erlang? How is it used?

Here's a way involving 'map':

 1> L = [1,2,3,4,5].
 [a1,2,3,4,5]
 2> F = fun(X) -> 2*X end.
 #Fun<erl_eval.19.120858100>
 3> lists:map(F, L).
 [2,4,6,8,10]

A more concise way is with a list comprehension:

  4> [ 2*X || X <- [1,2,3,4,5]].
  [2,4,6,8,10]

 > 2. Does Erlang support lazy evaluation?

No. I think it's fairly uncontroversial to say that lazy evaluation
makes it significantly harder for humans to reason about execution
time and resource consumption, both of which tend to be important in
telecomms applications.

Hope you have fun playing with Erlang.

Matthias


From hal@REDACTED  Mon May  8 06:09:25 2000
From: hal@REDACTED (Hal Snyder)
Date: 07 May 2000 23:09:25 -0500
Subject: load balancing
Message-ID: <87puqx3cp6.fsf@ghidra.vail>

Several of us at my place of employment have been studying Erlang as
an academic exercise.

We now have a chance to do an Erlang-based pilot project putting load
balancing and failover ("robustification") in front of a couple remote
servers running a custom IP protocol over a private WAN.

I've looked at the white papers on bluetail.com, and am now reviewing
Eddieware docs, but also wanted to ask the participants of this list:

1. Other than Bluetail and Eddieware, are there additional
Erlang-related resources on load balancing we should be consulting?

2. How usable is Eddieware? There are caveats about the 1.4.0 release
which came out in February.

3. Is Eddieware still an active project?

4. Are there any recommendations as to how to proceed?

5. Where does Erlang give one an advantage on this sort of project?



From geoff@REDACTED  Mon May  8 06:51:35 2000
From: geoff@REDACTED (Geoff Wong)
Date: Mon, 8 May 2000 14:51:35 +1000 (EST)
Subject: load balancing
In-Reply-To: <87puqx3cp6.fsf@ghidra.vail> from "Hal Snyder" at May 07, 2000 11:09:25 PM
Message-ID: <200005080451.EAA10968@gecko.serc.rmit.edu.au>


Hi,

> We now have a chance to do an Erlang-based pilot project putting load
> balancing and failover ("robustification") in front of a couple remote
> servers running a custom IP protocol over a private WAN.
> I've looked at the white papers on bluetail.com, and am now reviewing
> Eddieware docs, but also wanted to ask the participants of this list:
 
> 1. Other than Bluetail and Eddieware, are there additional
> Erlang-related resources on load balancing we should be consulting?

Not specifically load balancing, but it's worth
brushing up on the options available in Mnesia for building
robust (non single point of failure) distributed databases (etc).

> 2. How usable is Eddieware? There are caveats about the 1.4.0 release
> which came out in February.

Hmm - some people have got it working and are testing/playing with
it. But it's got a couple of serious bugs (which we've fixed). I hope to
do a stable release shortly. I haven't had much time to
work on it recently.

> 3. Is Eddieware still an active project?

Yes :). Just less active than it used to be.

> 4. Are there any recommendations as to how to proceed?

The Eddieware structure should pretty much support what you want
to do; you just need to provide a custom protocol handler
(either in C or Erlang). Check out the inet_server/ module within
Eddieware.

> 5. Where does Erlang give one an advantage on this sort of project?

I guess the big things for us are:

* distributed databases with no single point of failure, Mnesia
  is a great tool!
* really simple RPC
* the gen_server (etc) stuff which is built into the libraries 
  which makes building robust client/server stuff pretty easy (in
  conjunction with the global module for elections when you 
  what a "master" controller of some sort). Also nice "supervisor"
  and "heart" stuff which is essential for robust code.

Geoff



From taha@REDACTED  Mon May  8 13:22:37 2000
From: taha@REDACTED (Walid Taha)
Date: Mon, 8 May 2000 13:22:37 +0200 (MET DST)
Subject: CFP:  Workshop on Program Generation
Message-ID: <Pine.SOL.4.21.0005081315570.4048-100000@muppet70.cs.chalmers.se>


[Reminder:  Deadline in two weeks.]

                         LAST CALL FOR PAPERS 

               Semantics, Applications and Implementation 
                      of Program Generation (SAIG) 
                                                                              
              ICFP Workshop, Montreal, September 20th, 2000.  
                         (Deadline:  May 22, 2000)

                    http://www.md.chalmers.se/~taha/saig/

Numerous recent studies investigate different aspects of program
generation systems, including their semantics, their applications, and
their implementation.  Existing theories and systems address both
high-level (source) language and low-level (machine) language
generation.  A number of programming languages now supports program
generation and manipulation, with different goals, implementation
techniques, and targeted at different applications. The goal of this
workshop is to provide a meeting place for researchers and
practitioners interested in this research area, and in program
generation in general.

Scope: The workshop solicits submissions related to one or more of the
following topics:

  - Multi-level and multi-stage languages, staged computation,
  - Partial evaluation (of e.g. functional, logical, imperative
    programs),
  - Run-time specialization (in e.g. compilers, operating systems),
  - High-level program generation (applications, foundations,
    environments),
  - Symbolic computation, in-lining and macros, 

Submissions are especially welcome if they relate ideas and concepts
from several topics, bridge the gap between theory and practice, cover
new ground, or report exciting applications.  The program committee
will be happy to advise on the appropriateness of a particular
subject.

Distribution: Accepted papers will be published as a Chalmers
technical report, and will be made available online.  A special issue
of the Journal of Higher Order and Symbolic Computation (HOSC) is
planned afterwards.

Format: The one-day workshop will contain slots for participants to
present accepted papers. In addition, there will be time allocated for
open discussions during the workshop.  Invited speakers will be
announced in the near future.

Invited Speaker:

          Frank Pfenning, CMU 

Submission Details: Authors are invited to submit papers of at most
5000 words (excluding figures), in postscript format (letter or A4),
to saig@REDACTED by 22nd May 2000. Both position and technical
papers are welcome.  Please indicate at time of submission. Position
papers are expected to describe ongoing work, future directions,
and/or survey previous results.  Technical papers are expected to
contain novel results.  All papers will be reviewed by the program
committee for the above mentioned criteria, in addition to correctness
and clarity.  Authors will be notified of acceptance by 3 July 2000.
Final version of the papers must be submitted by 31 July 2000.

Program Committee: 

          Cliff Click, Sun Micro Systems 
          Rowan Davies, CMU 
          Torben Mogensen, DIKU 
          Suresh Jagannathan, NEC Research 
          Tim Sheard, OGI 
          Walid Taha, Chalmers (workshop chair) 
          Peter Thiemann, Freiburg 





From tvd@REDACTED  Mon May  8 20:50:25 2000
From: tvd@REDACTED (Todd Vander Does)
Date: Mon, 8 May 2000 14:50:25 -0400 (EDT)
Subject: Makefile for ssl and patches
Message-ID: <Pine.GSO.4.21.0005081436490.15107-100000@sun06.ams.org>


Hello, 

I am compiling erlang so we can test eddie. I would like to
compile erlang with ssl.  Does anyone have the Makefile.in and
vsn.mk that appear to be necessary?  I have the openssl package
(and the 0.9.0 ssleay release if it is really necessary.)

Are there patches I should add to erlang from 
otp_src_R6B-0.tar.gz or to eddie from eddie-1.4.0-1.tar.gz?



From hal@REDACTED  Mon May  8 21:55:50 2000
From: hal@REDACTED (Hal Snyder)
Date: 08 May 2000 14:55:50 -0500
Subject: load balancing
In-Reply-To: Geoff Wong's message of "Mon, 8 May 2000 14:51:35 +1000 (EST)"
References: <200005080451.EAA10968@gecko.serc.rmit.edu.au>
Message-ID: <87r9bcolyx.fsf@ghidra.vail>

Thank you for the detailed reply.

Geoff Wong <geoff@REDACTED> writes:

> > 2. How usable is Eddieware? There are caveats about the 1.4.0
> > release which came out in February.

> Hmm - some people have got it working and are testing/playing with
> it. But it's got a couple of serious bugs (which we've fixed). I
> hope to do a stable release shortly. I haven't had much time to work
> on it recently.

Well, that naturally leads to the following questions.

1. What were the serious bugs?

2. Are the fixes available in current CVS bits? If not, are they
available some other way?  :)


From tobbe@REDACTED  Mon May  8 22:47:15 2000
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: 08 May 2000 22:47:15 +0200
Subject: load balancing
In-Reply-To: Hal Snyder's message of "07 May 2000 23:09:25 -0500"
References: <87puqx3cp6.fsf@ghidra.vail>
Message-ID: <lohfc8py5o.fsf@kiwi.bluetail.com>


> We now have a chance to do an Erlang-based pilot project putting load
> balancing and failover ("robustification") in front of a couple remote
> servers running a custom IP protocol over a private WAN.

JFYI: With the Blutail products you can robustify (almost) any
protocol running on top of TCP. But of course, it is more fun
to write it yourself :-)

Cheers /Tobbe
--
Bluetail AB , Hantverkargatan 78 , SE-112 38 Stockholm , Sweden            
Email: support@REDACTED , Web: http://www.bluetail.com
Tel: +46 8 692 22 20 , Fax: +46 8 654 70 71



From stephan_marvin@REDACTED  Tue May  9 21:34:52 2000
From: stephan_marvin@REDACTED (Stephan Feilhauer)
Date: Tue, 9 May 2000 12:34:52 -0700 (PDT)
Subject: Information
Message-ID: <20000509193452.5677.qmail@web611.mail.yahoo.com>

Hi, 
my name is Stephan Feilhauer and I am a math student
from Berlin, Germany.
I was wondering, if you Email algorithms or
mathematical concepts that you use for your software
to students like me, because we are discussing
algorithms in math class and I would like to find out,
how one from "real life" would look like. 
Looking forward to your reply, 

Stephan

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/


From Sean.Hinde@REDACTED  Wed May 10 12:14:54 2000
From: Sean.Hinde@REDACTED (Sean Hinde)
Date: Wed, 10 May 2000 11:14:54 +0100
Subject: Emulator stopping during mnesia writes
Message-ID: <402DD461F109D411977E0008C791C312564DD3@imp02mbx.one2one.co.uk>

Hi all,

My application has been suffering from a problem where under a fairly heavy
write load into a disc_copies mnesia table the read performance suffers to
the point where the emulator can hang for up to 5 or so seconds
(particularly during the mnesia log dump, and regardless of whether
dump_log_load_regulation is set).

Working under my commercial support agreement with the guys in Sweden we
have established that as the emulator is single threaded with regard to disk
operations, a disk operation which is slow will stop the emulator.

I wonder if anyone else has come across this problem using mnesia, and maybe
come up with a solution or workaround.. I'm using Solaris 2.6.

Thanks very much,

Sean


From scott@REDACTED  Wed May 10 17:46:56 2000
From: scott@REDACTED (Scott Lystig Fritchie)
Date: Wed, 10 May 2000 10:46:56 -0500
Subject: Emulator stopping during mnesia writes 
In-Reply-To: Message of "Wed, 10 May 2000 11:14:54 BST."
             <402DD461F109D411977E0008C791C312564DD3@imp02mbx.one2one.co.uk> 
Message-ID: <200005101546.KAA87128@snookles.snookles.com>

>>>>> "sh" == Sean Hinde <Sean.Hinde@REDACTED> writes:

sh> Working under my commercial support agreement with the guys in
sh> Sweden we have established that as the emulator is single threaded
sh> with regard to disk operations, a disk operation which is slow
sh> will stop the emulator.

The output of "sar" or "iostat" would help confirm this.  If say a 1
minute snapshot of activity from "sar -d 5 12" shows that the
disk/volume that the Mnesia log is written to is busier than 70%
("%busy"), the average I/O queue length is above a handful
("avqueue"), and/or the average seek time is above 20 ms ("avseek"),
you've got a disk/volume that's too busy.  (I'm pulling those numbers
out of my memory ... I highly recommend Adrian Cockroft's book on
Solaris performance tuning book (2nd edition), if you don't already
have it.)

Over-busy disk spindles are the bane of Usenet News, email, and
database servers universally.  In my INN hacking days, I've seen
hopelessly overloaded INN servers (using "truss") take over a second
just to perform a single open("/var/spool/news/alt/whatever/989832",
O_CREAT|O_EXCL|O_WRONLY) system call.  Problems with too many files in
a single directory on an FFS-based file system (as Sun's UFS is) were
only exacerbated by having the disks in the file system (using the
Solstice volume manager) at over 95% busy on average.

If indeed the disk/disks storing the file system with the mnesia logs
is too busy, the solutions are few: software-based striping across
multiple disk drives, hardware-based striping across multiple disk
drives, solid state disk drives, or algorithmic changes to reduce I/O
workload.  The last may be more difficult to do than the former
three.  :-)

-Scott


From Sean.Hinde@REDACTED  Wed May 10 18:33:08 2000
From: Sean.Hinde@REDACTED (Sean Hinde)
Date: Wed, 10 May 2000 17:33:08 +0100
Subject: Emulator stopping during mnesia writes 
Message-ID: <402DD461F109D411977E0008C791C312564DDB@imp02mbx.one2one.co.uk>

Thanks Scott,

> If indeed the disk/disks storing the file system with the mnesia logs
> is too busy, the solutions are few: software-based striping across
> multiple disk drives, hardware-based striping across multiple disk
> drives, solid state disk drives, or algorithmic changes to reduce I/O
> workload.  The last may be more difficult to do than the former
> three.  :-)

I am hoping that there may be some fix in the future where disk i/o is
farmed off to a separate thread/threads within the emulator. Then if i/o
blocks it will not stop servicing other requests which are for RAM based
data. There is a rumour something like this MAY be in R7...

One possible solution I am looking at is to have a set of nodes with
disc_only_copies which just hold the persistent data, and a separate set of
nodes with ram_copies to service the database reads. Other suggestions
welcome.

Sean


From klacke@REDACTED  Wed May 10 22:01:11 2000
From: klacke@REDACTED (Klacke)
Date: Wed, 10 May 2000 22:01:11 +0200
Subject: Emulator stopping during mnesia writes
In-Reply-To: <402DD461F109D411977E0008C791C312564DDB@imp02mbx.one2one.co.uk>
References: <402DD461F109D411977E0008C791C312564DDB@imp02mbx.one2one.co.uk>
Message-ID: <20000510220111.B11954@bluetail.com>

On Wed, May 10, 2000 at 05:33:08PM +0100, Sean Hinde wrote:
> Thanks Scott,
> 
> > If indeed the disk/disks storing the file system with the mnesia logs
> > is too busy, the solutions are few: software-based striping across
> > multiple disk drives, hardware-based striping across multiple disk
> > drives, solid state disk drives, or algorithmic changes to reduce I/O
> > workload.  The last may be more difficult to do than the former
> > three.  :-)
> 
> I am hoping that there may be some fix in the future where disk i/o is
> farmed off to a separate thread/threads within the emulator. Then if i/o
> blocks it will not stop servicing other requests which are for RAM based
> data. There is a rumour something like this MAY be in R7...
> 
> One possible solution I am looking at is to have a set of nodes with
> disc_only_copies which just hold the persistent data, and a separate set of
> nodes with ram_copies to service the database reads. Other suggestions
> welcome.
> 

We at bluetail have had some serious troble with disk io too. In
particular loads of disk operations that modify a directory entry 
such as open/creat, unlink, rename

What makes the situation a lot worse is that while disk io is
pending, the emulator can't run no reductions at all and the overall 
performance drops to an almost grinding halt.

It also turns out that different file systems are better or worse.
In particular FreeBSD with Soft updates performed well whereas
UFS/Solaris and FFS/BSD performed bad (They are almost identical)

We have a short term kludge solution (in production use today) which
is an external unix process that offloads the emulator
with calls to unlink,stat,link and rename.

In the longer run we have an async driver in the pipe 
which schedules job to kernel threads. (if the os have them) 

This async driver might just make it into r7 this fall. 

However if the applictaion is soley io bound, the overall 
performance is of corce soley dependant on the underlying 
disk system, this is however most often not the typical case.
Typically an application has lots of stuff to do, it's just that
sometimes disk io becomes very intesive (mnesia dump for example)
and in those cases it would be nice if some other thread/process than
the emulator is suspended waiting for io completion.


/klacke


-- 
Claes Wikstrom                          <klacke@REDACTED>
Bluetail AB                             http://www.bluetail.com




From scott@REDACTED  Thu May 11 00:04:05 2000
From: scott@REDACTED (Scott Lystig Fritchie)
Date: Wed, 10 May 2000 17:04:05 -0500
Subject: Emulator stopping during mnesia writes 
In-Reply-To: Message of "Wed, 10 May 2000 22:01:11 +0200."
             <20000510220111.B11954@bluetail.com> 
Message-ID: <200005102204.RAA89908@snookles.snookles.com>

>>>>> "k" == Klacke  <klacke@REDACTED> writes:

k> We have a short term kludge solution (in production use today)
k> which is an external unix process that offloads the emulator with
k> calls to unlink,stat,link and rename.

Sounds like the strategy Squid uses for some operations.

k> In the longer run we have an async driver in the pipe which
k> schedules job to kernel threads. (if the os have them)

I've noticed a general reluctance not to introduce features that
aren't portable across all the platforms supported by Erlang.
(Specifically my query earlier about binding UDP ports to a port,
which is necessary if you want to use readv() or writev() on a UDP
socket.)  Such an "if the os has them" feature would go against that
general philosophy.

Not to say that such a driver wouldn't be incredibly useful.  Or that
supporting bound UDP sockets isn't easy.  It just seems inconsistent.
{shrug}

-Scott


From klacke@REDACTED  Thu May 11 00:18:29 2000
From: klacke@REDACTED (Klacke)
Date: Thu, 11 May 2000 00:18:29 +0200
Subject: Emulator stopping during mnesia writes
In-Reply-To: <200005102204.RAA89908@snookles.snookles.com>
References: <20000510220111.B11954@bluetail.com> <200005102204.RAA89908@snookles.snookles.com>
Message-ID: <20000511001829.A29168@bluetail.com>


> k> In the longer run we have an async driver in the pipe which
> k> schedules job to kernel threads. (if the os have them)
> 
> I've noticed a general reluctance not to introduce features that
> aren't portable across all the platforms supported by Erlang.

Well this one is pretty portable. In particular it is implementable
on basically all platforms. Those platforms that don't support
kernel threads (BSD*) will run just fine, except that the
operation will not be performed asyncronously. It'll be just great
on Solaris, win32, and now on linux with the pthreads/clone kit.


Besides, we're not the otp crew, we're just another company
that use erlang to deliver applications to our paying customers.
If we need a feature, we implement it, if then that feature is
not implemntable on , say VxWorks, well ....

We ship the stuff we do to the otp crew and if they like it they
take it. If they don't like it and we desperately need it, we need to
reintroduce our fixes into the releases that come from the otp crew.


Cheers

/klacke


-- 
Claes Wikstrom                          <klacke@REDACTED>
Bluetail AB                             http://www.bluetail.com




From dgould@REDACTED  Thu May 11 03:30:08 2000
From: dgould@REDACTED (dgould@REDACTED)
Date: Wed, 10 May 2000 18:30:08 -0700
Subject: Emulator stopping during mnesia writes
In-Reply-To: <20000511001829.A29168@bluetail.com>; from klacke@bluetail.com on Thu, May 11, 2000 at 12:18:29AM +0200
References: <20000510220111.B11954@bluetail.com> <200005102204.RAA89908@snookles.snookles.com> <20000511001829.A29168@bluetail.com>
Message-ID: <20000510183008.C24844@archimedes.suse.com>

On Thu, May 11, 2000 at 12:18:29AM +0200, Klacke wrote:
> 
> > k> In the longer run we have an async driver in the pipe which
> > k> schedules job to kernel threads. (if the os have them)
> > 
> > I've noticed a general reluctance not to introduce features that
> > aren't portable across all the platforms supported by Erlang.
> 
> Well this one is pretty portable. In particular it is implementable
> on basically all platforms. Those platforms that don't support
> kernel threads (BSD*) will run just fine, except that the
> operation will not be performed asyncronously. It'll be just great
> on Solaris, win32, and now on linux with the pthreads/clone kit.
> 
> 
> Besides, we're not the otp crew, we're just another company
> that use erlang to deliver applications to our paying customers.
> If we need a feature, we implement it, if then that feature is
> not implemntable on , say VxWorks, well ....
> 
> We ship the stuff we do to the otp crew and if they like it they
> take it. If they don't like it and we desperately need it, we need to
> reintroduce our fixes into the releases that come from the otp crew.

There is nothing wrong with using a whole process to do asynch I/O
operations if threads are not availible. Many high performance systems
do this. And if the I/O process segv's recovery is probably easier.


-- 

David Gould                                             dgould@REDACTED
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
As long as each individual is facing the TV tube alone, formal
freedom poses no threat to privilege.  --Noam Chomsky


From Sean.Hinde@REDACTED  Thu May 11 10:33:29 2000
From: Sean.Hinde@REDACTED (Sean Hinde)
Date: Thu, 11 May 2000 09:33:29 +0100
Subject: Emulator stopping during mnesia writes
Message-ID: <402DD461F109D411977E0008C791C312564DE1@imp02mbx.one2one.co.uk>

> It also turns out that different file systems are better or worse.
> In particular FreeBSD with Soft updates performed well whereas
> UFS/Solaris and FFS/BSD performed bad (They are almost identical)

In my case we were supposed to be using Veritas VXFS on Solaris but I found
out this morning that the partition our UNIX guys created for my application
was done with UFS. Thanks Guys there goes two weeks wasted investigation!!
I'm going to re-run my tests and will report back.

sean


From klacke@REDACTED  Thu May 11 11:39:19 2000
From: klacke@REDACTED (Klacke)
Date: Thu, 11 May 2000 11:39:19 +0200
Subject: Emulator stopping during mnesia writes
In-Reply-To: <20000510183008.C24844@archimedes.suse.com>
References: <20000510220111.B11954@bluetail.com> <200005102204.RAA89908@snookles.snookles.com> <20000511001829.A29168@bluetail.com> <20000510183008.C24844@archimedes.suse.com>
Message-ID: <20000511113919.A44114@bluetail.com>

> 
> There is nothing wrong with using a whole process to do asynch I/O
> operations if threads are not availible. Many high performance systems
> do this. And if the I/O process segv's recovery is probably easier.
> 


Well there is always the case with opening and closing filedescriptors.
It is possible (by means of the AF_UNIX socket trick) to send fd's
back and forth between unix processes, but a kernel thread sure
make it easier.


/klacke


-- 
Claes Wikstrom                          <klacke@REDACTED>
Bluetail AB                             http://www.bluetail.com




From etxuwig@REDACTED  Thu May 11 12:56:30 2000
From: etxuwig@REDACTED (Ulf Wiger)
Date: Thu, 11 May 2000 12:56:30 +0200 (MET DST)
Subject: Emulator stopping during mnesia writes
In-Reply-To: <20000510220111.B11954@bluetail.com>
Message-ID: <Pine.GSO.4.10.10005111206170.6926-100000@avc303>

On Wed, 10 May 2000, Klacke wrote:

>We at bluetail have had some serious troble with disk io too. In
>particular loads of disk operations that modify a directory entry 
>such as open/creat, unlink, rename
>
>What makes the situation a lot worse is that while disk io is
>pending, the emulator can't run no reductions at all and the overall 
>performance drops to an almost grinding halt.
>
>It also turns out that different file systems are better or worse.
>In particular FreeBSD with Soft updates performed well whereas
>UFS/Solaris and FFS/BSD performed bad (They are almost identical)

At AXD 301, we've also had some problems with disk I/O.
One of the things we uncovered was that Solaris likes to handle
/tmp as a virtual partition (unless you specify that you want it
to be a true disk partition). This can cause conflicts between
swapping and disk I/O to /tmp, which can lead to some magnificent
delays.

Another problem we've had is when testing an IDE drive, as a 
replacement for our current SCSI drives. Access times were 
significantly slower, and (I believe in combination with a few 
driver or HW bugs) could lead to whopping delays in disk access
-- which of course caused the whole VM to hang.

We've found ways around these problems, but would very much like 
to see a modification of the current I/O implementation.

BTW, in my own pet project - a web server for source code browsing 
in ClearCase, I've had great difficulty with the ClearCase client
sometimes causing delays of > 1 minute*. It's not a great feature
of a web server to get stuck for that long, servicing a single 
request. My solution was to create a number of slave nodes and 
spreading out the file requests to those nodes. This seems to 
work reasonably well (although I had to increase (!) net_ticktime
from 1 minute to 5 in order to keep the distribution going.)

* For those of you unfamiliar with ClearCase, the ClearCase client
hooks into the file I/O system, so if the ClearCase server is bogged
down, your file ops will hang.

/Uffe
-- 
Ulf Wiger, Chief Designer AXD 301         <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuv?gen 9, ?lvsj?                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44



From sawomer@REDACTED  Thu May 11 13:23:56 2000
From: sawomer@REDACTED (SAWSAN MOHAMMED)
Date: Thu, 11 May 2000 11:23:56 GMT
Subject: Information about Mnesia DBMS software
Message-ID: <20000511112356.30178.qmail@hotmail.com>

Dear Erlang organization,
Hello,
I am a student studying DBMSs and I have a research on the MNESIA DBMS .
Hopping if you can help me in getting this software.
I heard from my colleeges about your help and your consideration to their 
e-mails . I thank you in advance .

                                  Yours
                              Sawsan Mohammed Omer
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From hakan@REDACTED  Thu May 11 13:28:16 2000
From: hakan@REDACTED (Hakan Mattsson)
Date: Thu, 11 May 2000 13:28:16 +0200 (MET DST)
Subject: Information about Mnesia DBMS software
In-Reply-To: <20000511112356.30178.qmail@hotmail.com>
Message-ID: <Pine.GSO.4.21.0005111325590.12407-100000@boddington>

On Thu, 11 May 2000, SAWSAN MOHAMMED wrote:

Sawsan> Dear Erlang organization,
Sawsan> Hello,
Sawsan> I am a student studying DBMSs and I have a research on the MNESIA DBMS .
Sawsan> Hopping if you can help me in getting this software.
Sawsan> I heard from my colleeges about your help and your consideration to their 
Sawsan> e-mails . I thank you in advance .

You may download Erlang/OTP (including Mnesia) as Open Source, from

	http://www.erlang.org

or explore the commercial Erlang/OTP site at

	http://www.erlang.se

If you just want an intro to Mnesia and Erlang/OTP, these two
documents are good to start with:

	http://www.ericsson.se/cslab/~hakan/mnesia_overview.pdf
	http://www.erlang.org/white_paper.html

/H?kan

-------------------------------------+------------------------------------
H?kan Mattsson                       | Phone: +46 8 727 57 99
Computer Science Laboratory          | E-mail: hakan@REDACTED
Ericsson Network Core Products       | http://www.ericsson.se/cslab/~hakan
Box 1505, SE-126 25 Stockholm Sweden |



From pascal.brisset@REDACTED  Thu May 11 16:12:16 2000
From: pascal.brisset@REDACTED (Pascal Brisset)
Date: Thu, 11 May 2000 16:12:16 +0200 (CEST)
Subject: Erlang type-checker (erltc) ?
Message-ID: <200005111412.e4BEC3C15245@hades.cslab.ericsson.net>

Is anyone maintaining erltc, the erlang type-checker mentionned at
http://www.dcs.gla.ac.uk/fp/doors.html ?

Are there other static verification tools for Erlang ?

-- Pascal Brisset



From thomas@REDACTED  Thu May 11 16:25:58 2000
From: thomas@REDACTED (Thomas Arts)
Date: Thu, 11 May 2000 16:25:58 +0200
Subject: Erlang type-checker (erltc) ?
References: <200005111412.e4BEC3C15245@hades.cslab.ericsson.net>
Message-ID: <391AC2F6.9C8A954C@cslab.ericsson.se>

Pascal Brisset wrote:
> 
> Is anyone maintaining erltc, the erlang type-checker mentionned at
> http://www.dcs.gla.ac.uk/fp/doors.html ?
> 
> Are there other static verification tools for Erlang ?


The typechecker as developed by Simon Marlow and Phil Wadler
is not updated to the newer Erlang releases. A different
approach is available at:

http://www.ericsson.se/cslab/~thomas/typesdownload.shtml

and a newer version is under construction and yet applied
to code of one of the bigger projects.

Another verification tool that has been developed
is a theorem-prover like tool which can be used to (manually) 
prove arbitrary  properties of Erlang programs:

http://www.ericsson.se/cslab/~thomas/verification.shtml
http://www.sics.se/fdt

Recently at the university of Aachen they have build a 
prototype modelchecker tool for Erlang:

http://www-i2.informatik.rwth-aachen.de/hutch/

Please send me an email if you need more detailed information.

Regards
Thomas



---
Thomas Arts
Ericsson
Computer Science Laboratory
http://www.ericsson.se/cslab/~thomas


From Sean.Hinde@REDACTED  Thu May 11 20:19:56 2000
From: Sean.Hinde@REDACTED (Sean Hinde)
Date: Thu, 11 May 2000 19:19:56 +0100
Subject: Emulator stopping during mnesia writes
Message-ID: <402DD461F109D411977E0008C791C312564DF3@imp02mbx.one2one.co.uk>

Hi,

> In my case we were supposed to be using Veritas VXFS on 
> Solaris but I found out this morning that the partition our 
> UNIX guys created for my application was done with UFS. 
> Thanks Guys there goes two weeks wasted investigation!! I'm 
> going to re-run my tests and will report back.

After the most painful day where our UNIX team managed to delete all trace
of erlang and all the backups they took while upgrading the file systems to
Veritas I have some good news to report.

Growing a table from scratch at full transaction rate used to run at max 400
per second with pauses in the emulator of up to 7 seconds. With Veritas File
system it now runs at 2000 per second while another node is doing 100 remote
reads per second, and the longest read delay was 150mS.

UFS nil points!!

I am using Sun Netra t1s with 440MHz IIci SPARCs with just the two built in
discs.

Cheers,
Sean


From scott@REDACTED  Thu May 11 20:26:33 2000
From: scott@REDACTED (Scott Lystig Fritchie)
Date: Thu, 11 May 2000 13:26:33 -0500
Subject: Emulator stopping during mnesia writes 
In-Reply-To: Message of "Thu, 11 May 2000 11:39:19 +0200."
             <20000511113919.A44114@bluetail.com> 
Message-ID: <200005111826.NAA97514@snookles.snookles.com>

>>>>> "k" == Klacke  <klacke@REDACTED> writes:

k> Well there is always the case with opening and closing
k> filedescriptors.  It is possible (by means of the AF_UNIX socket
k> trick) to send fd's back and forth between unix processes, but a
k> kernel thread sure make it easier.

There's another separate-process hack possible ... inspired by Squid
and the I/O-Lite (?) guys & their speedy Web server(*).  Have an
external process open() the file, immediately close it, then report
back to you.  When you get word back, immediately open it again.
Hopefully the OS will have everything cached for you and you avoid
blocking.  This could be especially useful if you're opening with
O_CREAT.

In off-hours "wouldn't be fun if I hacked on Z" moments, pondering
what Z might be, I've thought that AIO (asynchronous I/O) would be a
nifty thing to add to the VM.  Not enough hours in the day, though.
:-)

-Scott

(*) I _think_ it was the I/O-Lite folks at Rice (?) University.  They
had a recent paper describing a Web server that, at its core, was a
single process with a select() (poll()?) driver loop.  Really busy Web
servers implemented that way have a problem blocking for local disk
I/O, though.  So they use a whole bunch of external processes to read
the file (if it indeed exists), which brings the whole thing into page
cache first.  The main process rarely blocks for local disk I/O.  Sick
and twisted, but apparently a very effective technique.  And portable.


From scott@REDACTED  Thu May 11 20:33:40 2000
From: scott@REDACTED (Scott Lystig Fritchie)
Date: Thu, 11 May 2000 13:33:40 -0500
Subject: Emulator stopping during mnesia writes 
In-Reply-To: Message of "Wed, 10 May 2000 18:30:08 PDT."
             <20000510183008.C24844@archimedes.suse.com> 
Message-ID: <200005111833.NAA97547@snookles.snookles.com>

>>>>> "dg" == dgould  <dgould@REDACTED> writes:

dg> There is nothing wrong with using a whole process to do asynch I/O
dg> operations if threads are not availible. Many high performance
dg> systems do this. And if the I/O process segv's recovery is
dg> probably easier.

I agree; it's a noble technique.  If process A has data that it wasn't
process B to write to disk, there's the pesky problem of getting the
data over to B first.  I've experimented with kludging shared memory
onto the VM's memory management scheme.  It works, at least under
light loads.  It remains to be seen if we'll actually use it, though.

-Scott


From dgould@REDACTED  Thu May 11 21:02:41 2000
From: dgould@REDACTED (dgould@REDACTED)
Date: Thu, 11 May 2000 12:02:41 -0700
Subject: Emulator stopping during mnesia writes
In-Reply-To: <200005111826.NAA97514@snookles.snookles.com>; from scott@sendmail.com on Thu, May 11, 2000 at 01:26:33PM -0500
References: <20000511113919.A44114@bluetail.com> <200005111826.NAA97514@snookles.snookles.com>
Message-ID: <20000511120241.E27633@archimedes.suse.com>

On Thu, May 11, 2000 at 01:26:33PM -0500, Scott Lystig Fritchie wrote:
> single process with a select() (poll()?) driver loop.  Really busy Web
> servers implemented that way have a problem blocking for local disk
> I/O, though.  So they use a whole bunch of external processes to read
> the file (if it indeed exists), which brings the whole thing into page
> cache first.  The main process rarely blocks for local disk I/O.  Sick
> and twisted, but apparently a very effective technique.  And portable.

This is exactly what I was suggesting. For example, Informix and Oracle
database systems do this.

-dg
 
-- 

David Gould                                             dgould@REDACTED
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
As long as each individual is facing the TV tube alone, formal
freedom poses no threat to privilege.  --Noam Chomsky


From dgould@REDACTED  Thu May 11 21:08:05 2000
From: dgould@REDACTED (dgould@REDACTED)
Date: Thu, 11 May 2000 12:08:05 -0700
Subject: Emulator stopping during mnesia writes
In-Reply-To: <Pine.GSO.4.10.10005111206170.6926-100000@avc303>; from etxuwig@etxb.ericsson.se on Thu, May 11, 2000 at 12:56:30PM +0200
References: <20000510220111.B11954@bluetail.com> <Pine.GSO.4.10.10005111206170.6926-100000@avc303>
Message-ID: <20000511120805.G27633@archimedes.suse.com>

On Thu, May 11, 2000 at 12:56:30PM +0200, Ulf Wiger wrote:
> On Wed, 10 May 2000, Klacke wrote:
... 
> * For those of you unfamiliar with ClearCase, the ClearCase client
> hooks into the file I/O system, so if the ClearCase server is bogged
> down, your file ops will hang.

Ah yes, I was extremely familiar with the bogged down ClearCase file ops.

-dg
 
-- 

David Gould                                             dgould@REDACTED
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
As long as each individual is facing the TV tube alone, formal
freedom poses no threat to privilege.  --Noam Chomsky


From klacke@REDACTED  Thu May 11 21:08:10 2000
From: klacke@REDACTED (Klacke)
Date: Thu, 11 May 2000 21:08:10 +0200
Subject: Emulator stopping during mnesia writes
In-Reply-To: <200005111826.NAA97514@snookles.snookles.com>
References: <20000511113919.A44114@bluetail.com> <200005111826.NAA97514@snookles.snookles.com>
Message-ID: <20000511210810.A12180@bluetail.com>

On Thu, May 11, 2000 at 01:26:33PM -0500, Scott Lystig Fritchie wrote:
> There's another separate-process hack possible ... inspired by Squid
> and the I/O-Lite (?) guys & their speedy Web server(*).  Have an
> external process open() the file, immediately close it, then report
> back to you.  When you get word back, immediately open it again.
> Hopefully the OS will have everything cached for you and you avoid
> blocking.  This could be especially useful if you're opening with
> O_CREAT.
> 
> In off-hours "wouldn't be fun if I hacked on Z" moments, pondering
> what Z might be, I've thought that AIO (asynchronous I/O) would be a
> nifty thing to add to the VM.  Not enough hours in the day, though.
> :-)


Yeah, I think both ideas are good, we've talked and discussed 
them both here, the first one makes the directory changing operations
happen in a different process which is great. It's a bit of a kludge
though.

The second one with some sort of interface to the aio_ routines
is also interesting. I did some fiddling around with the aio_ 
routines a a couple of months ago. The trouble with the aio_
calls is that they send a signal to the caller upon completion.

Some years ago, we had signal support in the vm, where the 
a driver could install a sig handler, the sig handler wrote
a flag, and the driver was the later invoked by the scheduler.
(It's not possible to do anything interesting with the vm inside
the sighandler) This would be pretty easy and straightforward to
reintroduce (The signal code was ripped out of the vm a few years
ago by somebody ??)

There's also a polling interface to the aio_ routines where
it's supposed to be able to call a function and see if the
operation is finished. I couldn't get that to work though so I 
dropped the whole thing

Well well .... so much to do and so little time ... :-(

/klacke


-- 
Claes Wikstrom                          <klacke@REDACTED>
Bluetail AB                             http://www.bluetail.com




From dgould@REDACTED  Thu May 11 22:08:20 2000
From: dgould@REDACTED (dgould@REDACTED)
Date: Thu, 11 May 2000 13:08:20 -0700
Subject: Emulator stopping during mnesia writes
In-Reply-To: <200005111833.NAA97547@snookles.snookles.com>; from scott@sendmail.com on Thu, May 11, 2000 at 01:33:40PM -0500
References: <20000510183008.C24844@archimedes.suse.com> <200005111833.NAA97547@snookles.snookles.com>
Message-ID: <20000511130820.M27633@archimedes.suse.com>

On Thu, May 11, 2000 at 01:33:40PM -0500, Scott Lystig Fritchie wrote:
> >>>>> "dg" == dgould  <dgould@REDACTED> writes:
> 
> dg> There is nothing wrong with using a whole process to do asynch I/O
> dg> operations if threads are not availible. Many high performance
> dg> systems do this. And if the I/O process segv's recovery is
> dg> probably easier.
> 
> I agree; it's a noble technique.  If process A has data that it wasn't
> process B to write to disk, there's the pesky problem of getting the
> data over to B first.  I've experimented with kludging shared memory
> onto the VM's memory management scheme.  It works, at least under
> light loads.  It remains to be seen if we'll actually use it, though.
> 
> -Scott

Go for it. I would be happy to help at least, having done this sort of
stuff for the DB engines in prior lives. Better yet, lets define an
ideal api that lets naively written servers scale easily, ie perl,
python, java, erlang, and I will see if I can hack it into the Linux
kernel... Just looking for the right motivation.

-dg


-- 

David Gould                                             dgould@REDACTED
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
As long as each individual is facing the TV tube alone, formal
freedom poses no threat to privilege.  --Noam Chomsky


From hal@REDACTED  Thu May 11 22:28:45 2000
From: hal@REDACTED (Hal Snyder)
Date: 11 May 2000 15:28:45 -0500
Subject: Emulator stopping during mnesia writes
In-Reply-To: dgould@suse.com's message of "Thu, 11 May 2000 13:08:20 -0700"
References: <20000510183008.C24844@archimedes.suse.com>
	<200005111833.NAA97547@snookles.snookles.com>
	<20000511130820.M27633@archimedes.suse.com>
Message-ID: <87puqsbzlu.fsf@ghidra.vail>

dgould@REDACTED writes:

> On Thu, May 11, 2000 at 01:33:40PM -0500, Scott Lystig Fritchie wrote:
...
> > I agree; it's a noble technique.  If process A has data that it wasn't
> > process B to write to disk, there's the pesky problem of getting the
> > data over to B first.  I've experimented with kludging shared memory
> > onto the VM's memory management scheme.  It works, at least under
> > light loads.  It remains to be seen if we'll actually use it, though.
> > 
> > -Scott
> 
> Go for it. I would be happy to help at least, having done this sort of
> stuff for the DB engines in prior lives. Better yet, lets define an
> ideal api that lets naively written servers scale easily, ie perl,
> python, java, erlang, and I will see if I can hack it into the Linux
> kernel... Just looking for the right motivation.

Do soft updates in *BSD make this irrelevant? :)

If not, being a BSD user, I'd be interested to see how it works on
this side of the fence and help as time allows.


From Sean.Hinde@REDACTED  Fri May 12 00:13:32 2000
From: Sean.Hinde@REDACTED (Sean Hinde)
Date: Thu, 11 May 2000 23:13:32 +0100
Subject: Emulator stopping during mnesia writes
Message-ID: <402DD461F109D411977E0008C791C312564DF5@imp02mbx.one2one.co.uk>

> Growing a table from scratch at full transaction rate used to 
> run at max 400 per second with pauses in the emulator of up 
> to 7 seconds. With Veritas File system it now runs at 2000 
> per second while another node is doing 100 remote reads per 
> second, and the longest read delay was 150mS.

I knew it was too good to be true. That was for a ram_copies typo, er table.

The real result was 1000 per second, with the longest read delay less than a
second. Still a massive improvement. It almost meets the "soft real time"
spec..

Sean


From thomas@REDACTED  Fri May 12 16:29:49 2000
From: thomas@REDACTED (Thomas Arts)
Date: Fri, 12 May 2000 16:29:49 +0200
Subject: Information
References: <20000509193452.5677.qmail@web611.mail.yahoo.com>
Message-ID: <391C155D.C341F772@cslab.ericsson.se>

Stephan Feilhauer wrote:
> 
> Hi,
> my name is Stephan Feilhauer and I am a math student
> from Berlin, Germany.
> I was wondering, if you Email algorithms or
> mathematical concepts that you use for your software
> to students like me, because we are discussing
> algorithms in math class and I would like to find out,
> how one from "real life" would look like.
> Looking forward to your reply,

Just have a look in the libraries of the Erlang distribution
http://www.erlang.org

in particular you may be interested in 
digraph.erl
ordset.erl

and it might also be nice to look at the source code
for handling big numbers (our integers have no upperbound).
Excepts for graph's and sets we do not have that many mathematical
concepts implemented. No topologies, no logics, no continuous
functions, no differential equation packages... After all it is
the math that forms the model for the software, not the software
that forms the prove for the model!
You could see strong similarities between lambda calculus and 
a functional programming language, but the notion of lambda
calculus is more the field of theoretic computer science than 
that of math ;0).


/Thomas


From etxhste@REDACTED  Fri May 12 19:11:11 2000
From: etxhste@REDACTED (Hakan Stenholm)
Date: Fri, 12 May 2000 19:11:11 +0200
Subject: optimization tricks ?
Message-ID: <391C3B2F.59D762BB@etxb.ericsson.se>

I'm currently working on a strategy game in my spare time (i.e. not a
large distributed real time system) and have spent some time wondering
about how to write efficent (speed and memory vise) erlang code.
I know about tail recursion and last call optimization (allthough
exactly when this ocures seams a bit vauge) and that handling files as
binaries (if posible) can be significantly faster. But I have been
wondering about several things and as erlang was originaly inspired by
prolog these optimization tricks spring to mind:

* in Prolog the order of the predicate (function) clauses affect the
speed of selecting the apropriate clause (first match is used). e.g. :
do_something_per_element([E|Rest]) ->
        do_something(E),
        do_something_per_element(Rest);
do_something_per_element([]) -> ok.

would be faster becouse the first clause is allways the right one expect
in one case (when it is done).
Does this apply to Erlang as well ?

* if the functions clauses use pattern matching in their heads e.g. :
    F1(case_a, D) -> ....
    F1(case_b, D) -> ....

    F2(D, case_a) -> ....
    F2(D, case_b) -> ....

Prolog would be faster for F1 as pattern matching would not be needed
for more than the first argument i.e. keys should be first and placed in
such an order as to reduce the amount of possibal matching function
clauses.
Does this apply to Erlang as well ?
- - - - - - - - - - - - - - - - - - - -

Are there any other non-algoritmic tricks for better perfomance ?
Is pattern matching with atoms faster than strings (i.e. list of
integers which will presumebly need to be matched letter for letter) ?

And yes I _DO_ know that the choice of algoritms is generaly far more
important than tricks that can change the Ordo by some constant    : )

H?kan Stenholm



From rv@REDACTED  Mon May 15 11:12:40 2000
From: rv@REDACTED (Robert Virding)
Date: Mon, 15 May 2000 11:12:40 +0200
Subject: optimization tricks ? 
In-Reply-To: Your message of "Fri, 12 May 2000 19:11:11 +0200."
             <391C3B2F.59D762BB@etxb.ericsson.se> 
Message-ID: <200005150912.LAA22649@trana.bluetail.com>

Hakan Stenholm <etxhste@REDACTED> writes:
>* in Prolog the order of the predicate (function) clauses affect the
>speed of selecting the apropriate clause (first match is used). e.g. :
>do_something_per_element([E|Rest]) ->
>        do_something(E),
>        do_something_per_element(Rest);
>do_something_per_element([]) -> ok.
>
>would be faster becouse the first clause is allways the right one expect
>in one case (when it is done).
>Does this apply to Erlang as well ?

Not really!  The pattern matching compiler reorders clauses where it 
safely can so that arguments of the same type are together, it then 
reorders the types with a (very) simple heuristic to try and optimise 
speed.  Basically it orders them as cons, tuples, atomic.

However, within each type it does not reorder the clauses.  So you could 
get some benefit from ordering clauses, BUT we also do hash indexing 
which removes the order dependency.

>* if the functions clauses use pattern matching in their heads e.g. :
>    F1(case_a, D) -> ....
>    F1(case_b, D) -> ....
>
>    F2(D, case_a) -> ....
>    F2(D, case_b) -> ....
>
>Prolog would be faster for F1 as pattern matching would not be needed
>for more than the first argument i.e. keys should be first and placed in
>such an order as to reduce the amount of possibal matching function
>clauses.
>Does this apply to Erlang as well ?

No!  We do match from left to right but all the tricks and 
optimisations are done to all the arguments so there is no gain in 
speed through reordering the arguments.  Prolog does not do this.

>Are there any other non-algoritmic tricks for better perfomance ?
>Is pattern matching with atoms faster than strings (i.e. list of
>integers which will presumebly need to be matched letter for letter) ?

Pattern matching is definitely faster with atomics than with structures
like strings which are matched character by character.  There is *VERY*
little gain, however, in using integers instead of atoms, so be clear.

>And yes I _DO_ know that the choice of algoritms is generaly far more
>important than tricks that can change the Ordo by some constant    : )

Well, my opinion is that it is always better to have clear code which 
works rather than fast optimised code which doesn't.  As someone once 
said, it is easy to optimise as erroneous program.

	Robert

-- 
Robert Virding                          Tel: +46 (0)8 692 22 12
Bluetail AB                             Email: rv@REDACTED
Hantverkargatan 78                      WWW: http://www.bluetail.com/~rv
SE-112 38 Stockholm, SWEDEN
"Folk s?ger att jag inte bryr mig om n?gonting, men det skiter jag i".




From cesarini@REDACTED  Mon May 15 11:32:01 2000
From: cesarini@REDACTED (Francesco Cesarini)
Date: Mon, 15 May 2000 10:32:01 +0100
Subject: optimization tricks ?
References: <391C3B2F.59D762BB@etxb.ericsson.se>
Message-ID: <391FC411.4788781D@terminus.ericsson.se>

Erlang methodology:

1. First make it work
2. Then make it beautiful
3. Then [if you *really* *really* have to] make it fast [keeping it
beautiful and correct].

In 9 cases out of 10, you will realize you do not need step 3 as the
application runs fast enough. In the 10th case, you probably won't have
time for the third step.

//FC

Hakan Stenholm wrote:
> 
> I'm currently working on a strategy game in my spare time (i.e. not a
> large distributed real time system) and have spent some time wondering
> about how to write efficent (speed and memory vise) erlang code.
> I know about tail recursion and last call optimization (allthough
> exactly when this ocures seams a bit vauge) and that handling files as
> binaries (if posible) can be significantly faster. But I have been
> wondering about several things and as erlang was originaly inspired by
> prolog these optimization tricks spring to mind:
> 
> * in Prolog the order of the predicate (function) clauses affect the
> speed of selecting the apropriate clause (first match is used). e.g. :
> do_something_per_element([E|Rest]) ->
>         do_something(E),
>         do_something_per_element(Rest);
> do_something_per_element([]) -> ok.
> 
> would be faster becouse the first clause is allways the right one expect
> in one case (when it is done).
> Does this apply to Erlang as well ?
> 
> * if the functions clauses use pattern matching in their heads e.g. :
>     F1(case_a, D) -> ....
>     F1(case_b, D) -> ....
> 
>     F2(D, case_a) -> ....
>     F2(D, case_b) -> ....
> 
> Prolog would be faster for F1 as pattern matching would not be needed
> for more than the first argument i.e. keys should be first and placed in
> such an order as to reduce the amount of possibal matching function
> clauses.
> Does this apply to Erlang as well ?
> - - - - - - - - - - - - - - - - - - - -
> 
> Are there any other non-algoritmic tricks for better perfomance ?
> Is pattern matching with atoms faster than strings (i.e. list of
> integers which will presumebly need to be matched letter for letter) ?
> 
> And yes I _DO_ know that the choice of algoritms is generaly far more
> important than tricks that can change the Ordo by some constant    : )
> 
> H?kan Stenholm

-- 
Francesco Cesarini

Erlang/OTP consultant
Cellular: +44-(0)7776 250381
ECN: 832-707192


From etxuwig@REDACTED  Mon May 15 12:01:09 2000
From: etxuwig@REDACTED (Ulf Wiger)
Date: Mon, 15 May 2000 12:01:09 +0200 (MET DST)
Subject: optimization tricks ?
In-Reply-To: <391C3B2F.59D762BB@etxb.ericsson.se>
Message-ID: <Pine.GSO.4.10.10005151051530.12823-100000@avc303>

On Fri, 12 May 2000, Hakan Stenholm wrote:

>* in Prolog the order of the predicate (function) clauses affect the
>speed of selecting the apropriate clause (first match is used). e.g. :
>do_something_per_element([E|Rest]) ->
>        do_something(E),
>        do_something_per_element(Rest);
>do_something_per_element([]) -> ok.
>
>would be faster becouse the first clause is allways the right one expect
>in one case (when it is done).
>Does this apply to Erlang as well ?

Robert has already answered this.


>Are there any other non-algoritmic tricks for better perfomance ?

Yes.

Francesco has already given you the Speech about how you shouldn't
worry about optimization until you have working (beautiful) code.

However, having spent the last four years on a product where we
had to constantly invent ways to improve performance, I have some
views of my own on the subject:

1. First, we've come across several cases where programmers have
optmimized themselves into bad, unsafe, and even inefficient code. One
of the better ones is using gen_server:cast/2 instead of
gen_server:call/3 "because it's faster" (I'll let you ponder that one
for yourselves.) You really need to understand your application (and
Erlang)  well before you can start optimizing.

2. Don't believe rumours like "the lists module is inefficiently
implemented, so you should write your own list functions". Perhaps
this started due to an unfortunate modification of lists:map/2 back in
the old days. Indeed, some of the lists functions (e.g. member,
keysearch, reverse, append) are even BIFs, and can't be beaten by
Erlang code. This is an example of how you'd be better off pointing
out where Erlang needs to improve, and wait until the improvements are
implemented.

Below is a rambling collection of optimization tricks. Not knowing
your application, it's of course hard to be specific.

3. If you really want to make an implementation-specific optimization,
break it out, make it easy to change, document it carefully, and plan
to keep up with the development of Erlang/OTP, so that you'll know
when your optimization has become obsolete.

4. All ets table reads and writes are copying operations, so strive
to keep objects small (at least give this some thought if your objects
are very large.)

5. setelement/3 becomes expensive on very large tuples. You might want
to consider switching to another representation (e.g. dynarray or
ets).

6. Try to avoid code that builds enormous amounts of live data on the
process heap. The garbage collector has a hard time with this, and you
may end up allocating tremendous amounts of memory (tricky area - it's
best to do a lot of profiling in order to understand this, before
trying to optimize.) You might want to look at the options available
for the obscure BIF spawn_opt/4 (e.g. gc_switch). If you are deeply
familiar with the characteristics of the garbage collector, you can
specify whether you want fullsweep collection or generational (or
both) for your process.

7. A more useful option for spawn_opt is perhaps 'min_heap_size',
allowing you to set a heap large enough that you completely avoid GC.
This can be used for jobs that are short but intense: you spawn a
process with a large heap, then have at it until the job is done, and
then terminate the process. This can give significantly better
performance.

8. If your application has "I/O" processes, whose job is simply to
dispatch information to the process doing the actual work, set it to
high priority. This type of process can be seen as an interrupt
handler, and keeping them on normal priority usually only increases
latency.

9. If your application uses strings a lot, perhaps to send them
through a port to the user (e.g. a web server), don't worry about
flattening lists. The Erlang ports are quite happy with deep lists,
and will normally do a better job of flattening them than you can.

/Uffe
-- 
Ulf Wiger, Chief Designer AXD 301         <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuv?gen 9, ?lvsj?                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44





From dgould@REDACTED  Mon May 15 19:00:33 2000
From: dgould@REDACTED (dgould@REDACTED)
Date: Mon, 15 May 2000 10:00:33 -0700
Subject: optimization tricks ?
In-Reply-To: <391FC411.4788781D@terminus.ericsson.se>; from cesarini@terminus.ericsson.se on Mon, May 15, 2000 at 10:32:01AM +0100
References: <391C3B2F.59D762BB@etxb.ericsson.se> <391FC411.4788781D@terminus.ericsson.se>
Message-ID: <20000515100033.A8133@archimedes.suse.com>

On Mon, May 15, 2000 at 10:32:01AM +0100, Francesco Cesarini wrote:
> Erlang methodology:
> 
> 1. First make it work
> 2. Then make it beautiful
> 3. Then [if you *really* *really* have to] make it fast [keeping it
> beautiful and correct].
> 
> In 9 cases out of 10, you will realize you do not need step 3 as the
> application runs fast enough. In the 10th case, you probably won't have
> time for the third step.

Very nice. I prefer however to:

 1. First make it beautiful
 2. Then make it work

Since 2 almost naturally follows from 1.

The corollary is that one rarely ends up debugging pretty code.

-dg "yes I am mostly serious about this"


-- 

David Gould                                             dgould@REDACTED
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
As long as each individual is facing the TV tube alone, formal
freedom poses no threat to privilege.  --Noam Chomsky


From etxuwig@REDACTED  Mon May 15 19:11:05 2000
From: etxuwig@REDACTED (Ulf Wiger)
Date: Mon, 15 May 2000 19:11:05 +0200 (MET DST)
Subject: optimization tricks ?
In-Reply-To: <20000515100033.A8133@archimedes.suse.com>
Message-ID: <Pine.GSO.4.10.10005151902380.12823-100000@avc303>

On Mon, 15 May 2000 dgould@REDACTED wrote:

>Very nice. I prefer however to:
>
> 1. First make it beautiful
> 2. Then make it work
>
>Since 2 almost naturally follows from 1.
>
>The corollary is that one rarely ends up debugging pretty code.
>
>-dg "yes I am mostly serious about this"


The "first make it beautiful, then make it work" philosophy does
conflict somwhat with that other maxim, "plan to throw away the first
version of your program -- you will have to anyway."

In other words, it might be seen as a waste of time making your code
beautiful before you know that your thinking makes sense. In order to
test and verify your ideas, your code doesn't have to be that pretty.

...unless, of course, you write beautiful first drafts.  (:

Having said this, I think it's pretty much a question of different
mindsets. Some people work well only if they are allowed to do things
properly, in order; others create a mess, but lots of good stuff tends
to result from it. I once worked with a guy who was absolutely
brilliant, but who couldn't do anything half-baked even if his life
depended on it. Then again, he was not a programmer...

/Uffe
-- 
Ulf Wiger, Chief Designer AXD 301         <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuv?gen 9, ?lvsj?                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44



From dgould@REDACTED  Mon May 15 20:42:14 2000
From: dgould@REDACTED (dgould@REDACTED)
Date: Mon, 15 May 2000 11:42:14 -0700
Subject: optimization tricks ?
In-Reply-To: <Pine.GSO.4.10.10005151902380.12823-100000@avc303>; from etxuwig@etxb.ericsson.se on Mon, May 15, 2000 at 07:11:05PM +0200
References: <20000515100033.A8133@archimedes.suse.com> <Pine.GSO.4.10.10005151902380.12823-100000@avc303>
Message-ID: <20000515114214.D8133@archimedes.suse.com>

On Mon, May 15, 2000 at 07:11:05PM +0200, Ulf Wiger wrote:
> On Mon, 15 May 2000 dgould@REDACTED wrote:
> 
> >Very nice. I prefer however to:
> >
> > 1. First make it beautiful
> > 2. Then make it work
> >
> >Since 2 almost naturally follows from 1.
> >
> >The corollary is that one rarely ends up debugging pretty code.
> >
> >-dg "yes I am mostly serious about this"
> 
> 
> The "first make it beautiful, then make it work" philosophy does
> conflict somwhat with that other maxim, "plan to throw away the first
> version of your program -- you will have to anyway."
 
I don't think there is a conflict if one expects that it may take a few
discarded rough drafts to get to something approaching beautiful.

The real hazard is when time presses and you end up shipping the rough
draft.

-dg 
-- 

David Gould                                             dgould@REDACTED
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
As long as each individual is facing the TV tube alone, formal
freedom poses no threat to privilege.  --Noam Chomsky


From scott@REDACTED  Mon May 15 22:48:31 2000
From: scott@REDACTED (Scott Lystig Fritchie)
Date: Mon, 15 May 2000 15:48:31 -0500
Subject: optimization tricks ? 
In-Reply-To: Message of "Mon, 15 May 2000 10:32:01 BST."
             <391FC411.4788781D@terminus.ericsson.se> 
Message-ID: <200005152048.PAA33441@snookles.snookles.com>

>>>>> "fc" == Francesco Cesarini <cesarini@REDACTED> writes:

fc> Erlang methodology:

Since most worthwhile performance increases come from algorithmic
changes, I'd have to agree with Francesco's methodology.  Discussion
on the list about whether to go for "beauty" first is just a minor
problem of choosing a decent algorithm ... for some value of decent.
:-)

Once you've decided that you need more speed, and algorithmic changes
have been exhausted (or are impractical), it's worth targeting your
optimization efforts.  The Erlang profiling tools are weak, but they
can help prevent you from optimizing code that has a minimal effect.
Several times, profiling has saved me from doing work: the code that I
thought was a performance problem really wasn't.  Being a lazy
performance optimizer is almost always a good thing.  Look for the low
hanging fruit first.

The "eprof" module in the Erlang distribution was giving me headaches
(as discussed in this forum a few months back).  Ulf Wiger, I believe,
told me to do what his team ended up doing when facing the same
problem: write my own profiler.  I chose instead to hack "eprof".  The
result isn't pretty, but it does a much better job than "eprof" does.

It still isn't as accurate as it should be, but it doesn't seem to be
my fault.  The trace messages generated by the BEAM VM don't always
cooperate.  I've seen cases where a gen_server callback looking
something like (pulling from memory):

	handle_call({foo, Bar, Baz}, From, State) ->
	    Reply = call_real_foo_func(Bar, Baz, State),
	    {reply, Reply, State);

	call_real_foo_func(A, B, S) when tuple(A) ->
	    do_foo(A, B, S);
	call_real_foo_func(A, B, S) when atom(A) ->
	    do_some_other_foo(A, B, S).

... would sometimes only tally one call to call_real_foo_func() when I
*know* it's being called hundreds of times via handle_call().  {shrug}
Given the rumors that R7 is going to have a new and improved profiler,
I haven't worried much about it because it's infrequent.  (If anyone
finds a bug in the code below, feel free to fix it and lemme know.  :-)

At any rate, the eprof-derived profiler code, dubbed slf_eprof.erl, is
included below.

-Scott

P.S.  Oh, one other thing.  We learned a fair amount about our
application by enabling profiling when compiling the BEAM interpreter.
It's kindof a 10,000 meter overview of how things work, but it was
worth doing.  Add "-pg" to the "TYPE_FLAGS" line in
erts/emulator/Makefile.in, then a "./configure" at the top, then
compile, run your app, then analyze with "gprof".

P.P.S.  Eprof and slf_eprof are both really annoying because they
don't maintain call graphs.  (Difficult, perhaps impossible, with the
current tracing messages.)  Hopefully the new profiler will be able to
track a function's time and the time of its descendents.

--- snip --- snip --- snip --- snip --- snip --- snip --- snip --- snip --- 

%% ``The contents of this file are subject to the Erlang Public License,
%% Version 1.1, (the "License"); you may not use this file except in
%% compliance with the License. You should have received a copy of the
%% Erlang Public License along with this software. If not, it can be
%% retrieved via the world wide web at http://www.erlang.org/.
%% 
%% Software distributed under the License is distributed on an "AS IS"
%% basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
%% the License for the specific language governing rights and limitations
%% under the License.
%% 
%% The Initial Developer of the Original Code is Ericsson Utvecklings AB.
%% Portions created by Ericsson are Copyright 1999, Ericsson Utvecklings
%% AB. All Rights Reserved.''
%% 
%%     $Id: slf_eprof.erl,v 1.5 2000/03/28 00:11:10 scott Exp $
%%
%% Purpose: Profile a system in order to figure out where the 
%% time goes.
%%
%% Hacked by Scott Lystig Fritchie, <scott@REDACTED>.  Based in large
%% part on eprof.erl from the R6B distro ... and is *much* more accurate
%% than the original.  AFAIK, its errors aren't due to significant bugs
%% in this module but are rather caused by quirks from the trace messages
%% generated by the current BEAM VM.  Bug fixes and additions are welcome.
%%
%% Rumor has it there's a new profiler in the works for R7.  Hopefully
%% this hacked eprof will not be necessary when R7 is released.  In
%% the meantime, feel free to use this module for whatever purpose
%% within the license's constraints.
%%
%% New start() syntax.  start(wall_clock) measures wall-clock time, where
%% time spent swapped out will be counted against the function being traced.
%% start(swapped) will explictly measure the amount of time spent swapped out.
%% start() will default to start(swapped).
%%
%% NOTE: Use of "wall_clock" is not recommended.  Caveat user.
%%
%% It would be *really* cool if we could tell the difference between being
%% swapped out because our quantum was spent or because we we blocked
%% trying to "receive" on a mailbox that didn't have a matching message.
%%
%% Example usage:	slf_eprof:start(swapped|wall_clock).

-module(slf_eprof).
-behaviour(gen_server).

-define(NAME, slf_eprof).
-define(GARBAGE_FUNC, {erlang, garbage_collection, 0}).

-export([start/0, start/1, stop/0, dump/0, total_analyse/0,
	 start_profiling/1, profile/4, profile/1,
	 stop_profiling/0, analyse/0, log/1]).
-export([keep_history/1, get_history/0]).

%% Internal exports 
-export([init/1,
	 call/4,
	 handle_call/3,
	 handle_cast/2,
	 handle_info/2,
	 terminate/2,
	 echo/0]).

-import(lists, [flatten/1,reverse/1,keysort/2, member/2,keysearch/3]).

-record(state, {table = notable,
		method = void,
		proc = noproc, 
		profiling = false, 
		pfunc = nofunc,
		ptime = 0,
		acktime = 0,
		pop = running,
		keephistory = false,
		history = [],
		rootset = []}).

%%%%%%%%%%%%%%

start() ->
    start(swapped).
start(Method) when atom(Method) ->
    if
	Method == wall_clock; Method == swapped ->
	    gen_server:start({local, ?NAME}, ?NAME, [Method], []);
	true ->
	    io:format("usage: start(wall_clock | swapped)\n"),
	    {error, usage}
    end.
stop()  -> gen_server:call(?NAME, stop, infinity).


profile(Pids,M,F,A) ->
    start(),
    gen_server:call(?NAME, {profile,Pids, M,F,A},infinity).

dump() -> 
    gen_server:call(?NAME, dump, infinity).

analyse() ->
    gen_server:call(?NAME, analyse, infinity).

log(File) ->
    gen_server:call(?NAME, {logfile, File}, infinity).

total_analyse() ->
    gen_server:call(?NAME, total_analyse, infinity).

start_profiling(Rootset) ->
    start(),
    gen_server:call(?NAME, {profile, Rootset}, infinity).

stop_profiling() ->
    gen_server:call(?NAME, stop_profiling, infinity).

profile(Rs) ->
    start_profiling(Rs).

keep_history(Value) ->				% true | false
    gen_server:call(?NAME, {keep_history, Value}, infinity).

get_history() ->
    gen_server:call(?NAME, get_history, infinity).

%%%%%%%%%%%%%%%%

init([Method]) ->
    process_flag(trap_exit, true),
    process_flag(priority, max), 
    put(oct, onecalltime()),			% The time erlang:time() takes.
    put(sched_time, sched_time()),
    {ok, #state{method = Method}}.

subtr({X1,Y1,Z1}, {X1,Y1,Z2}) ->
    Z1 - Z2;
subtr({X1,Y1,Z1}, {X1,Y2,Z2}) ->
    ((Y1 * 1000000) + Z1) - ((Y2 * 1000000) + Z2).

collect_trace_messages() ->
    receive
	X when tuple(X), element(1,X) == trace_ts ->
	    [X | collect_trace_messages()];
	X when tuple(X), element(1,X) == trace ->
	    [X | collect_trace_messages()]
    after 0 -> 
	    []
    end.

into_tab(Method, Tab, Pid, Op, Func, Time) ->
    case Func of
	%% If you wish to do pattern matching beyond what erlang:trace_pattern
	%% can do, put it here.  Too bad it needs to be recompiled to change
	%% the pattern.
	{erlang, make_ref, 0} ->
	    %% Do something first, perhaps?
	    into_tab2(Method, Tab, Pid, Op, Func, Time);
	_ ->
	    into_tab2(Method, Tab, Pid, Op, Func, Time)
    end.
into_tab2(Method, Tab, Pid, Op, Func, Time) ->
    LastKey = {last, Pid},
    case ets:lookup(Tab, LastKey) of
	[] ->		% First we've heard from this pid.
	    case Op of
		in ->
		    ets:insert(Tab, {LastKey, Func, Time});
		out ->
		    do_nothing;
		return_to ->
		    ets:insert(Tab, {LastKey, Func, Time});
		call ->
		    ets:insert(Tab, {LastKey, Func, Time});
		gc_start ->
		    %% Pretend a pseudo-function: erlang:gc/0.
		    ets:insert(Tab, {LastKey, ?GARBAGE_FUNC, Time}),
		    %% Gotta push a bogus entry onto the "stack".
		    ets:insert(Tab, {{gc_stack, Pid}, {nofunc, nofunc, 0}, 0});
		gc_end ->
		    do_nothing;
		_ ->
		    io:format("into_tab: first-timers: got op ~w for pid ~w\n", [Op, Pid])
	    end;
	[{LastKey, LastFunc, LastTime}] -> % Perhaps stackable?
	    TimeDiff = subtr(Time, LastTime),
	    AccKey = {Pid, LastFunc},		% Accumulator key
	    case Op of
		in ->
		    if
			Method == swapped ->
			    %% Sum the amount of time we've spent swapped out.
			    sum_it(Tab, {Pid, LastFunc}, TimeDiff, 1);
			true ->
			    %% Don't inflate the number of times the suspended
			    %% function was called.
			    sum_it(Tab, {Pid, LastFunc}, TimeDiff, 0)
		    end,
		    ets:insert(Tab, {LastKey, Func, Time});
		out ->
		    if
			Func == LastFunc ->
			    ok;
			true ->
			    ok
		    end,
		    sum_it(Tab, AccKey, TimeDiff, 0),
		    if
			Method == swapped ->
			    ets:insert(Tab, {LastKey, {erlang, swapped_out, 0},
					     Time});
			true ->
			    ok
		    end;		    
		return_to ->
		    sum_it(Tab, AccKey, TimeDiff, 0),
		    ets:insert(Tab, {LastKey, Func, Time});
		call ->
		    sum_it(Tab, AccKey, TimeDiff, 0),
		    sum_it(Tab, {Pid, Func}, 0, 1), % Incr count for this func
		    ets:insert(Tab, {LastKey, Func, Time});
		gc_start ->
		    sum_it(Tab, AccKey, TimeDiff, 0),
		    ets:insert(Tab, {LastKey, Func, Time}),

		    %% In this case, we need to remember what was going on
		    %% when the GC interrupted.  Push onto a "stack" (with
		    %% max depth of 1) the tuple from "Perhaps stackable?"
		    %% comment above.  We'll retrieve it when we hit gc_end.
		    ets:insert(Tab, {{gc_stack, Pid}, LastFunc, LastTime});
		gc_end ->
		    sum_it(Tab, {Pid, ?GARBAGE_FUNC}, TimeDiff, 1),
		    [{StackKey, StackFunc, StackTime}] =
			ets:lookup(Tab, {gc_stack, Pid}),
		    ets:insert(Tab, {{last, Pid}, StackFunc, StackTime});
		_ ->
		    io:format("into_tab: repeat: got op ~w for pid ~w\n", [Op, Pid])
	    end;
	Error ->
	    io:format("ERROR: into_tab: got ~w\n", [Error])
    end.

do_messages([{trace_ts, Pid, Op, {M, F, A}, Time}|Tail], Tab, Method, Acc) when list(A) ->
    do_messages([{trace_ts, Pid, Op, {M, F, length(A)}, Time}|Tail], Tab, Method, Acc);
do_messages([{trace_ts, Pid, Op, Func, Time} = Msg|Tail], Tab, Method, Acc) ->
    into_tab(Method, Tab, Pid, Op, Func, Time),
    do_messages(Tail,Tab,Method, [Msg|Acc]);
do_messages([], Tab,Method, Acc) ->
    Acc.

sum_it(Tab, Key, Time, CallIncr) ->
    case ets:lookup(Tab, Key) of
	[] ->
	    ets:insert(Tab, {Key, Time, 1});
	[{Key, TotalTime, TotalCalls}] ->
	    ets:insert(Tab, {Key, TotalTime + Time, TotalCalls + CallIncr})
    end.

%%%%%%%%%%%%%%%%%%

handle_cast(Req, S) -> {noreply, S}.

terminate(Reason, S) -> normal.

%%%%%%%%%%%%%%%%%%

handle_call({logfile, F}, _FromTag, Status) ->
    case file:open(F, write) of
	{ok, Fd} ->
	    case get(fd) of
		undefined -> ok;
		FdOld -> file:close(FdOld)
	    end,
	    put(fd, Fd),
	    {reply, ok, Status};
	{error, _} ->
	    {reply, error, Status}
    end;

handle_call({profile, Rootset}, {From, _Tag}, S) ->
    link(From),
    maybe_delete(S#state.table),
    io:format("~s: Starting profiling ..... ~n",[?MODULE]),
    load_check(),
    ptrac(S#state.rootset, false, all()),
    flush_receive(),
    Tab = ets:new(?NAME, [set, public]),
    case ptrac(Rootset, true, all()) of
	false ->
	    {reply, error,  #state{method = S#state.method}};
	true ->
	    erase(replyto),
	    {reply, profiling, #state{table = Tab,
				      method = S#state.method,
				      proc = From,
				      profiling = true,
				      history = [],
				      rootset = Rootset}}
    end;

handle_call(stop_profiling, _FromTag, S) when S#state.profiling == true ->
    ptrac(S#state.rootset, false, all()),
    io:format("~s: Stop profiling~n",[?MODULE]),
    ets:delete(S#state.table, nofunc),
    {reply, profiling_stopped, S#state{profiling = false}};

handle_call(stop_profiling, _FromTag, S) ->
    {reply, profiling_already_stopped, S};

handle_call({profile, Rootset, M, F, A}, FromTag, S) ->
    io:format("~s: Starting profiling ..... ~n",[?MODULE]),
    load_check(),
    maybe_delete(S#state.table),
    ptrac(S#state.rootset, false, all()),
    flush_receive(),
    put(replyto, FromTag),
    Tab = ets:new(?NAME, [set, public]),
    P = spawn_link(?NAME, call, [self(), M, F, A]),
    case ptrac([P|Rootset], true, all()) of
	true ->
	    {noreply, #state{table     = Tab, 
			     method    = S#state.method,
			     profiling = true,
			     rootset   = [P|Rootset]}};
	false ->
	    erase(replyto),
	    {reply, error, #state{method = S#state.method}}
    end;

handle_call(dump, _FromTag, S) ->
    {reply, dump(S#state.table), S};

handle_call(analyse, _FromTag, S) ->
    {reply, analyse(S#state.table), S};

handle_call(total_analyse, _FromTag, S) ->
    {reply, total_analyse(S#state.table), S};

handle_call({keep_history, Value}, _FromTag, S) ->
    {reply, Value, S#state{keephistory = Value}};

handle_call(get_history, _FromTag, S) ->
    {reply, lists:reverse(S#state.history), S};

handle_call(stop, _FromTag, S) ->
    {stop, normal, stopped, S}.

%%%%%%%%%%%%%%%%%%%

handle_info({trace_ts, From, Op, Func, Time} = Msg, S) when S#state.profiling == true ->
    put(start, convert_time(erlang:now())),
    Tmsgs = [{trace_ts, From, Op, Func, Time} | collect_trace_messages()],
    Messages = do_messages(Tmsgs, S#state.table, S#state.method, []),
    if
	S#state.keephistory == true ->
	    {noreply, S#state{history = Messages ++ S#state.history}};
	true ->
	    {noreply, S}
    end;

handle_info({trace_ts, From, _, _, _}, S) when S#state.profiling == false ->
    ptrac([From], false, all()),
    {noreply, S};

handle_info({P, {answer, A}}, S) ->
    ptrac(S#state.rootset, false, all()),
    io:format("~s: Stop profiling~n",[?MODULE]),
    {From, Tag} = get(replyto),
    catch unlink(From),
    ets:delete(S#state.table,nofunc),
    gen_server:reply(erase(replyto), {ok, A}),
    {noreply, S#state{profiling = false,
		      rootset = []}};

handle_info({'EXIT', P, Reason}, S) when S#state.profiling == true,
                                         S#state.proc == P  ->
    maybe_delete(S#state.table),
    ptrac(S#state.rootset, false, all()),
    io:format("~s: Fail profiling~n",[?MODULE]),
    case erase(replyto) of
	undefined ->
	    {noreply, #state{method = S#state.method}};
	FromTag ->
	    gen_server:reply(FromTag, {error, Reason}),
	    {noreply, #state{method = S#state.method}}
    end;

handle_info({'EXIT', P, Reason}, S) ->
    {noreply, S}.

%%%%%%%%%%%%%%%%%%

call(Top, M, F, A) ->
    Top ! {self(), {answer, apply(M,F,A)}}.

ptrac([all|T], How, Flags) ->
    case dotrace(all, How, Flags) of
	true ->
	    ptrac(T, How, Flags);
	false when How == true ->
	    false;
	false ->
	    ptrac(T, How, Flags)
    end;

ptrac([P|T], How, Flags) when pid(P) ->
    case dotrace(P, How, Flags) of
	true ->
	    ptrac(T, How, Flags);
	false when How == true ->
	    false;
	false ->
	    ptrac(T, How, Flags)
    end;

ptrac([P|T], How, Flags) when atom(P) ->
    case whereis(P) of
	undefined when How == true ->
	    false;
	undefined when How == false ->
	    ptrac(T, How, Flags);
	Pid ->
	    ptrac([Pid|T], How, Flags)
    end;

ptrac([H|T], How, Flags) ->
    io:format("** ~s: Bad process: ~w~n",[?MODULE, H]),
    false;

ptrac([],_,_) -> true.

dotrace(P,How,What) ->
    case (catch erlang:trace(P, How, What)) of
	NumPids when integer(NumPids) ->
	    erlang:trace_pattern({'_', '_', '_'}, true),
	    true;
	Other when How == false ->
	    true;
	Other ->
	    io:format("** ~s: erlang:trace: bad process ~w: ~w~n",[?MODULE, P, Other]),
	    false
    end.

all() -> [call, old_call_trace, running, timestamp, set_on_spawn, garbage_collection].

total_analyse(notable) -> 
    nothing_to_analyse;
total_analyse(T) ->
    Pcalls = reverse(keysort(2, replicas(ets:tab2list(T)))),
    Time = collect_times(Pcalls),
    format("FUNCTION~44s      TIME    SECONDS   uSEC/CALL~n", ["CALLS"]),   
    printit(Pcalls, Time).

analyse(notable) -> 
    nothing_to_analyse;
analyse(T) ->
    Pids = ordsets:list_to_set(flatten(ets:match(T, {{'$1','_'},'_', '_'}))),
    Times = sum(ets:match(T, {'_','$1', '_'})),
    format("FUNCTION~44s      TIME ~n", ["CALLS"]),     
    do_pids(Pids, T, 0, Times).

do_pids([Pid|Tail], T, AckTime, Total) ->
    Pcalls = 
     reverse(keysort(2, to_tups(ets:match(T, {{Pid,'$1'}, '$2','$3'})))),
    Time = collect_times(Pcalls),
    PercentTotal = 100 * (divide(Time, Total)),
    format("~n****** Process ~w    -- ~s % of profiled time *** ~n", 
	   [Pid, fpf(PercentTotal)]),
    printit(Pcalls, Time),
    do_pids(Tail, T, AckTime + Time, Total);
do_pids([], _, _, _) -> 
    ok.

printit([],_) -> ok;
printit([{{Mod,Fun,Arity}, Time, Calls} |Tail], ProcTime)  ->
    format("~s  ~s ~3s % ~9.4f   ~w~n", [ff(Mod,Fun,Arity), fint(Calls),
			      fpf(100*(divide(Time,ProcTime))), Time/1000000,
					  Time/Calls]),
    printit(Tail, ProcTime);
printit([{{_,{Mod,Fun,Arity}}, Time, Calls} |Tail], ProcTime)  ->
    format("~s  ~s ~3s % ~9.4f   ~w~n", [ff(Mod,Fun,Arity), fint(Calls),
			      fpf(100*(divide(Time,ProcTime))), Time/1000000,
					   Time/Calls]),
    printit(Tail, ProcTime); 
printit([_|T], Time) ->
    printit(T, Time).

ff(Mod,Fun,Arity) ->
    pad(flatten(io_lib:format("~w:~w/~w", [Mod,Fun, Arity])),45).

pad(Str, Len) -> 
    Strlen = length(Str),
    if
	Strlen > Len -> strip_tail(Str, 45);
	true -> lists:append(Str, mklist(Len-Strlen))
    end.

strip_tail([H|T], 0) ->[];
strip_tail([H|T], I) -> [H|strip_tail(T, I-1)];
strip_tail([], I) -> [].

fpf(F) -> strip_tail(flatten(io_lib:format("~.2f", [F])), 5).
fint(Int) -> pad(flatten(io_lib:format("~w",[Int])), 10).

mklist(0) -> [];
mklist(I) -> [$ |mklist(I-1)].

to_tups(L) -> lists:map(fun(List) -> erlang:list_to_tuple(List) end, L).

divide(X,Y) -> X / Y.

collect_times([]) -> 0;
collect_times([Tup|Tail]) -> element(2, Tup) + collect_times(Tail).

dump(T) ->
    L = ets:tab2list(T),
    format(L).

format([H|T]) -> 
    format("~p~n", [H]), format(T);
format([]) -> ok.

format(F, A) ->
    io:format(F,A),
    case get(fd) of
	undefined -> ok;
	Fd -> io:format(Fd, F,A)
    end.

maybe_delete({T,Ref}) when reference(Ref) ->
    ets:delete({T, Ref});
maybe_delete(_) -> ok.

%% Try to figure out how much time a single erlang:time() call takes.

onecalltime() -> hd(lists:sort([oct(), oct(), oct()])).

oct() ->
    garbage_collect(),  %% ehhh
    N = erlang:now(),
    call_loop(100,time),
    Time1 = subtr(erlang:now(), N) div 100,

    garbage_collect(),  %% ehhh
    N2 = erlang:now(),
    call_loop(100,notime),
    Time2 = subtr(erlang:now(), N2) div 100,
    
    (Time1 - Time2) div 2.

sched_time() ->
    P = spawn(?NAME, echo, []),
    X = erlang:now(),
    P ! self(),
    receive P -> ok end,
    subtr(erlang:now(), X).

echo() ->
    receive P -> P ! self() end.

call_loop(0,_) -> ok;
call_loop(I,time) ->
    erlang:now(), call_loop(I-1,time);
call_loop(I, notime) ->
    call_loop(I-1, notime).

convert_time({Msecs,Secs,Mysecs}) ->
    (1000000000000 * Msecs) + (1000000 * Secs) + Mysecs.

sum([[H]|T]) -> H + sum(T);
sum([]) -> 0.

replicas(L) ->
    replicas(L, []).

replicas([{{Pid, {Mod,Fun,Arity}}, Ack,Calls} |Tail], Result) ->
    case search({Mod,Fun,Arity},Result) of
	false ->
	    replicas(Tail, [{{Pid, {Mod,Fun,Arity}}, Ack,Calls} |Result]);
	{Ack2, Calls2} ->
	    Result2 = del({Mod,Fun,Arity}, Result),
	    replicas(Tail, [{{Pid, {Mod,Fun,Arity}}, 
			     Ack+Ack2,Calls+Calls2} |Result2])
    end;

replicas([_|T], Ack) ->  %% Whimpy
    replicas(T, Ack);

replicas([], Res) -> Res.

search(Key, [{{_,Key}, Ack, Calls}|_]) -> 
    {Ack, Calls};
search(Key, [_|T]) -> 
    search(Key, T);
search(Key, []) -> false.

del(Key, [{{_,Key}, Ack, Calls}|T]) ->
    T;
del(Key, [H | Tail]) ->
    [H|del(Key, Tail)];
del(Key, []) -> [].

flush_receive() ->
    receive 
	{trace_ts, From, _, _, _} when pid(From) ->
	    ptrac([From], false, all()),
	    flush_receive();
	_ ->
	    flush_receive()
    after 0 ->
	    ok
    end.

load_check() ->
    load_check(code:all_loaded()).
load_check([{Mod, File} |Tail]) ->
    load_check_mod(Mod, keysearch(options, 1,
				  apply(Mod, module_info,[compile]))),
    load_check(Tail);
load_check([]) -> done.

load_check_mod(Mod, {value, {_, Opts}}) ->
    case member(trace, Opts) of
	true -> true;
	false -> 
	    io:format("** ~s: Warning module ~w not trace compiled ~n", 
		      [?MODULE, Mod])
    end;
load_check_mod(Mod, _) ->
    io:format("** ~s: No compile_opts found in ~w:module_info()~n", [?MODULE, Mod]).



From jhague@REDACTED  Tue May 16 04:39:24 2000
From: jhague@REDACTED (James Hague)
Date: Mon, 15 May 00 21:39:24 -0500
Subject: optimization tricks ? 
Message-ID: <200005160239.VAA10215@node-02.advancenet.net>

>Since most worthwhile performance increases come from algorithmic
>changes, I'd have to agree with Francesco's methodology.  Discussion
>on the list about whether to go for "beauty" first is just a minor
>problem of choosing a decent algorithm ... for some value of decent.
>:-)

You also have to realize the limits of Erlang, or at least the type of 
problem it isn't suited for.  If your problem is very state-heavy, then 
writing it in an imperative language may make sense.  Some types of 
games--what the orignal poster mentioned--tend to lean more toward the 
imperative side of things.  Might be able to get away with just using ETS 
or process tables in lieu of variables.  Be interesting to try.

One tiny code improvement that isn't used in many older examples is this:

dumb_example({X,Y}, L) -> {X+Y, {X,Y}}.

can be replaced by:

dumb_example({X,Y}=A, L) -> {X+Y, A}.

The second version avoids rebuilding the {X,Y} tuple, or so I've been 
told :)

James


From SadikovIF@REDACTED  Tue May 16 10:57:10 2000
From: SadikovIF@REDACTED (SadikovIF)
Date: Tue, 16 May 2000 13:57:10 +0500
Subject: Question
Message-ID: <39210D65.C83DF73@ic.bashedu.ru>

I would like to know, whether there are mirrors yours web-page in
Russian.
Beforehand to you is grateful!
S.Ilshat
SadikovIF@REDACTED
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20000516/2ae8347a/attachment.htm>

From bjorn@REDACTED  Tue May 16 14:42:35 2000
From: bjorn@REDACTED (Bjorn Gustavsson)
Date: 16 May 2000 14:42:35 +0200
Subject: optimization tricks ?
In-Reply-To: Scott Lystig Fritchie's message of "Mon, 15 May 2000 15:48:31 -0500"
References: <200005152048.PAA33441@snookles.snookles.com>
Message-ID: <o1ya5all8k.fsf@erix.ericsson.se>

There will be a better eprof module in R7, not an entirely new profiler.

The new eprof module will use the new local call trace facility in R7,
meaning that you don't have to trace-compile the modules to be traced.
Also, the new eprof module is faster (it will slow down your program less
than the old version).

I've had good experiences with profiling. I've have found several totally
unexpected bottle-necks which I would never have guessed otherwise.

In a C++ project some five years ago our program was too slow. Elobarate
re-designs were proposed. When I profiled the program with Quantify,
the bottle-neck turned out to be a short loop where an object was allocated
and then immediately destroyed each time the loop was executed. Moving
the object allocation out of the loop eliminated the entire speed problem.

With the help of the current version of eprof I found an bottle-neck in
the Erlang compiler. It was easy to eliminate the problem as soon as I
found it, but I would probably not have found the bottle-neck without
a profiler. (The problem in the compiler was fixed before R6 was released.)

BTW, there is a "caller" instruction that can be used in trace patterns
to get the caller of the current function. I suppose it could be used
to make call graphs.

/Bjorn

Scott Lystig Fritchie <scott@REDACTED> writes:

> >>>>> "fc" == Francesco Cesarini <cesarini@REDACTED> writes:
> 
> fc> Erlang methodology:
> 
> Since most worthwhile performance increases come from algorithmic
> changes, I'd have to agree with Francesco's methodology.  Discussion
> on the list about whether to go for "beauty" first is just a minor
> problem of choosing a decent algorithm ... for some value of decent.
> :-)
> 
> Once you've decided that you need more speed, and algorithmic changes
> have been exhausted (or are impractical), it's worth targeting your
> optimization efforts.  The Erlang profiling tools are weak, but they
> can help prevent you from optimizing code that has a minimal effect.
> Several times, profiling has saved me from doing work: the code that I
> thought was a performance problem really wasn't.  Being a lazy
> performance optimizer is almost always a good thing.  Look for the low
> hanging fruit first.
> 
> The "eprof" module in the Erlang distribution was giving me headaches
> (as discussed in this forum a few months back).  Ulf Wiger, I believe,
> told me to do what his team ended up doing when facing the same
> problem: write my own profiler.  I chose instead to hack "eprof".  The
> result isn't pretty, but it does a much better job than "eprof" does.
> 
> It still isn't as accurate as it should be, but it doesn't seem to be
> my fault.  The trace messages generated by the BEAM VM don't always
> cooperate.  I've seen cases where a gen_server callback looking
> something like (pulling from memory):
> 
> 	handle_call({foo, Bar, Baz}, From, State) ->
> 	    Reply = call_real_foo_func(Bar, Baz, State),
> 	    {reply, Reply, State);
> 
> 	call_real_foo_func(A, B, S) when tuple(A) ->
> 	    do_foo(A, B, S);
> 	call_real_foo_func(A, B, S) when atom(A) ->
> 	    do_some_other_foo(A, B, S).
> 
> ... would sometimes only tally one call to call_real_foo_func() when I
> *know* it's being called hundreds of times via handle_call().  {shrug}
> Given the rumors that R7 is going to have a new and improved profiler,
> I haven't worried much about it because it's infrequent.  (If anyone
> finds a bug in the code below, feel free to fix it and lemme know.  :-)
> 
> At any rate, the eprof-derived profiler code, dubbed slf_eprof.erl, is
> included below.
> 
> -Scott
> 
> P.S.  Oh, one other thing.  We learned a fair amount about our
> application by enabling profiling when compiling the BEAM interpreter.
> It's kindof a 10,000 meter overview of how things work, but it was
> worth doing.  Add "-pg" to the "TYPE_FLAGS" line in
> erts/emulator/Makefile.in, then a "./configure" at the top, then
> compile, run your app, then analyze with "gprof".
> 
> P.P.S.  Eprof and slf_eprof are both really annoying because they
> don't maintain call graphs.  (Difficult, perhaps impossible, with the
> current tracing messages.)  Hopefully the new profiler will be able to
> track a function's time and the time of its descendents.

-- 
Bj?rn Gustavsson            Ericsson Utvecklings AB
bjorn@REDACTED      ?T2/UAB/F/P
			    BOX 1505
+46 8 727 56 87 	    125 25 ?lvsj?


From bjorn@REDACTED  Tue May 16 18:02:54 2000
From: bjorn@REDACTED (Bjorn Gustavsson)
Date: 16 May 2000 18:02:54 +0200
Subject: Question
In-Reply-To: SadikovIF's message of "Tue, 16 May 2000 13:57:10 +0500"
References: <39210D65.C83DF73@ic.bashedu.ru>
Message-ID: <o166selbyp.fsf@erix.ericsson.se>

SadikovIF <SadikovIF@REDACTED> writes:

> Content-type: text/plain ; charset = koi8-r
> 
> I would like to know, whether there are mirrors yours web-page in
> Russian.

Po mojemu, njet zerkalov (mirrors) na russkom jazyke nasjich web-stranits.

As far as I know, there are no mirrors of our web pages in the Russian language.

/Bjorn

> Beforehand to you is grateful!
> S.Ilshat
> SadikovIF@REDACTED
> 

-- 
Bj?rn Gustavsson            Ericsson Utvecklings AB
bjorn@REDACTED      ?T2/UAB/F/P
			    BOX 1505
			    125 25 ?lvsj?


From etxhste@REDACTED  Tue May 16 18:28:23 2000
From: etxhste@REDACTED (Hakan Stenholm)
Date: Tue, 16 May 2000 18:28:23 +0200 (MET DST)
Subject: optimization tricks ?
Message-ID: <200005161628.SAA11914@avc240.etxb.ericsson.se>


> Date: Mon, 15 May 2000 10:32:01 +0100
> From: Francesco Cesarini <cesarini@REDACTED>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: erlang-questions@REDACTED
> CC: Hakan Stenholm <etxhste@REDACTED>
> Subject: Re: optimization tricks ?
> Content-Transfer-Encoding: 8bit
> 
> Erlang methodology:
> 
> 1. First make it work
> 2. Then make it beautiful
> 3. Then [if you *really* *really* have to] make it fast [keeping it
> beautiful and correct].
> 
I agree that point 1 and 2 generaly are sufficent but ocasionaly point 3 will 
rear it's ugly head and it might be usefull to know what to do in these cases.
 
It does also seam to me that if one knowns the behaviour (bugs, Ordos of 
operations ...) of different language constructs and libraries, that one often 
will be able to write better/faster/stabler/more butiful code if one is aware of 
the shortcomings and advantages of different solutions.

My main purpouse of asking wasn't becouse I wanted to do a lot of optimization 
(that will be something to look into if things go to slowly) but rather to get a 
grasp of what can be done in the way of optimization if one has to do it and 
what returns in terms of speed (and memory usage) one can expect.

> In 9 cases out of 10, you will realize you do not need step 3 as the
> application runs fast enough. In the 10th case, you probably won't have
> time for the third step.
> 
> //FC
> 
> Hakan Stenholm wrote:
> > 
> > I'm currently working on a strategy game in my spare time (i.e. not a
> > large distributed real time system) and have spent some time wondering
> > about how to write efficent (speed and memory vise) erlang code.
....
....
> > H?kan Stenholm
> 
> -- 
> Francesco Cesarini
> 
> Erlang/OTP consultant
> Cellular: +44-(0)7776 250381
> ECN: 832-707192



From jonas.jerfsten@REDACTED  Tue May 16 21:48:55 2000
From: jonas.jerfsten@REDACTED (Jonas Jerfsten)
Date: Tue, 16 May 2000 21:48:55 +0200
Subject: How does the garbage collector really works?
Message-ID: <LPBBKHKEDFELLHNDPNDBAECCCAAA.jonas.jerfsten@st.se>

Hi!
I have a question about how the garbage collector (gc) in Erlang works. I am
working on a module that performs a file:consult/1 on a large file and then
stores the data in an ets-table. All that is done in the init of the
process. I have performed memory analysis on the process using
erlang:trace/3 and process_info/2. It seems as if the file:consult/1
function call results in a large memory allocation and that the process will
hold on to that memory even after the calling function has gone out of
scope. If I do not make any further function calls to the process, it seems
as if the gc will not go in and free the memory. That means that when the
process is initialised, it will allocate a lot of memory and keep it until
the process is scheduled again. Correct? Or am I making incorrect
assumptions from my memory analysis? If the process is not scheduled again,
when will the gc free the memory?

/Jonas Jerfsten

------------------------------------------------
Sj?land & Thyselius AB
Address: Sehlstedtsgatan 6, S-115 28 STOCKHOLM
Phone:+46(0)8-587 623 04 Mobil: +46(0)708-12 33 36 Fax: +46(0)8-667 82 30
Internet: jonas.jerfsten@REDACTED, http://www.st.se/



From Pekka.Hedqvist@REDACTED  Wed May 17 07:41:02 2000
From: Pekka.Hedqvist@REDACTED (Pekka.Hedqvist@REDACTED)
Date: Wed, 17 May 2000 15:41:02 +1000 (EST)
Subject: Monitoring of nodes..
Message-ID: <14626.12526.990595.445925@eddieware.eddieware.org>

What have I missed if I have three (3) nodes <a@REDACTED,b@REDACTED,c@REDACTED>, they
are all "connected" with each other. Node 'a@REDACTED' does BIF calls to
monitor_node(b@REDACTED, true) and monitor_node(c@REDACTED,true). Now node
'a@REDACTED' monitors both node 'b@REDACTED' and node 'c@REDACTED'. If I terminate
node 'b@REDACTED', node 'a@REDACTED' should receive an {nodedown, b@REDACTED} message
which it does. 
BUT, if I then terminate the 'c@REDACTED' node I do NOT receive any
{nodedown, c@REDACTED} message. Now, is this the correct behaviour? It's
not what I expected anyway..?

/pekka



From geoff@REDACTED  Wed May 17 08:06:09 2000
From: geoff@REDACTED (Geoff Wong)
Date: Wed, 17 May 2000 16:06:09 +1000 (EST)
Subject: Monitoring of nodes..
In-Reply-To: <14626.12526.990595.445925@eddieware.eddieware.org> from "Pekka.Hedqvist@ericsson.com" at May 17, 2000 03:41:02 PM
Message-ID: <200005170606.GAA13951@gecko.serc.rmit.edu.au>

> 
> What have I missed if I have three (3) nodes <a@REDACTED,b@REDACTED,c@REDACTED>, they
> are all "connected" with each other. Node 'a@REDACTED' does BIF calls to
> monitor_node(b@REDACTED, true) and monitor_node(c@REDACTED,true). Now node
> 'a@REDACTED' monitors both node 'b@REDACTED' and node 'c@REDACTED'. If I terminate
> node 'b@REDACTED', node 'a@REDACTED' should receive an {nodedown, b@REDACTED} message
> which it does. 
> BUT, if I then terminate the 'c@REDACTED' node I do NOT receive any
> {nodedown, c@REDACTED} message. Now, is this the correct behaviour? It's
> not what I expected anyway..?
> 

Indeed net_kernel:monitor_nodes(true) also gives unexpected behaviour.

If we do:

net_kernel:monitor_nodes(true),
net_adm:ping(my@REDACTED),  % assuming this is up and responds with 'ping'
receive X -> X end.

Then terminate my@REDACTED and we never get a nodedown message 
on the node which ran net_kernel:monitor_nodes().

Geoff



From mbj@REDACTED  Wed May 17 08:45:59 2000
From: mbj@REDACTED (Martin Bjorklund)
Date: Wed, 17 May 2000 08:45:59 +0200
Subject: Monitoring of nodes..
In-Reply-To: Your message of "Wed, 17 May 2000 16:06:09 +1000 (EST)"
	<200005170606.GAA13951@gecko.serc.rmit.edu.au>
References: <200005170606.GAA13951@gecko.serc.rmit.edu.au>
Message-ID: <20000517084559W.mbj@bluetail.com>

Geoff Wong <geoff@REDACTED> wrote:
> 
> Indeed net_kernel:monitor_nodes(true) also gives unexpected behaviour.
> 
> If we do:
> 
> net_kernel:monitor_nodes(true),
> net_adm:ping(my@REDACTED),  % assuming this is up and responds with 'ping'
> receive X -> X end.
> 
> Then terminate my@REDACTED and we never get a nodedown message 
> on the node which ran net_kernel:monitor_nodes().

Note that you'll receive a nodeup message as well when you ping the
node:

(a@REDACTED)1> net_kernel:monitor_nodes(true).
ok
(a@REDACTED)2> net_adm:ping(my@REDACTED).
pong
(a@REDACTED)3> receive X -> X end.
{nodeup,my@REDACTED}
(a@REDACTED)4> receive Y -> Y end.
  
  [terminating my@REDACTED]

{nodedown,my@REDACTED}


If the node was already connected before thr ping, you wouldn't have
received the nodeup though.  (however, you do receive the nodedown).



/martin


From geoff@REDACTED  Wed May 17 08:51:17 2000
From: geoff@REDACTED (Geoff Wong)
Date: Wed, 17 May 2000 16:51:17 +1000 (EST)
Subject: Monitoring of nodes..
In-Reply-To: <20000517084559W.mbj@bluetail.com> from "Martin Bjorklund" at May 17, 2000 08:45:59 AM
Message-ID: <200005170651.GAA14189@gecko.serc.rmit.edu.au>


> (a@REDACTED)1> net_kernel:monitor_nodes(true).
> ok
> (a@REDACTED)2> net_adm:ping(my@REDACTED).
> pong
> (a@REDACTED)3> receive X -> X end.
> {nodeup,my@REDACTED}
> (a@REDACTED)4> receive Y -> Y end.
>   
>   [terminating my@REDACTED]
> 
> {nodedown,my@REDACTED}
> 
> 
> If the node was already connected before thr ping, you wouldn't have
> received the nodeup though.  (however, you do receive the nodedown).
> 

Hmm, I gave my example incorrectly. Basically I was
trying to indicate that net_kernel:monitor_nodes(true)
gives the same behaviour as Pekka was explaining  with 
the bif monitor_node.

erl -sname fud
Erlang (BEAM) emulator version 4.9.1 [source]

Eshell V4.9.1  (abort with ^G)
(fud@REDACTED)1> net_adm:ping(y@REDACTED).
pong
(fud@REDACTED)2> net_adm:ping(x@REDACTED).
pong
(fud@REDACTED)3> net_kernel:monitor_nodes(true).
ok
(fud@REDACTED)4> receive A -> A end.
{nodedown,x@REDACTED}
(fud@REDACTED)5> receive A -> A end.

I never get a nodedown when I take down y@REDACTED (after taking
down x@REDACTED).

Geoff





From mbj@REDACTED  Wed May 17 09:03:15 2000
From: mbj@REDACTED (Martin Bjorklund)
Date: Wed, 17 May 2000 09:03:15 +0200
Subject: Monitoring of nodes..
In-Reply-To: Your message of "Wed, 17 May 2000 16:51:17 +1000 (EST)"
	<200005170651.GAA14189@gecko.serc.rmit.edu.au>
References: <200005170651.GAA14189@gecko.serc.rmit.edu.au>
Message-ID: <20000517090315Q.mbj@bluetail.com>

Geoff Wong <geoff@REDACTED> wrote:

> Hmm, I gave my example incorrectly. Basically I was
> trying to indicate that net_kernel:monitor_nodes(true)
> gives the same behaviour as Pekka was explaining  with 
> the bif monitor_node.
> 
> erl -sname fud
> Erlang (BEAM) emulator version 4.9.1 [source]
> 
> Eshell V4.9.1  (abort with ^G)
> (fud@REDACTED)1> net_adm:ping(y@REDACTED).
> pong
> (fud@REDACTED)2> net_adm:ping(x@REDACTED).
> pong
> (fud@REDACTED)3> net_kernel:monitor_nodes(true).
> ok
> (fud@REDACTED)4> receive A -> A end.
> {nodedown,x@REDACTED}
> (fud@REDACTED)5> receive A -> A end.
>
> I never get a nodedown when I take down y@REDACTED (after taking
> down x@REDACTED).

In this case it's because A is bound to {nodedown, x@REDACTED}, so the
receive just hangs, waiting for another nodedown from x@REDACTED

Which OS are you running?  Do you which OS pekka is running?



/martin


From miyakawa@REDACTED  Wed May 17 09:00:14 2000
From: miyakawa@REDACTED (Shinya MIYAKAWA)
Date: Wed, 17 May 2000 16:00:14 +0900
Subject: IFIP TCS2000
Message-ID: <20000517160014S.miyakawa@ito.ecei.tohoku.ac.jp>

[Apologies for multiple copies]

IFIP TCS2000 PROGRAM AND REGISTRATION INFORMATION
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
--------------------------------------------------------------------------

IFIP International Conference on Theoretical Computer Science 
                   (IFIP TCS2000)
 --- Exploring New Frontiers of Theoretical Informatics ---

 August 17 - 19, 2000

 Aoba Memorial Bldg., Tohoku University, Sendai, Japan

 Further Information about IFIP TCS2000 can be obtained on the Web, at

       http://tcs2000.ito.ecei.tohoku.ac.jp/tcs2000/

 Any inquiry on IFIP TCS2000 Program and Registration may be directed to

       TCS2000@REDACTED

--------------------------------------------------------------------------

PRELIMINARY PROGRAM
^^^^^^^^^^^^^^^^^^^
  [Outline]
   
      AUGUST 16: 15:00 Registration at Sendai Tokyu Hotel till 20:00
                 18:00 Welcome at Sendai Tokyu Hotel till 19:00

      AUGUST 17:  9:30 Opening Session 
                 10:00 Keynote Plenary Talk 1
                 -----------------------------------------
                 11:10 - 17:30  TRACK (1)  ||  TRACK (2) 
                 -----------------------------------------

      AUGUST 18:  9:10 Keynote Plenary Talk 2 
                 -----------------------------------------
                 10:20 - 15:30  TRACK (1)  ||  TRACK (2)
                 -----------------------------------------
                 15:50 Panel Discussion till 17:10
                 -----------------------------------------
                 18:30 Banquet at Sendai Tokyu Hotel

      AUGUST 19:  9:10 Keynote Plenary Talk 3 
                 -----------------------------------------
                 10:20 - 14:20  TRACK (1)  ||  TRACK (2)
                 -----------------------------------------
                 14:30 Closing Session till 14:40
                 -----------------------------------------
                 15:00 Open Lectures till 17:00
                 -----------------------------------------
                 18:30 Japanese Dinner Party till 20:00
                 -----------------------------------------

AUGUST 16 WEDNESDAY
^^^^^^^^^^^^^^^^^^^
  15:00 REGISTRATION at Sendai Tokyu Hotel till 20:00

  18:00 WELCOME with light snack at Sendai Tokyu Hotel till 19:00

AUGUST 17 THURSDAY
^^^^^^^^^^^^^^^^^^
   9:30 OPENING SESSION
        Giorgio Ausiello (TC1 Chair and IFIP TCS2000 Co-Chair)
        Takayasu Ito (IFIP TCS2000 Co-Chair)
  
  10:00 KEYNOTE PLENARY TALK
        Reconciling Two Views of Cryptography (The Computational Soundness 
        of Formal Encryption) 
        Martin Abadi (Bell Labs, Lucent)*, Phillip Rogaway (UC Davis)
           (*: speaker)

  10:50 Break

 [TRACK (1)]

            SESSION (1.1), 11:10 - 12:00

  11:10 Approximation Algorithms for String Folding Problems
        Giancarlo Mauri, Giulio Pavesi

  11:35 An Index for Two Dimensional String Matching Allowing Rotations
        Kimmo Fredriksson, Gonzalo Navarro, Esko Ukkonen

  12:00 Lunch Break

            SESSION (1.2),  13:30 - 14:20

  13:30 Parallel Edge Coloring of a Tree on a Mesh Connected Computer
        Chang-Sung Jeong, Sung-Up Cho, Sun-Chul Whang, Mi-Young Choi

  13:55 Parallel Approximation Algorithms for Maximum Weighted Matching
        in General Graphs
        Ryuhei Uehara, Zhi-Zhong Chen

  14:20 Break

  14:40 TRACK (1) INVITED TALK
        It is on the Boundary: Complexity Considerations for Polynomial 
        Ideals
        Ernst Mayr (TU Muenchen)

  15:30 Break

            SESSION (1.3), 15:50 - 17:30

  15:50 An Efficient Parallel Algorithm for Scheduling Interval Ordered 
        Tasks
        Yoojin Chung, Kunsoo Park, Hyuk-Chul Kwon

  16:15 Task Distributions on Multiprocessor Systems
        Evgeny V. Shchepin, Nodari N. Vakhania

  16:40 Fast Interpolation using Kohonen Self-Organizing Neural Networks
        Olivier Sarzeaud, Yann Stephan

  17:05 Steganography Using Modern Arts
        Carlo Blundo, Clemente Galdi

  17:30 Break

  -----------//

 [TRACK (2)]

            SESSION (2.1), 11:10 - 12:00

  11:10 Ambient Groups and Mobility Types
        Luca Cardelli, Giorgio Ghelli, Andrew D. Gordon

  11:35 An Asynchronous, Distributed Implementation of Mobile Ambients
        Cedric Fournet, Jean-Jacques Levy, Alan Schmitt

  12:00 Lunch Break

  13:30 TRACK (2) INVITED TALK
        Type Systems for Concurrent Processes: From Deadlock-Freedom to 
        Livelock-Freedom, Time-Boundedness
        Naoki Kobayashi (U. Tokyo)

  14:20 Break

            SESSION (2.2), 14:40 - 15:30

  14:40 Local pi-Calculus at Work: Mobile Objects as Mobile Processes
        Massimo Merro, Josva Kleist, Uwe Nestmann

  15:05 An Interpretation of Typed Concurrent Objects in the Blue Calculus
        Silvano Dal Zilio

  15:30 Break

            SESSION (2.3), 15:50 - 17:30

  15:50 A Higher-Order Specification of the pi-Calculus
        Joelle Despeyroux

  16:15 Open Ended Systems, Dynamic Bisimulation, and Tile Logic
        Roberto Bruni, Ugo Montanari, Vladimiro Sassone

  16:40 Fibred Models of Processes: Discrete, Continuous, and Hybrid Systems
        Marcelo P. Fiore

  17:05 On the Complexity of Bisimulation Problems for Pushdown Automata
        Richard Mayr

  17:30 Break

AUGUST 18 FRIDAY
^^^^^^^^^^^^^^^^
   9:10 KEYNOTE PLENARY TALK
        Theory and Construction of Molecular Computers
        Masami Hagiya (U. Tokyo)

  10:00 Break

 [TRACK (1)]

            SESSION (1.4), 10:20 - 12:00

  10:20 Trade-offs between Density and Robustness in Random Interconnection
        Graphs
        P. Flajolet, K. Hatzis, S. Nikoletseas, P. Spirakis

  10:45 The ($\sigma$+1)-Edge-Connectivity Augmentation Problem without 
        Creating Multiple Edges of a Graph
        Satoshi Taoka, Toshimasa Watababe

  11:10 On the Hardness of Approximating Some NP-optimization Problems 
        Related to Minimum Linear Ordering Problem
        Sounaka Mishra, Kripasindhu Sikdar

  11:35 Maximum Clique and Minimum Clique Partition in Visibility Graphs
        Stephan Eidenbenz, Christoph Stamm

  12:00 Lunch Break

            SESSION (1.5), 13:30 - 14:20

  13:30 Real-Time Language Recognition by Alternating Cellular Automata
        Thomas Buchholz, Andreas Klein, Martin Kutrib

  13:55 Damage Spreading and $\mu$-Sensitivity on Cellular Automata
        Bruno Martin

  14:20 Break

  14:40 TRACK (1) INVITED TALK
        Discrepancy Theory and its Applications to Finance
        Shu Tezuka (IBM Tokyo Research Lab)

  15:30 Break

  -----------//

 [TRACK (2)]

            SESSION (2.4), 10:20 - 12:00

  10:20 A Type-theoretic Study on Partial Continuations
        Yukiyoshi Kameyama

  10:45 Partially Typed Terms between Church-Style and Curry-Style
        Ken-etsu Fujita, Aleksy Schubert

  11:10 Alternating Automata and Logics over Infinite Words
        Christof Loeding, Wolfgang Thomas

  11:35 Hypothesis Support for Information Integration in Four-Valued Logics
        Yann Loyer, Nicolas Spyratos, Daniel Stamate

  12:00 Lunch Break

  13:30 TRACK (2) INVITED TALK
        Masaccio: A Formal Model for Embedded Components
        Thomas A. Henzinger (UC Berkeley)

  14:20 Break

            SESSION (2.5), 14:40 - 15:30

  14:40 A Single Complete Refinement Rule for Demonic Specifications
        Karl Lermer, Paul Strooper

  15:05 Reasoning about Composition using Property Transformers and their 
        Conjugates
        Michel Charpentier, K. Mani Chandy
        
  15:30 Break

  -----------------------
 
  15:50 PANEL DISCUSSION on "New Challenges for TCS"
        Panelists: Giorgio Ausiello (U. Roma "La Sapienza")
                   Jozef Gruska <Co-Chair> (Masaryk U.)
                   Ugo Montanari (U. Pisa)
                   Takao Nishizeki <Co-Chair> (Tohoku U.)
                   Yoshihito Toyama (Tohoku U.)
                   Jiri Wiedermann (Inst. Informatics, Prague)

  17:10 Break

  18:30 BANQUET at Sendai Tokyu Hotel till 20:45
        BANQUET SPEECH
        Non-Random Thoughts about Randomization
        Michael O. Rabin (Harvard U.)

AUGUST 19 SATURDAY
^^^^^^^^^^^^^^^^^^
   9:10 KEYNOTE PLENARY TALK
        List Decoding: Algorithms and Applications
        Madhu Sudan (MIT)

  10:00 Break

 [TRACK (1)]

            SESSION (1.6), 10:20 - 12:00

  10:20 Fully Consistent Extensions of Partially Defined Boolean Functions
        with Missing Bits
        Endre Boros, Toshihide Ibaraki, Kazuhisa Makino

  10:45 Characterization of Optimal Key Set Protocols
        Takaaki Mizuki, Hiroki Shizuya, Takao Nishizeki

  11:10 On the Complexity of Integer Programming in the Blum-Shub-Smale
        Computational Model
        Valentin E. Brimkov, Stefan S. Dantchev

  11:35 On Logarithmic Simulated Annealing
        A. Albrecht, C. K. Wong

  12:00 Lunch Break

  13:30 TRACK (1) INVITED TALK
        Hierarchical State Machines
        Mihalis Yannakakis (Bell Labs, Lucent)

  14:20 Break

  -----------//

 [TRACK (2)]

  10:20 TRACK (2) INVITED TALK
        Some New Directions in the Syntax and Semantics of Formal Languages
        Gordon D. Plotkin (Edinburgh U.)

  11:10 Break

  11:20 DEMO SESSION (1) on Verification Tools

  12:00 Lunch Break

  13:30 DEMO SESSION (2) on Verification Tools

  14:20 Break

 ------------------------

  14:30 CLOSING SESSION till 14:40
        Giorgio Ausiello (TC1 Chair and IFIP TCS2000 Co-Chair) 
        Takayasu Ito (IFIP TCS2000 Co-Chair)

 ------------------------

 [OPEN LECTURES]

  15:00 On the Power of Interactive Computing
        Jan van Leeuwen (U. Utrecht)*, Jiri Wiedermann (Acad. Sciences, Czech)
           (*: speaker)

  16:00 The Varieties of Programming Language Semantics
        Peter D. Mosses (U. Aarhus)

  17:00 Break

 ------------------------

  18:30 JAPANESE DINNER PARTY till 20:00

==========================================================================

GENERAL INFORMATION
^^^^^^^^^^^^^^^^^^^

IFIP TCS2000 is the first International Conference on Theoretical Computer 
Science organized by IFIP TC1 on Foundations of Computer Science, and it 
consists of two tracks: TRACK (1) on Algorithms, Complexity and Models of 
Computation, and TRACK (2) on Logic, Semantics, Specification, and 
Verification. The conference proceedings will be published as a volume
of Lecture Notes in Computer Science, Springer-Verlag.

IFIP TCS2000 will be held on the campus of Tohoku University, Sendai, Japan.
The invited talks and contributed talks will be presented at the Aoba 
Memorial Building and Engineering Conference Hall, Faculty of Engineering 
located on the Aoba Hill about 3 km west of downtown Sendai. The conference
welcome reception and banquet will be held at Sendai Tokyu Hotel, located 
at downtown Sendai.

Please, register and make reservations by returning the completed form 
by email and fax, following the instructions below.
There will also be on-site registration at:
   * Sendai Tokyu Hotel, 15:00 - 20:00, August 16
   * Aoba Memorial Bldg., Tohoku Univ., 9:00 - 17:00 on August 17 - 19.

Transportation

Conference participants arriving at the new Tokyo International (Narita) 
Airport are advised to take the JR Narita Express train from Narita Airport
to Tokyo Station. 
Then, take the Yamabiko super express train of Tohoku Shinkansen (Tohoku 
Bullet Train) to Sendai from Tokyo Station. The Yamabiko runs every 20 - 30
min. and takes about 2 hours from Tokyo to Sendai. Making reservation at 
Narita Station for the Yamabiko is recommended, since it will be the summer
tourist season. 
Those arriving at the new Osaka International Airport (Kansai Airport) can
fly to Sendai Airport, and take Limousine Bus service to Sendai Station. 
The bus takes about 30 min. to go from the Airport to Sendai Station. You 
can also take a shuttle bus service from Kansai Airport to the Osaka-Itami 
Airport to fly from there to Sendai Airport. Alternatively, you can take a 
local train from the Kansai Airport to JR Shin Osaka Station, then take the
Tokaido Shinkansen from Osaka to Tokyo Station and change at Tokyo Station 
to Tohoku Shinkansen. 
Some details on transportation will be available on the TCS2000 Web page, at
        http://tcs2000.ito.ecei.tohoku.ac.jp/tcs2000/
Note: 
(1) In Japan, mid-August is the busiest tourist time during summer, 
    including domestic and international flights. 
(2) No flight service is available from Narita to Sendai Airport, since the
    train service is convenient. There is another train service from Narita
    Airport to downtown Tokyo (Ueno) by Skyliner of the Keisei-Narita Line.
    At Ueno you can take the Yamabiko super express of Tohoku Shinkansen to
    Sendai, but you have to walk about 10 min. from Keisei-Ueno Station to 
    JR Ueno Station to take Tohoku Shinkansen.
(3) If you are going to travel in Japan by JR lines before/after the IFIP 
    TCS2000 conference, it will be convenient and economical to get a JR 
    PASS before your departure. Contact your travel agent for more 
    information on JR PASS (Japan Rail Pass).

Hotels

Two hotels are arranged to offer special discount rates to IFIP TCS2000 
participants: Sendai Tokyu Hotel and Sendai Washington Hotel. They are 
1.2 km west of Sendai Station and about 800 Yen by taxi from the station. 
These hotels are located within 5 min. walk from each other. The conference
welcome reception and banquet will be held at Sendai Tokyu Hotel.

Sendai and Climate

Sendai is the largest city in the northern part of the Honshu Island of 
Japan, with a population of about a million. The City is known in Japan 
as "City of Trees". Sendai is a modern, safe city with a temperate climate 
blessed by four distinct seasons; even in mid August it is quite seldom 
that the highest temperature exceeds 30 C (86 F). 
Usually, the weather in mid August would be mostly sunny with temperatures
ranging from 20 C (68 F) to 30 C (86 F), and rain, if any, would rarely be
heavy.
Note: Average temperatures in August at Sendai, Tokyo and Osaka are about 
      23.5 C, 26.5 C and 27.5, respectively.

REGISTRATION AND RESERVATION INFORMATION
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                                                            
REGISTRATION FEES

Registration fees cover attendance in all sessions, a copy of the proceedings, 
refreshments, the welcome reception and banquet, but not the Japanese dinner 
party on August 19. The reduced author rate applies to all authors of the 
accepted papers, and the reduced committee member rate applies to all TC1 
members and to all members of the Program Committee and the Organizing 
Committee. The student rate applies to full time students. Registrants paying
reduced rates have full privileges at the conference. The companion rate 
covers the reception and banquet only.

                      Through July 1st, 2000          From July 2nd, 2000 
   Regular                  40,000 Yen                    50,000 Yen
   Author                   30,000 Yen                    40,000 Yen
   Committee Member         30,000 Yen                    40,000 Yen
   Student                  25,000 Yen                    30,000 Yen
   Companion                 5,000 Yen                     7,000 Yen

HOTELS

Two convenient Western Style hotels offer special IFIP TCS2000 discount rates.
Rates are per person, per night, and include service charge and tax (not 
including breakfast).

                                    Single Room           Twin Room
   Sendai Tokyu Hotel               10,500 Yen            8,400 Yen
   Sendai Washington Hotel II        8,400 Yen            7,350 Yen
   Sendai Washington Hotel I         7,350 Yen            ---------

Note: Twin room reservations are available for two persons. No roommate 
      matching service is available, so that twin room reservations remain 
      the registrant's responsibility.
 
JAPANESE DINNER PARTY

A Japanese dinner party for participants from abroad will be arranged at
SHOZANKAN in the evening of August 19. The invited speakers, some Steering
Committee members, PC members and conference organizers will attend. A 
limited number of reservations will be available for this dinner party. 
The rates are as follows.

   Conference registrant:   10,000 Yen
   Companion:                7,000 Yen

=============================================================================
Cut here to send your registration form after filling in the required items.
=============================================================================

IFIP TCS2000 REGISTRATION AND RESERVATION FORM
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Please register and make reservations by completing the form below and 
returning it by email to

        tcs02@REDACTED

Registrants are advised to email a copy of their completed form to

        TCS2000@REDACTED

They are also encouraged to send a signed, printed copy of their completed 
form by fax to

        022-262-5002 (domestic)
     +81-22-262-5002 (from abroad)

which is the fax number of the following agent to take care of the conference
registration and reservation.

    JTB (Japan Travel Bureau) Tohoku Communications Inc.
    Kotsukosha Bldg 3F, 3-6-Chuo
    Aoba-Ku, Sendai 980-0021, Japan

    (Fax)   022-262-5002 (domestic)
            +81-22-262-5002 (from abroad)
    (Phone) 022-262-5055 (domestic)
            +81-22-262-5055 (from abroad)
    (Email) tcs02@REDACTED

Registration and reservations will be completed by your payment, whose method
is described below.

IMPORTANT NOTE: As described below, from the standpoint of the safety, 
    registrants are advised to pay fees by Bank Transfer. When the payment is
    made by a credit card, they are advised to send the required information 
    including Credit Card numbers by FAX; that is, do NOT send Credit Card 
    numbers by email.
  
REGISTRATION FOR IFIP TCS2000
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  Last (Family) Name:

  First (Given) Name:

  Middle:

  Affiliation:

  Postal Address:

  City/State/Zip:

  Country:

  Phone:

  Fax:

  Email:

  Registration Status 
    <Regular, Author, Committee Member, Student>:

  Number of Companions:

  Companions' names (if applicable):

  (A) Total Registration Fee(s) in Yen:

HOTEL RESERVATION

  Hotel First Choice:

  Hotel Second Choice:

  Number of Single Room(s):

  Number of Twin Room(s):

  Roommate's Name(s) for Twin Room(s):

  Check-in Date:

  Check-out Date:

  Number of Nights:

  Special Room or other Request:

JAPANESE DINNER PARTY

  A limited number of reservations are available for the Japanese dinner 
  party at SHOZANKAN on August 19 to be arranged for participants from 
  abroad.

  (B) 10,000 Yen x [   ] conference registrant(s):

  (C)  7,000 Yen x [   ] companion(s):

TOTAL FEE IN YEN

  (A) + (B) + (C):

Signature (not needed for email):

METHOD OF PAYMENT FOR IFIP TCS2000

   From the standpoint of the safety and security, participants are encouraged
   to pay via Bank Transfer. When they pay via credit card, they are advised 
   to send the required information (in particular, Credit Card numbers) by 
   FAX; that is, do NOT send your Credit Card numbers by email. 
   In credit card payment Visa card, MasterCard, and Diners card will be 
   accepted. Personal checks cannot be accepted.
   All payments must be made in Japanese Yen.

Indicate method of payment below:

  [    ] Bank Transfer to

              Bank: Tokyo Mitsubishi Bank, Sendai Branch
              Account Name: IFIP TCS2000 Chair Takayasu Ito
              Account No. 1108671  

         From <bank name>:

         Date of transfer:

         Payer's name:

         Note: In Japan the bank number of Tokyo Mitsubishi Bank is 0005, and
               the number of its Sendai Branch is 320.

  [    ] Payment by Credit Card

         Credit Card Type <Visa, MasterCard, or Diners>:

         Card Number:

         Expiration Date:

         Signature (not needed for email):
                                                                              
  <Note>: When your payment is via Credit Card, send the above information
          by FAX to +81-22-262-5002, the fax no. of JTB Communications Inc. 
          Even when you send the above form by fax, send it by EMAIL 
          without  filling in Credit Card number for safety.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Registration and reservations will be confirmed upon receipt of payment.
Refunds will be made upon written request received through July 31st, 2000
by JTB Tohoku Communications Inc.


From mbj@REDACTED  Wed May 17 09:15:29 2000
From: mbj@REDACTED (Martin Bjorklund)
Date: Wed, 17 May 2000 09:15:29 +0200
Subject: Monitoring of nodes..
In-Reply-To: Your message of "Wed, 17 May 2000 15:41:02 +1000 (EST)"
	<14626.12526.990595.445925@eddieware.eddieware.org>
References: <14626.12526.990595.445925@eddieware.eddieware.org>
Message-ID: <20000517091529J.mbj@bluetail.com>

Pekka.Hedqvist@REDACTED wrote:
> What have I missed if I have three (3) nodes <a@REDACTED,b@REDACTED,c@REDACTED>, they
> are all "connected" with each other. Node 'a@REDACTED' does BIF calls to
> monitor_node(b@REDACTED, true) and monitor_node(c@REDACTED,true). Now node
> 'a@REDACTED' monitors both node 'b@REDACTED' and node 'c@REDACTED'. If I terminate
> node 'b@REDACTED', node 'a@REDACTED' should receive an {nodedown, b@REDACTED} message
> which it does. 
> BUT, if I then terminate the 'c@REDACTED' node I do NOT receive any
> {nodedown, c@REDACTED} message. Now, is this the correct behaviour? It's
> not what I expected anyway..?

I've tried this as well, and it seems to work just fine:

(a@REDACTED)1> nodes().
[c@REDACTED,b@REDACTED]
(a@REDACTED)2> erlang:monitor_node(b@REDACTED, true).
true
(a@REDACTED)3> erlang:monitor_node(c@REDACTED, true).
true

  terminating b@REDACTED

(a@REDACTED)4> flush().
Shell got {nodedown,b@REDACTED}
ok

  terminating c@REDACTED


(a@REDACTED)5> flush().
Shell got {nodedown,c@REDACTED}
ok

Could you post your program?



/martin


From Pekka.Hedqvist@REDACTED  Wed May 17 09:19:30 2000
From: Pekka.Hedqvist@REDACTED (Pekka.Hedqvist@REDACTED)
Date: Wed, 17 May 2000 17:19:30 +1000 (EST)
Subject: Monitoring of nodes..
In-Reply-To: <20000517090315Q.mbj@bluetail.com>
References: <200005170651.GAA14189@gecko.serc.rmit.edu.au>
	<20000517090315Q.mbj@bluetail.com>
Message-ID: <14626.18434.255867.447748@eddieware.eddieware.org>

 > receive just hangs, waiting for another nodedown from x@REDACTED
 > 
 > Which OS are you running?  Do you which OS pekka is running?

..duh.. You'r right, everything is as one expects it to work if one
actually make sure not to test it in the shell and forgets to f() or
new varnames.. :/


From davidg@REDACTED  Wed May 17 09:27:13 2000
From: davidg@REDACTED (David Gould)
Date: Wed, 17 May 2000 00:27:13 -0700
Subject: optimization tricks ?
In-Reply-To: <o1ya5all8k.fsf@erix.ericsson.se>; from Bjorn Gustavsson on Tue, May 16, 2000 at 02:42:35PM +0200
References: <200005152048.PAA33441@snookles.snookles.com> <o1ya5all8k.fsf@erix.ericsson.se>
Message-ID: <20000517002713.A1217@dnai.com>

On Tue, May 16, 2000 at 02:42:35PM +0200, Bjorn Gustavsson wrote:
> In a C++ project some five years ago our program was too slow. Elobarate
> re-designs were proposed. When I profiled the program with Quantify,
> the bottle-neck turned out to be a short loop where an object was allocated
> and then immediately destroyed each time the loop was executed. Moving
> the object allocation out of the loop eliminated the entire speed problem.

Quantify is a pretty good at what it does, but beware, on modern machines
it can be seriously misleading. Quantify counts instructions executed. It
does not measure real time, nor does it account for memory latency or cache
effects. Since cache behavior can make order of magnitude changes in runtime,
it is important to optimize this, and Quantify is of no help here.

-dg

-- 
David Gould                davidg@REDACTED              510.536.1443 
                           dgould@REDACTED              510.628.3380
- If simplicity worked, the world would be overrun with insects. -



From etxuwig@REDACTED  Wed May 17 10:15:14 2000
From: etxuwig@REDACTED (Ulf Wiger)
Date: Wed, 17 May 2000 10:15:14 +0200 (MET DST)
Subject: How does the garbage collector really works?
In-Reply-To: <LPBBKHKEDFELLHNDPNDBAECCCAAA.jonas.jerfsten@st.se>
Message-ID: <Pine.GSO.4.10.10005170958230.17619-100000@avc303>

On Tue, 16 May 2000, Jonas Jerfsten wrote:

>Hi!
>I have a question about how the garbage collector (gc) in Erlang
>works. I am working on a module that performs a file:consult/1 on a
>large file and then stores the data in an ets-table. All that is
>done in the init of the process. I have performed memory analysis on
>the process using erlang:trace/3 and process_info/2. It seems as if
>the file:consult/1 function call results in a large memory
>allocation and that the process will hold on to that memory even
>after the calling function has gone out of scope. If I do not make
>any further function calls to the process, it seems as if the gc
>will not go in and free the memory. That means that when the process
>is initialised, it will allocate a lot of memory and keep it until
>the process is scheduled again. Correct? Or am I making incorrect
>assumptions from my memory analysis? If the process is not scheduled
>again, when will the gc free the memory?
>
>/Jonas Jerfsten

Hi,

You are correct, and the answer is: never -- unless...

The garbage collector will allocate an increasingly larger heap, if
the process keeps growing (i.e. the GC sweep is unable to free enough
memory to allocate the new data*. It can happen that the function
finishes before filling up the new heap. You will then be stuck with
the large heap (with mostly garbage), possibly forever, if the process
doesn't get to perform more work. As soon as the process starts
executing a new job, it will most likely create more garbage, and a
garbage collection sweep will be triggered.

You can force a garbage collection by calling
erlang:garbage_collect(). This can be useful in cases where you *know*
that the process will not execute again for a long time (perhaps
never).

In older versions of OTP (I think before R5B), you had to specifically
call a function after calling garbage_collect(), for the GC to
actually take place, but I'm pretty sure this has been fixed.

/Uffe

* Using a fibonacci sequence if I'm not mistaken.
-- 
Ulf Wiger, Chief Designer AXD 301         <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuv?gen 9, ?lvsj?                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44



From bjorn@REDACTED  Wed May 17 14:02:11 2000
From: bjorn@REDACTED (Bjorn Gustavsson)
Date: 17 May 2000 14:02:11 +0200
Subject: How does the garbage collector really works?
In-Reply-To: "Jonas Jerfsten"'s message of "Tue, 16 May 2000 21:48:55 +0200"
References: <LPBBKHKEDFELLHNDPNDBAECCCAAA.jonas.jerfsten@st.se>
Message-ID: <o1snvhqta4.fsf@erix.ericsson.se>

An alternate way to get rid of garbage is to spawn a new separate
process for temporary jobs. Terminating a process frees all its memory
at once, faster than a garbage collection would do.

/Bjorn

"Jonas Jerfsten" <jonas.jerfsten@REDACTED> writes:

> Hi!
> I have a question about how the garbage collector (gc) in Erlang works. I am
> working on a module that performs a file:consult/1 on a large file and then
> stores the data in an ets-table. All that is done in the init of the
> process. I have performed memory analysis on the process using
> erlang:trace/3 and process_info/2. It seems as if the file:consult/1
> function call results in a large memory allocation and that the process will
> hold on to that memory even after the calling function has gone out of
> scope. If I do not make any further function calls to the process, it seems
> as if the gc will not go in and free the memory. That means that when the
> process is initialised, it will allocate a lot of memory and keep it until
> the process is scheduled again. Correct? Or am I making incorrect
> assumptions from my memory analysis? If the process is not scheduled again,
> when will the gc free the memory?
> 
> /Jonas Jerfsten
> 
> ------------------------------------------------
> Sj?land & Thyselius AB
> Address: Sehlstedtsgatan 6, S-115 28 STOCKHOLM
> Phone:+46(0)8-587 623 04 Mobil: +46(0)708-12 33 36 Fax: +46(0)8-667 82 30
> Internet: jonas.jerfsten@REDACTED, http://www.st.se/
> 

-- 
Bj?rn Gustavsson            Ericsson Utvecklings AB
bjorn@REDACTED      ?T2/UAB/F/P
			    BOX 1505
+46 8 727 56 87 	    125 25 ?lvsj?


From bjorn@REDACTED  Wed May 17 11:10:05 2000
From: bjorn@REDACTED (Bjorn Gustavsson)
Date: 17 May 2000 11:10:05 +0200
Subject: How does the garbage collector really works?
In-Reply-To: Ulf Wiger's message of "Wed, 17 May 2000 10:15:14 +0200 (MET DST)"
References: <Pine.GSO.4.10.10005170958230.17619-100000@avc303>
Message-ID: <o166sdv8ya.fsf@erix.ericsson.se>

Ulf Wiger <etxuwig@REDACTED> writes:

> In older versions of OTP (I think before R5B), you had to specifically
> call a function after calling garbage_collect(), for the GC to
> actually take place, but I'm pretty sure this has been fixed.

Actually, it is not fixed. You still have to call a function to force a
context switch.

I might fix it in R7, especially if you think it is important.

You can also call erlang:garbage_collect(Pid) from another process, which
will force an immediate garbage collection. (erlang:garbage_collect(self())
is equvivalent to erlang:garbage_collect().)

> 
> /Uffe
> 
> * Using a fibonacci sequence if I'm not mistaken.

Yes.

/Bj?rn

-- 
Bj?rn Gustavsson            Ericsson Utvecklings AB
bjorn@REDACTED      ?T2/UAB/F/P
			    BOX 1505
+46 8 727 56 87 	    125 25 ?lvsj?


From etxuwig@REDACTED  Wed May 17 10:38:55 2000
From: etxuwig@REDACTED (Ulf Wiger)
Date: Wed, 17 May 2000 10:38:55 +0200 (MET DST)
Subject: Monitoring of nodes..
In-Reply-To: <20000517090315Q.mbj@bluetail.com>
Message-ID: <Pine.GSO.4.10.10005171038010.17619-100000@avc303>

On Wed, 17 May 2000, Martin Bjorklund wrote:

>Geoff Wong <geoff@REDACTED> wrote:
>
>> (fud@REDACTED)3> net_kernel:monitor_nodes(true).
>> ok
>> (fud@REDACTED)4> receive A -> A end.
>> {nodedown,x@REDACTED}
>> (fud@REDACTED)5> receive A -> A end.
>>
>> I never get a nodedown when I take down y@REDACTED (after taking
>> down x@REDACTED).
>
>In this case it's because A is bound to {nodedown, x@REDACTED}, so the
>receive just hangs, waiting for another nodedown from x@REDACTED



It's probably better to use flush() in the shell. That way, you avoid
binding a variable.


/Uffe
-- 
Ulf Wiger, Chief Designer AXD 301         <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuv?gen 9, ?lvsj?                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44



From vances@REDACTED  Thu May 18 06:45:46 2000
From: vances@REDACTED (Vance Shipley)
Date: Thu, 18 May 2000 00:45:46 -0400
Subject: gen_udp:send/4
Message-ID: <NBBBIOHCCJPPDNIBBIKCIEAJCDAA.vances@motivity.ca>


How do we format the packet for a UDP send?

I'd like to send:

	{xx, yyy, {123, foo, bar}}

Of couse we need to construct the term on the fly.

Here's the sort of thing we see:

Erlang (BEAM) emulator version 4.9.1 [source]

Eshell V4.9.1  (abort with ^G)
1> {ok, S} = gen_udp:open(6789).
{ok,{socket,<0.30.0>,#Port<0.7>,inet_udp}}
2> gen_udp:send(S, "localhost", 7000, "1234").
ok
3> gen_udp:send(S, "localhost", 7000, [1, 2, 3, 4]).
ok
4> gen_udp:send(S, "localhost", 7000, tuple_to_list({1, 2, 3, 4})).
ok
5> gen_udp:send(S, "localhost", 7000, tuple_to_list({1, 2, 3, four})).

=ERROR REPORT==== 18-May-2000::00:42:41 ===
Bad value on output port 'udp_inet'
ok
6> 


	-Vance


From Pekka.Hedqvist@REDACTED  Thu May 18 07:57:23 2000
From: Pekka.Hedqvist@REDACTED (Pekka.Hedqvist@REDACTED)
Date: Thu, 18 May 2000 15:57:23 +1000 (EST)
Subject: gen_udp:send/4
In-Reply-To: <NBBBIOHCCJPPDNIBBIKCIEAJCDAA.vances@motivity.ca>
References: <NBBBIOHCCJPPDNIBBIKCIEAJCDAA.vances@motivity.ca>
Message-ID: <14627.34371.824809.23005@eddieware.eddieware.org>

Open the port as a binary. 
1> {ok, S} = gen_udp:open(6789,[binary]).
5> gen_udp:send(S, "localhost", 7000, term_to_binary(({1, 2, 3, four})))

and on the other end you get the udp packet and do a term_to_binary
and then voila you get back {1,2,3,four}. Of course if Erlang is not
on the other end you need to use some other external data representation
etc..

/pekka


From etxuwig@REDACTED  Thu May 18 10:58:12 2000
From: etxuwig@REDACTED (Ulf Wiger)
Date: Thu, 18 May 2000 10:58:12 +0200 (MET DST)
Subject: gen_udp:send/4
In-Reply-To: <14627.34371.824809.23005@eddieware.eddieware.org>
Message-ID: <Pine.GSO.4.10.10005181057000.20383-100000@avc303>

On Thu, 18 May 2000 Pekka.Hedqvist@REDACTED wrote:

>Open the port as a binary. 
>1> {ok, S} = gen_udp:open(6789,[binary]).
>5> gen_udp:send(S, "localhost", 7000, term_to_binary(({1, 2, 3, four})))
>
>and on the other end you get the udp packet and do a term_to_binary


... oops, typo. It should of course be binary_to_term ...


>and then voila you get back {1,2,3,four}. Of course if Erlang is not
>on the other end you need to use some other external data representation
>etc..
>
>/pekka

-- 
Ulf Wiger, Chief Designer AXD 301         <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuv?gen 9, ?lvsj?                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44



From vladdu@REDACTED  Thu May 18 13:37:17 2000
From: vladdu@REDACTED (Vlad Dumitrescu)
Date: Thu, 18 May 2000 13:37:17 CEST
Subject: erlang window manager
Message-ID: <20000518113717.92247.qmail@hotmail.com>

Hi all!

One possible application of Erlang in the book (or more exactly, in The Book 
:-) is a graphical window manager, where all controls and windows are Erlang 
processes and the messages sent are real messages.

It would be an interesting project. Huge, but interesting. Has anyone give 
it any thought? Would it be a practical thing to do? Personally, I am not so 
fond of gs or etk... and a nice GUI would make a lot as marketing material 
:-)

[The question was actualized when I checked out Clean and was impressed by 
the graphical I/O library written all in Clean. And there's a game library 
too, for developing platform games! http://www.cs.kun.nl/~clean/]

regards,
Vlad
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From tobbe@REDACTED  Thu May 18 14:04:15 2000
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: 18 May 2000 14:04:15 +0200
Subject: erlang window manager
In-Reply-To: "Vlad Dumitrescu"'s message of "Thu, 18 May 2000 13:37:17 CEST"
References: <20000518113717.92247.qmail@hotmail.com>
Message-ID: <lo3dngxdxc.fsf@kiwi.bluetail.com>


> One possible application of Erlang in the book (or more exactly, 
> in The Book :-) is a graphical window manager....

Well, if you really want to begin from the lowest level you
have an embryo here:

  http://www.erlang.org/user.html#ex11-0.11

It is a small part of the X11 protocol, implemented in Erlang.

Cheers /Tobbe
--
Torbj?rn T?rnkvist , tel: +46 8 692 22 15 , fax: +46 8 654 70 71
Bluetail AB , Hantverkargatan 78 , SE-112 38 Stockholm , Sweden            
Email: tobbe@REDACTED , Web: http://www.bluetail.com/~tobbe


From vladdu@REDACTED  Thu May 18 15:00:55 2000
From: vladdu@REDACTED (Vlad Dumitrescu)
Date: Thu, 18 May 2000 15:00:55 CEST
Subject: erlang window manager
Message-ID: <20000518130055.92614.qmail@hotmail.com>

Hi

>Well, if you really want to begin from the lowest level you have an embryo 
>here:
Thanks, I'll look at it.

I have to confess that in my previous posting something was left out 
unintentionally: I meant "platform independent window manager"...

I know it's a huge amount of work, and I barely have time to breathe :-)
So I won't start doing it - but maybe someone catches the idea and jumps on 
it!

regards
/Vlad
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com



From Sean.Hinde@REDACTED  Thu May 18 16:56:38 2000
From: Sean.Hinde@REDACTED (Sean Hinde)
Date: Thu, 18 May 2000 15:56:38 +0100
Subject: catch in assignment
Message-ID: <402DD461F109D411977E0008C791C312564E21@imp02mbx.one2one.co.uk>

All,

Can anyone shed any light on the following behaviour:

node@REDACTED> A = catch 1.
** 3: syntax error before: 'catch' **

but

node@REDACTED> A = (catch 1).
1

It doesn't strike me as ambiguous to assign the result of a catch to a
variable directly...

Sean


From rv@REDACTED  Thu May 18 17:43:08 2000
From: rv@REDACTED (Robert Virding)
Date: Thu, 18 May 2000 17:43:08 +0200
Subject: catch in assignment 
In-Reply-To: Your message of "Thu, 18 May 2000 15:56:38 BST."
             <402DD461F109D411977E0008C791C312564E21@imp02mbx.one2one.co.uk> 
Message-ID: <200005181543.RAA00836@trana.bluetail.com>

Sean Hinde <Sean.Hinde@REDACTED> writes:
>All,
>
>Can anyone shed any light on the following behaviour:
>
>node@REDACTED> A = catch 1.
>** 3: syntax error before: 'catch' **
>
>but
>
>node@REDACTED> A = (catch 1).
>1
>
>It doesn't strike me as ambiguous to assign the result of a catch to a
>variable directly...

No, it isn't ambiguous.  The reason is that 'catch' is a prefix operator
which happens to have the same as '=' and '=' demands higher priority 
on the right.  You can write:

	catch A = 1.

Yes, this could be solved by a hack to the parser, but I never thought 
it was worth it.  The REAL way to solve it would be to change 'catch' 
so as not to be a prefix operator but to terminate with an 'end', but 
it was to late for that (which would save begin .. end):

	A = catch foo(X), bar(Y) end.

	Robert

-- 
Robert Virding                          Tel: +46 (0)8 692 22 12
Bluetail AB                             Email: rv@REDACTED
Hantverkargatan 78                      WWW: http://www.bluetail.com/~rv
SE-112 38 Stockholm, SWEDEN
"Folk s?ger att jag inte bryr mig om n?gonting, men det skiter jag i".




From vances@REDACTED  Thu May 18 18:07:47 2000
From: vances@REDACTED (Vance Shipley)
Date: Thu, 18 May 2000 12:07:47 -0400
Subject: gen_udp looses datagrams
In-Reply-To: <200005181543.RAA00836@trana.bluetail.com>
Message-ID: <NBBBIOHCCJPPDNIBBIKCGEAKCDAA.vances@motivity.ca>


We're finding that when we have an active UDP socket
we can, and do, loose incoming datagrams.  At times
we will receive only the latter of two packets sent
immediately after one another.  Why would this be?

	-Vance

The following demonstrates:

-module(test_udp).
-export([start/1]).

start(Port)->
        {ok, Socket} = gen_udp:open(Port),
        gen_udp:send(Socket, "foo", 4000, "Please send me two packets!"),
        loop(Socket).

loop(Socket) ->
        receive
                {udp, S, A, P, M} ->
                        io:fwrite("~s ~n", [M]),
                        loop(S)
        end.



Erlang (BEAM) emulator version 4.9.1 [source]

Eshell V4.9.1  (abort with ^G)
1> test_udp:start(5000).                          
Here's the first one you asked for.
Here's the second one you asked for.


BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
       (v)ersion (k)ill (D)b-tables (d)istribution

$ erl
Erlang (BEAM) emulator version 4.9.1 [source]

Eshell V4.9.1  (abort with ^G)
1> test_udp:start(6789).                          
Here's the second one you asked for.



From luke@REDACTED  Fri May 19 02:18:40 2000
From: luke@REDACTED (Luke Gorrie)
Date: 19 May 2000 02:18:40 +0200
Subject: gen_udp looses datagrams
In-Reply-To: "Vance Shipley"'s message of "Thu, 18 May 2000 12:07:47 -0400"
References: <NBBBIOHCCJPPDNIBBIKCGEAKCDAA.vances@motivity.ca>
Message-ID: <87r9azmly7.fsf@cockatoo.bluetail.com>

"Vance Shipley" <vances@REDACTED> writes:

> We're finding that when we have an active UDP socket
> we can, and do, loose incoming datagrams.  At times
> we will receive only the latter of two packets sent
> immediately after one another.  Why would this be?

Datagrams are unreliable by nature. They're really low-level, just IP
packets annotated with port numbers afaik - they're not guaranteed to
arrive, and may arrive out of order. For reliability you need to come
up with some sort of scheme to compensate for lost or reordered
packets, or use TCP.

Cheers,
Luke



From vances@REDACTED  Thu May 18 18:41:43 2000
From: vances@REDACTED (Vance Shipley)
Date: Thu, 18 May 2000 12:41:43 -0400
Subject: gen_udp looses datagrams
In-Reply-To: <87r9azmly7.fsf@cockatoo.bluetail.com>
Message-ID: <NBBBIOHCCJPPDNIBBIKCKEAKCDAA.vances@motivity.ca>

Luke writes:
}  "Vance Shipley" <vances@REDACTED> writes:
}  
}  > We're finding that when we have an active UDP socket
}  > we can, and do, loose incoming datagrams.  At times
}  > we will receive only the latter of two packets sent
}  > immediately after one another.  Why would this be?
}  
}  Datagrams are unreliable by nature. They're really low-level, just IP
}  packets annotated with port numbers afaik - they're not guaranteed to
}  arrive, and may arrive out of order. For reliability you need to come
}  up with some sort of scheme to compensate for lost or reordered
}  packets, or use TCP.


While I completely understand this I very much doubt that it is the
issue here.  The communication is across a LAN and the other observation
is that it is only the first packet which is lost on every occasion 
we have seen.

	-Vance


From fven07@REDACTED  Thu May 18 19:39:13 2000
From: fven07@REDACTED (Felicia Venn)
Date: Thu, 18 May 2000 18:39:13 +0100 (BST)
Subject: Mathematical calculation
Message-ID: <Pine.GSO.4.05.10005181832120.29449-100000@saturn>

please could you send me the syntax for calculating an 'average delay for
all calls' using the (Erlang table)

I have attached the work which this question is related to.  Please send
me an answer as soon as possible because i need this information urgently

Thank you

Alternative e-mail address:

FELLYBABY@REDACTED













This memo addresses the issue of staffing support levels currently in
practice at the SNB university. Having reviewed the last interview notes
regarding this issue, there is reason to believe that some errors were
made in the assessment.  In particular, regarding the maximum waiting time
on calls to the helpdesk.  The following calculations indicate the correct
level of staff required by the helpdesk to provide more efficient levels
of service support.

 
Call volume 				= 42 calls/ hours 
Average call length 			= 10 minutes
Maximum waiting time 		= 1 minute

The PFM staff support workload works out as follows:

A 	Workload 		=  (10 * 42)/60
				=     420    /60
	  	
				=  7 Erlangs

B	The ADDC (Average Delay of Delayed calls) Factor works out
	follows:

	ADDC factor		= 1/ 10
				= 0.1

C	Using the Erlang Table: The amount of staff required = 17, Delayed	
	Portion = 0.0010

D	So Percentage of delayed calls  = ? %

E	ADDC (Average delay of Delayed calls) :

	- The ADDC factor from table          = 0.1
	- The average call length in seconds  = 10 minutes * 60 (seconds)	
					      = 600

	So ADDC 			    = 600 * 0.1
		  			    = 60 seconds
					    = 1 minute




F	'Average delay for all calls' 	    = ?



The mathematical evidence above shows that staff levels are of priority
and that the existing  staff levels are not adequate enough to handle the
current level of support calls to the helpdesk.  Therefore an increased
number of staff are required to work around the help desk which could help
eradicate the majority of all call delays to the helpdesk.






From per@REDACTED  Thu May 18 23:49:24 2000
From: per@REDACTED (Per Hedeland)
Date: Thu, 18 May 2000 23:49:24 +0200 (MET DST)
Subject: Mathematical calculation
In-Reply-To: <Pine.GSO.4.05.10005181832120.29449-100000@saturn>
References: <Pine.GSO.4.05.10005181832120.29449-100000@saturn>
Message-ID: <200005182149.e4ILnOM03557@super.du.uab.ericsson.se>

Felicia Venn <fven07@REDACTED> wrote:
>please could you send me the syntax for calculating an 'average delay for
>all calls' using the (Erlang table)

Sorry, you've come to the wrong place - we discuss Erlang the
programming language here, not Erlang the formula. You may have better
luck at www.erlang.com.

--Per Hedeland
per@REDACTED


From ramana.shankar@REDACTED  Fri May 19 08:37:13 2000
From: ramana.shankar@REDACTED (Ramana Shankar Yenishetti)
Date: Fri, 19 May 2000 14:37:13 +0800
Subject: Regarding node connection with C interface.
Message-ID: <00c201bfc15c$ac6c6480$a1250cc4@wipsys.stph.net>

Hi ,
        Iam trying to interface C with ERLANG , but couldnt establish the node connection , and even couldnt establish a connection on the remote node . where as the connection is possible on the same node.
        Can u suggest me any prerequisites which should be followed before trying to establish a connection.
         
Thanks & Regards
ramana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20000519/a55a8e18/attachment.htm>

From etxlg@REDACTED  Fri May 19 11:58:34 2000
From: etxlg@REDACTED (Lars G J Carlsson)
Date: Fri, 19 May 2000 11:58:34 +0200 (MET DST)
Subject: gen_udp looses datagrams
Message-ID: <200005190958.LAA07022@etxb.ericsson.se>

Hi!

This is the first time I stick my neck out on this list, i.e. PLEASE
cut me some slack if this turns out to be a really silly comment.

In view of the fact that it is always the first packet (out of two)
that is lost, could it be that the host that you are trying to reach
happens to NOT be in the ARP table initially?
If you know that the hosts are in continuous communication already, please
stop reading now, the rest maybe correct (or NOT!) but it is certainly 
irrelevant for you.

If the ARP table does not have an entry for where the datagram should go it
will issue an ARP broadcast to resolve it, however, I think it is not
regulated in standards what to do with the packet that triggered the ARPOP_REQ.
It could be buffered awaiting succesfull resolution, in which case the question
becomes; how many datagrams will be buffered before the initial one is discarded.
>From some reading (RFC826 ?) it would seem that it is legal to just throw away a 
datagram if no link destination is immidiately available.
It doesn't help telling me what platform you are on since I don't really know how
any of them actually does this, sorry.

BRGDS/LARS


> From: "Vance Shipley" <vances@REDACTED>
> To: "Luke Gorrie" <luke@REDACTED>
> Cc: <erlang-questions@REDACTED>
> Subject: RE: gen_udp looses datagrams
> Date: Thu, 18 May 2000 12:41:43 -0400
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
> Importance: Normal
> 
> Luke writes:
> }  "Vance Shipley" <vances@REDACTED> writes:
> }  
> }  > We're finding that when we have an active UDP socket
> }  > we can, and do, loose incoming datagrams.  At times
> }  > we will receive only the latter of two packets sent
> }  > immediately after one another.  Why would this be?
> }  
> }  Datagrams are unreliable by nature. They're really low-level, just IP
> }  packets annotated with port numbers afaik - they're not guaranteed to
> }  arrive, and may arrive out of order. For reliability you need to come
> }  up with some sort of scheme to compensate for lost or reordered
> }  packets, or use TCP.
> 
> 
> While I completely understand this I very much doubt that it is the
> issue here.  The communication is across a LAN and the other observation
> is that it is only the first packet which is lost on every occasion 
> we have seen.
> 
> 	-Vance

=================================================================
Lars Carlsson

Ericsson Telecom AB            eMail : lars.carlsson@REDACTED
ATM Switch Development         Phone : +46 8 719 2423
S-126 25 Stockholm, Sweden     ECN   : 850 92423
Office address:                Fax   : +46 8 719 4344
Varuv?gen 9B, S-125 30 ?lvsj?  Mobile: +46 70 519 2526
==================================================================



From not.for.email@REDACTED  Fri May 19 12:38:13 2000
From: not.for.email@REDACTED (Gordon Beaton)
Date: 19 May 2000 10:38:13 GMT
Subject: Regarding node connection with C interface.
References: <00c201bfc15c$ac6c6480$a1250cc4@wipsys.stph.net>
Message-ID: <8g35il$ni9$1@news.du.uab.ericsson.se>

On 19 May 2000 06:37:13 GMT, Ramana Shankar Yenishetti wrote:
>         Iam trying to interface C with ERLANG , but couldnt establish
> the node connection , and even couldnt establish a connection on the
> remote node . where as the connection is possible on the same node.
>         Can u suggest me any prerequisites which should be followed
> before trying to establish a connection.


Are you using the same cookie from both nodes? I think this is the
most common error.

The easiest way to debug communication problems from erl-interface is
to turn on message tracing in the C-node by setting an environment
variable before starting your program, e.g:

  tcsh> setenv ERL_DEBUG_DIST 4 
  tcsh> ./myprog

or

  bash$ export ERL_DEBUG_DIST=4 
  bash$ ./myprog

This will show you the connection setup as well as all messages passed
between the nodes.

Perhaps if you show us how you are trying to make the connection, and
describe what errors you are getting (if any) or other symptoms then
you could get a more concrete answer.

/gordon

-- 
g o r d o n . b e a t o n @ e r i c s s o n . c o m



From Matthias.Lang@REDACTED  Fri May 19 13:39:56 2000
From: Matthias.Lang@REDACTED (Matthias.Lang@REDACTED)
Date: Fri, 19 May 2000 13:39:56 +0200 (MET DST)
Subject: gen_udp looses datagrams
In-Reply-To: <NBBBIOHCCJPPDNIBBIKCKEAKCDAA.vances@motivity.ca>
References: <87r9azmly7.fsf@cockatoo.bluetail.com>
	<NBBBIOHCCJPPDNIBBIKCKEAKCDAA.vances@motivity.ca>
Message-ID: <14629.10252.510611.838161@gargle.gargle.HOWL>


 > While I completely understand this I very much doubt that it is the
 > issue here.  The communication is across a LAN and the other observation
 > is that it is only the first packet which is lost on every occasion 
 > we have seen.

Does tcpdump (on the receiving machine) show you that the packet
definitely got there? 

I've been using quite a bit of UDP (for VOIP), and I haven't noticed
any missing packets at all. That doesn't, of course, mean that there
aren't missing packets. What's your platform (I run my stuff on
solaris and linux using erlang R6B, the commercial version)?

Matthias


From sanjiva@REDACTED  Sat May 20 04:45:05 2000
From: sanjiva@REDACTED (Sanjiva Prasad)
Date: Sat, 20 May 2000 08:15:05 +0530
Subject: FSTTCS 2000:  revised Call for Papers 
Message-ID: <200005200245.IAA07183@cse.iitd.ernet.in>


--text follows this line--

***********************************************************************
*                                                                     *
*                            FST TCS 2000                             *
*                                                                     *
* Foundations of Software Technology and Theoretical Computer Science *
*                        December 13--15, 2000                        *
*                          New Delhi, India                           *
*                                                                     *
***********************************************************************
*                          Call for Papers                            *
***********************************************************************

New:  Electronic Submission Guidelines
      Revised list of Invited Speakers

**********************************************************************

IARCS, the Indian Association for Research in Computing Science,
announces the 20th Annual FST TCS Conference in New Delhi.
Tentatively planned satellite events include include two workshops: on
Computational Geometry and on Advances in Programming Languages.

Authors are invited to submit papers presenting original and
unpublished research on **any** theoretical aspects of Computer
Science. Papers in applied areas with a strong foundational emphasis
are also welcome.  The proceedings of the last six years' conferences
(Springer-Verlag Lecture Notes in Computer Science volumes 880, 1026,
1180, 1346, 1530, 1738) give an idea of the kind of papers typically
presented at FST TCS.  Typical areas include (but are not restricted to):

         Automata, Languages and Computability 
         Randomized and Approximation Algorithms 
         Computational Geometry
         Computational Biology
         Combinatorial Optimization
         Graph and Network Algorithms 
         Complexity Theory 
         Parallel and Distributed Computing 
         New Models of Computation
         Concurrent, Real-time and Hybrid Systems 
         Logics of Programs and Modal Logics
         Database Theory  and Information Retrieval
         Automated Reasoning, Rewrite Systems, and Applications 
         Logic, Proof Theory, Model Theory and Applications
         Semantics of Programming Languages
         Static Analysis and  Type Systems
         Theory of Functional and Constraint-based Programming 
         Software Specification and Verification 
         Cryptography and Security Protocols


For an accepted paper to be included in the proceedings, one of 
the authors must commit to presenting the paper at the conference.

Important Dates
---------------
  Deadline for Submission                             31 May, 2000
  Notification to Authors                             15 August, 2000
  Final Version of Accepted Papers due                15 September, 2000
  Deadline for Early Registration	       		15 November, 2000 


Submission Guidelines
- ---------------------
Authors may submit drafts of full papers or extended abstracts.
Submissions are limited to 12 A4-size pages, with 1.5 inch top
margin and other margins 1 inch wide with 11 point or larger font.  
Authors who feel that more details are necessary may include a 
clearly marked appendix which will be read at the discretion of 
the Programme Committee.  Each paper should contain a short abstract.  
If available, e-mail addresses and fax numbers of the authors should 
be included.

Electronic Submissions
- --------------------

Electronic submission is very strongly encouraged.  

You may submit your paper using Rich Gerber's system START by visiting
the URL for the conference and following the appropriate links.
The URL for submissions is

    http://www.cse.iitd.ernet.in/~fsttcs20/START/www/submit.html

In case you ar eunable to submit using START, self-contained uuencoded
gzipped Postscript versions of the paper may be sent by e-mail to

		    fsttcs20@REDACTED

In addition, the following information in ASCII format should be 
sent to this address in a **separate** e-mail: Title; authors; 
communicating author's name, address, and e-mail address and 
fax number if available; abstract of paper.

Hard-Copy Submissions
- ---------------------
If electronic submission is not possible, authors may submit five 
(5) hard-copies of the paper by post to the following address:

		    FST TCS 2000
		    Department of Computer Science  and Engineering 
		    I.I.T., Delhi 
		    Hauz Khas
		    New Delhi 110 016
		    INDIA

Invited Speakers
----------------
Invited Speakers who have confirmed participation include:
 Peter Buneman (U Penn)
 Bernard Chazelle (Princeton)
 E. Allen Emerson (U Texas, Austin)
 Martin Groetschel (ZIB)
 Jose Meseguer (SRI)
 Philip Wadler (Bell Labs)


Programme Committee
-------------------

Pankaj Agarwal		(Duke)
Manindra Agrawal	      (IIT, Kanpur)		
Tetsuo Asano		(JAIST)
Vijay Chandru		(IISc, Bangalore)
Rance Cleaveland	      (Stony Brook)		
Anuj Dawar		      (Cambridge)			
Sampath Kannan		(AT&T Research)
Sanjiv Kapoor		(IIT, Delhi)		(Co-chair)
Kamal Lodaya		(IMSc, Chennai)		
Madhavan Mukund		(CMI, Chennai)		
Gopalan Nadathur	      (Loyola)			
Seffi Naor		      (Bell Labs and Technion)
Tobias Nipkow		(TU Munich)			
Luke Ong		      (Oxford)			
C. Pandu Rangan		(IIT, Chennai)
Paritosh Pandya		(TIFR)		
Benjamin Pierce		(U Penn)			
Sanjiva Prasad		(IIT, Delhi)		(Co-chair)		
Sridhar Rajagopalan     (IBM, Almaden)
Abhiram Ranade	      (IIT, Mumbai)
Dave Sands		      (Chalmers)	
A Prasad Sistla		(U Illinois, Chicago)	
Michiel Smid		(Magdeburg)
Mandayam K. Srivas	(SRI) 


Organized by
------------
Indian Institute of Technology, Delhi
Hauz Khas, New Delhi 100 016. 



Organizing Committee
-------------------
Sandeep Sen			(chair)
Naveen Garg			(treasurer)
S N Maheshwari

Conference Site
---------------
The Conference will take place at the India International Centre,
40 Lodhi Estate, Max Mueller Marg, New Delhi 110 003.

Correspondence Address
----------------------
All correspondence regarding submissions may be addressed to 

    FST TCS 2000
    Department of Computer Science  and Engineering 
    I.I.T., Delhi
    Hauz Khas, 
    New Delhi 110 016, INDIA

    Email:	  fsttcs20@REDACTED
    Fax:	  +91 11 686 8765
    Phone:	  +91 11 659 1294 / 659 1286
    URL:	  http://www.cse.iitd.ernet.in/~fsttcs20






-- 


				    Sanjiva Prasad
				 Associate Professor

Department of Computer Science and Engineering		sanjiva@REDACTED
Indian Institute of Technology, Delhi			(Off) +91 11 659 1294
Hauz Khas, New Delhi 110016					(Res) +91 11 659 1684
INDIA									(Fax) +91 11 686 8765

		    http://www.cse.iitd.ernet.in/~sanjiva


From globalist@REDACTED  Tue May 23 07:32:37 2000
From: globalist@REDACTED (globalist@REDACTED)
Date: Mon, 22 May 2000 21:32:37 -0800
Subject: A Question For You To Answer
Message-ID: <b35j2n6r731k4m.nr8d6y4yw70hgkv67k7m@get.com>

Hello, 

I am a business owner and I would like to ask you a business related question.  Out of respect, I always like to get permission before I send an e-mail.  May I e-mail you this question? For your convenience simply click on the link below.  (When the email template appears, simply click the send button to receive this message.  A written message is not necessary.)

Thank you

NOTE:  To receive the question, click on the link below or use your reply button.
request1@REDACTED



---------------------------------------------------------------------------------------------------
This e-mail is being sent in compliance with Senate bill 1618, Title 3, section301.
http://www.senate.gov/~murkowski/commercialemail/S771index.html
Further transmissions to you by the sender of this email may be stopped at no cost to
you by sending a reply to this email address listcontrol@REDACTED
with the word "remove" in the subject line.
-------------------------------------------------------------------------------------------------------



From ingela@REDACTED  Wed May 24 15:52:28 2000
From: ingela@REDACTED (Ingela Anderton)
Date: Wed, 24 May 2000 15:52:28 +0200 (MET DST)
Subject: Routingtabels 
Message-ID: <200005241352.PAA27758@townsend.ericsson.se>


Hello!

I am trying to figure out if you can implement a ruoting table in
Erlang that is efficient enough or if you have to use c? Someone in the 
project that I currently work in made a version using ets-tables and
looking backwards starting with the mask 255.255.255.255 and then
trying 255.255.255.254, 255.255.255.252 etc. until they
find a entry and then they know that they have the longest prefix
match. As far as I understand it would be a better idea to use some
kind of tree-based algorithm. Would it be possible to do this
efficiently in Erlang?

-- 
/m.v.h Ingela

//The highway of life is always under construction. //

 	        |\      _,,,--,,_  ,)
                /,`.-'`'   -,  ;-;;' 
               |,4-  ) )-,_ ) /\
              '---''(_/--' (_/-'

Ericsson Utvecklings AB             Phone :   +46 8 719 18 13
Open Systems (f.d. Erlang Systems)  Cellular/Mobile: +46 70 636 78 68 
Torshamnsgatan 39 B
Box 1214                            http://www.erlang.se
S-164 28 KISTA, SWEDEN              ingela@REDACTED




From klacke@REDACTED  Wed May 24 16:37:00 2000
From: klacke@REDACTED (Klacke)
Date: Wed, 24 May 2000 16:37:00 +0200
Subject: Routingtabels
In-Reply-To: <200005241352.PAA27758@townsend.ericsson.se>
References: <200005241352.PAA27758@townsend.ericsson.se>
Message-ID: <20000524163700.A92288@bluetail.com>

On Wed, May 24, 2000 at 03:52:28PM +0200, Ingela Anderton wrote:
> 
> Hello!
> 
> I am trying to figure out if you can implement a ruoting table in
> Erlang that is efficient enough or if you have to use c? Someone in the 
> project that I currently work in made a version using ets-tables and
> looking backwards starting with the mask 255.255.255.255 and then
> trying 255.255.255.254, 255.255.255.252 etc. until they
> find a entry and then they know that they have the longest prefix
> match. As far as I understand it would be a better idea to use some
> kind of tree-based algorithm. Would it be possible to do this
> efficiently in Erlang?
> 


I'd say that a real routing table looking for longest prefix
just screams for a linked in driver. Typically routing tables
can grow pretty large as well. There's also a wealth of really good
c-implementations of routing-table search out there.

But it's indeed possible to implement as a tree in erlang. It all depends
on the speed requirements as well as the number of entries you
expect to get into your routing tables. 


/klacke


-- 
Claes Wikstrom                          <klacke@REDACTED>
Bluetail AB                             http://www.bluetail.com




From taha@REDACTED  Wed May 24 18:13:34 2000
From: taha@REDACTED (Walid Taha)
Date: Wed, 24 May 2000 18:13:34 +0200 (MET DST)
Subject: SAIG Deadline Extended to June 5th
In-Reply-To: <Pine.SOL.4.21.0005081315570.4048-100000@muppet70.cs.chalmers.se>
References: <Pine.SOL.4.21.0005081315570.4048-100000@muppet70.cs.chalmers.se>
Message-ID: <Pine.SOL.4.21.0005241809050.1710-100000@muppet70.cs.chalmers.se>


                             DEADLINE EXTENDED

                 Semantics, Applications and Implementation 
                       of Program Generation (SAIG)

                ( http://www.md.chalmers.se/~taha/saig/ )

              ICFP Workshop, Montreal, September 20th, 2000.  

              NEW DEADLINE:  June 5th, 2000 is final and firm.

Numerous recent studies investigate different aspects of program
generation systems, including their semantics, their applications, and
their implementation.  Existing theories and systems address both
high-level (source) language and low-level (machine) language generation.  
A number of programming languages now supports program generation and
manipulation, with different goals, implementation techniques, and
targeted at different applications. The goal of this workshop is to
provide a meeting place for researchers and practitioners interested in
this research area, and in program generation in general.

Scope:  The workshop solicits submissions related to one or more of the
following topics:

   * Multi-level and multi-stage languages, staged computation,
   * Partial evaluation (of e.g. functional, logical, imperative
     programs),
   * Run-time specialization (in e.g. compilers, operating systems),
   * High-level program generation (applications, foundations,
     environments),
   * Symbolic computation, in-lining and macros,

Submissions are especially welcome if they relate ideas and concepts from
several topics, bridge the gap between theory and practice, cover new
ground, or report exciting applications. The program committee will be
happy to advise on the appropriateness of a particular subject.

Distribution:  Accepted papers will be published as a Chalmers technical
report, and will be made available online.  A special issue of the Journal
of Higher Order and Symbolic Computation (HOSC) is planned afterwards.

Format:  The one-day workshop will contain slots for participants to
present accepted papers. In addition, there will be time allocated for
open discussions during the workshop.  Invited speakers will be announced
in the near future.

Invited Speakers:

   * Gilles Muller, IRISA
   * Dick Kieburtz, OGI
   * Frank Pfenning, CMU

Submission Details:  Authors are invited to submit papers of at most 5000
words (excluding figures), in postscript format (letter or A4), to
saig@REDACTED by June 5th 2000. Both position and technical papers
are welcome.  Please indicate at time of submission. Position papers are
expected to describe ongoing work, future directions, and/or survey
previous results.  Technical papers are expected to contain novel results.  
All papers will be reviewed by the program committee for the above
mentioned criteria, in addition to correctness and clarity.  Authors will
be notified of acceptance by 3 July 2000.  Final version of the papers
must be submitted by 31 July 2000.

Program Committee:

   Cliff Click, Sun Micro Systems
   Rowan Davies, CMU
   Torben Mogensen, DIKU
   Suresh Jagannathan, NEC Research
   Tim Sheard, OGI
   Walid Taha, Chalmers (workshop chair)
   Peter Thiemann, Freiburg




From etxuwig@REDACTED  Wed May 24 18:26:00 2000
From: etxuwig@REDACTED (Ulf Wiger)
Date: Wed, 24 May 2000 18:26:00 +0200 (MET DST)
Subject: Routingtabels 
In-Reply-To: <200005241352.PAA27758@townsend.ericsson.se>
Message-ID: <Pine.GSO.4.10.10005241816130.21006-100000@avc303>


You can make a pretty elegant prefix-match implementation using an
ordered_set ets table. Whether it's efficient enough depends on what
you're doing, but the AXD 301 ATM Switch is using a similar
implementation (we used to have a linked-in driver, but found this
approach efficient enough.)

The following shell dialog illustrates the principle.

Eshell V4.9.1.1  (abort with ^G)
1> ets:new(ana,[ordered_set,named_table]).
ana
2> ets:insert(ana, {"255.255.254", data}).
true
3> ets:insert(ana, {"255.255.252", data}).
true
4> ets:insert(ana, {"255.255.250", data}).
true
5> Prefix1 = ets:prev(ana, "255.255.254.13").
"255.255.254"
6> Prefix2 = ets:prev(ana, "255.255.251.13").
"255.255.250"

To find out whether the prefix matches, you can use e.g.
lists:prefix/2.

7> Prefix2 = ets:prev(ana, "255.255.251.13").
"255.255.250"
8> lists:prefix(Prefix2, "255.255.251.13").
false

/Uffe


On Wed, 24 May 2000, Ingela Anderton wrote:

>
>Hello!
>
>I am trying to figure out if you can implement a ruoting table in
>Erlang that is efficient enough or if you have to use c? Someone in the 
>project that I currently work in made a version using ets-tables and
>looking backwards starting with the mask 255.255.255.255 and then
>trying 255.255.255.254, 255.255.255.252 etc. until they
>find a entry and then they know that they have the longest prefix
>match. As far as I understand it would be a better idea to use some
>kind of tree-based algorithm. Would it be possible to do this
>efficiently in Erlang?
>
>

-- 
Ulf Wiger, Chief Designer AXD 301         <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuv?gen 9, ?lvsj?                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44



From martin@REDACTED  Thu May 25 21:43:55 2000
From: martin@REDACTED (Martin Logan)
Date: Thu, 25 May 2000 14:43:55 -0500 (CDT)
Subject: No subject
Message-ID: <Pine.BSF.4.02.10005251432340.4297-100000@rook.vail>

Some of us, at the company I work for, have become interested in erlang. I
have been doing a fair amount of reading on the Bluetail robustification
apps.  I am a little confused on one point.  Page 18 in the manual named
btw11.ps Bluetail Robustifiers/Prioritizers, states:

If more than one gateway is used each gateway is given a
separate IP adress and DNS round robin can be used to share the load
between the gateways. This avoids the problems caused by having stale IP
adresses in DNS cache since the IP adress is always fresh.
    
I am not clear on why the IP adresses are "always fresh".  Was this
somthing implemented via erlang?  Thank you in advance for any helpful
info you could provide me.
			      Sincerly,
                              Martin Logan.



From tobbe@REDACTED  Thu May 25 22:53:12 2000
From: tobbe@REDACTED (Torbjorn Tornkvist)
Date: 25 May 2000 22:53:12 +0200
Subject: none
In-Reply-To: Martin Logan's message of "Thu, 25 May 2000 14:43:55 -0500 (CDT)"
References: <Pine.BSF.4.02.10005251432340.4297-100000@rook.vail>
Message-ID: <lou2fmqrlz.fsf@parrot.bluetail.com>


> I am not clear on why the IP adresses are "always fresh".

It means that the IP address of the crashed machine is 
automatically moved to another (cooperating) machine.

> Was this somthing implemented via erlang? 

Yes (well, with the help of the native OS).

Cheers /Tobbe
--
Bluetail AB , Hantverkargatan 78 , SE-112 38 Stockholm , Sweden            
Email: support@REDACTED , Web: http://www.bluetail.com
Tel: +46 8 692 22 20 , Fax: +46 8 654 70 71


From R.Barrett@REDACTED  Fri May 26 15:23:52 2000
From: R.Barrett@REDACTED (Richard Barrett)
Date: Fri, 26 May 2000 14:23:52 +0100
Subject: epmd
Message-ID: <v04220802b5542102394f@[172.16.3.104]>

I am a newcomer to erlang and in my spare time trying to learn about 
it. I've got a problem with the the process monitor daemon, epmd, 
which may be due to my ignorance. It goes as follows:

Whenever I start an erlang process using erl -name ..., another copy 
of epmd is also created. This is regardless of whether an instance of 
epmd is already running as a a result of my having run it explicitly 
from the command line or previously started another instance of erl. 
I've checked using netstat and lsof and all these instances of epmd 
are trying to listen on port 4369.

Having started multiple instances of erl from different terminal 
windows, it appears that only the epmd process started by the most 
recently executed erl command will respond to an epmd -names command 
and it only reports knowing the name of the erl process that invoked 
it. Killing the most recent epmd will "expose" the "prior" invocation 
of epmd which still only reports the name of the erl process that ran 
it, and is equally ignorant of the names any other erl processes that 
are running.

Closing down an erl process does not lead to the corresponding epmd 
process terminating. Over a period of time this leaves growing 
numbers of epmd process in the system. It also leads to confusion in 
inter-erl-process communications and asymmetry in what inter-process 
communication can be performed.

This arrangement is not what I'd expected. I had assumed that once 
there was an instance of epmd in the system subsequent invocations of 
erl would communicate with that epmd process rather than invoking 
another. I'd also assumed the single epmd would report all of the 
named erl process in the system.

Can anyone tell me what I'm doing wrong or suggest where I might look 
in the documentation or source for a solution to this.

I am running erlang installed from erlang_otp-R6B-4.i386.rpm under 
Suse 6.2 Linux.

Thanks, in advance, for your help.

------------------------------------------------------------------
Richard Barrett, PostPoint 27,         e-mail:r.barrett@REDACTED
Fujitsu Telecommunications Europe Ltd,      tel: (44) 121 717 6337
Solihull Parkway, Birmingham Business Park, B37 7YU, England
"Democracy is two wolves and a lamb voting on what to have for
lunch. Liberty is a well armed lamb contesting the vote."
Benjamin Franklin, 1759
------------------------------------------------------------------


From not.for.email@REDACTED  Fri May 26 16:11:13 2000
From: not.for.email@REDACTED (Gordon Beaton)
Date: 26 May 2000 14:11:13 GMT
Subject: epmd
References: <v04220802b5542102394f@[172.16.3.104]>
Message-ID: <8gm0m1$p8i$1@news.du.uab.ericsson.se>

On 26 May 2000 13:23:52 GMT, Richard Barrett wrote:
> Whenever I start an erlang process using erl -name ..., another copy 
> of epmd is also created. This is regardless of whether an instance of 
> epmd is already running as a a result of my having run it explicitly 
> from the command line or previously started another instance of erl. 
> I've checked using netstat and lsof and all these instances of epmd 
> are trying to listen on port 4369.

This should not be possible! Epmd will exit at start if its attempt to
bind the socket to port 4369 fails. And if another process (such as an
earlier epmd) has already bound to the same port, then the attempt
*will* fail, unless something is seriously wrong with your kernel.

Are you quite certain that you have two running at the same time, on
the same host? Please show the output of ps!

Note that each of the erlang nodes maintains a connection to epmd, and
netstat will show this connection with port 4369 at the "foreign" end.

/gordon

-- 
g o r d o n . b e a t o n @ e r i c s s o n . c o m



From not.for.email@REDACTED  Fri May 26 16:18:18 2000
From: not.for.email@REDACTED (Gordon Beaton)
Date: 26 May 2000 14:18:18 GMT
Subject: epmd
References: <v04220802b5542102394f@[172.16.3.104]>
Message-ID: <8gm13a$prd$1@news.du.uab.ericsson.se>

On 26 May 2000 13:23:52 GMT, Richard Barrett wrote:
> This arrangement is not what I'd expected. I had assumed that once 
> there was an instance of epmd in the system subsequent invocations of 
> erl would communicate with that epmd process rather than invoking 
> another. I'd also assumed the single epmd would report all of the 
> named erl process in the system.

This is in fact what happens when the subsequent erlang nodes are
running on the same host as the original one. One instance of epmd
runs on each host where erlang is running, and epmd doesn't terminate
when erlang does. Each epmd only knows about the erlang nodes local to
that host.

When erlang node "foo@REDACTED" wants to connect to erlang node
"gurka@REDACTED", it asks epmd on "anotherhost" for the port number
to "gurka".

/gordon

-- 
g o r d o n . b e a t o n @ e r i c s s o n . c o m



From dgud@REDACTED  Fri May 26 16:33:01 2000
From: dgud@REDACTED (Dan Gudmundsson)
Date: Fri, 26 May 2000 16:33:01 +0200 (MET DST)
Subject: epmd
In-Reply-To: <v04220802b5542102394f@[172.16.3.104]>
References: <v04220802b5542102394f@[172.16.3.104]>
Message-ID: <14638.35613.282749.524042@gargle.gargle.HOWL>


Hi 

Clarification 
epmd = Erlang Port Mapper Daemon 
and NOT a process monitor.

/Dan

Richard Barrett writes:
 > I am a newcomer to erlang and in my spare time trying to learn about 
 > it. I've got a problem with the the process monitor daemon, epmd, 
 > which may be due to my ignorance. 


From per@REDACTED  Fri May 26 17:27:32 2000
From: per@REDACTED (Per Hedeland)
Date: Fri, 26 May 2000 17:27:32 +0200 (MET DST)
Subject: epmd
In-Reply-To: <8gm0m1$p8i$1@news.du.uab.ericsson.se>
References: <8gm0m1$p8i$1@news.du.uab.ericsson.se>
Message-ID: <200005261527.e4QFRWU00552@aalborg.du.uab.ericsson.se>

not.for.email@REDACTED (Gordon Beaton) wrote:
>On 26 May 2000 13:23:52 GMT, Richard Barrett wrote:
>> Whenever I start an erlang process using erl -name ..., another copy 
>> of epmd is also created. This is regardless of whether an instance of 
>> epmd is already running as a a result of my having run it explicitly 
>> from the command line or previously started another instance of erl. 
>> I've checked using netstat and lsof and all these instances of epmd 
>> are trying to listen on port 4369.
>
>This should not be possible!

Good point.:-)

> Epmd will exit at start if its attempt to
>bind the socket to port 4369 fails. And if another process (such as an
>earlier epmd) has already bound to the same port, then the attempt
>*will* fail, unless something is seriously wrong with your kernel.

Indeed, there seems to be something seriously wrong with Richard's
(Unix/Linux) kernel. I've actually seen this bug, i.e. the kernel
letting a new process bind to a port that another was already bound to,
a couple of times - it has exactly the weird symptoms Richard describes,
which are of course a disaster for a process that is supposed to manage
the Erlang-node-namespace on a host.

At one point the Erlang startup code had a workaround for this bug,
checking by means of trying to communicate with an existing epmd before
attempting to start a new one - but it has its own problems and isn't
fool-proof anyway (race conditions etc), and removing it was probably
the correct decision.

>> I am running erlang installed from erlang_otp-R6B-4.i386.rpm under 
>> Suse 6.2 Linux.

I'm afraid you'll have to contact Suse about this bug, if no-one else
has come across it already they're bound to do soon - most standard Unix
daemons will be affected by it to some degree, though in most cases not
as severely as epmd. You can try starting some number of those (e.g.
sendmail, as an example of a TCP-based server that normally runs
standalone rather than from inetd), and see if you don't get the same
effect (don't use the startup scripts though, run the binary directly).

Alternatively you could of course work around the bug by e.g. removing
the automatic startup of epmd (in erts/etc/common/erlexec.c I believe),
and making sure you manually start only one instance on each host -
probably not a very good idea, though.

--Per Hedeland
per@REDACTED

PS In case anyone's interested, the cases where I saw the bug was a)
when using some third-party SunOS 4 kernel patches for multicast, and b)
in an early Solaris version - maybe 2.2.


From enano@REDACTED  Fri May 26 17:50:55 2000
From: enano@REDACTED (Miguel Barreiro Paz)
Date: Fri, 26 May 2000 17:50:55 +0200 (CEST)
Subject: ODBC
Message-ID: <Pine.LNX.4.21.0005261741580.22988-100000@ceu.fi.udc.es>


	Hello all,

	Is anyone working on the ODBC application? It currently compiles
on Solaris and Win32 only; however, we gave it a try yesterday and it 
seems to work correctly under Linux after touching the Makefiles a bit. 

	In case someone is interested, we've used Openlink iODBC driver
manager 3.0.2 (beta) with the mysql odbc driver 2.50.26.

Regards,

Miguel






From R.Barrett@REDACTED  Tue May 30 14:20:58 2000
From: R.Barrett@REDACTED (Richard Barrett)
Date: Tue, 30 May 2000 13:20:58 +0100
Subject: epmd
In-Reply-To: <8gm0m1$p8i$1@news.du.uab.ericsson.se>
References: <v04220802b5542102394f@[172.16.3.104]>
 <8gm0m1$p8i$1@news.du.uab.ericsson.se>
Message-ID: <v04220800b55958636f13@[172.16.3.104]>

Gordon Beaton wrote:
>On 26 May 2000 13:23:52 GMT, Richard Barrett wrote:
>  > Whenever I start an erlang process using erl -name ..., another copy
>  > of epmd is also created. This is regardless of whether an instance of
>  > epmd is already running as a a result of my having run it explicitly
>  > from the command line or previously started another instance of erl.
>  > I've checked using netstat and lsof and all these instances of epmd
>  > are trying to listen on port 4369.
>
>This should not be possible! Epmd will exit at start if its attempt to
>bind the socket to port 4369 fails. And if another process (such as an
>earlier epmd) has already bound to the same port, then the attempt
>*will* fail, unless something is seriously wrong with your kernel.
>
>Are you quite certain that you have two running at the same time, on
>the same host? Please show the output of ps!
>
>Note that each of the erlang nodes maintains a connection to epmd, and
>netstat will show this connection with port 4369 at the "foreign" end.
>
>/gordon
>
>--
>g o r d o n . b e a t o n @ e r i c s s o n . c o m

I also wondered if I was delusional but the following output has 
convinced me I am not.

I am still investigating why this is occuring.

One line of enquiry a colleague has suggested to me is that if the 
SO_REUSEADDR socket option is specified then more than one bind to 
port 4369 could succeed (see TCP/IP Illustrated Vol 1 by W. Richard 
Stevens, Section 18.6 under Heading 2MSL Wait State, page 243 in my 
copy). If this hypothesis is correct then simply using bind failure 
to determine that a socket is not already in use may be insufficient 
to test for an existing epmd daemon, on Suse 6.2 Linux at least.

Incidentally, the machine concerned is running various other servers 
without any obvious problems although it is clear that my use of 
erlang is challenging the OS support for sockets in new and 
interesting ways. btw, I am using a stock kernel off the installation 
CDs rather than some home crafted version of my own, so the problem 
may be generic with erlang under Suse 6.2 Linux.


-----------------------------------------------------------

grep to find no copies of erl and epmd running:

vvvvvvvv
barrett@REDACTED:~ > ps ax | grep erl
19435  ?  S    0:00 grep erl
^^^^^^^^
-----------------------------------------------------------
Run one copy of erl as follows:

vvvvvvvv
barrett@REDACTED:~/erlang > erl -name fred
Erlang (BEAM) emulator version 4.9.1 [source]

Eshell V4.9.1  (abort with ^G)
(fred@REDACTED)1>
^^^^^^^^

grep again. we have a copy of beam and epmd running as expected:
vvvvvvvv
barrett@REDACTED:~ > ps ax | grep erl
19436  ?  S    0:00 /usr/local/lib/erlang/erts-4.9.1/bin/beam -- 
-root /usr/loca
19442  ?  S    0:00 /usr/local/lib/erlang/erts-4.9.1/bin/epmd -daemon
^^^^^^^^
and use epmd to find out who is about:

vvvvvvvv
barrett@REDACTED:~ > epmd -names
bash: epmd: command not found
barrett@REDACTED:~ > /usr/local/lib/erlang/erts-4.9.1/bin/epmd -names
epmd: up and running on port 4369 with data:
name fred at port 1752
^^^^^^^^
-----------------------------------------------------------
Second copy of erl run as follows:

vvvvvvvv
barrett@REDACTED:~/erlang > erl -name jim
Erlang (BEAM) emulator version 4.9.1 [source]

Eshell V4.9.1  (abort with ^G)
(jim@REDACTED)1>
^^^^^^^^
grep again. lo and behold, we now have two copies of epmd running on 
the same machine:

vvvvvvvv
barrett@REDACTED:~ > ps ax | grep erl
19436  ?  S    0:00 /usr/local/lib/erlang/erts-4.9.1/bin/beam -- 
-root /usr/loca
19442  ?  S    0:00 /usr/local/lib/erlang/erts-4.9.1/bin/epmd -daemon
19447  ?  S    0:00 /usr/local/lib/erlang/erts-4.9.1/bin/beam -- 
-root /usr/loca
19453  ?  S    0:00 /usr/local/lib/erlang/erts-4.9.1/bin/epmd -daemon
^^^^^^^^
and use epmd to find out who is about. only the most recently run 
beam is being reported:

vvvvvvvv
barrett@REDACTED:~ > /usr/local/lib/erlang/erts-4.9.1/bin/epmd -names
epmd: up and running on port 4369 with data:
name jim at port 1755
^^^^^^^^
use netstat to find out about which of the processes of interest is 
dealing with which ports. note the "impossible": both copies of epmd 
are bound to port 4369!

vvvvvvvv
barrett@REDACTED:~ > netstat -p | grep epmd
(Not all processes could be identified, non-owned process info
  will not be shown, you would have to be root to see it all.)
tcp        0      0 localhost.ftel.co.:4369 localhost.ftel.co.:1756 
ESTABLISHED 19453/epmd
tcp        0      0 localhost.ftel.co.:4369 localhost.ftel.co.:1753 
ESTABLISHED 19442/epmd
barrett@REDACTED:~ > netstat -p | grep beam
(Not all processes could be identified, non-owned process info
  will not be shown, you would have to be root to see it all.)
tcp        0      0 localhost.ftel.co.:1756 localhost.ftel.co.:4369 
ESTABLISHED 19447/beam
tcp        0      0 localhost.ftel.co.:1753 localhost.ftel.co.:4369 
ESTABLISHED 19436/beam
^^^^^^^^
check with lsof to see what it says about the open files for the epmd 
and beam processes. note the "impossible" again: both copies of epmd 
are listening on port 4369!

vvvvvvvv
barrett@REDACTED:~ > lsof -p 19436,19442,19447,19453 | grep TCP
beam    19436 barrett    3u  inet 264273            TCP *:1752 (LISTEN)
beam    19436 barrett    4u  inet 264275            TCP 
localhost.ftel.co.uk:1753->localhost.ftel.co.uk:4369 (ESTABLISHED)
epmd    19442 barrett    3u  inet 264271            TCP *:4369 (LISTEN)
epmd    19442 barrett    4u  inet 264276            TCP 
localhost.ftel.co.uk:4369->localhost.ftel.co.uk:1753 (ESTABLISHED)
beam    19447 barrett    3u  inet 264298            TCP *:1755 (LISTEN)
beam    19447 barrett    4u  inet 264300            TCP 
localhost.ftel.co.uk:1756->localhost.ftel.co.uk:4369 (ESTABLISHED)
epmd    19453 barrett    3u  inet 264296            TCP *:4369 (LISTEN)
epmd    19453 barrett    4u  inet 264301            TCP 
localhost.ftel.co.uk:4369->localhost.ftel.co.uk:1756 (ESTABLISHED)
^^^^^^^^


------------------------------------------------------------------
Richard Barrett, PostPoint 27,         e-mail:r.barrett@REDACTED
Fujitsu Telecommunications Europe Ltd,      tel: (44) 121 717 6337
Solihull Parkway, Birmingham Business Park, B37 7YU, England
"Democracy is two wolves and a lamb voting on what to have for
lunch. Liberty is a well armed lamb contesting the vote."
Benjamin Franklin, 1759
------------------------------------------------------------------


From sanjiva@REDACTED  Tue May 30 14:14:10 2000
From: sanjiva@REDACTED (Sanjiva Prasad)
Date: Tue, 30 May 2000 17:44:10 +0530
Subject: FST TCS 2000: One week extension on the submission deadline 
Message-ID: <200005301214.RAA02069@cse.iitd.ernet.in>


Anticipating down time at our site, and to give interested authors
the benefit of a weekend, we are extending the deadline for submission
to June 6, 2000.  We also encourange authors to submit using the
START program that can be accessed from the home page of the
FST TCS 2000 conference 
    http://www.cse.iitd.ernet.in/fsttcs20



***********************************************************************
*                                                                     *
*                            FST TCS 2000                             *
*                                                                     *
* Foundations of Software Technology and Theoretical Computer Science *
*                        December 13--15, 2000                        *
*                          New Delhi, India                           *
*                                                                     *
***********************************************************************
*                          Call for Papers                            *
***********************************************************************

Submission Guidelines
- ---------------------
Authors may submit drafts of full papers or extended abstracts.
Submissions are limited to 12 A4-size pages, with 1.5 inch top
margin and other margins 1 inch wide with 11 point or larger font.  
We advise authors to employ Springer-Verlag's LNCS style file "llncs.sty".
Authors who feel that more details are necessary may include a 
clearly marked appendix which will be read at the discretion of 
the Programme Committee.  Each paper should contain a short abstract.  
If available, e-mail addresses and fax numbers of the authors should 
be included.

Electronic Submissions
- --------------------

Electronic submission is very strongly encouraged.  

You may submit your paper using Rich Gerber's system START by visiting
the URL for the conference and following the appropriate links.
The URL for submissions is

    http://www.cse.iitd.ernet.in/~fsttcs20/START/www/submit.html

In case you ar eunable to submit using START, self-contained uuencoded
gzipped Postscript versions of the paper may be sent by e-mail to

		    fsttcs20@REDACTED

In addition, the following information in ASCII format should be 
sent to this address in a **separate** e-mail: Title; authors; 
communicating author's name, address, and e-mail address and 
fax number if available; abstract of paper.

Hard-Copy Submissions
- ---------------------
If electronic submission is not possible, authors may submit five 
(5) hard-copies of the paper by post to the following address:

		    FST TCS 2000
		    Department of Computer Science  and Engineering 
		    I.I.T., Delhi 
		    Hauz Khas
		    New Delhi 110 016
		    INDIA


-- 


				    Sanjiva Prasad
				 Associate Professor

Department of Computer Science and Engineering		sanjiva@REDACTED
Indian Institute of Technology, Delhi			(Off) +91 11 659 1294
Hauz Khas, New Delhi 110016					(Res) +91 11 659 1684
INDIA									(Fax) +91 11 686 8765

		    http://www.cse.iitd.ernet.in/~sanjiva


From TXMANYG@REDACTED  Tue May 30 18:15:48 2000
From: TXMANYG@REDACTED (Anders Nygren (TXM))
Date: Tue, 30 May 2000 11:15:48 -0500
Subject: Erlang on AIX
Message-ID: <2BAC8A0CFC6AD311A0E900508B0904F9273E98@EAMSTNT700>

Hi
I am trying to install erlang on an IBM RS/6000 with AIX 4.2.1
and found that there are some patches needed. But I am not clear
on which patches I really need. On the erlang.org web page with 
patches, it say about AIX that I need 
"all the above C-source patches" but I dont see why I 
would need for instance a patch for "Multicast add/drop membership
broken on Intel".
So which patches do I really need.

Also to expose my ignorance, how do I apply the patches. I tried
with the patch command and a number of different flags and parameters
and only got a reply like "sorry, can not find a patch in there"

-

Anders Nygren
System Architect
Empresa Tecnologica Ericsson
Tel +52 84 38 4799



From R.Barrett@REDACTED  Tue May 30 19:14:29 2000
From: R.Barrett@REDACTED (Richard Barrett)
Date: Tue, 30 May 2000 18:14:29 +0100
Subject: epmd
Message-ID: <v04220801b55997202c76@[172.16.3.104]>

I raised the problem on this mailing list of multiple copies of epmd 
being spawned when multiple copies erl were run, each of which only 
knew about the instance of beam that spawned it. Further, all epmd 
instances were successfully listening on port 4369.

Initial opinions in response were that this should be impossible and 
might be due to a screwed up kernel on my Suse 6.2 Linux controlled 
machine.

I have investigated further and believe that all is working as 
advertised with Suse Linux and the problem with empd arises from a 
conditional compilation decision in the distribution source file 
otp_src_R6B-0/erts/empd/src/epmd_srv.c

Around lines 135 to 146 of this source file, conditional compilation 
of a setsocketopt call to enable the SO_REUSEADDR option occurs if 
the OS being compiled under is not _WIN32_.

In effect, the coding assumption is that on non-_WIN32_ (that is, on 
UNIX or Linux I guess), an attempt by a new instance of epmd to bind 
to port 4369 when another instance of epmd is already bound to that 
port, will fail even if the SO_REUSEADDR socket option is set on the 
socket being used to bind to the port  This bind failure is in effect 
used to determine if epmd is already running.

It turns out that Suse 6.2 Linux (as on _WIN32_) and possibly other 
versions of Linux, take the SO_REUSEADDR socket option at face value. 
In consequence, bind failure, when this socket option is used, is 
inadequate as the sole determinant of whether epmd is already extant 
in the system.

Certainly, commenting out the relevant conditionally compiled lines 
in epmd_srv.c and rebuilding epmd has solved the multiple epmd 
instances problem I had.

For reasons I have yet to determine, under Sun Solaris, an attempt to 
bind to a given port by a second instance of my test scripts (see 
below) does fail, even though the SO_REUSEADDR socket option has be 
enabled. So, Solaris and Suse 6.2 Linux appear to interpret the 
semantics of the SO_REUSEADDR socket option rather differently and 
I've no opinion as to which is correct.

Incidentally, I explored this problem using some short Python 
scripts, copies of which are given below. Thanks to those readers who 
contributed a response to my original posting.

--------------------------------------------------------
Experimental Python scripts are as follows.

server script enabling SO_REUSEADDR --------------------

from socket import *
import os
pid = os.getpid()
HOST = ''
PORT = 4369
s = socket(AF_INET, SOCK_STREAM)
s.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
reuse = s.getsockopt(SOL_SOCKET, SO_REUSEADDR)
print "Server process pid=%d starting with SO_REUSEADDR=%d" % (pid, reuse)
s.bind(HOST, PORT)
s.listen(1)
conn, addr = s.accept()
s.close()
print "Process %d connected to %s with SO_REUSEADDR=%d" % (pid, addr, reuse)
while 1:
	data = conn.recv(1024)
	if not data: break
	data = data + (", returned by pid=%d" % pid)
	conn.send(data)
conn.close()

server script not enabling SO_REUSEADDR --------------------

from socket import *
import os
pid = os.getpid()
HOST = ''
PORT = 4369
s = socket(AF_INET, SOCK_STREAM)
reuse = s.getsockopt(SOL_SOCKET, SO_REUSEADDR)
print "Server process pid=%d starting with SO_REUSEADDR=%d" % (pid, reuse)
s.bind(HOST, PORT)
s.listen(1)
conn, addr = s.accept()
s.close()
print "Process %d connected to %s with SO_REUSEADDR=%d" % (pid, addr, reuse)
while 1:
	data = conn.recv(1024)
	if not data: break
	data = data + (", returned by pid=%d" % pid)
	conn.send(data)
conn.close()

client script --------------------
from socket import *
import os
pid = os.getpid()
print "Client process pid=%d starting" % pid
HOST = ''
PORT = 4369
s = socket(AF_INET, SOCK_STREAM)
s.connect(HOST, PORT)
s.send("Hello, world sent from pid=%d" % pid)
data = s.recv(1024)
s.close()
print 'Received', `data`
--------------------------------------------------------------
------------------------------------------------------------------
Richard Barrett, PostPoint 27,         e-mail:r.barrett@REDACTED
Fujitsu Telecommunications Europe Ltd,      tel: (44) 121 717 6337
Solihull Parkway, Birmingham Business Park, B37 7YU, England
"Democracy is two wolves and a lamb voting on what to have for
lunch. Liberty is a well armed lamb contesting the vote."
Benjamin Franklin, 1759
------------------------------------------------------------------


From dg@REDACTED  Tue May 30 20:22:45 2000
From: dg@REDACTED (dg@REDACTED)
Date: Tue, 30 May 2000 11:22:45 -0700
Subject: epmd
In-Reply-To: <v04220801b55997202c76@[172.16.3.104]>; from R.Barrett@ftel.co.uk on Tue, May 30, 2000 at 06:14:29PM +0100
References: <v04220801b55997202c76@[172.16.3.104]>
Message-ID: <20000530112245.A6679@archimedes.suse.com>

On Tue, May 30, 2000 at 06:14:29PM +0100, Richard Barrett wrote:
> I raised the problem on this mailing list of multiple copies of epmd 
> being spawned when multiple copies erl were run, each of which only 
> knew about the instance of beam that spawned it. Further, all epmd 
> instances were successfully listening on port 4369.
> 
> Initial opinions in response were that this should be impossible and 
> might be due to a screwed up kernel on my Suse 6.2 Linux controlled 
> machine.

Here from my copy (you can get one too!) of the 2.3.99pre8 kernel
sources is a longish comment on SO_REUSEADDR:

--- include/net/tcp.h:55 ---
/* There are a few simple rules, which allow for local port reuse by
 * * an application.  In essence:
 *      
 *      1) Sockets bound to different interfaces may share a local port.
 *         Failing that, goto test 2.
 *      2) If all sockets have sk->reuse set, and none of them are in
 *         TCP_LISTEN state, the port may be shared.
 *         Failing that, goto test 3.
 *      3) If all sockets are bound to a specific sk->rcv_saddr local
 *         address, and none of them are the same, the port may be
 *         shared.
 *         Failing this, the port cannot be shared.
 *
 * The interesting point, is test #2.  This is what an FTP server does
 * all day.  To optimize this case we use a specific flag bit defined
 * below.  As we add sockets to a bind bucket list, we perform a
 * check of: (newsk->reuse && (newsk->state != TCP_LISTEN))
 * As long as all sockets added to a bind bucket pass this test,
 * the flag bit will be set.
 * The resulting situation is that tcp_v[46]_verify_bind() can just
 * check
 * for this flag bit, if it is set and the socket trying to bind has
 * sk->reuse set, we don't even have to walk the owners list at all,
 * we return that it is ok to bind this socket to the requested local
 * port.
 *
 * Sounds like a lot of work, but it is worth it.  In a more naive
 * implementation (ie. current FreeBSD etc.) the entire list of ports
 * must be walked for each data port opened by an ftp server.  Needless
 * to say, this does not scale at all.  With a couple thousand FTP
 * users logged onto your box, isn't it nice to know that new data
 * ports are created in O(1) time?  I thought so. ;-)   -DaveM
 */
---------------------------

Dunno if this helps...

-dg

-- 
David Gould                                                 dg@REDACTED
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
C++ : an octopus made by nailing extra legs onto a dog


From enano@REDACTED  Tue May 30 21:07:14 2000
From: enano@REDACTED (Miguel Barreiro Paz)
Date: Tue, 30 May 2000 21:07:14 +0200 (CEST)
Subject: Erlang on alpha (was erlang on AIX)
In-Reply-To: <2BAC8A0CFC6AD311A0E900508B0904F9273E98@EAMSTNT700>
Message-ID: <Pine.LNX.4.21.0005302104510.29239-100000@ceu.fi.udc.es>


	On a related note, has anyone compiled Erlang on OSF/1 or Digital
Unix or Tru64 or whatever it's called this week? 

> Also to expose my ignorance, how do I apply the patches. I tried
> with the patch command and a number of different flags and parameters
> and only got a reply like "sorry, can not find a patch in there"

	cd patches_directory ; rm .toc ; smitty install_latest





From klacke@REDACTED  Tue May 30 21:27:50 2000
From: klacke@REDACTED (Klacke)
Date: Tue, 30 May 2000 21:27:50 +0200
Subject: epmd
In-Reply-To: <v04220801b55997202c76@[172.16.3.104]>
References: <v04220801b55997202c76@[172.16.3.104]>
Message-ID: <20000530212750.C13315@bluetail.com>

On Tue, May 30, 2000 at 06:14:29PM +0100, Richard Barrett wrote:
> Around lines 135 to 146 of this source file, conditional compilation 
> of a setsocketopt call to enable the SO_REUSEADDR option occurs if 
> the OS being compiled under is not _WIN32_.
> 
> In effect, the coding assumption is that on non-_WIN32_ (that is, on 
> UNIX or Linux I guess), an attempt by a new instance of epmd to bind 
> to port 4369 when another instance of epmd is already bound to that 
> port, will fail even if the SO_REUSEADDR socket option is set on the 
> socket being used to bind to the port  This bind failure is in effect 
> used to determine if epmd is already running.
> 
> It turns out that Suse 6.2 Linux (as on _WIN32_) and possibly other 
> versions of Linux, take the SO_REUSEADDR socket option at face value. 
> In consequence, bind failure, when this socket option is used, is 
> inadequate as the sole determinant of whether epmd is already extant 
> in the system.


Here are my cents ...

1. The only reason (as far as I can see) to have SO_REUSEADDR on the
epmd socket is while debugging epmd. That is while starting and stopping
epmd several times. So the SO_REUSEADDR option should be removed on 
the epmd daemon.

2. This is the first OS I've ever heard of that actualy steals the
port from another unix process that has already bound the port
to a socket. This simply cannot be right. I was living under
the impression that the SO_REUSEADDR ment that a bind attempt
to a port should succeed even if the port was still lingering 
in the kernel queue for old port bindings, assuming that no
process had the port already bound. In the latter case, the bind 
shall fail.


/klacke




From enano@REDACTED  Tue May 30 22:56:41 2000
From: enano@REDACTED (Miguel Barreiro Paz)
Date: Tue, 30 May 2000 22:56:41 +0200 (CEST)
Subject: Erlang on alpha (was erlang on AIX)
In-Reply-To: <Pine.LNX.4.21.0005302104510.29239-100000@ceu.fi.udc.es>
Message-ID: <Pine.LNX.4.21.0005302253470.4691-100000@ceu.fi.udc.es>


> 	cd patches_directory ; rm .toc ; smitty install_latest

	Great, certainly funny. Slashing myself in penitence.

	I mean, try "patch <tmp_patch_R6B0.9.txt" from the $OTP_ROOT
directory.
	
Regards,




From per@REDACTED  Wed May 31 00:11:15 2000
From: per@REDACTED (Per Hedeland)
Date: Wed, 31 May 2000 00:11:15 +0200 (MET DST)
Subject: Erlang on alpha (was erlang on AIX)
In-Reply-To: <Pine.LNX.4.21.0005302253470.4691-100000@ceu.fi.udc.es>
References: <Pine.LNX.4.21.0005302253470.4691-100000@ceu.fi.udc.es>
Message-ID: <200005302211.e4UMBFs28861@super.du.uab.ericsson.se>

Miguel Barreiro Paz <enano@REDACTED> wrote:
>
>> 	cd patches_directory ; rm .toc ; smitty install_latest
>
>	Great, certainly funny. Slashing myself in penitence.

AIX-internal joke?:-)

>	I mean, try "patch <tmp_patch_R6B0.9.txt" from the $OTP_ROOT
>directory.

Sorry, yes, there really should be an instruction on how to apply the
patches - the above is very close, really just needs a -p0 to honour the
paths in the patch files. I.e.

     cd $ERL_TOP              (i.e. the .../otp_src_R6B-0 directory)
     patch -p0 < tmp_patch_R6B0.9.txt

  or even

     cat tmp_patch_R6B0.* | patch -p0

If your patch program says something like "can't find a patch in there",
it is either very old or broken (or both), and doesn't understand the
"unified diff" format. Get a current version from your nearest GNU
archive or ftp.gnu.org.

And the instructions for the AIX patch actually explain why you should
apply all the patches:

  - To get all the problems fixed, in fact even to get this patch to
                                                ^^^^^^^^^^^^^^^^^^^^
  apply cleanly, it is necessary to first apply all the C source patches
  ^^^^^^^^^^^^^
  above.

The diffs in the patch are done relative to a version that has had all
the earlier patches applied (otherwise it would fail for those that had
this). In particular several of the patches update the generated
"configure" scripts, and any change to the configure.in input for these
tend to generate a *lot* of diffs due to the embedded line numbers in
configure, making multiple patches to configure heavily interdependant.

But anyway, AIX specifically needs *some* of the other patches too, and
they will all be incorporated into the next release, so there is really
no reason to skip any of them, even if it would work - if there are
problems with having them applied, we want to know about that.

--Per Hedeland
per@REDACTED


From per@REDACTED  Wed May 31 00:51:17 2000
From: per@REDACTED (Per Hedeland)
Date: Wed, 31 May 2000 00:51:17 +0200 (MET DST)
Subject: epmd
In-Reply-To: <v04220801b55997202c76@[172.16.3.104]>
References: <v04220801b55997202c76@[172.16.3.104]>
Message-ID: <200005302251.e4UMpHo00871@super.du.uab.ericsson.se>

Richard Barrett <R.Barrett@REDACTED> wrote:
>I raised the problem on this mailing list of multiple copies of epmd 
>being spawned when multiple copies erl were run, each of which only 
>knew about the instance of beam that spawned it. Further, all epmd 
>instances were successfully listening on port 4369.

Um, a new connection can only be delivered to one of them, and arguably
that's the only one that is "successfully" listening at that point in
time...

>I have investigated further and believe that all is working as 
>advertised with Suse Linux

It is not. I don't have a Suse Linux available, but on a RedHat 6.1
system (kernel 2.2.12-20smp), where I incidentally tried to reproduce
your problem but failed (i.e. SO_REUSEADDR worked correctly), the
socket(7) man page says:

       SO_REUSEADDR
              Indicates  that  the  rules  used   in   validating
              addresses  supplied  in a bind(2) call should allow
              reuse of local addresses. For PF_INET sockets  this
              means  that a socket may bind, except when there is
                                             ^^^^^^^^^^^^^^^^^^^^
              an active listening socket bound  to  the  address.
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
              When  the  listening  socket is bound to INADDR_ANY
              with a specific port then it  is  not  possible  to
              bind to this port for any local address.

- which is the standard semantics of SO_REUSEADDR. What the "reuse of
local addresses" means is that you're allowed to bind a socket to IP
address X, port Y, even though there is another socket already bound to
that address/port, *provided the remote address differs*. I.e. an
established connection {X,Y} <-> {P,Q} where {P,Q} is a remote
address/port, doesn't prevent a starting daemon from binding to {X,Y},
as the "remote address/port" is the "wildcard" {*,*}, i.e. different.

Without the SO_REUSEADDR such an established (or terminated but
"lingering") connection prevents the daemon from starting, thus it is
basically "standard operating procedure" for TCP-based daemons. It
should *not* allow two processes to have a socket with local
address/port {X,Y} and remote address/port {*,*}, anymore than it should
allow two identical established connections {X,Y} <-> {P,Q}.

>Around lines 135 to 146 of this source file, conditional compilation 
>of a setsocketopt call to enable the SO_REUSEADDR option occurs if 
>the OS being compiled under is not _WIN32_.

I'm afraid I can't comment on the WIN32 stuff, my guess would be that it
simply lacks the SO_REUSEADDR functionality, but of course it could be
broken there too (or done some other way).

>For reasons I have yet to determine, under Sun Solaris, an attempt to 
>bind to a given port by a second instance of my test scripts (see 
>below) does fail, even though the SO_REUSEADDR socket option has be 
>enabled.

Yes, modern versions of Solaris, like most all other Unix versions,
implement SO_REUSEADDR correctly.

All this being said, it might still be the case that Erlang should try
to avoid being bitten by a broken SO_REUSEADDR implementation. Klacke
wrote:

}1. The only reason (as far as I can see) to have SO_REUSEADDR on the
}epmd socket is while debugging epmd. That is while starting and stopping
}epmd several times. So the SO_REUSEADDR option should be removed on 
}the epmd daemon.

This might be reasonable - epmd doesn't fork on new connections (of
course), thus if one instance is already running, it will also take care
of any new connections, and there is no need to start a new daemon.
However if you've forcibly killed the running one for whatever reason,
and then immediately start up a new distributed Erlang system, you may
then end up with no epmd at all (i.e. distribution startup will fail),
due to a "lingering" connection. I don't know if this is acceptable - I
guess this needs some thinking about...

--Per Hedeland
per@REDACTED





From dg@REDACTED  Wed May 31 02:52:28 2000
From: dg@REDACTED (David Gould)
Date: Tue, 30 May 2000 17:52:28 -0700
Subject: epmd
In-Reply-To: <v04220801b55997202c76@[172.16.3.104]>; from R.Barrett@ftel.co.uk on Tue, May 30, 2000 at 06:14:29PM +0100
References: <v04220801b55997202c76@[172.16.3.104]>
Message-ID: <20000530175228.E7028@archimedes.suse.com>

On Tue, May 30, 2000 at 06:14:29PM +0100, Richard Barrett wrote:
... 
> It turns out that Suse 6.2 Linux (as on _WIN32_) and possibly other 
> versions of Linux, take the SO_REUSEADDR socket option at face value. 
> In consequence, bind failure, when this socket option is used, is 
> inadequate as the sole determinant of whether epmd is already extant 
> in the system.
... 
> For reasons I have yet to determine, under Sun Solaris, an attempt to 
> bind to a given port by a second instance of my test scripts (see 
> below) does fail, even though the SO_REUSEADDR socket option has be 
> enabled. So, Solaris and Suse 6.2 Linux appear to interpret the 
> semantics of the SO_REUSEADDR socket option rather differently and 
> I've no opinion as to which is correct.
> 
> Incidentally, I explored this problem using some short Python 
> scripts, copies of which are given below. Thanks to those readers who 
> contributed a response to my original posting.

I tested with your scripts on SuSE 6.4

  (Linux archimedes 2.2.14 #1 Sat Mar 11 04:17:23 GMT 2000 i686 unknown)

and get the correct result I think:

      $ python so_reuseaddr_svr.py  &
      [1] 7644
      Server process pid=7644 starting with SO_REUSEADDR=1
      $ python so_reuseaddr_svr.py  &
      [2] 7645
      Server process pid=7645 starting with SO_REUSEADDR=1
      Traceback (innermost last):
        File "so_reuseaddr_svr.py", line 11, in ?
          s.bind(HOST, PORT)
      socket.error: (98, 'Address already in use')

-dg
 
> --------------------------------------------------------
> Experimental Python scripts are as follows.
> 
> server script enabling SO_REUSEADDR --------------------
> 
> from socket import *
> import os
> pid = os.getpid()
> HOST = ''
> PORT = 4369
> s = socket(AF_INET, SOCK_STREAM)
> s.setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)
> reuse = s.getsockopt(SOL_SOCKET, SO_REUSEADDR)
> print "Server process pid=%d starting with SO_REUSEADDR=%d" % (pid, reuse)
> s.bind(HOST, PORT)
> s.listen(1)
> conn, addr = s.accept()
> s.close()
> print "Process %d connected to %s with SO_REUSEADDR=%d" % (pid, addr, reuse)
> while 1:
> 	data = conn.recv(1024)
> 	if not data: break
> 	data = data + (", returned by pid=%d" % pid)
> 	conn.send(data)
> conn.close()
> 
> server script not enabling SO_REUSEADDR --------------------
> 
> from socket import *
> import os
> pid = os.getpid()
> HOST = ''
> PORT = 4369
> s = socket(AF_INET, SOCK_STREAM)
> reuse = s.getsockopt(SOL_SOCKET, SO_REUSEADDR)
> print "Server process pid=%d starting with SO_REUSEADDR=%d" % (pid, reuse)
> s.bind(HOST, PORT)
> s.listen(1)
> conn, addr = s.accept()
> s.close()
> print "Process %d connected to %s with SO_REUSEADDR=%d" % (pid, addr, reuse)
> while 1:
> 	data = conn.recv(1024)
> 	if not data: break
> 	data = data + (", returned by pid=%d" % pid)
> 	conn.send(data)
> conn.close()
> 
> client script --------------------
> from socket import *
> import os
> pid = os.getpid()
> print "Client process pid=%d starting" % pid
> HOST = ''
> PORT = 4369
> s = socket(AF_INET, SOCK_STREAM)
> s.connect(HOST, PORT)
> s.send("Hello, world sent from pid=%d" % pid)
> data = s.recv(1024)
> s.close()
> print 'Received', `data`
> --------------------------------------------------------------

-- 
David Gould                                                 dg@REDACTED
SuSE, Inc.,  580 2cd St. #210,  Oakland, CA 94607          510.628.3380
C++ : an octopus made by nailing extra legs onto a dog