From vances@REDACTED Fri Oct 1 02:16:40 1999 From: vances@REDACTED (Vance Shipley) Date: Thu, 30 Sep 1999 20:16:40 -0400 Subject: net_adm:names() failing In-Reply-To: <005201bf0ac5$9e557920$0abdc5c0@desk.motivity.ca> Message-ID: <000101bf0ba2$3bad64d0$0abdc5c0@desk.motivity.ca> I seem to be having some problems with tcp on my Unixware port. I believe that I'm loosing messages when the socket gets closed. Anybody have any ideas? On my Unixware port I have a problem with net_adm:names() returning {ok, []} at all times (not just using short host names as I reported before). Some debugging shows that in the module erl_epmd, in the function do_get_names, the socket seems to be getting closed before the return message is received. In the receive loop the {tcp, Socket, [P0,P1,P2,P3|T]} never gets called, just the {tcp_closed, Socket}. erl_epmd.erl: do_get_names(Socket) -> inet_tcp:send(Socket, [?int16(1),?EPMD_NAMES]), receive {tcp, Socket, [P0,P1,P2,P3|T]} -> EpmdPort = ?u32(P0,P1,P2,P3), if EpmdPort == ?erlang_daemon_port -> names_loop(Socket, T, []); true -> close(Socket), {error, address} end; {tcp_closed, Socket} -> {ok, []} end. I know it's not a problem with epmd because my windows machine can get names from the unixware epmd and from unixware I can't get names from the windows machine. The debug output from epmd shows the same from both accesses: Windows: ***** Thu Sep 30 19:52:29 1999: opening connection on file descriptor 6 ***** Thu Sep 30 19:52:29 1999: time in seconds: 938735549 ***** Thu Sep 30 19:52:29 1999: time in seconds: 938735549 ***** Thu Sep 30 19:52:29 1999: got 3 bytes ***** 00000000 00 01 6e |..n| ***** Thu Sep 30 19:52:29 1999: time in seconds: 938735549 ***** Thu Sep 30 19:52:29 1999: got 4 bytes ***** 00000000 00 00 11 11 |....| ***** Thu Sep 30 19:52:29 1999: got 22 bytes ***** 00000000 6e 61 6d 65 20 66 6f 6f 20 61 74 20 70 6f 72 74 |name foo at port| ***** 00000010 20 31 32 37 35 0a | 1275.| ***** Thu Sep 30 19:52:29 1999: sent NAMES_RESP ***** Thu Sep 30 19:52:29 1999: closing connection on file descriptor 6 Unixware: ***** Thu Sep 30 19:53:01 1999: opening connection on file descriptor 6 ***** Thu Sep 30 19:53:01 1999: time in seconds: 938735581 ***** Thu Sep 30 19:53:01 1999: time in seconds: 938735581 ***** Thu Sep 30 19:53:01 1999: got 3 bytes ***** 00000000 00 01 6e |..n| ***** Thu Sep 30 19:53:01 1999: time in seconds: 938735581 ***** Thu Sep 30 19:53:01 1999: got 4 bytes ***** 00000000 00 00 11 11 |....| ***** Thu Sep 30 19:53:01 1999: got 22 bytes ***** 00000000 6e 61 6d 65 20 66 6f 6f 20 61 74 20 70 6f 72 74 |name foo at port| ***** 00000010 20 31 32 37 35 0a | 1275.| ***** Thu Sep 30 19:53:01 1999: sent NAMES_RESP ***** Thu Sep 30 19:53:01 1999: closing connection on file descriptor 6 -Vance -------------- next part -------------- A non-text attachment was scrubbed... Name: Vance Shipley.vcf Type: application/octet-stream Size: 518 bytes Desc: not available URL: From klacke@REDACTED Fri Oct 1 08:52:39 1999 From: klacke@REDACTED (Klacke) Date: Fri, 1 Oct 1999 08:52:39 +0200 (CEST) Subject: Code changing In-Reply-To: <87n1u4vr77.fsf@baked.vegetable.org> References: <87n1u4vr77.fsf@baked.vegetable.org> Message-ID: <14324.23095.691938.758856@kricka.bluetail.com> Luke Gorrie writes: > G'day all, > > A couple of questions about code changes in an erlang system. First, > we're having a problem changing code in etk-using modules. The module > itself is a gen_event and copes with code changes okay, but the > command functions given to tk objects don't seem to work > anymore. After a code change, I get: > > tkfun error: 1 : {function_clause,{messaging_gui, > module_lambda_1, > [10574021,[],{}]}} > > I've tried to fix this with: > The problem with this is that etk installs Funs in the etk processes. When the code is changed, the Funs are not valid any more. This is actually a bug which I think is fixed is the next release. Which by the way is due on Nov, 10. !!!!!! We had the Erlang User conference yesterday and and the OTP group told us that they'd just scheduled the next OSE release for Nov 10. This is great news. The bug is easily spotted if you compile -module(a). -compile(export_all). a(X) -> fun() ->X+1 end. with the 'E' flag (see erl -man compiler) and watch the output i a.E There's a timestamp compiled into the module_lambdas/4 function which is generated by the pre processor. Not very very good, but as I said, Bjorn Gustavsson has fixed this is the Nov 10, release. (I think) Cheers /klacke From magnus@REDACTED Fri Oct 1 08:54:30 1999 From: magnus@REDACTED (Magnus =?iso-8859-1?Q?Fr=F6berg?=) Date: Fri, 01 Oct 1999 08:54:30 +0200 Subject: net_adm:names() failing References: <000101bf0ba2$3bad64d0$0abdc5c0@desk.motivity.ca> Message-ID: <37F45AA6.3C244213@bluetail.com> Hi ! Vance Shipley wrote: > > I seem to be having some problems with tcp on my Unixware > port. I believe that I'm loosing messages when the socket > gets closed. Anybody have any ideas? I noticed the same some time ago (I think it was on SUSE linux) and made some changes to erl_epmd.erl. Seems like it was after the latest open source release though. > > On my Unixware port I have a problem with net_adm:names() > returning {ok, []} at all times (not just using short host > names as I reported before). > > Some debugging shows that in the module erl_epmd, in the > function do_get_names, the socket seems to be getting closed > before the return message is received. In the receive loop > the {tcp, Socket, [P0,P1,P2,P3|T]} never gets called, just > the {tcp_closed, Socket}. > The problem is that we cant be sure about that the 4 bytes port header arrives in the same tcp package. I send a fix I made right now (I compiled it and it seems to work ok for me;-). erl_epmd.erl: do_get_names(Socket) -> inet_tcp:send(Socket, [?int16(1),?EPMD_NAMES]), do_get_names(Socket, []). do_get_names(Socket, PList) -> receive {tcp, Socket, Bytes} -> case get_port(Bytes, PList) of {ok, ?erlang_daemon_port, T} -> names_loop(Socket, T, []); {more, PList1} -> do_get_names(Socket, PList1); _ -> close(Socket), {error, address} end; {tcp_closed, Socket} -> {ok, []} end. get_port(Bytes, [P0,P1,P2,P3]) -> {ok, ?u32(P0,P1,P2,P3), Bytes}; get_port([H|Bytes], PList) -> get_port(Bytes, PList ++ [H]); get_port([], PList) -> {more, PList}. Hope this was your case as well. /Magnus From klacke@REDACTED Fri Oct 1 08:55:31 1999 From: klacke@REDACTED (Klacke) Date: Fri, 1 Oct 1999 08:55:31 +0200 (CEST) Subject: safedets In-Reply-To: <19990929165729.F27137@hawk.oak.informix.com> References: <14322.31801.899127.579042@duva.bluetail.com> <19990929165729.F27137@hawk.oak.informix.com> Message-ID: <14324.23267.842505.318847@kricka.bluetail.com> > > Cool. One other thing to look at is Berkeley DB instead of gdbm. See > www.sleepycat.com for more info and downloads. > -dg Yeah, I know about the bekeley DB. The problem with it is that it costs a whole lot of money. I was just recently in contact with them, so I know. /klacke From "mickael_remond"@REDACTED Fri Oct 1 10:56:02 1999 From: "mickael_remond"@REDACTED ("mickael_remond"@REDACTED) Date: Fri, 1 Oct 1999 10:56:02 +0200 Subject: User Conference Message-ID: Hi, How was the User Conference ? Will the slides and a summary of the conference be available online ? Thanks in advance, Micka?l R?mond From etxuwig@REDACTED Fri Oct 1 11:03:22 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 1 Oct 1999 11:03:22 +0200 (MET DST) Subject: Code changing In-Reply-To: <87n1u4vr77.fsf@baked.vegetable.org> Message-ID: On 30 Sep 1999, Luke Gorrie wrote: luke>G'day all, luke> luke>A couple of questions about code changes in an erlang system. luke>First, we're having a problem changing code in etk-using modules. luke>The module itself is a gen_event and copes with code changes luke>okay, but the command functions given to tk objects don't seem to luke>work anymore. After a code change, I get: luke> luke>tkfun error: 1 : {function_clause,{messaging_gui, luke> module_lambda_1, luke> [10574021,[],{}]}} In the existing commercial release, OTP R5B, funs don't break during code change, but in R4B and OSE they do. Your only bet in Open Source (apart from waiting for the next release) is either avoiding funs in your state, or "recreating" them during code change (which is not always practical.) luke>The other issue is with gen_event and code_change. If I don't luke>make a code_change/3 function, my gen_event processes don't luke>survive code changes. I put this down to some code in gen_event: luke> luke>{ok, NewState} = Module:code_change(OldVsn, H#handler.state, Extra), Yes, this is something that isn't really documented: in reality, you need to write dummy code_change() functions for all your process implementations -- or fix the upgrade scripts by hand every time so that code change is not performed (only suspend-load-resume), which is OK if no internal state changes have occured. The release handler interprets any EXIT (including undef) in a code change function as an error -- as it should, I think. This is true for all behaviours as well as for processes which handle their own system messages: you must acknowledge the 'change_code' instruction if it is present in the application upgrade script. /Uffe Ulf Wiger, Chief Designer AXD 301 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 klacke@REDACTED Fri Oct 1 11:12:13 1999 From: klacke@REDACTED (Klacke) Date: Fri, 1 Oct 1999 11:12:13 +0200 (CEST) Subject: Code changing In-Reply-To: References: <87n1u4vr77.fsf@baked.vegetable.org> Message-ID: <14324.31469.999744.375995@kricka.bluetail.com> > change, but in R4B and OSE they do. Your only bet in Open Source (apart > from waiting for the next release) is either avoiding funs in your state, > or "recreating" them during code change (which is not always practical.) > It's not the case that Luke can avoid to use Funs in the state. The etk library uses Funs in the state and all of us etk users are stuck with that. We'll just have to wait for the next release. /klacke From SEAN.HINDE@REDACTED Fri Oct 1 11:28:00 1999 From: SEAN.HINDE@REDACTED (SEAN HINDE) Date: Fri, 1 Oct 1999 10:28:00 +0100 Subject: safedets Message-ID: <36076247.010999@smtpgate1.ONE2ONE.CO.UK> Does using fragmented tables mean that recovery is done in parallel across the fragments and therefore takes 1/'No of fragments' time to complete? I like the idea of giving up disc space to allow very fast recovery. Klacke, have you plugged safedets into mnesia and done any tests? Sean Hinde ---------- From: Torbjorn Tornkvist To: Hakan Mattsson Cc: erlang-questions@REDACTED Subject: Re: safedets Date: 30 September 1999 00:18 > By using the feature of fragmented tables in Mnesia, > a table may be split into lots of fragments where > each fragment is implemented as a normal Mnesia > table. I guess this is something new (i.e not in the Open Source Erlang) ? Can you give an example of how to do this ? /Tobbe From gunilla@REDACTED Fri Oct 1 11:40:13 1999 From: gunilla@REDACTED (Gunilla Hugosson) Date: Fri, 01 Oct 1999 11:40:13 +0200 Subject: Code changing References: <87n1u4vr77.fsf@baked.vegetable.org> <14324.31469.999744.375995@kricka.bluetail.com> Message-ID: <37F4817D.D5B32210@erix.ericsson.se> I can just add that the next release is scheduled to November 10. / Gunilla Klacke wrote: > > It's not the case that Luke can avoid to use Funs in the state. > The etk library uses Funs in the state and all of us etk users > are stuck with that. We'll just have to wait for the next release. > > /klacke From klacke@REDACTED Fri Oct 1 12:02:18 1999 From: klacke@REDACTED (Klacke) Date: Fri, 1 Oct 1999 12:02:18 +0200 (CEST) Subject: safedets In-Reply-To: <36076247.010999@smtpgate1.ONE2ONE.CO.UK> References: <36076247.010999@smtpgate1.ONE2ONE.CO.UK> Message-ID: <14324.34474.354052.239724@kricka.bluetail.com> > have you plugged safedets into mnesia and done any tests? Nope, I'll see If I get around to that. It's a good idea though and it ought to be pretty straight forward to do the naive implementation, However doing it properly is more work and probably something for the OTP crew. Mnesia already uses a log to log all transactions. safedets also uses a log to log a all write ops. One log to much :-( /klacke From luke@REDACTED Fri Oct 1 18:51:34 1999 From: luke@REDACTED (Luke Gorrie) Date: 02 Oct 1999 02:51:34 +1000 Subject: Code changing In-Reply-To: Gunilla Hugosson's message of "Fri, 01 Oct 1999 11:40:13 +0200" References: <87n1u4vr77.fsf@baked.vegetable.org> <14324.31469.999744.375995@kricka.bluetail.com> <37F4817D.D5B32210@erix.ericsson.se> Message-ID: <87g0zv2fe1.fsf@baked.vegetable.org> Gunilla Hugosson writes: > I can just add that the next release is scheduled to November 10. I think I speak for all of us when I say "yahooooo!" Will the commercial and open source versions be one and the same from this point onwards? Cheers, Luke From vances@REDACTED Sun Oct 3 19:29:39 1999 From: vances@REDACTED (Vance Shipley) Date: Sun, 3 Oct 1999 13:29:39 -0400 Subject: IG now broken Message-ID: <000501bf0dc4$def013d0$0abdc5c0@desk.motivity.ca> It would appear that the Interface Generator (ig-1.7.1) is now broken due to the fact that the sockets module has been removed. This came as an unwelcome suprise yesterday during a port of my application away from R5B (commercial) to the latest Open Source release. Unless I'm wrong I would suggest that IG either be removed or updated in the Open Source release. -Vance From tobbe@REDACTED Mon Oct 4 00:04:20 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 04 Oct 1999 08:04:20 +1000 Subject: IG now broken In-Reply-To: "Vance Shipley"'s message of "Sun, 3 Oct 1999 13:29:39 -0400" References: <000501bf0dc4$def013d0$0abdc5c0@desk.motivity.ca> Message-ID: > Unless I'm wrong I would suggest that IG either be removed > or updated in the Open Source release. But, I'm sure I've been using IG with the Open Source release !? Have someone removed the socket stuff recently or is my memory wrong ? Since there exist code which relies on IG I suggest either that someone writes an easy-to-follow transition guide line from IG to IC, or that IG continue to exist as a non-supported user contrib (I can port it to use gen_tcp). /Tobbe -- Torbj?rn T?rnkvist tobbe@REDACTED o{..}o ph: +61 3 9925 4089 fax:+61 3 9925 4094 moo! (oo)___ Software Engineering Research Centre (SERC) (______)\ / \ / \ From vances@REDACTED Mon Oct 4 00:56:13 1999 From: vances@REDACTED (Vance Shipley) Date: Sun, 3 Oct 1999 18:56:13 -0400 Subject: net_adm:names() failing In-Reply-To: <37F45AA6.3C244213@bluetail.com> Message-ID: <000801bf0df2$7de91fe0$0abdc5c0@desk.motivity.ca> Magnus, Unfortunately this patch didn't seem to have any effect. :( -Vance } -----Original Message----- } From: owner-erlang-questions@REDACTED } [mailto:owner-erlang-questions@REDACTED]On Behalf Of Magnus Fr berg } Sent: Friday, October 01, 1999 2:55 AM } To: Vance Shipley } Cc: erlang-questions@REDACTED } Subject: Re: net_adm:names() failing } } } Hi ! } } Vance Shipley wrote: } > } > I seem to be having some problems with tcp on my Unixware } > port. I believe that I'm loosing messages when the socket } > gets closed. Anybody have any ideas? } } I noticed the same some time ago (I think it was on SUSE linux) and made } some changes to erl_epmd.erl. Seems like it was after the latest open } source release though. } } > } > On my Unixware port I have a problem with net_adm:names() } > returning {ok, []} at all times (not just using short host } > names as I reported before). } > } > Some debugging shows that in the module erl_epmd, in the } > function do_get_names, the socket seems to be getting closed } > before the return message is received. In the receive loop } > the {tcp, Socket, [P0,P1,P2,P3|T]} never gets called, just } > the {tcp_closed, Socket}. } > } } The problem is that we cant be sure about that the 4 bytes port header } arrives in the same tcp package. I send a fix I made right now (I } compiled it and it seems to work ok for me;-). } } erl_epmd.erl: } } do_get_names(Socket) -> } inet_tcp:send(Socket, [?int16(1),?EPMD_NAMES]), } do_get_names(Socket, []). } } do_get_names(Socket, PList) -> } receive } {tcp, Socket, Bytes} -> } case get_port(Bytes, PList) of } {ok, ?erlang_daemon_port, T} -> } names_loop(Socket, T, []); } {more, PList1} -> } do_get_names(Socket, PList1); } _ -> } close(Socket), } {error, address} } end; } {tcp_closed, Socket} -> } {ok, []} } end. } } get_port(Bytes, [P0,P1,P2,P3]) -> } {ok, ?u32(P0,P1,P2,P3), Bytes}; } get_port([H|Bytes], PList) -> } get_port(Bytes, PList ++ [H]); } get_port([], PList) -> } {more, PList}. } } Hope this was your case as well. } } /Magnus } From vances@REDACTED Mon Oct 4 02:22:26 1999 From: vances@REDACTED (Vance Shipley) Date: Sun, 3 Oct 1999 20:22:26 -0400 Subject: net_adm:names() failing In-Reply-To: <37F45AA6.3C244213@bluetail.com> Message-ID: <000901bf0dfe$8958dda0$0abdc5c0@desk.motivity.ca> Magnus, More investigation suggests that the problem is on the epmd server side. I began to suspect that the problem was at the socket level and my research brought me to the SO_LINGER socket level option. This option is supposed to control what happens when you close a socket that has pending writes on it. I added in a setsockopt() call to set SO_LINGER but that didn't help. To check on this theory I put in a sleep(1) right before the close. This worked, net_adm:names() now returned correct information. However I can't get it to work through setting the socket option for linger (one thing is that the timeout value isn't documented anywhere, I don't know if it's seconds. ms, etc.). The thing that is strange about this is that my WinNT machine can get names off the Unixware epmd just fine without any changes. Putting in the sleep in epmd before closing the socket definitely made it work from the Unixware erl shell though. Hmmm... -Vance From vances@REDACTED Mon Oct 4 08:12:37 1999 From: vances@REDACTED (Vance Shipley) Date: Mon, 4 Oct 1999 02:12:37 -0400 Subject: erl_eterm core dumps? Message-ID: <000d01bf0e2f$7482bc80$0abdc5c0@desk.motivity.ca> I've been trying to implement a C program with the erl_interface library to communicate with an erlang node. I was following the examples in the documentation when I found that constructing ETERM items would core dump. I assumed it was my Unixware port again but I have since tried it on the otp_LXA_11928_sunos5_i386_R4B and otp_LXA_11928_sunos5_i386_R5B01 commercial versions with the same result. What if anything is wrong with this?: t.c: #include "erl_interface.h" #include "ei.h" main() { ETERM *e; int i; i = 1; e = erl_mk_int(i); } gcc -I/usr/local/lib/erlang/usr/include -o t t.c -L/usr/local/lib/erlang/usr/lib -lerl_interface -Vance From tobbe@REDACTED Mon Oct 4 08:26:19 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 04 Oct 1999 16:26:19 +1000 Subject: erl_eterm core dumps? In-Reply-To: "Vance Shipley"'s message of "Mon, 4 Oct 1999 02:12:37 -0400" References: <000d01bf0e2f$7482bc80$0abdc5c0@desk.motivity.ca> Message-ID: You have to call: erl_init(NULL, 0); the first thing you do. Cheers /Tobbe --------------------------------------------- /* This program doesn't core dump */ #include "erl_interface.h" #include "ei.h" main() { ETERM *e; int i; erl_init(NULL, 0); i = 1; e = erl_mk_int(i); } --------------------------------------------- From per@REDACTED Mon Oct 4 10:45:34 1999 From: per@REDACTED (Per Hedeland) Date: Mon, 4 Oct 1999 10:45:34 +0200 (MET DST) Subject: net_adm:names() failing Message-ID: <199910040845.KAA17180@super.du.uab.ericsson.se> >More investigation suggests that the problem is on the epmd >server side. I began to suspect that the problem was at the >socket level and my research brought me to the SO_LINGER >socket level option. This option is supposed to control what >happens when you close a socket that has pending writes on it. SO_LINGER just makes the close() block until the pending data is sent (allowing you to find out if the sending failed), without it the close() returns immediately, but the kernel will still send the data (modulo timeout, remote close, etc). Of course the Unixware socket/TCP implementation could be broken in this respect, but most TCP-using applications depend on this behaviour, so that's rather unlikely. > To check on this theory I put in a sleep(1) right before >the close. This worked, net_adm:names() now returned correct >information. >The thing that is strange about this is that my WinNT machine can >get names off the Unixware epmd just fine without any changes. >Putting in the sleep in epmd before closing the socket definitely >made it work from the Unixware erl shell though. All this, together with the fact that you previously reported that the Unixware system couldn't get names from a remote epmd either (or is this no longer the case?), definitely points to a problem on the Unixware "client side", I think. First thing I would do to debug it would be to add a receive clause for "Other" in erl_epmd.erl/do_get_names to see if an error message, or something else "unexpected", is received (arguably there should already be a clause for {tcp_error, Socket, Reason}). --Per Hedeland per@REDACTED From SEAN.HINDE@REDACTED Mon Oct 4 10:47:00 1999 From: SEAN.HINDE@REDACTED (SEAN HINDE) Date: Mon, 4 Oct 1999 9:47:00 +0100 Subject: Code changing Message-ID: <36076bc8.040999@smtpgate1.ONE2ONE.CO.UK> I use the commercial version for some very high availibility telecoms applications and still expect to receive fully tested new releases on a probably 6 monthly basis from Ericsson. I guess Ericssons many internal customers will have the same requirement. Any views on how this will/can/should be reconciled with a more freeform open source environment? Rgds, Sean Hinde >Gunilla Hugosson writes: > I can just add that the next release is scheduled to November 10. >I think I speak for all of us when I say "yahooooo!" Will the >commercial and open source versions be one and the same from this >point onwards? >Cheers, >Luke From etxuwig@REDACTED Mon Oct 4 11:48:11 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 4 Oct 1999 11:48:11 +0200 (MET DST) Subject: Code changing In-Reply-To: <36076bc8.040999@smtpgate1.ONE2ONE.CO.UK> Message-ID: On Mon, 4 Oct 1999, SEAN HINDE wrote: SEAN.H>I use the commercial version for some very high availibility SEAN.H>telecoms applications and still expect to receive fully SEAN.H>tested new releases on a probably 6 monthly basis from SEAN.H>Ericsson. I guess Ericssons many internal customers will have SEAN.H>the same requirement. Speaking for one of the internal customers, we will also expect fully tested releases for our very high availability application. However, we will not require releases of the entire system every 6 months. Backwards compatible application upgrades in between major releases are to be expected, but stuff like new compilers, new emulators, and other earth-moving stuff can come as far apart as a year or so... (: We also hope that it will be possible to find a good balance between Open Source and Commercial-Grade quality releases. Actually, I believe that support is more of an issue than the actual code. I have no reason to suspect that the Open Source release will be that much worse than the commercial release -- if they're not the same, that is. But there has to be a group of designers/testers that packages, certifies, and supports a commercial release to the standards that we need. /Uffe SEAN.H> SEAN.H>Any views on how this will/can/should be reconciled with a more freeform SEAN.H>open source environment? SEAN.H>Rgds, SEAN.H>Sean Hinde SEAN.H> SEAN.H>>Gunilla Hugosson writes: SEAN.H> SEAN.H>> I can just add that the next release is scheduled to November 10. SEAN.H> SEAN.H>>I think I speak for all of us when I say "yahooooo!" Will the SEAN.H>>commercial and open source versions be one and the same from this SEAN.H>>point onwards? SEAN.H> SEAN.H>>Cheers, SEAN.H>>Luke SEAN.H> SEAN.H> SEAN.H> Ulf Wiger, Chief Designer AXD 301 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 seb@REDACTED Mon Oct 4 12:57:03 1999 From: seb@REDACTED (Sebastian Strollo) Date: 04 Oct 1999 12:57:03 +0200 Subject: New release [was Re: Code changing] In-Reply-To: Ulf Wiger's message of "Mon, 4 Oct 1999 11:48:11 +0200 (MET DST)" Message-ID: Luke Gorrie writes: > >>Gunilla Hugosson writes: > >> I can just add that the next release is scheduled to November 10. > >>I think I speak for all of us when I say "yahooooo!" Will the >>commercial and open source versions be one and the same from this >>point onwards? > >>Cheers, >>Luke Yes, this is the (long awaited) release where we have merged open source with the regular development branch. The intention for the future is to keep it that way, i.e. the open source is pretty much the same as the commercial release. (Unfortunately we haven't had the time to improve the build system for this release, so this release will build pretty much as the old open source.) The plan then is to keep Erlang open source, however it will not be open development, meaning no public CVS repository or such (yet, perhaps in the future). However our ambition is of course to include all good fixes to the system in future releases, so just send diffs to erlang-maintainers@REDACTED and we will consider them. I think that the handling of Erlang/OTP is going to evolve over time in cooperation with our paying customers and our open source enthusiasts. We are not keeping anything secret or holding things back for their own sake, we just want to make sure we can guarantee quality in what we release and that we can handle it, configuration management wise. Getting the right balance is hard, but we are reaching a point where we have all the right preconditions for a great future. So keep the discussion going, it helps us figure out what is needed. I am not responsible for commercial Erlang/OTP but as far as I understand it when you pay, you get: binary releases, support and upgrades. (Also there might be special applications that you only get when you pay). I would like to end by quoting our boss Mike Williams (who spoke at the end of the Erlang User Conference) when speaking about the future success of Erlang/OTP, that it is up to us to tell everyone how great it is, so: "Spread the word!" -- Sebastian PS. Someone asked about the Erlang User conference, and yes it was great fun and the proceedings and/or slides will be put up on the web as soon as possible. From oyarzun@REDACTED Tue Oct 5 16:03:36 1999 From: oyarzun@REDACTED (Christian Oyarzun) Date: Tue, 5 Oct 1999 10:03:36 -0400 (EDT) Subject: solaris 7 Message-ID: <199910051403.KAA16632@voyager.wilmington.net> Has anyone got erlang to compile for Sun Solaris 7 on an Ultra Sparc. I am using gcc 2.95.1. It will compile the jam and beam compiler but then when ut tries to compile the libs I get segmentation fault core dumps. I happens with using both jam and beam. --Christian oyarzun@REDACTED From klacke@REDACTED Wed Oct 6 11:37:59 1999 From: klacke@REDACTED (Klacke) Date: Wed, 6 Oct 1999 11:37:59 +0200 (CEST) Subject: io_lib.erl Message-ID: <14331.6263.374280.294894@kricka.bluetail.com> The following diff has proved to be extremely valuable for us at bluetail. The idea is to let io:format's of ports to show a little bit more than #Port. In particular the #Port printouts ere very very good to have for debugging purposes. /klacke cvs diff -rstart io_lib.erl Index: io_lib.erl =================================================================== RCS file: /home/share/erlang/cvsroot/ose/erlang-47.4.1/lib/stdlib/src/io_lib.erl,v retrieving revision 1.1.1.1 retrieving revision 1.3 diff -u -r1.1.1.1 -r1.3 --- io_lib.erl 1999/05/10 13:24:09 1.1.1.1 +++ io_lib.erl 1999/09/22 06:11:21 1.3 @@ -20,7 +20,7 @@ %% File : io_lib.erl %% Author : Robert Virding %% Purpose : Library of useful i/o functions. -%% Revision: $Id: io_lib.erl,v 1.1.1.1 1999/05/10 13:24:09 erlang Exp $ +%% Revision: $Id: io_lib.erl,v 1.3 1999/09/22 06:11:21 magnus Exp $ %% This module is a library of useful i/o functions. It is hoped that the %% functions defined in it are basic enough to be used without modification @@ -88,6 +88,16 @@ indentation(Chars, Current) -> io_lib_format:indentation(Chars, Current). + +fmt_port(P) when node(P) == node() -> + case erlang:port_info(P) of + undefined -> "#Port"; + L -> {value, {id, Id}} = lists:keysearch(id,1,L), + lists:flatten(format("#Port<~p>", [Id])) + end; +fmt_port(P) -> + lists:flatten(format("#Port<~p>", [node(P)])). + %% write(Term) %% write(Term, Depth) %% write(Term, Depth, Pretty) @@ -105,7 +115,7 @@ write(Term, D) when integer(Term) -> integer_to_list(Term); write(Term, D) when float(Term) -> io_lib_format:fwrite_g(Term); write(Atom, D) when atom(Atom) -> write_atom(Atom); -write(Term, D) when port(Term) -> "#Port"; +write(Term, D) when port(Term) -> fmt_port(Term); %% "#Port"; write(Term, D) when pid(Term) -> pid_to_list(Term); write(Term, D) when reference(Term) -> "#Ref"; write(Term, D) when binary(Term) -> "#Bin"; From j.nilsson@REDACTED Wed Oct 6 17:18:53 1999 From: j.nilsson@REDACTED (=?iso-8859-1?Q?J=F6rgen?= Nilsson) Date: Wed, 06 Oct 1999 17:18:53 +0200 Subject: Erlang-projekt Message-ID: <37FB6856.B89CFD10@email.se> Vi arbetar som konsultf?rmedlare och s?ker nu ett antal professionella utvecklare med gedigen erfarenhet av ERLANG till internationella projekt. Om intresse, kontakta oss, asap, f?r mer info. Mvh J Nilsson From tobbe@REDACTED Wed Oct 6 17:30:09 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 07 Oct 1999 01:30:09 +1000 Subject: Erlang-projekt In-Reply-To: =?iso-8859-1?q?J=F6rgen?= Nilsson's message of "Wed, 06 Oct 1999 17:18:53 +0200" References: <37FB6856.B89CFD10@email.se> Message-ID: It could be a good idea to write in English to this list since we have lots of non-swedish people reading it. A rough translation follows: > Vi arbetar som konsultf?rmedlare och s?ker nu ett antal professionella We are looking for a number of professional > utvecklare med gedigen erfarenhet av ERLANG till internationella developers with good experience from ERLANG to international > projekt. Om intresse, kontakta oss, asap, f?r mer info. projects. If interested, contact us, asap, for more information. Cheers /Tobbe -- Torbj?rn T?rnkvist tobbe@REDACTED ph: +61 3 9925 4089 fax:+61 3 9925 4094 Software Engineering Research Centre (SERC) From david_schere@REDACTED Wed Oct 6 19:08:04 1999 From: david_schere@REDACTED (David Schere) Date: Wed, 6 Oct 1999 10:08:04 -0700 (PDT) Subject: C interface example Message-ID: <19991006170804.4244.rocketmail@web1501.mail.yahoo.com> Hello, I am looking for coding examples of how to communicate with an erlang program in C. I have studied the header files in the erlang/usr/include directory and have got a general idea of what is required. Where can I find some example code ? I have an existing Python application that I want to bolt into an erlang app and was going to write a language binding from python to erlang. Thanks in advance, David Schere ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From vances@REDACTED Wed Oct 6 23:04:20 1999 From: vances@REDACTED (Vance Shipley) Date: Wed, 6 Oct 1999 17:04:20 -0400 Subject: C interface example In-Reply-To: <19991006170804.4244.rocketmail@web1501.mail.yahoo.com> Message-ID: <004901bf103e$5bf45820$0abdc5c0@desk.motivity.ca> } I am looking for coding examples of how to } communicate with an erlang program in C. ... David, I have just moved one of my applications off the Interface Generator (ig-1.7.7) and on to a direct message pipe using the erl_interface libraries. There are two basic ways, as I see it, to link external programs to Erlang/OTP; RPC and message passing. I have opted for the latter. For the former you use IG or IC, or implement your own using multiple pipes like below. The following example code shows how to get a pipe up between C and Erlang/OTP and pass messages across it. I haven't figured out yet how to get the Erlang/OTP node to connect to a listening C node. Can anyone give us a hand with that? -Vance Motivity Telecom Inc. #include #include #include #include #include #include #include "erl_interface.h" #include "ei.h" #define PORT 6666 /* tcp port we listen on */ #define SELF(fd) erl_mk_pid(erl_thisnodename(), fd, 0, erl_thiscreation()) extern const char *erl_thisnodename(void); extern short erl_thiscreation(void); int sockfd, epmdfd; /* file descriptor of socket */ void endonsignal(int); /* handler for termination signals */ void endonsignal(int signo) { printf("termination on signal [%d]\n", signo); erl_close_connection(sockfd); erl_close_connection(epmdfd); } main() { struct in_addr addr; struct sockaddr_in sin; ETERM *arr[2], *answer, *cmsg, *pid; int rc; char buf[BUFSIZ]; ErlMessage emsg; char **names; int count; int i; ErlConnect remote; int opt; signal(SIGINT, endonsignal); /* set unbuffered stdout */ setvbuf (stdout, NULL, _IONBF, NULL); /* initialize the erl_eterm module */ erl_init(NULL, 0); /* This is the short host name initialization routine */ printf("Initializing ..."); if(!erl_connect_init(69, "My Cookie String", 0)) erl_err_sys("erl_connect_init"); printf(" done.\n"); printf("node=%s, host=%s, alive=%s, creation=%d\n ", erl_thisnodename(), erl_thishostname(), erl_thisalivename(), erl_thiscreation()); /* This is the long host name initialization routine */ /* printf("Initializing ..."); addr.s_addr = inet_addr("127.0.0.1"); if(!erl_connect_xinit("foo", "cnode", "cnode@REDACTED", &addr, "My Cookie String", 0)) erl_err_sys("erl_connect_xinit"); printf(" done.\n"); */ /* This is the short host name outgoing connect routine */ printf("Connecting ..."); if((sockfd = erl_connect("erlnode@REDACTED")) < 0) erl_err_sys("erl_connect"); printf(" done.\n"); /* This is the long host name outgoing connect routine */ /* printf("Connecting ..."); if((sockfd = erl_xconnect(&addr, "erlnode")) < 0) erl_err_sys("erl_xconnect"); printf(" done.\n"); */ /* This is the routine for listening for incoming connections memset((char *) &sin, 0, sizeof(sin)); sin.sin_family = AF_INET; sin.sin_addr.s_addr = htonl(INADDR_ANY); sin.sin_port = htons(PORT); if((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) erl_err_sys("socket"); if(bind(sockfd, (struct sockaddr *) &sin, sizeof(sin)) <0) erl_err_sys("bind"); if(listen(sockfd, 1) == -1) erl_err_sys("listen"); */ /* make the socket non-blocking */ /* opt = fcntl(sockfd, F_GETFL, 0); if (fcntl(sockfd, F_SETFL, opt | O_NONBLOCK) == -1) erl_err_sys("fcntl"); */ /* This routine publishes our port number with epmd if((epmdfd = erl_publish(PORT)) == -1) erl_err_sys("erl_publish"); memset((char *) &remote, 0, sizeof(remote)); if(erl_accept(sockfd, &remote) == ERL_ERROR) erl_err_sys("accept"); */ /* register our name globally */ pid = SELF(sockfd); if(erl_global_register(sockfd, "cnode", pid) != 0) erl_err_sys("erl_global_register"); /* find registered names on node */ names = erl_global_names(sockfd, &count); if(names == NULL) erl_err_sys("erl_global_names"); else if(count) { printf("Globally registered names:\n"); for(i=0; i < count; i++) printf(" %s\n", names[i]); } free(names); /* send a message */ /* arr[0] = SELF(sockfd); arr[1] = erl_mk_atom("Hello world"); cmsg = erl_mk_tuple(arr, 2); if(erl_reg_send(sockfd, "foo", cmsg) == 0) erl_err_sys("erl_reg_send"); erl_free_term(cmsg); */ /* Receive a message */ while(1) { rc = erl_receive_msg(sockfd, buf, BUFSIZ, &emsg); switch(rc) { case ERL_TICK: printf("ERL_TICK received\n"); break; case ERL_MSG: printf("ERL_MSG received\n"); arr[0] = erl_mk_atom("goodbye"); arr[1] = erl_element(1, emsg.msg); answer = erl_mk_tuple(arr, 2); erl_send(sockfd, arr[1], answer); erl_free_term(answer); erl_free_term(emsg.msg); erl_free_term(emsg.to); break; case ERL_ERROR: erl_err_sys("erl_receive_msg"); default: printf("unknown return value [%d]\n", rc); break; } } } From tobbe@REDACTED Wed Oct 6 23:45:59 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 07 Oct 1999 07:45:59 +1000 Subject: C interface example In-Reply-To: "Vance Shipley"'s message of "Wed, 6 Oct 1999 17:04:20 -0400" References: <004901bf103e$5bf45820$0abdc5c0@desk.motivity.ca> Message-ID: > I haven't figured out yet how to get the Erlang/OTP node > to connect to a listening C node. Can anyone give us a > hand with that? If I remember correctly you create a socket, bind an address to it, and then tells epmd about it with erl_publish(PortNo). You then listen to the socket (e.g using select). To connect from Erlang just send a message, e.g: {hello,foo@REDACTED} ! 42 Your select should now release so you can do an erl_accept(SockFd) and you'll receive the message '42' sent to the "registered process" 'hello' on you node ('foo@REDACTED'). NB: You have to send to a {RegProc,Node} address since you can't create a valid pid from within Erlang. However, if you connect from C to Erlang you can create and send valid pids from C that can be used from Erlang (using erl_mk_pid() ). It was a long time since I tried this so it may note be fully correct. Let us know when you get it to work, and perhaps add a FAQ entry at wikie.vegetable.org Cheers /Tobbe From vances@REDACTED Thu Oct 7 05:56:13 1999 From: vances@REDACTED (Vance Shipley) Date: Wed, 6 Oct 1999 23:56:13 -0400 Subject: C interface example In-Reply-To: Message-ID: <004a01bf1077$e61e95e0$0abdc5c0@desk.motivity.ca> Tobbe, Interesting. I hadn't noticed that you can send using: {RegProc,Node} ! Msg I have been using: global:registered_name(Regproc} ! Msg Now I like the simplicity and elegance of your syntax but it forces me to know the node that the process runs on. Why would this be? -Vance } from Erlang just send a message, e.g: {hello,foo@REDACTED} ! 42 } Your select should now release so you can do an erl_accept(SockFd) } and you'll receive the message '42' sent to the "registered process" } 'hello' on you node ('foo@REDACTED'). NB: You have to send to a } {RegProc,Node} address since you can't create a valid pid from } within Erlang. However, if you connect from C to Erlang you } can create and send valid pids from C that can be used from } Erlang (using erl_mk_pid() ). From tobbe@REDACTED Thu Oct 7 06:17:50 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 07 Oct 1999 14:17:50 +1000 Subject: C interface example In-Reply-To: "Vance Shipley"'s message of "Wed, 6 Oct 1999 23:56:13 -0400" References: <004a01bf1077$e61e95e0$0abdc5c0@desk.motivity.ca> Message-ID: > Now I like the simplicity and elegance of your syntax > but it forces me to know the node that the process runs on. > Why would this be? Well, here is the possible scenarios: 1. The part of your application which is written in C take contact with the Erlang part. 2. The part of your application which is written in Erlang take contact with the C part. In both cases you have to send messages to a registered process since you (initially) don't know any PIDs. This is for example what erl_rpc()/rpc:call() does (it calls the 'rex' process). You also have to know which Erlang node you want to talk with since you may have several Erlang nodes running on the same host. NB: Using the erl_interface library for communication means that you talk the Erlang distribution protocol. However, the C part won't show up in the result from the nodes/0 BIF (the C-node is said to be a hidden node). This is because some of the Erlang libraries, which implements varius distributed features, relies in being able to talk to all connected nodes. A C-node doesn't (and shouldn't) have to implement all those features, thus it won't show up in the result from nodes/0. Cheers /Tobbe From mbj@REDACTED Thu Oct 7 08:31:00 1999 From: mbj@REDACTED (Martin Bjorklund) Date: Thu, 07 Oct 1999 08:31:00 +0200 Subject: C interface example In-Reply-To: Your message of "Wed, 6 Oct 1999 23:56:13 -0400" <004a01bf1077$e61e95e0$0abdc5c0@desk.motivity.ca> References: <004a01bf1077$e61e95e0$0abdc5c0@desk.motivity.ca> Message-ID: <19991007083100I.mbj@bluetail.com> "Vance Shipley" wrote: > Tobbe, > > Interesting. I hadn't noticed that you can send using: > > {RegProc,Node} ! Msg > > I have been using: > > global:registered_name(Regproc} ! Msg > > Now I like the simplicity and elegance of your syntax > but it forces me to know the node that the process runs on. > Why would this be? These are two different mechanisms. The former sends a message to the _locally_ registered process RegProc at Node, and the latter sends a message to the _globally_ registered process Regproc. Note that the same process can have a local name and/or a global name, and they need not be the same. In this case, the first mechanism might be a good candidate because you'll have to know the node name in order to set up a connection to the node. When the connection has been set up, you can send pids between the nodes. /martin From cesarini@REDACTED Thu Oct 7 15:53:16 1999 From: cesarini@REDACTED (Francesco Cesarini) Date: Thu, 7 Oct 1999 15:53:16 +0200 (MET DST) Subject: EUC'99 (fwd) Message-ID: Some one had asked for the Erlang User conference proceedings... Just received this email which might be of interest... Rgds, Francesco --- Subject: EUC'99 Dear Erlang friends, Printed material an slides from the Fifth International Erlang/OTP User Conference is now available from http://www.ericsson.se/cslab/projects/euc99/ Best regards Bjarne D?cker From stone@REDACTED Thu Oct 7 16:32:25 1999 From: stone@REDACTED (Magnus Stenman) Date: Thu, 07 Oct 1999 16:32:25 +0200 Subject: Erlang .debs Message-ID: <37FCAEF9.A82C061@hkust.se> Anyone know where I can find Erlang as debian .deb packages? -- Magnus Stenman mailto:stone@REDACTED http://www.hkust.se ...all in all, it's just another rule in the firewall. /Ping Flood From quintela@REDACTED Thu Oct 7 17:37:25 1999 From: quintela@REDACTED (Juan J. Quintela) Date: 07 Oct 1999 17:37:25 +0200 Subject: Erlang .debs In-Reply-To: Magnus Stenman's message of "Thu, 07 Oct 1999 16:32:25 +0200" References: <37FCAEF9.A82C061@hkust.se> Message-ID: >>>>> "Magnus" == Magnus Stenman writes: Magnus> Anyone know where I can find Erlang as debian .deb Magnus> packages? They are in the official version, 2.2, also know as potato in the debian mirror near you :-). I don't know if somebody has compiled it for slink. Later, Juan. -- In theory, practice and theory are the same, but in practice they are different -- Larry McVoy From david_schere@REDACTED Thu Oct 7 20:41:48 1999 From: david_schere@REDACTED (David Schere) Date: Thu, 7 Oct 1999 11:41:48 -0700 (PDT) Subject: linking problems while trying to call erlang from C Message-ID: <19991007184148.22194.rocketmail@web1505.mail.yahoo.com> I am having linking problems using the *.rpm binary distribution of erlang for RedHat Linux. I am trying to link against liberl_interface.a and I can't get any symbols to resolve. I used the 'nm' command to spit out the symbol names and it seems as if everything is ok. ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From mskow@REDACTED Fri Oct 8 00:13:36 1999 From: mskow@REDACTED (Michael Skowronski) Date: Thu, 7 Oct 1999 18:13:36 -0400 (EDT) Subject: some basic questions Message-ID: is there support in any of the libraries/contributions for multi-node message delivery, similar to those found in GCS type toolkits or does this abstraction have to be built? also, if i understand things, the order in which the message patterns are placed after the ``receive'' keyword is the order that the node will get the message, regardless of the actual order the messages came in. is this right? next, from the literature i gather there aren't any gurantees for message delivery (no way to know if a message was consumed or not) -- is there any work being done on this? finally, if a node fails, what can one assume about current processes at that node? i guess i'm a little unclear about the relationship between message delivery and failure notofication/detetection. thanks. Mike P.S. if anyone is willing to share success/horror stories w/ erlang (outside of those at ericson) for commerical projects, i'd be very appreciative. From tobbe@REDACTED Fri Oct 8 03:28:12 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 08 Oct 1999 11:28:12 +1000 Subject: some basic questions In-Reply-To: Michael Skowronski's message of "Thu, 7 Oct 1999 18:13:36 -0400 (EDT)" References: Message-ID: Hi ! > is there support in any of the libraries/contributions for multi-node > message delivery, similar to those found in GCS type toolkits or does this > abstraction have to be built? I dont' know what GCS is but here are the relevant man-pages (you'll also find them at the web page under Documentation): rpc, pg, pg2, global, global_group, pool also interesting: net_adm, net_kernel, auth I know that there was some work done recently where lots of ISIS "concepts" were implemented in Erlang. Don't know what happend with it though... (Klacke ?) > also, if i understand things, the order in > which the message patterns are placed after the ``receive'' keyword is the > order that the node will get the message, regardless of the actual order > the messages came in. is this right? No, the first message in the "message-queue" which match any of the receive clauses will be taken. The test is aginst the receive clauses is performed top-down, i.e assume you have three messages in your message-queue (1,2,3) and three receive clauses in your receive statement (a,b,c) then this will happend: + Try and match message 1 against: - message a - message b - message c + Try and match message 2 against: - message a - message b - message c + Try and match message 3 against: - message a - message b - message c As soon you get a match, select that receive clause. If no match continue to be suspended. See the code and example at the end of this mail. > next, from the literature i gather > there aren't any gurantees for message delivery (no way to know if a > message was consumed or not) Correct ! To elaborate a little: Within a node, the only causes for failing to deliver a message are: 1. Programming error (send message to wrong or non-existant process) 2. No memory left in the system (but then you must have some other really serious programming faults in your programs) Between nodes, you have the same problem as for any distributed system. If the receiving system crashes or the network is cut off, you can't know whether your messages was delivered or not. > -- is there any work being done on this? There has been lots of work done for the general problems around distributed systems/algoritms. > finally, if a node fails, what can one assume about current processes at > that node? Again, there is no way to tell whether is was the Node or the Network which went down. Cheers /Tobbe ------------------------------------------------------------- %%% The code %%% -module(test). -export([start/0, go/0]). start() -> spawn(?MODULE, go, []). go() -> io:format("Going to sleep !~n"), sleep(15), io:format("Woke up !~n"), recv(). recv() -> receive {a,Msg} -> io:format("GOT: ~p~n",[Msg]); {b,Msg} -> io:format("GOT: ~p~n",[Msg]) end. sleep(Sec) -> receive after Sec*1000 -> true end. ------------------------------------------------- %%% Test Run %%% 1> c(test). {ok,test} 2> P=test:start(). Going to sleep ! <0.34.0> 3> P!{b,"B"}. {b,"B"} 4> P!{a,"A"}. {a,"A"} Woke up ! GOT: "B" 5> ------------------------------ From klacke@REDACTED Fri Oct 8 09:46:23 1999 From: klacke@REDACTED (Klacke) Date: Fri, 8 Oct 1999 09:46:23 +0200 (CEST) Subject: some basic questions In-Reply-To: References: Message-ID: <14333.41295.178009.45107@kricka.bluetail.com> Michael Skowronski writes: > is there support in any of the libraries/contributions for multi-node > message delivery, About two/three years ago I was really interested in the ISIS protocols developed by a group of researchers at Cornell with Ken Birman. These protocols support a concept of process groups and something they call "virtual syncronicity". The basic idea is that a group of processes is formed and named, messages sent to the group by means of the ISIS protocols can have different delivery semantics. The most interesting (and also efficiently implementable) is that "all members in the group get all messages in the same order". They also get all join_group, leave_group, member_crashed, message sin the same order. This basic mechanism, (which as I said is possible to implement efficiently) Can be used as the basic abstraction to build other stuff, such as transaction managers etc. I had two students from Uppsala that implemented the ISIS protocols in Erlang and did some experiments with it. However, and here comes the bad news. It turned out that the API they delivered (which was pretty similar to the classic ISIS API) wasn't that much easier to use than plain distributed Erlang. The focus of the work was ease of use and correctness. It is very very very hard to write 100 % correct fault tolerant distributed applications and the ISIS abstraction is the only one I've ever seen that raises above simple message passing/rpc To use I.e sun RPC, Corba or even distributed Erlang to build distributed apps is a bit low level. We did a couple of sample applications using the Erlang ISIS API as well as normal distributed Erlang, and it turned out that the ISIS apps weren't any easier to write or understand, so the idea was dropped. I'm not the only one who dropped the idea(s) from the Cornell group. The traffic now in comp.XX.isis is almost zero. However, I still think that we need better abstractions than the ones we have today in order to build distributed apps. (Note, here iI'm not talking about loosely loosely coupled apps like, nntp or www, but rather fault tolerant applications with hot standby's and such. The API provided by distributed erlang, mnesia, global, gen_server and friends is much much better than i.e a CORBA based api, but it's still too low level. Just my 5 ?re. Cheers /klacke Claes Wikstr?m Tel: +46 (0)8 692 22 09 Bluetail AB Email: klacke@REDACTED Hantverkargatan 78 WWW: http://www.bluetail.com SE-112 38 Stockholm, SWEDEN From mskow@REDACTED Fri Oct 8 17:59:20 1999 From: mskow@REDACTED (Michael Skowronski) Date: Fri, 8 Oct 1999 11:59:20 -0400 (EDT) Subject: some basic questions In-Reply-To: Message-ID: On 8 Oct 1999, Torbjorn Tornkvist wrote: thanks for clearing up things for me :) > > Hi ! > I dont' know what GCS is but here are the relevant man-pages > (you'll also find them at the web page under Documentation): Group Communication Services -- it's an approach to distribution where the middleware acts as a sort of container for process or object groups; messages are sent to the group and the members receive the messages with various properties enforced like message ordering and the like. Mike From mskow@REDACTED Fri Oct 8 18:24:49 1999 From: mskow@REDACTED (Michael Skowronski) Date: Fri, 8 Oct 1999 12:24:49 -0400 (EDT) Subject: some basic questions In-Reply-To: <14333.41295.178009.45107@kricka.bluetail.com> Message-ID: thank you so much for your information! i put some comments below. On Fri, 8 Oct 1999, Klacke wrote: > About two/three years ago I was really interested in the > ISIS protocols developed by a group of researchers at Cornell > with Ken Birman. These protocols support a concept of > process groups and something they call "virtual syncronicity". i'm familiar w/ ISIS. > > The basic idea is that a group of processes is formed and named, > messages sent to the group by means of the ISIS protocols > can have different delivery semantics. The most interesting (and > also efficiently implementable) is that "all members in the > group get all messages in the same order". They also get all > join_group, leave_group, member_crashed, message sin the same > order. > > This basic mechanism, (which as I said is possible to implement > efficiently) Can be used as the basic abstraction to build > other stuff, such as transaction managers etc. > > I had two students from Uppsala that implemented the ISIS > protocols in Erlang and did some experiments with it. > > However, and here comes the bad news. It turned out that > the API they delivered (which was pretty similar to the > classic ISIS API) wasn't that much easier to use than > plain distributed Erlang. that's unfortunate :( > > The focus of the work was > ease of use and correctness. It is very very very hard > to write 100 % correct fault tolerant distributed applications absolutely, which is why we're trying to find a solution that already exists! since we are a commercial company, we need to find a solution that's already there rather than create one, even if that solution isn't the perfect one (if that ever exists). thus our interest in erlang technologies. > > To use I.e sun RPC, Corba or even distributed Erlang to build > distributed apps is a bit low level. > > We did a couple of sample applications using the Erlang ISIS > API as well as normal distributed Erlang, and it turned out that > the ISIS apps weren't any easier to write or understand, so the > idea was dropped. I'm not the only one who dropped the idea(s) > from the Cornell group. The traffic now in comp.XX.isis is almost > zero. i believe, the same group is working on a new toolkit called Ensemble. from what i understand, the ISIS toolkit took a ``monolithic'' type approach and offered pre-defined and limited choices as to ordering and membership -- Ensemble i think has a sort of an OO approach and is more open, extensible and composible. have you had a look at Ensemble? > > However, I still think that we need better abstractions than > the ones we have today in order to build distributed apps. yes, i agree. > (Note, here iI'm not talking about loosely loosely coupled > apps like, nntp or www, but rather fault tolerant applications > with hot standby's and such. The API provided by distributed erlang, > mnesia, global, gen_server and friends is much much better than > i.e a CORBA based api, but it's still too low level. Mike From tobbe@REDACTED Thu Oct 7 23:34:51 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 08 Oct 1999 07:34:51 +1000 Subject: linking problems while trying to call erlang from C In-Reply-To: David Schere's message of "Thu, 7 Oct 1999 11:41:48 -0700 (PDT)" References: <19991007184148.22194.rocketmail@web1505.mail.yahoo.com> Message-ID: Can you give us a little trace of your call to gcc ? And perhaps the result from: uname ls -l ${ERLANG}/usr/lib Cheers /Tobbe From vances@REDACTED Sat Oct 9 00:10:51 1999 From: vances@REDACTED (Vance Shipley) Date: Fri, 8 Oct 1999 18:10:51 -0400 Subject: some basic questions In-Reply-To: Message-ID: <000201bf11d9$fb63a450$0abdc5c0@desk.motivity.ca> } is there support in any of the libraries/contributions for multi-node } message delivery, similar to those found in GCS type toolkits or does this Look at pg2(Module). } abstraction have to be built? also, if i understand things, the order in } which the message patterns are placed after the ``receive'' keyword is the } order that the node will get the message, regardless of the actual order } the messages came in. is this right? next, from the literature i gather I wouldn't agree with your semantics, the node receives the messages in the order it receives them. A process receives them in the order it pulls them out of the mailbox. The first receive clause done for a message of the form {foo, Bar} will succeed if a message of that pattern exists. If the first reeceive clause encountered is one which accepts anything (e.g. Msg) then you will get them in the order they were received. } there aren't any gurantees for message delivery (no way to know if a } message was consumed or not) -- is there any work being done on this? This has been one of my concerns I look forward to other's comments. } finally, if a node fails, what can one assume about current processes at } that node? i guess i'm a little unclear about the relationship between } message delivery and failure notofication/detetection. If you put them under an appropriately constructed supervision scheme you can assume they have been recreated at other nodes. } P.S. if anyone is willing to share success/horror stories w/ erlang } (outside of those at ericson) for commerical projects, i'd be very } appreciative. Love to. -Vance From etxuwig@REDACTED Sat Oct 9 13:13:29 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Sat, 9 Oct 1999 13:13:29 +0200 (MET DST) Subject: some basic questions In-Reply-To: <000201bf11d9$fb63a450$0abdc5c0@desk.motivity.ca> Message-ID: On Fri, 8 Oct 1999, Vance Shipley wrote: vances>} there aren't any gurantees for message delivery (no way to know vances>} if a message was consumed or not) vances>} -- is there any work being done on this? vances> vances>This has been one of my concerns I look forward to other's comments. Well, there is a new monitor() function in OTP R5B, which will also be in the next Open Source release (of course). It allows a sending process to monitor the receiving process; if the process is alive before you sent the message, and keeps on kicking afterwards, it got the message. Now, in R5B, the monitor() function didn't work across node limits, so one had to rely on a request-reply dialog protected by a timeout clause. Of course, even using the monitor() function, you'll probably want a reply message to make sure that the receiving process go the message -- even for other reasons, such as (simple) flow control. To clarify: Erlang does guarantee that the message is delivered *if* the receiver is alive, and there's a viable path between the sender and receiver (don't remember if the spec guarantees this, but the current implementation does, for all practical purposes.) It is still quite safe to use a cast if you combine this with a recovery mechanism using query semantics. That is, if the receiver crashes, it will ask what's been going on when it restarts. After that, it can receive casts notifying it of new events. /Uffe Ulf Wiger, Chief Designer AXD 301 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 per@REDACTED Sat Oct 9 15:13:15 1999 From: per@REDACTED (Per Hedeland) Date: Sat, 9 Oct 1999 15:13:15 +0200 (MET DST) Subject: some basic questions Message-ID: <199910091313.PAA09037@super.du.uab.ericsson.se> Ulf Wiger wrote: > >On Fri, 8 Oct 1999, Vance Shipley wrote: > >vances>} there aren't any gurantees for message delivery (no way to know >vances>} if a message was consumed or not) >vances>} -- is there any work being done on this? >vances> >vances>This has been one of my concerns I look forward to other's comments. > >Well, there is a new monitor() function in OTP R5B, which will also be in >the next Open Source release (of course). It allows a sending process to >monitor the receiving process; if the process is alive before you sent the >message, and keeps on kicking afterwards, it got the message. Hm, unless I'm missing something, monitor/2 is "just" a generalized (but so far only applies to pids) and uni-directional version of link/1 (which is bi-directional) - plus monitor produces normal messages rather than EXIT signals. And of course link/1 has been around since forever, and has worked across node limits ever since nodes came into existence as far as I know (it predates distributed Erlang). >To clarify: Erlang does guarantee that the message is delivered *if* the >receiver is alive, and there's a viable path between the sender and >receiver (don't remember if the spec guarantees this, but the current >implementation does, for all practical purposes.) Yes, or to simplify it even further: "Delivery is guaranteed if nothing breaks" - and if something breaks, you will find out provided you've used link/1 (or monitor/2, hopefully). I.e. when using link, you will get an EXIT signal not only if the linked process dies, but also if the entire remote node crashes, or the network is broken, or if any of these happen *before* you do the link. It seems this issue of "guaranteed delivery" comes up every now and then, but I've never managed to find out exactly what it is those that are asking for it actually want: - A guarantee that the message is put into the receiver's input queue? But if the receiver dies before extracting it from there, that guarantee is useless, as the message is lost anyway. - A guarantee that the receiver extracts the message from its input queue? Well, besides the obvious problem that depending on how the receiver is written, even if it lives happily ever after it may *never* extract that particular message, it suffers from a variant of the previous problem: Even if you "know" that the receiver has "consumed" the message, it may die before acting on it in any way, and then again it may as well never have been sent. - A guarantee that the receiver actually *processes* the message? Just kidding of course, hopefully it's obvious to everyone that the only way to obtain such a guarantee, regardless of what programming and communication system you use, is that the receiver is programmed to send an explicit acknowledgment when the processing is complete (of course this may be hidden below an abstraction such as RPC, but the fundamental principle holds). Add to this that any guarantee would *have* to entail some form of ack from the remote in at least a distributed system, even if it wasn't directly visible to the programmer. E.g. you could have '!' block until the ack comes back from the remote saying that the message had progressed however far you required - i.e. synchronous communication of sorts. But this would penalize those that *don't* require the "guarantee" and *want* asynchronous communication, and while it's trivial to implement synchronous communication on top of an asynchronous mechanism, doing the opposite is a pain (typically calls for dedicated "messenger processes" that do the sending for you). So, depending on your requirements, Erlang offers you *at least* these levels of "guarantee" (possibly substituting "monitor" for "link"): Super-safe: Receiver sends ack after processing; sender links, sends, waits for ack or EXIT => Sender knows, for each message, whether it was fully processed or not. (The link only needs to be done once, of course). Medium-safe: Receiver doesn't send acks; Sender links, sends message(s) => an EXIT signal informs the sender that some messages may never have been processed. Pretty-safe: Receiver doesn't send acks; sender sends messages.:-) Plus of course any number of combinations of these (e.g. receiver sends ack not after each message but at some critical points in the processing). And don't forget that the *really* fault-tolerant OTP supervision mechanisms were implemented with these "simple" "unsafe" primitives.:-) --Per Hedeland per@REDACTED PS You might want to look for parallels in the somewhat successful world of Internet protocols: IP ought to be a problem, since it doesn't "guarantee delivery"; nevertheless it was possible to build the "reliable" TCP on top of it. And if you think TCP "guarantees delivery" (which most people probably do), then so does Erlang...:-) From svg@REDACTED Sun Oct 10 19:17:25 1999 From: svg@REDACTED (svg@REDACTED) Date: Sun, 10 Oct 1999 23:17:25 +0600 Subject: What is wrong? Help please. Message-ID: <19991010231725N.svg@disney.surnet.ru> I'm working on simple erlang alarm monitor with Java front-end, but jive always crushs with same reason on the same function after 2-10 minutes of work. Below is a part of erlang-crush.dump. My environment is RedHat Linux 6.0 and erlang-47.4.1. Sun Oct 10 22:53:18 1999 Slogan: <0.184.0>: Overrun heap heap start 0x082f6c08, heap end 0x082f946c, size 0x00000a18 Erlang (JAM) emulator version 47.4.1 Compiled on Tue Sep 14 21:51:00 1999 Process Information -------------------------------------------------- ...skipped... -------------------------------------------------- <0.183.0> Waiting. Registered as: jive_server Spawned as: jive:jive_server_boot/0 Current call: jive:jive_server_loop/3 Link list: [<0.196.0>,<0.184.0>] Reductions=30 stack=87 heap=89 old_heap_sz=0 Heap unused=57 OldHeap unused=0 -------------------------------------------------- <0.184.0> Running. Spawned as: proc_lib:init_p/5 Current call: jive:int_to_bytes/1 Link list: [<0.196.0>,<0.183.0>,<0.189.0>,<0.188.0>] Dictionary: [{'$initial_call',{jive,listen_boot,[14000]}},{'$ancestors',[ams_sup,<0.174.0>]}] Reductions=133648 stack=375 heap=2584 old_heap_sz=2584 Heap unused=-1 OldHeap unused=2584 -------------------------------------------------- <0.185.0> Waiting. Registered as: alarm_reckeeper Spawned as: proc_lib:init_p/5 Current call: gen_server:loop/6 Link list: [<0.196.0>,<0.186.0>,<0.175.0>] Dictionary: [{'$initial_call',{gen,init_it,[gen_server,<0.175.0>,<0.175.0>,{local,alarm_reckeeper},alarm_reckeeper,[],[]]}},{'$ancestors',[ams_sup,<0.174.0>]}] Reductions=28356 stack=87 heap=377 old_heap_sz=377 Heap unused=11 OldHeap unused=377 -------------------------------------------------- <0.186.0> Waiting. Spawned as: alarm_observer:start/1 Current call: gen:wait_resp/4 Link list: [<0.185.0>] Dictionary: [{random_seed,{25880,17513,21457}}] Reductions=20319 stack=231 heap=610 old_heap_sz=377 Heap unused=467 OldHeap unused=377 -------------------------------------------------- <0.188.0> Waiting. Spawned as: proc_lib:init_p/5 Current call: inet_tcp:listen_loop/4 Link list: [<0,152>,<0.184.0>] Dictionary: [{'$initial_call',{inet_tcp,listen_mgr,[<0.184.0>,<<0,355>>,{sock,[],{0,0,0,0},14000,true,[{reuseaddr,true},{packet,4},{active,true}],[],[],[],undefined,undefined}]}},{'$ancestors',[<0.184.0>,ams_sup,<0.174.0>]}] Reductions=89 stack=87 heap=233 old_heap_sz=55 Heap unused=98 OldHeap unused=55 -------------------------------------------------- <0.189.0> Waiting. Spawned as: proc_lib:init_p/5 Current call: inet_tcp:socket_loop/3 Link list: [<0,153>,<0.184.0>] Dictionary: [{'$initial_call',{inet_tcp,accept_mgr,[<0.184.0>,<<0,357>>,2,{sock,[],{0,0,0,0},14000,true,[{reuseaddr,true},{packet,4},{active,true}],[],[],[],undefined,undefined},infinity]}},{'$ancestors',[<0.188.0>,<0.184.0>,ams_sup,<0.174.0>]}] Reductions=2407 stack=87 heap=1597 old_heap_sz=987 Heap unused=1153 OldHeap unused=987 -------------------------------------------------- <0.191.0> Waiting. Spawned as: erlang:apply/2 Current call: io:wait_io_reply/2 Link list: [<0.22.0>] Reductions=14 stack=87 heap=34 old_heap_sz=0 Heap unused=2 OldHeap unused=0 -------------------------------------------------- <0.196.0> Waiting. Spawned as: proc_lib:init_p/5 Current call: alarm_jive:loop/2 Link list: [<0.185.0>,<0.184.0>,<0.183.0>] Dictionary: [{'$initial_call',{alarm_jive,start,[0,{pidid,0}]}},{'$ancestors',[<0.192.0>,<0.184.0>,ams_sup,<0.174.0>]}] Reductions=2947 stack=87 heap=377 old_heap_sz=377 Heap unused=166 OldHeap unused=377 -------------------------------------------------- <0.197.0> Waiting. Spawned as: proc_lib:init_p/5 Current call: gen_tcp:call/2 Link list: [<0.198.0>] Dictionary: [{'$initial_call',{jive,listen,[{socket,<0.188.0>,<0,152>,inet_tcp}]}},{'$ancestors',[<0.194.0>,<0.192.0>,<0.184.0>,ams_sup,<0.174.0>]}] Reductions=7 stack=87 heap=34 old_heap_sz=34 Heap unused=17 OldHeap unused=34 -------------------------------------------------- <0.198.0> Waiting. Spawned as: proc_lib:init_p/5 Current call: inet_tcp:sync_cmd/4 Link list: [<0,158>,<0.197.0>] Dictionary: [{'$initial_call',{inet_tcp,accept_mgr,[<0.197.0>,<<0,415>>,2,{sock,[],{0,0,0,0},14000,true,[{reuseaddr,true},{packet,4},{active,true}],[],[],[],undefined,undefined},infinity]}},{'$ancestors',[<0.188.0>,<0.184.0>,ams_sup,<0.174.0>]}] Reductions=11 stack=142 heap=89 old_heap_sz=0 Heap unused=1 OldHeap unused=0 -------------------------------------------------- Port Information -------------------------------------------------- <1> Connected: <0.2.0> Links: <0.2.0> Port controls linked-in driver: efile -------------------------------------------------- <3> Connected: <0.16.0> Links: <0.16.0> Port controls linked-in driver: efile -------------------------------------------------- <4> Connected: <0.19.0> Links: <0.19.0> Port controls linked-in driver: tty_sl -c -------------------------------------------------- <152> Connected: <0.188.0> Links: <0.188.0> Port controls linked-in driver: tcp_inet -------------------------------------------------- <153> Connected: <0.189.0> Links: <0.189.0> Port controls linked-in driver: tcp_inet -------------------------------------------------- <158> Connected: <0.198.0> Links: <0.198.0> Port controls linked-in driver: tcp_inet -------------------------------------------------- <169> Connected: <0.176.0> Links: <0.176.0> Port controls linked-in driver: efile -------------------------------------------------- <172> Connected: <0.83.0> Links: <0.83.0> Port controls linked-in driver: efile -------------------------------------------------- Internal Table Information -------------------------------------------------- Hash Table(atom_tab), size(3203), used(2532), objs(4945), depth(7) Index Table(atom_tab), size(5000), limit(65536), used(4945), rate(100) Atom space 53612/65544 Hash Table(module_code), size(97), used(72), objs(115), depth(4) Index Table(module_code), size(120), limit(65536), used(115), rate(10) Hash Table(export_list), size(1597), used(1250), objs(2472), depth(7) Index Table(export_list), size(2500), limit(65536), used(2472), rate(100) Hash Table(process_reg), size(47), used(32), objs(44), depth(4) Allocated binary 6557 Allocated by process_desc 20160 Allocated by proc_bin_desc 9600 Allocated by table_desc 2080 Allocated by link_desc 3200 Allocated by atom_desc 99200 Allocated by export_desc 69440 Allocated by module_desc 3840 Allocated by preg_desc 960 -------------------------------------------------- Distribution Information Not alive Loaded Modules Information -------------------------------------------------- init 7438 erl_prim_loader 4556 erlang 2459 error_handler 639 heart 1947 error_logger 2197 gen_event 5294 gen 1840 proc_lib 3358 application_controller 14166 gen_server 3996 sys 3510 ets 5766 lists 4972 application 1210 application_master 3185 kernel 1875 supervisor 6060 rpc 2785 global 9279 inet_db 9456 inet_config 4520 inet_udp 2918 inet 9467 erl_open_port 1327 gen_udp 1199 string 2988 inet_parse 6200 os 2481 filename 5808 inet_hosts 1350 erl_distribution 980 global_group 5460 file 8418 code 2605 code_server 7188 code_server_int 919 code_aux 758 user_sup 1138 supervisor_bridge 1174 user_drv 3754 group 2770 edlin 4066 io_lib 2612 shell 3670 io_lib_format 3922 erl_eval 8450 dict 1374 io 2520 kernel_config 1398 error_logger_tty_h 2533 c 5977 erl_scan 5148 erl_parse 61862 io_lib_pretty 1807 example 566 sasl 1733 sasl_report_tty_h 678 alarm_handler 955 overload 1860 calendar 2216 release_handler 13046 sasl_report 1733 mnesia_sup 1400 timer 2562 mnesia_kernel_sup 757 mnesia_monitor 5892 mnesia_event 2067 mnesia_lib 12064 mnesia 15695 mnesia_bup 10603 mnesia_subscr 2524 mnesia_locker 6863 mnesia_recover 8876 mnesia_dumper 8608 gen_fsm 3884 mnesia_tm 16026 mnesia_schema 23960 dets 18949 mnesia_controller 10335 mnesia_log 5690 disk_log 11448 disk_log_server 1553 disk_log_sup 544 pg2 3236 disk_log_1 7377 net_kernel 10346 mnesia_checkpoint_sup 551 mnesia_snmp_sup 550 mnesia_late_loader 1049 mnesia_checkpoint 10695 mnesia_loader 4291 mnemosyne_sup 1121 mnesia_index 3036 mnemosyne_catalog 8169 mnesia_snmp_hook 1874 bplus_tree 5128 ams_sup 880 eva_sup 1075 eva_server 2876 eva 1319 eva_log_sup 797 log_server 2038 eva_log 2317 log 904 jive 3102 alarm_reckeeper 1392 gen_tcp 1391 alarm_observer 1982 inet_tcp 4357 alatest 433 random 818 alarm_listener 1088 record 537 alarm_jive 846 Totals. Current code = 553411 Old code = 0 -------------------------------------------------- From etxuwig@REDACTED Mon Oct 11 09:30:17 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 11 Oct 1999 09:30:17 +0200 (MET DST) Subject: some basic questions In-Reply-To: <199910091313.PAA09037@super.du.uab.ericsson.se> Message-ID: Per, I agree with you. I'd like to add one piece of information On Sat, 9 Oct 1999, Per Hedeland wrote: per>Ulf Wiger wrote: per>>Well, there is a new monitor() function in OTP R5B, [...] per>Hm, unless I'm missing something, monitor/2 is "just" a generalized (but per>so far only applies to pids) and uni-directional version of link/1 per>(which is bi-directional) - plus monitor produces normal messages rather per>than EXIT signals. And of course link/1 has been around since forever, per>and has worked across node limits ever since nodes came into existence per>as far as I know (it predates distributed Erlang). Yes, but unfortunately, link/1 hasn't been that useful in monitoring process communication. In fact, the one thing link does very well is cascading exits (that is, if one process dies, all processes linked to it will die.) There are a couple of things "wrong" with link: - It's two-way, which means that if you link to another process, you may cause trouble for that process if "you" die -- typically, a server may not have to trap exits, but if clients start linking to it, it may have to in order not to die when they die. - It's not additive, that is, the runtime system doesn't remember how often you called link/1. There will only be at most one link, and the first call to unlink/1 removes it. That makes it difficult to have nested calls to link/1. So basically, there was a need for a monitor() primitive. And monitor/2 solves the problems above. I believe the reason why it doesn't work across node limits yet, is that it wasn't obvious how to implement it efficiently. The traditional way to achieve safe process dialogs is to use "call" semantics, guarded with a timeout. It always works, as long as you handle the problem that the answer arrives just shortly after your timeour expires. The problem in real-time systems is that even if the server process dies before reading the message, you must wait for the length of the timeout to find out that something went wrong. Using monitor/1, you will find out immediately. /Uffe Ulf Wiger, Chief Designer AXD 301 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 klacke@REDACTED Mon Oct 11 10:20:17 1999 From: klacke@REDACTED (Klacke) Date: Mon, 11 Oct 1999 10:20:17 +0200 (CEST) Subject: some basic questions In-Reply-To: References: <14333.41295.178009.45107@kricka.bluetail.com> Message-ID: <14337.40385.650119.198613@kricka.bluetail.com> Michael Skowronski writes: > > i believe, the same group is working on a new toolkit called Ensemble. > from what i understand, the ISIS toolkit took a ``monolithic'' type > approach and offered pre-defined and limited choices as to ordering and > membership -- Ensemble i think has a sort of an OO approach and is more > open, extensible and composible. have you had a look at Ensemble? > Yes, we looked a lot at the Ensemble architecture as well during the ISIS/Erlang project. Ensemble is a very nice system written by Marc Hayden while at Cornell. He has now quit there and started at Compaq, doing other things. I met Marc Hayden at a conference last year and we discussed Erlang/ML/isis/Ensemble. Ensemble reimplements the ISIS protocolls. It's all written in ML !!!. Ensemble is really interesting from an Erlang point of view as well, not so much for it's ISIS implementation as for *how* it's implemented. Marc did a really cool thing with micro layers of protocols. Different layers could then be stacked on top of each other in different ways. (Note that this is in complete contrast to how protocols are normally *implemented* where typically all the layers are completelet intertwined for efficency reasons). Well, after the layer stacking, a cool type/proof/reduction machinery was run on the protocol stack which produced a specialized stack. A bit like compiler unfolding. The net result was a really efficent protocol implementaion. Ensemble was finished a couple of years ago and I don't know if it's actively maintained any more since Marc quit Cornell. > > > However, I still think that we need better abstractions than > > the ones we have today in order to build distributed apps. > > yes, i agree. I think that the group concept from ISIS was/is a really nice attempt at finding better distributed apps abstractions, however using them and using them good maybe isn't as easy as it should be. Cheers /klacke Claes Wikstr?m Tel: +46 (0)8 692 22 09 Bluetail AB Email: klacke@REDACTED Hantverkargatan 78 WWW: http://www.bluetail.com SE-112 38 Stockholm, SWEDEN From per@REDACTED Mon Oct 11 11:33:27 1999 From: per@REDACTED (Per Hedeland) Date: Mon, 11 Oct 1999 11:33:27 +0200 (MET DST) Subject: some basic questions Message-ID: <199910110933.LAA01521@super.du.uab.ericsson.se> Ulf Wiger wrote: >Yes, but unfortunately, link/1 hasn't been that useful in monitoring >process communication. In fact, the one thing link does very well is >cascading exits (that is, if one process dies, all processes linked to it >will die.) Right, it was part of the original (intentionally) "simplistic" Erlang error handling philosophy: Trying to do a lot of finegrained error handling is usually counterproductive, at least in the typical applications Erlang was intended for - the important thing is not to find out exactly what the problem was (with a lot of code that may actually *introduce* errors, especially since it rarely gets tested well), but to recover gracefully (abandoning/restarting some predefined "minimal" part of the system) and keep on running. But of course the real world requirements sometimes are stricter or more complex than that, and I didn't really mean to imply that monitor/2 was unneeded - rather to point out to anyone that might have missed it that there already *is* *one* mechanism to do "super-safe" communication, even if it may have some drawbacks. >There are a couple of things "wrong" with link: And I can add one (it too is "wrong", not wrong:-): - It produces EXIT signals, rather than normal messages. I.e. if you don't want the issuing process to die when the communication fails, it has to trap exits - and trapping exits in a library function (that e.g. makes a "call" to a server) is problematic or at least error- prone - if the calling process wasn't trapping exits, you have to deal correctly with any *other* EXIT signals that happen to arrive while you are waiting for the reply (and hope that you can differentiate them from the one you were looking for:-). >- It's two-way, which means that if you link to another process, > you may cause trouble for that process if "you" die -- typically, > a server may not have to trap exits, but if clients start > linking to it, it may have to in order not to die when they die. Well, maybe a server should always trap exits, to make sure it never dies - but not every process you want "guaranteed communication" with is necessarily a server, of course. >The problem in real-time systems is that even if the server process dies >before reading the message, you must wait for the length of the timeout to >find out that something went wrong. Using monitor/1, you will find out >immediately. As with link/1.:-) However I think perhaps that this "library function making a call to a server" is the actual problem, and I'm not absolutely convinced that monitor fully solves it: The intent in this case is to just monitor a single query/reply exchange (as opposed to two processes having a long-standing link/monitor "relationship"), and to be truly useful for this, monitor has to work across nodes of course (seems it does in "R6"), which means that a message must be sent to the remote node, and another for demonitor - and this is comparatively expensive, as you suggested (link has the same problem, of course). So perhaps there really is a need for something like monitor_send() - semantics could be (after ca 5 minutes of thinking about it:-) that the sending of the message itself started the monitoring, which was canceled as soon as the receiver sent a message back to the same process. But I'm sure those actually working on the implementation (or actually writing complex Erlang programs:-) have thought longer and harder about this than I have - comments appreciated...:-) --Per From luke@REDACTED Tue Oct 12 10:36:51 1999 From: luke@REDACTED (Luke Gorrie) Date: 12 Oct 1999 18:36:51 +1000 Subject: testing through trace analysis Message-ID: <87g0zh3rh8.fsf@baked.vegetable.org> Hi all, I've been playing with a novel (to me) way of testing programs by tracing their actions while they run, and then at the end checking that the sequence of events is valid. Like some stuff I read about in CSP. I did this by hand because it was fairly convenient to send special messages to a logging process all within the unit test module. Now I've noticed how powerful the trace/3 BIF is for this sort of thing and I'm really curious to know how people use it. I'm envisioning a testing framework that uses a little language that can be used to say what order(s) a set of events (sending messages, calls to certain modules, etc) can occur - the set of all possible correct traces - and then have it automatically and painlessly validated. Do people do this stuff? I'm finding it useful in my very simple example which lends itself to this sort of thing, but I'm curious to know if it's widely applicable. I've also been generally trying to imagine what the testing frameworks in use look like, and thinking about things like having any failed unit test automatically restarted in the debugger with a breakpoint set at the start, etc. If anyone wants to satisfy my curiousity as to what testing support works well I'd be very grateful. :-) -- "Time flies like an arrow; fruit-flies like a banana." -Groucho Marx From hakan@REDACTED Tue Oct 12 11:48:41 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Tue, 12 Oct 1999 11:48:41 +0200 (MET DST) Subject: some basic questions In-Reply-To: <199910110933.LAA01521@super.du.uab.ericsson.se> Message-ID: On Mon, 11 Oct 1999, Per Hedeland wrote: per> As with link/1.:-) However I think perhaps that this "library function per> making a call to a server" is the actual problem, and I'm not absolutely per> convinced that monitor fully solves it: The intent in this case is to per> just monitor a single query/reply exchange (as opposed to two processes per> having a long-standing link/monitor "relationship"), and to be truly per> useful for this, monitor has to work across nodes of course (seems it per> does in "R6"), which means that a message must be sent to the remote per> node, and another for demonitor - and this is comparatively expensive, per> as you suggested (link has the same problem, of course). per> per> So perhaps there really is a need for something like monitor_send() - per> semantics could be (after ca 5 minutes of thinking about it:-) that the per> sending of the message itself started the monitoring, which was canceled per> as soon as the receiver sent a message back to the same process. But I'm per> sure those actually working on the implementation (or actually writing per> complex Erlang programs:-) have thought longer and harder about this per> than I have - comments appreciated...:-) This seems like a good approach if it is implemented correctly. For processed with registered names, it is essential that the name is resolved to the same process identifier both for the delivery of the message and for monitoring of the process. Sometime ago I had lots of trouble with "unsafe" calls between named servers on different nodes. The problem turned out to be gen_server, which naivly sent the message to the named process, waited for a while and then resolved the name again to see if the process was alive. If it was alive it waited forever for the message (Timeout=infinity). Unfortunately my named process died and a new one was restarted with the same name. This lead to a situation where my message was delivered to one process and but the client was monitoring another one. Internally in Mnesia, named processes are used a lot and in order to make the "unsafe" gen_server calls "safe" we have used two different approaches depending on the circumstances: o At startup of Mnesia (after negotiating about which communication protocol to use) a local monitor process is linked to monitor processes on all other database nodes. The aim of the monitor process is to monitor various resources such as Mnesia on remote nodes, local dets and disk_log processes etc. (Luckily Mnesia has no need for monitoring of other applications.) When an inter-monitor-link breaks, the monitor forwards internal {mnesia_down, Node} messages to the processes that needs to be informed about this. Besides Mnesia's internal processes the message is forwarded to user processes, such as transaction coordinators. This mechanism works very well for communcication protocols which involves longer dialogs. It is both reliable and fast. The tricky part has been to avoid sending spurious {mnesia_down, Node} messages in the cases when the server first replies to the message and then dies shortly afterwards. In http://www.ericsson.se/cslab/~hakan/mnesia_internals_slides.pdf you will find some architectural pictures covering these issues. o Especially during the startup of Mnesia there are a various of interesting concurrency situations that may occur. The startup may be performed simultaneously on several nodes, possible with different pace and different degree of success. Named servers may crash and be restarted under the same name. In order to make the startup safe (despite of gen_server) the gen_server calls are sometimes wrapped by explicitly linking to the process BEFORE message delivery and unlinking it when the reply has arrived. It is reliable but costly. /H?kan From etxuwig@REDACTED Tue Oct 12 13:05:59 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 12 Oct 1999 13:05:59 +0200 (MET DST) Subject: some basic questions In-Reply-To: Message-ID: On Tue, 12 Oct 1999, Hakan Mattsson wrote: hakan> In order to make the startup safe (despite of gen_server) the hakan> gen_server calls are sometimes wrapped by explicitly linking hakan> to the process BEFORE message delivery and unlinking it when hakan> the reply has arrived. It is reliable but costly. Oh, yes. I do something similar in my own read-write locker. The server has a link table containing counters of link requests, so that I know when to really unlink. This can of course be avoided sometimes, depending on the behaviour of the clients. In my case, it's linking on the server side, because I care less about the event that the locker crashes, than about when clients crash. handle_call({creq, Req}, {From, Ref}, S) -> handle_link(From, Req), client_request(Req, {From, Ref}, S); ... handle_link(Pid, Req) when element(1, Req) == set -> add_link(Pid); handle_link(Pid, Req) when element(1, Req) == unset -> remove_link(Pid); handle_link(Pid, Req) -> ?DEBUG("no link operation (Req == ~p).~n", [Req]), ok. add_link(Pid) -> case catch ets:update_counter(?LINK_TABLE, Pid, 1) of {'EXIT', _} -> ets:insert(?LINK_TABLE, {Pid, 1}); _ -> true end, ?DEBUG("linking (~p).~n", [Pid]), link(Pid). remove_link(Pid) -> case ets:update_counter(?LINK_TABLE, Pid, -1) of 0 -> ?DEBUG("unlinking (~p).~n", [Pid]), unlink(Pid); _ -> true end. Ulf Wiger, Chief Designer AXD 301 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 etxuwig@REDACTED Tue Oct 12 13:16:06 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 12 Oct 1999 13:16:06 +0200 (MET DST) Subject: testing through trace analysis In-Reply-To: <87g0zh3rh8.fsf@baked.vegetable.org> Message-ID: On 12 Oct 1999, Luke Gorrie wrote: luke>Hi all, luke> luke>I've been playing with a novel (to me) way of testing programs by luke>tracing their actions while they run, and then at the end luke>checking that the sequence of events is valid. Like some stuff I luke>read about in CSP. I did this by hand because it was fairly luke>convenient to send special messages to a logging process all luke>within the unit test module. luke> luke>Now I've noticed how powerful the trace/3 BIF is for this sort of luke>thing and I'm really curious to know how people use it. I'm luke>envisioning a testing framework that uses a little language that luke>can be used to say what order(s) a set of events (sending luke>messages, calls to certain modules, etc) can occur - the set of luke>all possible correct traces - and then have it automatically and luke>painlessly validated. We use the trace BIF a lot, but not for esotheric stuff like event validation. Personally, I find the trace BIF very useful for debugging of timing- sensitive sequences in an embedded system. Usually, I enter the trace() calls from the shell prompt and then use the shell command flush() to display them (in other words, the shell process gets to collect trace messages in its message queue, until I'm ready to see them.) Other uses are: 1. Performance profiling, where we use trace messages with 'proc', 'gc' and 'timestamp' flags to see how much CPU time is spent performing a certain task. 2. Event-triggered trace, where we can specify how many trace messages before and after a certain event to display, as well as which event should trigger the trace presentation (e.g. 10 trace msgs before and 10 after the reception of message M.) 3. System trace, where we turn on message trace on all processes in the system and dump them all to disk, in order to figure out what is really happening when the system behaves strangely. luke>I've also been generally trying to imagine what the testing luke>frameworks in use look like, and thinking about things like luke>having any failed unit test automatically restarted in the luke>debugger with a breakpoint set at the start, etc. If anyone wants luke>to satisfy my curiousity as to what testing support works well luke>I'd be very grateful. :-) We haven't really invested much energy trying to build generic tools, as we (or more specifically our profiling guru Kurt) feel that it is just as easy to write a specific analysis program from scratch when needed. So much for code reuse... (: /Uffe Ulf Wiger, Chief Designer AXD 301 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 etxuwig@REDACTED Tue Oct 12 13:41:50 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 12 Oct 1999 13:41:50 +0200 (MET DST) Subject: testing through trace analysis In-Reply-To: Message-ID: On Tue, 12 Oct 1999, Ulf Wiger wrote: etxuwi>Other uses are: etxuwi> etxuwi>1. Performance profiling, where we use trace messages with etxuwi>'proc', 'gc' and 'timestamp' flags to see how much CPU time etxuwi>is spent performing a certain task. I thought I'd share a little invention: The macro SYS_TRACE_WRAP. It is used as a wrapper around a syntactical expression, in order to get a feeling for how long a certain block of code takes to execute. What the macro does is send a message to itself and then remove it. This is a very cheap operation (normally 10-20 us), and it does show on a timestamped message trace. (Never mind the debug:sys_trace() function. It's a debug filter, supposed to return true | false. You can remove that.) /Uffe -ifdef(sys_trace). %%% ---------------------------------------------------------- %%% # SYS_TRACE(Msg) %%% Description: Send trace message. %%% This macro sends a sys_trace message to its %%% own process and immediately removes it from %%% the message queue. This is a "cheap" way to %%% add a trace point in a message trace. %%% ---------------------------------------------------------- -define(SYS_TRACE(Term), case catch debug:sys_trace() of true -> begin self() ! {sys_trace, Term}, receive {sys_trace, _} -> ok end end; _ -> disabled end). %%% ---------------------------------------------------------- %%% # SYS_TRACE_WRAP(Expr, TraceInfo) %%% Input: Expression - simple or grouped with begin...end, %%% TraceInfo - any info you want to log to uniquely %%% identify the trace. %%% Description: Introduces trace points before and after %%% an expression, such as a function call. %%% Before executing Expr, a SYS_TRACE message %%% of the form {enter, Module, TraceInfo} is sent, %%% and after Expr is executed, %%% {exit, Module, TraceInfo} is sent. %%% The strange application of a function object %%% is used to avoid a variable binding, which %%% would prevent using the macro twice in one %%% function. Expr is evaluated *outside* the %%% fun, so exit messages should read as expected. %%% ---------------------------------------------------------- -define(SYS_TRACE_WRAP(Expr, TraceInfo), case catch debug:sys_trace() of true -> begin ?SYS_TRACE({begin_trace_wrap, ?MODULE, TraceInfo}), (fun(Res) -> ?SYS_TRACE({end_trace_wrap, ?MODULE, TraceInfo}), Res end)(Expr) end; _ -> % No filter Expr must be done Expr end). -else. -define(SYS_TRACE(Term), trace_disabled). -define(SYS_TRACE_WRAP(Expr, _), Expr). -endif. % sys_trace defined Ulf Wiger, Chief Designer AXD 301 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 Tue Oct 12 15:35:12 1999 From: vances@REDACTED (Vance Shipley) Date: Tue, 12 Oct 1999 09:35:12 -0400 Subject: some basic questions In-Reply-To: Message-ID: <002601bf14b6$9befca50$0abdc5c0@desk.motivity.ca> } Sometime ago I had lots of trouble with "unsafe" calls between named } servers on different nodes. The problem turned out to be gen_server, } which naivly sent the message to the named process, waited for a while } and then resolved the name again to see if the process was alive. If } it was alive it waited forever for the message (Timeout=infinity). } Unfortunately my named process died and a new one was restarted with } the same name. This lead to a situation where my message was delivered } to one process and but the client was monitoring another one. So are you suggesting that gen_server needs fixing? -Vance From hakan@REDACTED Wed Oct 13 14:04:03 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Wed, 13 Oct 1999 14:04:03 +0200 (MET DST) Subject: Test suite of Mnesia available In-Reply-To: <87yadou51g.fsf@baked.vegetable.org> Message-ID: I have made tar ball of Mnesia's test suite: http://www.ericsson.se/cslab/~hakan/mnesia_test_3.8.1.tgz It contains the source code for the test suite and a little introductory README file. Once upon the time I made a quite ambitious test plan for Mnesia. Nowdays most of the test suite is implemented, but there are still room for volunteers... The test suite is written for Mnesia 3.8.1 (soon to be released). This means that some of the test cases asssumes the availability of not yet released functionality such as incremental backups, decentralized backups, selective backups etc. and will therefore encounter some errors. Ignore these for the time being. For those of you that will go ahead and enhance Mnesia, you may be interested of a brief overview of Mnesia's internal architecture: http://www.ericsson.se/cslab/~hakan/mnesia_internals_slides.pdf /H?kan From elfaker@REDACTED Wed Oct 13 14:48:51 1999 From: elfaker@REDACTED (El Faker Abdellatif) Date: Wed, 13 Oct 1999 12:48:51 +0000 Subject: Questions regarding the GC of Erlang Message-ID: <38047FB3.CA9692AD@ensias.ac.ma> -- My topic of research consists in to construct a garbage collector (GC) for the actors distributed on several sites. I will like to knowledge the details of the GC that you use for the Erlang language, how has you measured the performances of this GC and lately if it is possible to send me some papers regarding this topic (GC of Erlang). Thank you of your collaboration ______________________________________________________ Khadija DOUZI ENSIAS, B.P. 713, Agdal, Rabat, Morocco Email : douzik@REDACTED Tel : (212) 7 77 85 79 Fax : (212) 7 77 72 30 From claygordon@REDACTED Wed Oct 13 16:32:58 1999 From: claygordon@REDACTED (Clay Gordon) Date: Wed, 13 Oct 1999 10:32:58 -0400 Subject: JDBC interface Message-ID: <4.2.0.58.19991013103052.009fbd40@pop.mindspring.com> I am investigating the use of an application that claims it is able to work with any relational database with a JDBC interface. The real-time, distributed nature of Mnesia makes it suitable for this particular scenario, so I am wondering about JDBC connectivity. I have not read it mentioned on the list and do not remember coming across it in any of the documentation I have read. Does it exist? TIA, Clay Gordon From mskow@REDACTED Wed Oct 13 19:40:00 1999 From: mskow@REDACTED (Michael Skowronski) Date: Wed, 13 Oct 1999 13:40:00 -0400 (EDT) Subject: mnesia and binary/large files In-Reply-To: Message-ID: hello, i just read some info about mnesia and the literature suggests that it might not be appropriate for text and binary data. what would happen if one were to store large text and/or binary datat in a mnesia database and try to use its replication features? thanks. mike From gandalf@REDACTED Wed Oct 13 21:26:10 1999 From: gandalf@REDACTED (Vladimir Ulogov) Date: Wed, 13 Oct 1999 15:26:10 -0400 Subject: mnesia and binary/large files References: Message-ID: <3804DCD2.D3D6E6D9@control.att.com> Michael Skowronski wrote: Hi there, > hello, > i just read some info about mnesia and the literature suggests that it > might not be appropriate for text and binary data. what would happen if My feeling it will be very slow on write operation. Delete shoudn't cause any problems. The read operation will be depend from the blob size and lookup from the keysize. So, do not use BLOB as keyfield (if you computer are not 20t megaelephant, same precautions like for pangalactic gargleblaster) You can speed-up read and write operations using old trick - split BLOB on the parts, so: -record(blobs, {blob_id, sequence_number, blob_data}). instead -record(blobs, {blob_id, blob_data}). in This case the second record could be a part of the set type table, but first definitely should be bag. You can write the functions which will split and pack blob in the binary object youself. It suppose to be easy. BTW, if you will need to cache the requests, as sample split the big image in the set of small portions and send it to the user portion-by-portion, you should take care about making these small BLOBS to be a full functional images (if they require some header or so on). > mike -- %% Vladimir I. Ulogov (gandalf@REDACTED) AT&T Labs "Where lands meets water. Where earth meets air. Where body meets mind. Where space meets time. We like to be on one side, and look at the other." D.Adams "Mostly harmless" From klacke@REDACTED Wed Oct 13 21:31:45 1999 From: klacke@REDACTED (Klacke) Date: Wed, 13 Oct 1999 21:31:45 +0200 (CEST) Subject: mnesia and binary/large files In-Reply-To: References: Message-ID: <14340.56865.70114.662890@duva.bluetail.com> > i just read some info about mnesia and the literature suggests that it > might not be appropriate for text and binary data. what would happen if > one were to store large text and/or binary datat in a mnesia database and > try to use its replication features? > i just read some info about mnesia and the literature suggests that it > might not be appropriate for text and binary data. what would happen if > one were to store large text and/or binary datat in a mnesia database and > try to use its replication features? > Mnesia has some really cool characteristics and some not so cool. One of the things mnesia handles poorly is large amounts of data. Two reasons: 1. The file-storage is performed by dets.erl. dets uses a mark in each datafile to determine whether the datafile was properly closed or not. A datafile is not properly closed if the erlang system crashes, the host/os crashes (Or erlang is brutally killed by means of either ^C or halt()) Whenever the datafile is reopened, dets notices this and starts to repair the datafile. Some hash structures as well as the freelist for the file is lost. This just exactly what we need and want unless the datafile is very very big. A couple of megabyte of disk data takes just a couple of seconds to fix, but if the amount is very large (and databases often are) it can take a considerable amount of time to fix. In a production environment, this happens when Erlang or the host/os crash. Neither of these events happen often. A possible fix to this problem is for mnesia to use the safedets.erl code I just recently posted to www.erlang.org 2. Replication, A replicated table is either loaded from disk or from the network. No incremental network loads whatsoever are implemented. A full network load of a very large table can also take some considerable amount of time. An obvious mnesia enhancemenet would be the following: Two nodes A + B, one table T. A dies, X and Y is inserted in T (on B only), A recovers. Now instead of copying the entire table T, we only need to redo the insertions of X and Y at A. Once I started to implement this but got severe headaches. It's a lot harder than it sounds. However, with the safedets fix we should at least be able to have large non-replicated tables. As for the issue of binary data, no problems at all. Just store Erlang binary objects at will, no problem. Cheers /klacke Ps. Now don't go and get all worked up about this, do some measurements instead and see how long it takes to repair as well as network load tables of different sizes. Usually it's ok. Claes Wikstrom Tel: +46 (0)8 692 22 09 Bluetail AB Email: klacke@REDACTED Hantverkargatan 78 WWW: http://www.bluetail.com SE-112 38 Stockholm, SWEDEN From david_schere@REDACTED Thu Oct 14 03:12:47 1999 From: david_schere@REDACTED (David Schere) Date: Wed, 13 Oct 1999 18:12:47 -0700 (PDT) Subject: C Erlang algorithm Message-ID: <19991014011247.18188.rocketmail@web1504.mail.yahoo.com> Is this the correct algorithm for making erlang calls using the erlang interface API ? Assume that no erlang process is running. The hostname is www.foo.com /* must be called before anything else */ erl_init( NULL, 0 ); /* initialize ystem */ erl_start_sys("theFoo","www.foo.com",0,NULL,NULL); fd = erl_connect("theFoo@REDACTED"); /* At some time T in the future */ eterm = erl_rpc(fd,"erlang","time", erl_format("[]") ); . . . . /* disconnect when done */ I keep on getting a timeout when calling 'erl_start_sys'. Can anybody give me an example ?? Thanks ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From luke@REDACTED Thu Oct 14 07:17:03 1999 From: luke@REDACTED (Luke Gorrie) Date: 14 Oct 1999 15:17:03 +1000 Subject: Test suite of Mnesia available In-Reply-To: Hakan Mattsson's message of "Wed, 13 Oct 1999 14:04:03 +0200 (MET DST)" References: Message-ID: <871zay34j4.fsf@baked.vegetable.org> Hakan Mattsson writes: > I have made tar ball of Mnesia's test suite: Thanks! This looks very thorough, I feel safe to hack Mnesia now :-) -- "Time flies like an arrow; fruit-flies like a banana." -Groucho Marx From tobbe@REDACTED Thu Oct 14 08:04:27 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 14 Oct 1999 16:04:27 +1000 Subject: C Erlang algorithm In-Reply-To: David Schere's message of "Wed, 13 Oct 1999 18:12:47 -0700 (PDT)" References: <19991014011247.18188.rocketmail@web1504.mail.yahoo.com> Message-ID: > Is this the correct algorithm for making erlang calls > using the erlang interface API ? Looks about right, but the erl_start_sys() is not documented from what I can see. Do you really need/want to start Erlang from your C program ? I guess you've already have seen the comment in erl_start.c: ------------------------------------------------------------------- /* Start an Erlang node. return value 0 indicates that node was * started successfully, negative values indicate error. * * node - the name of the remote node to start (alivename@REDACTED). * flags - turn on or off certain options. See erl_start.h for a list. * erl - is the name of the erl script to call. If NULL, the default * name "erl" will be used. * args - a NULL-terminated list of strings containing * additional arguments to be sent to the remote Erlang node. These * strings are simply appended to the end of the command line, so any * quoting of special characters, etc must be done by the caller. * There may be some conflicts between some of these arguments and the * default arguments hard-coded into this function, so be careful. */ int erl_start_sys(char *alive, Erl_IpAddr adr, int flags, char *erl, char *args[]) ------------------------------------------------------------------- /Tobbe From hakan@REDACTED Thu Oct 14 10:17:19 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Thu, 14 Oct 1999 10:17:19 +0200 (MET DST) Subject: mnesia and binary/large files In-Reply-To: <14340.56865.70114.662890@duva.bluetail.com> Message-ID: On Wed, 13 Oct 1999, Klacke wrote: klacke> An obvious mnesia enhancemenet would be the following: klacke> Two nodes A + B, one table T. klacke> A dies, X and Y is inserted in T (on B only), A recovers. klacke> Now instead of copying the entire table T, we only need to klacke> redo the insertions of X and Y at A. klacke> klacke> Once I started to implement this but got severe headaches. It's klacke> a lot harder than it sounds. Perhaps there are some volunteers, looking for headache? ;-) There are several approches that could be explored in order to speed up the table loading mechanism: - one is to introduce the notion of version identifiers on records in ets and dets. This would enable the table load mechanism to rely on an algorithm that looks for records whose version identifiers differs between trusted nodes and startups. To go a step further we could use a common version identifier generator for all records in a table. This would enable us to use the version identifier as a kind of timestamp for the entire table. If both nodes agrees on the fact that the the table timestamp are the same on both nodes, there are no need to iterate over the table and compare the version identifier of each record. - another is to introduce the notion of durable checkpoints in Mnesia. That is checkpoints that survives, even if all nodes would go down simultaneously. A durable checkpoint should be activated while all replicas are active and the checkpoint should then be moved forwards, now and then, in the same manner as checkpoints used for the purpose of incremental backups. At startup the table load algorithm could compare the checkpoint contents of the nodes and only transfer the lost updates. Using checkpoints are not for free, but in systems using incremental backups it would be almost for free. - ... The real headache comes, when you start to think about backwards compatibility and smooth on-line upgrade... klacke>Ps. Now don't go and get all worked up about this, do some klacke>measurements instead and see how long it takes to repair klacke>as well as network load tables of different sizes. klacke>Usually it's ok. If it is not ok, you should try to use the feature of fragmented tables in Mnesia. This will make the dets files smaller and therefore shorten the repair times of them. Fragmented tables may also be used for the purpose of distributing large amounts of data over several nodes, and therefore decrease need for copying bauta tables between the nodes. /H?kan From hakan@REDACTED Thu Oct 14 10:34:46 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Thu, 14 Oct 1999 10:34:46 +0200 (MET DST) Subject: JDBC interface In-Reply-To: <4.2.0.58.19991013103052.009fbd40@pop.mindspring.com> Message-ID: On Wed, 13 Oct 1999, Clay Gordon wrote: Clay> I am investigating the use of an application that claims it is able to work Clay> with any relational database with a JDBC interface. The real-time, Clay> distributed nature of Mnesia makes it suitable for this particular Clay> scenario, so I am wondering about JDBC connectivity. I have not read it Clay> mentioned on the list and do not remember coming across it in any of the Clay> documentation I have read. Clay> Clay> Does it exist? No, it does not exist. Mnesia has no SQL interface. We do however have a prototype of an SQL interface, which was implemented as a master thesis work. For a small subset of SQL, the compiler translated SQL queries into the internal form of the Mnemosyne query compiler, and then used Mnesmosyne's backend to evaluate the query. There is a substantial amount of work needed, in order to implement a fully SQL compliant interface for Mnesia. We have no such plans for the moment. /H?kan From david_schere@REDACTED Fri Oct 15 22:12:53 1999 From: david_schere@REDACTED (David Schere) Date: Fri, 15 Oct 1999 13:12:53 -0700 (PDT) Subject: Python/Erlang Beta Message-ID: <19991015201253.18345.rocketmail@web1504.mail.yahoo.com> Hello, I have a beta release of a binding of Python to Erlang. Where do I go to upload the contribution ? ===== __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com From luke@REDACTED Fri Oct 15 23:01:46 1999 From: luke@REDACTED (Luke Gorrie) Date: 16 Oct 1999 07:01:46 +1000 Subject: Python/Erlang Beta In-Reply-To: David Schere's message of "Fri, 15 Oct 1999 13:12:53 -0700 (PDT)" References: <19991015201253.18345.rocketmail@web1504.mail.yahoo.com> Message-ID: <87k8ooz6bp.fsf@baked.vegetable.org> David Schere writes: > Hello, > > I have a beta release of a binding of Python to > Erlang. Where do I go to upload the contribution ? There are some instructions for posting contributions to erlang.org at http://www.erlang.org/contrib/rules.html This sounds good, I've been trying to get some Python-loving friends into Erlang for months :-) maybe this will help. -- "Time flies like an arrow; fruit-flies like a banana." -Groucho Marx From peter.sommerfeld@REDACTED Sat Oct 16 01:03:57 1999 From: peter.sommerfeld@REDACTED (Peter Sommerfeld) Date: Sat, 16 Oct 1999 01:03:57 +0200 Subject: Python/Erlang Beta In-Reply-To: <87k8ooz6bp.fsf@baked.vegetable.org> References: David Schere's message of "Fri, 15 Oct 1999 13:12:53 -0700 (PDT)" <19991015201253.18345.rocketmail@web1504.mail.yahoo.com> Message-ID: Luke Gorrie writes: >This sounds good, I've been trying to get some Python-loving friends >into Erlang for months :-) maybe this will help. I would like to use both too. But unfortuanatly Erlang isn't available on Mac. Is there any chance for a Mac port ? -- Peter From hgarza@REDACTED Sat Oct 16 14:13:42 1999 From: hgarza@REDACTED (Hector Garza) Date: Sat, 16 Oct 1999 06:13:42 -0600 Subject: Oid for Mnesia Message-ID: <38086BF6.2251644F@citi.com.mx> I'm defining a table in which the primary key is formed of two attributes, not just one (relation-2 foreign keys). The thing is that when I try to initialize the table, I get the message that I have a bad record definition, which points to the first element of the record (./cf.hrl:39: bad record field). These are the record definitions I've tried> -record(placed_on, { [id_procedure,id_plataform], path}). -record(placed_on, { {id_procedure,id_plataform}, path} ). As you see, I tried first to define the first element as a list, and then as a tuple, but none of those ways work. Any of you guys could help me on this... thanks hector garza> From luke@REDACTED Sat Oct 16 01:42:17 1999 From: luke@REDACTED (Luke Gorrie) Date: 16 Oct 1999 09:42:17 +1000 Subject: Oid for Mnesia In-Reply-To: Hector Garza's message of "Sat, 16 Oct 1999 06:13:42 -0600" References: <38086BF6.2251644F@citi.com.mx> Message-ID: <87hfjsyyw6.fsf@baked.vegetable.org> What I see most commonly used for this is to just change your record so that both components of the key are put in the same attribute: -record(placed_on, {id, path}). where id is a {Procedure, Platform} tuple, accessed as in {Procedure, Platform} = Rec#placed_on.id or, depending on your taste, id can be a record in its own right: -record(id, {procedure, platform}). accessed as in Procedure = (Rec#placed_on.id)#id.procedure But there might be a better way to do this that I don't know about. Hector Garza writes: > I'm defining a table in which the primary key is formed of two > attributes, not just one (relation-2 foreign keys). > The thing is that when I try to initialize the table, I get the > message that I have a bad record definition, which points to the first > element of the record (./cf.hrl:39: bad record field). > > These are the record definitions I've tried> > > -record(placed_on, { [id_procedure,id_plataform], > path}). > > -record(placed_on, { {id_procedure,id_plataform}, > path} ). > > As you see, I tried first to define the first element as a list, and > then as a tuple, but none of those ways work. > > Any of you guys could help me on this... > thanks > hector garza> -- "Time flies like an arrow; fruit-flies like a banana." -Groucho Marx From stone@REDACTED Sat Oct 16 15:31:20 1999 From: stone@REDACTED (Magnus Stenman) Date: Sat, 16 Oct 1999 15:31:20 +0200 Subject: Python/Erlang Beta References: <19991015201253.18345.rocketmail@web1504.mail.yahoo.com> Message-ID: <38087E28.AD487234@hkust.se> Anybody know if there is an equivalent for perl? /magnus David Schere wrote: > > Hello, > > I have a beta release of a binding of Python to > Erlang. Where do I go to upload the contribution ? > > ===== > > __________________________________________________ > Do You Yahoo!? > Bid and sell for free at http://auctions.yahoo.com From vances@REDACTED Sat Oct 16 23:45:29 1999 From: vances@REDACTED (Vance Shipley) Date: Sat, 16 Oct 1999 17:45:29 -0400 Subject: Erl_interface's fixed term allocator Message-ID: My C program which interfaces to Erlang using the erl_interface library keeps failing hours or days after startup with: erl_alloc_eterm: Failed to allocate more memory : Insufficient or invalid memory I use erl_free_term() to free each ETERM that I allocate. Some investigation suggests that this is not enough. Apparently this just moves the memory to a "freelist". Do I have to empty the freelist myself with erl_eterm_release()? If so when and how often should I do so? -Vance From mskow@REDACTED Sun Oct 17 21:53:04 1999 From: mskow@REDACTED (Michael Skowronski) Date: Sun, 17 Oct 1999 15:53:04 -0400 (EDT) Subject: mnesia scaleability Message-ID: Hello, suppose someone were to try and store terabytes of information in an mnesia database -- would mnesia be able to handle this? Mike From tobbe@REDACTED Sun Oct 17 23:30:41 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 18 Oct 1999 07:30:41 +1000 Subject: Erl_interface's fixed term allocator In-Reply-To: "Vance Shipley"'s message of "Sat, 16 Oct 1999 17:45:29 -0400" References: Message-ID: > I use erl_free_term() to free each ETERM that I allocate. Some > investigation suggests that this is not enough. Apparently this > just moves the memory to a "freelist". Let's see if I remember this correct. The erl_interface library uses a sort of reference counting system to keep track of allocated ETERM structs. So if you write: ETERM *t_arr[2]; ETERM *t1; t_arr[0] = erl_mk_atom("hello"); t_arr[1] = erl_mk_atom("world"); t1 = erl_mk_tuple(&t_arr[0],2); you have created three (3) Erlang terms (ETERM). Now if you call: erl_free_term(t1) you only free upp the tuple not the other two ETERM's. To free all the allocated memory, you would have to call: erl_free_term(t_arr[0]); erl_free_term(t_arr[1]); erl_free_term(t1) To avoid all these calls to erl_free_term() you can use: erl_free_compund() instead. It does a "deep" free of all ETERM's. So the above could be accomplished with: erl_free_compund(t1) Thus, this routine makes it possible for you to write in a more compact way where you don't have to remember the references to all sub-component ETERM's. Example: ETERM *list; list = erl_cons(erl_mk_int(36), erl_cons(erl_mk_atom("tobbe"), erl_mk_empty_list())); ... /* do some work */ erl_free_compound(list); Cheers /Tobbe (Ps. I guess it is obvious that after a call to erl_free_compound(t1) in the first example you must not call erl_free_term(t_arr[i]) (where i = 0 or 1). ) From tobbe@REDACTED Mon Oct 18 01:01:46 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 18 Oct 1999 09:01:46 +1000 Subject: What is wrong? Help please. In-Reply-To: svg@disney.surnet.ru's message of "Sun, 10 Oct 1999 23:17:25 +0600" References: <19991010231725N.svg@disney.surnet.ru> Message-ID: > I'm working on simple erlang alarm monitor with Java front-end, but jive > always crushs with same reason on the same function after 2-10 minutes of > work. Below is a part of erlang-crush.dump. > > > Sun Oct 10 22:53:18 1999 > > Slogan: <0.184.0>: Overrun heap > heap start 0x082f6c08, heap end 0x082f946c, size 0x00000a18 Did you ever get an answer for the above question ? I can't help you much since I haven't used Jive myself, but that "Overrun heap" message indicates that you may have an Erlang function running which never terminates. Not much help I know. Cheers /Tobbe (Ps. Is it really no one else on this list who has used Jive ? ) From luke@REDACTED Mon Oct 18 02:01:23 1999 From: luke@REDACTED (Luke Gorrie) Date: 18 Oct 1999 10:01:23 +1000 Subject: What is wrong? Help please. In-Reply-To: Torbjorn Tornkvist's message of "18 Oct 1999 09:01:46 +1000" References: <19991010231725N.svg@disney.surnet.ru> Message-ID: <87d7udv8oc.fsf@baked.vegetable.org> Torbjorn Tornkvist writes: > (Ps. Is it really no one else on this list who has used Jive ? ) I used Jive for a little while, but I couldn't make it run stable and ended up switching over to Orber. I don't remember the exact details of my problem with Jive though. -- "Time flies like an arrow; fruit-flies like a banana." -Groucho Marx From klacke@REDACTED Mon Oct 18 09:17:37 1999 From: klacke@REDACTED (Klacke) Date: Mon, 18 Oct 1999 09:17:37 +0200 (CEST) Subject: mnesia scaleability In-Reply-To: References: Message-ID: <14346.51601.367360.446270@kricka.bluetail.com> > > suppose someone were to try and store terabytes of information in an > mnesia database -- would mnesia be able to handle this? > No, It's the file storage (dets.erl) that fails. Actually file.erl also fails, it assumes file positions are four bytes unsigned. So then, what is the recommeneded upper limit, ?? I'don't know. /klacke From stone@REDACTED Mon Oct 18 15:39:18 1999 From: stone@REDACTED (Magnus Stenman) Date: Mon, 18 Oct 1999 15:39:18 +0200 Subject: EPL and Open Source Message-ID: <380B2306.C8026BBE@hkust.se> I see that the EPL is not listed as an open source license at www.opensource.org. Since it is a close derivative of the MPL, it should be easy to get it listed there? All that is needed is to mail the licence to them, instructions are at http://www.opensource.org/certification-mark.html Any takers? /magnus -- Magnus Stenman mailto:stone@REDACTED http://www.hkust.se ...all in all, it's just another rule in the firewall. /Ping Flood From etxuwig@REDACTED Mon Oct 18 16:41:37 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 18 Oct 1999 16:41:37 +0200 (MET DST) Subject: Oid for Mnesia In-Reply-To: <38086BF6.2251644F@citi.com.mx> Message-ID: Records must be defined as -record(Name:atom(), {Attr1:atom() [ = Default:term()] [, ...]}). That is, you cannot define a compund structure of attributes. On the other hand, you can assign any value to an attribute. If you need to define the data types of your objects, you can do that using the RDBMS user contribution on http://www.erlang.org /Uffe On Sat, 16 Oct 1999, Hector Garza wrote: hgarza>I'm defining a table in which the primary key is formed of two hgarza>attributes, not just one (relation-2 foreign keys). hgarza> The thing is that when I try to initialize the table, I get the hgarza>message that I have a bad record definition, which points to the first hgarza>element of the record (./cf.hrl:39: bad record field). hgarza> hgarza>These are the record definitions I've tried> hgarza> hgarza>-record(placed_on, { [id_procedure,id_plataform], hgarza> path}). hgarza> hgarza>-record(placed_on, { {id_procedure,id_plataform}, hgarza> path} ). hgarza> hgarza>As you see, I tried first to define the first element as a list, and hgarza>then as a tuple, but none of those ways work. hgarza> hgarza>Any of you guys could help me on this... hgarza>thanks hgarza>hector garza> hgarza> hgarza> Ulf Wiger, Chief Designer AXD 301 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 Mon Oct 18 20:54:46 1999 From: vances@REDACTED (Vance Shipley) Date: Mon, 18 Oct 1999 14:54:46 -0400 Subject: Erl_interface's fixed term allocator In-Reply-To: Message-ID: Answering my own question, I put in calls to erl_eterm_statistics() and observered how the memory was being used. I was in fact using increasingly more memory and found a break in a case loop that didn't belong and was causing the erl_free_term() top be skipped. What erl_eterm_statistics() showed me though was that it was handling freeing up the "freed" list periodically. It seemed to keep about 30 items in the freed list at all times. -Vance } My C program which interfaces to Erlang using the erl_interface } library keeps failing hours or days after startup with: } } erl_alloc_eterm: Failed to allocate more memory } : Insufficient or invalid memory } } I use erl_free_term() to free each ETERM that I allocate. Some } investigation suggests that this is not enough. Apparently this } just moves the memory to a "freelist". } } Do I have to empty the freelist myself with erl_eterm_release()? } If so when and how often should I do so? } } -Vance } From art1235@REDACTED Tue Oct 19 12:00:30 1999 From: art1235@REDACTED (art1235@REDACTED) Date: Tue, 19 Oct 1999 12:00:30 Subject: laser printer toner advertisement Message-ID: <587.33448.404476@> BENCHMARK SUPPLY 7540 BRIDGEGATE COURT ATLANTA GA 30350 ***LASER PRINTER TONER CARTRIDGES*** ***FAX AND COPIER TONER*** CHECK OUT OUR NEW CARTRIDGE PRICES : APPLE LASER WRITER PRO 600 OR 16/600 $69 LASER WRITER SELECT 300,310.360 $69 LASER WRITER 300, 320 $54 LASER WRITER LS,NT,2NTX,2F,2G & 2SC $54 LASER WRITER 12/640 $79 HEWLETT PACKARD LASERJET SERIES 2,3 & 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $49 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $59 LASERJET SERIES 4000 HIGH YIELD (27X) $99 LASERJET SERIES 4V $95 LASERJET SERIES 5SI , 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $135 LASERJET SERIES 1100 (92A) $49 LASERJET SERIES 2100 (96A) $89 LASERJET SERIES 8100 (82X) $145 HP LASERFAX LASERFAX 500, 700, FX1, $59 LASERFAX 5000, 7000, FX2, $59 LASERFAX FX3 $69 LASERFAX FX4 $79 LEXMARK OPTRA 4019, 4029 HIGH YIELD $135 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $115 EPSON EPL-7000, 8000 $105 EPL-1000, 1500 $105 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 FX1 $59 CANONFAX L5000 L70000 FX2 $59 CANON COPIERS PC 20, 25 ETC.... $89 PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $89 NEC SERIES 2 LASER MODEL 90,95 $105 PLEASE NOTE: 1) ALL OUR CARTRIDGES ARE GENUINE OEM CARTRIDGES. 2) WE DO NOT SEND OUT CATALOGS OR PRICE LISTS 3) WE DO NOT FAX QUOTES OR PRICE LISTS. 4) WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS 5) WE DO NOT CARRY: BROTHER-MINOLTA-KYOSERA-PANASONIC PRODUCTS 6) WE DO NOT CARRY: XEROX-FUJITSU-OKIDATA OR SHARP PRODUCTS 7) WE DO NOT CARRY ANY COLOR PRINTER SUPPLIES 8) WE DO NOT CARRY DESKJET/INKJET OR BUBBLEJET SUPPLIES 9) WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS WE ACCEPT GOVERNMENT, SCHOOL & UNIVERSITY PURCHASE ORDERS JUST LEAVE YOUR PO # WITH CORRECT BILLING & SHIPPING ADDRESS ****OUR ORDER LINE IS 770-399-0953 **** ****OUR CUSTOMER SERVICE LINE IS 800-586-0540**** ****OUR E-MAIL REMOVAL AND COMPLAINT LINE IS 888-532-7170**** ****PLACE YOUR ORDER AS FOLLOWS**** : BY PHONE 770-399-0953 BY FAX: 770-698-9700 BY MAIL: BENCHMARK PRINT SUPPLY 7540 BRIDGEGATE COURT , ATLANTA GA 30350 MAKE SURE YOU INCLUDE THE FOLLOWING INFORMATION IN YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) YOUR NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT. (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE 1) WE SHIP UPS GROUND. ADD $4.5 FOR SHIPPING AND HANDLING. 2) COD CHECK ORDERS ADD $3.5 TO YOUR SHIPPING COST. 2) WE ACCEPT ALL MAJOR CREDIT CARD OR "COD" ORDERS. 3) OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS 4) OUR STANDARD MERCHANDISE REPLCAMENT POLICY IS NET 90 DAYS. NOTE NUMBER (1): PLEASE DO NOT CALL OUR ORDER LINE TO REMOVE YOUR E-MAIL ADDRESS OR COMPLAIN. OUR ORDER LINE IS NOT SETUP TO FORWARD YOUR E-MAIL ADDRESS REMOVAL REQUESTS OR PROCESS YOUR COMPLAINTS..IT WOULD BE A WASTED PHONE CALL.YOUR ADDRESS WOULD NOT BE REMOVED AND YOUR COMPLAINTS WOULD NOT BE HANDLED.PLEASE CALL OUR TOLL FREE E-MAIL REMOVAL AND COMPLAINT LINE TO DO THAT. NOTE NUMBER (2): OUR E-MAIL RETURN ADDRESS IS NOT SETUP TO ANSWER ANY QUESTIONS YOU MIGHT HAVE REGARDING OUR PRODUCTS. OUR E-MAIL RETURN ADDRESS IS ALSO NOT SETUP TO TAKE ANY ORDERS AT THIS TIME. PLEASE CALL THE ORDER LINE TO PLACE YOUR ORDER OR HAVE ANY QUESTIONS ANSWERED. OTHERWISE PLEASE CALL OUR CUSTOMER SERCICE LINE. NOTE NUMBER (3): OWNERS OF ANY OF THE DOMAINS THAT APPEAR IN THE HEADER OF THIS MESSAGE,ARE IN NO WAY ASSOCIATED WITH, PROMOTING, DISTRIBUTING OR ENDORSING ANY OF THE PRODUCTS ADVERTISED HEREIN AND ARE NOT LIABLE TO ANY CLAIMS THAT MAY ARISE THEREOF. From mskow@REDACTED Wed Oct 20 02:25:26 1999 From: mskow@REDACTED (Michael Skowronski) Date: Tue, 19 Oct 1999 20:25:26 -0400 (EDT) Subject: build problems Message-ID: Hello, i've been unsucessfully trying to build erlang from the sources. i'm using erlang_base-47.4.1.src.tar.gz, linux 2.2.1, debian (unstable). after configuring, i simply type ``make'' and get the following compile errors /usr/bin/ld: cannot find -lerl_interface collect2: ld returned 1 exit status make[4]: *** [/home/mskow/erlang-47.4.1/erts/bin/i686-unknown-linux/erl_call] Error 1 make[4]: Leaving directory `/home/mskow/erlang-47.4.1/erts/system/erl_interface/src' make[3]: *** [opt] Error 2 make[3]: Leaving directory `/home/mskow/erlang-47.4.1/erts/system/erl_interface/src' make[2]: *** [opt] Error 2 make[2]: Leaving directory `/home/mskow/erlang-47.4.1/erts/system/erl_interface' make[1]: *** [opt] Error 2 make[1]: Leaving directory `/home/mskow/erlang-47.4.1/erts/system' make: *** [emulator] Error 2 thanks. Mike From mskow@REDACTED Wed Oct 20 05:16:10 1999 From: mskow@REDACTED (Michael Skowronski) Date: Tue, 19 Oct 1999 23:16:10 -0400 (EDT) Subject: build problems In-Reply-To: Message-ID: Hello, Thanks for the info. that got me through the build ok and when i tried to install and run erl, i get 'Error 2 executing '/usr/local/lib/erlang/erts-47.4.1/bin/jam' after looking through the build output in a little more detail, i noticed that some of the functions to manage the terminfo stuff in `ttsl_drv.c' were'nt getting defined. so i tried fiddling with the includes for the curses and term headers and it still didn;t help. it's probably something w/ my machine, however any suggestions would be greatly appreciated. Mike P.S. i applied the patch for the ``potato'' debian (which i;m using) that i found on the ``bugs'' page at erlang.org -- still didn't work for me. On 20 Oct 1999, Torbjorn Tornkvist wrote: > > I think Klacke posted a patch some months ago. > I can't find it now but try to compile with: > > make -k > > and disrgard the the erl_interface things. They > are note crucial for running Erlang (I think... :-) > > Cheers /Tobbe > > > > > > From sam@REDACTED Wed Oct 20 11:27:07 1999 From: sam@REDACTED (Samuel Tardieu) Date: Wed, 20 Oct 1999 11:27:07 +0200 Subject: build problems In-Reply-To: References: Message-ID: <1999-10-20-11-27-07+trackit+sam@debian.org> Here are the patches I use for my own compilation (I'm not the Debian maintainer of Erlang). Patches called *.official.dpatch come from the Erlang home page. Sam -------------- next part -------------- #PATCHOPTIONS: -p1 --- erlang-47.4.1.orig/erts/system/emulator/runtime/bif.c Tue Feb 23 10:28:55 1999 +++ erlang-47.4.1/erts/system/emulator/runtime/bif.c Fri May 21 12:22:24 1999 @@ -55,7 +55,9 @@ #include "dist.h" #include "erl_version.h" -#if defined(sparc) +/* this is buggy -- this test should be for SunOS, not for Sparc + * I've done this hack for now, below are more */ +#if defined(sparc) && ! defined(linux) #include #define PERFMON_SETPCR _IOW('P', 1, unsigned long long) #define PERFMON_GETPCR _IOR('P', 2, unsigned long long) @@ -3940,7 +3942,7 @@ return 0; return attributes_for_module(BIF_P, tp[0], tp[1]); #endif -#if defined(__GNUC__) && defined(sparc) +#if defined(__GNUC__) && defined(sparc) && ! defined(linux) } else if (sel == am_ultrasparc_set_pcr) { unsigned long long tmp; int fd; @@ -4115,7 +4117,7 @@ } BIF_RET(res); #endif -#if defined(__GNUC__) && defined(sparc) +#if defined(__GNUC__) && defined(sparc) && ! defined(linux) } else if (BIF_ARG_1 == am_ultrasparc_read_tick1) { register unsigned high asm("%l0"); register unsigned low asm("%l1"); -------------- next part -------------- #PATCHOPTIONS: -p0 --- lib/gs/c_src/lib/tcl7.6/generic/tclPosixStr.c.orig Tue Sep 28 15:45:49 1999 +++ lib/gs/c_src/lib/tcl7.6/generic/tclPosixStr.c Tue Sep 28 15:46:37 1999 @@ -336,7 +336,7 @@ #ifdef ENXIO case ENXIO: return "ENXIO"; #endif -#ifdef EOPNOTSUPP +#if defined (EOPNOTSUPP) && (!defined (ENOTSUP) || (EOPNOTSUPP != ENOTSUP)) case EOPNOTSUPP: return "EOPNOTSUPP"; #endif #ifdef EPERM @@ -785,2 +785,2 @@ #endif -#ifdef EOPNOTSUPP +#if defined (EOPNOTSUPP) && (!defined (ENOTSUP) || (EOPNOTSUPP != ENOTSUP)) -------------- next part -------------- #PATCHOPTIONS: -p1 --- erlang-47.4.1/erts/autoconf/configure.ORIG Tue Feb 23 16:16:17 1999 +++ erlang-47.4.1/erts/autoconf/configure Wed Sep 1 15:00:35 1999 @@ -1291,7 +1291,7 @@ case $host in - *-*-solaris*|free_source) + *-*-solaris*|free_source|*-univel-*) if test -x /usr/ucb/install; then INSTALL="/usr/ucb/install -c" fi -------------- next part -------------- #PATCHOPTIONS: -p1 --- erlang-47.4.1.orig/erts/autoconf/config.guess Tue Feb 23 17:16:18 1999 +++ erlang-47.4.1/erts/autoconf/config.guess Mon May 24 18:22:12 1999 @@ -347,6 +347,8 @@ echo "${UNAME_MACHINE}-unknown-linux" ; exit 0 elif echo "$ld_help_string" | grep >/dev/null 2>&1 "supported emulations: m68klinux"; then echo "${UNAME_MACHINE}-unknown-linuxaout" ; exit 0 + elif test "${UNAME_MACHINE}" = "ppc" ; then + echo "powerpc-unknown-linux"; exit 0 elif test "${UNAME_MACHINE}" = "alpha" ; then echo alpha-unknown-linux ; exit 0 else -------------- next part -------------- #PATCHOPTIONS: -p1 --- erlang-47.4.1/erts/system/emulator/runtime/erl_posix_str.c.ORIG Tue Feb 23 16:28:59 1999 +++ erlang-47.4.1/erts/system/emulator/runtime/erl_posix_str.c Thu May 27 16:22:14 1999 @@ -362,7 +362,7 @@ #ifdef ENXIO case ENXIO: return "enxio"; #endif -#ifdef EOPNOTSUPP +#if defined(EOPNOTSUPP) && (!defined(ENOTSUP) || (EOPNOTSUPP != ENOTSUP)) case EOPNOTSUPP: return "eopnotsupp"; #endif #ifdef EPERM From mskow@REDACTED Wed Oct 20 19:12:04 1999 From: mskow@REDACTED (Michael Skowronski) Date: Wed, 20 Oct 1999 13:12:04 -0400 (EDT) Subject: build problems In-Reply-To: <14349.52651.903006.375935@kricka.bluetail.com> Message-ID: i get the same errors as you. apparently, debian ``potato'' has the same problems. i'm trying to get ``buyin'' from the technical staff to replace some of the backend things that we're doing in java w/ erlang so i need to demonstrate that i can at least build it! i'm going to keep trying and thanks for everyone's help. Mike On Wed, 20 Oct 1999, Klacke wrote: > > Michael Skowronski writes: > > after looking through the build output in a little more detail, i noticed > > that some of the functions to manage the terminfo stuff in `ttsl_drv.c' > > were'nt getting defined. so i tried fiddling with the includes for the > > curses and term headers and it still didn;t help. > > > I had similar (And still have) problems with the ttsl_drv.c on > some of our Redhat systems. I have no idea what's the problem was but the > following shell session seems to illustrate a serious problem > the redhat installation on host duva: > > > > duva:klacke> cat ttytest.c > > main() > { > tputs("a", 0, 0); > } > > duva:klacke> gcc ttytest.c > /tmp/ccKFadDK.o: In function `main': > /tmp/ccKFadDK.o(.text+0xd): undefined reference to `tputs' > collect2: ld returned 1 exit status > > > duva:klacke> gcc ttytest.c -ltermcap > /usr/bin/ld: cannot open -ltermcap: No such file or directory > collect2: ld returned 1 exit status > > duva:klacke> nm /lib/libtermcap.so.2 | grep tputs > 00001abc T tputs > 0000361c B tputs_baud_rate > > duva:klacke> gcc ttytest.c -ltermcap -L/lib > /usr/bin/ld: cannot open -ltermcap: No such file or directory > collect2: ld returned 1 exit status > > duva:klacke> cat /etc/redhat-release > Red Hat Linux release 6.0 (Hedwig) > > > > Can you compile ttytest.c > > > /klacke > From per@REDACTED Wed Oct 20 20:39:12 1999 From: per@REDACTED (Per Hedeland) Date: Wed, 20 Oct 1999 20:39:12 +0200 (MET DST) Subject: build problems Message-ID: <199910201839.UAA23680@aalborg.du.uab.ericsson.se> Um, Tobbe and Klacke, please feel free to Cc the list...:-) Michael Skowronski wrote: > >On Wed, 20 Oct 1999, Klacke wrote: > >> duva:klacke> gcc ttytest.c -ltermcap -L/lib >> /usr/bin/ld: cannot open -ltermcap: No such file or directory >> collect2: ld returned 1 exit status Try with -L *before* -l, those flags are normally intentionally position-dependant. It seems rather weird to not have /lib in the default directory list, though. --Per From wadler@REDACTED Wed Oct 20 21:05:55 1999 From: wadler@REDACTED (Philip Wadler) Date: Wed, 20 Oct 1999 15:05:55 -0400 Subject: ICFP 2000: Call for Papers Message-ID: <199910201905.PAA17628@nslocum.cs.bell-labs.com> Below is the official call-for-papers for ICFP 2000. You may prefer to view it on the web: http://www.cs.bell-labs.com/~wadler/icfp2000 This year we are experimenting with two special classes of submissions, Application letters (Applets) and Functional Pearls, to emphasize both the utility and the beauty of functional programming. If you have a nifty application or an elegant program that never quite seemed to fit the conference mold, this is your year! And of course, we also want submissions that fulfill the traditional model of a crisp new research result. See you in Montreal! -- P Call for Papers ICFP 2000: International Conference on Functional Programming Montreal, Canada; 18--20 September 2000 (associated with PLI 2000: Colloquium on Principles, Logics, and Implementations of High-Level Programming Languages) http://www.cs.bell-labs.com/~wadler/icfp2000 Scope ~~~~~ ICFP 2000 seeks original papers on the full spectrum of the art, science, and practice of functional programming. The conference invites submissions on all topics ranging from principles to practice, from foundations to features, and from abstraction to application. The scope covers all languages that encourage programming with functions, including both purely applicative and imperative languages, as well as languages that support objects and concurrency. Papers setting new directions in functional programming are particularly encouraged. Topics of interest include, but are not limited to, the following: FOUNDATIONS: formal semantics, lambda calculus, type theory, monads, continuations, control, state, effects. DESIGN: modules and type systems, concurrency and distribution, components and composition, relations to object-oriented and logic programming, multiparadigm programming. IMPLEMENTATION: abstract machines, compile-time and run-time optimization, just-in-time compilers, memory management, foreign-function and component interfaces. TRANSFORMATION AND ANALYSIS: abstract interpretation, partial evaluation, program transformation, theorem proving, specification and verification. APPLICATIONS: scientific and numerical computing, symbolic computing and artificial intelligence, systems programming, databases, graphic user interfaces, multimedia programming, web programming. EXPERIENCE: FP in education and industry, ramifications on other paradigms and computing disciplines. The conference also solicits two special classes of submissions, application letters and functional pearls, described below. Application Letters (Applets) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Especially in industry, users of functional languages may be fully occupied writing functional programs, and may lack the time to write a full paper describing their work. Thus attendees often hear only from those developing functional languages --- the users are too busy using them. In order to attract greater participation from users, the conference solicits application letters describing experience using functional languages to real-life problems. Such papers might typically be about six pages (any length up to twelve pages is fine), and may be judged by interest of the application and novel use of functional languages as opposed to a crisp new research result. Functional Pearls ~~~~~~~~~~~~~~~~~ Program committees traditionally expect a paper to make a contribution of a certain size. Ideas that are small, rounded, and glow with their own light may have a number of venues, but conferences are not typically among them. (Among the outlets have been columns such as Bentley's Programming Pearls in Communications of the ACM, Rem's Small Programming Exercises in Science of Computer Programming, and Barendregt's Theoretical Pearls and Bird's Functional Pearls in the Journal of Functional Programming.) As an experiment, this year the conference invites papers that develop a short functional program. Such papers might typically be about six pages (any length up to twelve pages is fine), and may be judged by elegance of development and clarity of expression as opposed to a crisp new research result. Submission guidelines ~~~~~~~~~~~~~~~~~~~~~ Authors should submit a 100-200 word abstract and a full paper. Submissions should be no more than 12 pages in standard ACM conference format: two columns, nine point font on ten point baseline, page 20pc (3.33in) wide and 54pc (9in) tall with a column gutter of 2pc (0.33in). Submissions that do not meet these guidelines will not be considered. Application letters and functional pearls should be labeled as such on the first page. They may be any length up to the full twelve pages, though shorter submissions are welcome. Submitted papers must have content that has not previously been published in other conferences or refereed venues, and simultaneous submission to other conferences or refereed venues is unacceptable. Each paper should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, saying why it is significant, and comparing it with previous work. Authors should strive to make the technical content of their papers understandable to a broad audience. Important dates and submission details ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Submission Deadline 13.00 EST (18.00 UTC), 1 March 2000 Submission Length 12 pages in ACM conference format Notification of Acceptance or Rejection8 May 2000 Final Paper Due 12 June 2000 ICFP '00 in Montreal 18--20 September 2000 The submission deadline and length above are firm. Submissions will be carried out electronically via the Web. (The exact method will be determined at a later date.) Papers must be submitted as PostScript documents that are interpretable by Ghostscript, or in PDF format, and they must be printable on both USLetter and A4 paper. Individuals for which this requirement is a hardship should contact the program chair. Authors of accepted papers will be required to sign ACM copyright release forms. Program Committee ~~~~~~~~~~~~~~~~~ Program Chair Program Committee ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ Philip Wadler Richard Bird, Oxford Bell Labs, Lucent Technologies Charles Consel, IRISA 600 Mountain Ave, room 2T-402 Susan Eisenbach, Imperial Murray Hill, NJ 07974-0636, USA Fergus Henderson, Melbourne phone: +1 908 582 4004 Ralf Hinze, Bonn http://www.cs.bell-labs.com/~wadler Shriram Krishnamurthi, Rice wadler@REDACTED Xavier Leroy, INRIA/Trusted Logic Eugenio Moggi, Genova General Chair Greg Morisset, Cornell ~~~~~~~~~~~~~ Atsushi Ohori, Kyoto Martin Odersky Catuscia Palamedissi, Penn State Ecole Polytechnique Federale de Lausanne Andrew Wright, Intertrust From klacke@REDACTED Wed Oct 20 21:18:22 1999 From: klacke@REDACTED (Klacke) Date: Wed, 20 Oct 1999 21:18:22 +0200 (CEST) Subject: build problems In-Reply-To: <199910201839.UAA23680@aalborg.du.uab.ericsson.se> References: <199910201839.UAA23680@aalborg.du.uab.ericsson.se> Message-ID: <14350.5502.478348.178018@duva.bluetail.com> > >> duva:klacke> gcc ttytest.c -ltermcap -L/lib > >> /usr/bin/ld: cannot open -ltermcap: No such file or directory > >> collect2: ld returned 1 exit status > > Try with -L *before* -l, those flags are normally intentionally > position-dependant. It seems rather weird to not have /lib in the > default directory list, though. > The order of the flags isn't the problem here, Linux is The only way to compile the ttytest.c program on some (broken) versions of Linux is by explicitly linking with the .so file. The way I feel about this is that the behaviour is so broken so I don't even care to investigate what the reasons might be. Ignore the error and upgrade/downgrade the linux installation is the proper remedy. /klacke duva:klacke> gcc ttytest.c -L/lib -ltermcap /usr/bin/ld: cannot open -ltermcap: No such file or directory collect2: ld returned 1 exit status duva:klacke> From ug-erlang@REDACTED Wed Oct 20 22:41:52 1999 From: ug-erlang@REDACTED (David Brown) Date: Wed, 20 Oct 1999 13:41:52 -0700 (PDT) Subject: build problems In-Reply-To: <14350.5502.478348.178018@duva.bluetail.com> References: <199910201839.UAA23680@aalborg.du.uab.ericsson.se> <14350.5502.478348.178018@duva.bluetail.com> Message-ID: <14350.10512.979808.973544@opus.davidb.org> Klacke writes: > > > > >> duva:klacke> gcc ttytest.c -ltermcap -L/lib > > >> /usr/bin/ld: cannot open -ltermcap: No such file or directory > > >> collect2: ld returned 1 exit status > > > > Try with -L *before* -l, those flags are normally intentionally > > position-dependant. It seems rather weird to not have /lib in the > > default directory list, though. > > try gcc ttytest.c -lncurses Most Linux distributions don't have a libtermcap at all. Dave Brown From vladdu@REDACTED Thu Oct 21 17:27:39 1999 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Thu, 21 Oct 1999 17:27:39 +0200 Subject: Win32 build with gcc? Message-ID: <19991021152658.52728.qmail@hotmail.com> Hi all! Did anyone try to compile under Win32 with gcc? I notice there are only VC++ makefiles... If yes, are there any special things to have in mind? regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From klacke@REDACTED Thu Oct 21 22:55:11 1999 From: klacke@REDACTED (Klacke) Date: Thu, 21 Oct 1999 22:55:11 +0200 (CEST) Subject: Win32 build with gcc? In-Reply-To: <19991021152658.52728.qmail@hotmail.com> References: <19991021152658.52728.qmail@hotmail.com> Message-ID: <14351.32175.753961.489231@duva.bluetail.com> > > Did anyone try to compile under Win32 with gcc? I notice there are only VC++ makefiles... If yes, are there any special things to have in mind? > To my knowledge, no one has done this yet. I don't know about the OTP team and what they've done, however the next OSE release will only come with the beam compiler. This is a threaded code compiler where the interpreter takes advantage of gcc specific features with named labels. So there's bound to be some gcc stuff there then. We'll just have to patiently wait and see. Today, the win32-erlang runs only with the old byte code interpreter, jam. And the build process in the released code is certainly not made for win32 builds. /klacke From Olivier.Lefevre@REDACTED Thu Oct 21 23:13:06 1999 From: Olivier.Lefevre@REDACTED (Olivier.Lefevre@REDACTED) Date: Thu, 21 Oct 1999 17:13:06 -0400 Subject: Win32 build with gcc? In-Reply-To: <14351.32175.753961.489231@duva.bluetail.com> Message-ID: > [...] however the next OSE release will only come with the beam compiler. This > is a threaded code compiler where the interpreter takes advantage of gcc > specific features with named labels. Does that mean that, starting with that release, compilation with anything else but gcc will become impossible? Regards, -- O.L. PS: Please ignore junk below. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From klacke@REDACTED Thu Oct 21 23:41:26 1999 From: klacke@REDACTED (Klacke) Date: Thu, 21 Oct 1999 23:41:26 +0200 (CEST) Subject: Win32 build with gcc? In-Reply-To: References: <14351.32175.753961.489231@duva.bluetail.com> Message-ID: <14351.34950.504657.952031@duva.bluetail.com> Olivier.Lefevre@REDACTED writes: > Does that mean that, starting with that release, > compilation with anything else > but gcc will become impossible? > I don't know, However I would imagine that's the case. Unless someone from the OTP team enlighten us here, we'll just have to wait and see. /klacke From etxuwig@REDACTED Fri Oct 22 00:45:23 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 22 Oct 1999 00:45:23 +0200 (MET DST) Subject: Win32 build with gcc? In-Reply-To: <14351.34950.504657.952031@duva.bluetail.com> Message-ID: As I understand it, beam can be compiled using any ANSI C compiler. It just means it won't use the "computed gotos" supported by the gcc compiler, and thus it will be slightly less efficient. /Uffe On Thu, 21 Oct 1999, Klacke wrote: klacke> klacke>Olivier.Lefevre@REDACTED writes: klacke> > Does that mean that, starting with that release, klacke> > compilation with anything else klacke> > but gcc will become impossible? klacke> > klacke> klacke>I don't know, However I would imagine that's the case. klacke>Unless someone from the OTP team enlighten us here, we'll just klacke>have to wait and see. klacke> klacke>/klacke klacke> Ulf Wiger, Chief Designer AXD 301 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 hakan@REDACTED Fri Oct 22 09:57:54 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 22 Oct 1999 09:57:54 +0200 (MET DST) Subject: The service broker - a new user contribution Message-ID: The service broker is a brand new user contribution at www.erlang.org. It is a simple (but hopefully useful) mechanism for brokering and supervision of services for service providers and their users. When either part of the service dies or selects to disconnect from the service, the other part is notified about this. The service broker may be for many purposes, such as dynamic syncronizing of application startup, protocol negotiations, inter application supervision, implementation of safe calls etc. A man page (as comment in the module) and a test program are also supplied. /H?kan From kenneth@REDACTED Fri Oct 22 10:51:15 1999 From: kenneth@REDACTED (Kenneth Lundin) Date: Fri, 22 Oct 1999 10:51:15 +0200 Subject: Win32 build with gcc? References: Message-ID: <38102583.929BDE68@erix.ericsson.se> Olivier.Lefevre@REDACTED wrote: > > [...] however the next OSE release will only come with the beam compiler. This > > is a threaded code compiler where the interpreter takes advantage of gcc > > specific features with named labels. > > Does that mean that, starting with that release, compilation with anything else > but gcc will become impossible? > > Regards, > > -- O.L. > In the next release of OSE which only includes the beam system compilation can still be done with any ANSI-C compiler (i.e unchanged situation). But to get full speed out of the beam system 1 file (the emulator) need to be compiled with gcc in order to take advantage of the "GOTO Variable" feature available in gcc. The rest of the files can be compiled with e.g the MSC++ compiler , that's how we do it. The gcc compiled file is processed by a filter (which is delivered) to make it compatible with the MSC++ linker. The performance will be significantly better when the gcc specific feature is used. /Kenneth (Erlang/OTP development team) -- Kenneth Lundin Ericsson Utvecklings AB kenneth@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 57 25 125 25 ?lvsj? From vladdu@REDACTED Fri Oct 22 11:40:17 1999 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Fri, 22 Oct 1999 11:40:17 CEST Subject: Embedded Erlang Message-ID: <19991022094017.1029.qmail@hotmail.com> > Did anyone try to compile under Win32 with gcc? I notice there are only VC++ makefiles... If yes, are there any special things to have in mind? I feel I have to reformulate slightly my question: will there be any gcc-based makefiles? The MS ones are not compatible, and the "release" ones are not intended for Windows... My intention is actually to try to cross-compile Erlang for an embedded system, stripping away a lot of stuff that's not needed... Maybe it would be easier to do from Linux than from Windows, since there the compile already uses gcc, and my cross-compiler is also gcc? thanks Vlad ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From sam@REDACTED Fri Oct 22 12:35:00 1999 From: sam@REDACTED (Samuel Tardieu) Date: Fri, 22 Oct 1999 12:35:00 +0200 Subject: Embedded Erlang In-Reply-To: <19991022094017.1029.qmail@hotmail.com>; from vladdu@hotmail.com on Fri, Oct 22, 1999 at 11:40:17AM +0200 References: <19991022094017.1029.qmail@hotmail.com> Message-ID: <1999-10-22-12-35-00+trackit+sam@inf.enst.fr> | My intention is actually to try to cross-compile Erlang for an embedded | system, stripping away a lot of stuff that's not needed... Maybe it would be | easier to do from Linux than from Windows, since there the compile already | uses gcc, and my cross-compiler is also gcc? Please let me know if you really start something, as this is one of my project for November: we have a small robot with 32MB of RAM, eCos and TCP/IP and I'd like to have Erlang running on top of it. From vladdu@REDACTED Fri Oct 22 13:03:35 1999 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Fri, 22 Oct 1999 13:03:35 CEST Subject: Embedded Erlang Message-ID: <19991022110336.9533.qmail@hotmail.com> >| My intention is actually to try to cross-compile Erlang for an embedded >system >Please let me know if you really start something, as this is one of my >project for November: we have a small robot with 32MB of RAM, eCos and >TCP/IP and I'd like to have Erlang running on top of it. Sure, but my project is something more like 32KB and a dedicated OS... (If anyone wonders, the hardware platform is the Lego Mindstorms RCX, a robot controller unit. Which made me realize one thing: the CPU is 8 bit... maybe it's not as simple a task as I have thought to try to port Erlang... hmmmm...) /Vlad ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From Matthias.Lang@REDACTED Fri Oct 22 13:11:42 1999 From: Matthias.Lang@REDACTED (Matthias.Lang@REDACTED) Date: Fri, 22 Oct 1999 13:11:42 +0200 (MET DST) Subject: Embedded Erlang In-Reply-To: <1999-10-22-12-35-00+trackit+sam@inf.enst.fr> References: <19991022094017.1029.qmail@hotmail.com> <1999-10-22-12-35-00+trackit+sam@inf.enst.fr> Message-ID: <14352.17618.153467.617466@martell> Vlad wrote: > | My intention is actually to try to cross-compile Erlang for an embedded > | system, stripping away a lot of stuff that's not needed... Maybe A few projects here use Erlang cross-compiled to run on VxWorks, but I don't think that's open sourced. I.e. it's possible. The stripping away part is a bit more work---OTP has so many internal dependencies that even simple programs tend to pull in almost all of OTP. mml From sam@REDACTED Fri Oct 22 13:23:14 1999 From: sam@REDACTED (Samuel Tardieu) Date: Fri, 22 Oct 1999 13:23:14 +0200 Subject: Embedded Erlang In-Reply-To: <19991022110336.9533.qmail@hotmail.com>; from vladdu@hotmail.com on Fri, Oct 22, 1999 at 01:03:35PM +0200 References: <19991022110336.9533.qmail@hotmail.com> Message-ID: <1999-10-22-13-23-15+trackit+sam@inf.enst.fr> | Sure, but my project is something more like 32KB and a dedicated OS... Well, the less the better :))) | Which made me realize one thing: the CPU is 8 bit... maybe it's not as | simple a task as I have thought to try to port Erlang... hmmmm...) As soon as you have a GCC port, it should be able to emulate 32 and 64 bits operations. From vladdu@REDACTED Fri Oct 22 14:08:28 1999 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Fri, 22 Oct 1999 14:08:28 CEST Subject: Embedded Erlang Message-ID: <19991022120828.22885.qmail@hotmail.com> | Sure, but my project is something more like 32KB and a dedicated OS... >Well, the less the better :))) Okay, I will let you know when I am ready to start! | Which made me realize one thing: the CPU is 8 bit... maybe it's not as | simple a task as I have thought to try to port Erlang... hmmmm...) >As soon as you have a GCC port, it should be able to emulate 32 and 64 bits operations. Yes, the full suite of GCC tools exists, so it should not be a problem. I am still not sure if emulating is enough, because the memory management structures must be adapted... On the other hand, the memory management and garbage collector might have to be rewritten completely........ I will have to take one step at a time... :-) /Vlad ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From jim@REDACTED Fri Oct 22 21:42:00 1999 From: jim@REDACTED (Jim Larson) Date: Fri, 22 Oct 1999 12:42:00 -0700 Subject: Passive sockets Message-ID: <199910221942.MAA24733@lefse.jetcafe.org> I'm running Open-source Erlang 47.4.1 on FreeBSD 2.2.8. The online documentation states that passive mode does not currently work for UDP sockets. I've tried to use passive mode for TCP sockets, but I can't seem to get that working either. Do passive-mode TCP sockets work for 47.4.1? How about the forthcoming release? Thanks, Jim From per@REDACTED Fri Oct 22 22:40:35 1999 From: per@REDACTED (Per Hedeland) Date: Fri, 22 Oct 1999 22:40:35 +0200 (MET DST) Subject: Passive sockets Message-ID: <199910222040.WAA27392@super.du.uab.ericsson.se> Jim Larson wrote: > >I'm running Open-source Erlang 47.4.1 on FreeBSD 2.2.8. > >The online documentation states that passive mode does not currently >work for UDP sockets. I've tried to use passive mode for TCP sockets, >but I can't seem to get that working either. > >Do passive-mode TCP sockets work for 47.4.1? Despite what the docs say, both passive UDP and TCP sockets seem to work just fine in 47.4.1 (tried it on Solaris 2.6 and FreeBSD 3.1, with {packet, raw}). What problems are you having? --Per Hedeland per@REDACTED From per@REDACTED Fri Oct 22 23:28:28 1999 From: per@REDACTED (Per Hedeland) Date: Fri, 22 Oct 1999 23:28:28 +0200 (MET DST) Subject: Embedded Erlang Message-ID: <199910222128.XAA27788@super.du.uab.ericsson.se> Vlad Dumitrescu wrote: > >>| My intention is actually to try to cross-compile Erlang for an embedded >>system > >Sure, but my project is something more like 32KB and a dedicated OS... Um, I don't want to sound negative, but *32KB*? What minor part of the language do you plan to actually leave *in*?:-) Seriously, the "size" command on FreeBSD (i.e. x86 arch) says text data bss dec hex filename 279497 44564 113454 437515 6ad0b .../erts-47.4.1/bin/jam - i.e. just the runtime system is almost 10 times that in pure native machine *code* (which doesn't include anything from the C library), and then you need a bit of data (data+bss above), and it would be nice to be able to actually fit some Erlang code in there too...:-) I'm sure it would be possible to reduce that if you decided to leave out some parts that you didn't need (this requires intimate understanding of the runtime system C code of course), but even the basic emulator (just instruction interpreter - no BIFs, processes, garbage collection...) is almost 32K code. I really do hope that you succeed in building a "really" "embedded" Erlang, but I think you'll stand a better chance of doing that with more realistic expectations... --Per Hedeland per@REDACTED From felty@REDACTED Fri Oct 22 23:30:03 1999 From: felty@REDACTED (Amy Felty) Date: Fri, 22 Oct 1999 17:30:03 -0400 Subject: PLI 2000: Call for Workshops Message-ID: <199910222130.RAA17832@nslocum.cs.bell-labs.com> CALL FOR WORKSHOP PROPOSALS PRINCIPLES, LOGICS, AND IMPLEMENTATIONS OF HIGH-LEVEL PROGRAMMING LANGUAGES (PLI'00) Montreal, Canada, September 18-23, 2000 http://www.cs.yorku.ca/pli-00 Submission deadline: January 7, 2000 Proposals are invited for workshops at PLI'00, a federation of colloquia which includes ICFP 2000 (ACM-SIGPLAN International Conference on Functional Programming) and PPDP 2000 (ACM-SIGPLAN 2nd International Conference on Principles and Practice of Declarative Programming), to be held in Montreal, September 18-23, 2000. (Details of these and other affiliated events are available from the Web pages listed below.) Such proposals should be sent to the Workshop Chair of PLI'00, should be no longer than two pages and should describe the topic of the workshop (that should relate broadly to declarative and/or functional programming), the names and contact information of the organizers, the expected number of participants and duration, and any other factors relevant to its selection. The preference is for day-long workshops, but longer or shorter ones will be considered. THE DEADLINE FOR RECEIPT OF PROPOSALS IS JANUARY 7, 2000. Proposals will be evaluated by the PLI'00 Workshop Chair, the ICFP and PPDP Program Chairs, and the ICFP General Chair. Acceptance decisions will be made by February 1, 2000. A more detailed call for workshop proposals is available at http://www.cs.yorku.ca/pli-00/workshops.html Evaluation Committee: Amy Felty (Bell Labs), PLI'00 Workshop Chair, felty@REDACTED Maurizio Gabbrielli (University of Udine), PPDP 2000 Program Co-Chair Martin Odersky (EPFL Lausanne), ICFP 2000 General Chair Frank Pfenning (Carnegie Mellon University), PPDP 2000 Program Co-Chair Philip Wadler (Bell Labs), ICFP 2000 Program Chair PLI'00 Web Page: http://www.cs.yorku.ca/pli-00 ICFP 2000 Web Page: http://diwww.epfl.ch/~odersky/icfp2000 PPDP 2000 Web Page: http://www.cs.yorku.ca/ppdp-00 From jim@REDACTED Sat Oct 23 01:15:49 1999 From: jim@REDACTED (Jim Larson) Date: Fri, 22 Oct 1999 16:15:49 -0700 Subject: Passive sockets In-Reply-To: Your message of "Fri, 22 Oct 1999 22:40:35 +0200." <199910222040.WAA27392@super.du.uab.ericsson.se> Message-ID: <199910222315.QAA25079@lefse.jetcafe.org> In message <199910222040.WAA27392@REDACTED> Per Hedeland writes: >Despite what the docs say, both passive UDP and TCP sockets seem to >work just fine in 47.4.1 (tried it on Solaris 2.6 and FreeBSD 3.1, >with {packet, raw}). What problems are you having? Ack - you're right. I must not be setting the controlling_process correctly. Here's a correction for the documentation team: the kernel's gen_udp:recv() may return {ok, {IP, Port, Packet}} instead of {ok, Packet}. Jim From per@REDACTED Sat Oct 23 01:36:16 1999 From: per@REDACTED (Per Hedeland) Date: Sat, 23 Oct 1999 01:36:16 +0200 (MET DST) Subject: Passive sockets Message-ID: <199910222336.BAA29050@super.du.uab.ericsson.se> Jim Larson wrote: >Here's a correction for the documentation team: the kernel's >gen_udp:recv() may return {ok, {IP, Port, Packet}} instead of {ok, >Packet}. Thanks, this has already been fixed in the upcoming release (it never returns {ok, Packet} of course). --Per From vladdu@REDACTED Sat Oct 23 16:38:02 1999 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Sat, 23 Oct 1999 16:38:02 +0200 Subject: Embedded Erlang References: <199910222128.XAA27788@super.du.uab.ericsson.se> Message-ID: <19991023143650.27239.qmail@hotmail.com> ----- Original Message ----- From: Per Hedeland > Um, I don't want to sound negative, but *32KB*? What minor part of the > language do you plan to actually leave *in*?:-) I am well aware of the problems. It is very possible that in order to do that, a complete rewrite of the run-time should be done... A lot of work, but possible. What I am more worried about is for example the memory management. 8 bit CPU=16 bit addresses; 4 bits used for type management => 4k of heap memory... Not at all enough! Note: "possible" does not mean necessarily "worth the amount of work". But I think it is an interesting thing to look into. /Vlad From per@REDACTED Sat Oct 23 23:56:56 1999 From: per@REDACTED (Per Hedeland) Date: Sat, 23 Oct 1999 23:56:56 +0200 (MET DST) Subject: Embedded Erlang Message-ID: <199910232156.XAA08284@super.du.uab.ericsson.se> Vlad Dumitrescu wrote: >I am well aware of the problems. OK then, that's the important thing - good luck! --Per From jim@REDACTED Sun Oct 24 01:27:42 1999 From: jim@REDACTED (Jim Larson) Date: Sat, 23 Oct 1999 16:27:42 -0700 Subject: Third-party send to active and passive TCP sockets Message-ID: <199910232327.QAA29802@lefse.jetcafe.org> I'm running open-source Erlang 47.4.1 on FreeBSD 2.2.8. I've noticed some interesting behavior regarding which processes can use the gen_tcp:send() call to send data over a TCP socket. A single process P can open the socket, send data with gen_tcp:send(), and receive the reply in either active or passive mode. A process P can open the socket and spawn a child C1, and make C1 the controlling process of the socket with gen_tcp:controlling_process(). P can then call gen_tcp:send() to send data, and C1 can receive the reply[1] in either active or passive mode. However, if P forks off a second child C2 which is dedicated to sending data with gen_tcp:send(), this works in active mode but doesn't in passive mode - C2's call to gen_tcp:send() never returns. Is this behavior deliberate and correct? I've tried to read through the code for gen_tcp.erl, inet_tcp.erl, and inet_drv.c, but I can't see where the difference in behavior comes up. For what it's worth, I'm trying to implement a gen_server module that implements the client-side logic of a popular RPC package, using TCP as a transport protocol. The data rates may be intense, so to avoid running the socket open-loop, I'm trying to have dedicated input and output processes to read from and write to (respectively) the passive socket. The parent process "P" above is the server process, and should never block, thus shouldn't do I/O with a passive socket directly. Thanks in advance, Jim [1]: You have to do an interesting little dance when you do this, since the child can't call gen_tcp:recv() until it is the controlling process, and it can't be made the controlling process until the parent has spawned it to get the Pid and called gen_tcp:controlling_process(): Parent: {ok, Socket} = gen_tcp:connect(...), Child = spawn(...), gen_tcp:controlling_process(Socket, Child), Child ! go_ahead, % Signal the child gen_tcp:send(Socket, ...) Child: %% Can't recv immediately - must wait for signal from parent. receive go_ahead -> true % We're now the controlling process end, case gen_tcp:recv(Socket, 0) of ... This might be worth a footnote in the documentation? From Sean.Hinde@REDACTED Mon Oct 25 16:44:19 1999 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 25 Oct 1999 15:44:19 +0100 Subject: Using application behaviour to just change a gen event handler Message-ID: Hi Everyone, I have a requirement for an "application" which doesn't have any processes of its own but has a set of library type functions and installs an event handler in the local alarm_handler gen_event process. The application behaviour appears to require the Pid of the top level supervisor to be returned but I won't have one in my case. Any suggestions as to how to install the new event handler during application startup while maintaining the API rules of application? Thanks, Sean Hinde -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/ms-tnef Size: 2295 bytes Desc: not available URL: From mbj@REDACTED Mon Oct 25 17:05:33 1999 From: mbj@REDACTED (Martin Bjorklund) Date: Mon, 25 Oct 1999 17:05:33 +0200 Subject: Using application behaviour to just change a gen event handler In-Reply-To: Your message of "Mon, 25 Oct 1999 15:44:19 +0100" References: Message-ID: <19991025170533K.mbj@bluetail.com> Sean Hinde wrote: > Hi Everyone, > > I have a requirement for an "application" which doesn't have any processes > of its own but has a set of library type functions and installs an event > handler in the local alarm_handler gen_event process. > > The application behaviour appears to require the Pid of the top level > supervisor to be returned but I won't have one in my case. > > Any suggestions as to how to install the new event handler during > application startup while maintaining the API rules of application? Here are two alternatives: 1) Make the application "code-only", and provide an API function for others to use, which installs you handler in alarm_handler. 2) Create a 'supervisor' with one child which receives a message from alarm_handler if your module crashes. If this happens, this child process calls exit/1, and the supervisor restarts the child, which reinstalls the handler module in alarm_handler. Here's some code to do the trick: /martin %%%----------------------------------------------------------------- %%% Handler supervisor %%%----------------------------------------------------------------- start_link() -> proc_lib:start_link(?MODULE, init, [self(), self()]). init(Caller, Parent) -> process_flag(trap_exit, true), register(?MY_NAME, self()), Handler = install(), link(Handler), proc_lib:init_ack(Caller, {ok, self()}), loop(Parent, Handler). loop(Parent, Handler) -> receive {'EXIT', Parent, Reason} -> %% Parent orders shutdown uninstall(), exit(Reason); {gen_event_EXIT, ?MY_HANDLER_MODULE, Reason} -> %% My handler module crashed exit(Reason); {'EXIT', Handler, Reason} -> %% The gen_event manager crashed exit(Reason); {system, From, Req} -> sys:handle_system_msg(Req, From, Parent, ?MODULE, [], Handler); _ -> loop(Parent) end. %%----------------------------------------------------------------- %% Callback functions for system messages handling. %%----------------------------------------------------------------- system_continue(Parent, _, Handler) -> loop(Parent, Handler). system_terminate(Reason, _Parent, _, _Handler) -> uninstall(), exit(Reason). system_code_change(Handler, _Module, OldVsn, Extra) -> {ok, Handler}. install() -> Pid = whereis(?HANDLER_NAME), ok = gen_event:add_sup_handler(Pid, ?MY_HANDLER_MODULE, []), Pid. uninstall() -> gen_event:delete_handler(?HANDLER_NAME, ?MY_HANDLER_MODULE, []). From Sean.Hinde@REDACTED Mon Oct 25 18:05:35 1999 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 25 Oct 1999 17:05:35 +0100 Subject: No subject Message-ID: > 2) Create a 'supervisor' with one child which receives a message from > alarm_handler if your module crashes. If this happens, this child > process calls exit/1, and the supervisor restarts the child, which > reinstalls the handler module in alarm_handler. > > Here's some code to do the trick: > > > /martin I used your code with a few changes to allow passing in the handler names as startup data (and fixing the loop call arity). Fantastic, thanks. Out of interest, why did you choose to implement this as a 'made up' behaviour rather than using gen_server. Is the reason performance / simplicity, or something subtle to do with the functionality of the startup mechanism which can't be achieved using standard behaviours. Sean From etxuwig@REDACTED Mon Oct 25 18:17:35 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 25 Oct 1999 18:17:35 +0200 (MET DST) Subject: your mail In-Reply-To: Message-ID: On Mon, 25 Oct 1999, Sean Hinde wrote: Sean.H>> 2) Create a 'supervisor' with one child which receives a message from Sean.H>> alarm_handler if your module crashes. If this happens, this child Sean.H>> process calls exit/1, and the supervisor restarts the child, which Sean.H>> reinstalls the handler module in alarm_handler. Sean.H>> Sean.H>> Here's some code to do the trick: Sean.H>> Sean.H>> Sean.H>> /martin Sean.H>[...] Sean.H>Out of interest, why did you choose to implement this as a 'made up' Sean.H>behaviour rather than using gen_server. Is the reason performance / Sean.H>simplicity, or something subtle to do with the functionality of the startup Sean.H>mechanism which can't be achieved using standard behaviours. Sean.H> Sean.H>Sean Same problem, different solution, using gen_server (taken from the AXD301 project): -module(sysHandlerSup). -behaviour(gen_server). -date('98-11-16'). -author('etxuwig@REDACTED'). -export([start_link/3, start_link/4, stop/1]). -export([code_change/3]). -export([init/1, handle_info/2, handle_call/3, terminate/2]). code_change(OldVsn, State, Extra) -> {ok, State}. start_link(Name, Module, Args) -> start_link(error_logger, Name, Module, Args). start_link(EventMgr, Name, Module, Args) -> gen_server:start_link({local, Name}, sysHandlerSup, {EventMgr, Module, Args}, []). stop(Name) -> gen_server:call(Name, stop). init({EventMgr, Module, Args}) -> install(EventMgr, Module, Args), {ok, {EventMgr, Module}}. handle_call(stop, _From, S) -> {stop, normal, ok, S}. handle_info({gen_event_EXIT, Mod, Reason}, State) -> {stop, {gen_event_EXIT, Mod, Reason}, State}. terminate(Reason, {EventMgr, Module}) -> uninstall(EventMgr, Module), ok. install(EventMgr, Module, Args) -> ok = gen_event:add_sup_handler(EventMgr, Module, Args). uninstall(EventMgr, Module) -> gen_event:delete_handler(EventMgr, Module, stop). Ulf Wiger, Chief Designer AXD 301 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 aresende@REDACTED Tue Oct 26 02:44:16 1999 From: aresende@REDACTED (Amando Resendez) Date: Mon, 25 Oct 1999 18:44:16 -0600 Subject: jive Message-ID: <3814F95F.B4CBF682@citi.com.mx> Hello: Where can I get more information about Java Interface JIVE ? From Pekka.Hedqvist@REDACTED Tue Oct 26 02:00:31 1999 From: Pekka.Hedqvist@REDACTED (Pekka.Hedqvist@REDACTED) Date: Tue, 26 Oct 1999 10:00:31 +1000 (EST) Subject: jive In-Reply-To: <3814F95F.B4CBF682@citi.com.mx> References: <3814F95F.B4CBF682@citi.com.mx> Message-ID: <14356.61215.782195.116284@eddieware.eddieware.org> A good start is: http://www.erlang.org/doc/doc/lib/jive-1.2/doc/index.html But you maybe already found it and is wondering about something more specific..? From bob@REDACTED Tue Oct 26 04:51:06 1999 From: bob@REDACTED (Bob) Date: Mon, 25 Oct 1999 16:51:06 -1000 Subject: hard limits? Message-ID: <199910260251.EAA20000@hades.cslab.ericsson.net> Aloha, I've read most everything I could find in the last two days, but have not been able to find a document discussing the hard limits of Erlang. Is it accurate to say that Erlang scales to the limits of the hardware? Mnesia must have some limits on limits? I'd very much appreciate if someone could point me to an appropriate document, or give me their thoughts on the upper limits of various aspects of Erlang. Thanks, Bob From klacke@REDACTED Tue Oct 26 09:17:23 1999 From: klacke@REDACTED (Klacke) Date: Tue, 26 Oct 1999 09:17:23 +0200 (CEST) Subject: hard limits? In-Reply-To: <199910260251.EAA20000@hades.cslab.ericsson.net> References: <199910260251.EAA20000@hades.cslab.ericsson.net> Message-ID: <14357.21891.995943.395874@kricka.bluetail.com> Bob writes: > Aloha, > I've read most everything I could find in the last > two days, but have not been able to find a document > discussing the hard limits > of Erlang. There exists a large number of hard (or maybe I should say semi-hard) limits for the erlang runtime system. Just to mention a few: Number of processes. Number of ports Number of ets tables Number of open file descriptors .... As far as I know there are no docs about this at all. Some of the limits can be changed by changing a constant in the source, some cannot be changed. Some limits have to do with the underlying OS, and some to do with the runtime implementation. Which specific limit(s) is it that you are interested in ?? /klacke From Sean.Hinde@REDACTED Tue Oct 26 10:50:58 1999 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 26 Oct 1999 09:50:58 +0100 Subject: hard limits? Message-ID: I think there is also a 1G RAM limit on the BEAM process, and a 256M limit for a JAM machine. Sean > -----Original Message----- > From: Klacke [mailto:klacke@REDACTED] > Sent: 26 October 1999 08:17 > To: bob@REDACTED > Cc: erlang-questions@REDACTED > Subject: hard limits? > > > > Bob writes: > > Aloha, > > I've read most everything I could find in the last > > two days, but have not been able to find a document > > discussing the hard limits > > of Erlang. > > There exists a large number of hard (or maybe I should say > semi-hard) limits for the erlang runtime system. > > Just to mention a few: > Number of processes. > Number of ports > Number of ets tables > Number of open file descriptors > .... > > As far as I know there are no docs about this at all. Some of > the limits > can be changed by changing a constant in the source, some > cannot be changed. Some limits have to do with the underlying OS, > and some to do with the runtime implementation. > > Which specific limit(s) is it that you are interested in ?? > > /klacke > From hakan@REDACTED Tue Oct 26 11:10:15 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Tue, 26 Oct 1999 11:10:15 +0200 (MET DST) Subject: hard limits? In-Reply-To: <199910260251.EAA20000@hades.cslab.ericsson.net> Message-ID: On Mon, 25 Oct 1999, Bob wrote: bob>Is it accurate to say that Erlang scales to the limits of the hardware? Mnesia must have some limits on limits? In: http://www.ericsson.se/cslab/~hakan/mnesia_consumption.txt you may read about the resource consumption and system limits of Mnesia. It is not complete but should give you an hint of things to think about when using Mnesia. You may also take a look at some slides: http://www.ericsson.se/cslab/~hakan/mnesia_consumption.txt about the internal architecture of Mnesia. /H?kan From hakan@REDACTED Tue Oct 26 11:14:07 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Tue, 26 Oct 1999 11:14:07 +0200 (MET DST) Subject: hard limits? Message-ID: Sorry, the URL to the slides should be: http://www.ericsson.se/cslab/~hakan/mnesia_internals_slides.pdf /H?kan ---------- Forwarded message ---------- Date: Tue, 26 Oct 1999 11:10:15 +0200 (MET DST) From: Hakan Mattsson To: Bob Cc: erlang-questions@REDACTED Subject: Re: hard limits? On Mon, 25 Oct 1999, Bob wrote: bob>Is it accurate to say that Erlang scales to the limits of the hardware? Mnesia must have some limits on limits? In: http://www.ericsson.se/cslab/~hakan/mnesia_consumption.txt you may read about the resource consumption and system limits of Mnesia. It is not complete but should give you an hint of things to think about when using Mnesia. You may also take a look at some slides: http://www.ericsson.se/cslab/~hakan/mnesia_consumption.txt about the internal architecture of Mnesia. /H?kan From etxuwig@REDACTED Tue Oct 26 12:28:13 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 26 Oct 1999 12:28:13 +0200 (MET DST) Subject: hard limits? In-Reply-To: <199910260251.EAA20000@hades.cslab.ericsson.net> Message-ID: On Mon, 25 Oct 1999, Bob wrote: bob>I've read most everything I could find in the last two days, but bob>have not been able to find a document discussing the hard limits of bob>Erlang. I can't really think of any hard limits in the language itself. I'm sure you didn't mean that either, but nevertheless it's an important distinction to make. bob>Is it accurate to say that Erlang scales to the limits of the bob>hardware? Mnesia must have some limits on limits? At AXD 301, we have run into some of the limitations of the runtime system: - We ran into the 256 MB limit previously in BEAM - We ran into the limit of ca 2000 ETS tables Now, BEAM can address 1 GB, which is more than enough for us, and the ETS table limit has been raised to some 6500 or so, which makes it less likely that we'll run out of tables again (we also redesigned our software.) We've also run out of file descriptors, but that was due to an OS setting, not Erlang. Bascally, the limits change as the runtime system is improved. The ETS table limit is still unnecessarily low, because the removal of tables due to process termination involves a linear search. If someone could fix that, we could raise the ETS table limit to some absurdly high number. /Uffe Ulf Wiger, Chief Designer AXD 301 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 mbj@REDACTED Tue Oct 26 13:38:59 1999 From: mbj@REDACTED (Martin Bjorklund) Date: Tue, 26 Oct 1999 13:38:59 +0200 Subject: Using application behaviour to just change a gen event handler In-Reply-To: Your message of "Mon, 25 Oct 1999 17:05:35 +0100" References: Message-ID: <19991026133859B.mbj@bluetail.com> Sean Hinde wrote: > > 2) Create a 'supervisor' with one child which receives a message from > > alarm_handler if your module crashes. If this happens, this child > > process calls exit/1, and the supervisor restarts the child, which > > reinstalls the handler module in alarm_handler. > > > > Here's some code to do the trick: > > > > > > /martin > > > I used your code with a few changes to allow passing in the handler names as > startup data (and fixing the loop call arity). Fantastic, thanks. > > Out of interest, why did you choose to implement this as a 'made up' > behaviour rather than using gen_server. Is the reason performance / > simplicity, or something subtle to do with the functionality of the startup > mechanism which can't be achieved using standard behaviours. No reason at all. You could use Ulf's gen_server based code as well. [Ok, there must have been a reason somewhere... I probably wrote the first "gen event supervisor" in the same module as an ordinary supervisor, (or maybe another gen_server), and I didn't want any more modules. The recommendation is of course to use a separate module anyway ;) - modules are cheap!] /martin From Sean.Hinde@REDACTED Tue Oct 26 14:06:32 1999 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 26 Oct 1999 13:06:32 +0100 Subject: Supervisers who always restart their children Message-ID: Hi all, A question related to supervisors. Is it possible to define a supervisor so that it retries an infinite number of times to restart its children regardless of how often they die. I have an application where my supervised process is designed to die as a result of an external system breaking its connection, but it should always be restarted so the external system can re-connect. Thanks, Sean From per@REDACTED Tue Oct 26 14:18:29 1999 From: per@REDACTED (Per Hedeland) Date: Tue, 26 Oct 1999 14:18:29 +0200 (MET DST) Subject: Third-party send to active and passive TCP sockets Message-ID: <199910261218.OAA27576@aalborg.du.uab.ericsson.se> Jim Larson wrote: >I've noticed some interesting behavior regarding which processes >can use the gen_tcp:send() call to send data over a TCP socket. > >A single process P can open the socket, send data with gen_tcp:send(), >and receive the reply in either active or passive mode. > >A process P can open the socket and spawn a child C1, and make C1 >the controlling process of the socket with gen_tcp:controlling_process(). >P can then call gen_tcp:send() to send data, and C1 can receive >the reply[1] in either active or passive mode. > >However, if P forks off a second child C2 which is dedicated to >sending data with gen_tcp:send(), this works in active mode but >doesn't in passive mode - C2's call to gen_tcp:send() never returns. > >Is this behavior deliberate and correct? At least partly, I think:-) - i.e. my understanding is that you're not supposed to be able to what you want to do, but you're not supposed to be able to do some of the things you actually manage to do, either.:-) I believe the problem is that these lines from the gen_udp(3) man page: If any of the following functions are called with a Socket that was not opened by the calling process, they will return {error, not_owner}. The ownership of a Socket can be transferred to another process with controlling_process/2. - or words to that effect:-) - should also be in the corresponding place in the gen_tcp(3) man page, but aren't. I.e. only the controlling process can (or at least is allowed to:-) send/recv on the socket, which unfortunately precludes having separate reader and writer processes. I.e. the bug(s) you're seeing (apart from the documentation) would be that your process P can use send after giving away the control, and that C2 hangs rather than getting an error. >For what it's worth, I'm trying to implement a gen_server module >that implements the client-side logic of a popular RPC package, >using TCP as a transport protocol. The data rates may be intense, >so to avoid running the socket open-loop, I'm trying to have >dedicated input and output processes to read from and write to >(respectively) the passive socket. The parent process "P" above >is the server process, and should never block, thus shouldn't do >I/O with a passive socket directly. Hmm, if the input process is just going to turn around and do a 'Server ! Packet' when the recv() returns, I think you might just as well (or better) use active mode with the server as controlling process - the input process is effectively an "activifier" anyway then. >[1]: You have to do an interesting little dance when you do this, >since the child can't call gen_tcp:recv() until it is the controlling >process, and it can't be made the controlling process until the >parent has spawned it to get the Pid and called >gen_tcp:controlling_process(): Well, yes, but having to synchronize with the spawned child for some reason or another isn't all that uncommon... --Per Hedeland per@REDACTED From Chandru.Mullaparthi@REDACTED Tue Oct 26 14:36:34 1999 From: Chandru.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Tue, 26 Oct 1999 13:36:34 +0100 Subject: Supervisers who always restart their children References: Message-ID: <3815A052.D22C012E@eei.ericsson.se> Sean Hinde wrote: > > Hi all, > > A question related to supervisors. > > Is it possible to define a supervisor so that it retries an infinite number > of times to restart its children regardless of how often they die. I have an > application where my supervised process is designed to die as a result of an > external system breaking its connection, but it should always be restarted > so the external system can re-connect. #In the return value of your Module:init function you can make MaxR as some HUGE integer value and MaxT=1 This will make sure your supervised process is always restarted. hth, Chandru From mskow@REDACTED Tue Oct 26 20:14:32 1999 From: mskow@REDACTED (Michael Skowronski) Date: Tue, 26 Oct 1999 14:14:32 -0400 (EDT) Subject: orber Message-ID: Hello, does anyone on this list have experiences using Orber in commercial settings and would be willing to share those experiences? also, a pointer to any whitepapers and/or testimonials about Orber, if there are any, would be appreciated as well. Mike From bob@REDACTED Wed Oct 27 02:13:51 1999 From: bob@REDACTED (Bob) Date: Tue, 26 Oct 1999 14:13:51 -1000 Subject: hard limits? Message-ID: <199910270013.CAA21663@hades.cslab.ericsson.net> Thanks to everyone for your quick replies, and your great contributions to Erlang. Of course, it's obvious after seeing your replies, that there are runtime and os limits as well as hardware. I'm mostly interested in the upper practical limits on number of nodes, and on individual Mnesia tables. Would it be hundreds of nodes, thousands, tens of thousands, or hundreds of thousands. Would Mnesia scale to tens of gigabyte (disk-based) tables, with millions of records? Or, should Mnesia be limited to use as a near real time db, with some other backend for the big stuff? Even if Mnesia wouldn't scale in that manner, it would seem (at first thought) fairly easy to work around table size limits with a language such as Erlang? Aloha, Bob From mikl@REDACTED Wed Oct 27 07:59:26 1999 From: mikl@REDACTED (Mickael Remond) Date: Wed, 27 Oct 1999 07:59:26 +0200 Subject: Gen_server and states Message-ID: <19991027075926.A1131@louxor.home> Hi, I am currently working on behaviours. My question is about the state of the gen_server. >From what I understand, this "state" is supposed to stored the data managed by the server. Is this correct ? How would you put up with a server as soon as you get a huge amount of data, that cannot fit into your RAM ? Would you use a mnesia table or Dets and use the state as an handler to those data ? Is there alternative solutions ? Thanks in advance for your help. Mickael From luke@REDACTED Wed Oct 27 08:18:34 1999 From: luke@REDACTED (Luke Gorrie) Date: 27 Oct 1999 16:18:34 +1000 Subject: Gen_server and states In-Reply-To: Mickael Remond's message of "Wed, 27 Oct 1999 07:59:26 +0200" References: <19991027075926.A1131@louxor.home> Message-ID: <87iu3t1g3p.fsf@baked.vegetable.org> Mickael Remond writes: > How would you put up with a server as soon as you get a huge amount of data, > that cannot fit into your RAM ? Would you use a mnesia table or Dets and use > the state as an handler to those data ? Yes, though it might affect your design more than this. For instance, if you were storing all your state in Mnesia, you might throw the server away and execute requests in the client process, since you don't have to worry about serialising access to the state when you're using transactions. -- "Time flies like an arrow; fruit-flies like a banana." -Groucho Marx From etxuwig@REDACTED Wed Oct 27 09:30:48 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 27 Oct 1999 09:30:48 +0200 (MET DST) Subject: hard limits? In-Reply-To: <199910270013.CAA21663@hades.cslab.ericsson.net> Message-ID: On Tue, 26 Oct 1999, Bob wrote: bob>I'm mostly interested in the upper practical limits on number of bob>nodes, and on individual Mnesia tables. Would it be hundreds of bob>nodes, thousands, tens of thousands, or hundreds of thousands. I am personally not aware of anyone running more than 70-80 nodes in one erlang system. We are aiming for up to 32 in an *extremely* busy network. It's difficult to reason about a practical upper limit, because it obviously depends on what the applications are doing. One problem is that erlang uses a fully meshed network. For a really big network, one might want to have a hierarchical structure, and some kind of broadcast mechanism, perhaps. The global name server has been designed to handle larger networks, by allowing multiple locker domains. This solves (?) one issue that we've had before. bob>Would Mnesia scale to tens of gigabyte (disk-based) tables, with bob>millions of records? Or, should Mnesia be limited to use as a near bob>real time db, with some other backend for the big stuff? I don't think mnesia scales that well in practise. A few problems: - the table sync algorithm is a bit too naiive (it always copies the whole table, instead of just the updates) - the disk storage mechanism (dets) doesn't scale that well. I don't see many hard limits that are so entrenched that they cannot be lifted. Mnesia will surely evolve to handle larger data sets as users begin to voice a requirement for it. Any hardcode database experts out there who'd like to help? (: /Uffe Ulf Wiger, Chief Designer AXD 301 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 etxuwig@REDACTED Wed Oct 27 09:41:21 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 27 Oct 1999 09:41:21 +0200 (MET DST) Subject: Gen_server and states In-Reply-To: <87iu3t1g3p.fsf@baked.vegetable.org> Message-ID: On 27 Oct 1999, Luke Gorrie wrote: luke>Mickael Remond writes: luke> luke>> How would you put up with a server as soon as you get a luke>> huge amount of data, that cannot fit into your RAM ? luke>> Would you use a mnesia table or Dets and use luke>> the state as an handler to those data ? luke> luke>Yes, though it might affect your design more than this. For luke>instance, if you were storing all your state in Mnesia, you might luke>throw the server away and execute requests in the client process, luke>since you don't have to worry about serialising access to the luke>state when you're using transactions. Another option is to use ETS. If you have lots of data in your state, you'll want to break it up into smaller pieces so that you can lookup one item at a time. Depending on your problem, you may then also allow clients to read the data directly from ETS, while serialising all writes, using the server. Sometimes this is a good idea, but think about it carefully, so you don't cause race conditions. The main problem with having a huge state record in a gen_server is GC. Keeping the data in ETS eliminates this. Keeping it in dets would probably incur overhead similar to the GC overhead. Personally, I've tried keeping a data set of 30,000 small records on the process heap, with relative success, so you may have to experiment with the limits to see what works for you. /Uffe Ulf Wiger, Chief Designer AXD 301 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 ebernard@REDACTED Wed Oct 27 09:49:29 1999 From: ebernard@REDACTED (Emmanuelle BERNARD) Date: Wed, 27 Oct 1999 09:49:29 +0200 Subject: Mnesia: table names vs record name Message-ID: <3816AE89.FA5A5017@email.enst.fr> Hi, I'd like to build several tables with the record "domain" So I create my table as follows: TabDef=[{record_name,domain}] mnesia:create_table(school,TabDef). But when I want to write a #domain Tuple in the database with the write/3 function, the answer is "bad_type" How to make a disc_copies of this table school?(it doesn't want me to write anything else in the TabDef) moreover, I don't succeed in loading any textfile, there is an error in the line 1 of my file, although I wrote exactly the same code provided on www.erlang.org in Chapter 4.4 from the User's Guide for Mnesia... Has anyone the same problems?, or solutions? Thanks Emmanuelle From klacke@REDACTED Wed Oct 27 10:40:17 1999 From: klacke@REDACTED (Klacke) Date: Wed, 27 Oct 1999 10:40:17 +0200 (CEST) Subject: Mnesia: table names vs record name In-Reply-To: <3816AE89.FA5A5017@email.enst.fr> References: <3816AE89.FA5A5017@email.enst.fr> Message-ID: <14358.47729.682682.389826@kricka.bluetail.com> Emmanuelle BERNARD writes: > Hi, > > I'd like to build several tables with the record "domain" > So I create my table as follows: > TabDef=[{record_name,domain}] > mnesia:create_table(school,TabDef). > > But when I want to write a #domain Tuple in the database with the > write/3 function, the answer is "bad_type" > How to make a disc_copies of this table school?(it doesn't want me to > write anything else in the TabDef) This works like a charm for me: 12> TabDef=[{record_name,domain}]. [{record_name,domain}] 13> mnesia:create_table(school,TabDef). {atomic,ok} 14> mnesia:transaction(fun() ->mnesia:write(school, {domain, 3,4}, write) end). {atomic,ok} Maybe you are not having #domain record with exactly two attributes. Since you are not specifying the attributes, 2 is the deafult: mnesia:transaction(fun() ->mnesia:write(school, {domain, 3,4,5}, write) end). {aborted,{bad_type,{domain,3,4,5}}} Checkout the {attributes , A} flag to mnesia:create_table/2 > > moreover, I don't succeed in loading any textfile, there is an error in > the line 1 of my file, although I wrote exactly the same code provided > on www.erlang.org in Chapter 4.4 from the User's Guide for Mnesia... > Probably the same problem here ?? /klacke From cesarini@REDACTED Wed Oct 27 11:52:11 1999 From: cesarini@REDACTED (Francesco Cesarini) Date: Wed, 27 Oct 1999 11:52:11 +0200 (MET DST) Subject: Supervisers who always restart their children In-Reply-To: <3815A052.D22C012E@eei.ericsson.se> Message-ID: > #In the return value of your Module:init function you can make > MaxR as some HUGE integer value and MaxT=1 > This will make sure your supervised process is always restarted. That is only safeish, however. It can be argued that the supervisor behaviour should allow the atom infinity a a valid value denoting MaxR and MaxT to be set to infinity, as this value is allowed elsewhere along side integers. It is just a few lines of code to be added in the supervisor module... The easiest solution, however, is your own supervisor... Rgds, FC -- -module(mysup). -behaviour(gen_server). -export([start_link/3]). -export([init/1, handle_info/2, terminate/2]). %%%---------------------------------------------------------------------- %%% API %%%---------------------------------------------------------------------- start_link(Mod,Fun,Args) -> gen_server:start_link({local, ?MODULE}, ?MODULE, {Mod,Fun,Args}, []). %%%---------------------------------------------------------------------- %%% Callback functions from gen_server %%%---------------------------------------------------------------------- init({Mod,Func,Args}) -> process_flag(trap_exit, true), Pid = proc_lib:spawn_link(Mod, Func, Args), {ok, {Pid,{Mod,Func,Args}}}. handle_info({'EXIT', Pid, Reason}, {Pid, {Mod, Func, Args}}) -> NewPid = proc_lib:spawn_link(Mod, Func, Args), {noreply, {NewPid, {Mod, Func, Args}}}. terminate(Reason, {Pid, {Mod, Func, Arg}}) -> exit(Pid, shutdown), %%Be kind receive {'EXIT', Pid, shutdown} -> ok after 10000 -> %%Timeout, use violence exit(Pid, kill) end From wadler@REDACTED Wed Oct 27 16:21:16 1999 From: wadler@REDACTED (Philip Wadler) Date: Wed, 27 Oct 1999 10:21:16 -0400 Subject: Call for Papers, ICFP 2000 (correction) Message-ID: <199910271421.KAA03707@nslocum.cs.bell-labs.com> Last week I posted the call for papers for ICFP 2000, but it contained some errors. Corrected information is below. Please see the web site for the full call. -- P Call for Papers ICFP 2000: International Conference on Functional Programming Montreal, Canada; 18--20 September 2000 (associated with PLI 2000: Colloquium on Principles, Logics, and Implementations of High-Level Programming Languages) http://www.cs.bell-labs.com/~wadler/icfp2000 Important dates and submission details ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Submission Deadline 13.00 EST (18.00 UTC), 1 March 2000 Submission Length 12 pages in ACM conference format Notification of Acceptance or Rejection 8 May 2000 Final Paper Due 12 June 2000 ICFP '00 in Montreal 18--20 September 2000 Program Chair Program Committee ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ Philip Wadler Richard Bird, Oxford Bell Labs, Lucent Technologies Craig Chambers, Washington 600 Mountain Ave, room 2T-402 Charles Consel, IRISA Murray Hill, NJ 07974-0636, USA Susan Eisenbach, Imperial phone: +1 908 582 4004 Fergus Henderson, Melbourne http://www.cs.bell-labs.com/~wadler Ralf Hinze, Bonn wadler@REDACTED Shriram Krishnamurthi, Rice Xavier Leroy, INRIA/Trusted Logic Eugenio Moggi, Genova General Chair Greg Morisset, Cornell ~~~~~~~~~~~~~ Atsushi Ohori, Kyoto Martin Odersky Catuscia Palamedissi, Penn State Ecole Polytechnique Federale de Lausanne Andrew Wright, Intertrust fcc: travel/icfp00 Subject: Call for Papers, ICFP 2000 (correction) -------- Last week I posted the call for papers for ICFP 2000, but it contained some errors. Corrected information is below. Please see the web site for the full call. -- P Call for Papers ICFP 2000: International Conference on Functional Programming Montreal, Canada; 18--20 September 2000 (associated with PLI 2000: Colloquium on Principles, Logics, and Implementations of High-Level Programming Languages) http://www.cs.bell-labs.com/~wadler/icfp2000 Important dates and submission details ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Submission Deadline 13.00 EST (18.00 UTC), 1 March 2000 Submission Length 12 pages in ACM conference format Notification of Acceptance or Rejection 8 May 2000 Final Paper Due 12 June 2000 ICFP '00 in Montreal 18--20 September 2000 Program Chair Program Committee ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~ Philip Wadler Richard Bird, Oxford Bell Labs, Lucent Technologies Craig Chambers, Washington 600 Mountain Ave, room 2T-402 Charles Consel, IRISA Murray Hill, NJ 07974-0636, USA Susan Eisenbach, Imperial phone: +1 908 582 4004 Fergus Henderson, Melbourne http://www.cs.bell-labs.com/~wadler Ralf Hinze, Bonn wadler@REDACTED Shriram Krishnamurthi, Rice Xavier Leroy, INRIA/Trusted Logic Eugenio Moggi, Genova General Chair Greg Morisset, Cornell ~~~~~~~~~~~~~ Atsushi Ohori, Kyoto Martin Odersky Catuscia Palamedissi, Penn State Ecole Polytechnique Federale de Lausanne Andrew Wright, Intertrust From jim@REDACTED Wed Oct 27 21:51:44 1999 From: jim@REDACTED (Jim Larson) Date: Wed, 27 Oct 1999 12:51:44 -0700 Subject: Third-party send to active and passive TCP sockets In-Reply-To: Your message of "Tue, 26 Oct 1999 14:18:29 +0200." <199910261218.OAA27576@aalborg.du.uab.ericsson.se> Message-ID: <199910271951.MAA05233@lefse.jetcafe.org> In message <199910261218.OAA27576@REDACTED> Per Hedeland writes: >Jim Larson wrote: >>For what it's worth, I'm trying to implement a gen_server module >>that implements the client-side logic of a popular RPC package, >>using TCP as a transport protocol. The data rates may be intense, >>so to avoid running the socket open-loop, I'm trying to have >>dedicated input and output processes to read from and write to >>(respectively) the passive socket. The parent process "P" above >>is the server process, and should never block, thus shouldn't do >>I/O with a passive socket directly. > >Hmm, if the input process is just going to turn around and do a >'Server ! Packet' when the recv() returns, I think you might just as >well (or better) use active mode with the server as controlling process >- the input process is effectively an "activifier" anyway then. With passive sockets, we have the option of deferring further recv()s in response to high load. For client-side sockets, we can acheive the same effect with active sockets by delaying the send() of requests to limit the number of outstanding requests at any one time. For server-side sockets, we may be overwhelmed by client request messages. Any suggestions for what we can do here? Does the Erlang process scheduler look at the depth of message queues in order to avoid overflows? Jim From ebernard@REDACTED Wed Oct 27 22:45:12 1999 From: ebernard@REDACTED (Emmanuelle Bernard) Date: Wed, 27 Oct 1999 20:45:12 +0000 Subject: mnesia table: mnemosyne query Message-ID: <38176458.42F7F097@email.enst.fr> Hi! I've the following code: in the file: projet.hrl -record (domaine, { nom, ip , type }). in the file: projet.erl -module(projet). -copyright('Copyright (c) 1991-97 Ericsson Telecom AB'). -export([ nouv_table/1 , insert_ordi/2 , essai/0]). -include("projet.hrl"). -include_lib("mnemosyne/include/mnemosyne.hrl"). nouv_table(Nom_Table) -> mnesia:create_table(Nom_Table,[{record_name,domaine},{disc_copies, [node()]}, {attributes, record_info(fields, domaine)}]). insert_ordi(Tuple,Where) -> Fun = fun() -> mnesia:write(Where,Tuple,write) end, mnesia:transaction(Fun). essai() -> Handle= query [U.ip || U <- table(domaine), U.nom = 4] end, Answer = mnesia:transaction( fun() -> mnemosyne:eval(Handle) end) . In the shell: 21> c(projet). {ok,projet} 22> projet:nouv_table(ecole). {atomic,ok} 23> projet:insert_ordi({domaine,4,5,6},ecole). {atomic,ok} 24>tv:start(). <0.129.0> 25>projet:essai(). {aborted,{no_exists,domaine}} // if I replace by "U <- table(ecole)" in the projet.erl file it doesn't want to compile: 26> c(projet). ./projet.erl:112: the record "ecole" is undefined ./projet.erl:124: function essai/0 undefined error How can I ask it to search in the table "ecole" (that has a "domaine" record) with the mnemosyne query? Moreover, when I check my tables with tv, they are empty, even if I've written anything in. Can anyone help me? thanks Emmanuelle From dgud@REDACTED Thu Oct 28 08:09:41 1999 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 28 Oct 1999 08:09:41 +0200 (MET DST) Subject: mnesia table: mnemosyne query In-Reply-To: <38176458.42F7F097@email.enst.fr> References: <38176458.42F7F097@email.enst.fr> Message-ID: <14359.59557.252350.334602@gargle.gargle.HOWL> Both 'Tv', 'Mnemosyne' don't work if the table name differ from record name. The handling of 'record name' was a new feature in mnesia in the open source release and the other apps wasn't fixed to handle it. Mnemosyne should handle record names in the new open source release. Coming soon.. :-) /Dan Emmanuelle Bernard writes: > Hi! > > I've the following code: > > in the file: projet.hrl > > -record (domaine, { nom, ip , type }). > > in the file: projet.erl > > -module(projet). > -copyright('Copyright (c) 1991-97 Ericsson Telecom AB'). > -export([ nouv_table/1 , insert_ordi/2 , essai/0]). > > -include("projet.hrl"). > -include_lib("mnemosyne/include/mnemosyne.hrl"). > > nouv_table(Nom_Table) -> > mnesia:create_table(Nom_Table,[{record_name,domaine},{disc_copies, > [node()]}, {attributes, record_info(fields, domaine)}]). > > > insert_ordi(Tuple,Where) -> > Fun = fun() -> > mnesia:write(Where,Tuple,write) > end, > mnesia:transaction(Fun). > > > essai() -> > Handle= > query > [U.ip || U <- table(domaine), > U.nom = 4] > end, > Answer = > mnesia:transaction( > fun() -> > mnemosyne:eval(Handle) > end) > . > > > > In the shell: > > > 21> c(projet). > {ok,projet} > > 22> projet:nouv_table(ecole). > {atomic,ok} > > 23> projet:insert_ordi({domaine,4,5,6},ecole). > {atomic,ok} > > 24>tv:start(). > <0.129.0> > > 25>projet:essai(). > {aborted,{no_exists,domaine}} > > // if I replace by "U <- table(ecole)" in the projet.erl file > it doesn't want to compile: > > 26> c(projet). > ./projet.erl:112: the record "ecole" is undefined > ./projet.erl:124: function essai/0 undefined > error > > > How can I ask it to search in the table "ecole" (that has a "domaine" > record) with the mnemosyne query? > Moreover, when I check my tables with tv, they are empty, even if I've > written anything in. > > Can anyone help me? > thanks > > Emmanuelle > From etxuwig@REDACTED Thu Oct 28 10:01:22 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 28 Oct 1999 10:01:22 +0200 (MET DST) Subject: Third-party send to active and passive TCP sockets In-Reply-To: <199910271951.MAA05233@lefse.jetcafe.org> Message-ID: On Wed, 27 Oct 1999, Jim Larson wrote: jim>Does the Erlang process scheduler look at the depth of message jim>queues in order to avoid overflows? No, the scheduler doesn't, but then again, the message queues don't usually overflow, since they are dynamically resized. You can perform the check yourself, using process_info(Pid, message_queue_len) -> {message_queue_len, L} which is a very fast operation. This can be used for simple load regulation, based on the assumption that if a process has e.g. > 100 messages in its queue, it may be falling behind. /Uffe Ulf Wiger, Chief Designer AXD 301 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 etxuwig@REDACTED Thu Oct 28 10:17:13 1999 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 28 Oct 1999 10:17:13 +0200 (MET DST) Subject: mnesia table: mnemosyne query In-Reply-To: <38176458.42F7F097@email.enst.fr> Message-ID: Emmanuelle, You can try writing like this for now: essai() -> {atomic, Objs} = mnesia:transaction( fun() -> mnesia:match_object(ecole, '_') end), [D#domaine.id || D <- Objs, D#domain.nom == 4]. For simple queries, this is just as efficient as mnemosyne. Also, for checking your tables quickly, you may try ets:tab2list(ecole) or ets:i(), since disc_copies are also stored in RAM, at ETS tables. There is also an Open Source contribution called trex, similar to tv, which doesn't have a problem displaying tables, even if the records differ. /Uffe On Wed, 27 Oct 1999, Emmanuelle Bernard wrote: eberna>Hi! eberna> eberna>I've the following code: eberna> eberna>in the file: projet.hrl eberna> eberna>-record (domaine, { nom, ip , type }). eberna> eberna>in the file: projet.erl eberna> eberna>-module(projet). eberna>-copyright('Copyright (c) 1991-97 Ericsson Telecom AB'). eberna>-export([ nouv_table/1 , insert_ordi/2 , essai/0]). eberna> eberna>-include("projet.hrl"). eberna>-include_lib("mnemosyne/include/mnemosyne.hrl"). eberna> eberna>nouv_table(Nom_Table) -> eberna> mnesia:create_table(Nom_Table,[{record_name,domaine},{disc_copies, eberna>[node()]}, {attributes, record_info(fields, domaine)}]). eberna> eberna> eberna>insert_ordi(Tuple,Where) -> eberna> Fun = fun() -> eberna> mnesia:write(Where,Tuple,write) eberna> end, eberna> mnesia:transaction(Fun). eberna> eberna> eberna>essai() -> eberna>Handle= eberna> query eberna> [U.ip || U <- table(domaine), eberna> U.nom = 4] eberna> end, eberna>Answer = eberna> mnesia:transaction( eberna> fun() -> eberna> mnemosyne:eval(Handle) eberna> end) eberna>. eberna> eberna> eberna> eberna>In the shell: eberna> eberna> eberna>21> c(projet). eberna>{ok,projet} eberna> eberna>22> projet:nouv_table(ecole). eberna>{atomic,ok} eberna> eberna>23> projet:insert_ordi({domaine,4,5,6},ecole). eberna>{atomic,ok} eberna> eberna>24>tv:start(). eberna><0.129.0> eberna> eberna>25>projet:essai(). eberna>{aborted,{no_exists,domaine}} eberna> eberna>// if I replace by "U <- table(ecole)" in the projet.erl file eberna>it doesn't want to compile: eberna> eberna> 26> c(projet). eberna> ./projet.erl:112: the record "ecole" is undefined eberna> ./projet.erl:124: function essai/0 undefined eberna> error eberna> eberna> eberna>How can I ask it to search in the table "ecole" (that has a "domaine" eberna>record) with the mnemosyne query? eberna>Moreover, when I check my tables with tv, they are empty, even if I've eberna>written anything in. eberna> eberna>Can anyone help me? eberna>thanks eberna> eberna>Emmanuelle eberna> eberna> eberna> Ulf Wiger, Chief Designer AXD 301 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 hakan@REDACTED Thu Oct 28 10:56:20 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Thu, 28 Oct 1999 10:56:20 +0200 (MET DST) Subject: mnesia table: mnemosyne query In-Reply-To: Message-ID: On Thu, 28 Oct 1999, Ulf Wiger wrote: Uffe> You can try writing like this for now: Uffe> Uffe> essai() -> Uffe> {atomic, Objs} = Uffe> mnesia:transaction( Uffe> fun() -> Uffe> mnesia:match_object(ecole, '_') Uffe> end), Uffe> [D#domaine.id || D <- Objs, D#domain.nom == 4]. Uffe> Uffe> For simple queries, this is just as efficient as mnemosyne. In fact it is more efficient to avoid Mnemosyne... Instead of first performing a copy of all records from ets to your process heap (potentially on another node than the ets table), it is better to let ets do the selection of which records that matches the constraint (D#domain.nom == 4). It can be done like this: essai() -> Tab = ecole, Pat = mnesia:table_info(Tab,wild_pattern), Fun = fun() -> mnesia:match_object(Tab, Pat#domaine{nom = 4}) end, {atomic, Domains} = mnesia:transaction(Fun), [D#domaine.ip || D <- Domains]. The mnesia:transaction/1 call may be replaced with a call to mnesia:sync_dirty/1 or mnesia:ets/1 if you want it more efficient. /H?kan From per@REDACTED Thu Oct 28 17:15:51 1999 From: per@REDACTED (Per Hedeland) Date: Thu, 28 Oct 1999 17:15:51 +0200 (MET DST) Subject: Third-party send to active and passive TCP sockets Message-ID: <199910281515.RAA29437@aalborg.du.uab.ericsson.se> Jim Larson wrote: > >Per Hedeland writes: >>Hmm, if the input process is just going to turn around and do a >>'Server ! Packet' when the recv() returns, I think you might just as >>well (or better) use active mode with the server as controlling process >>- the input process is effectively an "activifier" anyway then. > >With passive sockets, we have the option of deferring further >recv()s in response to high load. Of course - I didn't mean to imply that you might just as well use active mode *in general* - just that if your input process didn't do anything in particular with the input, there wasn't much of an actual difference. So, I assume the input process behaves as above, with the addition that the server can tell it to stop recv()ing when it considers the load too high (based on some criteria). The question then becomes why the server can't just do the recv()ing itself, and stop doing it when the load is too high. I know you said that you don't want it to block, but if it's just blocking when it's waiting for new input, that shouldn't be a problem I think. But of course it all depends on your overall design, e.g. whether the server farms out the actual processing to other processes and then needs to collect the results, etc. It also depends on whether there is any inherent flow control in your application - you said it was an RPC server, if the clients always wait for a response after sending a query, and the number of clients isn't infinite, there's an upper limit to how big your "work queue" can become. --Per From per@REDACTED Thu Oct 28 22:31:19 1999 From: per@REDACTED (Per Hedeland) Date: Thu, 28 Oct 1999 22:31:19 +0200 (MET DST) Subject: hard limits? Message-ID: <199910282031.WAA01455@super.du.uab.ericsson.se> Ulf Wiger wrote: >It's difficult to reason about a practical upper limit, because it >obviously depends on what the applications are doing. One problem >is that erlang uses a fully meshed network. Yes, among other things this (with the currently implemented distribution mechanism, i.e. TCP sockets) translates to each node needing one file descriptor for every other node. Many OSes start having functional problems (in particular with the select() system call) when a process has around 1000 descriptors open (some can't even do that), and of course it's also a performance issue since checking for I/O on all those descriptors doesn't come for free. Another thing to note might be that the current Pid format (a 32-bit word) restricts you to max 2^15 processes per node and 2^8 nodes total in a distribution-connected network. The tradeoff between processes per node and total nodes could be changed relatively easily I guess - the totals could also be raised (by using more than one word), but not nearly as easily.:-) --Per Hedeland per@REDACTED From lmcpmcg@REDACTED Sat Oct 30 20:43:58 1999 From: lmcpmcg@REDACTED (Paul McGee (LMC)) Date: Sat, 30 Oct 1999 14:43:58 -0400 Subject: No subject Message-ID: <6293663F5176D211B2D800805FFEBAAE0595C69E@lmc35.lmc.ericsson.se> Reference Manual Location???? From lmcpmcg@REDACTED Sat Oct 30 20:43:33 1999 From: lmcpmcg@REDACTED (Paul McGee (LMC)) Date: Sat, 30 Oct 1999 14:43:33 -0400 Subject: Reference Manual Location????? Message-ID: <6293663F5176D211B2D800805FFEBAAE0595C69D@lmc35.lmc.ericsson.se> From chris.williams@REDACTED Sun Oct 31 14:04:44 1999 From: chris.williams@REDACTED (Chris Williams) Date: Sun, 31 Oct 1999 13:04:44 +0000 Subject: No subject References: <6293663F5176D211B2D800805FFEBAAE0595C69E@lmc35.lmc.ericsson.se> Message-ID: <381C3E6C.22741C1B@ericsson.com> Hi, Look in the directory /doc and open "index.html" or do erl -man on the application you need help on. You can also look at http://erlang.org/doc/doc/index.html //Chris "Paul McGee (LMC)" wrote: > > Reference Manual Location???? -- ============================================================================ Christopher Williams Phone: +353 902 31365 Ericsson Systems ECN: 8301365 Expertise Limited, Mob: +353 87 670 58 47 Athlone, Fax: +353 902 31304 Co.Westmeath, http://www.eei.ericsson.se/~eeiaxm3 Ireland chris.williams@REDACTED ============================================================================