From per@REDACTED Mon Apr 1 09:43:40 2002 From: per@REDACTED (Per Bergqvist) Date: Mon, 01 Apr 2002 08:43:40 +0100 Subject: [d]ets:lookup misbehaves when called during =?iso-8859-1?q?init:start=3F?= In-Reply-To: <20020330235235.215344cf.cpressey@catseye.mb.ca> Message-ID: <200204010643.g316hfN09809@hyena.levonline.com> Hi Chris, the problem is that the inet_db modules has not yet been started and hence the inet_db ets table does not exist (yet). It is supposed to be started by the kernel_sup supervisor. I haven't managed to recreate the problem with R8B-0 under Linux but two possible other workarounds are a) wait for the inet_db process to become registered. b) call inet_db:start from your application (as ftp,httpd and orber already does (for the same reason ?)). /Per > I have discovered one workaround for this, although it comes at a grave > cost (namely, the use of the shell) > > Instead of > > erl -run module function > > use > > echo 'module:function().' | erl > > Should have been obvious I suppose :) > > Chris > > On Fri, 29 Mar 2002 06:27:22 -0600 > Chris Pressey wrote: > > > I'd really like to get to the bottom of this one... > > > > I have a server that opens a socket. If I start this server from the > > Erlang shell, everything works smoothly. If I try to start it with a > > -run command line argument to erl, it does *not* work and I get the > > following error message upon quitting: > > > > {error_logger,{{2002,3,29},{6,10,40}},'Error in process <0.24481.0> > > with exit value: {badarg,[{ets,lookup,[inet_db,tcp_module]}, > > {inet_db,db_get,1},{gen_tcp,listen,2},{ce_socket,start,4}]}\n',[]} > > > > I get the same error if I try to start it from my .erlang file. > > > > The question is... why? > > > > I've asked this once before a while ago, but got no response so far. > > > > It seems someone else is (anonymously) getting a very similar error > > trying to start the wiki in the same way: > > > > http://www.bluetail.com/wiki/showPage?node=WikiSetup > > > > {badarg,[{ets,lookup_element,[dets_registry,wikie,3]}, > > {dets,lookup,2}, > > {wikie,fetch_page,1}, > > {erl_eval,expr,3}, > > {erl_eval,exprs,4}, > > {esp,eval,2}, > > {esp,expand,3}, > > {esp,do_expand_file,2}, > > {esp,handle,1}| > > more]} > > > > Any information on this anomaly (e.g. why it happens and/or how to work > > around it) would be greatly appreciated (seeing as I *really* don't want > > to have to start my server from the Erlang shell every time I want to > > use it :) > > > > Thanks in advance, > > Chris > ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From luke@REDACTED Tue Apr 2 04:18:45 2002 From: luke@REDACTED (Luke Gorrie) Date: 02 Apr 2002 04:18:45 +0200 Subject: Client Nodes (ie gui). In-Reply-To: <20020327050445.27739.qmail@web13002.mail.yahoo.com> References: <20020327050445.27739.qmail@web13002.mail.yahoo.com> Message-ID: Eric Merritt writes: > In any case, my question is simple. Are there other > GUI options? Should I simply implement the client in > another language and use the more traditional client > server method with custom protocol? I should mention - erlgtk does infact work great on Win32. You can download a win32 binary from http://www.bluetail.com/~luke/misc/erlgtk-0.9.0.zip That may not be the latest version, it it's quite complete. Cheers, Luke From luke@REDACTED Tue Apr 2 04:28:55 2002 From: luke@REDACTED (Luke Gorrie) Date: 02 Apr 2002 04:28:55 +0200 Subject: Distel 1.0 Message-ID: Fun! Excitement! Emacs! I've feverishly hacked together a 1.0 version of "Distributed Emacs Lisp", which implements "Emacs nodes" with all the fixin's. For details see http://www.bluetail.com/~luke/distel/ - there's even a manual (!!) If you're a *real* Emacs weenie you should find this pretty handy! Cheers, Luke From cyberlync@REDACTED Tue Apr 2 05:29:59 2002 From: cyberlync@REDACTED (Eric Merritt) Date: Mon, 1 Apr 2002 19:29:59 -0800 (PST) Subject: C interface question In-Reply-To: Message-ID: <20020402032959.84962.qmail@web13001.mail.yahoo.com> I have a question for those of you who use the C interface. The function ei_get_type from the ei library returns a type value as an it. There is nothing there to indicate where the defines are for the diffrent types. I went looking and found a list of types in the eiext.h file but I am not sure that these are the actual defines. In any case, could someone point this out for me? Thanks Eric __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://http://taxes.yahoo.com/ From bjarne@REDACTED Tue Apr 2 10:00:28 2002 From: bjarne@REDACTED (Bjarne =?iso-8859-1?Q?D=E4cker?=) Date: Tue, 02 Apr 2002 10:00:28 +0200 Subject: Regular Expressions: Erlang Is Worth a Look References: <20020327050445.27739.qmail@web13002.mail.yahoo.com> Message-ID: <3CA9651C.87A56FF1@erix.ericsson.se> http://www.unixreview.com/documents/s=2425/uni1016550801055/ From vlad_dumitrescu@REDACTED Tue Apr 2 10:44:24 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 02 Apr 2002 10:44:24 +0200 Subject: system limits Message-ID: Hi folks, * I have a question about the 32000 processes limit. Sometimes I get an error message stating that this limit has been reached (it's not easily reproducible) even if there should not be more than 8-9000 processes around... I wonder if there might be some obscure condition that might raise this error message but the problem actually lies elsewhere. To be more exact, I wonder if it might be a similar condition with the limit concerning the number of ets tables: one gets a "system limit reached" when one creates a named ets table and then tries to create a mnesia table with the same name. * And I would also like to ask again a question that I didn't get an answer before: the number of interconnected nodes limit. Does the 256 nodes limit refer to "simultaneously connected nodes"? Also, is it a limit for the total number of nodes present in the network, or for the number of nodes that one noce can be connected to? Thanks for the help. Regards, Vlad _________________________________________________________________ Chatta med v?nner online, prova MSN Messenger: http://messenger.msn.se From Helen.Airiyan@REDACTED Tue Apr 2 12:00:02 2002 From: Helen.Airiyan@REDACTED (Helen Airiyan) Date: Tue, 02 Apr 2002 12:00:02 +0200 Subject: system limits References: Message-ID: <3CA98122.315E7ADE@eed.ericsson.se> hi Vlad, twice on a live network we have seen the error message about the system limit being reached, i.e: =ERROR REPORT==== 1-Apr-2002::11:01:36 === Too many processes In both cases it was public holiday and noone was able to check the status of the node to see how many processes there are & who eats them up. After that there was a complete reload & all info lost. We have been investigating this for a while, but the progress is very slow. So, I would be very curious to hear more on this subject also. Regards, Helen Vlad Dumitrescu wrote: > Hi folks, > > * I have a question about the 32000 processes limit. Sometimes I get an > error message stating that this limit has been reached (it's not easily > reproducible) even if there should not be more than 8-9000 processes > around... I wonder if there might be some obscure condition that might raise > this error message but the problem actually lies elsewhere. > > To be more exact, I wonder if it might be a similar condition with the limit > concerning the number of ets tables: one gets a "system limit reached" when > one creates a named ets table and then tries to create a mnesia table with > the same name. > > * And I would also like to ask again a question that I didn't get an answer > before: the number of interconnected nodes limit. Does the 256 nodes limit > refer to "simultaneously connected nodes"? Also, is it a limit for the total > number of nodes present in the network, or for the number of nodes that one > noce can be connected to? > > Thanks for the help. > Regards, > Vlad > > _________________________________________________________________ > Chatta med v?nner online, prova MSN Messenger: http://messenger.msn.se From luis.gonzalezpascual@REDACTED Tue Apr 2 16:46:58 2002 From: luis.gonzalezpascual@REDACTED (luis.gonzalezpascual@REDACTED) Date: Tue, 2 Apr 2002 16:46:58 +0200 Subject: Using >megaco_simple_mg:start_tcp_txt() by ip address. Message-ID: Hakan Mattsson @erix.ericsson.se con fecha 25/03/2002 16.43.07 Enviado por: hakan@REDACTED Destinatarios: Luis Gonzalez Pascual/INFR/TESA@REDACTED CC: erlang-questions@REDACTED Asunto: Re: Using >megaco_simple_mg:start_tcp_txt() by ip address. On Mon, 25 Mar 2002 luis.gonzalezpascual@REDACTED wrote: Luis> I'm very new to Erlang. I've installed win32 binary version of erlang R8B-0 Luis> on win95. Luis> I want to run erlang media gateway over a tcp/ip lan without DNS server. Luis> Luis> If I execute Luis> >megaco_simple_mgc:start(). Luis> >megaco_simple_mg:start(). Luis> Luis> in the same machine Ok, but I need run (for example) Luis> Luis> >megaco_simple_mg:start_tcp_txt( "10.16.109.16",[]). Besides the misspelled function name, this should work. Does it work for you? Luis> in order to connect to a MGC in other machine using its ip address. Luis> Do I need a translation ip_address-host_name file and use >megaco_simple_mg:start_tcp_txt( "host_name",[]).? No, the IP-address should be enough. /H?kan --- H?kan Mattsson Ericsson Computer Science Laboratory http://www.ericsson.com/cslab/~hakan/ Hi. I've reinstalled Erlang in two Win95 PC's in another LAN and it work fine. Thanks a lot. ___________________________________________________________________________ Este mensaje se dirige exclusivamente a su destinatario y puede contener informaci?n privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilizaci?n, divulgaci?n y/o copia sin autorizaci?n est? prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. This message is intended exclusively for its addressee and may contain information that is CONFIDENTIAL and protected by professional privilege. If you are not the intended recipient you are hereby notified that any dissemination, copy or disclosure of this communication is strictly prohibited by law. If this message has been received in error, please immediately notify us via e-mail and delete it. ___________________________________________________________________________ From kostis@REDACTED Tue Apr 2 17:58:53 2002 From: kostis@REDACTED (Kostis Sagonas) Date: Tue, 2 Apr 2002 17:58:53 +0200 (MET DST) Subject: system limits In-Reply-To: Mail from 'Helen Airiyan ' dated: Tue, 02 Apr 2002 12:00:02 +0200 Message-ID: <200204021558.RAA19474@harpo.it.uu.se> Helen Airiyan wrote: > twice on a live network we have seen the error message about the > system limit being reached, i.e: > > =ERROR REPORT==== 1-Apr-2002::11:01:36 === > Too many processes And you believed this message? :-) Apologies for the bandwidth, but I could not resist... :-) Cheers, Kostis. From peter@REDACTED Tue Apr 2 20:35:30 2002 From: peter@REDACTED (Peter H|gfeldt) Date: Tue, 2 Apr 2002 20:35:30 +0200 (MET DST) Subject: C interface question In-Reply-To: <20020402032959.84962.qmail@web13001.mail.yahoo.com> Message-ID: Yes, the #defines are those given in `eiext.h': ERL_SMALL_INTEGER_EXT etc. /Peter On Mon, 1 Apr 2002, Eric Merritt wrote: > I have a question for those of you who use the C > interface. The function ei_get_type from the ei > library returns a type value as an it. There is > nothing there to indicate where the defines are for > the diffrent types. I went looking and found a list of > types in the eiext.h file but I am not sure that these > are the actual defines. In any case, could someone > point this out for me? > > Thanks > Eric > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://http://taxes.yahoo.com/ > From cyberlync@REDACTED Tue Apr 2 21:47:16 2002 From: cyberlync@REDACTED (Eric Merritt) Date: Tue, 2 Apr 2002 11:47:16 -0800 (PST) Subject: C interface question In-Reply-To: Message-ID: <20020402194716.712.qmail@web13005.mail.yahoo.com> Peter, Thank you, that being the case what types do ERL_SMALL_BIG_EXT and ERL_LARGE_BIG_EXT correspond to? I could really find their match. Thank you, Eric __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://http://taxes.yahoo.com/ From cpressey@REDACTED Wed Apr 3 02:39:17 2002 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 02 Apr 2002 18:39:17 -0600 Subject: [d]ets:lookup misbehaves when called during init:start? In-Reply-To: <200204010643.g316hfN09809@hyena.levonline.com> References: <20020330235235.215344cf.cpressey@catseye.mb.ca> <200204010643.g316hfN09809@hyena.levonline.com> Message-ID: <20020402183917.77a60844.cpressey@catseye.mb.ca> Thanks! FWIW, erl -run inet_db -run yourapp also seems to work. Chris On Mon, 01 Apr 2002 08:43:40 +0100 Per Bergqvist wrote: > Hi Chris, > > the problem is that the inet_db modules has not yet been started > and hence the inet_db ets table does not exist (yet). > It is supposed to be started by the kernel_sup supervisor. > > I haven't managed to recreate the problem with R8B-0 under > Linux but two possible other workarounds are > a) wait for the inet_db process to become registered. > b) call inet_db:start from your application (as ftp,httpd and orber > already does (for the same reason ?)). > > /Per > > > I have discovered one workaround for this, although it comes at a > grave > > cost (namely, the use of the shell) > > > > Instead of > > > > erl -run module function > > > > use > > > > echo 'module:function().' | erl > > > > Should have been obvious I suppose :) > > > > Chris > > > > On Fri, 29 Mar 2002 06:27:22 -0600 > > Chris Pressey wrote: > > > > > I'd really like to get to the bottom of this one... > > > > > > I have a server that opens a socket. If I start this server from > the > > > Erlang shell, everything works smoothly. If I try to start it > with a > > > -run command line argument to erl, it does *not* work and I get > the > > > following error message upon quitting: > > > > > > {error_logger,{{2002,3,29},{6,10,40}},'Error in process > <0.24481.0> > > > with exit value: {badarg,[{ets,lookup,[inet_db,tcp_module]}, > > > {inet_db,db_get,1},{gen_tcp,listen,2},{ce_socket,start,4}]}\n',[]} > > > > > > I get the same error if I try to start it from my .erlang file. > > > > > > The question is... why? > > > > > > I've asked this once before a while ago, but got no response so > far. > > > > > > It seems someone else is (anonymously) getting a very similar > error > > > trying to start the wiki in the same way: > > > > > > http://www.bluetail.com/wiki/showPage?node=WikiSetup > > > > > > {badarg,[{ets,lookup_element,[dets_registry,wikie,3]}, > > > {dets,lookup,2}, > > > {wikie,fetch_page,1}, > > > {erl_eval,expr,3}, > > > {erl_eval,exprs,4}, > > > {esp,eval,2}, > > > {esp,expand,3}, > > > {esp,do_expand_file,2}, > > > {esp,handle,1}| > > > more]} > > > > > > Any information on this anomaly (e.g. why it happens and/or how to > work > > > around it) would be greatly appreciated (seeing as I *really* > don't want > > > to have to start my server from the Erlang shell every time I want > to > > > use it :) > > > > > > Thanks in advance, > > > Chris > > > ========================================================= > Per Bergqvist > Synapse Systems AB > Phone: +46 709 686 685 > Email: per@REDACTED From vlad_dumitrescu@REDACTED Wed Apr 3 10:23:00 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 03 Apr 2002 10:23:00 +0200 Subject: edoc structure Message-ID: Hi all, I have looked at JDox, a XML format for JavaDoc, and tried to adapt it to Erlang and EDoc. Please look at the result and figure out what I forgot about and what is superfluous. I used a simple outline format instead of a real DTD because it's so much simpler to read. The point in using this representation as output from the edoc parser is that afterwards several transformations might be applied in order to produce different documentation types (more or less technical or detailed, different styles, different kinds of output). have fun! Vlad _________________________________________________________________ MSN Photos ?r det enklaste s?ttet att dela ut och skriva ut foton: http://photos.msn.se/Support/WorldWide.aspx -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: edox.txt URL: From trinder@REDACTED Wed Apr 3 10:29:29 2002 From: trinder@REDACTED (Phil Trinder) Date: Wed, 3 Apr 2002 09:29:29 +0100 (GMT Daylight Time) Subject: Haskell/Erlang Research Position Message-ID: Research Associate in Haskell/Erlang for Distributed Telecommunications ?17,278-?26,229 p.a. Applications are invited for a three year Research Associate position at Heriot-Watt University to work with Dr Phil Trinder on an EPSRC funded project entitled "High-Level Techniques for Distributed Telecommunications Software". The project is a collaboration with Motorola UK Research Labs and aims to evaluate high-level distributed programming techniques for constructing realistic telecommunications software. Applications are welcomed from candidates with a doctorate or a very good first degree in Computing or cognate discipline; a successful candidate without a PhD will have the opportunity of registering for one. Applicants should have good written and verbal communication skills and be able to demonstrate a strong programming ability: experience with distribution and the Haskell or Erlang programming languages is desirable. Likewise a research background, and familiarity with the telecommunications sector are desirable. For application details please contact the Personnel Office, Heriot-Watt University, Edinburgh, EH14 4AS, tel/fax: 0131 451 3475 (24 hours) quoting Ref 66/02/J. The closing date is Friday 19th April 2002. Informal enquires can be directed to Phil Trinder tel: +44 131 451 3435, or e-mail: trinder@REDACTED More details of the project and further particulars for the position can be found at: http://www.cee.hw.ac.uk/~dsg/telecoms/ From rprice@REDACTED Wed Apr 3 11:46:32 2002 From: rprice@REDACTED (Roger Price) Date: Wed, 3 Apr 2002 09:46:32 +0000 (GMT) Subject: edoc structure In-Reply-To: Message-ID: On Wed, 3 Apr 2002, Vlad Dumitrescu wrote: > I have looked at JDox, a XML format for JavaDoc, and tried to adapt it to > Erlang and EDoc. Please look at the result and figure out what I forgot > about and what is superfluous. I used a simple outline format instead of a > real DTD because it's so much simpler to read. It would help if you provided a DTD: it's essential for validation of the document grammar, and later validation of the document instances. Are there no existing DTDs with existing tools which would do the job? Best Regards, Roger From DHawes@REDACTED Thu Apr 4 00:40:08 2002 From: DHawes@REDACTED (Hawes, Drew) Date: Wed, 3 Apr 2002 16:40:08 -0600 Subject: What is an acceptable AVAILABILITY %... Message-ID: for an 80% calls answered in 20 seconds 3 min AHT hrs of operation from 6am to 11pm ____________________________________________________________________________ Disclaimer: The information contained in this communication is confidential and proprietary, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. ____________________________________________________________________________ From vlad_dumitrescu@REDACTED Thu Apr 4 08:47:28 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 04 Apr 2002 08:47:28 +0200 Subject: edoc structure Message-ID: >It would help if you provided a DTD: it's essential for validation of the >document grammar, and later validation of the document instances. Yes, of course. I just thought that the DTD is much harder to read if one isn't used to reading DTDs. >Are there no existing DTDs with existing tools which would do the job? Couldn't find any. More precisely, there is Erlang specific information that would be difficult to store using a general DTD - it would come more or less to using something like ... gen_server ... or even ... behaviour gen_server ... I did write a DTD, which I attach here, and also tried to document it as a W3C schema. However the resulting HTML file is ~40k zipped and I'm not sure if everyone would be happy to have the mailbox clogged with it. Let me know if it's interesting. best regards, Vlad _________________________________________________________________ MSN Photos ?r det enklaste s?ttet att dela ut och skriva ut foton: http://photos.msn.se/Support/WorldWide.aspx From garry@REDACTED Thu Apr 4 21:28:59 2002 From: garry@REDACTED (Garry Hodgson) Date: Thu, 04 Apr 2002 14:28:59 -0500 Subject: starting erlang on remote node Message-ID: <3CACA97B.C2F364D3@sage.att.com> i'm writing some oam scripts to enable users to remotely start up erlang on various nodes in our linux clusters. i'm attempting to use ssh for this, and getting some errors i don't understand. in particular, when i run: ssh node0 erl -setcookie cookie -name node -pa $FATHOM/lib -run master checkin i get: Eshell V5.0.1 (abort with ^G) (node@REDACTED)1> =ERROR REPORT==== 4-Apr-2002::14:09:48 === ** System running to use fully qualified hostnames ** ** Hostname kestrel is illegal ** (node@REDACTED)1> and no response to anything i type at this command prompt. the master:checkin() from the "-run" arg does not appear to get run. hitting ^C gets me: Killed by signal 2. the "Hostname kestrel is illegal" error is odd, since i'm running this command from a machine named "master", although i did ssh there from kestrel originally. if i run the above command with "-node node@REDACTED" i get the same result. if i run the above command, minus the "ssh node0" on node0, it works fine. any ideas? thanks -- Garry Hodgson Let my inspiration flow Senior Hacker in token rhyme suggesting rhythm Software Innovation Services that will not forsake me AT&T Labs 'til my tale is told and done. garry@REDACTED From peter@REDACTED Thu Apr 4 22:07:20 2002 From: peter@REDACTED (Peter H|gfeldt) Date: Thu, 4 Apr 2002 22:07:20 +0200 (MET DST) Subject: What is an acceptable AVAILABILITY %... In-Reply-To: Message-ID: Please try www.erlang.com . erlang.org is for the programming language Erlang, and not for traffic calculations. Regards, Peter ------------------------------------------------------------------------- Peter H?gfeldt e-mail : peter@REDACTED Open Telecom Platform Phone: : +46 (8) 727 57 58 Ericsson Utvecklings AB Mobile : +46 070-519 57 51 S-126 25 STOCKHOLM Fax: : +46 (8) 727 5775 Office address: Armborstv?gen 1, ?lvsj? "Computers are machines that do exactly what you tell them, but often surprise you in the result." Richard Dawkins in The Blind Watchmaker On Wed, 3 Apr 2002, Hawes, Drew wrote: > for an 80% calls answered in 20 seconds > > 3 min AHT > > hrs of operation from 6am to 11pm > > > ____________________________________________________________________________ > > Disclaimer: The information contained in this communication is confidential > and proprietary, is intended only for the use of the recipient named above, > and may be legally privileged. If the reader of this message is not the > intended recipient, you are hereby notified that any dissemination, > distribution, or copying of this communication, or any of its contents, is > strictly prohibited. If you have received this communication in error, > please re-send this communication to the sender and delete the original > message and any copy of it from your computer system. > > ____________________________________________________________________________ > From svg@REDACTED Thu Apr 4 22:35:53 2002 From: svg@REDACTED (Vladimir Sekissov) Date: Fri, 05 Apr 2002 02:35:53 +0600 (YEKST) Subject: starting erlang on remote node In-Reply-To: <3CACA97B.C2F364D3@sage.att.com> References: <3CACA97B.C2F364D3@sage.att.com> Message-ID: <20020405.023553.09527122.svg@surnet.ru> Garry Hodgson wrote: garry> i'm writing some oam scripts to enable users to remotely start up garry> erlang on various nodes in our linux clusters. i'm attempting to use garry> ssh for this, and getting some errors i don't understand. in garry> particular, garry> when i run: garry> garry> ssh node0 erl -setcookie cookie -name node -pa $FATHOM/lib -run garry> master checkin garry> garry> i get: garry> garry> Eshell V5.0.1 (abort with ^G) garry> (node@REDACTED)1> garry> =ERROR REPORT==== 4-Apr-2002::14:09:48 === garry> ** System running to use fully qualified hostnames ** garry> ** Hostname kestrel is illegal ** garry> (node@REDACTED)1> garry> garry> and no response to anything i type at this command prompt. the garry> master:checkin() garry> from the "-run" arg does not appear to get run. hitting ^C gets me: garry> garry> Killed by signal 2. Your shell on remote host is not interactive. So you can't interact with your program. On localhost: $ echo $- himBH ^ +--- interactive $ ssh some.host.net 'echo $-' hBc - noninteractive (there isn't `i') And it's better to use -s instead of -run: ssh node0 erl -setcookie cookie -name node -pa $FATHOM/lib -s master checkin Best Regards, Vladimir Sekissov From garry@REDACTED Thu Apr 4 22:35:40 2002 From: garry@REDACTED (Garry Hodgson) Date: Thu, 04 Apr 2002 15:35:40 -0500 Subject: starting erlang on remote node References: <3CACA97B.C2F364D3@sage.att.com> <20020405.023553.09527122.svg@surnet.ru> Message-ID: <3CACB91C.28F1CD6C@sage.att.com> Vladimir Sekissov wrote: > Garry Hodgson wrote: > > garry> i'm writing some oam scripts to enable users to remotely start up > garry> erlang on various nodes in our linux clusters. i'm attempting to use > garry> ssh for this, and getting some errors i don't understand. in > garry> particular, > garry> when i run: > garry> > garry> ssh node0 erl -setcookie cookie -name node -pa $FATHOM/lib -run > garry> master checkin > garry> > garry> i get: > garry> > garry> Eshell V5.0.1 (abort with ^G) > garry> (node@REDACTED)1> > garry> =ERROR REPORT==== 4-Apr-2002::14:09:48 === > garry> ** System running to use fully qualified hostnames ** > garry> ** Hostname kestrel is illegal ** > garry> (node@REDACTED)1> > garry> > garry> and no response to anything i type at this command prompt. the > garry> master:checkin() > garry> from the "-run" arg does not appear to get run. hitting ^C gets me: > garry> > garry> Killed by signal 2. > > Your shell on remote host is not interactive. > So you can't interact with your program. i realized after i posted that i can, indeed, type at the erlang shell and run commands. the error above is coming from the master:checkin() call implied by the -run flag. if i run it by hand at the prompt i get, the same error appears, even though the nodename appears correct: (node@REDACTED)2> master:checkin(). =ERROR REPORT==== 4-Apr-2002::15:33:19 === ** System running to use fully qualified hostnames ** ** Hostname kestrel is illegal ** {checkin,'node@REDACTED'} (node@REDACTED)3> node(). 'node@REDACTED' -- Garry Hodgson Let my inspiration flow Senior Hacker in token rhyme suggesting rhythm Software Innovation Services that will not forsake me AT&T Labs 'til my tale is told and done. garry@REDACTED From rprice@REDACTED Fri Apr 5 00:04:37 2002 From: rprice@REDACTED (Roger Price) Date: Thu, 4 Apr 2002 22:04:37 +0000 (GMT) Subject: edoc structure In-Reply-To: Message-ID: On Thu, 4 Apr 2002, Vlad Dumitrescu wrote: > deprecated?, see?, modules, references?, copyright?)> Perhaps version could be an attribute. Attribute "lang" missing. Add an attribute "date"? > If authors? in application were replaced by author*, element authors could be removed. > exported NMTOKEN(yes | no) #REQUIRED Should read exported (yes | no) #REQUIRED. Attribute for arity? > Shouldn't this be an attribute? > name CDATA #IMPLIED > email CDATA #REQUIRED #REQUIRED is very strong here! > website CDATA #IMPLIED > > > Attribute? > See comment on authors. > See comment on authors. > See comment on authors. > > > See comment on authors. > See comment on authors. > See comment on authors. > See comment on authors. > Multiple definition! ... > Since there is no mixed content, perhaps (#PCDATA) could be replaced by CDATA throughout the DTD. After repair of attribute "exported" and removal of duplicate element valuetype, the DTD validates with James Clark's SP. Best Regards, Roger From per@REDACTED Fri Apr 5 06:28:39 2002 From: per@REDACTED (Per Bergqvist) Date: Fri, 05 Apr 2002 05:28:39 +0100 Subject: starting erlang on remote node In-Reply-To: <3CACB91C.28F1CD6C@sage.att.com> Message-ID: <200204050328.g353Sev09490@vargen.levonline.com> Garry, Erlang node names use either fully qualified domain names or "shortnames" for the host part of node name. This is controlled by the "-name" (FQDN) and "-sname" (short name) switches. To resolve your problem: a1) replace "-name node" with "-sname node" to use shortnames or a2) try to contact "kestrel.sage.att.com" instead of "kestrel". /Per > Vladimir Sekissov wrote: > > Garry Hodgson wrote: > > > > garry> i'm writing some oam scripts to enable users to remotely start up > > garry> erlang on various nodes in our linux clusters. i'm attempting to use > > garry> ssh for this, and getting some errors i don't understand. in > > garry> particular, > > garry> when i run: > > garry> > > garry> ssh node0 erl -setcookie cookie -name node -pa $FATHOM/lib -run > > garry> master checkin > > garry> > > garry> i get: > > garry> > > garry> Eshell V5.0.1 (abort with ^G) > > garry> (node@REDACTED)1> > > garry> =ERROR REPORT==== 4-Apr-2002::14:09:48 === > > garry> ** System running to use fully qualified hostnames ** > > garry> ** Hostname kestrel is illegal ** > > garry> (node@REDACTED)1> > > garry> > > garry> and no response to anything i type at this command prompt. the > > garry> master:checkin() > > garry> from the "-run" arg does not appear to get run. hitting ^C gets me: > > garry> > > garry> Killed by signal 2. > > > > Your shell on remote host is not interactive. > > So you can't interact with your program. > > i realized after i posted that i can, indeed, type at the erlang > shell and run commands. the error above is coming from the > master:checkin() > call implied by the -run flag. if i run it by hand at the prompt i get, > the same error appears, even though the nodename appears correct: > > (node@REDACTED)2> master:checkin(). > > =ERROR REPORT==== 4-Apr-2002::15:33:19 === > ** System running to use fully qualified hostnames ** > ** Hostname kestrel is illegal ** > {checkin,'node@REDACTED'} > (node@REDACTED)3> node(). > 'node@REDACTED' > > -- > Garry Hodgson Let my inspiration flow > Senior Hacker in token rhyme suggesting rhythm > Software Innovation Services that will not forsake me > AT&T Labs 'til my tale is told and done. > garry@REDACTED > ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From rusmufti@REDACTED Fri Apr 5 12:38:03 2002 From: rusmufti@REDACTED (Joerg Scheurich aka MUFTI) Date: Fri, 5 Apr 2002 12:38:03 +0200 (CEST) Subject: otp_src_R8B-0 on IRIX: IPPORT_USERRESERVED undefined Message-ID: Hi ! The compilation of the otp_src_R8B-0 source on IRIX 6.5 fails, cause IPPORT_USERRESERVED in line 64 of otp_src_R8B-0/lib/orber/c_src/setsockaddr_in.c is not defined. All you have is IPPORT_RESERVED (in /usr/include/netinet/in.h) so long MUFTI -- Pers?nlicher Benutzer - f?r den einzelnen Benutzer hing der Wunsch des kompakten, hohen Klarheit Kopfes SVGA-Bildschirmanzeigen (aus einer Webseite fuer einen 3D Datenhelm) From daniel.neri@REDACTED Fri Apr 5 13:02:49 2002 From: daniel.neri@REDACTED (Daniel =?iso-8859-1?q?N=E9ri?=) Date: 05 Apr 2002 11:02:49 +0000 Subject: otp_src_R8B-0 on IRIX: IPPORT_USERRESERVED undefined In-Reply-To: References: Message-ID: Joerg Scheurich aka MUFTI writes: > The compilation of the otp_src_R8B-0 source on IRIX 6.5 fails, cause > IPPORT_USERRESERVED in line 64 of > otp_src_R8B-0/lib/orber/c_src/setsockaddr_in.c is not defined. Yup. It breaks on NetBSD too, for the same reason. I proposed a fix quite some time ago: http://www.erlang.org/ml-archive/erlang-questions/200010/msg00045.html Regards, --Daniel -- Daniel N?ri Sigicom AB, Sweden From Laszlo.Varga@REDACTED Fri Apr 5 15:39:38 2002 From: Laszlo.Varga@REDACTED (Laszlo Varga) Date: Fri, 5 Apr 2002 15:39:38 +0200 (MEST) Subject: about gen_event Message-ID: <200204051339.g35DdcC19227@duna273.eth.ericsson.se> Hello all, I've spent a week or more with setting up a framework for some equipment management. After I got it work, I've realised that what i made was very alike to OTP's gen_event event manager module. So it seems that I reinvented the wheel again. Now I'm thinking about pushing my ideas into the gen_event concept. For helping me with this: COULD ANYONE SHOW ME PAPERS about USING GEN_EVENT. Thanks Laszlo Varga mailto:ethvala@REDACTED From matthias@REDACTED Fri Apr 5 16:03:13 2002 From: matthias@REDACTED (Matthias Lang) Date: Fri, 5 Apr 2002 16:03:13 +0200 Subject: about gen_event In-Reply-To: <200204051339.g35DdcC19227@duna273.eth.ericsson.se> References: <200204051339.g35DdcC19227@duna273.eth.ericsson.se> Message-ID: <15533.44705.409523.699758@antilipe.corelatus.se> Laszlo Varga writes: > COULD ANYONE SHOW ME PAPERS about USING GEN_EVENT. Inside Ericsson, if you're using Erlang/OTP you should have a manual (on paper, came with the system) called "Design Principles". Chapter 5 is about gen_event. You can probably also find it on PRIM/GASK ;-) or read it online at: http://www.erlang.org/doc/r8b/doc/design_principles/part_frame.html Matthias From svg@REDACTED Fri Apr 5 16:16:09 2002 From: svg@REDACTED (Vladimir Sekissov) Date: Fri, 05 Apr 2002 20:16:09 +0600 (YEKST) Subject: about gen_event In-Reply-To: <200204051339.g35DdcC19227@duna273.eth.ericsson.se> References: <200204051339.g35DdcC19227@duna273.eth.ericsson.se> Message-ID: <20020405.201609.61547058.svg@surnet.ru> Laszlo Varga wrote: Laszlo.Varga> I've spent a week or more with setting up a framework for Laszlo.Varga> some equipment management. After I got it work, I've realised Laszlo.Varga> that what i made was very alike to OTP's gen_event event manager module. Laszlo.Varga> So it seems that I reinvented the wheel again. Laszlo.Varga> Now I'm thinking about pushing my ideas into the gen_event concept. Laszlo.Varga> For helping me with this: Laszlo.Varga> COULD ANYONE SHOW ME PAPERS about USING GEN_EVENT. Look at Erlang/OTP EVA. It is a great, well documented application intended for event management. Best Regards, Vladimir Sekissov From garry@REDACTED Fri Apr 5 17:19:35 2002 From: garry@REDACTED (Garry Hodgson) Date: Fri, 05 Apr 2002 10:19:35 -0500 Subject: starting erlang on remote node References: <200204050328.g353Sev09490@vargen.levonline.com> Message-ID: <3CADC087.F1DFF471@sage.att.com> Per Bergqvist wrote: > Erlang node names use either fully qualified domain names or > "shortnames" for the host part of node name. > This is controlled by the "-name" (FQDN) and "-sname" (short name) > switches. > > To resolve your problem: > a1) replace "-name node" with "-sname node" to use shortnames > or > a2) try to contact "kestrel.sage.att.com" instead of "kestrel". Francesco Cesarini wrote: > I think you are mixing long node names with short node names in your > program (When using the -name flag, you should have the domain name > kestrel.sage.att.com). Nodes started with a long name can not > communicate with nodes started with a short name. thanks, i know about long and short names. the thing that had me puzzled was why the name "kestrel" was involved at all. i'm running the ssh from "master.sage.att.com" on another machine "node0.sage.att.com". but your mail prompted me to look more carefully, and i found a default value in the code that is used if it can't find the correct environment variable. when running over ssh, the proper environment is not set, and this short name was being used, where everywhere else i use long names. hence the problem. i now feed it the proper value with the -env flag. thanks -- Garry Hodgson Let my inspiration flow Senior Hacker in token rhyme suggesting rhythm Software Innovation Services that will not forsake me AT&T Labs 'til my tale is told and done. garry@REDACTED From hans@REDACTED Fri Apr 5 17:20:18 2002 From: hans@REDACTED (Hans Nilsson) Date: Fri, 5 Apr 2002 17:20:18 +0200 (CEST) Subject: Bug in erl_interface 3.3.0 (with fix) Message-ID: Hi, In encode_term.c in erl_interface 3.3.0 (open source erlang R8B-0) there is a bug in the function ei_x_encode_term. 32c32 < if (!x_fix_buff(x, i)) --- > if (!x_fix_buff(x, (i+erl_term_len(t)) )) With this patch it will calculate the size of the needed area before checking the area size. The changed function is like this after the fix: int ei_x_encode_term(ei_x_buff* x, void* t) { int i = x->index; char* s, * s0; if (!x_fix_buff(x, (i+erl_term_len(t)) )) return -1; s0 = s = x->buff + i; i += erl_term_len(t) - 1; if (erl_encode_it(t,(unsigned char **)&s, 5)) return -1; x->index += s - s0; return 0; } By the way, couldn't "i += erl_term_len(t) - 1;" be removed? /Hans From kent@REDACTED Fri Apr 5 18:40:23 2002 From: kent@REDACTED (Kent Boortz) Date: 05 Apr 2002 18:40:23 +0200 Subject: Bug in erl_interface 3.3.0 (with fix) In-Reply-To: Hans Nilsson's message of "Fri, 5 Apr 2002 17:20:18 +0200 (CEST)" References: Message-ID: Hans Nilsson writes: > In encode_term.c in erl_interface 3.3.0 (open source erlang R8B-0) there > is a bug in the function ei_x_encode_term. > > 32c32 > < if (!x_fix_buff(x, i)) > --- > > if (!x_fix_buff(x, (i+erl_term_len(t)) )) > > > With this patch it will calculate the size of the needed area before > checking the area size. Thank you for the patch. I can't find the reason why this function does not follow the safer coding pattern of the ei_x_encode_* functions in "ei_x_encode.c", i.e. why it was not written like int ei_x_encode_term(ei_x_buff* x, void* t) { int i = x->index; ei_encode_term(NULL, &i, t); if (!x_fix_buff(x, i)) return -1; return ei_encode_term(x->buff, &x->index, t); } kent From hal@REDACTED Sat Apr 6 20:06:43 2002 From: hal@REDACTED (Hal Snyder) Date: 06 Apr 2002 12:06:43 -0600 Subject: Ousterhout papers and Erlang Message-ID: <87vgb4hfbg.fsf@gamera.vail> A little Erlang advocacy. Two of my favorite papers from Usenix past are by John Ousterhout. (IIRC the second was quoted heavily as part of the 1999 keynote address.) Scripting: Higher Level Programming for the 21st Century http://home.pacbell.net/ouster/scripting.html This paper explains, and makes a very rough stab at quantifying, the gains to be had using a scripting language such as Perl or Tcl. I think one can realize the same sorts of gains using Erlang, for many of the same reasons mentioned. Where I work, one change might be that, where Ousterhout writes of using Perl or Tcl to glue together different programs, we use OTP to glue together different network resources in a distributed and reliable way. Why Threads Are A Bad Idea (for most purposes) http://www.cc.gatech.edu/ccg/people/rob/software/threads/ousterhout_threads.html Certainly developing a multi-process app in Erlang shields one from the week-long bughunts seen when a project goes deep into C++/threading/STL country - trying to determine whether a segfault that happens after a million or so transactions comes from application, system libs, toolchain, or OS. Not to say using threads is always bad; but doing so relentlessly distributes into one's code complexity that has for decades been sequestered in the operating system. From bjarne@REDACTED Mon Apr 8 11:29:05 2002 From: bjarne@REDACTED (Bjarne =?iso-8859-1?Q?D=E4cker?=) Date: Mon, 08 Apr 2002 11:29:05 +0200 Subject: Erlang User Conference 2002 References: <87vgb4hfbg.fsf@gamera.vail> Message-ID: <3CB162E1.9C7568FC@erix.ericsson.se> EUC'2002 Welcome to the Eight International Erlang User Conference which will take place on November 19, 2002, in Stockholm. Please see the call-for-papers http://www.erlang.se/euc/02/ This is not to be confused with the ACM SIGPLAN Erlang workshop in Pittsburgh http://www.erlang.se/workshop/2002/ So there will be two international Erlang events this year ! The EUC'2002 invites researchers, developers, users, programmers, etc. and persons interested in functional or concurrent programming or who are interested in large scale software developments. Please make a note in your calendar already now ! Bjarne D?cker Computer Science Lab Ericsson AB From zist@REDACTED Mon Apr 8 16:28:50 2002 From: zist@REDACTED (. zist) Date: Mon, 08 Apr 2002 14:28:50 +0000 Subject: Non blocking mode for port ? Message-ID: How is it possible to change a port to non-blocking mode ? I'm using a port as a named pipe/fifo for communication towards an external process Port = open_port(fifo,[eof,out]) If the remote process dies, the erlang program stays blocked in the send/port_command operation so obviously ports are by default in blocking mode. In C, I would use the O_NONBLOCK flag (when opening the fifo or later on with fcntl), and then instead of staying blocked on the write operation, the process would receive a SIGPIPE signal on failure of the remote process. Thanks, Christophe Lesourd InSerTO _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com From philou@REDACTED Mon Apr 8 21:36:46 2002 From: philou@REDACTED (Philippe Strauss) Date: Mon, 8 Apr 2002 21:36:46 +0200 Subject: snmp_mgr_tests.erl and udp or gen_udp start() function Message-ID: <20020408193646.GA8769@philou.ch> Hello, I'm starting to learn Erlang, and I would like to have something interesting to cut my tooth against, and since I'm in SNMP managers right now, I try to run snmp_mgr_tests.erl BUT a compile warning tell me to use gen_udp instead of from snmp_mgr_tests.erl: ... -compile(export_all). -import(snmp_mgr, [gn/1, g/1, s/1, expect/2, expect/4, expect/6]). start() -> udp:start(), <--- warning tells use gen_udp instead !! snmp_mgr:start([{agent,"192.168.x.x"},{community,"nopublic"}, % {mibs,["STANDARD-MIB.bin"]}, quiet]), simple_standard_test(). ... BUT neither udp nor gen_udp have a start() function exported, 4> c(snmp_mgr_tests). {ok,snmp_mgr_tests} 5> snmp_mgr_tests:start(). ** exited: {undef,[{gen_udp,start,[]}, {snmp_mgr_tests,start,0}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** if I comment out the (gen)_udp:start(), line, I can run the manager but it only timeout, tcpdumping the loopback show this: 21:30:19.902606 195.202.200.121.5000 > 195.202.200.121.4000: udp 41 (DF) 21:30:19.902653 195.202.200.121 > 195.202.200.121: icmp: 195.202.200.121 udp port 4000 unreachable [tos 0xc0] ... 21:30:23.412972 195.202.200.121.5000 > 195.202.200.121.4000: udp 42 (DF) 21:30:23.413029 195.202.200.121 > 195.202.200.121: icmp: 195.202.200.121 udp port 4000 unreachable [tos 0xc0] so how do we start this udp layer? is there an up-to-date snmp_mgr_tests.erl? thanks a lot. -- Philippe Strauss http://philou.ch/ L'indiff?rence est le plus grand risque de notre temps, la forme civilis?e de la cruaut?. -- Zenta Maurina -- From mbj@REDACTED Mon Apr 8 21:48:37 2002 From: mbj@REDACTED (Martin Bjorklund) Date: Mon, 08 Apr 2002 21:48:37 +0200 (CEST) Subject: snmp_mgr_tests.erl and udp or gen_udp start() function In-Reply-To: <20020408193646.GA8769@philou.ch> References: <20020408193646.GA8769@philou.ch> Message-ID: <20020408.214837.74741826.mbj@bluetail.com> Hi, Philippe Strauss wrote: > Hello, > > I'm starting to learn Erlang, and I would like to have something > interesting to cut my tooth against, and since I'm in SNMP managers > right now, I try to run snmp_mgr_tests.erl Where did you find that module? It's obviously not up-to-date, but it may work after some modifications... > start() -> > udp:start(), <--- warning tells use gen_udp instead !! The udp module is obsolete, and gen_udp does not have a start function. Just remove this call. > 21:30:23.412972 195.202.200.121.5000 > 195.202.200.121.4000 ^^^^ The problem here is that the snmp_mgr module is using port 4000 by default, for some historic reason. Use the option {agent_port, 161} to snmp_mgr:start(). /martin From philou@REDACTED Mon Apr 8 22:00:10 2002 From: philou@REDACTED (Philippe Strauss) Date: Mon, 8 Apr 2002 22:00:10 +0200 Subject: snmp_mgr_tests.erl and udp or gen_udp start() function Message-ID: <20020408200010.GB9095@philou.ch> On Mon, Apr 08, 2002 at 09:48:37PM +0200, Martin Bjorklund wrote: > Hi, Hi Martin, it's the debian erlang-base package, version 8.0 (debian 8.0-4) philou@REDACTED:~$ dpkg -S snmp_mgr_tests erlang-base: /usr/lib/erlang/lib/snmp-3.3.3/examples/snmp_mgr_tests.erl philou@REDACTED:~$ dpkg -s erlang-base Package: erlang-base Status: install ok installed Priority: optional Section: non-US Installed-Size: 22864 Maintainer: Samuel Tardieu Source: erlang Version: 1:8.0-4 Replaces: erlang-java, erlang-erl Conflicts: erlang-java, erlang-erl Description: Erlang architecture independent files Open Source Erlang is a functional programming language designed at the Ericsson Computer Science Laboratory. . Some of Erlang's main features are: Clear declarative syntax and is largely free from side-effects; Builtin support for real-time, concurrent and distributed programming; Designed for development of robust and continuously operated programs; Dynamic code replacement at runtime. . This package contains all the architecture independent file of the Erlang runtime. regards. -- Philippe Strauss http://philou.ch/ L'indiff?rence est le plus grand risque de notre temps, la forme civilis?e de la cruaut?. -- Zenta Maurina -- From svg@REDACTED Mon Apr 8 22:36:29 2002 From: svg@REDACTED (Vladimir Sekissov) Date: Tue, 09 Apr 2002 02:36:29 +0600 (YEKST) Subject: snmp_mgr_tests.erl and udp or gen_udp start() function In-Reply-To: <20020408193646.GA8769@philou.ch> References: <20020408193646.GA8769@philou.ch> Message-ID: <20020409.023629.23150832.svg@surnet.ru> Philippe Strauss wrote: philou> I'm starting to learn Erlang, and I would like to have something philou> interesting to cut my tooth against, and since I'm in SNMP managers philou> right now, I try to run snmp_mgr_tests.erl philou> philou> so how do we start this udp layer? is there an up-to-date philou> snmp_mgr_tests.erl? If you work with Cisco routers I have Cisco dial-up connection SNMP monitor/killer. I used modified snmp_mgr for it so I could get multiple SNMP sessions at the same time. It has HTTP and CORBA interfaces. Let me know and I'll send you code by e-mail. Best Regards, Vladimir Sekissov From joe@REDACTED Tue Apr 9 10:25:09 2002 From: joe@REDACTED (Joe Armstrong) Date: Tue, 9 Apr 2002 10:25:09 +0200 (CEST) Subject: Bug methinks :-) Message-ID: If I define a couple of macros -define(Entry(X, Y), (Y:X)). -define(DWORD, 32/unsigned-little-integer). -define(LONG, 32/unsigned-little-integer). -define(WORD, 16/unsigned-little-integer). -define(BYTE, 8/unsigned-little-integer). Then some fancy stuff in C Like typedef struct IMAGE_OPTIONAL_HEADER { DWORD ImageBase; DWORD SectionAlignment; DWORD FileAlignment; WORD MajorOperatingSystemVersion; Becomes in Erlang << ?Entry(?DWORD, ImageBase), ?Entry(?DWORD, SectionAlignment), ?Entry(?DWORD, FileAlignment), ?Entry(?WORD, MajorOperatingSystemVersion), Which is near enough to make me feel warm and fuzzy inside. If I then compile this I get an error. Here's bug.erl -module(bug). -compile(export_all). -define(Entry(X, Y), (Y:X)). -define(DWORD, 32/unsigned-little-integer). -define(WORD, 16/unsigned-little-integer). foo(B) -> <> = B. Compiling gives > erlc bug.erl bug.erl:14: illegal pattern bug.erl:15: illegal pattern bug.erl:16: illegal pattern bug.erl:17: illegal pattern But amazingly > erlc -P bug.erl > mv bug.P bug1.erl > erlc bug1.erl Compiles correctly - which is not what I had expected. /Joe From Laszlo.Varga@REDACTED Tue Apr 9 11:51:39 2002 From: Laszlo.Varga@REDACTED (Laszlo Varga) Date: Tue, 9 Apr 2002 11:51:39 +0200 (MEST) Subject: what's happend to hyber.org? Message-ID: <200204090951.g399pdC20631@duna273.eth.ericsson.se> Hi, is there anybody knows something about yaws.hyber.org? Thanks Laszlo Varga From vlad_dumitrescu@REDACTED Tue Apr 9 12:53:35 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 09 Apr 2002 12:53:35 +0200 Subject: Bug methinks :-) Message-ID: Hi, your program works with -define(Entry(X, Y), Y:X). but I think it isn't _that_ bug you are referring to :-) It is very weird to see that there is no error in the second case... My guess is that erl_lint is not run when compiling with -P, and the parantheses are removed in the process. Should it work with parantheses? regards, Vlad >If I define a couple of macros > >-define(Entry(X, Y), (Y:X)). >...snip... >But amazingly > > > erlc -P bug.erl > > mv bug.P bug1.erl > > erlc bug1.erl > >Compiles correctly - which is not what I had expected. _________________________________________________________________ Kom med i v?rldens st?rsta e-posttj?nst; MSN Hotmail. http://www.hotmail.com/sv From vlad_dumitrescu@REDACTED Tue Apr 9 14:10:48 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 09 Apr 2002 14:10:48 +0200 Subject: SDL code generation tool Message-ID: Hi again, I stumbled upon Magnus Fr?berg's paper about the above topic. I think it would be very educative to be able to look at the code, if it is available somewhere. Does anybody know more details? regards, Vlad _________________________________________________________________ Chatta med v?nner online, prova MSN Messenger: http://messenger.msn.se From martin@REDACTED Wed Apr 10 03:25:21 2002 From: martin@REDACTED (Martin J. Logan) Date: Tue, 09 Apr 2002 20:25:21 -0500 Subject: Mnesia Questions References: <402DD461F109D411977E0008C791C312039F63F8@IMP02MBX> Message-ID: <3CB39481.3F78B178@vailsys.com> Hello All, I have a few quiestions regarding mnesia policy and capability. 1. I know that dirty operations do not aquire a lock on a table but do they respect one? 2. I have a situation where I am reloading some data on the fly. It is not acceptable to lock the table delete the old data and reload the new. Since the data is competely differant it is also not possible to simply update the records. I must have this done quickly. I am wondering if there is some method similar to a pointer switch in C where in I could fill up another table with the data and then simply switch the pointer from the old table to the new - perhaps like a code change. If this is not possible, and I can think of a few reasons why it wouldn't be, does anyone have any suggestions on how I might rapidly exchange my data. Thanks, Martin From etxuwig@REDACTED Wed Apr 10 09:27:11 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 10 Apr 2002 09:27:11 +0200 (MET DST) Subject: Mnesia Questions In-Reply-To: <3CB39481.3F78B178@vailsys.com> Message-ID: On Tue, 9 Apr 2002, Martin J. Logan wrote: >Hello All, > I have a few quiestions regarding mnesia policy and capability. >1. I know that dirty operations do not aquire a lock on a table >but do they respect one? No, they don't. Dirty operations honour replication and indexing, but do not check for the presence of locks. Since they cannot acquire locks, forcing them to wait for locks could cause unpleasant effects (like starvation of dirty ops, which are really intended to be blindingly fast.) >2. I have a situation where I am reloading some data on the fly. It is not > acceptable to lock the table delete the old data and reload > the new. Since the data is competely differant it is also not > possible to simply update the records. I must have this done > quickly. I am wondering if there is some method similar to a > pointer switch in C where in I could fill up another table with > the data and then simply switch the pointer from the old table to > the new - perhaps like a code change. If this is not possible, and > I can think of a few reasons why it wouldn't be, does anyone have > any suggestions on how I might rapidly exchange my data. > > Thanks, > Martin If you're storing your data in mnesia, you can do something like this (just snipping from a call prefix analysis program that I wrote a long time ago): %% We start by finding out which is the active tab, then we stay %% within that tab. This is so that we may switch to a new tab %% after editing numbers off-line. The old tab must remain for %% a few millisecs to ensure that no lookups are made to it %% anymore, then it may be removed. lookup(Num) -> Tab = where_to_read(), case get_lengths(Num, Tab) of [] -> []; Ls -> match_lengths(Ls, (length(Num) bsl 3), lists:reverse(Num), Tab) end. where_to_read() -> ets:lookup_element(anax, where_to_read, 2). That is, keep an active table and a "scratch" table. You may edit the scratch table and build your data there, and then switch, by updating a "pointer" in a central table. This is fairly common when building/editing prefix lookup tables. The active and scratch tables can be configured to have exactly the same record representation.... Come to think of it, I use practically the same setup in CCviewer's cross-reference tables: I select a table based on the "config spec" (ClearCase branch), but here, I select tables using an algorithm and the venerable list_to_atom() function. list_exports(Module, CS) -> Tab = table_name(exports, CS), case ets:lookup(Tab, to_int_module(Module)) of [] -> {error, not_found}; [#ccv_exports{exports = Exports}] -> {ok, Exports} end. table_name(xrefs, CS) -> list_to_atom("ccv_xrefs_" ++ CS); table_name(exports, CS) -> list_to_atom("ccv_exports_" ++ CS); table_name(includes, CS) -> list_to_atom("ccv_includes_" ++ CS); table_name(records, CS) -> list_to_atom("ccv_records_" ++ CS); table_name(defines, CS) -> list_to_atom("ccv_defines_" ++ CS). = = = = If you keep your data on the heap, you can make quite exensive updates quite cheaply as long as you consider how data is stored and updated on the heap. You should avoid, for example, keeping your data in a huge record, as the entire record (essentially a pointer array) is copied each time you change an attribute. In e.g. gb_trees and dict, you may keep a large access structure with quite large objects on the heap and very cheaply update objects without extensive copying. /Uffe From vlad_dumitrescu@REDACTED Wed Apr 10 13:18:50 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 10 Apr 2002 13:18:50 +0200 Subject: xmerl fix Message-ID: Hi all, There is a thing about xmerl that I stumbled upon, in the handling of the simple-xml format. It seems that in {Tag, Content}, Content must be an atom, a {Tag...} tuple or a list beginning with an integer (text). But this makes building something like "This is quite fun" awkward: "This is " ++ {em, "quite"} ++ " fun" instead of the nicer and more natural (I think) ["This is ", {em, "quite"}, " fun"] In case my pooint of view is accepted, I include a quick-and-dirty diff on xmerl.erl, a very ugly hack but I couldn't come up with a nicer one without rewriting a lot more. best regards, Vlad 193a194,206 > expand_content(Content = [H|_], Pos, Parents) when list(H) -> > case catch list_to_binary(Content) of > {'EXIT', _} -> > %% mixed content > {Text, Rest} = collect_text(lists:flatten(Content)), > [#xmlText{pos = Pos, > parents = Parents, > value = Text}|expand_content(Rest, Pos+1, Parents)]; > Bin -> > [#xmlText{pos = Pos, > parents = Parents, > value = binary_to_list(Bin)}] > end; 203a217,218 > collect_text([H|T], Acc) when list(H) -> > collect_text(T, [lists:reverse(H)|Acc]); From hal@REDACTED Wed Apr 10 16:06:17 2002 From: hal@REDACTED (Hal Snyder) Date: 10 Apr 2002 09:06:17 -0500 Subject: resynchronizing mnesia nodes Message-ID: <87elhnfy1y.fsf@gamera.vail> We are looking at various policies for recovering from communication failure with mnesia, and studying Chapter 6 of the Mnesia User's Guide, Version 4.0. Suppose you have several nodes running mnesia, replicating content. They become partitioned long enough to record mutual mnesia_down entries, and continue to receive updates. In some special cases - for example, when updates to a table consist only of adding a positive increment to a counter, or of inserting a record with a globally unique key - it should be possible to resynchronize automatically without fear of inconsistencies. Is this sort of thing readily feasible with mnesia? Is anyone doing it? From martin@REDACTED Wed Apr 10 22:57:25 2002 From: martin@REDACTED (Martin J. Logan) Date: Wed, 10 Apr 2002 15:57:25 -0500 Subject: Telecom & Mnesia - Call Detail Record Collection References: Message-ID: <3CB4A735.4262D75A@vailsys.com> Hello All, I am working for a small telephony company here in the States. The only method that we have for billing our customers is via call detail records. The system that we are using now is a rather poor one. My boss and I propose that we can revolutionize the way that we do this by employing erlang and mnesia. All of my past projects with it have been extremly succesfull. I have started running some preliminary stress/load tests with mnesia and I am encountering a few problems. Mnesia really seems to slow down at 120,000 small records stored as disk_only_copies and at 300,000 small records stored as ram_copies. The requirements for this project could be in excess of 8 gig of data storage with 500,000 records comming in on a daily basis. I have always thought of mnesia as a real time db for storing smaller amounts of data. I would like to build this cdr collection and reporting system entirly in erlang though and remove the need for the sql db if possible. The more erlang the better off we all are. The quiestions I have are: 1. Has anyone stored such a vast amount of data in mnesia? I could not find much on the list. 2. How does mnesia preform under large loads? I need to do reporting on the data. 3. What are the most effective mnesia configurations for maxing out its data storage potential? What is its potential? 3. Has anyone out there used mnesia/erts/otp for call detail record collection? If so can you give me any recomendations for my project? Thank you for any help in this matter, Martin. From Chandrashekhar.Mullaparthi@REDACTED Thu Apr 11 08:16:22 2002 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Thu, 11 Apr 2002 07:16:22 +0100 Subject: Telecom & Mnesia - Call Detail Record Collection Message-ID: <402DD461F109D411977E0008C791C31205E065D1@imp02mbx.one2one.co.uk> We store information about our entire customer base (10+ million) in an mnesia database. Right now, this is split into fragments across 8 machines with replicas on 8 other machines. We are now planning to put the entire database on one machine with the database split into fragments across two erlang nodes. And our previous experience shows that we can support upto a 1000 transactions/sec. But this database takes relatively few writes compared to the amount of reads. If you want to store a lot of data you should fragment your mnesia tables. We haven't really thought of using mnesia for storing CDRs - my initial thoughts would be that mnesia wouldn't be very suitable for this. let us know how you get on. cheers, Chandru -----Original Message----- From: Martin J. Logan [mailto:martin@REDACTED] Sent: 10 April 2002 21:57 Cc: 'Erlang Questions' Subject: Telecom & Mnesia - Call Detail Record Collection Hello All, I am working for a small telephony company here in the States. The only method that we have for billing our customers is via call detail records. The system that we are using now is a rather poor one. My boss and I propose that we can revolutionize the way that we do this by employing erlang and mnesia. All of my past projects with it have been extremly succesfull. I have started running some preliminary stress/load tests with mnesia and I am encountering a few problems. Mnesia really seems to slow down at 120,000 small records stored as disk_only_copies and at 300,000 small records stored as ram_copies. The requirements for this project could be in excess of 8 gig of data storage with 500,000 records comming in on a daily basis. I have always thought of mnesia as a real time db for storing smaller amounts of data. I would like to build this cdr collection and reporting system entirly in erlang though and remove the need for the sql db if possible. The more erlang the better off we all are. The quiestions I have are: 1. Has anyone stored such a vast amount of data in mnesia? I could not find much on the list. 2. How does mnesia preform under large loads? I need to do reporting on the data. 3. What are the most effective mnesia configurations for maxing out its data storage potential? What is its potential? 3. Has anyone out there used mnesia/erts/otp for call detail record collection? If so can you give me any recomendations for my project? Thank you for any help in this matter, Martin. NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From per@REDACTED Thu Apr 11 11:22:28 2002 From: per@REDACTED (Per Bergqvist) Date: Thu, 11 Apr 2002 10:22:28 +0100 Subject: Telecom & Mnesia - Call Detail Record Collection In-Reply-To: <3CB4A735.4262D75A@vailsys.com> Message-ID: <200204110822.g3B8MSA28384@raven.levonline.com> Hi Martin, My experience is that disk_copies work extremely well until you run out of RAM. disk_only_copies seem to consume memory relative the database size and run out of steam far to early for really large databases. I have a similiar problem like your CDR problem and for this purpose I use Berkeley db which is performing well even with very large databases. This however, does not give you a distributed database. My intention is to combine Berkeley db with mnesia transaction management, but this is really just an idea at this stage due to lack of time. /Per > Hello All, > I am working for a small telephony company here in the States. The only > method that we have for billing our customers is via call detail records. The > system that we are using now is a rather poor one. My boss and I propose that > we can revolutionize the way that we do this by employing erlang and mnesia. > All of my past projects with it have been extremly succesfull. I have started > running some preliminary stress/load tests with mnesia and I am encountering a > few problems. Mnesia really seems to slow down at 120,000 small records stored > as disk_only_copies and at 300,000 small records stored as ram_copies. The > requirements for this project could be in excess of 8 gig of data storage with > 500,000 records comming in on a daily basis. I have always thought of mnesia > as a real time db for storing smaller amounts of data. I would like to build > this cdr collection and reporting system entirly in erlang though and remove > the need for the sql db if possible. The more erlang the better off we all > are. > The quiestions I have are: > > 1. Has anyone stored such a vast amount of data in mnesia? I could not find > much on the list. > 2. How does mnesia preform under large loads? I need to do reporting on the > data. > 3. What are the most effective mnesia configurations for maxing out its data > storage potential? What is its potential? > 3. Has anyone out there used mnesia/erts/otp for call detail record > collection? If so can you give me any recomendations > for my project? > > Thank you for any help in this matter, > Martin. > ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From etxuwig@REDACTED Thu Apr 11 10:41:59 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 11 Apr 2002 10:41:59 +0200 (MET DST) Subject: Telecom & Mnesia - Call Detail Record Collection In-Reply-To: <200204110822.g3B8MSA28384@raven.levonline.com> Message-ID: On Thu, 11 Apr 2002, Per Bergqvist wrote: >I have a similiar problem like your CDR problem and for this >purpose I use Berkeley db which is performing well even with >very large databases. > >This however, does not give you a distributed database. My >intention is to combine Berkeley db with mnesia transaction >management, but this is really just an idea at this stage due to >lack of time. > >/Per I've also thought about similar things. One thing I did in the past was to add triggers (abort/commit) to the rdbms contrib. It's not a completely clean solution, but one could perhaps build on the rdbms framework in order to tie an external database to mnesia's transaction handling. At least, it doesn't require hacking mnesia to get it working reasonably well... I think. (The triggers work well. We use exactly the same solution in AXD 301, and they work even for nested transactions.) A seemless integration of external tables in mnesia requires some hacking -- not a lethal dose, but enough to warrant some consideration first. It's been discussed. Dan G. usually doesn't do cartwheels when it's brought up, but the idea hasn't been killed yet. ;) I have not updated the rdbms contrib for OTP R8 (it still requires a patch to mnesia_schema, but I've been promised that my changes will be part of the next mnesia release.) If anyone actually uses rdbms today, I'm not aware of it. My next rdbms project was going to be to incorporate support for fragmented tables, together with a facility to explicitly control the distribution of objects between fragments. If anyone is interested in that, let me know, and I might give it slightly higher priority... /Uffe From etxuwig@REDACTED Thu Apr 11 10:55:54 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 11 Apr 2002 10:55:54 +0200 (MET DST) Subject: Telecom & Mnesia - Call Detail Record Collection In-Reply-To: <3CB4A735.4262D75A@vailsys.com> Message-ID: On Wed, 10 Apr 2002, Martin J. Logan wrote: >Hello All, > I am working for a small telephony company here in the >States. The only method that we have for billing our customers >is via call detail records. The system that we are using now is >a rather poor one. My boss and I propose that we can >revolutionize the way that we do this by employing erlang and >mnesia. Erlang -- great; I'm not sure about using mnesia for this, though. >The requirements for this project could be in excess of 8 gig of >data storage with 500,000 records comming in on a daily basis. I >have always thought of mnesia as a real time db for storing >smaller amounts of data. I would like to build this cdr >collection and reporting system entirly in erlang though and >remove the need for the sql db if possible. The more erlang the >better off we all are. Question: is this a CDR collection or generation system, or both? In a CDR collection system (which presumably also does analysis and produces bills), you certainly want a powerful database system of sorts. You'll probably end up doing correlation, rules lookup, taking into account discount rules, coupon days, etc. In a CDR generation system, you usually want to transfer CDRs to the collection system as efficiently as possible, either in real-time (a la RADIUS accounting), or in batch (normal for telecom systems). For this, I'd use_disk log, and perhaps ftp. Basically, disk_log will efficiently throw the CDRs onto disk, and you'd probably want to configure it as a stop log, since you don't want to automatically overwrite old CDRs. Using Erlang is probably still a good idea, since it offers advantages both in generation and collection: - if you need to scale by adding processors, Erlang will handle much of that in a nearly transparent fashion. - if you want to write sophisticated filtering functions for correlation of CDRs, Erlang's declarative style will probably come in handy. >The quiestions I have are: > >1. Has anyone stored such a vast amount of data in mnesia? I >could not find much on the list. Chandru and Per B answered. I've been storing a few million records in disc_copies (which use disk_log for disk storage, but also keep the table in RAM). One needs _lots_ of RAM for this type of setup (I have 1 GB, and that's really not sufficient.) >2. How does mnesia preform under large loads? I need to do >reporting on the data. It depends on how you store data and what your access patterns are. For reporting, I guess you do mostly reads. If you're reading/traversing tables that are loaded into RAM, mnesia shines. On disk-based accesses, most decent DBMSs will probably run circles around it. Mnesia is still mainly a RAM-based DBMS, with facilities for disk storage. If you're continuously running transactions with lots of writes on disk-based tables, you may want to use the transaction type 'sync_transaction' (mnesia:activity(sync_transaction, Fun)). Otherwise, mnesia will log your writes to a transaction log, and periodically "dump" the log information into the actual tables. This will make the transaction appear cheaper than they really are, and you may eventually overload the system. >3. What are the most effective mnesia configurations for maxing >out its data storage potential? What is its potential? I think this is a moving target. If you use fragmented tables, the potential for storing large amounts of data in mnesia is huge, but it probably doesn't suit all applications. I recall that H?kan Mattsson verified linear transaction processing scalability of mnesia in a 50 node system. If your application allows the database to be partitioned, and accesses can be localized to single fragments, it's mostly a question about how much hardware you can throw at the solution (well, with a hard BEAM limit of 256 nodes). >3. Has anyone out there used mnesia/erts/otp for call detail >record collection? If so can you give me any recomendations for >my project? We use Erlang for CDR collection and transfer to a (non-Erlang) billing system. I tried to find a public document that describes how we do it, but have yet been unsuccessful. At least, we support 90,000 voice calls per processor, and are able to turn on charging on each call. We're also able to output CDRs in a robust manner. I believe that we've dimensioned the intermediate storage of CDRs for 720,000 records, which should be enough for a while, given that we periodically output records to one of two redundant Billing Systems. The Billing system is not Erlang-based, and is Somebody Else's Problem (tm). I can't give you any hints there. (: /Uffe From phillipd@REDACTED Thu Apr 11 17:19:12 2002 From: phillipd@REDACTED (phillipd@REDACTED) Date: Thu, 11 Apr 2002 08:19:12 -0700 Subject: Telecom & Mnesia - Call Detail Record Collection Message-ID: Hi, I realize I am jumping into an area I am not too versed in, but here goes. In the database world I live in (pick like stuff) there is a file type called a Partfile. Depending on the key it goes into a section of the file (key ends in 0 it goes into the 0 part file) It would seem to me that segmenting transactions to Berkeley DB that has several "instances" running on the various nodes would work. But it may not solve the problem discussed, and may be a maintenacne headache. /Dale -----Original Message----- From: Ulf Wiger [mailto:etxuwig@REDACTED] Sent: Thursday, April 11, 2002 1:42 AM To: Per Bergqvist Cc: 'Erlang Questions' Subject: Re: Telecom & Mnesia - Call Detail Record Collection On Thu, 11 Apr 2002, Per Bergqvist wrote: >I have a similiar problem like your CDR problem and for this >purpose I use Berkeley db which is performing well even with >very large databases. > >This however, does not give you a distributed database. My >intention is to combine Berkeley db with mnesia transaction >management, but this is really just an idea at this stage due to >lack of time. > >/Per I've also thought about similar things. One thing I did in the past was to add triggers (abort/commit) to the rdbms contrib. It's not a completely clean solution, but one could perhaps build on the rdbms framework in order to tie an external database to mnesia's transaction handling. At least, it doesn't require hacking mnesia to get it working reasonably well... I think. (The triggers work well. We use exactly the same solution in AXD 301, and they work even for nested transactions.) A seemless integration of external tables in mnesia requires some hacking -- not a lethal dose, but enough to warrant some consideration first. It's been discussed. Dan G. usually doesn't do cartwheels when it's brought up, but the idea hasn't been killed yet. ;) I have not updated the rdbms contrib for OTP R8 (it still requires a patch to mnesia_schema, but I've been promised that my changes will be part of the next mnesia release.) If anyone actually uses rdbms today, I'm not aware of it. My next rdbms project was going to be to incorporate support for fragmented tables, together with a facility to explicitly control the distribution of objects between fragments. If anyone is interested in that, let me know, and I might give it slightly higher priority... /Uffe From hakan@REDACTED Thu Apr 11 17:53:15 2002 From: hakan@REDACTED (Hakan Mattsson) Date: Thu, 11 Apr 2002 17:53:15 +0200 (MEST) Subject: Telecom & Mnesia - Call Detail Record Collection In-Reply-To: Message-ID: On Thu, 11 Apr 2002, Ulf Wiger wrote: Uffe> >3. What are the most effective mnesia configurations for maxing Uffe> >out its data storage potential? What is its potential? Uffe> Uffe> I think this is a moving target. If you use fragmented tables, Uffe> the potential for storing large amounts of data in mnesia is Uffe> huge, but it probably doesn't suit all applications. I recall Uffe> that H?kan Mattsson verified linear transaction processing Uffe> scalability of mnesia in a 50 node system. If your application Uffe> allows the database to be partitioned, and accesses can be Uffe> localized to single fragments, it's mostly a question about how Uffe> much hardware you can throw at the solution (well, with a hard Uffe> BEAM limit of 256 nodes). The source code for the benchmark program is included in the Mnesia distribution and is located under mnesia/examples/bench. If you have a big computer farm, please go ahead and set a new highscore! /H?kan From fritchie@REDACTED Thu Apr 11 18:54:38 2002 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 11 Apr 2002 11:54:38 -0500 Subject: Berkeley DB, was Telecom & Mnesia - Call Detail Record Collection In-Reply-To: Message of "Thu, 11 Apr 2002 08:19:12 PDT." Message-ID: <200204111654.g3BGsc811456@snookles.snookles.com> >>>>> "dp" == phillipd writes: dp> It would seem to me that segmenting transactions to Berkeley DB dp> that has several "instances" running on the various nodes would dp> work. [...] Speaking of Berkeley DB... ... In a former life, I had a fair bit of experience dealing with Berkeley DB and it's no-longer-shiny-new transaction mechanisms. One project (rough prototype) was a user-space file system that intercepted all file I/O system calls and stores the "files" in DB tables. The other (which worked surprisingly well) involved writing a wrapper API that looked like a (large) subset of the Berkeley DB API but stored the data in an external ODBC data store instead. Both of those projects have been set aside since that former life became the former life. But I've always been tempted, just for fun, to write an Erlang driver for Berkeley DB. The itch to hack on a hobby project is strong right now. :-) The other itch I've got is to write a driver for Spread, a reliable multicast toolkit. (See http://www.spread.org/ for details.) The database possibilities of Spread + Mnesia or of Berkeley DB + Mnesia or of Berkeley DB + Mnesia + Spread are quite interesting. After all, Spread is already being used with PostgreSQL to build the PostgreSQL, Inc. Replication Server (called eRServer?).... If anyone has any ideas on how I ought to be procrastinating working on home remodelling projects, contact me with your opinion. :-) I can't make any promises about if/when I'd get anything done, but sometimes a person has just got to hack. -Scott From robert.virding@REDACTED Thu Apr 11 21:25:01 2002 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 11 Apr 2002 21:25:01 +0200 Subject: New format/fwrite options Message-ID: <3CB5E30D.8040502@telia.com> OK, I sat down and wrote my own version of binary/hex/based integer output. I prefer to use ~# for based instead of ~B as I think that upper/lower case letters should be about the "same thing". Comments? If Bj?rn sends the man page source I can add some documentation as well. Robert -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: io_lib_format.erl URL: From robert.virding@REDACTED Thu Apr 11 22:17:44 2002 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 11 Apr 2002 22:17:44 +0200 Subject: New format/fwrite options References: <3CB5E30D.8040502@telia.com> Message-ID: <3CB5EF68.800@telia.com> Robert Virding wrote: > OK, I sat down and wrote my own version of binary/hex/based integer > output. I prefer to use ~# for based instead of ~B as I think that > upper/lower case letters should be about the "same thing". Comments? > > If Bj?rn sends the man page source I can add some documentation as well. > > Robert I should have given some examples of course: Eshell V2001.09.13 (abort with ^G) 1> io:fwrite("~#~n", [4711]). %Default is 8 8#11147 ok 2> io:fwrite("~#~n", [-4711]). -8#11147 ok 3> io:fwrite("~.16#~n", [-4711]). -16#1267 ok 4> io:fwrite("~.16#~n", [4711]). 16#1267 ok 5> io:fwrite("~28.16#~n", [4711]). 16#1267 ok 6> io:fwrite("~b~n", [4711]). %Default is 32 bits 00000000000000000001001001100111 ok 7> io:fwrite("~b~n", [-4711]). 11111111111111111110110110011001 ok 8> io:fwrite("~.16b~n", [-4711]). %Default is 32 bits 1110110110011001 ok 9> io:fwrite("~.16b~n", [4711]). 0001001001100111 ok 10> io:fwrite("~.16x~n", [4711]). 1267 ok 11> io:fwrite("~.16x~n", [-4711]). ed99 ok 12> io:fwrite("~x~n", [-4711]). ffffed99 ok 13> io:fwrite("~x~n", [4711]). 00001267 ok I think you get the idea. The only real question I think is if it should be the precision field which gives the number of relevant bits in ~b/x or the field width. It might be bit of an overkill to have both field width and "precision". Comments? Robert From richardc@REDACTED Fri Apr 12 00:03:16 2002 From: richardc@REDACTED (Richard Carlsson) Date: Fri, 12 Apr 2002 00:03:16 +0200 (MET DST) Subject: New format/fwrite options In-Reply-To: <3CB5EF68.800@telia.com> Message-ID: On Thu, 11 Apr 2002, Robert Virding wrote: > Eshell V2001.09.13 (abort with ^G) > 1> io:fwrite("~#~n", [4711]). %Default is 8 > 8#11147 Great. I agree that 8 is a good default. > 6> io:fwrite("~b~n", [4711]). %Default is 32 bits > 00000000000000000001001001100111 > ok > 7> io:fwrite("~b~n", [-4711]). > 11111111111111111110110110011001 Terrific. > I think you get the idea. The only real question I think is if it > should be the precision field which gives the number of relevant > bits in ~b/x or the field width. It might be bit of an overkill to > have both field width and "precision". Comments? Definitely the precision. Field width is a parameter of, well, the field size (duh), while precision is the "rendering" parameter. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From james@REDACTED Fri Apr 12 04:46:36 2002 From: james@REDACTED (James Hague) Date: Thu, 11 Apr 2002 21:46:36 -0500 Subject: Compiler bug Message-ID: <3CB6043C.28669.242301@localhost> I found a compiler bug in R8B-0. Here is the simplest test case I could come up with: -module(compiler_bug). -export([test/1]). test(A) when not is_list(A) -> A. Compiling this with c(compiler_bug) results in: ./compiler_bug.erl:none: internal error in v3_codegen; crash reason: {{case_clause,{'EXIT',{function_clause, [{v3_codegen,fetch_stack,[cor0,[],0]}, {v3_codegen,gen_moves,4}, {v3_codegen,cg_call_args,4}, {v3_codegen,cg_setup_call,4}, {v3_codegen,return_cg,5}, {v3_codegen,cg_basic_block,4}, {v3_codegen,flatmapfoldl,3}, {v3_codegen,cg_basic_block,7}| more]}}}, [{compile,'-select_passes/2-fun-0-',2}, {compile,'-internal_comp/4-fun-1-',2}, {compile,fold_comp,3}, {compile,internal_comp,4}, {compile,internal,3}]} error From Chandrashekhar.Mullaparthi@REDACTED Fri Apr 12 10:23:27 2002 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Fri, 12 Apr 2002 09:23:27 +0100 Subject: resynchronizing mnesia nodes Message-ID: <402DD461F109D411977E0008C791C31205E065D8@imp02mbx.one2one.co.uk> I think when such a thing happens, you can set the master nodes for each table so that when the nodes resync, one of the tables is considered the "correct" one. But I don't think it is possible to merge tables - I'm not sure that it is even desirable. But if it is - then mnesia could invoke a user defined merge fun which would take in as parameters each conflict entry and return a result such as {ok, NewEntry} or discard. For large tables - this can mean that mnesia will take a long time to resync. cheers, Chandru -----Original Message----- From: Hal Snyder [mailto:hal@REDACTED] Sent: 10 April 2002 15:06 To: erlang-questions@REDACTED Subject: resynchronizing mnesia nodes We are looking at various policies for recovering from communication failure with mnesia, and studying Chapter 6 of the Mnesia User's Guide, Version 4.0. Suppose you have several nodes running mnesia, replicating content. They become partitioned long enough to record mutual mnesia_down entries, and continue to receive updates. In some special cases - for example, when updates to a table consist only of adding a positive increment to a counter, or of inserting a record with a globally unique key - it should be possible to resynchronize automatically without fear of inconsistencies. Is this sort of thing readily feasible with mnesia? Is anyone doing it? NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From per@REDACTED Fri Apr 12 12:22:18 2002 From: per@REDACTED (Per Bergqvist) Date: Fri, 12 Apr 2002 11:22:18 +0100 Subject: =?iso-8859-1?q?erl=5Finterface?= compare ... In-Reply-To: <2D2400732F67504EA11CF37BF66D95A808CA7B@svr-wa-e2k1.usa.alliedtelesyn.com> Message-ID: <200204120922.g3C9MIO15284@hyena.levonline.com> Hi, Snip from in beam/utils.c: * According to the Erlang Standard, types are orderered as follows: * numbers < (characters) < atoms < refs < funs < ports < pids < * tuples < [] < conses < binaries. * But in erl_marshal cmp_array for NIL has the lowest value and not between tuples and conses. Bug ? /Per ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From etxmacr@REDACTED Fri Apr 12 11:34:56 2002 From: etxmacr@REDACTED (Mats Cronqvist) Date: Fri, 12 Apr 2002 11:34:56 +0200 Subject: New format/fwrite options Message-ID: <200204120934.g3C9Yui00983@cbe2077.al.sw.ericsson.se> > > On Thu, 11 Apr 2002, Robert Virding wrote: > > > Eshell V2001.09.13 (abort with ^G) > > 1> io:fwrite("~#~n", [4711]). %Default is 8 > > 8#11147 > > Great. I agree that 8 is a good default. > well, although i agree with the "great" part, i can't see what's so good about base 8. i never use it, and don't know anyone who does. i would much prefer base 16 to be the default. mats From Jouni.Ryno@REDACTED Fri Apr 12 11:44:07 2002 From: Jouni.Ryno@REDACTED (Jouni =?ISO-8859-1?Q?Ryn=F6?=) Date: 12 Apr 2002 12:44:07 +0300 Subject: New format/fwrite options In-Reply-To: <3CB5E30D.8040502@telia.com> References: <3CB5E30D.8040502@telia.com> Message-ID: <1018604648.12939.4.camel@adic> On Thu, 2002-04-11 at 22:25, Robert Virding wrote: > OK, I sat down and wrote my own version of binary/hex/based integer > output. I prefer to use ~# for based instead of ~B as I think that > upper/lower case letters should be about the "same thing". Comments? > So will you add upper case X ? > control($x, [A], F, Adj, P, Pad, I) when integer(A) -> > hex_int(A, F, Adj, P, Pad); control($X, ...) was not found ... But otherwise, good! Jouni -- Jouni Ryn? mailto://Jouni.Ryno@REDACTED/ http://www.geo.fmi.fi/~ryno/ Finnish Meteorological Institute http://www.fmi.fi/ Geophysical Research http://www.geo.fmi.fi/ P.O.BOX 503 Tel (+358)-9-19294656 FIN-00101 Helsinki FAX (+358)-9-19294603 Finland priv-GSM (+358)-50-5302903 "It's just zeros and ones, it cannot be hard" From etxhste@REDACTED Fri Apr 12 14:03:08 2002 From: etxhste@REDACTED (Hakan Stenholm) Date: Fri, 12 Apr 2002 14:03:08 +0200 (MET DST) Subject: Compiler bug Message-ID: <200204121203.g3CC39U01106@cbe.ericsson.se> >I found a compiler bug in R8B-0. Here is the simplest test case >I could come up with: > >-module(compiler_bug). >-export([test/1]). > >test(A) when not is_list(A) -> A. This shouldn't work: * you can't use user defined functions (like is_list/1) in a guard, only type checks: atom/1, constant/1 ,float/1, integer/1, list/1, number/1, pid/1, port/1, reference/1, tuple/1, binary/1, record/2 comparision operartors: >,<,=<,>=,==,/=,=:=,=/= and some bifs (together with arithmeteric ops): element/2, float/1, hd/1, length/1, round/1, self/0, size/1, trunc/1, tl/1, abs/1, node/1, node/0, nodes/0 * I'm not sure if "and", "or" and "not" can be used (, and ; can be used in a when statement to get "and" and "or" behaviour). From bjorn@REDACTED Fri Apr 12 14:10:52 2002 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 12 Apr 2002 14:10:52 +0200 Subject: Compiler bug In-Reply-To: Hakan Stenholm's message of "Fri, 12 Apr 2002 14:03:08 +0200 (MET DST)" References: <200204121203.g3CC39U01106@cbe.ericsson.se> Message-ID: The example is legal Erlang code. is_list/1 is a type check (from R8). "and", "or", and "not" are now allowed (from R8). There really is a bug in the compiler. A bug fix will probably be included in the next OS release of R8B. /Bjorn Hakan Stenholm writes: > >I found a compiler bug in R8B-0. Here is the simplest test case > >I could come up with: > > > >-module(compiler_bug). > >-export([test/1]). > > > >test(A) when not is_list(A) -> A. > > This shouldn't work: > * you can't use user defined functions (like is_list/1) in a guard, > only type checks: > atom/1, constant/1 ,float/1, integer/1, list/1, number/1, pid/1, > port/1, reference/1, tuple/1, binary/1, record/2 > > comparision operartors: > >,<,=<,>=,==,/=,=:=,=/= > > and some bifs (together with arithmeteric ops): > element/2, float/1, hd/1, length/1, round/1, self/0, size/1, > trunc/1, tl/1, abs/1, node/1, node/0, nodes/0 > > * I'm not sure if "and", "or" and "not" can be used (, and ; can be used in a > when statement to get "and" and "or" behaviour). > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From etxhste@REDACTED Fri Apr 12 14:41:56 2002 From: etxhste@REDACTED (Hakan Stenholm) Date: Fri, 12 Apr 2002 14:41:56 +0200 (MET DST) Subject: Compiler bug Message-ID: <200204121241.g3CCfuU04210@cbe.ericsson.se> > To: Hakan Stenholm > Cc: erlang-questions@REDACTED, james@REDACTED > Subject: Re: Compiler bug > From: Bjorn Gustavsson > Date: 12 Apr 2002 14:10:52 +0200 > > The example is legal Erlang code. > > is_list/1 is a type check (from R8). "and", "or", and "not" are now allowed > (from R8). Is there a up to date version of the guard expression description ? Page 29-30 (Concurrent programming in erlang 2:nd edtion) lists most typechecks, comparision and bifs allowed. Erlang Extensions Since 4.4 (html docs) mentions the record/2 and function/1 typecheck, but where is is_list/1 and the use of "and", "or", and "not" mentioned ? > > There really is a bug in the compiler. > > A bug fix will probably be included in the next OS release of R8B. > > /Bjorn > > Hakan Stenholm writes: > > > >I found a compiler bug in R8B-0. Here is the simplest test case > > >I could come up with: > > > > > >-module(compiler_bug). > > >-export([test/1]). > > > > > >test(A) when not is_list(A) -> A. > > > > This shouldn't work: > > * you can't use user defined functions (like is_list/1) in a guard, > > only type checks: > > atom/1, constant/1 ,float/1, integer/1, list/1, number/1, pid/1, > > port/1, reference/1, tuple/1, binary/1, record/2 > > > > comparision operartors: > > >,<,=<,>=,==,/=,=:=,=/= > > > > and some bifs (together with arithmeteric ops): > > element/2, float/1, hd/1, length/1, round/1, self/0, size/1, > > trunc/1, tl/1, abs/1, node/1, node/0, nodes/0 > > > > * I'm not sure if "and", "or" and "not" can be used (, and ; can be used in a > > when statement to get "and" and "or" behaviour). > > > > -- > Bj?rn Gustavsson Ericsson Utvecklings AB > bjorn@REDACTED ?T2/UAB/F/P > BOX 1505 > +46 8 727 56 87 125 25 ?lvsj? From thomas.lindgren@REDACTED Fri Apr 12 17:23:09 2002 From: thomas.lindgren@REDACTED (Thomas Lindgren) Date: Fri, 12 Apr 2002 17:23:09 +0200 Subject: Compiler bug In-Reply-To: <200204121241.g3CCfuU04210@cbe.ericsson.se> Message-ID: >Is there a up to date version of the guard expression description ? >Page 29-30 (Concurrent programming in erlang 2:nd edtion) lists most typechecks, >comparision and bifs allowed. >Erlang Extensions Since 4.4 (html docs) mentions the record/2 and function/1 >typecheck, but where is is_list/1 and the use of "and", "or", and "not" >mentioned ? Perhaps it is time to raise the question whether there are getting to be too many similar operations in Erlang as well? For guards, we have comma, semicolon (or), and, or, not. (Could we merge some operations here?) For guard operations, we have type(X) and is_type(X). (Could this be unified into just type(X)?) For expressions, we have and, or, andalso, orelse. (Do people use "E1 and E2" while relying on E2 being evaluated when E1 is false? If not, rename andalso into and, etc.) What do you think? Best, Thomas From cpressey@REDACTED Fri Apr 12 18:24:03 2002 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 12 Apr 2002 11:24:03 -0500 Subject: Compiler bug In-Reply-To: References: <200204121241.g3CCfuU04210@cbe.ericsson.se> Message-ID: <20020412112403.3749208b.cpressey@catseye.mb.ca> On Fri, 12 Apr 2002 17:23:09 +0200 "Thomas Lindgren" wrote: > > >Is there a up to date version of the guard expression description ? > >Page 29-30 (Concurrent programming in erlang 2:nd edtion) lists most > typechecks, > >comparision and bifs allowed. > >Erlang Extensions Since 4.4 (html docs) mentions the record/2 and > function/1 > >typecheck, but where is is_list/1 and the use of "and", "or", and "not" > >mentioned ? > > Perhaps it is time to raise the question whether there > are getting to be too many similar operations in Erlang as well? > > For guards, we have comma, semicolon (or), and, or, not. > (Could we merge some operations here?) > > For guard operations, we have type(X) and is_type(X). > (Could this be unified into just type(X)?) I feel somewhat responsible for this 'improvement' as it appeared shortly after I expressed a desire for the language to be more orthogonal. Doubling the number of guard tests is not my idea of orthogonality, but it's not the only time one of my suggestions has been misinterpreted I think. > For expressions, we have and, or, andalso, orelse. > (Do people use "E1 and E2" while relying on E2 being > evaluated when E1 is false? If not, rename andalso into and, > etc.) > > What do you think? Honestly? - Allow ANY function in guard tests. - Only WARN if the guard test does not operate in constant time. - Deduce which functions operate in constant time by analysis (A function operates in constant time iff all the functions it calls operate in constant time AND it never calls itself or calls a function which calls itself - i.e. no cycles in the recursion graph. This does not seem very difficult to determine.) - Possibly have a module 'type' and place all the type-assertion functions in it (type:number(X), type:list(X), etc) - type:string(X) would be nice (list(X) and 0 =< hd(X) =< 255)) Basically, I see guards as syntactic sugar for case statements. The semantics are almost exactly the same except for the constant time requirement, which has always struck me as overly strict, considering (for example) that a type mismatch is an error (which will be completely ignored by the compiler) while a non-constant-time guard is merely an inefficiency (but which will result in a compiler error just as drastic as a syntax error.) I think it should be a warning only. In some ways, Erlang has always struck me as a bizarre combination of extremely low-level (assembler-like) concepts and extremely high-level (lambda-calculus-like) concepts. While reasoning about performance is of course important in any language for programming soft real-time systems, I am of the opinion that computers are better at reasoning about performance than humans, and thus the onus should be placed more on them, allowing the programmer to write more expressive and easier-to-maintain code. As for short-circuiting, you shouldn't have to think about it in referentially transparent code, and (for me at least) it's fairly rare that I have to think about it in side-effectful code either, so I'm not sure why orelse and andalso were introduced, when two seperate tests in the code is more explicit and possibly clearer. Chris From hal@REDACTED Fri Apr 12 19:37:31 2002 From: hal@REDACTED (Hal Snyder) Date: 12 Apr 2002 12:37:31 -0500 Subject: Compiler bug In-Reply-To: <20020412112403.3749208b.cpressey@catseye.mb.ca> References: <200204121241.g3CCfuU04210@cbe.ericsson.se> <20020412112403.3749208b.cpressey@catseye.mb.ca> Message-ID: <87it6wzulg.fsf@ghidra.vail> Chris Pressey writes: > As for short-circuiting, you shouldn't have to think about it in > referentially transparent code, and (for me at least) it's fairly > rare that I have to think about it in side-effectful code either... Will stick in my oar (warning: bikeshed issue). I'm totally accustomed to short-circuit boolean ops and was somewhat disappointed on seeing Erlang's initial ones not do so. Isn't the biggest win with short-circuit eval that it becomes easier to code two tests, for which the second makes sense only when the first has a certain outcome - for example 1) is x nonzero? 2) something about foo/x. Which reminds me, I wish Erlang had elsif, or cond. Did anything come of http://www.bluetail.com/~rv/Erlang-spec/Proposals/cond.shtml? From cpressey@REDACTED Fri Apr 12 19:45:15 2002 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 12 Apr 2002 12:45:15 -0500 Subject: [d]ets:lookup misbehaves when called during init:start? In-Reply-To: <20020402183917.77a60844.cpressey@catseye.mb.ca> References: <20020330235235.215344cf.cpressey@catseye.mb.ca> <200204010643.g316hfN09809@hyena.levonline.com> <20020402183917.77a60844.cpressey@catseye.mb.ca> Message-ID: <20020412124515.1c4fbfcc.cpressey@catseye.mb.ca> Unhappy to report - this is not a consistent solution :( Sometimes it works; other times, I can call inet_db:start/0, wait for a process with the name inet_db to be registered, and sleep for a whole extra second - and the problem is still there - all calls to gen_tcp:accept/1 immediately return {error, closed}. It is possibly a FreeBSD thing - I'm running 4.5-stable and "stable" can be something of a euphemism in FreeBSDtalk :) So, back to echo 'myapp:start().' | erl, for now... Chris On Tue, 02 Apr 2002 18:39:17 -0600 Chris Pressey wrote: > Thanks! FWIW, erl -run inet_db -run yourapp also seems to work. > > Chris > > On Mon, 01 Apr 2002 08:43:40 +0100 > Per Bergqvist wrote: > > > Hi Chris, > > > > the problem is that the inet_db modules has not yet been started > > and hence the inet_db ets table does not exist (yet). > > It is supposed to be started by the kernel_sup supervisor. > > > > I haven't managed to recreate the problem with R8B-0 under > > Linux but two possible other workarounds are > > a) wait for the inet_db process to become registered. > > b) call inet_db:start from your application (as ftp,httpd and orber > > already does (for the same reason ?)). > > > > /Per > > > > > I have discovered one workaround for this, although it comes at a > > grave > > > cost (namely, the use of the shell) > > > > > > Instead of > > > > > > erl -run module function > > > > > > use > > > > > > echo 'module:function().' | erl > > > > > > Should have been obvious I suppose :) > > > > > > Chris > > > > > > On Fri, 29 Mar 2002 06:27:22 -0600 > > > Chris Pressey wrote: > > > > > > > I'd really like to get to the bottom of this one... > > > > > > > > I have a server that opens a socket. If I start this server from > > the > > > > Erlang shell, everything works smoothly. If I try to start it > > with a > > > > -run command line argument to erl, it does *not* work and I get > > the > > > > following error message upon quitting: > > > > > > > > {error_logger,{{2002,3,29},{6,10,40}},'Error in process > > <0.24481.0> > > > > with exit value: {badarg,[{ets,lookup,[inet_db,tcp_module]}, > > > > {inet_db,db_get,1},{gen_tcp,listen,2},{ce_socket,start,4}]}\n',[]} > > > > > > > > I get the same error if I try to start it from my .erlang file. > > > > > > > > The question is... why? > > > > > > > > I've asked this once before a while ago, but got no response so > > far. > > > > > > > > It seems someone else is (anonymously) getting a very similar > > error > > > > trying to start the wiki in the same way: > > > > > > > > http://www.bluetail.com/wiki/showPage?node=WikiSetup > > > > > > > > {badarg,[{ets,lookup_element,[dets_registry,wikie,3]}, > > > > {dets,lookup,2}, > > > > {wikie,fetch_page,1}, > > > > {erl_eval,expr,3}, > > > > {erl_eval,exprs,4}, > > > > {esp,eval,2}, > > > > {esp,expand,3}, > > > > {esp,do_expand_file,2}, > > > > {esp,handle,1}| > > > > more]} > > > > > > > > Any information on this anomaly (e.g. why it happens and/or how to > > work > > > > around it) would be greatly appreciated (seeing as I *really* > > don't want > > > > to have to start my server from the Erlang shell every time I want > > to > > > > use it :) > > > > > > > > Thanks in advance, > > > > Chris > > > > > ========================================================= > > Per Bergqvist > > Synapse Systems AB > > Phone: +46 709 686 685 > > Email: per@REDACTED From kent@REDACTED Fri Apr 12 19:52:46 2002 From: kent@REDACTED (Kent Boortz) Date: 12 Apr 2002 19:52:46 +0200 Subject: The update R8B-1 is released Message-ID: Bug fix release : otp_src_R8B-1 Build from snapshot : 20020412 This is a bug fix release R8B-1. You can download the full source distribution or the patch that take R8B-0 up to R8B-1. http://www.erlang.org/download/otp_src_R8B-1.tar.gz http://www.erlang.org/download/otp_src_R8B-0to1.patch.gz The bug fixes and improvements in this release is described in the release notes http://www.erlang.org/download/otp_src_R8B-1.readme If you have access to the Ericsson intranet you can find the same files at http://erlang.ericsson.se/opensource/download/ To patch the previos release "otp_src_R8B-0" you use a patch program that understand the "unified" patch format and do % cd otp_src_R8B-X % gzip -dc /location/of/patch/file/otp_src_R8B-0to1.patch.gz | patch -p1 For installation instructions please read the README that is part of the distribution. There is no support for building a Windows version from source. The Windows binary distribution can be downloaded from http://www.erlang.org/download/otp_win32_R8B-1.exe The documentation at http://www.erlang.org will be updated. You can also download the complete HTML documentation or the Unix manual files http://www.erlang.org/download/otp_html_R8B-1.tar.gz http://www.erlang.org/download/otp_man_R8B-1.tar.gz For some OTP applications there are more detailed release notes in the HTML documentation. We also want to thank those that sent us patches, suggestions and bug reports, The OTP Team From jamesh@REDACTED Fri Apr 12 20:56:57 2002 From: jamesh@REDACTED (James Hague) Date: Fri, 12 Apr 2002 13:56:57 -0500 Subject: Compiler bug Message-ID: Chris Pressey wrote: >In some ways, Erlang has always struck me as a bizarre combination of >extremely low-level (assembler-like) concepts and extremely high-level >(lambda-calculus-like) concepts. I don't agree. If you look at how pattern matching works in Haskell and the ML family of languages, it is limited compared to what Erlang offers. You can't repeat a variable, for example: first_two_are_same([X,X|_]) -> true. In general, you have to use classic if..then..else statements more often in these languages, because the pattern matching and guards are _more_ restrictive than in Erlang. In Erlang you can write beautiful code where much of the work is done by the patterns. In other languages with simpler pattern matching this is discouraged, at least in that the compilers aren't designed to optimize that kind of code. If you look at the Core Erlang spec, it's actually similar to what you get out-of-the-box with Haskell and ML. But it takes a good amount of work to compile a legal Erlang program down to the level of Core Erlang! From cpressey@REDACTED Fri Apr 12 22:19:50 2002 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 12 Apr 2002 15:19:50 -0500 Subject: Strengths of Erlang as a declarative language (was Re: Compiler bug) Message-ID: <000801c1e25f$67661b80$9564a8c0@PRESSEY> James Hague wrote: >Chris Pressey wrote: >>In some ways, Erlang has always struck me as a bizarre combination of >>extremely low-level (assembler-like) concepts and extremely high-level >>(lambda-calculus-like) concepts. > >I don't agree. If you look at how pattern matching works in Haskell and the >ML family of languages, it is limited compared to what Erlang offers. You >can't repeat a variable, for example: > >first_two_are_same([X,X|_]) -> true. > >In general, you have to use classic if..then..else statements more often in >these languages, because the pattern matching and guards are _more_ >restrictive than in Erlang. I don't disagree, and I don't think it diminishes my point... perhaps it would have been more appropriate to have said "declarative-logic-(ProLog)-like" instead of ^-c-like. (Except that Erlang is still a far cry from ProLog in that there is no backtracking and there are quite a few more restrictions on source code order... all in all this is not a terrible thing, in fact it's what attracts me to it as a (nearly) general purpose language.) My point being that one of Erlang's strengths is expressivity, so I don't think it should be unnaturally limited by arbitrary restrictions on guard clauses... (that, and evaluation order so strictly following source code order, are what strike me as the lowest-level almost "imperative"-like features of Erlang.) While I'm on the subject of language criticism... more and more I am finding myself disagreeing with the canon law that message passing ought to be encapsulated in function calls. I agree that it ought to be *encapsulated* for the sake of abstraction, but I believe that a function is the wrong thing to encapsulate it in! Functions traditionally do not have side effects. If I have a piece of Erlang code like Z = some_function(X,Y). then I cannot immediately tell if there are side effects involved. There may or may not be, and it might be appropriate to assume that there "shouldn't" be. However, if I have a piece of Erlang code like some_server ! {some_function, self(), [X,Y]}, Z = receive Any -> Any end. then I can *immediately* tell at a glance that there *are* side effects involved, I'm not left wondering and relying on my iffy neural-net memory or hunting through source code. Of course, a good naming convention accomplishes the same goal. Chris From jabba@REDACTED Fri Apr 12 22:30:50 2002 From: jabba@REDACTED (Jani Launonen) Date: Fri, 12 Apr 2002 23:30:50 +0300 (EEST) Subject: Dining philosophers in Erlang Message-ID: Hello, I've been in Formal Methods course and there were presented message passing language that had communications channels that could be both read and written. The dining philosophers -problem could be solved by storing "available" information about chop stick in a channel (that is dining philosopher process could write "available" to the channel and if it weren't consumed by it's neighbour, one could read it back by itself). This is something impossible in Erlang - as one can write only to a another process - so how could one solve the problem in Erlang in most elegant way? I cannot think of solution that doesn't involve having a chop stick process that has only use for responding whether chop stick in question is available or not. Is it possible to not to have chop stick process (and have the required parallelism) in most basic Erlang possible? Could someone more enlightened Erlanger explain this more elegant solution, please? Cheers, -+-+-+- Jani Launonen Student. . . . . . . . . .University of Oulu, Dept. of EE Assistant Researcher . . .Genie of the Net Project "Computing is a field which has one of the shortest collective memories of any engineering or scientific discipline." - Marty Fouts, comp.distributed From robert.virding@REDACTED Sat Apr 13 10:26:37 2002 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 13 Apr 2002 10:26:37 +0200 Subject: New format/fwrite options References: <3CB5E30D.8040502@telia.com> <3CB5EF68.800@telia.com> Message-ID: <00d301c1e2c4$f1360040$2100a8c0@virding.org> I have lost the original message but someone was wondering about ~X. I suppose I could manage that. How about a ~B with uppercase 1/0? Robert From per@REDACTED Sun Apr 14 04:15:16 2002 From: per@REDACTED (Per Bergqvist) Date: Sun, 14 Apr 2002 03:15:16 +0100 Subject: The update R8B-1 is released In-Reply-To: Message-ID: <200204140115.g3E1FVI27263@raven.levonline.com> Attached is small patch to make it build properly under RedHat 7.2. In addtion to corrections the patch fix support for current (i.e. 0.9.4 and later) openssl releases. (Nobody should use releases older than 0.9.6 anyway). Apply with patch -p0 from $ERL_TOP. There are still some warnings in erl_sl_alloc.c. beam/erl_sl_alloc.c:2077: warning: operation on `list' may be undefined beam/erl_sl_alloc.c:2078: warning: operation on `list' may be undefined beam/erl_sl_alloc.c:2079: warning: operation on `list' may be undefined . . . Is there any way to avoid those warnings ? /Per > > Bug fix release : otp_src_R8B-1 > Build from snapshot : 20020412 > > This is a bug fix release R8B-1. You can download the full source > distribution or the patch that take R8B-0 up to R8B-1. > > http://www.erlang.org/download/otp_src_R8B-1.tar.gz > http://www.erlang.org/download/otp_src_R8B-0to1.patch.gz > > The bug fixes and improvements in this release is described in the > release notes > > http://www.erlang.org/download/otp_src_R8B-1.readme > > If you have access to the Ericsson intranet you can find the same files at > > http://erlang.ericsson.se/opensource/download/ > > To patch the previos release "otp_src_R8B-0" you use a patch program > that understand the "unified" patch format and do > > % cd otp_src_R8B-X > % gzip -dc /location/of/patch/file/otp_src_R8B-0to1.patch.gz | patch -p1 > > For installation instructions please read the README that is part of > the distribution. > > There is no support for building a Windows version from source. > The Windows binary distribution can be downloaded from > > http://www.erlang.org/download/otp_win32_R8B-1.exe > > The documentation at http://www.erlang.org will be updated. You can > also download the complete HTML documentation or the Unix manual files > > http://www.erlang.org/download/otp_html_R8B-1.tar.gz > http://www.erlang.org/download/otp_man_R8B-1.tar.gz > > For some OTP applications there are more detailed release notes in the > HTML documentation. > > We also want to thank those that sent us patches, suggestions and bug > reports, > > The OTP Team > ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: R8B-1.patch Type: application/octet-stream Size: 3013 bytes Desc: not available URL: From per@REDACTED Sun Apr 14 04:46:07 2002 From: per@REDACTED (Per Bergqvist) Date: Sun, 14 Apr 2002 03:46:07 +0100 Subject: =?iso-8859-1?q?erl=5Fsl=5Falloc?= warnings... In-Reply-To: <200204140115.g3E1FVI27263@raven.levonline.com> Message-ID: <200204140146.g3E1k7907404@hunden.levonline.com> > > Is there any way to avoid those warnings ? > > /Per > Yes, and here is the patch. (The reason is that ADD_3TUP do the assignment of 'list' ...) patch -p0 from $ERL_TOP. /Per -------------- next part -------------- A non-text attachment was scrubbed... Name: R8B-1.patch2 Type: application/octet-stream Size: 370 bytes Desc: not available URL: From vances@REDACTED Sun Apr 14 04:17:48 2002 From: vances@REDACTED (Vance Shipley) Date: Sat, 13 Apr 2002 22:17:48 -0400 Subject: FreeBSD port Message-ID: <20020413221748.K615@mobility.motivity.ca> I notice that the FreeBSD ports collection was recently updated with R8B-0. I'm sure that the maintainer will be updating that to R8B-1 soon. In the mean time here's what I did to update the port: 1) update the Makefile for the new version: 9c9 < PORTVERSION= 8.1 --- > PORTVERSION= 8.0 15c15 < DISTNAME= otp_src_R8B-1 --- > DISTNAME= otp_src_R8B-0 40c40 < ERLANG_MAN= otp_man_R8B-1.tar.gz --- > ERLANG_MAN= otp_man_R8B-0.tar.gz 42c42 < ERLANG_DOCS= otp_html_R8B-1.tar.gz --- > ERLANG_DOCS= otp_html_R8B-0.tar.gz 2) Install the R8B-1 distribution files in /usr/ports/distfiles/erlang. 3) Upadate the MD5 signatures in /usr/ports/lang/erlang/distinfo with `make distinfo`. 4) Remove the following patches: /usr/ports/lang/erlang/files/patch-ab /usr/ports/lang/erlang/files/patch-ak /usr/ports/lang/erlang/files/patch-am /usr/ports/lang/erlang/files/patch-ao /usr/ports/lang/erlang/files/patch-aq 5) make install -Vance -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED From fritchie@REDACTED Sun Apr 14 22:23:49 2002 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Sun, 14 Apr 2002 15:23:49 -0500 Subject: Bug in R8B-1 (and -0) using set_port_control_flags() in driver? Message-ID: <200204142023.g3EKNn822507@snookles.snookles.com> Please pardon me for this abbreviated bug (?) report and lack of fix. On a lark, I tried adding a call to set_port_control_flags(port, PORT_CONTROL_FLAG_BINARY) in my test driver's "start" function. Without the set_port_control_flags() call in "start", I get a list of 3 bytes. With the call to set_port_control_flags(), I get a bogus binary of random size instead. Erlang (BEAM) emulator version 5.1.1 [source] [threads:5] Eshell V5.1.1 (abort with ^G) 1> P1 = foodrv:open(). #Port<0.29> 2> X = foodrv:do_control(P1, 2,0). <<64,7,29,8,0,0,0,0,72,0,0,0,24,180,55,8,200,239,191,191,20,180,55,8,212,239,191,191,213,...>> 3> size(X). 3214020608 4> q(). ok FWIW, here's what do_control() looks like: do_control(Port, Sec, MSec) -> case erlang:port_control(Port, ?AS_CMD_ASLEEP, <>) of <<0:8, Tag:16>> -> % FIXME Const for OK status receive {Port, Tag, M} -> M end; XXX -> XXX end. If I leave out the set_port_control_flags() and use this instead, it works fine. do_control(Port, Sec, MSec) -> case erlang:port_control(Port, ?AS_CMD_ASLEEP, <>) of [0, Tag1, Tag2] -> % FIXME Const for OK status Tag = (Tag1 bsl 8) bor Tag2, receive {Port, Tag, M} -> M end; XXX -> XXX end. I'll just avoid using set_port_control_flags() for now. -Scott From vances@REDACTED Sun Apr 14 23:27:16 2002 From: vances@REDACTED (Vance Shipley) Date: Sun, 14 Apr 2002 17:27:16 -0400 Subject: patch to eliminate otp/hipe GNU m4 dependency Message-ID: <20020414172716.A57952@mobility.motivity.ca> In Message-ID: <15308.15549.142584.146486@REDACTED> Mikael Pettersson writes: } } Since so many have been trapped by this .. Here's a patch to eliminate } the dependency on GNU m4 when building OTP R8 with --enable-hipe. } } I'm CC:ing the patch to erlang-questions in case the OTP folks don't have } time to put this into R8 before the real release. } } /Mikael This change isn't in R8B-1 either. :( Applying the patch allows HIPE to build on FreeBSD. http://www.erlang.org/ml-archive/erlang-questions/200110/threads.html -Vance -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED From richardc@REDACTED Mon Apr 15 16:23:34 2002 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 15 Apr 2002 16:23:34 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: <000801c1e25f$67661b80$9564a8c0@PRESSEY> Message-ID: Hi everybody! I'll try to give some answers to the questions asked in the latest Erlang language debate. (This got rather long; be warned.) Following the "Compiler bug?" confusion, Thomas Lindgren asked: > Perhaps it is time to raise the question whether there are > getting to be too many similar operations in Erlang as well? > > For guard operations, we have type(X) and is_type(X). (Could > this be unified into just type(X)?) Originally, the only builtin type tests were on the form "integer(X)" etc., and these could only be accessed in guards which effectively have a separate name space, so you could not write: Bool = integer(X) anywhere outside a guard. Indeed, you cannot even use them at the "guard expression" level, only the "guard test" top level, so the following clause is not accepted: X when integer(X) == true -> ... because integer(X) is not a "guard BIF", only a "guard test". To further complicate things, "float(X)", is also defined as a BIF - even as a guard BIF, with completely different semantics (int-to-float typecast). Assume that B contains a boolean value. Then, in the following clause: X when B == float(X) -> float(X) does not refer to the type test, but to the typecast function. To make things more uniform, all guard tests were given new alternative names "is_...(X)", which are also proper BIFs/guard BIFs, and may thus be used anywhere, both as guard tests and in normal code. Like most BIFs, they belong to the 'erlang' module, The old type tests must of course remain for backwards compatibility, but they are now being renamed to the "is_" forms very early in the compilation. Back to Thomas: > For guards, we have comma, semicolon (or), and, or, not. > (Could we merge some operations here?) This is still work in progress, more or less. Robert Virding extended the guard syntax to allow 'and' for comma and 'or' for semicolon, as well as allowing these operators in guard expressions. 'not' should also be allowed on all levels. It seems that there still is some bug in the implementation, however. Here too, the reason for the extension is to make guards more like other expressions. A complication is that failure in the first argument of a top-level guard 'or' (semicolon) goes on to try the other alternative as if there were two clauses, while at the expression-level the whole 'or'-operation fails immediately. > For expressions, we have and, or, andalso, orelse. (Do people > use "E1 and E2" while relying on E2 being evaluated when E1 is > false? If not, rename andalso into and, etc.) For some reason, the original and/or were defined to evaluate both arguments. Personally, I would love to give and/or the semantics of andalso/orelse, but previous experience suggests that any semantic changes in Erlang, however obscure, are politically impossible. Could this be an exception to the rule? Chris Pressey wrote: - Allow ANY function in guard tests. - Only WARN if the guard test does not operate in constant time. - Deduce which functions operate in constant time by analysis The main problem with allowing any function in guards is not really the time (after all, length/1 is allowed), but the side effects (such as sending messages or updating ETS tables). The assumption when a guard fails is that the state of the world did not change. Also, guards are used in 'receive': sending a message from a guard expression in a receive-clause, or evaluating a receive within a receive, could cause major inconsistencies (it would be very hard to specify what the semantics actually should be, if this was allowed). Analysing an expression to tell whether it is side effect free is not that hard, but note that even a call to another module is a potential side effect (the module might even not be loaded yet). So for user-defined functions, only local calls could be allowed. Now, guards should be efficiently implemented: even if not always taking constant time, the overhead should be small, so a full backtracking mechanism like in Prolog is out of the question. The current Beam implementation relies quite heavily on being able to generate special code for guards, where many things can be assumed: - no side effects can happen - exceptions only cause a jump to a "failure" label - all calls are to builtins; special calling conventions can be used. - any created data is not live outside the guard - (possibly other things...) To put it briefly: allowing more general expressions in guards is definitely something one would like to do, but it needs a lot of work to make it both safe and efficient. Chris also suggested: > - Possibly have a module 'type' and place all the type-assertion > functions in it (type:number(X), type:list(X), etc) Structured module namespaces are just making their way into the language, so you may see something like "erl.lang.term:is_list(X)" in the future. > As for short-circuiting, you shouldn't have to think about it in > referentially transparent code, and (for me at least) it's > fairly rare that I have to think about it in side-effectful code > either, so I'm not sure why orelse and andalso were introduced, > when two seperate tests in the code is more explicit and > possibly clearer. Of course, if the compiler can decide that the RHS of an 'and' is ref. transparent *and* type-safe (i.e., can't cause an exception), it can generate short-circuit code. But this is often not possible (outside guards). Using andalso/orelse let you express that you know what you are doing. Having two separate tests is not clearer. Compare e.g.: is_string([X | Xs]) -> is_char(X) andalso is_string(Xs); is_string([]) -> true. to: is_string([X | Xs]) -> case is_char(X) of true -> is_string(X); false -> false end. is_string([]) -> true. With the explicit test, you have to make sure you get the true/false cases right (which gets error prone if there is more than one level) when writing it, and furthermore, someone reading your code must ask him/herself "what does this (nested) switch here really implement?" Chris also wrote: > more and more I am finding myself disagreeing with the canon law > that message passing ought to be encapsulated in function calls. > I agree that it ought to be *encapsulated* for the sake of > abstraction, but I believe that a function is the wrong thing to > encapsulate it in! Functions traditionally do not have side > effects. If I have a piece of Erlang code like > > Z = some_function(X,Y). > > then I cannot immediately tell if there are side effects > involved. [...] However, if I have a piece of Erlang code like > > some_server ! {some_function, self(), [X,Y]}, > Z = receive > Any -> Any > end. > > then I can *immediately* tell at a glance that there *are* side > effects involved, I agree: there should (in a better world) be another kind of abstraction for this purpose. The real issue is not that the send/receive are explicit in the code - because they often ought to be - but that they expose the data structures used in the message passing (or to be specific, the 'receive' does). A way to handle this would be to have abstract patterns (O'Keefe 1998), but from what I have heard, implementing this idea in an efficient way turned out to be a lot more difficult than expected. Hal Snyder asked: > Which reminds me, I wish Erlang had elsif, or cond. Did anything > come of http://www.bluetail.com/~rv/Erlang-spec/Proposals/cond.shtml? This is on its way. In preparation, 'cond' was made a reserved word in R8, along with 'try'. (Adding a new keyword is a fairly large language change, so people should be duly warned.) I hope that about covers it. Thank you for your time. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From L.A.Timochouk@REDACTED Tue Apr 16 00:37:58 2002 From: L.A.Timochouk@REDACTED (Leonid Timochouk) Date: Mon, 15 Apr 2002 23:37:58 +0100 (BST) Subject: Problems with starting/stopping applications Message-ID: Hello Erlang users, In Erlang/OTP R8B on Linux, I have noticed the following two problems: (1) It is NOT possible to start applications by using the "-s" or "-run" command-line parameters in "erl", like erl -pa some_path -s application start my_application_name permanent The "-s" or "-run" parameters simply have no effect, as confirmed by using the "-init_debug" option. On the other hand, invoking application:start (my_application_name, permanent) from the Erlang shell starts an application without any problems. (2) Similarly, calling init:stop () from the Erlang shell shuts down all applications and then terminates the "beam" emulator, as it should be. But if the same function is invoked from within some working process, it only shuts down all applications but does not terminate "beam" itself. Anyone has an idea why this can happen (especially (1))? Thanks a lot in advance, Dr Leonid Timochouk Computing Laboratory University of Kent at Canterbury, England From maurice@REDACTED Tue Apr 16 00:57:13 2002 From: maurice@REDACTED (Maurice Castro) Date: Tue, 16 Apr 2002 08:57:13 +1000 (EST) Subject: Erlang language issues In-Reply-To: from Richard Carlsson at "Apr 15, 2002 04:23:34 pm" Message-ID: <200204152257.g3FMvD802485@parallel.serc.rmit.edu.au> Richard Carlsson (richardc@REDACTED) wrote: > > For some reason, the original and/or were defined to evaluate both > arguments. Personally, I would love to give and/or the semantics > of andalso/orelse, but previous experience suggests that any > semantic changes in Erlang, however obscure, are politically > impossible. Could this be an exception to the rule? > In languages that have to work in real time, the passing of time is a side effect. Short circuit logic evaluation makes the evaluation time of a function less consistent and hence can be undesirable. Maurice Castro From vances@REDACTED Tue Apr 16 01:47:57 2002 From: vances@REDACTED (Vance Shipley) Date: Mon, 15 Apr 2002 19:47:57 -0400 Subject: Problems with starting/stopping applications In-Reply-To: ; from L.A.Timochouk@ukc.ac.uk on Mon, Apr 15, 2002 at 11:37:58PM +0100 References: Message-ID: <20020415194757.D60177@mobility.motivity.ca> On Mon, Apr 15, 2002 at 11:37:58PM +0100, Leonid Timochouk wrote: } Hello Erlang users, } } In Erlang/OTP R8B on Linux, I have noticed the following two problems: } } (1) It is NOT possible to start applications by using the "-s" } or "-run" command-line parameters in "erl", like The problem would appear to be with starting "applications" and not that -run is broken. I do see that when I try to start an application it doesn't work: $ erl -run application start sasl Erlang (BEAM) emulator version 5.1.1 [source] Eshell V5.1.1 (abort with ^G) 1> application:which_applications(). [{stdlib,"ERTS CXC 138 10","1.10.1"},{kernel,"ERTS CXC 138 10","2.7.2"}] The SASL application doesn't show up in the list. Did this work in previous releases? } (2) Similarly, calling } } init:stop () } } from the Erlang shell shuts down all applications and then terminates } the "beam" emulator, as it should be. But if the same function is } invoked from within some working process, it only shuts down all } applications but does not terminate "beam" itself. This works though: $ erl -run init stop Erlang (BEAM) emulator version 5.1.1 [source] Eshell V5.1.1 (abort with ^G) 1> $ :) -Vance -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED From kent@REDACTED Tue Apr 16 02:19:07 2002 From: kent@REDACTED (Kent Boortz) Date: 16 Apr 2002 02:19:07 +0200 Subject: Problems with starting/stopping applications In-Reply-To: Vance Shipley's message of "Mon, 15 Apr 2002 19:47:57 -0400" References: <20020415194757.D60177@mobility.motivity.ca> Message-ID: Vance Shipley writes: > $ erl -run application start sasl > Erlang (BEAM) emulator version 5.1.1 [source] > > Eshell V5.1.1 (abort with ^G) > 1> application:which_applications(). > [{stdlib,"ERTS CXC 138 10","1.10.1"},{kernel,"ERTS CXC 138 10","2.7.2"}] > > The SASL application doesn't show up in the list. Did this work in > previous releases? No it did not. And I think the call at the command line with -run and -s is the same as application:start(["sasl"]) application:start([sasl]) that is supposed to fail. We just don't see the error beause the call doesn't raise an exception, it just returns the value {error,{bad_application,[hej]}}. Maybe it should raise an exception when the argument isn't an atom. This is all guesses, I haven't looked close at this, kent From cpressey@REDACTED Tue Apr 16 07:37:29 2002 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 16 Apr 2002 00:37:29 -0500 Subject: Erlang language issues In-Reply-To: References: <000801c1e25f$67661b80$9564a8c0@PRESSEY> Message-ID: <20020416003729.7d4fee69.cpressey@catseye.mb.ca> Sorry that this is an equally long (actually, longer!) response to a long message... it's a topic that is of great interest to me :) On Mon, 15 Apr 2002 16:23:34 +0200 (MET DST) Richard Carlsson wrote: > For some reason, the original and/or were defined to evaluate both > arguments. Personally, I would love to give and/or the semantics > of andalso/orelse, but previous experience suggests that any > semantic changes in Erlang, however obscure, are politically > impossible. Could this be an exception to the rule? With any production language, retaining backwards-compatibility is important, some might even say crucial. Languages are never designed 100% correctly the first time of course, such an expectation would be unrealistic. But once an imperfect language is in use, it has to stay imperfect... one might say that it experiences 'language pollution' after a time. Things like erlang:hash/1, the lib module, the orddict module, the assumption that ports are synonymous with named pipes, etc, are all deprecated and in theory will disappear someday - but in practice, it seems likely they won't, because they can't without breaking someone's old code somewhere. It's somewhat akin to archaic words in spoken language. Very few people use the word 'wherefore' in conversation these days, but if you don't know the word 'wherefore', you can't enjoy Shakespeare! On the other hand, if all you want to do is enjoy Shakespeare, you don't need to know the word 'microwave'... Back in terms of programming languages - sometimes the pressure from language pollution encourages people to design a fresh new language which discards the 'mistakes' of the old language while retaining all the things it got 'right'. Java, over C++, might be an example of that. I doubt that there is enough pressure currently to completely redesign and migrate to a "Rational Erlang", but one could also say that it's only a matter of time. (That's kind of a rhetorical excuse, though.) > Chris Pressey wrote: > > - Allow ANY function in guard tests. > - Only WARN if the guard test does not operate in constant time. > - Deduce which functions operate in constant time by analysis > > The main problem with allowing any function in guards is not > really the time (after all, length/1 is allowed), Well, this is beside the point, and splitting hairs too, but is it written in stone that length/1 must operate in O(n) time? The length of a list - as well as its tail pointer - could be cached for quick retrieval, and this could make some list operations quicker (at the cost of other operations) Whether this would be 'breaking backwards-compatibility' or not is a tough question, though. Generally I'd say no, but for Erlang, being very sensitive to execution performance, I might make an exception. > but the side > effects (such as sending messages or updating ETS tables). The > assumption when a guard fails is that the state of the world did > not change. Very true. Side-effects in a guard would be very bad programming practice - usually a dire mistake, and when not, then certainly an awkward and objectionable coding style. But, Erlang treats this almost as a syntactic rule, rather than a semantic one - the syntax of a guard expression disallows side-effects. This seems a bit strict - very understandable, considering the origins of the language, but a bit strict nonetheless. Reformulating it as a semantic rule would be a bit nicer, in my mind. > Also, guards are used in 'receive': sending a message > from a guard expression in a receive-clause, or evaluating a > receive within a receive, could cause major inconsistencies (it > would be very hard to specify what the semantics actually should > be, if this was allowed). Absolutely. Again, my only problem with it is that the restrictions are more syntax-based than semantics-based. On a related note, is there a good reason for 'receive' to be a language structure, rather than a BIF? For example, instead of receive {foo, X} -> bar(X); {baz, Y} -> quuz(Y) end couldn't one say, with identical intent, Msg = receive(), case Msg of {foo, X} -> bar(X); {baz, Y} -> quuz(Y) end Is the reason that it's a language structure, that the compiler can more easily generate better code (something like Linda?) > Analysing an expression to tell whether it is side effect free is > not that hard, but note that even a call to another module is a > potential side effect (the module might even not be loaded yet). > So for user-defined functions, only local calls could be allowed. And that diminishes its usefulness - as it would be desirable to put user-defined guards in a common, reusable module - but I can see why, given the ability to update code while it's running. I'm tempted to see module loading as a special case of side-effect, though. It should only happen once for each time the code is updated, which would not be a common occurance. > Now, guards should be efficiently implemented: even if not always > taking constant time, the overhead should be small, so a full > backtracking mechanism like in Prolog is out of the question. The > current Beam implementation relies quite heavily on being able to > generate special code for guards, where many things can be > assumed: > > - no side effects can happen > - exceptions only cause a jump to a "failure" label > - all calls are to builtins; special calling conventions > can be used. > - any created data is not live outside the guard > - (possibly other things...) > > To put it briefly: allowing more general expressions in guards is > definitely something one would like to do, but it needs a lot of > work to make it both safe and efficient. I see... I tend to see the most elegant path to achieving this, to be rigorous analysis and optimization on the compiler's part. But this definately has drawbacks, not the least of which is the complexity of the compiler, and long compile times. > Chris also suggested: > > > - Possibly have a module 'type' and place all the type-assertion > > functions in it (type:number(X), type:list(X), etc) > > Structured module namespaces are just making their way into the > language, so you may see something like "erl.lang.term:is_list(X)" > in the future. Oddly, I've never been too concerned that Erlang has such a 'flat' namespace structure. I think a deep heirarchy would be even worse. Unless perhaps there was some sort of 'search path'-like mechanism for resolving names. > > As for short-circuiting, you shouldn't have to think about it in > > referentially transparent code, and (for me at least) it's > > fairly rare that I have to think about it in side-effectful code > > either, so I'm not sure why orelse and andalso were introduced, > > when two seperate tests in the code is more explicit and > > possibly clearer. > > Of course, if the compiler can decide that the RHS of an 'and' is > ref. transparent *and* type-safe (i.e., can't cause an exception), > it can generate short-circuit code. But this is often not possible > (outside guards). Using andalso/orelse let you express that you > know what you are doing. > > Having two separate tests is not clearer. Compare e.g.: > > is_string([X | Xs]) -> > is_char(X) andalso is_string(Xs); > is_string([]) -> > true. > to: > is_string([X | Xs]) -> > case is_char(X) of > true -> > is_string(X); > false -> > false > end. > is_string([]) -> true. > > With the explicit test, you have to make sure you get the > true/false cases right (which gets error prone if there is more > than one level) when writing it, and furthermore, someone reading > your code must ask him/herself "what does this (nested) switch > here really implement?" Perhaps this is a strange way to approach it, but it seems to me that Erlang's evalutation-order-closely-follows-source-code-order feature could be exploited to write a fairly clear, non-nested version of this as: is_string([X | Xs]) when not is_char(X) -> false; is_string([X | Xs]) when not is_string(Xs) -> false; is_string(X) when is_list(X) -> true. On the topic of type-safeness... I am somewhat confounded by the fact that all errors are treated equally. This may be somewhat difficult to explain, but I don't feel that a type error and (e.g.) a file-not-found error are of the same gravity. What I am doing more and more often in my code is writing 'wrapper' functions around BIF's that throw errors. One example of this is list_to_integer/1. Often I'm in a position where I want to convert a string to an integer, even if it isn't a legal integer. I ended up writing a function like: my_list_to_integer(List, Default) -> case catch list_to_integer(List) of X when is_integer(X) -> X; _ -> Default end. Some might say that this comes from ingrained habit of working with languages with bad error-handling capabilities, and that may be true. But then again, string:str/2 doesn't throw an error when the substring is not found, so... is it really 'wrong'? (Also it would be more consistent for the indexes in GS stuff to be 1-based, not 0-based, but that is really digressing from the point...) > > Chris also wrote: > > > more and more I am finding myself disagreeing with the canon law > > that message passing ought to be encapsulated in function calls. > > I agree that it ought to be *encapsulated* for the sake of > > abstraction, but I believe that a function is the wrong thing to > > encapsulate it in! Functions traditionally do not have side > > effects. If I have a piece of Erlang code like > > > > Z = some_function(X,Y). > > > > then I cannot immediately tell if there are side effects > > involved. [...] However, if I have a piece of Erlang code like > > > > some_server ! {some_function, self(), [X,Y]}, > > Z = receive > > Any -> Any > > end. > > > > then I can *immediately* tell at a glance that there *are* side > > effects involved, > > I agree: there should (in a better world) be another kind of > abstraction for this purpose. One such thing I thought of - not particularly elegant - is a 'relay process', a process whose entire purpose is simply to pass any messages it receives, to another process - possibly translating them while in transit. The translation provides a place for the abstraction to happen. But this seems, at the very least, somewhat wasteful. > The real issue is not that the > send/receive are explicit in the code - because they often ought > to be - but that they expose the data structures used in the > message passing (or to be specific, the 'receive' does). A way to > handle this would be to have abstract patterns (O'Keefe 1998), but > from what I have heard, implementing this idea in an efficient way > turned out to be a lot more difficult than expected. It might not be necessary to go that far (but abstract patterns might clear up a lot of other issues as well) - I think mainly it's a matter of breaking the habit of thinking in terms of what is being sent as data. Or 'raw' data, if you like. A function can be thought of in terms of 'raw' data - it is an atom or two, for the module and function name, and a list of terms, for the arguments. But we don't generally think of it this way, for reasons of abstraction (although we DO think of it this way when using spawn/3, but never mind that! :) If messages could be thought of as similarly consistently 'packaged' data, that might help matters a bit, without going all the way into abstract patterns. Considering spawn/3, and the syntax used in ets:match, I would say that Erlang is a bit weak when it comes to reflectivity - being able to describe Erlang code in Erlang. Ideally the syntax for spawn'ed functions would closely match that of non-spawn'ed functions, and the syntax for ets:match'ing would closely resemble that for regular case ... of ... end matching. Abstract patterns seem to hold a comprehensive, if somewhat drastic (overkill) solution, to all these things, and more (like macros.) My, I do tend to ramble on, don't I? Sorry about that :) Chris From robert.virding@REDACTED Tue Apr 16 08:46:42 2002 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 16 Apr 2002 08:46:42 +0200 Subject: Bug methinks :-) References: Message-ID: <3CBBC8D2.4060100@telia.com> Joe Armstrong wrote: > Here's bug.erl > > -module(bug). > > -compile(export_all). > > -define(Entry(X, Y), (Y:X)). > > -define(DWORD, 32/unsigned-little-integer). > -define(WORD, 16/unsigned-little-integer). > > foo(B) -> > < ?Entry(?DWORD, SectionAlignment), > ?Entry(?DWORD, FileAlignment), > ?Entry(?WORD, MajorOperatingSystemVersion)>> = B. You are actually hitting two different things here: 1. Seeing you have put parantheses around the bit expression it is parsed as an expression not as a bit expression with extra optional fields. 2. A mis-feature in the parser which allows to get past parsing and be caught in the linter. So if you expand your macros (look in bug.P) you will see: (ImageBase:32/unsigned-little-integer) and : / - are parsed as normal operators. Without the paratheses is is parsed as you expect. That : is parsed as an operator is the mis-feature. So this is not a bug, and there is no real way around it as we need to be able to have paranthesised expressions in bit expressions. Otherwise the syntax would be extremely restricted, basically just variables which would really suck. I will however fix up the : as operator bug!. Robert From thomas.lindgren@REDACTED Tue Apr 16 11:14:50 2002 From: thomas.lindgren@REDACTED (Thomas Lindgren) Date: Tue, 16 Apr 2002 11:14:50 +0200 Subject: Erlang language issues In-Reply-To: Message-ID: Lots of issues here, hope I got them all :-) [new and old type tests] >The old type tests must of course remain for backwards >compatibility, but they are now being renamed to the "is_" forms >very early in the compilation. I think my basic question is whether one can rename guard tests into the new operations directly. This way, one could get rid of having both type(X) and is_type(X). It would seem to be possible for most cases, perhaps excepting the dual mode of float(X) that you mention, or any similar cases. (Though looking at the context, it should be possible to deduce what version is intended: off the top of my head, on the toplevel one uses is_float(X), inside arithmetic one uses to_float(X) or whatever the operation may be called. Any questionable cases are flagged with a warning.) > /.../ the reason for the extension is to make guards more like > other expressions. A complication is that failure in the first > argument of a top-level guard 'or' (semicolon) goes on to try the > other alternative as if there were two clauses, while at the > expression-level the whole 'or'-operation fails immediately. I think making guards behave like expressions is a Good Thing, generally speaking, because it is more convenient to have full boolean expressions. As you say, the problem is nailing down the details. I suppose the behaviours above should be unified. If nothing else, for the sanity of programmers :-) [boolean expressions] >For some reason, the original and/or were defined to evaluate both >arguments. Personally, I would love to give and/or the semantics >of andalso/orelse, but previous experience suggests that any >semantic changes in Erlang, however obscure, are politically >impossible. Could this be an exception to the rule? One might hope so, if only for the reason that most people might think 'and' really works like 'andalso'. And that is why I asked the question: do you people out there really want 'and' to evaluate both arguments? (Personally, I tend to curse the fact that it does :-) [deep guards] >The main problem with allowing any function in guards is not >really the time (after all, length/1 is allowed), but the side >effects (such as sending messages or updating ETS tables). The >assumption when a guard fails is that the state of the world did >not change. Also, guards are used in 'receive': sending a message >from a guard expression in a receive-clause, or evaluating a >receive within a receive, could cause major inconsistencies (it >would be very hard to specify what the semantics actually should >be, if this was allowed). To handle this, I once proposed that execution would be in 'normal mode' or 'guard mode'. The latter would trigger an un-catchable exception (i.e., fail) when a side-effect was attempted. That way, remote calls still work. (The originating guard would catch the failure.) (Roughly speaking, you would only switch out of guard mode when you exit the guard that set the computation into guard mode.) I'm a bit ambivalent about permitting "deep guards", however. What do we define as a side-effect, for instance? _Reading_ the database? Permitting long-running guards means we must be able to context-switch inside the guard, which means the database can change while we run the guard, which might be construed as an impurity. (And what about read locks?) And so on. I believe the original restriction on guards comes from concurrent logic programming, where "deep guards" had severe problems and ultimately led to disallowing them. Well, the Real World intrudes so I have to leave off here. Basically, I'd like to reduce the number of constructs when their meanings are very close. And yes, legacy code is a problem. -- Thomas From vances@REDACTED Tue Apr 16 12:48:27 2002 From: vances@REDACTED (Vance Shipley) Date: Tue, 16 Apr 2002 06:48:27 -0400 Subject: extending standard behaviours Message-ID: <20020416064827.A60903@mobility.motivity.ca> What would be the best way to extend standard behaviours? For example I have created a module using the gen_fsm behaviour which implements a state machine. There are a number of different versions of this, with different numbers of states. The mandatory callbacks are common between all versions (e.g. handle_event, handle_info, init, etc.). -Vance -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED From thomas@REDACTED Tue Apr 16 13:59:22 2002 From: thomas@REDACTED (Thomas Arts) Date: Tue, 16 Apr 2002 13:59:22 +0200 Subject: Dining philosophers in Erlang References: Message-ID: <3CBC121A.7BE4C307@cslab.ericsson.se> Hello Jani As you know, Erlang has no notion of channels. However, you could model Erlang's communication to any process, by NxN channels. I don't believe that that is a nice solution, but surely possible. I hope I understand your question right, but as far as I can see, you could use either synchronous communication with time-out (like in the gen_server) orelse change the protocol to the complement and react on a message if you are idle, hence if you don't react, you assume that the philosopher is busy. Good luck with your exercise Thomas Jani Launonen wrote: > > Hello, > > I've been in Formal Methods course and there were presented message passing > language that had communications channels that could be both read and > written. The dining philosophers -problem could be solved by storing > "available" information about chop stick in a channel (that is dining > philosopher process could write "available" to the channel and if it > weren't consumed by it's neighbour, one could read it back by itself). This > is something impossible in Erlang - as one can write only to a another > process - so how could one solve the problem in Erlang in most elegant way? > I cannot think of solution that doesn't involve having a chop stick process > that has only use for responding whether chop stick in question is > available or not. Is it possible to not to have chop stick process (and > have the required parallelism) in most basic Erlang possible? Could someone > more enlightened Erlanger explain this more elegant solution, please? > > Cheers, > > -+-+-+- > Jani Launonen > Student. . . . . . . . . .University of Oulu, Dept. of EE > Assistant Researcher . . .Genie of the Net Project > > "Computing is a field which has one of the shortest collective memories > of any engineering or scientific discipline." - Marty Fouts, comp.distributed From cpressey@REDACTED Tue Apr 16 18:33:00 2002 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 16 Apr 2002 11:33:00 -0500 Subject: extending standard behaviours In-Reply-To: <20020416064827.A60903@mobility.motivity.ca> References: <20020416064827.A60903@mobility.motivity.ca> Message-ID: <20020416113300.2e1656b9.cpressey@catseye.mb.ca> On Tue, 16 Apr 2002 06:48:27 -0400 Vance Shipley wrote: > > What would be the best way to extend standard behaviours? > My initial feeling would be: create another behaviour. Writing a module which conforms to a behaviour, is a case of the 'specialization' pattern. There's nothing saying that this module can't be, itself, a behaviour as well, and offhand that sounds like what you have, here. > For example I have created a module using the gen_fsm > behaviour which implements a state machine. There are a > number of different versions of this, with different numbers > of states. The mandatory callbacks are common between all > versions (e.g. handle_event, handle_info, init, etc.). > > -Vance > > -- > Vance Shipley > Motivity Telecom Inc. > +1 519 579 5816 > vances@REDACTED Chris From vances@REDACTED Tue Apr 16 19:51:26 2002 From: vances@REDACTED (Vance Shipley) Date: Tue, 16 Apr 2002 13:51:26 -0400 Subject: extending standard behaviours In-Reply-To: <20020416113300.2e1656b9.cpressey@catseye.mb.ca>; from cpressey@catseye.mb.ca on Tue, Apr 16, 2002 at 11:33:00AM -0500 References: <20020416064827.A60903@mobility.motivity.ca> <20020416113300.2e1656b9.cpressey@catseye.mb.ca> Message-ID: <20020416135126.B60903@mobility.motivity.ca> On Tue, Apr 16, 2002 at 11:33:00AM -0500, Chris Pressey wrote: } Vance Shipley wrote: } } > What would be the best way to extend standard behaviours? } } My initial feeling would be: create another behaviour. This would amount to copying the entire gen_fsm.erl module to my_gen_fsm.erl and adding in a few lines of code. This seems pretty ugly to me. I have been using the include directive to source in a common module with the call back functions: -module(fxs_fsm). -behaviour(gen_fsm). -include("template_fsm.erl"). I have not seen any examples of including a .erl file anywhere as as such assume some will find this bad style. I'm not too sure I like it either. -Vance From Sean.Hinde@REDACTED Tue Apr 16 20:03:46 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 16 Apr 2002 19:03:46 +0100 Subject: extending standard behaviours Message-ID: <402DD461F109D411977E0008C791C312039F6A07@imp02mbx.one2one.co.uk> > This would amount to copying the entire gen_fsm.erl module to > my_gen_fsm.erl and adding in a few lines of code. This seems > pretty ugly to me. I had this problem some time ago. I wanted to add state aware timers to the gen_fsm behaviour (i.e timers which on expiry called the current state function with a timeout parameter rather than appearing en mass in handle_info). The only solution I could come up with was exactly this - my own gen_fsm_timer.erl. I proposed my changes as an addition to the standard gen_fsm at the time, this being the only route available which avoided my having to re-patch new versions of gen_fsm in the future. It was rejected by popular vote it seems :( I fear we are straying a bit close into OO land here, but perhaps there is something useful to steal from those guys?? Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From jamesh@REDACTED Tue Apr 16 20:20:58 2002 From: jamesh@REDACTED (James Hague) Date: Tue, 16 Apr 2002 13:20:58 -0500 Subject: Erlang language issues Message-ID: >On a related note, is there a good reason for 'receive' to be a language >structure, rather than a BIF? For example, instead of > > receive > {foo, X} -> bar(X); > {baz, Y} -> quuz(Y) > end > >couldn't one say, with identical intent, > > Msg = receive(), > case Msg of > {foo, X} -> bar(X); > {baz, Y} -> quuz(Y) > end Ah, but they're not the same! In the second case you're always pulling a message out of the mailbox. In the first case, if the message doesn't match one of the patterns, then it remains in the mailbox. I think this is an interesting discussion, one which I unwittingly started :). But I suspect that if you wrote down a comprehensive list of the polluted parts of Erlang (and not just pet peeves about the language design), it would be a fairly short list. It might be longer if you include all of OTP in that list, so junk like the crypto module could get a mention. This would be a good document to have, I think. From cpressey@REDACTED Tue Apr 16 22:33:04 2002 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 16 Apr 2002 15:33:04 -0500 Subject: extending standard behaviours Message-ID: <001201c1e585$e95d4720$9564a8c0@PRESSEY> Vance Shipley wrote: >On Tue, Apr 16, 2002 at 11:33:00AM -0500, Chris Pressey wrote: >} Vance Shipley wrote: >} >} > What would be the best way to extend standard behaviours? >} >} My initial feeling would be: create another behaviour. > >This would amount to copying the entire gen_fsm.erl module to >my_gen_fsm.erl and adding in a few lines of code. This seems >pretty ugly to me. No copying involved - either you misunderstood me, or I misstated. Your behaviour extension would look something like: -module(my_fsm). -behaviour(gen_fsm). -export( # same as gen_fsm # ). # your functions, which are wrappers on top of those in gen_fsm # And then, any modules which you wish to conform to your extended behaviour would look like: -module(a_specific_fsm). -behaviour(my_fsm). # whatever # Chris From cpressey@REDACTED Tue Apr 16 22:56:16 2002 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 16 Apr 2002 15:56:16 -0500 Subject: Erlang language issues Message-ID: <003901c1e589$270b0b40$9564a8c0@PRESSEY> James Hague wrote: >>On a related note, is there a good reason for 'receive' to be a language >>structure, rather than a BIF? For example, instead of >> >> receive >> {foo, X} -> bar(X); >> {baz, Y} -> quuz(Y) >> end >> >>couldn't one say, with identical intent, >> >> Msg = receive(), >> case Msg of >> {foo, X} -> bar(X); >> {baz, Y} -> quuz(Y) >> end > >Ah, but they're not the same! In the second case you're always pulling a >message out of the mailbox. In the first case, if the message doesn't match >one of the patterns, then it remains in the mailbox. Good point. A more accurate analogy would be Msg = receive(), case Msg of {foo, X} -> bar(X); {baz, Y} -> quuz(Y); _ -> putback(Msg) end And at that point, it's hard to see how this is any better than the built-in receive language structure. In fact it's arguably worse, as it's quite easy to forget to put the message back... >I think this is an interesting discussion, one which I unwittingly started >:). But I suspect that if you wrote down a comprehensive list of the >polluted parts of Erlang (and not just pet peeves about the language >design), it would be a fairly short list. It might be longer if you include >all of OTP in that list, so junk like the crypto module could get a mention. >This would be a good document to have, I think. Very true - most of the 'cruft' is in OTP. Chris From luke@REDACTED Tue Apr 16 23:12:55 2002 From: luke@REDACTED (Luke Gorrie) Date: 16 Apr 2002 23:12:55 +0200 Subject: Erlang language issues In-Reply-To: <003901c1e589$270b0b40$9564a8c0@PRESSEY> References: <003901c1e589$270b0b40$9564a8c0@PRESSEY> Message-ID: "Chris Pressey" writes: > >Ah, but they're not the same! In the second case you're always pulling a > >message out of the mailbox. In the first case, if the message doesn't > match > >one of the patterns, then it remains in the mailbox. > > Good point. A more accurate analogy would be > > Msg = receive(), > case Msg of > {foo, X} -> bar(X); > {baz, Y} -> quuz(Y); > _ -> putback(Msg) > end > > And at that point, it's hard to see how this is any better than the built-in > receive language structure. In fact it's arguably worse, as it's quite easy > to forget to put the message back... It needs to do more still - receive scans the whole queue for a message that matches the pattern, and if it finds one then removes only it. If there isn't a match it has to block until new message(s) are received, and then scan those with the same patterns. And do timeouts :-) Cheers, Luke From cpressey@REDACTED Tue Apr 16 23:13:36 2002 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 16 Apr 2002 16:13:36 -0500 Subject: extending standard behaviours Message-ID: <003e01c1e58b$9309ea80$9564a8c0@PRESSEY> Sean Hinde wrote: >I fear we are straying a bit close into OO land here, but perhaps there is >something useful to steal from those guys?? It's called the 'specialization' relationship, and they stole it from *us*, split it in two, and renamed it 'inheritance' and 'instantiation' :) Seriously, though... subclassing, and implementing a behaviour ('behaving'?), are the same idea (design pattern) in two different realms. Fido 'IS-A' dog, which 'IS-A' animal. my_specific_fsm_timer 'IS-A' gen_fsm_timer, which 'IS-A' gen_fsm. I wish I could explain this better, but I guess it's so intuitive to me that it's difficult to put into words. Basically I don't see much difference, maybe no real difference at all, between an Erlang behaviour and a Java interface. The difference is that the behaviour is specified in terms of callback functions instead of properties of an object, but this is (to me) such a small distinction as to be easily dismissed, since functions can do the work of object properties and/or methods. Chris From cpressey@REDACTED Tue Apr 16 23:42:43 2002 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 16 Apr 2002 16:42:43 -0500 Subject: Mnesia data partitioning question Message-ID: <004401c1e58f$a4c459a0$9564a8c0@PRESSEY> Although I don't really expect a concrete answer to this one, I thought it might be interesting to share opinions on the subject... Mnesia lacks the concept of a 'secondary key' - that is, using more than one field to uniquely identify a record. So, is it, generally speaking, wiser to model a many-to-many relationship in Mnesia as: - a 'set' table with a compound key, or - a 'bag' table with an index on a second field? Perhaps I should give some background. I am currently using Erlang outside of telecom - in a retail setting - for an order-tracking application. I chose Erlang partly because the problem is inherently distributed and soft real-time - users in different physical locations want immediate updates on the status of orders. Erlang makes this easy - the shipping department manages a database, and all the other nodes simply subscribe to Mnesia events, and update their displays accordingly. Orders go out in shipments. If orders are small, more than one order may be placed in the same shipment. If an order is large, it may be split across more than one shipment. So there is a many-many relationship between shipments and orders, and the key in the main table is order_id+shipment_id. I've currently implemented this as a compound key, i.e. a 'set' table where the key is a tuple {order_id, shipment_id}. Unfortunately, I need indexes on the order_id and shipment_id fields individually, for other purposes, so they are repeated in the record - wasting space. I see that I could be using a 'bag' table instead, and this would save me space in the database, as I would not need to repeat the indexed fields. However, space is not a crucial issue (there will probably be at the very most 1000 records in the database at any given time, and each record is fairly small), and the drawback with the bag seems to be that it does not ensure that order_id+shipment_id is unique for any given record. There could be two records with the same order_id and the same shipment_id. I honestly doubt that either way to do it would be a 'mistake', but I would be interested to hear if anyone wanted to share similar experiences in Mnesia table design. Thanks! Chris From cpressey@REDACTED Wed Apr 17 00:40:09 2002 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 16 Apr 2002 17:40:09 -0500 Subject: Erlang language issues In-Reply-To: References: <003901c1e589$270b0b40$9564a8c0@PRESSEY> Message-ID: <20020416174009.5363788e.cpressey@catseye.mb.ca> On 16 Apr 2002 23:12:55 +0200 Luke Gorrie wrote: > "Chris Pressey" writes: > > > >Ah, but they're not the same! In the second case you're always > > >pulling a message out of the mailbox. In the first case, if the > > >message doesn't match > > >one of the patterns, then it remains in the mailbox. > > > > Good point. A more accurate analogy would be > > > > Msg = receive(), > > case Msg of > > {foo, X} -> bar(X); > > {baz, Y} -> quuz(Y); > > _ -> putback(Msg) > > end > > > > And at that point, it's hard to see how this is any better than the > > built-in receive language structure. In fact it's arguably worse, as > > it's quite easy to forget to put the message back... > > It needs to do more still - receive scans the whole queue for a > message that matches the pattern, and if it finds one then removes > only it. If there isn't a match it has to block until new message(s) > are received, and then scan those with the same patterns. > > And do timeouts :-) > > Cheers, > Luke OK - then it's easy to see why it's a language feature. Guess I should've figured that out myself... :) Chris From vances@REDACTED Wed Apr 17 02:31:29 2002 From: vances@REDACTED (Vance Shipley) Date: Tue, 16 Apr 2002 20:31:29 -0400 Subject: extending standard behaviours In-Reply-To: <001201c1e585$e95d4720$9564a8c0@PRESSEY>; from cpressey@catseye.mb.ca on Tue, Apr 16, 2002 at 03:33:04PM -0500 References: <001201c1e585$e95d4720$9564a8c0@PRESSEY> Message-ID: <20020416203129.F60903@mobility.motivity.ca> OK, I see how to do this now. My new behaviour module will look like a user to the gen_fsm behaviour and so it exports the call backs that gen_fsm expects. It will look like a behaviour to it's users so we export the same but possibly extended interface as gen_fsm to our users. I put this together and it seems to work brilliantly. This gives me exactly what I wanted which is to be able to write generic handlers in one place and handle the specifics in the individual state hanlder modules. For instance when we terminate the fxs_fsm module's terminate/3 function will do it's own clean up (hang up a call in a signaling specific way) and then call the cha_fsm terminate function to do the common clean up tasks (write to a log). Messages received by fxs_fsm which are not understood by it are forwarded on to chan_fsm which handles them in a generic way. Thanks Chris! -Vance ----------------------------------------------------------------------------- -module(chan_fsm). -behaviour(gen_fsm). % export the gen_fsm interface -export([start/3, start/4, start_link/3, start_link/4, send_event/2, sync_send_event/2, sync_send_event/3, send_all_state_event/2, sync_send_all_state_event/2, sync_send_all_state_event/3, reply/2]). % behaviour modules must export this function -export([behaviour_info/1]). % export the gen_fsm call backs -export([init/1, handle_event/3, handle_sync_event/4, handle_info/3, terminate/3, code_change/4]). %% %% define what call backs users must export %% behaviour_info(callbacks) -> % we add our own requirements to those of gen_fsm [{idle, 2},{busy, 2}] ++ gen_fsm:behaviour_info(callbacks); behaviour_info(Other) -> gen_fsm:behaviour_info(Other). %% %% pass through functions to gen_fsm %% start(Mod, Args, Options) -> gen_fsm:start(Mod, Args, Options). start(Name, Mod, Args, Options) -> gen_fsm:start(Name, Mod, Args, Options). start_link(Mod, Args, Options) -> gen_fsm:start_link(Mod, Args, Options). start_link(Name, Mod, Args, Options) -> gen_fsm:start_link(Mod, Args, Options). send_event(Name, Event) -> gen_fsm:send_event(Name, Event). sync_send_event(Name, Event) -> gen_fsm:sync_send_event(Name, Event). sync_send_event(Name, Event, Timeout) -> gen_fsm:sync_send_event(Name, Event). send_all_state_event(Name, Event) -> gen_fsm:send_all_state_event(Name, Event). sync_send_all_state_event(Name, Event) -> gen_fsm:sync_send_all_state_event(Name, Event). sync_send_all_state_event(Name, Event, Timeout) -> gen_fsm:sync_send_all_state_event(Name, Event, Timeout). reply(Caller, Reply) -> gen_fsm:reply(Caller, Reply). %% %% call backs %% init(Args) -> process_flag(trap_exit, true), io:fwrite("chan_fsm: OK, let's play!~n"), {ok, idle, []}. handle_event(Event, StateName, StateData) -> io:fwrite("chan_fsm: Thank you for the ~w event.~n", [Event]), {next_state, StateName, StateData}. handle_sync_event(Event, From, StateName, StateData) -> io:fwrite("chan_fsm: I don't handle sync events!~n"), {reply, ignore, StateName, StateData}. handle_info(Event, State, StateData) -> io:fwrite("chan_fsm: Please use chan_fsm:send_event/2 to talk to me!~n"), {next_state, State, StateData}. terminate(Reason, State, StateData) -> io:fwrite("chan_fsm: It's been fun. Bye.~n"). code_change(OldVersion, State, Data, Extra) -> io:fwrite("chan_fsm: Nothing to do here.~n"), {ok, State, Data}. ----------------------------------------------------------------------------- -module(fxs_fsm). -behaviour(chan_fsm). % export the states -export([idle/2, busy/2]). % export the gen_fsm call backs -export([init/1, handle_event/3, handle_sync_event/4, handle_info/3, terminate/3, code_change/4]). %% %% states %% idle(Event, StateData) -> io:fwrite("The fxs state machine got ~w in ~w~n", [Event, idle]), {next_state, busy, StateData}. busy(Event, StateData) -> io:fwrite("The fxs state machine got ~w in ~w~n", [Event, busy]), {next_state, idle, StateData}. %% %% call backs %% init(Args) -> chan_fsm:init(Args). handle_event(Event, StateName, StateData) -> chan_fsm:handle_event(Event, StateName, StateData). handle_sync_event(Event, From, StateName, StateData) -> chan_fsm:handle_sync_event(Event, From, StateName, StateData). handle_info(foo, State, StateData) -> io:fwrite("The fxs state machine accepts your foo event~n"), {next_state, State, StateData}; handle_info(bar, State, StateData) -> io:fwrite("The fxs state machine accepts your bar event~n"), {next_state, State, StateData}; handle_info(Event, State, StateData) -> chan_fsm:handle_info(Event, State, StateData). terminate(Reason, State, StateData) -> io:fwrite("Here I would do any fxs specific clean up.~n"), chan_fsm:terminate(Reason, State, StateData). code_change(OldVersion, State, Data, Extra) -> io:fwrite("Here I would do any fxs specific code change tasks.~n"), chan_fsm:code_change(OldVersion, State, Data, Extra). From vlad_dumitrescu@REDACTED Wed Apr 17 06:25:06 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 17 Apr 2002 06:25:06 +0200 Subject: Erlang language issues Message-ID: Hi, Since the language itself is an issue right now, I will pop up a question about that, even if not really related to the rest of the thread. Would a "block comment" concept be wrong for Erlang? Difficult to implement? The reason why I need it is that I would like to be able to embed Erlang code within a HTML page using the same trick that JavaScript uses, namely the HTML is commented out for the JS parser and the JS code is commented out for the HTML parser. I don't see a way to do it with only the % comments.... regards, Vlad _________________________________________________________________ MSN Photos ?r det enklaste s?ttet att dela ut och skriva ut foton: http://photos.msn.se/Support/WorldWide.aspx From fredrik.linder@REDACTED Wed Apr 17 08:48:48 2002 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Wed, 17 Apr 2002 08:48:48 +0200 Subject: Erlang language issues References: Message-ID: <001501c1e5dc$093f6540$f6b7f2d5@frelin> > Thomas Lindgren: > [new and old type tests] > >The old type tests must of course remain for backwards > >compatibility, but they are now being renamed to the "is_" forms > >very early in the compilation. > > I think my basic question is whether one can rename guard tests > into the new operations directly. This way, one could get rid > of having both type(X) and is_type(X). It would seem to be possible > for most cases, perhaps excepting the dual mode of float(X) that > you mention, or any similar cases. > > (Though looking at the context, it should be possible to deduce > what version is intended: off the top of my head, on the toplevel > one uses is_float(X), inside arithmetic one uses to_float(X) or > whatever the operation may be called. Any questionable cases are > flagged with a warning.) > > > /.../ the reason for the extension is to make guards more like > > other expressions. A complication is that failure in the first > > argument of a top-level guard 'or' (semicolon) goes on to try the > > other alternative as if there were two clauses, while at the > > expression-level the whole 'or'-operation fails immediately. > > I think making guards behave like expressions is a Good Thing, > generally speaking, because it is more convenient to have full > boolean expressions. As you say, the problem is nailing down the details. > > I suppose the behaviours above should be unified. If nothing else, for > the sanity of programmers :-) I have always thought of Erlang as a make-it-easy-for-the-programmer type of language, especially with respect to understandability and ease-of-use; only one or two ways of doing the same thing, clear language constructs etc. But lately I find that Erlang is drifting away from that, my thought, with things like: andalso, the MatchSpec used in ets/mnesia, etc. Please do not misinterpret my intension here, some or most of these changes are very useful; it is the syntax of them that concerns me. For instance, I cannot see why 'and', 'or' and 'not' could not be allowed in guards. This syntax change(?) could still coexists with (;.), and have the same rules applied to them. With 'and' as syntactic sugar for ',', 'or' as syntactic sugar for ';' and 'not' as suntactic sugar for 'false == ' (or something) and possibly warning if (;,) is used, would I as a programmer only have one boolean syntax to use. > Thomas Lindgren: > [boolean expressions] > >For some reason, the original and/or were defined to evaluate both > >arguments. Personally, I would love to give and/or the semantics > >of andalso/orelse, but previous experience suggests that any > >semantic changes in Erlang, however obscure, are politically > >impossible. Could this be an exception to the rule? > > One might hope so, if only for the reason that most people might > think 'and' really works like 'andalso'. And that is why I > asked the question: do you people out there really want 'and' to evaluate > both arguments? No > Thomas Lindgren: > (Personally, I tend to curse the fact that it does :-) > > [deep guards] > >The main problem with allowing any function in guards is not > >really the time (after all, length/1 is allowed), but the side > >effects (such as sending messages or updating ETS tables). The > >assumption when a guard fails is that the state of the world did > >not change. Also, guards are used in 'receive': sending a message > >from a guard expression in a receive-clause, or evaluating a > >receive within a receive, could cause major inconsistencies (it > >would be very hard to specify what the semantics actually should > >be, if this was allowed). > > To handle this, I once proposed that execution would be in 'normal mode' or > 'guard mode'. The latter would trigger an un-catchable exception > (i.e., fail) when a side-effect was attempted. That way, remote > calls still work. (The originating guard would catch the failure.) > > (Roughly speaking, you would only switch out of guard mode when you > exit the guard that set the computation into guard mode.) > > I'm a bit ambivalent about permitting "deep guards", however. > > What do we define as a side-effect, for instance? _Reading_ the database? > Permitting long-running guards means we must be able to context-switch > inside the guard, which means the database can change while we run the > guard, which might be construed as an impurity. (And what about read locks?) > And so on. > > I believe the original restriction on guards comes from concurrent logic > programming, where "deep guards" had severe problems and ultimately > led to disallowing them. > > Well, the Real World intrudes so I have to leave off here. Basically, > I'd like to reduce the number of constructs when their meanings are > very close. And yes, legacy code is a problem. Could one way to go be to add a 'guard' construct for writing guard-functions, that only may use other guard-functions? guard my_guard(Arg1, Arg2) -> true | false. Maybe with the extension of considering the guard construct as a catch - to guard from exceptions? Also maybe to consider all guards to belong to the same module 'guard', but allow new guards to be defined in other modules (these should then be updated when re-loading the original module): -module(x). -guards([my_guard/2]). guard:my_guard(Arg1, Arg2) -> true | false. From raimo@REDACTED Wed Apr 17 08:53:47 2002 From: raimo@REDACTED (Raimo Niskanen) Date: Wed, 17 Apr 2002 08:53:47 +0200 Subject: Erlang language issues References: <003901c1e589$270b0b40$9564a8c0@PRESSEY>, Message-ID: <3CBD1BFB.B4CECFA7@erix.ericsson.se> Luke Gorrie wrote: > > "Chris Pressey" writes: > > > >Ah, but they're not the same! In the second case you're always pulling a > > >message out of the mailbox. In the first case, if the message doesn't > > match > > >one of the patterns, then it remains in the mailbox. > > > > Good point. A more accurate analogy would be > > > > Msg = receive(), > > case Msg of > > {foo, X} -> bar(X); > > {baz, Y} -> quuz(Y); > > _ -> putback(Msg) > > end > > > > And at that point, it's hard to see how this is any better than the built-in > > receive language structure. In fact it's arguably worse, as it's quite easy > > to forget to put the message back... > > It needs to do more still - receive scans the whole queue for a > message that matches the pattern, and if it finds one then removes > only it. If there isn't a match it has to block until new message(s) > are received, and then scan those with the same patterns. And as an optimisation - receive scans only the new messages when they arrive, since the old messages are already known to not match. And also - the putback() thing would disturb the order of received messages for subsequent receive()s / Raimo Niskanen > > And do timeouts :-) > > Cheers, > Luke From Chandrashekhar.Mullaparthi@REDACTED Wed Apr 17 10:29:33 2002 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Wed, 17 Apr 2002 09:29:33 +0100 Subject: Mnesia data partitioning question Message-ID: <402DD461F109D411977E0008C791C31205E06606@imp02mbx.one2one.co.uk> Since you say that space is not an issue - you could generate a unique integer index for every order_id+shipment_id combination and make the generated index the primary key and the order_id and shipment_id as secondary indices. Space will still be wasted - but a little less. cheers, Chandru -----Original Message----- From: Chris Pressey [mailto:cpressey@REDACTED] Sent: 16 April 2002 22:43 To: erlang-questions@REDACTED Subject: Mnesia data partitioning question Although I don't really expect a concrete answer to this one, I thought it might be interesting to share opinions on the subject... Mnesia lacks the concept of a 'secondary key' - that is, using more than one field to uniquely identify a record. So, is it, generally speaking, wiser to model a many-to-many relationship in Mnesia as: - a 'set' table with a compound key, or - a 'bag' table with an index on a second field? Perhaps I should give some background. I am currently using Erlang outside of telecom - in a retail setting - for an order-tracking application. I chose Erlang partly because the problem is inherently distributed and soft real-time - users in different physical locations want immediate updates on the status of orders. Erlang makes this easy - the shipping department manages a database, and all the other nodes simply subscribe to Mnesia events, and update their displays accordingly. Orders go out in shipments. If orders are small, more than one order may be placed in the same shipment. If an order is large, it may be split across more than one shipment. So there is a many-many relationship between shipments and orders, and the key in the main table is order_id+shipment_id. I've currently implemented this as a compound key, i.e. a 'set' table where the key is a tuple {order_id, shipment_id}. Unfortunately, I need indexes on the order_id and shipment_id fields individually, for other purposes, so they are repeated in the record - wasting space. NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From klacke@REDACTED Wed Apr 17 11:27:10 2002 From: klacke@REDACTED (Klacke) Date: Wed, 17 Apr 2002 11:27:10 +0200 Subject: what's happend to hyber.org? In-Reply-To: <200204090951.g399pdC20631@duna273.eth.ericsson.se>; from Laszlo.Varga@eth.ericsson.se on Tue, Apr 09, 2002 at 11:51:39AM +0200 References: <200204090951.g399pdC20631@duna273.eth.ericsson.se> Message-ID: <20020417112710.C4479@bluetail.com> On Tue, Apr 09, 2002 at 11:51:39AM +0200, Laszlo Varga wrote: > Hi, > is there anybody knows something about yaws.hyber.org? > Works for me :-) Haven't had much time to hack on it lateley, but i've started to to basic Authenticate: support Latest release is still 0.33 /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From Laszlo.Varga@REDACTED Wed Apr 17 11:45:57 2002 From: Laszlo.Varga@REDACTED (Laszlo Varga) Date: Wed, 17 Apr 2002 11:45:57 +0200 (MEST) Subject: generated file names Message-ID: <200204170945.g3H9jvC23844@duna273.eth.ericsson.se> Hi, I'm facing to a problem which is rather interesting than hard. I 'm going to generate a big variety (>10^8) of files, with (almost) unique names. (Files can be deleted after use.) Different files should have different names, but the same content can be stored under different names. One technique may be using some seed information that defines the file's content in the file name. In my case this is possible, but I'd prefer something more 'cryptic'. The other way I can see is including an on-the-fly generated unique string into the file name. For example erlang:ref_to_list(make_ref()). It is unique enough, but not really 'cryptic' again, and moreover ref_to_list is something condemned dirty. Other suggestions? Thanks laszlo mailto:ethvala@REDACTED From richardc@REDACTED Wed Apr 17 11:56:44 2002 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 17 Apr 2002 11:56:44 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: Message-ID: On Wed, 17 Apr 2002, Vlad Dumitrescu wrote: > Would a "block comment" concept be wrong for Erlang? Difficult to > implement? Not difficult to implement; just a question of deciding on the delimiters. Joe Armstrong also proposed this, mainly to make it easier to write edoc documentation, and it has been agreed that block comments should be added to the language, probably for the next release. (Should have told you this before, Vlad - sorry.) After some initial attempts at inventing new delimiters, all of which had subtle problems, we came to the conclusion that the normal C comment delimiters /* ... */ were probably the best choice. Flames, anybody? /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From eleberg@REDACTED Wed Apr 17 12:04:42 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Wed, 17 Apr 2002 12:04:42 +0200 (MET DST) Subject: Erlang language issues Message-ID: <200204171004.g3HA4gU19070@cbe.ericsson.se> > X-Authentication-Warning: meg.it.uu.se: richardc owned process doing -bs > Date: Wed, 17 Apr 2002 11:56:44 +0200 (MET DST) > From: Richard Carlsson > After some initial attempts at inventing new delimiters, all of which > had subtle problems, we came to the conclusion that the normal C comment > delimiters /* ... */ were probably the best choice. will they nest? (unlike c) bengt From joe@REDACTED Wed Apr 17 12:10:58 2002 From: joe@REDACTED (Joe Armstrong) Date: Wed, 17 Apr 2002 12:10:58 +0200 (CEST) Subject: Erlang language issues In-Reply-To: Message-ID: > Hi, > > Since the language itself is an issue right now, I will pop up a question > about that, even if not really related to the rest of the thread. > > Would a "block comment" concept be wrong for Erlang? no > Difficult to implement? no This is also needed for edoc'd files to look nice - > > The reason why I need it is that I would like to be able to embed Erlang > code within a HTML page using the same trick that JavaScript uses, namely > the HTML is commented out for the JS parser and the JS code is commented out > for the HTML parser. I don't see a way to do it with only the % comments.... > Yes :-) > regards, > Vlad /Joe From etxuwig@REDACTED Wed Apr 17 12:11:37 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 17 Apr 2002 12:11:37 +0200 (MET DST) Subject: Mnesia data partitioning question In-Reply-To: <004401c1e58f$a4c459a0$9564a8c0@PRESSEY> Message-ID: On Tue, 16 Apr 2002, Chris Pressey wrote: >Although I don't really expect a concrete answer to this one, I >thought it might be interesting to share opinions on the >subject... > >Mnesia lacks the concept of a 'secondary key' - that is, using >more than one field to uniquely identify a record. So, is it, >generally speaking, wiser to model a many-to-many relationship >in Mnesia as: > >- a 'set' table with a compound key, or >- a 'bag' table with an index on a second field? I would go for a 'set' table with a compound key. I wonder if you've looked at the support for relational constraints in the 'rdbms' contrib? It offers support for things like cascading delete and "insertion constraints" (e.g. the secondary key must identify an existing record in a given table.) If you find it lacking in certain respects, I'd be happy to hear what you feel would need to be added/changed. /Uffe From etxuwig@REDACTED Wed Apr 17 12:23:59 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 17 Apr 2002 12:23:59 +0200 (MET DST) Subject: generated file names In-Reply-To: <200204170945.g3H9jvC23844@duna273.eth.ericsson.se> Message-ID: On Wed, 17 Apr 2002, Laszlo Varga wrote: >For example > erlang:ref_to_list(make_ref()). >It is unique enough, but not really 'cryptic' again, and >moreover ref_to_list is something condemned dirty. Well, the following should be more unique than the above, and not use any constructs that are officially frowned upon: unique_name() -> {Ms,S,Us} = erlang:now(), lists:append([integer_to_list(Ms), ".", integer_to_list(S), ".", integer_to_list(Us)]). If you want it more cryptic, you can call erlang:md5(list_to_binary(unique_name()), which will make it less unique, but not by much. But to make it a valid filename, you'd have to do encode it as (ascii) hex representation or something. (: /Uffe From richardc@REDACTED Wed Apr 17 12:25:18 2002 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 17 Apr 2002 12:25:18 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: <200204171004.g3HA4gU19070@cbe.ericsson.se> Message-ID: On Wed, 17 Apr 2002, Bengt Kleberg wrote: > > After some initial attempts at inventing new delimiters, all of which > > had subtle problems, we came to the conclusion that the normal C comment > > delimiters /* ... */ were probably the best choice. > > will they nest? (unlike c) Yes. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From klacke@REDACTED Wed Apr 17 13:28:00 2002 From: klacke@REDACTED (Klacke) Date: Wed, 17 Apr 2002 13:28:00 +0200 Subject: Berkeley DB, was Telecom & Mnesia - Call Detail Record Collection In-Reply-To: <200204111654.g3BGsc811456@snookles.snookles.com>; from fritchie@snookles.com on Thu, Apr 11, 2002 at 11:54:38AM -0500 References: <200204111654.g3BGsc811456@snookles.snookles.com> Message-ID: <20020417132800.D4479@bluetail.com> On Thu, Apr 11, 2002 at 11:54:38AM -0500, Scott Lystig Fritchie wrote: > >>>>> "dp" == phillipd writes: > > dp> It would seem to me that segmenting transactions to Berkeley DB > dp> that has several "instances" running on the various nodes would > dp> work. [...] > > Speaking of Berkeley DB... > I looked a lot at the berkeley db a couple of years ago, the one thing that made me stop workin on it was that I was never able to figure out how to repair a broken berkely db file. Writing into the berkely db updates the metadata for the file in way where there are certain points in time where the file is broken.... That's at least how I recall it. Great db package though ....... and fast /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From eleberg@REDACTED Wed Apr 17 13:57:16 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Wed, 17 Apr 2002 13:57:16 +0200 (MET DST) Subject: Erlang language issues Message-ID: <200204171157.g3HBvGU28382@cbe.ericsson.se> > Date: Tue, 16 Apr 2002 00:37:29 -0500 > From: Chris Pressey > With any production language, retaining backwards-compatibility is > important, some might even say crucial. perhaps we should at this point seperate 1 binary backwards-compatibility 2 source backwards-compatibility i think case 2 could still allow evolution. compiler for release X has a feature. compiler X+1 warns about this features soon to be demise, and suggest a replacement. compiler X+2 stops with error. case 1 does not allow such an evolution. but sometimes (yap => beam) there is a clean break, and one is allowed to evolve things by case 2. ...deleted > But, Erlang treats this almost as a syntactic rule, rather than a semantic > one - the syntax of a guard expression disallows side-effects. This seems > a bit strict - very understandable, considering the origins of the > language, but a bit strict nonetheless. Reformulating it as a semantic > rule would be a bit nicer, in my mind. showing my ignorance i must at this point ask if there is a (simple) explanation for syntax vs semantics. bengt From richardc@REDACTED Wed Apr 17 14:13:45 2002 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 17 Apr 2002 14:13:45 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: Message-ID: On Tue, 16 Apr 2002, Thomas Lindgren wrote: > [new and old type tests] > >The old type tests must of course remain for backwards > >compatibility, but they are now being renamed to the "is_" forms > >very early in the compilation. > > I think my basic question is whether one can rename guard tests > into the new operations directly. This way, one could get rid > of having both type(X) and is_type(X). It would seem to be possible > for most cases, perhaps excepting the dual mode of float(X) that > you mention, or any similar cases. > > (Though looking at the context, it should be possible to deduce > what version is intended: off the top of my head, on the toplevel > one uses is_float(X), inside arithmetic one uses to_float(X) or > whatever the operation may be called. Any questionable cases are > flagged with a warning.) You *can* do this, even today! (Shameless self-promotion follows.) If you get my syntax_tools package (1.2) from erlang.org, there is a module 'erl_tidy' (full documentation in doc/erl_tidy.html), which does this and lots more to "modernise" old code - all nicely pretty-printed with comments and preprocessor stuff preserved. A number of options are available to control what things are changed. If you just want to use it as a "lint"-thing, you can give it a flag "test", and you'll get the reports without changing files. It automatically updates known obsolete function calls to the new functions, where possible (i.e., where arity and argument order are the same). You can supply a list of additional functions to be redirected. It can remove unused functions from the code, and expand function imports so that all remote calls become explicit, plus some other nifty transformations. The 'dir' function works recursively through a directory tree. If files are being created, backups of the original files are made. I can't guarantee that it's totally bug free, but I have run it on the *whole* Erlang/OTP distribution - every single .erl file in it - and recompiled, and everything seems to work. In a few cases, it's just too hard for it to read a particular file (if weird macros are used), and then it just skips that file. Go ahead and try it. If you come up with more things it should be able to update, please tell me. > > /.../ the reason for the extension is to make guards more like > > other expressions. A complication is that failure in the first > > argument of a top-level guard 'or' (semicolon) goes on to try the > > other alternative as if there were two clauses, while at the > > expression-level the whole 'or'-operation fails immediately. > > I think making guards behave like expressions is a Good Thing, > generally speaking, because it is more convenient to have full > boolean expressions. As you say, the problem is nailing down the details. > > I suppose the behaviours above should be unified. If nothing else, for > the sanity of programmers :-) Not to mention the sanity of compiler writers :-] But this seems to be another of those things that just can't be changed. Syntactically, we can and do allow and/or for ,/; - but the semantic difference in guards between "top-level" conjunction and "expression-level" conjunction will have to remain, I'm afraid. It's a fairly subtle thing, and I don't think it will cause any real trouble. > [deep guards] > I'm a bit ambivalent about permitting "deep guards", however. > > What do we define as a side-effect, for instance? _Reading_ the > database? Permitting long-running guards means we must be able to > context-switch inside the guard, which means the database can change > while we run the guard, which might be construed as an impurity. > (And what about read locks?) And so on. > > I believe the original restriction on guards comes from concurrent > logic programming, where "deep guards" had severe problems and > ultimately led to disallowing them. Thanks - that saved me from trying to explain this point. I also believe that although we might be able to extend guards in Erlang somewhat, and remove some strange syntactic limitations, we will probably never have "deep guards" - they come with deep problems, especially with things like context switching. (And a special syntax for declaring guard functions does not fix this.) /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From richardc@REDACTED Wed Apr 17 14:34:14 2002 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 17 Apr 2002 14:34:14 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: <200204171157.g3HBvGU28382@cbe.ericsson.se> Message-ID: On Wed, 17 Apr 2002, Bengt Kleberg wrote: > showing my ignorance i must at this point ask if there is a (simple) > explanation for syntax vs semantics. Syntax: how the text is allowed to "look". Semantics: what sort of things/behaviour we are talking about Erlang's syntax is described by the tokenisation and parsing grammars. The semantics of Erlang programs is the visible behaviour and the data objects being manipulated. In the guards example, for instance, there are syntactic limits on how a guard may look: only certain combinations of infix operators and function calls, plus variables/constants. One can argue that any expression should be allowed (syntactically) as a guard, and only if it is semantically impossible - or at least not safe - should the compiler reject the program: for instance if one of the called functions might cause a side effect (perhaps indirectly). This would however require extra analysis beyond simple syntax checking. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From etxuwig@REDACTED Wed Apr 17 14:47:12 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 17 Apr 2002 14:47:12 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: Message-ID: On Wed, 17 Apr 2002, Richard Carlsson wrote: >On Tue, 16 Apr 2002, Thomas Lindgren wrote: > >> [deep guards] >> I'm a bit ambivalent about permitting "deep guards", however. >> >> What do we define as a side-effect, for instance? _Reading_ the >> database? Permitting long-running guards means we must be able to >> context-switch inside the guard, which means the database can change >> while we run the guard, which might be construed as an impurity. >> (And what about read locks?) And so on. >> >> I believe the original restriction on guards comes from concurrent >> logic programming, where "deep guards" had severe problems and >> ultimately led to disallowing them. > >Thanks - that saved me from trying to explain this point. I also >believe that although we might be able to extend guards in >Erlang somewhat, and remove some strange syntactic limitations, >we will probably never have "deep guards" - they come with deep >problems, especially with things like context switching. (And a >special syntax for declaring guard functions does not fix this.) > > /Richard In some way this is perhaps similar to the previous discussions on match specifications, where posters, self() included, have suggested a more erlang-like syntax. http://www.erlang.org/ml-archive/erlang-questions/200010/msg00223.html Basically, a fun() or similar could be used as a guard (or match specification) iff it is obvious to the compiler that it is (1) shallow, (2) pure. /Uffe From cpressey@REDACTED Wed Apr 17 20:31:39 2002 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 17 Apr 2002 13:31:39 -0500 Subject: extending standard behaviours In-Reply-To: <20020416203129.F60903@mobility.motivity.ca> References: <001201c1e585$e95d4720$9564a8c0@PRESSEY> <20020416203129.F60903@mobility.motivity.ca> Message-ID: <20020417133139.060ff09c.cpressey@catseye.mb.ca> On Tue, 16 Apr 2002 20:31:29 -0400 Vance Shipley wrote: > > OK, I see how to do this now. My new behaviour module will > look like a user to the gen_fsm behaviour and so it exports > the call backs that gen_fsm expects. It will look like a > behaviour to it's users so we export the same but possibly > extended interface as gen_fsm to our users. > > I put this together and it seems to work brilliantly. This > gives me exactly what I wanted which is to be able to write > generic handlers in one place and handle the specifics in > the individual state hanlder modules. For instance when > we terminate the fxs_fsm module's terminate/3 function will > do it's own clean up (hang up a call in a signaling specific > way) and then call the cha_fsm terminate function to do the > common clean up tasks (write to a log). Messages received > by fxs_fsm which are not understood by it are forwarded on > to chan_fsm which handles them in a generic way. > > Thanks Chris! > > -Vance Actually, I was having problems with my e-mail yesterday, and I thought that short message I sent might not have gone through. Not being very familiar with gen_fsm, I started putting together a more coherent and complete example from scratch, and I ran into some problems with that idea that worked so nicely in my own head :) In this example (attached), gen_cat.erl is a behaviour for a generic cat - it exports a function meow/1, and insists that whatever module implements it, exports a function meow_sound/0. (It's not a great example, but it's simple.) puff.erl behaves to gen_cat. gen_loud_cat.erl is a specialization of gen_cat which ensures that the sound the cat makes is loud (printed in uppercase). rusty.erl behaves to gen_loud_cat. gen_loud_cat behaves to gen_cat, and it 'intercepts' the meow_sound function, calling httpd_util:to_upper/1 on the sound, before passing it through to gen_cat. The problem is that gen_loud_cat must cache it's callback module in an ets table - because I couldn't see any other way for it to 'remember' what module is implementing it. That's not very elegant at all. I guess object-oriented languages use a list of superclasses - I know Perl does something like that - but if Erlang behaviours are written with only a singleton callback module in mind - it might be difficult to extend them. It might be easier, if they were written with a list of callback modules in mind. Or perhaps I simply missed something. The other odd thing that I didn't initially expect (thinking about this in somewhat too-OO terms) is that whether, for example, puff.erl behaves to gen_cat or gen_loud_cat is, on one level, irrelevant, since they both expose the same interface. The only difference is in how it's implemented- the specific behaviour. You can change the single line -behaviour(gen_cat) to -behaviour(gen_loud_cat) in puff.erl, and this changes puff's behaviour. But this is a good thing! This is the sort of near-interchangeability we're looking for, I think. Perhaps I missed a shortcut where a step could be skipped, but I'm not sure what it is. Anyway, I'm glad this hasn't turned out to be just an exercise in navel-gazing... :) Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: gen_cat.erl Type: application/octet-stream Size: 362 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: puff.erl Type: application/octet-stream Size: 87 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gen_loud_cat.erl Type: application/octet-stream Size: 490 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: rusty.erl Type: application/octet-stream Size: 133 bytes Desc: not available URL: From rcena@REDACTED Thu Apr 18 00:46:27 2002 From: rcena@REDACTED (Cena, Resty) Date: Wed, 17 Apr 2002 16:46:27 -0600 Subject: Erlang SQL to Oracle Message-ID: <06CBB456EB4A724D9D210FCA20E84513015D15E8@ececmx01.epcor.ca> Hi, Where can one get a copy of Tobias Lindgren's Erlang SQL interface to Oracle? Thanks. rcena@REDACTED From uglydaemon@REDACTED Thu Apr 18 02:28:55 2002 From: uglydaemon@REDACTED (Chris Moline) Date: Wed, 17 Apr 2002 18:28:55 -0600 Subject: How to print escape? Message-ID: <20020417182855.A16659@Veggie.lb.shawcable.net> hi, to learn erlang i am implementing a simple rogue-like game. my problem is that i cant seem to print escape. i have tried io:fwrite("~c[34m", [27]). io:format("~c[34m", [27]). io:put_chars([27,91,51,52,109]). all three of them print ^[[34m instead of causing the foreground color to become blue. how can i fix this? sincerly, chris moline From fritchie@REDACTED Thu Apr 18 06:13:00 2002 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 17 Apr 2002 23:13:00 -0500 Subject: Berkeley DB, was Telecom & Mnesia - Call Detail Record Collection In-Reply-To: Message of "Wed, 17 Apr 2002 13:28:00 +0200." <20020417132800.D4479@bluetail.com> Message-ID: <200204180413.g3I4D0832544@snookles.snookles.com> >>>>> "cw" == Klacke writes: cw> I looked a lot at the berkeley db a couple of years ago, the one cw> thing that made me stop workin on it was that I was never able to cw> figure out how to repair a broken berkely db file. Writing into cw> the berkely db updates the metadata for the file in way where cw> there are certain points in time where the file is cw> broken.... That's at least how I recall it. A friend of mine, I'll call him Bob, is much more familiar with the beauty and perils of Berkeley DB. He says: bob> There are known problems with recovery in DB 3.0.55 where it gets bob> confused trying to redo the log. They rewrote the recovery subsystem bob> in 3.1 and things appear to be much better since then. I also asked: >The only other related thing I can dredge from memory is that it >was/is? easier to hose a DB transaction system with multiple processes >operating in the same environment instead of a multithreaded single >process. bob> Oh, yes. All process that use the environment must have closed it bob> before recovery is performed. That can be by killing them or politely, bob> bearing in mind that processes may hang on a lock held by another thread bob> that choked, so that killing it may be the only way to get it out. bob> bob> If some process is still in the database when you run recovery, well, bob> all bets are off. On the Erlang driver front, things have been going well. I've got my dynamically loadable driver using Berkeley DB 4.0.14. It's creating tables and doing basic record storage & retrieval. There appear to be some memory leaks that I'll have to track down ... but adding functionality is more fun right now. :-) Perhaps I'll get the cursor-related calls typed in yet tonight before the pint of Boddington's hits me full force.... -Scott From vlad_dumitrescu@REDACTED Thu Apr 18 08:45:33 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 18 Apr 2002 08:45:33 +0200 Subject: extending standard behaviours Message-ID: Hi Chris, I have been thinking along those lines too, but never got to try it in practice. :-) First a note: for some reason Hotmail thought rusty.erl contains a virus, and refused to download it... Hmmm ;-) >The problem is that gen_loud_cat must cache it's callback module in an ets >table - because I couldn't see any other way for it to 'remember' what >module is implementing it. That's not very elegant at all. The alternative would be to extend the State of the gen_cat server, and store the callback there. Anyway, there must be a way to ask gen_cat for its state. >I guess object-oriented languages use a list of superclasses - I know Perl >does >something like that - but if Erlang behaviours are written with only a >singleton callback module in mind - it might be difficult to extend them. >It might be easier, if they were written with a list of callback modules >in mind. Right! OO languages do their magic by means of extensive support from the compiler and the runtime. It can be accomplished "the hard way" (tm), but it won't be nice nor easy. Think what it would be like to implement C++ classes in C... scary! The same extensive support from compiler/runtime we get in Erlang for pattern matching and receive statements (see ongoing discussion about that). This way we get expressiveness and clarity -- OO languages use just another approach. >Or perhaps I simply missed something. The other odd thing that I didn't >initially expect (thinking about this in somewhat too-OO terms) is that >whether, for example, puff.erl behaves to gen_cat or gen_loud_cat is, on >one level, irrelevant, since they both expose the same interface. The >only difference is in how it's implemented- the specific behaviour. You >can change the single line -behaviour(gen_cat) to -behaviour(gen_loud_cat) >in puff.erl, and this changes puff's behaviour. But this is a good thing! Why didn't you expect it? It's the same in OO - if you define a class with a public method, and inherit from it without changing the interface, then it isn't really relevant to which class an object belongs, it's only a difference of behaviour. Polymorphism! ;-) regards, Vlad _________________________________________________________________ MSN Foto ?r det enklaste s?ttet att dela eller skaffa papperskopior av dina foton: http://photos.msn.com/support/worldwide.aspx From fredrik.linder@REDACTED Thu Apr 18 09:18:17 2002 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Thu, 18 Apr 2002 09:18:17 +0200 Subject: Erlang language issues References: Message-ID: <003601c1e6a9$38e24920$01b7f2d5@frelin> > > > After some initial attempts at inventing new delimiters, all of which > > > had subtle problems, we came to the conclusion that the normal C comment > > > delimiters /* ... */ were probably the best choice. > > > > will they nest? (unlike c) > > Yes. Will you also allow // as an alternative to %? From eleberg@REDACTED Thu Apr 18 09:24:03 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Thu, 18 Apr 2002 09:24:03 +0200 (MET DST) Subject: Erlang language issues Message-ID: <200204180724.g3I7O3U03517@cbe.ericsson.se> > From: "Fredrik Linder" > Will you also allow // as an alternative to %? would this be beneficial? (ie, is the profit of 2 different comment-until-end-of-line markup signs bigger than the cost?) bengt From klacke@REDACTED Thu Apr 18 09:56:00 2002 From: klacke@REDACTED (Klacke) Date: Thu, 18 Apr 2002 09:56:00 +0200 Subject: How to print escape? In-Reply-To: <20020417182855.A16659@Veggie.lb.shawcable.net>; from uglydaemon@shaw.ca on Wed, Apr 17, 2002 at 06:28:55PM -0600 References: <20020417182855.A16659@Veggie.lb.shawcable.net> Message-ID: <20020418095600.B31565@bluetail.com> On Wed, Apr 17, 2002 at 06:28:55PM -0600, Chris Moline wrote: > hi, to learn erlang i am implementing a simple rogue-like game. my > problem is that i cant seem to print escape. i have tried > > io:fwrite("~c[34m", [27]). > io:format("~c[34m", [27]). > io:put_chars([27,91,51,52,109]). > > all three of them print ^[[34m instead of causing the foreground color > to become blue. how can i fix this? > > sincerly, > chris moline Doing tty/terminal stuff using the normal erlang i/o function is hard or even downright impossible. Your best bet for tty stuff is to use my slang interface which available at http://erlang.org/user.html This is a one 2 one mapping between erlang and the slang tty functions. (slang is a general purpose portable tty library) On ther other hand, since you said that you were actually learning erlang just right now, the slang library may be a bit hard to use..... /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From vlad_dumitrescu@REDACTED Thu Apr 18 10:37:25 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 18 Apr 2002 10:37:25 +0200 Subject: mod_dav Message-ID: Hi all, Does any of the existent Erlang web servers support WebDAV? If not, are there any plans? I tried to look at the P9 snapshot, but the tar got corrupted. Aside from "serious" (=corporate) use, it would be fun to rewrite the WikiE to use DAV... regards, Vlad _________________________________________________________________ H?mta MSN Explorer kostnadsfritt p? http://explorer.msn.se/intl.asp From Sean.Hinde@REDACTED Thu Apr 18 10:47:19 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 18 Apr 2002 09:47:19 +0100 Subject: Erlang SQL to Oracle Message-ID: <402DD461F109D411977E0008C791C312039F6A18@imp02mbx.one2one.co.uk> Hi, Have you considered using the standard ODBC interface which comes with OTP? I had good results with it last year when we were considering actually moving away from mnesia. Mnesia is now firmly back in top spot for us but ODBC certainly works. Sean > -----Original Message----- > From: Cena, Resty [mailto:rcena@REDACTED] > Sent: 17 April 2002 23:46 > To: 'erlang-questions@REDACTED' > Subject: Erlang SQL to Oracle > > > Hi, > Where can one get a copy of Tobias Lindgren's Erlang SQL interface to > Oracle? > Thanks. > rcena@REDACTED > NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From fredrik.linder@REDACTED Thu Apr 18 10:56:52 2002 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Thu, 18 Apr 2002 10:56:52 +0200 Subject: Erlang language issues References: <200204180724.g3I7O3U03517@cbe.ericsson.se> Message-ID: <005301c1e6b6$fc18bac0$01b7f2d5@frelin> > > From: "Fredrik Linder" > > > Will you also allow // as an alternative to %? > > would this be beneficial? (ie, is the profit of 2 different > comment-until-end-of-line markup signs bigger than the cost?) > Are there no tools for extracting comments from C++ code? If Erlang uses the same comment syntax as in C++, then one should be abel to use those tools. And what is the actual cost? Slightly altering the pre-processor? When we're at it, why not convert to C++-style completely, issuing a warning when % is used! Seriously, I think we'll have to live with %... /Fredrik From eleberg@REDACTED Thu Apr 18 13:20:13 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Thu, 18 Apr 2002 13:20:13 +0200 (MET DST) Subject: Erlang language issues Message-ID: <200204181120.g3IBKDU18051@cbe.ericsson.se> > From: "Fredrik Linder" > Are there no tools for extracting comments from C++ code? If Erlang uses the > same comment syntax as in C++, then one should be abel to use those tools. is it a good thing to be able to extract comments? i see the need for/use of tools like edoc, but simply extracting comments? perhaps there is a c++ tool that does what edoc does, and would be possible to use directly, if comments changed in erlang? that would be a good thing. there is not a lot of code written for edoc, and new code would use the style mandated by the c++ tool instead. > And what is the actual cost? Slightly altering the pre-processor? i must admit that i never consider changes in the compiler as a cost. mainly since i will not do it. i was thinking of the headache i would get from reading source with different style comments. and while teching people erlang, having to explain the different possiblities. > When we're at it, why not convert to C++-style completely, issuing a warning > when % is used! > Seriously, I think we'll have to live with %... if we have to live with %, why make things more complicated by having an alternative? bengt From vlad_dumitrescu@REDACTED Thu Apr 18 13:43:08 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 18 Apr 2002 13:43:08 +0200 Subject: Distel Message-ID: Hi, Did anyone got Distel working? (I suppose at least Luke should be able to answer "yes" :-) When the announcement came, I downloaded and I remember that it worked... but now whatever I do, the Erlang node says "Connection attemp from disallowed node erlmacs@REDACTED"... What could have happened? It is also possible that it never worked, and am just delirious ;-) but I'd like to have it started nevertheless. Btw Luke, is there any progress with XEmacs? Help needed? regards, Vlad _________________________________________________________________ Kom med i v?rldens st?rsta e-posttj?nst med MSN Hotmail. http://www.hotmail.com From vlad_dumitrescu@REDACTED Thu Apr 18 13:46:01 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 18 Apr 2002 13:46:01 +0200 Subject: Erlang language issues Message-ID: >there is not a lot of code written for >edoc, and new code would use the style mandated by the c++ tool >instead. erm, that's not entirely true... Of course, there's no use in reinventing the wheel, so if anything else works, then it's fine by me. But as it is, EDoc does some work at parsing Erlang code, which may have to be done with another tool too. regards, Vlad _________________________________________________________________ Kom med i v?rldens st?rsta e-posttj?nst med MSN Hotmail. http://www.hotmail.com From svg@REDACTED Thu Apr 18 14:36:37 2002 From: svg@REDACTED (Vladimir Sekissov) Date: Thu, 18 Apr 2002 18:36:37 +0600 (YEKST) Subject: Distel In-Reply-To: References: Message-ID: <20020418.183637.66835542.svg@surnet.ru> Good day, vlad_dumitrescu> Did anyone got Distel working? (I suppose at least Luke should be able to vlad_dumitrescu> answer "yes" :-) Yes, it works and works very well. Our admin for example is very happy with tail like emacs online browser of binary disk logs I've wrote for him with Distel. When I'd looked at Distel first time I was mostly interested in Emacs<->Erlang interaction but quickly realized that it makes pure emacs programming more easier. It allows me to think more like programmer not like Emacs buffer/window manager. Best Regards, Vladimir Sekissov From klacke@REDACTED Thu Apr 18 14:46:22 2002 From: klacke@REDACTED (Klacke) Date: Thu, 18 Apr 2002 14:46:22 +0200 Subject: mod_dav In-Reply-To: ; from vlad_dumitrescu@hotmail.com on Thu, Apr 18, 2002 at 10:37:25AM +0200 References: Message-ID: <20020418144622.B6372@bluetail.com> On Thu, Apr 18, 2002 at 10:37:25AM +0200, Vlad Dumitrescu wrote: > Hi all, > > Does any of the existent Erlang web servers support WebDAV? If not, are > there any plans? > > I tried to look at the P9 snapshot, but the tar got corrupted. > > Aside from "serious" (=corporate) use, it would be fun to rewrite the WikiE > to use DAV... > Me was thinkin about adding dav to my yaws server, just read the webdav rfc and it's quite a lot of stuff there.... lot's of work. /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From cyberlync@REDACTED Thu Apr 18 15:37:04 2002 From: cyberlync@REDACTED (Eric Merritt) Date: Thu, 18 Apr 2002 06:37:04 -0700 (PDT) Subject: Erlang language issues In-Reply-To: <005301c1e6b6$fc18bac0$01b7f2d5@frelin> Message-ID: <20020418133704.93730.qmail@web13007.mail.yahoo.com> > Are there no tools for extracting comments from C++ > code? If Erlang uses the > same comment syntax as in C++, then one should be > abel to use those tools. I believe that most comment extraction/document generators do at least some minimal amount of language parsing. Thus you would be able to use these without some, possibly extensive, modifications. In any case, what value would we get by using the '//' for eol comments we already have '%' which is actually shorter to type and just as easy to read. I personnaly dont see any reason to change this style of comments. I seams that all we would get from this are comments that looked like C comments - small return for any investment. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From hakan@REDACTED Thu Apr 18 16:21:35 2002 From: hakan@REDACTED (Hakan Mattsson) Date: Thu, 18 Apr 2002 16:21:35 +0200 (MEST) Subject: Distel In-Reply-To: Message-ID: On Thu, 18 Apr 2002, Vlad Dumitrescu wrote: Vlad> When the announcement came, I downloaded and I remember that it worked... Vlad> but now whatever I do, the Erlang node says "Connection attemp from Vlad> disallowed node erlmacs@REDACTED"... What could have happened? Check your Erlang distibution cookies. It looks like your erlang-node and your "emacs"-node uses incompatible cookies. /H?kan From joe@REDACTED Thu Apr 18 16:34:59 2002 From: joe@REDACTED (Joe Armstrong) Date: Thu, 18 Apr 2002 16:34:59 +0200 (CEST) Subject: Erlang language issues In-Reply-To: <20020418133704.93730.qmail@web13007.mail.yahoo.com> Message-ID: > > On Thu, 18 Apr 2002, Eric Merritt wrote: > > > Are there no tools for extracting comments from C++ > > code? If Erlang uses the > > same comment syntax as in C++, then one should be > > abel to use those tools. > I believe that most comment extraction/document > generators do at least some minimal amount of language > parsing. Thus you would be able to use these without > some, possibly extensive, modifications. > Yes but but but .... The problem with using existing tools is always that: 1) They do not work in *every* Erlang environment 2) They never do *exactly* what you want Now if they do "almost what you want" you have to modify them and port them to all Erlang environments. IMHO all tools for supporting Erlang code should be 100% pure Erlang programs (thus problem (1) is immediately solved). Modifing some almost right thing to make it do what you want is often far more difficult than "rolling your own from scratch". In the case we are discussing (extracting comments from code) the problem is trivial and a non-starter - formatting them is a tad more difficult but no big deal. Deciding what the code formatter should do is the tricky bit - expect many hours of heated discussion here :-) - but once you've decided what to do coding up the result is probably only a few hours hack. Modifing an existing program *desiged to run with C++* seems like a major project to me - but then any simple project can be made arbitrarily difficult by appropriate re-use of tools that you didn't implement yourself and which were designed to do something else :-) I favor re-inventing the wheel - much quicker to make a new wheel that works than bodge up an old one that doesn't. > In any case, what value would we get by using the '//' > for eol comments we already have '%' which is actually > shorter to type and just as easy to read. I personnaly > dont see any reason to change this style of comments. > I seams that all we would get from this are comments > that looked like C comments - small return for any > investment. > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Tax Center - online filing with TurboTax > http://taxes.yahoo.com/ > /Joe From vlad_dumitrescu@REDACTED Thu Apr 18 17:28:01 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 18 Apr 2002 17:28:01 +0200 Subject: Distel References: Message-ID: > Check your Erlang distibution cookies. > It looks like your erlang-node and your > "emacs"-node uses incompatible cookies. Ouch... it was actually even simpler: a needed external C program (dec32) was not to be found - a $path trouble. It still doesn't work perfectly, but at least it connects. thanx Vlad From cyberlync@REDACTED Thu Apr 18 17:37:22 2002 From: cyberlync@REDACTED (Eric Merritt) Date: Thu, 18 Apr 2002 08:37:22 -0700 (PDT) Subject: c Merritt Message-ID: <20020418153722.13381.qmail@web13002.mail.yahoo.com> I was wondaring why every one was posting replies that agreed with me so closly, then I realized my typo -> 'Thus you would be able to use these without some, possibly extensive, modifications.' should have read -> 'Thus you would not be able to use these without some, possibly extensive, modifications.' This will teach me not to review my comments before posting. Let me restate my point, we have a decent single line comment, it maybe a bit diffrent but it works. The only thing we would probably get from adding '//' style comments is some minor amount of confusion. There seems to be no ROI for this addition. Now that being said, I like the idea of multiline comments very much. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ From thomas.lindgren@REDACTED Thu Apr 18 17:37:58 2002 From: thomas.lindgren@REDACTED (Thomas Lindgren) Date: Thu, 18 Apr 2002 17:37:58 +0200 Subject: Erlang language issues In-Reply-To: Message-ID: From: Richard Carlsson [mailto:richardc@REDACTED] > You *can* [rewrite guards, etc], even today! (Shameless self-promotion follows.) Well, why not do it, then? :-) In the compiler, you can do it after macro preprocessing too, so the case of strange macros that you mention subsequently does not occur. It sounds like a nice tool, btw. >But this seems to be another of those things that just can't be changed. >Syntactically, we can and do allow and/or for ,/; - but the semantic >difference in guards between "top-level" conjunction and >"expression-level" conjunction will have to remain, I'm afraid. It's a >fairly subtle thing, and I don't think it will cause any real trouble. Subtle differences sound somewhat ominous to me; doubly so when there is no good reason for them (apart from "backwards compatibility"). Indeed, this proliferation was why I raised the question to begin with. (So we neatly return to the beginning again :-) -- Thomas From richardc@REDACTED Thu Apr 18 18:18:43 2002 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 18 Apr 2002 18:18:43 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: Message-ID: On Thu, 18 Apr 2002, Thomas Lindgren wrote: > > You *can* [rewrite guards, etc], even today! (Shameless self-promotion > follows.) > > Well, why not do it, then? :-) In the compiler, you can do it after > macro preprocessing too, so the case of strange macros that you mention > subsequently does not occur. Not sure what you mean here. Of course, the compiler does those things internally, when translating to Core Erlang: on that level, guards are plain boolean expressions composed of 'and' and 'or', with 'catch' blocks inserted as necessary to preserve the Erlang guard semantics. No confusion there. It's the source level backwards compatibility that's the problem. The not entirely unimportant category called "customers" do not want to change a single thing in their source code unless it is a bug - and preferably not even recompile anything. They won't switch to a new version of the compiler if that means new bugs in old code. There are several small things that I'd personally like to modify in the Erlang semantics, but it seems like a completely impossible thing to do. Still, maybe if a "New Erlang" was released, with a compiler that could be given a backwards-compatibility flag... or is that a pipe dream? /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From per@REDACTED Thu Apr 18 19:21:22 2002 From: per@REDACTED (Per Bergqvist) Date: Thu, 18 Apr 2002 18:21:22 +0100 Subject: =?iso-8859-1?q?dist=5Fac?= question Message-ID: <200204181621.g3IGLMn19807@raven.levonline.com> I have problems with dist_ac in R8B-1. The dist_ac procress is blocking for ever even though all nodes are defined in sync_nodes_optional. In the readme for bug OTP-3509 it says that sync_nodes functionality must be used. My question is : is sync_nodes_optional enough. Can somebody please elaborate a bit on the topic ? BR /Per ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From cpressey@REDACTED Thu Apr 18 19:45:26 2002 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 18 Apr 2002 12:45:26 -0500 Subject: Mnesia data partitioning question In-Reply-To: References: <004401c1e58f$a4c459a0$9564a8c0@PRESSEY> Message-ID: <20020418124526.7bb6eb1c.cpressey@catseye.mb.ca> On Wed, 17 Apr 2002 12:11:37 +0200 (MET DST) Ulf Wiger wrote: > On Tue, 16 Apr 2002, Chris Pressey wrote: > > >Although I don't really expect a concrete answer to this one, I > >thought it might be interesting to share opinions on the > >subject... > > > >Mnesia lacks the concept of a 'secondary key' - that is, using > >more than one field to uniquely identify a record. So, is it, > >generally speaking, wiser to model a many-to-many relationship > >in Mnesia as: > > > >- a 'set' table with a compound key, or > >- a 'bag' table with an index on a second field? > > I would go for a 'set' table with a compound key. Thanks (to Chandru as well.) That does seem the saner course. > I wonder if you've looked at the support for relational > constraints in the 'rdbms' contrib? It offers support for things > like cascading delete and "insertion constraints" (e.g. the > secondary key must identify an existing record in a given table.) > If you find it lacking in certain respects, I'd be happy to hear > what you feel would need to be added/changed. I have looked at it before; it would probably be overkill for the current project, which is almost at the 'refined prototype' stage and still less than 25k of source code - much of which is regularly 'drained off' into other reusable applications, as I discover stuff that is too tightly integrated. Perhaps it will be called for once it is in regular use. All my critique of the rdbms package is, like my critique of Erlang, more one of idealism and beauty, than a lack of doing-what-needs-to-be-done. It would be nice if record validation were more of a language-level concept, and if validation was more orthogonal with how type checking is presently done in the language (here we are back on the topic of guards, again - instead of the atom 'integer', the function 'is_integer' would seem more apropriate, and so forth.) But that's only because lack of orthogonality is one of my pet peeves :) Chris From luke@REDACTED Thu Apr 18 21:35:46 2002 From: luke@REDACTED (Luke Gorrie) Date: 18 Apr 2002 21:35:46 +0200 Subject: Distel In-Reply-To: References: Message-ID: "Vlad Dumitrescu" writes: > > Check your Erlang distibution cookies. > > It looks like your erlang-node and your > > "emacs"-node uses incompatible cookies. > > Ouch... it was actually even simpler: a needed external C program (dec32) > was not to be found - a $path trouble. It still doesn't work perfectly, but > at least it connects. I recently put Distel on Sourceforge, the project page is http://sourceforge.net/projects/distel/. The CVS version has some fixes since 1.0 (mostly thanks to Vladimir Sekissov). That might solve your troubles - otherwise please send me a mail or file a bug report on SF. Regarding XEmacs, the problem right now is that some Emacs functions I'm using don't exist there, like set-buffer-multibyte and dired-string-replace-match. If someone who knows XEmacs wants to port it I'll be happy to accept get a patch :-) otherwise I'll break out the XEmacs manual before the next release. BTW, a nice feature of the CVS version is pattern matching, e.g. you can "port": case X of {add, X, Y} -> X + Y; {sub, X, Y} -> X - Y; _ -> error end. to: (mcase x ([tuple add X Y] (+ x y)) ([tuple sub X Y] (- x y)) (_ 'error)) I'll do a new release after I get 'receive' implemented and update the manual. Toodlepip, Luke From vlad_dumitrescu@REDACTED Thu Apr 18 21:49:47 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 18 Apr 2002 21:49:47 +0200 Subject: debugger bug in R8B1? Message-ID: Hi! Are there any known problems with the debugger in R8B1? I tried to use it and all I get after interpreting modules and running test:go("test.erl") is ** exited: {{badfun,#Fun}, [{lists,map,2}, {dbg_debugged,handle_command,2}, {dbg_debugged,msg,1}, {test,go,1}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** Am I doing something wrong, or is it a bug? regards, Vlad From peter@REDACTED Thu Apr 18 21:56:24 2002 From: peter@REDACTED (Peter H|gfeldt) Date: Thu, 18 Apr 2002 21:56:24 +0200 (MET DST) Subject: =?iso-8859-1?q?dist=5Fac?= question In-Reply-To: <200204181621.g3IGLMn19807@raven.levonline.com> Message-ID: Quite some time since I tried this. I think though, that you have to set sync_nodes_timeout (to something finite) as well. /Peter On Thu, 18 Apr 2002, Per Bergqvist wrote: > I have problems with dist_ac in R8B-1. > The dist_ac procress is blocking for ever even though > all nodes are defined in sync_nodes_optional. > > In the readme for bug OTP-3509 it says that sync_nodes functionality > must be used. > > My question is : is sync_nodes_optional enough. > > Can somebody please elaborate a bit on the topic ? > > BR > /Per > > ========================================================= > Per Bergqvist > Synapse Systems AB > Phone: +46 709 686 685 > Email: per@REDACTED > From robert.virding@REDACTED Thu Apr 18 22:19:24 2002 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 18 Apr 2002 22:19:24 +0200 Subject: Erlang language issues References: Message-ID: <3CBF2A4C.2020408@telia.com> Richard Carlsson wrote: > On Wed, 17 Apr 2002, Bengt Kleberg wrote: > > >>>After some initial attempts at inventing new delimiters, all of which >>>had subtle problems, we came to the conclusion that the normal C comment >>>delimiters /* ... */ were probably the best choice. >> >>will they nest? (unlike c) > > > Yes. The trouble with blocked comments is that it can become very difficult to see if a section of code has been commented out. Especially if it a large block extending over one "page", which is generally when you use them. Yes I know you can have convetions like beginning each commented out line with a specific character, for example '*' in C-style comments but if you are going to do that then you might a well use ine comments. That is why I have been against block comments. If they are so great why were line comments added to C++? Robert From vlad_dumitrescu@REDACTED Thu Apr 18 23:18:47 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 18 Apr 2002 23:18:47 +0200 Subject: Distel References: Message-ID: > I recently put Distel on Sourceforge, the project page is > http://sourceforge.net/projects/distel/. The CVS version has some > fixes since 1.0 (mostly thanks to Vladimir Sekissov). That might solve > your troubles - otherwise please send me a mail or file a bug report > on SF. Yes and no - Vladimir told me about sourceforge, and it works now - to a point. The problem is not the Erlang link, but the display of the result for erl-process-list. > Regarding XEmacs, the problem right now is that some Emacs functions > I'm using don't exist there, like set-buffer-multibyte and > dired-string-replace-match. If someone who knows XEmacs wants to port > it I'll be happy to accept get a patch :-) otherwise I'll break out > the XEmacs manual before the next release. My XEmacs 21.1.1 has both of those functions. The above mentioned crash complains about a function called buffer-or-string-p, that I can't find (nor any references to it...) I would try the port, but I discovered that my Emacs programming skills have become very rusty and old and.... *sigh* Maybe after I do some field training! regards, Vlad From eleberg@REDACTED Fri Apr 19 07:37:22 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Fri, 19 Apr 2002 07:37:22 +0200 (MET DST) Subject: Erlang language issues Message-ID: <200204190537.g3J5bMU13741@cbe.ericsson.se> > > Date: Thu, 18 Apr 2002 22:19:24 +0200 > From: Robert Virding > The trouble with blocked comments is that it can become very difficult > to see if a section of code has been commented out. Especially if it a > large block extending over one "page", which is generally when you use > them. Yes I know you can have convetions like beginning each commented > out line with a specific character, for example '*' in C-style comments > but if you are going to do that then you might a well use ine comments. > > That is why I have been against block comments. If they are so great > why were line comments added to C++? block comments are much more difficult to read than line comments. especially c style block comments that do not nest. presumably this is why line comments got added to c++. the block-comment-for-erlang question/issue seems to have to do with some special case in text fomatting/processing where erlang will be inserted into something else. bengt From eleberg@REDACTED Fri Apr 19 07:50:20 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Fri, 19 Apr 2002 07:50:20 +0200 (MET DST) Subject: Erlang language issues Message-ID: <200204190550.g3J5oKU14533@cbe.ericsson.se> > X-Authentication-Warning: meg.it.uu.se: richardc owned process doing -bs > Date: Thu, 18 Apr 2002 18:18:43 +0200 (MET DST) > From: Richard Carlsson ...deleted > It's the source level backwards compatibility that's the problem. The > not entirely unimportant category called "customers" do not want to > change a single thing in their source code unless it is a bug - and > preferably not even recompile anything. They won't switch to a new > version of the compiler if that means new bugs in old code. i presume that you mean deprecated constructs when you write new bugs. any new compiler might genereate genuinly new bugs in the binary/beam file. a new compiler that issues a warning, and a (correct) suggestion on how to re-write the expression, is still my suggestion for source code. binary/beam backwards compatibility is much more important (too me). > There are several small things that I'd personally like to modify in the > Erlang semantics, but it seems like a completely impossible thing to do. > Still, maybe if a "New Erlang" was released, with a compiler that could > be given a backwards-compatibility flag... or is that a pipe dream? the backwards-compatibility-flag is a good idea. one could even keep an old, unchanging, version of the compiler in the distribution that was started in the presence of such a flag. and document the fact that backwards compatibility means including the old bugs :-) bengt From hakan@REDACTED Fri Apr 19 09:25:34 2002 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 19 Apr 2002 09:25:34 +0200 (MEST) Subject: Mnesia data partitioning question In-Reply-To: <20020418124526.7bb6eb1c.cpressey@catseye.mb.ca> Message-ID: On Thu, 18 Apr 2002, Chris Pressey wrote: Chris> On Wed, 17 Apr 2002 12:11:37 +0200 (MET DST) Chris> Ulf Wiger wrote: Chris> Chris> > On Tue, 16 Apr 2002, Chris Pressey wrote: Chris> > Chris> > >Although I don't really expect a concrete answer to this one, I Chris> > >thought it might be interesting to share opinions on the Chris> > >subject... Chris> > > Chris> > >Mnesia lacks the concept of a 'secondary key' - that is, using Chris> > >more than one field to uniquely identify a record. So, is it, Chris> > >generally speaking, wiser to model a many-to-many relationship Chris> > >in Mnesia as: Chris> > > Chris> > >- a 'set' table with a compound key, or Chris> > >- a 'bag' table with an index on a second field? Chris> > Chris> > I would go for a 'set' table with a compound key. You could also try the 'ordered_set' as it would almost give you an index on the left-most part of the compund key for free. For an ordered_set, a match on a {order_id, '_'} key pattern is much faster than a match on a {'_', shipment_id} key pattern as ets is keeping the records sorted on their keys. /H?kan From dnteletech008@REDACTED Fri Apr 19 10:03:38 2002 From: dnteletech008@REDACTED (Bulk Email CD) Date: Fri, 19 Apr 2002 09:03:38 +0100 Subject: 60 Million Email Addresses $30, 30 Euros, £20 Message-ID: <200204190808.g3J87oj35832@hades.cslab.ericsson.net> For simple information on this offer please visit http://70194581.com From tobbe@REDACTED Fri Apr 19 10:20:06 2002 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 19 Apr 2002 10:20:06 +0200 Subject: Erlang language issues In-Reply-To: <3CBF2A4C.2020408@telia.com> References: <3CBF2A4C.2020408@telia.com> Message-ID: I agree completely with Robert. Use a (Emacs-) keyboard macro (or something similar) to insert a block of comment signs. Cheers /Tobbe From gunilla@REDACTED Fri Apr 19 11:05:12 2002 From: gunilla@REDACTED (Gunilla Arendt) Date: Fri, 19 Apr 2002 11:05:12 +0200 Subject: debugger bug in R8B1? References: Message-ID: <3CBFDDC8.EEAB52F2@arendt.se> It's a bug in the code loading used by Debugger, for some reason it can't always handle funs. IIRC, it's nested funs that is the problem. / Gunilla Vlad Dumitrescu wrote: > > Hi! > > Are there any known problems with the debugger in R8B1? I tried to use it > and all I get after interpreting modules and running test:go("test.erl") is > > ** exited: {{badfun,#Fun}, > [{lists,map,2}, > {dbg_debugged,handle_command,2}, > {dbg_debugged,msg,1}, > {test,go,1}, > {erl_eval,expr,3}, > {erl_eval,exprs,4}, > {shell,eval_loop,2}]} ** > > Am I doing something wrong, or is it a bug? > > regards, > Vlad From vlad_dumitrescu@REDACTED Fri Apr 19 11:16:48 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 19 Apr 2002 11:16:48 +0200 Subject: inline compilation Message-ID: Hi again, I had some trouble that I tracked down to some inlined functions. It was my understanding that inlining works only inside a module, not when calling an external function. But it seems that the latter is the case, because I made a change to a function and suddenly nothing worked until I recompiled the other module too... Should it be so? thanks. /Vlad _________________________________________________________________ Skicka och ta emot Hotmail-meddelanden p? din mobilenhet: http://mobile.msn.com From Sean.Hinde@REDACTED Fri Apr 19 11:16:26 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Fri, 19 Apr 2002 10:16:26 +0100 Subject: Erlang language issues Message-ID: <402DD461F109D411977E0008C791C312039F6A21@imp02mbx.one2one.co.uk> > Richard Carlsson wrote: > > On Wed, 17 Apr 2002, Bengt Kleberg wrote: > > > > > >>>After some initial attempts at inventing new delimiters, > all of which > >>>had subtle problems, we came to the conclusion that the > normal C comment > >>>delimiters /* ... */ were probably the best choice. > >> > >>will they nest? (unlike c) > > > > > > Yes. > > That is why I have been against block comments. If they are so great > why were line comments added to C++? I agree, I thought this is what emacs was for (i.e blocking and unblocking out multiple lines of code with %) :) Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From peter@REDACTED Fri Apr 19 13:03:28 2002 From: peter@REDACTED (Peter H|gfeldt) Date: Fri, 19 Apr 2002 13:03:28 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: <3CBF2A4C.2020408@telia.com> Message-ID: On Thu, 18 Apr 2002, Robert Virding wrote: [...] > > That is why I have been against block comments. If they are so great > why were line comments added to C++? I completely agree. If you want to annotate your documentation with proper Erlang module code, you can do as follows :-). -module(nocommentsplease). -export([foo/0]). -ifdef(BULKYBLOCKCOMMENT). . -endif. foo() -> bar. /Peter From sameerp@REDACTED Fri Apr 19 13:00:21 2002 From: sameerp@REDACTED (Sameer Pendse) Date: Fri, 19 Apr 2002 16:30:21 +0530 Subject: no badarg thrown by spawned process - quiet ext Message-ID: i am using r8b-1 on win2k. in a spawned process, if i do a io:format("...~w",L) where L is a list, then my spawned process exits without a badarg error. if i put the L in a [L], it works fine. if i do the badop in a top-level process, i do get the badarg error. i thought this bug was resolved in 8b-1. From etxuwig@REDACTED Fri Apr 19 14:11:44 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 19 Apr 2002 14:11:44 +0200 (MET DST) Subject: no badarg thrown by spawned process - quiet ext In-Reply-To: Message-ID: On Fri, 19 Apr 2002, Sameer Pendse wrote: >i am using r8b-1 on win2k. > >in a spawned process, if i do a io:format("...~w",L) where L is >a list, then my spawned process exits without a badarg error. if >i put the L in a [L], it works fine. if i do the badop in a >top-level process, i do get the badarg error. Uhh, the second argument to io:format/2 is supposed to be a list. Thus, io:format("...~w", [L]) is the correct form. If your process was created with spawn/3, och spawn_link/3, you will not get any SASL crash report. If you instead use proc_lib:spawn[_link]/3, you will get a crash report when the process dies. /Uffe From sameerp@REDACTED Fri Apr 19 14:17:53 2002 From: sameerp@REDACTED (Sameer Pendse) Date: Fri, 19 Apr 2002 17:47:53 +0530 Subject: no badarg thrown by spawned process - quiet ext In-Reply-To: Message-ID: Uffe, i changed the spawn/3 to proc_lib:spawn/3 & did the wrong io:format. the spawned process still died quietly without throwing a proper 'badarg' EXIT. i need to get this resolved because quiet death's are a nuisance to debug. i can send you the .erl source code if you like so you can try for yourself. rsvp. cheers sameer -----Original Message----- From: Ulf Wiger [mailto:etxuwig@REDACTED] Sent: Friday, April 19, 2002 5:42 PM To: Sameer Pendse Cc: erlang-questions@REDACTED Subject: Re: no badarg thrown by spawned process - quiet ext On Fri, 19 Apr 2002, Sameer Pendse wrote: >i am using r8b-1 on win2k. > >in a spawned process, if i do a io:format("...~w",L) where L is >a list, then my spawned process exits without a badarg error. if >i put the L in a [L], it works fine. if i do the badop in a >top-level process, i do get the badarg error. Uhh, the second argument to io:format/2 is supposed to be a list. Thus, io:format("...~w", [L]) is the correct form. If your process was created with spawn/3, och spawn_link/3, you will not get any SASL crash report. If you instead use proc_lib:spawn[_link]/3, you will get a crash report when the process dies. /Uffe From yrashk@REDACTED Fri Apr 19 15:28:13 2002 From: yrashk@REDACTED (Yurii A. Rashkovskii) Date: Fri, 19 Apr 2002 16:28:13 +0300 Subject: Jam/MR Message-ID: <001301c1e7a6$0e91fb40$5864a8c0@softerra.int> Ladies and Gentlemen, Did anybody develop Jam/MR rules and actions for Erlang? -- Best regards, Yurii (http://yar.com.ua/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Fri Apr 19 15:43:08 2002 From: vances@REDACTED (Vance Shipley) Date: Fri, 19 Apr 2002 09:43:08 -0400 Subject: no badarg thrown by spawned process - quiet ext In-Reply-To: ; from sameerp@3genesis.com on Fri, Apr 19, 2002 at 05:47:53PM +0530 References: Message-ID: <20020419094308.A48286@mobility.motivity.ca> On Fri, 19 Apr 2002, Sameer Pendse wrote: > >in a spawned process, if i do a io:format("...~w",L) where L is >a list, then my spawned process exits without a badarg error. if >i put the L in a [L], it works fine. if i do the badop in a >top-level process, i do get the badarg error. Since the secord argument to io:format/2 is supposed to be a list if you pass it a list as you say the behaviour will depend on what is in that list. It may even work: 9> L = [foo]. [foo] 10> io:format("...~w~n", L). ...foo ok I tried a couple things and they all gave me a badarg. What is in your list? -Vance -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED From sameerp@REDACTED Fri Apr 19 16:21:30 2002 From: sameerp@REDACTED (Sameer Pendse) Date: Fri, 19 Apr 2002 19:51:30 +0530 Subject: pri queue manager/attached .erl file - spawned process exiting In-Reply-To: <20020419094308.A48286@mobility.motivity.ca> Message-ID: guys, i have attached qmpri.erl which implements priority message processing using time-outs. same problem here is that the spawned process exits/dies quietly, pman seems to indicate a badarg situation - but that is not getting thrown to console. 1. c(qmpri). 2. Qm=qmpri:start([1,2,3,4]). 3. qmpri:testdeq(Qm). % this just waits because pid=Qm has vanished can you advise on why qmpri:qm/1 is quitting out of infinite recursion in the absence of a stop message? cheers sameer -----Original Message----- From: Vance Shipley [mailto:vances@REDACTED] Sent: Friday, April 19, 2002 7:13 PM To: Sameer Pendse Cc: Ulf Wiger; erlang-questions@REDACTED Subject: Re: no badarg thrown by spawned process - quiet ext On Fri, 19 Apr 2002, Sameer Pendse wrote: > >in a spawned process, if i do a io:format("...~w",L) where L is >a list, then my spawned process exits without a badarg error. if >i put the L in a [L], it works fine. if i do the badop in a >top-level process, i do get the badarg error. Since the secord argument to io:format/2 is supposed to be a list if you pass it a list as you say the behaviour will depend on what is in that list. It may even work: 9> L = [foo]. [foo] 10> io:format("...~w~n", L). ...foo ok I tried a couple things and they all gave me a badarg. What is in your list? -Vance -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: qmpri.erl Type: application/octet-stream Size: 871 bytes Desc: not available URL: From vances@REDACTED Fri Apr 19 17:36:22 2002 From: vances@REDACTED (Vance Shipley) Date: Fri, 19 Apr 2002 11:36:22 -0400 Subject: pri queue manager/attached .erl file - spawned process exiting In-Reply-To: ; from sameerp@3genesis.com on Fri, Apr 19, 2002 at 07:51:30PM +0530 References: <20020419094308.A48286@mobility.motivity.ca> Message-ID: <20020419113621.A48454@mobility.motivity.ca> Sameer, The start function has some problems: start(L) -> io:format("Queue: ~w~n",[L]), QmPid = spawn(qm,qm,[L]). The first argument to spawn should be the module name, in this case 'qmpri'. The QmPid variable assignment does noting here as it is lost as soon as the function is done. Change it to: start(L) -> io:format("Queue: ~w~n",[L]), spawn(qmpri,qm,[L]). Now you get a process running as you see here: Erlang (BEAM) emulator version 5.1.1 [source] Eshell V5.1.1 (abort with ^G) 1> c(qmpri). {ok,qmpri} 2> Qm=qmpri:start([1,2,3,4]). Queue: [1,2,3,4] <0.33.0> 3> i(0, 33, 0). [{current_function,{qmpri,qm,1}}, {initial_call,{qmpri,qm,1}}, {status,waiting}, {message_queue_len,0}, {messages,[]}, {links,[]}, {dictionary,[]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.21.0>}, {heap_size,233}, {stack_size,3}, {reductions,1}, {garbage_collection,[{fullsweep_after,65535}]}] -Vance On Fri, Apr 19, 2002 at 07:51:30PM +0530, Sameer Pendse wrote: } guys, } } i have attached qmpri.erl which implements priority message processing using } time-outs. same problem here is that the spawned process exits/dies quietly, } pman seems to indicate a badarg situation - but that is not getting thrown } to console. } } 1. c(qmpri). } 2. Qm=qmpri:start([1,2,3,4]). } 3. qmpri:testdeq(Qm). % this just waits because pid=Qm has vanished } } can you advise on why qmpri:qm/1 is quitting out of infinite recursion in } the absence of a stop message? } } cheers } sameer From Chandrashekhar.Mullaparthi@REDACTED Fri Apr 19 17:45:45 2002 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Fri, 19 Apr 2002 16:45:45 +0100 Subject: pri queue manager/attached .erl file - spawned process exitin g Message-ID: <402DD461F109D411977E0008C791C31205E06630@imp02mbx.one2one.co.uk> Vance has pointed out why your infinite recursion isn't working. On windows, when you start an erlang shell, sasl isn't automatically started. At the command line, start the sasl application application:start(sasl). 5> qmpri:start([1,2,3,4]). Queue: [1,2,3,4] <0.55.0> 6> =CRASH REPORT==== 19-Apr-2002::16:49:39 === crasher: pid: <0.55.0> registered_name: [] error_info: {undef,[{qm,qm,[[1,2,3,4]]},{proc_lib,init_p,5}]} initial_call: {qm,qm,[[1,2,3,4]]} ancestors: [<0.33.0>] messages: [] links: [] dictionary: [] trap_exit: false status: running heap_size: 233 stack_size: 23 reductions: 83 neighbours: cheers Chandru -----Original Message----- From: Sameer Pendse [mailto:sameerp@REDACTED] Sent: 19 April 2002 15:22 To: Vance Shipley; Ulf Wiger; erlang-questions@REDACTED Subject: pri queue manager/attached .erl file - spawned process exiting guys, i have attached qmpri.erl which implements priority message processing using time-outs. same problem here is that the spawned process exits/dies quietly, pman seems to indicate a badarg situation - but that is not getting thrown to console. 1. c(qmpri). 2. Qm=qmpri:start([1,2,3,4]). 3. qmpri:testdeq(Qm). % this just waits because pid=Qm has vanished can you advise on why qmpri:qm/1 is quitting out of infinite recursion in the absence of a stop message? cheers sameer -----Original Message----- From: Vance Shipley [mailto:vances@REDACTED] Sent: Friday, April 19, 2002 7:13 PM To: Sameer Pendse Cc: Ulf Wiger; erlang-questions@REDACTED Subject: Re: no badarg thrown by spawned process - quiet ext On Fri, 19 Apr 2002, Sameer Pendse wrote: > >in a spawned process, if i do a io:format("...~w",L) where L is >a list, then my spawned process exits without a badarg error. if >i put the L in a [L], it works fine. if i do the badop in a >top-level process, i do get the badarg error. Since the secord argument to io:format/2 is supposed to be a list if you pass it a list as you say the behaviour will depend on what is in that list. It may even work: 9> L = [foo]. [foo] 10> io:format("...~w~n", L). ...foo ok I tried a couple things and they all gave me a badarg. What is in your list? -Vance -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From return@REDACTED Sat Apr 20 20:46:41 2002 From: return@REDACTED (Christine Hall) Date: Sun, 21 Apr 2002 2:46:41 +0800 Subject: WWW.ERLANG.ORG Message-ID: <200204210836.g3L8ah720106@ns5.trafficmagnet.net> An HTML attachment was scrubbed... URL: From per@REDACTED Sun Apr 21 10:23:46 2002 From: per@REDACTED (Per Bergqvist) Date: Sun, 21 Apr 2002 09:23:46 +0100 Subject: =?iso-8859-1?q?dist=5Fac?= question In-Reply-To: Message-ID: <200204210723.g3L7NkB24925@lejon.levonline.com> Investigating dist_ac a bit more exposed some serious deadlocks. 1) During startup it almost certain that introduce will cause a deadlock if nodes are started at the same time. 2) weight negotiation will cause a lock-up if a app is not yet loaded on a remote node. Fixed in the attached patch. Apply with patch -p0 The problem is present in previous releases as well. The weight negotiation is somewhat changed so that dist_ac will respond with weight = undefined if there are some kind of problem. Weight = undefined will later on be excluded from selection of node. Has anybody ever successfully used distributed applications ??? /Per > > Quite some time since I tried this. I think though, that you have to > set sync_nodes_timeout (to something finite) as well. > > /Peter > > On Thu, 18 Apr 2002, Per Bergqvist wrote: > > > I have problems with dist_ac in R8B-1. > > The dist_ac procress is blocking for ever even though > > all nodes are defined in sync_nodes_optional. > > > > In the readme for bug OTP-3509 it says that sync_nodes functionality > > must be used. > > > > My question is : is sync_nodes_optional enough. > > > > Can somebody please elaborate a bit on the topic ? > > > > BR > > /Per > > > > ========================================================= > > Per Bergqvist > > Synapse Systems AB > > Phone: +46 709 686 685 > > Email: per@REDACTED > > > ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED -------------- next part -------------- A non-text attachment was scrubbed... Name: R8B-1.patch8 Type: application/octet-stream Size: 3459 bytes Desc: not available URL: From luke@REDACTED Mon Apr 22 05:14:54 2002 From: luke@REDACTED (Luke Gorrie) Date: 22 Apr 2002 05:14:54 +0200 Subject: Distel 2.0 In-Reply-To: References: Message-ID: "Vlad Dumitrescu" writes: > Btw Luke, is there any progress with XEmacs? Help needed? I just did a new release, this one works on XEmacs. Better yet, this one has a "receive" construct with pattern matching. There aren't any new Emacs "client" commands in this release, just a better programming interface. See the updated manual for details! Cheers, Luke From joe@REDACTED Mon Apr 22 10:42:41 2002 From: joe@REDACTED (Joe Armstrong) Date: Mon, 22 Apr 2002 10:42:41 +0200 (CEST) Subject: Erlang language issues In-Reply-To: Message-ID: > On Thu, 18 Apr 2002, Robert Virding wrote: > [...] > > > > That is why I have been against block comments. If they are so great > > why were line comments added to C++? > To make it even more ugly :-) > I completely agree. If you want to annotate your documentation with proper > Erlang module code, you can do as follows :-). > > -module(nocommentsplease). > -export([foo/0]). > > -ifdef(BULKYBLOCKCOMMENT). > > . > > -endif. > > foo() -> > bar. > > /Peter This, I suppose, is a pessimisation (I'd always wanted to use that word) of /* and */ :-). The principle reason for block comments is for the sake of edoc, since if people write lots of documentation in edoc it will look foul if every line of documentation is preceded by a %. This is not only aesthetically displeasing but also it is a pain to edit - and yes if you have emacs and the right .el files I'm sure this can be fixed - but not everybody has emacs (I know they *should* but they don't). Why do I think that this is aesthetically displeasing? Modules consist of code interspersed by comments - or at least I think they *should* consists of code and comments. If we use a meta character to distinguish the two (like %) there are two possible choices A) We tag all the comments, leaving the code untagged (this is what most languages do. or B) We tag all the code leaving the comments untagged. Of the two conventions we chose, of course, the wrong one - A) when it should have been B) - what we should have done was to use the "literate comment" convention in Haskell - we should have said "all lines beginning with %" are code - the rest are comments. The reason for this is, of course, comments [which are in a natural language] have a far less rigid syntax than code - we *expect* to have to write code according to rigid syntax rules (like, for example, having to put a % at the start of every line) - we do not expect to have to do this for English. At least, when I went to school nobody told me to put a % at the start of every line I wrote - and I guess if they did this to every line of text in my daily paper everybody would start complaining. So as an alternative to block comments I'd happily consider "literate Erlang" where the comment convention is reversed. To quote the Haskell report "The literate style encourages comments by making them the default" - encouraging comments seems to be a worth thing to do :-) Block comments have several advantages, not the least of which is they save your fingers and are environmentally friendly. A long time ago Robert changed his login name (and email address etc.) from robert to rv - this, he ensured me, was to save typing and to stop him from waring his fingers out - it only took him the best part of a week to change his name and mail *all* his friends etc. - but this he assured me was a long term gain. After a mere 47,000 (I forget the exact number) logins he would reap the benefits and his fingers would last longer. The gain of /* */ over "% per line" comes if you write more than 4 lines of comments per comment block - we can thus hypothesis that those people who write *more* than 4 lines of comments per comment block would be in favor of block comments and those who wrote less would be against :-) Why environmentally friendly? Less characters = less space = smaller disks = less disk factories = less pollution. The only *disadvantage* is that you might comment out a large block of code which you don't easily see when you are editing. What can we do about that? emacs to the rescue [1] The code bits are color coded (at least mine are) so you can easily see what's code and whats not - /Joe [1] I know From eleberg@REDACTED Mon Apr 22 12:30:37 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Mon, 22 Apr 2002 12:30:37 +0200 (MET DST) Subject: Erlang language issues Message-ID: <200204221030.g3MAUbU19020@cbe.ericsson.se> > X-Authentication-Warning: enfield.sics.se: joe owned process doing -bs > Date: Mon, 22 Apr 2002 10:42:41 +0200 (CEST) > From: Joe Armstrong ...deleted > The principle reason for block comments is for the sake of edoc, since if > people write lots of documentation in edoc it will look foul if every > line of documentation is preceded by a %. > > This is not only aesthetically displeasing but also it is a pain to > edit - and yes if you have emacs and the right .el files I'm sure this > can be fixed - but not everybody has emacs (I know they *should* but > they don't). one pain is that reformatting will put the %s all over the text. ...deleted > A) We tag all the comments, leaving the code untagged (this is > what most languages do. > > or > > B) We tag all the code leaving the comments untagged. > > > Of the two conventions we chose, of course, the wrong one - A) when it > should have been B) - what we should have done was to use the > "literate comment" convention in Haskell - we should have said "all > lines beginning with %" are code - the rest are comments. good idea. you should have thought of that a little bit earlier. :-) ...deleted > > So as an alternative to block comments I'd happily consider "literate > Erlang" where the comment convention is reversed. this is surly a better solution than block comments. ...deleted > Block comments have several advantages, not the least of which is they > save your fingers and are environmentally friendly. i use an editor (not emacs) to add % first. the selection and adding is done with a mouse, something that saves greatly upon my fingers. > Why environmentally friendly? > > Less characters = less space = smaller disks = less disk factories = > less pollution. you forgot :-) > The only *disadvantage* is that you might comment out a large block of > code which you don't easily see when you are editing. What can we do > about that? sofar the compiler has always told me when code is missing. if i manage to remove both the -export() and the code, then i would lose. but my main objection to block comments is that i am far more likely to confuse myself and others by doing the following with block comments (this was actually a C code example that used #ifdefs): /* start1 lots of comments and code /* start2 lots of comments and code end 2 */ /* start3 lots of comments end1 */ lots of comments and code end3 */ guess what happened when i (the maintainer) tried to get rid of the start3 code that was no longer needed? bengt From vlad_dumitrescu@REDACTED Mon Apr 22 14:55:41 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 22 Apr 2002 14:55:41 +0200 Subject: Erlang language issues Message-ID: > > So as an alternative to block comments I'd happily consider "literate > > Erlang" where the comment convention is reversed. >this is surly a better solution than block comments. If I may add my 0.02 euros ;-) I like the idea, but there is still a problem: code needs sometimes be reformatted too... it might not be a big issue when writing new code, but for maintenance, it is a pain not to have Emacs -- so it should be noted then thet Emacs Erlang mode should be aware of the % signs and keep them in the right place, even iserting them when appropriate. But I feel this gets things more complicated than they should be... regards Vlad _________________________________________________________________ Chatta med kompisar online, prova MSN Messenger: http://messenger.msn.com From Sean.Hinde@REDACTED Mon Apr 22 15:10:42 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 22 Apr 2002 14:10:42 +0100 Subject: Erlang language issues Message-ID: <402DD461F109D411977E0008C791C312039F6A51@imp02mbx.one2one.co.uk> > > > So as an alternative to block comments I'd happily > consider "literate > > > Erlang" where the comment convention is reversed. Erlang is a declarative language. What are these /%comment%/ things used for again? Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From joe@REDACTED Mon Apr 22 16:02:36 2002 From: joe@REDACTED (Joe Armstrong) Date: Mon, 22 Apr 2002 16:02:36 +0200 (CEST) Subject: Erlang language issues In-Reply-To: <402DD461F109D411977E0008C791C312039F6A51@imp02mbx.one2one.co.uk> Message-ID: On Mon, 22 Apr 2002, Sean Hinde wrote: > > > > > So as an alternative to block comments I'd happily > > consider "literate > > > > Erlang" where the comment convention is reversed. > > Erlang is a declarative language. What are these /%comment%/ things used for > again? > > Sean The code tells the computer what to do. The comments might, on a good day, give you a faint clue as to what the program was supposed to do. /Joe From Sean.Hinde@REDACTED Mon Apr 22 16:43:03 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 22 Apr 2002 15:43:03 +0100 Subject: Erlang language issues Message-ID: <402DD461F109D411977E0008C791C312039F6A56@imp02mbx.one2one.co.uk> > > Erlang is a declarative language. What are these > /%comment%/ things used for > > again? > The code tells the computer what to do. > > The comments might, on a good day, give you a faint clue as > to what the > program was supposed to do. Or on a bad day, when the comments are way out of date, quite possibly lead you right up the garden path. I guess my point was the rather tired old one that if you understand the problem domain, and choose meaningful function names then it should be pretty self evident what the program does. Agreed that reading other peoples C programs is often almost impossible without comments, but reading Erlang is not often that hard except for maybe any really tricky synchro bits (in which case comments about this would be fairly meaningless taken in isolation). Here at T-Mobile (UK) we tend to work by writing a Functional Spec which has pretty pictures and a wide audience/review. The code tends to be a straightforward declaration of the contents of this doc. I have thought about edoc style/literate programming before but never quite saw the value add in the context of this type of work (Emacs doesn't do pictures for example, and if the audience is only other programmers then too many words can get in the way of the reality). Maybe it's of most use for library writers where the API docs can be kept with the code (OK, OK I know the point is supposed to be a complete culture change in the way programming is done but pending that there must be some use for this stuff :)) Sean (Who recently spent two weeks finishing off someone's pretty much undocumented code while they were on holiday, and having no problems understanding any of it) NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From jamesh@REDACTED Mon Apr 22 16:57:59 2002 From: jamesh@REDACTED (James Hague) Date: Mon, 22 Apr 2002 09:57:59 -0500 Subject: Erlang language issues Message-ID: Joe Armstrong wrote: >This is not only aesthetically displeasing but also it is a pain to >edit - and yes if you have emacs and the right .el files I'm sure this >can be fixed - but not everybody has emacs (I know they *should* but >they don't). Anyone who uses Emacs is automatically disqualified from talking about aesthetics :) >So as an alternative to block comments I'd happily consider "literate >Erlang" where the comment convention is reversed. I like this idea a lot. There just needs to be a simple way to differentiate between literate and non-literate Erlang source files. File extension? From joe@REDACTED Mon Apr 22 17:10:20 2002 From: joe@REDACTED (Joe Armstrong) Date: Mon, 22 Apr 2002 17:10:20 +0200 (CEST) Subject: Erlang language issues In-Reply-To: Message-ID: On Mon, 22 Apr 2002, James Hague wrote: > Joe Armstrong wrote: > > >This is not only aesthetically displeasing but also it is a pain to > >edit - and yes if you have emacs and the right .el files I'm sure this > >can be fixed - but not everybody has emacs (I know they *should* but > >they don't). > > Anyone who uses Emacs is automatically disqualified from talking about > aesthetics :) > > >So as an alternative to block comments I'd happily consider "literate > >Erlang" where the comment convention is reversed. > > I like this idea a lot. There just needs to be a simple way to > differentiate between literate and non-literate Erlang source files. File > extension? > Since the comment convention is reversed then so would the extension => .lre /Joe From jamesh@REDACTED Mon Apr 22 17:21:49 2002 From: jamesh@REDACTED (James Hague) Date: Mon, 22 Apr 2002 10:21:49 -0500 Subject: Pyrex Message-ID: An interesting post from Lambda the Ultimate, included below. I've thought in the past about how something like this could work for Erlang. It would be really nice to be able to write BIF-like extensions without having to modify the runtime system and without having to stream everything through a binary port. For example, there's no good way to tack a speedy matrix multiply into the Wings3D code. http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/ Pyrex - A language for writing Python extension modules Pyrex is a language specially designed for writing Python extension modules. It's designed to bridge the gap between the nice, high-level, easy-to-use world of Python and the messy, low-level world of C... Pyrex deals with the basic types just as easily as SWIG, but it also lets you write code to convert between arbitrary Python data structures and arbitrary C data structures, in a simple and natural way, without knowing anything about the Python/C API. That's right -- nothing at all! Nor do you have to worry about reference counting or error checking -- it's all taken care of automatically, behind the scenes, just as it is in interpreted Python code. And when fully implemented, Pyrex will let you define new built-in Python types just as easily as you can define new classes in Python. The way this works is that you write code in a Python-like language (Pyrex), which allows you to access C data types directly, as well as standard Python data. The Pyrex code is then compiled into C. Seems like a nice way to extend a language. Better than having to use a different language completely, as when writing extension modules in C or C++. In some sense this is reminiscent of inlining and macros. From richardc@REDACTED Mon Apr 22 17:18:10 2002 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 22 Apr 2002 17:18:10 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: <402DD461F109D411977E0008C791C312039F6A56@imp02mbx.one2one.co.uk> Message-ID: On Mon, 22 Apr 2002, Sean Hinde wrote: > Or on a bad day, when the comments are way out of date, quite > possibly lead you right up the garden path. > > I guess my point was the rather tired old one that if you understand the > problem domain, and choose meaningful function names then it should be > pretty self evident what the program does. I agree; in as much as possible, the function and module names should give you most of the clues you need, and comments should neither duplicate nor be instead of good naming and structuring conventions. > Maybe it's of most use for library writers where the API docs can be > kept with the code Quite so. There are at least two kinds of documentation: First, we have the comments in the source code (and any other external documents) which help the programmer understand what the program actually does, and what the original author was thinking (often: what the programmer himself was thinking six months ago). Second, we have the API documentation: How is the program/module/library used? What functions are there? What arguments do I pass them? What guarantees are there? What happens if ...? It's very nice indeed to be able to browse this kind of stuff online, with lots of cross-references. And it *needs* to be up-to-date. "Literary programming" usually targets the first, or both, of these, but is generally overkill unless you plan to publish something like The TeXbook. Programs like Javadoc or EDoc only target the second category, making it easy to keep the API documentation updated. However, things like obsolete docs should be avoided: first of all, use good naming conventions and you won't have to write so much extra documentation on the side. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From thomas.lindgren@REDACTED Mon Apr 22 17:33:32 2002 From: thomas.lindgren@REDACTED (Thomas Lindgren) Date: Mon, 22 Apr 2002 17:33:32 +0200 Subject: Erlang language issues In-Reply-To: Message-ID: >Not sure what you mean here. Of course, the compiler does those things >internally, when translating to Core Erlang: on that level, guards are >plain boolean expressions composed of 'and' and 'or', with 'catch' >blocks inserted as necessary to preserve the Erlang guard semantics. No >confusion there. There you go then. One could use your tool to automatically rewrite as much of the code as possible, carefully telling the programmer what it has done, and also let the Erlang compiler flag obsolete constructs (much like it does today with some operations) when put in "migration mode". >It's the source level backwards compatibility that's the problem. The >not entirely unimportant category called "customers" do not want to >change a single thing in their source code unless it is a bug - and >preferably not even recompile anything. They won't switch to a new >version of the compiler if that means new bugs in old code. Since I am working for a company using Erlang, I took the opportunity to hear how things are done. Cellpoint is a pretty small firm, with roughly 20 developers and 10 testers. So what does the project management think about non-backwards compatible changes to Erlang? I asked our project leader, who supervises the whole shebang and who has been doing project supervision for a decade or so. [I paraphrase and summarize a short conversation here:] -- In order to move to a new release of Erlang, (1) the system has to be re-tested; (2) Cellpoint also has made a number of internal patches to Erlang, which have to be migrated to a new release. Doing _this_ migration work is needed regardless of whether Erlang-the-language is backwards compatible or not, obviously. There is also (3) installed base. The basic problem is that some customers are unwilling to migrate to a new product release, but still want you to patch the code. If so, you have to work with two language versions until you can persuade customers to switch. (In Cellpoint's case this is not a big problem; perhaps AXD301 would find it more painful.) The actual porting problem is deemed to be minor, as long as the language changes are minor. -- So that's one data point (which I hope I summarized fairly). Anybody else want to comment, please do. In closing, I'd like to say that I do _not_ propose continuing changes to the language in this way. Not at all. But I do think we need an orderly way to change things when the language is getting hairy. Best, Thomas From Sean.Hinde@REDACTED Mon Apr 22 18:35:41 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 22 Apr 2002 17:35:41 +0100 Subject: Erlang language issues Message-ID: <402DD461F109D411977E0008C791C312039F6A58@imp02mbx.one2one.co.uk> > The actual porting problem is deemed to be minor, as > long as the language changes are minor. > -- > > So that's one data point (which I hope I summarized fairly). > Anybody else > want to comment, please do. OK, I'll add that from a T-Mobile (UK) (I am practising not saying the old name!) point of view, with only our several years work worth of codebase, I would be happy to migrate code in such cases if it improves the language. Apart from anything else we don't have any pesky external customers (only pesky internal ones :-) ). > In closing, I'd like to say that I do _not_ propose continuing changes > to the language in this way. Not at all. But I do think we > need an orderly > way to change things when the language is getting hairy. I'd actually be happy to see any deprecated features disappear within a release or two (so long as there's a better replacement - even better again if there are automated update tools). Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From cpressey@REDACTED Mon Apr 22 19:58:35 2002 From: cpressey@REDACTED (Chris Pressey) Date: Mon, 22 Apr 2002 12:58:35 -0500 Subject: Erlang language issues In-Reply-To: References: Message-ID: <20020422125835.4c300a0c.cpressey@catseye.mb.ca> On Wed, 17 Apr 2002 11:56:44 +0200 (MET DST) Richard Carlsson wrote: > On Wed, 17 Apr 2002, Vlad Dumitrescu wrote: > > > Would a "block comment" concept be wrong for Erlang? Difficult to > > implement? > > Not difficult to implement; just a question of deciding on the > delimiters. Joe Armstrong also proposed this, mainly to make it easier > to write edoc documentation, and it has been agreed that block comments > should be added to the language, probably for the next release. (Should > have told you this before, Vlad - sorry.) > > After some initial attempts at inventing new delimiters, all of which > had subtle problems, we came to the conclusion that the normal C comment > delimiters /* ... */ were probably the best choice. > > Flames, anybody? Yes. I object to the characterization of any part of C as 'normal'. :-) The only pressing reason to have block comments that I can see is to interleave Erlang code with some other language code, like Javascript and HTML. Personally I find that approach, with any two languages, very ugly - polyglots are interesting curiousities, but relying on them during real work is headache-y. I know next to nothing about XML, but - isn't it supposed to provide alternatives for this sort of thing? By supplying a 'structured document' approach? Parts of a document can be in Erlang, parts can be in HTML, parts can be Javascript, parts can be English commentary, and parts can be diagrams and theme music and whatever else. The Erlang part can be automatically extracted just before compilation - it's not as if the compiler should care what's in comments. But I know nothing about XML, so maybe I'm on the wrong track with that idea. Erlang is in theory self-documenting - but choosing appropriate function and variable names is a lot harder than it sounds. Many functions should probably be nested, but aren't, resulting in some very strange names, suffixed with _tail or 0. And single-letter variable names are a hard habit to break, when called for - sometimes they are OK, in utility functions where there is not much that can be assumed about the values. Other times they are disastrous, although, probably worse in a non-single-assignment language like C. Chris From richardc@REDACTED Mon Apr 22 20:35:14 2002 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 22 Apr 2002 20:35:14 +0200 (MET DST) Subject: Erlang language issues In-Reply-To: <20020422125835.4c300a0c.cpressey@catseye.mb.ca> Message-ID: On Mon, 22 Apr 2002, Chris Pressey wrote: > I know next to nothing about XML, but - isn't it supposed to provide > alternatives for this sort of thing? By supplying a 'structured > document' approach? Parts of a document can be in Erlang, parts can > be in HTML, parts can be Javascript, parts can be English > commentary, and parts can be diagrams and theme music and whatever > else. The Erlang part can be automatically extracted just before > compilation - it's not as if the compiler should care what's in > comments. Well, you'd want a special editor (or Emacs-mode) that can handle this for you, since it would mean that every program file would have to be a proper XML file (beginning with some painful XML-declaration stuff), and of course, you'd have to escape every '<' or '&' character, unless you're in a CDATA ("verbatim") block. Basically: XML is just a formalisation of how to represent a tree structure as text. It's a more picky version of SGML - e.g., you cannot leave out end tags - with some extra stuff like name spaces and data types. (And XHTML is thus a picky version of HTML.) I just don't think the world is ready yet to go from plain text files (simple to read, use any text editor) to "XML everywhere". Not until practically all text editors and similar tools can handle it. > Erlang is in theory self-documenting - but choosing appropriate > function and variable names is a lot harder than it sounds. Many > functions should probably be nested, but aren't, resulting in some > very strange names, suffixed with _tail or 0. And single-letter > variable names are a hard habit to break, when called for - > sometimes they are OK, in utility functions where there is not much > that can be assumed about the values. Other times they are > disastrous, although, probably worse in a non-single-assignment > language like C. That's true, but again, I was really only talking about the API part, i.e., the public functions. As long as you give those good names and reasonable input/output conventions, it does not matter to a user if it looks horrible inside. :-] (Not until they try to fix your bugs, anyway...) /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From thomas@REDACTED Mon Apr 22 21:01:10 2002 From: thomas@REDACTED (Thomas Lange) Date: Mon, 22 Apr 2002 21:01:10 +0200 Subject: queries allowed with form posts? Message-ID: <3CC45DF6.9B1ACD3C@corelatus.com> I am building a chat server that uses ESI to call my code. But, "
", does not work. mod_esi only handles query strings if action is "GET", not "POST", which causes the function erlchat:logoff?User to be called. So is the reason: 1. Lack of functionality in mod_esi? 2. This is not allowed according to standards? 3. I am stupid enough to use query strings this way? I can use an input variable instead, no big deal, but I just want to know the reason. /Thomas From fritchie@REDACTED Wed Apr 24 06:35:49 2002 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Tue, 23 Apr 2002 23:35:49 -0500 Subject: Erlang to driver communication: why not a non-serialized option? Message-ID: <200204240435.g3O4Zn851741@snookles.snookles.com> Well, there's an easy answer to that: to maintain the same interface (on the Erlang side) when communicating with a C driver or a driver in an external process (communicating via a pipe). However, in the last couple of major releases, the fiction that the two types of drivers are the same has eroded. (Aside: I use "C driver" to mean a driver that is either linked into the VM at compile time or a driver dynamically loaded by erl_ddll. I'll call the original kind of driver, in an external UNIX process, a "pipe driver". Are there better words to name them?) The first erosion was the addition of "outputv" to the ErlDrvEntry structure used by C drivers. Code on the Erlang side still sent an I/O list to the port, but the driver side can access the data via and ErlIOVec structure. That way is more efficient because the data doesn't need to be fully copied into a single contiguous buffer before the driver can access it. (I've noticed that small amounts of data will be copied into a single buffer, though.) The second (and much larger) erosion was the introduction of driver_output_term() and driver_send_term(). These functions break the serialization barrier by making it possible to send an Erlang term to an Erlang process instead of a mere sequence of bytes.(*) The third erosion is something that snuck in with R8 (?), erlang:port_call/3. It allows both sending and receiving arbitrary /erlang terms to and from the driver. Cool! ... except that it, too, maintains the "C drivers and pipe drivers are the same" fiction. To make a long quesion short, what reasons are there for avoiding giving C drivers direct access to the C structure that represents the term? I'm interested for a couple of reasons: 1. Efficiency. It seems like every Erlang project I've worked on involves moving lots of data through drivers: TCP, UDP, then UNIX domain sockets and shared memory, and now Berkeley DB. All that extra byte copying is damn annoying. 2. Ease of driver implementation. Accessing a terms' C data structure may not seem "easy" in the general case (like dealing with an arbitrary length & depth I/O list), but you can force the Erlang side to restrict what kinds of terms it passes to the driver. And dealing with those C structures may very well be easier than the *tedious* work of serializing the arguments to a driver call on the Erlang side and unserializing them in the driver side ... and having to do the same thing again for the reply. All that byte copying is damn annoying. Perhaps I should've picked a project with an API that has fewer than 40+ functions I wanted to expose to Erlang. Perhaps I picked the perfect driver to expose this problem, to whine if anyone has a solution already, and if not, storm off and go write a solution myself. :-) -Scott (*) Despite this "advance" in communicating in the driver -> Erlang direction, there are still vestiges of serial communication. For example, the prim_inet.erl module uses an interesting trick to make "receive" filtering easier: 1. Send a serialized request to the tcp_inet driver asking it to perform an accept(2) on an existing socket. 2. Erlang gets a small serialized message back from the driver that acknowledges that the request was kosher. The message includes an encoded 16 bit integer, call it Ref, that will be included in the "real" response to the accept call. 3. Erlang then simply has to wait for the real answer: receive {inet_async, S, Ref, Status} -> case Status of ok -> accept_opts(L, S); Error -> close(S), Error end end; Ref isn't an Erlang reference but just an integer, but it's doing the same thing that references are chiefly used for: tagging messages for selective receipt. From per@REDACTED Wed Apr 24 10:07:37 2002 From: per@REDACTED (Per Bergqvist) Date: Wed, 24 Apr 2002 09:07:37 +0100 Subject: erLounge Stockholm In-Reply-To: <200204231004.g3NA4qP01956@raven.levonline.com> Message-ID: <200204240707.g3O77c905231@lejon.levonline.com> Hi, As we all know it is fun to use Erlang. To make it even more fun we think it is about time to get together over a (lot of) beer, share experiences and discuss life, universe and everything. Proposed date is Wednesday May 8th. Please send a mail to erlounge@REDACTED if you are interested and we will make the necessary arrangements. Best Regards, Per Bergqvist, Synapse Systems AB Patrik Winroth, Vindaloo AB From per@REDACTED Wed Apr 24 10:07:48 2002 From: per@REDACTED (Per Bergqvist) Date: Wed, 24 Apr 2002 09:07:48 +0100 Subject: erLounge Stockholm In-Reply-To: <200204231004.g3NA4qP01956@raven.levonline.com> Message-ID: <200204240707.g3O77m905336@lejon.levonline.com> Hi, As we all know it is fun to use Erlang. To make it even more fun we think it is about time to get together over a (lot of) beer, share experiences and discuss life, universe and everything. Proposed date is Wednesday May 8th. Please send a mail to erlounge@REDACTED if you are interested and we will make the necessary arrangements. Best Regards, Per Bergqvist, Synapse Systems AB Patrik Winroth, Vindaloo AB From joe@REDACTED Wed Apr 24 14:50:01 2002 From: joe@REDACTED (Joe Armstrong) Date: Wed, 24 Apr 2002 14:50:01 +0200 (CEST) Subject: Starting Erlang In-Reply-To: Message-ID: Hello, I am working on a new stand-alone Erlang - this time I want to do it properly.... So far I have manged to build windows .exe files in a pure Erlang environment (which means you can build your windows .exe files on linux and then run them on windows). I am now turning my attention to the Erlang start sequence itself. Questions: Does *anybody* understand (I mean *really* understand the Erlang start-boot sequence). Is all this junk in the .script files really necessary. Do you think there would be any objections if I reworked it all? Does anybody write their own .script files and make their own home rolled .boot files? - If so please mail me privatly. I currently imagine distributing applications something like this: 1) You install "Erlang" (one dll or so) (I hope) and erlRun (an executable to lauch Erlang) 2) An application is (usually) three files. foo.bat (windows launcher) foo.sh (unix launcher) foo.ear (Erlang archive) foo.bar and foo.sh would be one liners containing just erlRun foo.ear -s Mod Func Arg1 Arg2 ... ArgN foo.ear is assumed to be a Mod x Code archive - The code in this is loaded (lazily) Evaluating the command line: foo.sh ExtraArg1, ExtraArg2, ... Would just do apply(Mod, Func, [Arg1, .. ArgN], [ExtraArg1, .., ExtraArgN]) that's it. For those of you who want the "old style" behaviour all the things that are done inside the .script files and in init.erl and kernel.erl can be safely hidden away inside one of the start up modules. 3) the new erlRun command would (probably) have many extra args, so you could say > erlRun F1.ear F2.ear URL , ..... To allow multiple archives and loading off URI's etc. 4) The program epack would make a single file executable from a .bat or .sh file > epack Foo.bat would create Foo.exe for windows (with *everything* packed into one file) > epack Foo.sh would do the same for unixes I also feel it is high time to revamp code loading. code.erl is a total mess - IMHO we sould only retain the few calls that people actually make and add support so we can code load off URLs and .ear archives. Will this worry anybody? /Joe From etxuwig@REDACTED Wed Apr 24 17:29:51 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 24 Apr 2002 17:29:51 +0200 (MET DST) Subject: Starting Erlang In-Reply-To: Message-ID: On Wed, 24 Apr 2002, Joe Armstrong wrote: >Does *anybody* understand (I mean *really* understand the Erlang >start-boot sequence). Is all this junk in the .script files >really necessary. I think I understand at least some of it. And I have a serious gripe: You cannot patch .app files, as they are read at installation time and then copied into the boot script. If, for example, you'd want to add an application dependency or an included application -- or do something trivial as updating the description field -- you must reinstall the system or perform a full software upgrade. By contrast, changes to an erlang module can be easily inserted as a patch into the system. "Patching" the boot script by recompiling it in place really breaks the release handling structure -- you are clearly not supposed to do things like that. One idea I've had is that the .app file attributes should become callbacks in the application behaviour instead. I have not yet convinced myself that it's the best solution, but I'm working on it. >Do you think there would be any objections if I reworked it all? Well... I'd say that all the usual objections probably apply (: (Don't let that deter you from exploring the matter, though.) >Does anybody write their own .script files and make their own >home rolled .boot files? - If so please mail me privatly. I have mailed you privately. (: /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From jamesh@REDACTED Wed Apr 24 18:02:57 2002 From: jamesh@REDACTED (jamesh@REDACTED) Date: Wed, 24 Apr 2002 18:02:57 +0200 (CEST) Subject: No subject Message-ID: <200204241602.g3OG2uj64954@hades.cslab.ericsson.net> From jamesh@REDACTED Wed Apr 24 18:08:12 2002 From: jamesh@REDACTED (James Hague) Date: Wed, 24 Apr 2002 11:08:12 -0500 Subject: Erlang to driver communication: why not a non-serialized opti on? Message-ID: >The second (and much larger) erosion was the introduction of >driver_output_term() and driver_send_term(). These functions break >the serialization barrier by making it possible to send an Erlang term >to an Erlang process instead of a mere sequence of bytes.(*) > >The third erosion is something that snuck in with R8 (?), >erlang:port_call/3. Are there examples of either of these? It seems that the documentation has gotten very behind in this area. From mikpe@REDACTED Wed Apr 24 18:49:44 2002 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 24 Apr 2002 18:49:44 +0200 (MET DST) Subject: Starting Erlang Message-ID: <200204241649.SAA19199@harpo.it.uu.se> On Wed, 24 Apr 2002 14:50:01 +0200 (CEST), Joe Armstrong wrote: > 2) An application is (usually) three files. > > foo.bat (windows launcher) > foo.sh (unix launcher) > foo.ear (Erlang archive) > > foo.bar and foo.sh would be one liners > containing just > > erlRun foo.ear -s Mod Func Arg1 Arg2 ... ArgN > > foo.ear is assumed to be a Mod x Code archive - > The code in this is loaded (lazily) Please please please make .ear be a standard (e.g. POSIX) archive format, usable by standard tools (e.g. tar/cpio/pax). The world doesn't need Yet Another Pointless Archive Format(TM). /Mikael From mbj@REDACTED Wed Apr 24 20:35:45 2002 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 24 Apr 2002 20:35:45 +0200 (CEST) Subject: Starting Erlang In-Reply-To: References: Message-ID: <20020424.203545.78705067.mbj@bluetail.com> Joe Armstrong wrote: > I am now turning my attention to the Erlang start sequence itself. > > Questions: > > Does *anybody* understand (I mean *really* understand the > Erlang start-boot sequence). Yes, I'd like to think that I do (and I think that e.g. magnus does). > Is all this junk in the .script files > really necessary. Well... of course this is just one solution to the problem, there are others. > Do you think there would be any objections if I reworked it all? Please make sure that you understand *everything* about how script/boot files are used before changing this (I got the impression from your question that you don't). It's very easy to fall into the old trap "I don't understand this code, it looks complicated, it can't be necessary, I'll remove it". Also, I don't think it's very complicated. init.erl interprets the boot script (which usually is generated by a tool like systools.erl) A boot script for a complete product may look complicated, but remember start_old.script? It was pretty small. > Does anybody write their own .script files and make their own > home rolled .boot files? - If so please mail me privatly. Yes, Nortel does (by using the appropriate tools). /martin From fritchie@REDACTED Thu Apr 25 02:55:13 2002 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 24 Apr 2002 19:55:13 -0500 Subject: Erlang to driver communication: why not a non-serialized opti on? In-Reply-To: Message of "Wed, 24 Apr 2002 11:08:12 CDT." Message-ID: <200204250055.g3P0tD854144@snookles.snookles.com> >>>>> "jh" == James Hague writes: >> The second (and much larger) erosion was the introduction of >> driver_output_term() and driver_send_term(). [...] >> >> The third erosion is something that snuck in with R8 (?), >> erlang:port_call/3. jh> Are there examples of either of these? It seems that the jh> documentation has gotten very behind in this area. A find + xargs grep of the OTP R8 Erlang code didn't find any usage of erlang:port_call/3. The R8 docs mention it in the "erlang" section of the Kernel Reference Manual, but it is misalphabetized: it appears between port_control and erlang:port_info. The only driver that appears to use driver_output_term() or driver_send_term() is the inet_drv driver, found in erts/emulator/drivers/common/inet_drv.c; it uses both. -Scott From vances@REDACTED Thu Apr 25 09:01:58 2002 From: vances@REDACTED (Vance Shipley) Date: Thu, 25 Apr 2002 03:01:58 -0400 Subject: Erlang to driver communication: why not a non-serialized opti on? In-Reply-To: <200204250055.g3P0tD854144@snookles.snookles.com>; from fritchie@snookles.com on Wed, Apr 24, 2002 at 07:55:13PM -0500 References: <200204250055.g3P0tD854144@snookles.snookles.com> Message-ID: <20020425030155.G1016@mobility.motivity.ca> James Hague writes: } } Are there examples of either of these? It seems that the } documentation has gotten very behind in this area. The documentation does describe driver_output_term() for example: $ERL_TOP/lib/erlang/erts-5.1.1/doc/html/erl_driver.html -Vance -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED From joe@REDACTED Thu Apr 25 09:42:50 2002 From: joe@REDACTED (Joe Armstrong) Date: Thu, 25 Apr 2002 09:42:50 +0200 (CEST) Subject: Starting Erlang In-Reply-To: <20020424.203545.78705067.mbj@bluetail.com> Message-ID: > Joe Armstrong wrote: > > > I am now turning my attention to the Erlang start sequence itself. > > > > Questions: > > > > Does *anybody* understand (I mean *really* understand the > > Erlang start-boot sequence). > > Yes, I'd like to think that I do (and I think that e.g. magnus does). This was more of a rhetorical question - it is (as you say) reasonably simple :-) What I was wondering more was if all the things that we made provision for in the boot sequence are actually used. The vast majority of systems seem to fetch their code from a file system either local, NFS mounted or flashed. init.erl has the possibility to fetch code from the net. *does anybody use the -loader inet -hosts ...* stuff ????? > > > Is all this junk in the .script files > > really necessary. > > Well... of course this is just one solution to the problem, there are > others. > > > Do you think there would be any objections if I reworked it all? > > Please make sure that you understand *everything* about how > script/boot files are used before changing this (I got the impression > from your question that you don't). It's very easy to fall into the > old trap "I don't understand this code, it looks complicated, it can't > be necessary, I'll remove it". > > Also, I don't think it's very complicated. init.erl interprets the > boot script (which usually is generated by a tool like systools.erl) > A boot script for a complete product may look complicated, but > remember start_old.script? It was pretty small. Actually, one small addition to the init scripting language would solve a lot of problems (i.e. a change to init:eval_script), i.e. add a: {loadCode, Mod, Bin} Instruction - this way you could include code directly in the boot file. A simple change to systools could ensure that the correct code is found and added. /Joe > From etxuwig@REDACTED Thu Apr 25 09:57:27 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 25 Apr 2002 09:57:27 +0200 (MET DST) Subject: Starting Erlang In-Reply-To: Message-ID: On Thu, 25 Apr 2002, Joe Armstrong wrote: > init.erl has the possibility to fetch code from the net. > > *does anybody use the -loader inet -hosts ...* stuff ????? We have at least discussed this option as we move towards running Erlang on our device boards. A simple NFS mount might do the trick, though. We need to look at it some more. Your idea of including binaries in the script file is a bit interesting, but it would make patching more difficult (then again, if it's an _option_, this doesn't have to be a problem). Of course, _reading_ start.script would be a bit more tiring if all the beam code were embedded -- kindof defeats the purpose of having a text representation... I'm sure this can be solved elegantly. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From joe@REDACTED Thu Apr 25 10:22:00 2002 From: joe@REDACTED (Joe Armstrong) Date: Thu, 25 Apr 2002 10:22:00 +0200 (CEST) Subject: Starting Erlang In-Reply-To: <200204241649.SAA19199@harpo.it.uu.se> Message-ID: On Wed, 24 Apr 2002, Mikael Pettersson wrote: > On Wed, 24 Apr 2002 14:50:01 +0200 (CEST), Joe Armstrong wrote: > > 2) An application is (usually) three files. > > > > foo.bat (windows launcher) > > foo.sh (unix launcher) > > foo.ear (Erlang archive) > > > > foo.bar and foo.sh would be one liners > > containing just > > > > erlRun foo.ear -s Mod Func Arg1 Arg2 ... ArgN > > > > foo.ear is assumed to be a Mod x Code archive - > > The code in this is loaded (lazily) > > Please please please make .ear be a standard (e.g. POSIX) archive > format, usable by standard tools (e.g. tar/cpio/pax). > The world doesn't need Yet Another Pointless Archive Format(TM). > > /Mikael > Ummm - It's not clear to me the advantages of following a standard format outweigh the advantages of using a non-standard format.... Since I expect an Erlang program to produce the YAPAF file and another Erlang program to consume the YAPAF I don't see why it matters what the format is. A symmetric pair of term_to_binary and binary_to_term calls is all that is needed - not exactly complex code. Using a YAPAF file means the standard tools like tar/cpio/... cannot work on these formats - and this you can view as either an advantage or a disadvantage depending upon your perspective. I think it's an advantage since other people cannot (easily) mess around with your files :-) In my experience doing things in pure Erlang is usually quicker than mixing tools (apart from if the non Erlang thing is itself terribly complex). Standard tools seem in my experience not to be so standard (or maybe I've just been unlucky) - and don't work identically on all platforms - I know they should - but they often don't. Even if they *do* work they are usually not available on all platforms - I would not, for example, want to have to install the Cygnus gnu utilities on windows in order to list the contents of a archive file. I would (possibly) agree if unpacking the archive file occurred late in the boot sequence - the problem is that the *first* file read in the boot sequence *is* the archive file. So basically all I want to do is execute a minimal bit of code that says, something like: {ok, Bin} = prim_file_read(BootFile), {Mods, {M,F,A}} = binary_to_term(Bin), map(fun({Mod,Bin}) -> load_code(Mod, Bin) end, Mods), apply(M,F,A) I don't (at this stage) want to execute complex code to unpack a tar file format before I can get started - remember this happens very *early* in the boot sequence so I want this to be as fast as possible (so I can do single line shell scripts for scripting applications) hopefully much faster than (say) perl. I don't mind unpacking tar files etc. *late* in the boot sequence - since by then all my code for error handling and recovery is loaded - but not early in the boot sequence. /Joe From vances@REDACTED Thu Apr 25 11:06:04 2002 From: vances@REDACTED (Vance Shipley) Date: Thu, 25 Apr 2002 05:06:04 -0400 Subject: Starting Erlang In-Reply-To: ; from joe@sics.se on Thu, Apr 25, 2002 at 10:22:00AM +0200 References: <200204241649.SAA19199@harpo.it.uu.se> Message-ID: <20020425050603.H1016@mobility.motivity.ca> On Thu, Apr 25, 2002 at 09:42:50AM +0200, Joe Armstrong wrote: } } The vast majority of systems seem to fetch their code from a file system } either local, NFS mounted or flashed. } } init.erl has the possibility to fetch code from the net. } } *does anybody use the -loader inet -hosts ...* stuff ????? On Thu, Apr 25, 2002 at 09:57:27AM +0200, Ulf Wiger wrote: } } We have at least discussed this option as we move towards running } Erlang on our device boards. A simple NFS mount might do the } trick, though. ..... We have been thinking along the same lines. Erlang/OTP is well suited for a more distributed control architecture and we had been planning to run some nodes embedded on cPCI peripheral cards. In this scenario I had thought that using the cPSB ethernet bus to load code and do distribution was a perfect fit. -Vance -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED From vances@REDACTED Thu Apr 25 12:24:29 2002 From: vances@REDACTED (Vance Shipley) Date: Thu, 25 Apr 2002 06:24:29 -0400 Subject: Erlang to driver communication: why not a non-serialized option? In-Reply-To: <200204240435.g3O4Zn851741@snookles.snookles.com>; from fritchie@snookles.com on Tue, Apr 23, 2002 at 11:35:49PM -0500 References: <200204240435.g3O4Zn851741@snookles.snookles.com> Message-ID: <20020425062427.I1016@mobility.motivity.ca> Scott, Thanks for pointing out the new features in erl_driver et. al. There are a number of improvements: - ease of encoding complex erlang terms - zero copying of terms - ability to send terms to arbitrary processes - registered port names The latter allows a good deal of optimization for some uses. I am rewriting our driver for the Netaccess LAPD/MTP2 boards to use all of these features. One thing that seems odd at first glance is that when doing syncronous calls from erlang into the driver the terms are sent and received in a different format than the asyncronous functions used to send terms from the driver to erlang. When erlang:port_call/3 is used the driver's callback is passed a buffer which can be decoded with the functions in the ei library (part of erl_interface). The same library is used to encode the response to the erlang port. The erl_driver functions driver_output_term() and driver_send_term() use "the driver term format". There are a set of functions for doing some of this encoding but they are entirely different than ei. I guess it goes with what you were saying about there being some increasing differences between drivers and ports. -Vances -- Vance Shipley Motivity Telecom Inc. +1 519 579 5816 vances@REDACTED From thomas.lindgren@REDACTED Thu Apr 25 13:42:01 2002 From: thomas.lindgren@REDACTED (Thomas Lindgren) Date: Thu, 25 Apr 2002 13:42:01 +0200 Subject: Starting Erlang In-Reply-To: Message-ID: >> Please please please make .ear be a standard (e.g. POSIX) archive >> format, usable by standard tools (e.g. tar/cpio/pax). >> The world doesn't need Yet Another Pointless Archive Format(TM). >> >> /Mikael > > Ummm - It's not clear to me the advantages of following a standard >format outweigh the advantages of using a non-standard format.... > > Since I expect an Erlang program to produce the YAPAF file and >another Erlang program to consume the YAPAF I don't see why it matters >what the format is. A symmetric pair of term_to_binary and >binary_to_term calls is all that is needed - not exactly complex code. If there is any interest, I have not one but two .ear formats with encoder/decoders :-) Yes, they are YAPAFs, but straightforward ones.(On the bright side, I have archived and installed the entire OTP .beam collection with both. On Solaris and Linux.) The main advantage of doing it in Erlang is portability, hence availability. (This doesn't argue for a YAPAF, of course, since we could implement some well-known format in Erlang.) We can use the same code on Windows and VxWorks as on various Unices. (Using a YAPAF, we also get the double-edged sword of flexibility :-) -- Thomas From enano@REDACTED Thu Apr 25 13:53:06 2002 From: enano@REDACTED (Miguel Barreiro Paz) Date: Thu, 25 Apr 2002 13:53:06 +0200 (CEST) Subject: Starting Erlang In-Reply-To: <20020425050603.H1016@mobility.motivity.ca> Message-ID: > We have at least discussed this option as we move towards running > Erlang on our device boards. A simple NFS mount might do the > trick, though. ..... The problem with NFS is that upon network failures tends to behave in rather unpredictable ways, from clean unmounting to mounts hanging or not recovering for an extremely long time (and thus processes with their cwd or open descriptors on that filesystem either hanging or dying). One certainly wants a process reading boot code to work or fail, not to wait for a long time in an uncertain state. Also events like rebooting a server and not the clients may range from harmless to a recipe for disaster depending on client/server combinations. (I had to say that, just after fighting a mountain of Linux, AIX, IRIX and Solaris boxes of various ages using NFS 2 and 3, over TCP and UDP, with automount and autofs or nothing at all, with soft and hard mounts, with... agh) Regards, Miguel From joe@REDACTED Thu Apr 25 14:22:50 2002 From: joe@REDACTED (Joe Armstrong) Date: Thu, 25 Apr 2002 14:22:50 +0200 (CEST) Subject: Simple xref question Message-ID: How can I find all functions in the standard system that call a given function {Mod,Func,Arity}? Is their a one-liner to do this? /Joe From joe@REDACTED Thu Apr 25 15:03:23 2002 From: joe@REDACTED (Joe Armstrong) Date: Thu, 25 Apr 2002 15:03:23 +0200 (CEST) Subject: Starting Erlang In-Reply-To: Message-ID: On Thu, 25 Apr 2002, Ulf Wiger wrote: > On Thu, 25 Apr 2002, Joe Armstrong wrote: > > > init.erl has the possibility to fetch code from the net. > > > > *does anybody use the -loader inet -hosts ...* stuff ????? > > We have at least discussed this option as we move towards running > Erlang on our device boards. A simple NFS mount might do the > trick, though. We need to look at it some more. Your idea of > including binaries in the script file is a bit interesting, but > it would make patching more difficult (then again, if it's an > _option_, this doesn't have to be a problem). I (quickly) tried changing eval_script in init.erl to include a command to load some embedded code - a very easy change - this opens up a range of interesting possibilities ... assume the start.script is now {script, {"OTP APN 181 01","P9"}, [{preLoaded,[init,erl_prim_loader]}, {progress,preloaded}, {loadCode, [sneaky]}, {apply, {sneaky, run, []}}]} then you change systools:script2boot so that is *expands* loadCode into {script, {"OTP APN 181 01","P9"}, [{preLoaded,[init,erl_prim_loader]}, {progress,preloaded}, {loadCode, [{sneaky, <>]}, {apply, {sneaky, run, []}}]} Where Bin is the beam code for sneaky.erl Now you define run() in sneaky.erl as run() -> init:eval_script([{path,["$ROOT/lib/kernel/ebin"]}, {primLoad,[application, application_controller, ... Or whatever :-) [It's not quite as simple as this but you get the idea] Once sneaky has terminated you get the old behaviour - *but* you can embedd any code you like into the .boot file - so the complete application can (if you like) be distributed as a single boot file, and to run it you say erl -boot BootFile Since the bootfile can access the command line arguments, you can then expand the system in an arbitrary manner erl -boot Boot1 abc.ear .... and then turn the whole thing into a single executable ... /Joe > > Of course, _reading_ start.script would be a bit more tiring if > all the beam code were embedded -- kindof defeats the purpose of > having a text representation... I'm sure this can be solved > elegantly. > > /Uffe > From thomas.lindgren@REDACTED Thu Apr 25 15:12:44 2002 From: thomas.lindgren@REDACTED (Thomas Lindgren) Date: Thu, 25 Apr 2002 15:12:44 +0200 Subject: Simple xref question In-Reply-To: Message-ID: > How can I find all functions in the standard system that call >a given function {Mod,Func,Arity}? > > Is their a one-liner to do this? You can pass the option {use, MFAs} to 'analyze' once you have the analyzer running, it seems. Alas, I don't think apply/spawn is handled the way one wants. (They are treated as "unresolved calls" in general.) This is annoying so here is a proposal for Son of Erlang: new directives. -export([f/n, ...]). -apply([f/n, ...]). -spawn([f/n, ...]). An -export means the functions can be called remotely, mod:f(...). An -apply means the functions can be invoked by apply. A -spawn means the functions can be spawned. There are two advantages to this: 1. Programmers can ensure that a function only can be called directly, by ONLY -export:ing it, which means xref will find all references to it. 2. No need for the "internal exports" that dot the code, e.g., when one needs to spawn certain servers. If f/n is -spawn declared but not -export:ed, then it will not be visible to the outside. I think such an extension (though non-compatible, since -export does all three today) would clean up some annoyances, remove some queer coding practices and generally usher in an era of utopical bliss. -- Thomas From joe@REDACTED Thu Apr 25 15:59:18 2002 From: joe@REDACTED (Joe Armstrong) Date: Thu, 25 Apr 2002 15:59:18 +0200 (CEST) Subject: Simple xref question In-Reply-To: Message-ID: On Thu, 25 Apr 2002, Thomas Lindgren wrote: > > How can I find all functions in the standard system that call > >a given function {Mod,Func,Arity}? > > > > Is their a one-liner to do this? > > You can pass the option {use, MFAs} to 'analyze' once you have the analyzer > running, it seems. Alas, I don't think apply/spawn is handled the way one > wants. (They are treated as "unresolved calls" in general.) > That much I had understood - Is there a convenient way of loading every module in the system prior to doing the analysis?? BTW to my relief I find there are a few undocumented functions in xref.erl namely, analyse/2 and analyse/3 that can be used instead of analyze/2 and analyze/3. > This is annoying so here is a proposal for Son of Erlang: new directives. > > -export([f/n, ...]). > -apply([f/n, ...]). > -spawn([f/n, ...]). > > An -export means the functions can be called remotely, mod:f(...). > An -apply means the functions can be invoked by apply. > A -spawn means the functions can be spawned. > > There are two advantages to this: > > 1. Programmers can ensure that a function only can be called > directly, by ONLY -export:ing it, which means xref will find all > references to it. > > 2. No need for the "internal exports" that dot the code, e.g., when > one needs to spawn certain servers. If f/n is -spawn declared > but not -export:ed, then it will not be visible to the outside. > > I think such an extension (though non-compatible, since -export does all > three today) would clean up some annoyances, remove some queer coding > practices and generally usher in an era of utopical bliss. Utopical bliss indeed - what a cornucopic joy your postings are. /Joe > > -- Thomas > > From hal@REDACTED Thu Apr 25 16:31:25 2002 From: hal@REDACTED (Hal Snyder) Date: 25 Apr 2002 09:31:25 -0500 Subject: Starting Erlang In-Reply-To: (Miguel Barreiro Paz's message of "Thu, 25 Apr 2002 13:53:06 +0200 (CEST)") References: Message-ID: <87u1pzsvcy.fsf@gamera.vail> Miguel Barreiro Paz writes: > The problem with NFS is that upon network failures tends to behave > in rather unpredictable ways, from clean unmounting to mounts > hanging or not recovering for an extremely long time (and thus > processes with their cwd or open descriptors on that filesystem > either hanging or dying)... Agreed. All too often, NFS turns small failures into large ones. And it thereby introduces a single point of failure into a nicely distributed OTP system, no? From per@REDACTED Thu Apr 25 21:59:53 2002 From: per@REDACTED (Per Bergqvist) Date: Thu, 25 Apr 2002 20:59:53 +0100 Subject: Starting Erlang In-Reply-To: Message-ID: <200204251859.g3PIxsr22763@vargen.levonline.com> > > >> Please please please make .ear be a standard (e.g. POSIX) archive > >> format, usable by standard tools (e.g. tar/cpio/pax). > >> The world doesn't need Yet Another Pointless Archive Format(TM). > >> > >> /Mikael > > > > Ummm - It's not clear to me the advantages of following a standard > >format outweigh the advantages of using a non-standard format.... > > > > Since I expect an Erlang program to produce the YAPAF file and > >another Erlang program to consume the YAPAF I don't see why it matters > >what the format is. A symmetric pair of term_to_binary and > >binary_to_term calls is all that is needed - not exactly complex code. > > If there is any interest, I have not one but two .ear formats with > encoder/decoders :-) Yes, they are YAPAFs, but straightforward ones.(On the > bright side, I have archived and installed the entire OTP .beam collection > with both. On Solaris and Linux.) > > The main advantage of doing it in Erlang is portability, hence availability. > (This doesn't argue for a YAPAF, of course, since we could implement some > well-known format in Erlang.) We can use the same code on Windows and > VxWorks as on various Unices. (Using a YAPAF, we also get the double-edged > sword of flexibility :-) > > -- Thomas > As we discussed before Thomas, I think that support for other resources than .beam files should be supported (i.e. loadable drivers but make it generic). Support for different architectures in parallell should be included. Next had this with its fat binaries. (It also had utilities to slim the binaries ;-) BTW, Lack of support for other files is than .beam files is what makes the network bootloader useless. /PER ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From mbj@REDACTED Thu Apr 25 21:21:12 2002 From: mbj@REDACTED (Martin Bjorklund) Date: Thu, 25 Apr 2002 21:21:12 +0200 (CEST) Subject: Starting Erlang In-Reply-To: <200204251859.g3PIxsr22763@vargen.levonline.com> References: <200204251859.g3PIxsr22763@vargen.levonline.com> Message-ID: <20020425.212112.78708502.mbj@bluetail.com> Per Bergqvist wrote: > As we discussed before Thomas, I think that support for other > resources than .beam files should be supported (i.e. loadable drivers > but make it generic). Very good point! Also external port programs and data files. I fixed this for the R7 SAE that Joe did (I sent that to you Joe). We're using this modified SAE to distribute RPMs (one with sae itself, one for the app). The main thing that needs to be done if you don't want to modify existing code is to support code:priv_dir/1. In my modification I added that function to Joe's simple code.erl and let each RPM package install it's priv dir into /usr/local/lib/erlsae/AppName/priv/. The reason for this was that existing code usually calls priv_dir/1 and then use the file.erl functions to read the files. Of course it would be even better if you could provide a new API for application specific files which is not dependent on the local filesystem (or maybe add a new filedescriptor so the existing file.erl functions could be used).. /martin From fritchie@REDACTED Fri Apr 26 06:24:57 2002 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 25 Apr 2002 23:24:57 -0500 Subject: Starting Erlang In-Reply-To: Message of "25 Apr 2002 09:31:25 CDT." <87u1pzsvcy.fsf@gamera.vail> Message-ID: <200204260424.g3Q4Ov857620@snookles.snookles.com> >>>>> "hs" == Hal Snyder writes: hs> Miguel Barreiro Paz writes: >> The problem with NFS is that upon network failures tends to behave >> in rather unpredictable ways, [...] hs> All too often, NFS turns small failures into large ones. And it hs> thereby introduces a single point of failure into a nicely hs> distributed OTP system, no? No. At least, not the OTP system that I worked on at my last gig. But then again, we implemented the NFS client in Erlang and chose quite intentionally not to implement the braindamaged behavior that most UNIX kernels have evolved and that no one (myself included) has bothered To Do a Better Way. :-) To be fair, that work also meant making the applications aware that their "disk" operations might fail. Many developers treat the file system like the ancients regarded fish in the sea: it's just there. Developers that do check file op errors almost never do it with the mindset of, "Oh, that one might be only temporary." So, most UNIX flavors try to hide from user space apps the funky & weird things can (and do) happen regularly to networks. The mishmash result, without a doubt, sucks. Having said all that malicious and quite true stuff about kernel NFS client implementations ... If you have decent & sane ways of dealing with network errors, there are several NFS servers that have had dozens of person years spent on them to be able to move huge amounts of data across a network very quickly.... -Scott From thomas.lindgren@REDACTED Fri Apr 26 10:48:03 2002 From: thomas.lindgren@REDACTED (Thomas Lindgren) Date: Fri, 26 Apr 2002 10:48:03 +0200 Subject: Starting Erlang In-Reply-To: <200204251859.g3PIxsr22763@vargen.levonline.com> Message-ID: >As we discussed before Thomas, I think that support for other >resources than .beam files should be supported (i.e. loadable drivers >but make it generic). Support for different architectures in parallell >should be included. >Next had this with its fat binaries. >(It also had utilities to slim the binaries ;-) > >BTW, Lack of support for other files is than .beam files is what makes >the network bootloader useless. Yes, good point. After you mentioned it last time, I wrote some code to take care of that problem. Nominally, the archivers (at least one of them) support archiving and installing non-beam files as well, in particular drivers. I haven't had the opportunity to check that it really works, though. Nor that it works the Right Way. (The development of those .ear programs was driven by listening to Per, in case anyone wonders :-) -- Thomas From joe@REDACTED Fri Apr 26 16:21:00 2002 From: joe@REDACTED (Joe Armstrong) Date: Fri, 26 Apr 2002 16:21:00 +0200 (CEST) Subject: xref Message-ID: Does anybody know anything about xref??? I want to do a very simple thing. Load kernel and stdlib into xref and ask for a listing of all calls to a particular {Mode,Func,Arity} I *thought* that this should be simple. Step one: loading the code ... I tryed go() -> {ok, P} = xref:start(a), add_libs(P, libs()), xref:stop(P). add_libs(P, L) -> foreach(fun(I) -> Dir = code:lib_dir(stdlib) ++ "/ebin", io:format("adding:~p~n", [Dir]), X = xref:add_directory(P, Dir, [{verbose,true}]), io:format("X=~p~n", [X]) end, L). libs() -> [stdlib, kernel]. This produces the following error: beam_lib: 1 unresolved call X={error,xref_base, {module_clash, {beam_lib, "/home/joe/installed/otp_src_R8B-0/lib/stdlib/ebin/beam_lib.beam", "/home/joe/installed/otp_src_R8B-0/lib/stdlib/ebin/beam_lib.beam"}}} The manual page does not document the meaning of this error. *what does this error mean* /Joe From peter@REDACTED Fri Apr 26 19:24:39 2002 From: peter@REDACTED (Peter H|gfeldt) Date: Fri, 26 Apr 2002 19:24:39 +0200 (MET DST) Subject: xref In-Reply-To: Message-ID: On Fri, 26 Apr 2002, Joe Armstrong wrote: You just made a very trivial programming error: > > Does anybody know anything about xref??? > > I want to do a very simple thing. > > Load kernel and stdlib into xref and ask for a listing of all calls > to a particular {Mode,Func,Arity} > > I *thought* that this should be simple. > > Step one: loading the code ... I tryed > > go() -> > {ok, P} = xref:start(a), > add_libs(P, libs()), > xref:stop(P). > > add_libs(P, L) -> > foreach(fun(I) -> > Dir = code:lib_dir(stdlib) ++ "/ebin", ^^^^^^ Dir = code:lib_dir(I) ++ "/ebin", > io:format("adding:~p~n", [Dir]), > X = xref:add_directory(P, Dir, [{verbose,true}]), > io:format("X=~p~n", [X]) > end, L). > > libs() -> > [stdlib, kernel]. > > This produces the following error: > > beam_lib: 1 unresolved call > X={error,xref_base, > {module_clash, > {beam_lib, > "/home/joe/installed/otp_src_R8B-0/lib/stdlib/ebin/beam_lib.beam", > "/home/joe/installed/otp_src_R8B-0/lib/stdlib/ebin/beam_lib.beam"}}} > > The manual page does not document the meaning of this error. > > *what does this error mean* > > /Joe /Peter From kostis@REDACTED Fri Apr 26 19:41:51 2002 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 26 Apr 2002 19:41:51 +0200 (MET DST) Subject: xref In-Reply-To: Mail from 'Peter H|gfeldt ' dated: Fri, 26 Apr 2002 19:24:39 +0200 (MET DST) Message-ID: <200204261741.TAA27490@harpo.it.uu.se> Peter H|gfeldt wrote: > > On Fri, 26 Apr 2002, Joe Armstrong wrote: > > You just made a very trivial programming error: > > > add_libs(P, L) -> > > foreach(fun(I) -> > > Dir = code:lib_dir(stdlib) ++ "/ebin", > ^^^^^^ > Dir = code:lib_dir(I) ++ "/ebin", Coming from a Prolog background, it never ceases to amaze me why the Erlang compiler (and experienced Erlang programmers) insist on having singleton variable warnings turned off... Kostis. From sbello4@REDACTED Fri Apr 26 19:16:08 2002 From: sbello4@REDACTED (bello sankoh) Date: Fri, 26 Apr 2002 19:16:08 GMT+1 Subject: CONFIDENCE Message-ID: <1019841368026709@caramail.com> ATTN:MANAGER HELLO DEAR, I am well confidence of your capability to assist me in a transaction for mutual benefit for both parties, ie (me and you) I am also believing that you will not expose or betray the trust and confidence I am about to establish on you. I have decided to contact you with greatest delight and personal respect. Well, I am BELLO SANKOH, Son to MR FODAY SANKOH who was arrested by the ECOMAOG PEACE KEEPING FORCE months ago in my country Sierra Leone. Few days before the arrest of my father, he confided in me and ordered me to go to his underground safe and move out immediately, with a Deposit Agreement and Cash Receipt he made with a security Company in Abidjan Cote d?Ivoire where he deposited One Iron Box containing USD$ 22 million dollars cash (Twenty Two Million dollars cash). This money was made from the sell of Gold and Diamond by my FATHER and he have already decided to use this money for future investment of the family before his arrest. Thereafter, I rushed down to Abidjan with these documents and confirmed the deposit of the box by my father. Also, I have been granted political stay as a Refugee by the Government of C?te d?Ivoire. Meanwhile, my father have instructed me to look for a trusted foreigner who can assist me to move out this money from C?te d?Ivoire immediately for investment . Based on this , I solicit for your assistance to transfer this fund into your Account, but I will demand for the following requirement: (1) Could you provide for me a safe Bank Account where this fund will be transferred to in your country or another nearby country where taxation will not take great toll on the money? (2) Could you be able to assist me to obtain my travelling papers after this transfer to enable me come over to meet you in your country for the investment of this money? (3) Could you be able to introduce me to a profitable business venture that would not require much technical expertise in your country where part of this fund will be invested? Please, all these requirements are urgently needed as it will enable me to establish a stronger business relationship with you hence I will like you to be the general overseer of the investment thereafter. I am a Christian and I will please, want you to handle this transaction based on the trust I have established on you. For your assistance in this transaction, I have decided to offer you 12% percent commission of the total amount ( 22 million dollars ) at the end of this business. The security of this business is very important to me and as such, I would like you to keep this business very confidential. I shall expect your urgent reply. My telephone number is 22507625348. Thank you and God bless you BELLO SANKOH Tel :22507625348 ______________________________________________________ Envoyez des messages musicaux sur le portable de vos amis http://mobile.lycos.fr/mobile/local/sms_musicaux/ ______________________________________________________ Bo?te aux lettres - Caramail - http://www.caramail.com From sbello4@REDACTED Fri Apr 26 19:16:08 2002 From: sbello4@REDACTED (bello sankoh) Date: Fri, 26 Apr 2002 19:16:08 GMT+1 Subject: CONFIDENCE Message-ID: <1019841368026709@caramail.com> ATTN:MANAGER HELLO DEAR, I am well confidence of your capability to assist me in a transaction for mutual benefit for both parties, ie (me and you) I am also believing that you will not expose or betray the trust and confidence I am about to establish on you. I have decided to contact you with greatest delight and personal respect. Well, I am BELLO SANKOH, Son to MR FODAY SANKOH who was arrested by the ECOMAOG PEACE KEEPING FORCE months ago in my country Sierra Leone. Few days before the arrest of my father, he confided in me and ordered me to go to his underground safe and move out immediately, with a Deposit Agreement and Cash Receipt he made with a security Company in Abidjan Cote d?Ivoire where he deposited One Iron Box containing USD$ 22 million dollars cash (Twenty Two Million dollars cash). This money was made from the sell of Gold and Diamond by my FATHER and he have already decided to use this money for future investment of the family before his arrest. Thereafter, I rushed down to Abidjan with these documents and confirmed the deposit of the box by my father. Also, I have been granted political stay as a Refugee by the Government of C?te d?Ivoire. Meanwhile, my father have instructed me to look for a trusted foreigner who can assist me to move out this money from C?te d?Ivoire immediately for investment . Based on this , I solicit for your assistance to transfer this fund into your Account, but I will demand for the following requirement: (1) Could you provide for me a safe Bank Account where this fund will be transferred to in your country or another nearby country where taxation will not take great toll on the money? (2) Could you be able to assist me to obtain my travelling papers after this transfer to enable me come over to meet you in your country for the investment of this money? (3) Could you be able to introduce me to a profitable business venture that would not require much technical expertise in your country where part of this fund will be invested? Please, all these requirements are urgently needed as it will enable me to establish a stronger business relationship with you hence I will like you to be the general overseer of the investment thereafter. I am a Christian and I will please, want you to handle this transaction based on the trust I have established on you. For your assistance in this transaction, I have decided to offer you 12% percent commission of the total amount ( 22 million dollars ) at the end of this business. The security of this business is very important to me and as such, I would like you to keep this business very confidential. I shall expect your urgent reply. My telephone number is 22507625348. Thank you and God bless you BELLO SANKOH Tel :22507625348 ______________________________________________________ Envoyez des messages musicaux sur le portable de vos amis http://mobile.lycos.fr/mobile/local/sms_musicaux/ ______________________________________________________ Bo?te aux lettres - Caramail - http://www.caramail.com From rusmufti@REDACTED Fri Apr 26 20:55:47 2002 From: rusmufti@REDACTED (Joerg Scheurich aka MUFTI) Date: Fri, 26 Apr 2002 20:55:47 +0200 (CEST) Subject: Compile with "-Wall" Message-ID: Hi ! I try to compile otp_src_R8B-1 with a compiler other than gcc. One of its problems it the "-Wall" option, which is only supported on gcc. It occures in ./lib/ic/examples/c-server/Makefile ./lib/ic/examples/all-against-all/Makefile ./lib/ic/examples/c-client/Makefile but it looks like, it is also used in .erl files like ./lib/ic/src/icgen.erl:1647:allowed_opt('Wall', V) and so on. so long MUFTI -- Wenn Sie ein Videospiel benutzen, das am Bildschirm angeschlossen ist, sollten Sie entsprechend der Anschlusskabellaenge Abstand vom Bildschirm halten. (Aus dem Handbuch einer Nvidia MX2 Graphikkarte von Elsa) From hakan.stenholm@REDACTED Sat Apr 27 20:41:43 2002 From: hakan.stenholm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Stenholm?=) Date: Sat, 27 Apr 2002 20:41:43 +0200 Subject: Compile with "-Wall" Message-ID: <6B835840-5A0E-11D6-B8A8-003065B5F8B4@mbox304.swipnet.se> >Hi ! > >I try to compile otp_src_R8B-1 with a compiler other than gcc. > >One of its problems it the "-Wall" option, which is only supported >on gcc. > >It occures in > >./lib/ic/examples/c-server/Makefile >./lib/ic/examples/all-against-all/Makefile >./lib/ic/examples/c-client/Makefile > >but it looks like, it is also used in .erl files like > >./lib/ic/src/icgen.erl:1647:allowed_opt('Wall', V) > >and so on. One possible solution (or hack) would be to create a mini gcc, a small application or shell script that maps or discards gcc compiler flags and replaces them with what your compiler uses i.e. converts calls to gcc to calls to "other complier". From georges.picard@REDACTED Sun Apr 28 04:16:44 2002 From: georges.picard@REDACTED (Georges PICARD) Date: Sun, 28 Apr 2002 04:16:44 +0200 Subject: No subject Message-ID: <25909200240282164469@tiscali.fr> From Sean.Hinde@REDACTED Mon Apr 29 10:59:55 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 29 Apr 2002 09:59:55 +0100 Subject: xref Message-ID: <402DD461F109D411977E0008C791C312039F6A96@imp02mbx.one2one.co.uk> > > Peter H|gfeldt wrote: > > > > On Fri, 26 Apr 2002, Joe Armstrong wrote: > > > > You just made a very trivial programming error: > > > > > add_libs(P, L) -> > > > foreach(fun(I) -> > > > Dir = code:lib_dir(stdlib) ++ "/ebin", > > ^^^^^^ > > Dir = code:lib_dir(I) ++ "/ebin", > > > Coming from a Prolog background, it never ceases to amaze me why > the Erlang compiler (and experienced Erlang programmers) insist > on having singleton variable warnings turned off... Could it be because they are almost undocumented? All I could find was a mention in the compiler release notes and an entry in erl_lint (which I have never even opened before, and probably wouldn't if it didn't appear in a documentation search on "warn_unused_vars") Perhaps R9 will bring a list of ALL useful compiler flags into the COMPILER documentation. Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From joe@REDACTED Mon Apr 29 12:10:20 2002 From: joe@REDACTED (Joe Armstrong) Date: Mon, 29 Apr 2002 12:10:20 +0200 (CEST) Subject: Shock horror Message-ID: Complexity Shock Horror .... I have found to my horror and amazement that that our beloved Erlang system is far more complex than it should be ... ... it all started when I started reading systools.erl ... Warning - timid souls should not read on for this is a tale of horror that will chill your very entrails and make you doubt your sanity .... (scroll the page for more) I wanted to change systools:script2boot/1 Now this function calls systools_lib:file_term2binary/2 and I could not understand why the code for this had been placed in a *different* module - surely *nobody* would want to call systools_lib:file_term2binary/2 - it's so obscure that nobody would ever think to use it. And it's not even documented (systools_lib) has no man pages - so the chances that anybody would ever even think of using this function are minuscule. I thought to myself - "I'll do a Xref analysis to find out if anybody calls systools_lib:file_term2binary/2" - this turned out to be more difficult than I had imagined - xref once small and easy to use has grown in complexity since I last used it to the point where it is almost (but not quite) impossible to use. <> After a few false starts and guesses to what xref did I was able to analyse the system to see who called "systools_lib:file_term2binary/2" - and my intuition was correct: systools_lib:file_term2binary/2 is only called from systools.erl Now I might be completely "out and cycling" here (as my Swedish friends would say) - but IMMVHO (Most very :-) if it is the case that only one other module calls an exported function then the function could be MOVED to the place from whence it was called. A case of "Whither wert tho called oh systools_lib:file_term2binary/2? "From only systools.erl" "Then go ye thence" So I thought to myself - How many exported functions are "singletons" (by that I means functions which are only called from one external module) - To answer this I wrote a little program... During the writing, thereof, I discovered that there were not only a large number of singletons (I had hoped that I had stumbled across the only one) but also a large number of "nollitons" - exported functions that *nobody* calls. For your edification and delight, the numbers are: #exported functions = 8148 4632 functions do not need to be exported (nollitons) 2225 functions can be moved (singletons) 1291 functions cannot be moved Pretty stinky stuff, ej wot. IMHO every time a nolliton or singleton is used the system become more difficult to understand and more difficult to structure and more difficult optimise - "module at a time" compilers do not like external functions - and thinking up sensible names for them is a pain in the nether regions. Even worse I don't even know if we can remove the buggers - perhaps (horrors) some application actually calls an undocumented nolliton - removing (say) all nollitons might awaken the the great God of backwards incompatibility - their might be much gnashing and grinding of teeth and wailing and crying if we did this ... Before the age utopic bliss is achieved (thank you Thomas) we could perhaps check to see if any of the BIG applications call the nasty little nollitons and singletons ... Do they? Run the enclosed program to see (adding you own own application modules to the set of stuff that is analysed) /Joe PS cannot anything be done about this, apart from a total re-write using Richards heirarchical module system (which I guess we should do at the same time :-) -------------- next part -------------- -module(anal). -compile(export_all). -import(lists, [foldl/3, foreach/2, map/2, member/2, sort/1]). %% anal:go(all) %% runs the analysis libs(small) -> [stdlib, kernel, sasl]; libs(all) -> [erl_interface,mnemosyne,sasl,appmon,eva,mnesia,snmp,asn1, gs,mnesia_session,ssl,odbc,stdlib,compiler,ic,toolbar, inets,os_mon,tools,parsetools,tv,debugger,kernel,pman, runtime_tools]. go(Type) -> {ok, P} = xref:start(a), add_libs(P, libs(Type)), R = xref:analyse(P, {use, {code, lib_dir, 1}}, []), io:format("R=~p~n",[R]), R1 = xref:analyse(P, {use, {systools_lib, file_term2binary, 2}}, []), Mods = map(fun({I,_}) -> I end, xref:info(P, modules)), io:format("Mods=~p~n",[Mods]), L1 = foldl(fun(Mod, A) -> Exports = Mod:module_info(exports), Exports1 = remove_module_info(Exports), foldl(fun({Func, Arity}, A0) -> MFA = {Mod, Func, Arity}, case xref:analyse(P,{use, MFA}) of {ok, L} -> Tup = {MFA, L}, [Tup|A0]; Other -> io:format("uugh:~p~n",[Other]), A0 end end, A, Exports1) end, [], Mods), io:format("L1=~p~n",[L1]), L2 = compute_complexity(L1), {ok, S} = file:open("anal_result.tmp", write), io:format(S, "~p~n",[L2]), file:close(S), xref:stop(P). %% The completity of aan exported function = %% #Emods = the number of external modules %% that call the function %% We want to compute the following %% The number of functions that should not be exported %% = (the number of fucntions that should not be exported) compute_complexity(L) -> %% Each exported function counts 1 Cinit = length(L), io:format("Current complexity= ~p~n", [Cinit]), L1 = map(fun({{M,F,A}, La}) -> {{M,F,A}, external_exports(M, La, [])} end, L), %% The function which do not need to be exported L2 = [MFA||{MFA, []} <- L1], io:format("~w functions do not need to be exported~n", [length(L2)]), L3 = [MFA||{MFA, [X]} <- L1], io:format("~w functions can be moved~n", [length(L3)]), L4 = [MFA||{MFA, X} <- L1, length(X) > 1], io:format("~w functions cannot be moved~n", [length(L4)]), L5 = sort(map(fun({MFA,E}) -> {length(E), MFA, E} end, L1)). remove_module_info([{module_info,_}|T]) -> remove_module_info(T); remove_module_info([H|T]) -> [H|remove_module_info(T)]; remove_module_info([]) -> []. external_exports(M, [{M,F,A}|T], External) -> external_exports(M, T, External); external_exports(M1, [{M2,F,A}|T], External) -> case member(M2, External) of true -> external_exports(M1, T, External); false -> external_exports(M1, T, [M2|External]) end; external_exports(M, [], E) -> E. complexity(Mod, [{Mod,_,_}|T]) -> complexity(Mod, T); complexity(Mod, [H|T]) -> [H|complexity(Mod, T)]; complexity(Mod, []) -> []. add_libs(P, L) -> foreach(fun(I) -> Dir = code:lib_dir(I) ++ "/ebin", io:format("adding:~p~n", [Dir]), X = xref:add_directory(P, Dir, [{verbose,false}]), io:format("X=~p~n", [X]) end, L). From thomas@REDACTED Mon Apr 29 12:24:55 2002 From: thomas@REDACTED (Thomas Arts) Date: Mon, 29 Apr 2002 12:24:55 +0200 Subject: Shock horror References: Message-ID: <3CCD1F77.31C6A296@cslab.ericsson.se> Joe Armstrong wrote: > > Complexity Shock Horror .... > > I have found to my horror and amazement that that our beloved > Erlang system is far more complex than it should be ... > > ... it all started when I started reading systools.erl ... > > Warning - timid souls should not read on for this is a tale of > horror that will chill your very entrails and make you doubt your sanity I was brave enough to scroll... > During the writing, thereof, I discovered that there were not only a > large number of singletons (I had hoped that I had stumbled across the > only one) but also a large number of "nollitons" - exported functions > that *nobody* calls. > > For your edification and delight, the numbers are: > > #exported functions = 8148 > 4632 functions do not need to be exported (nollitons) > 2225 functions can be moved (singletons) > 1291 functions cannot be moved > > Pretty stinky stuff, ej wot. But not the nollitons. If you write a library, you write it for the nollitons! Users are going to call these functions. calender:date_to_greorgian_date/1 may be a nollition, it is supposed to be that. Thus, the concern are the nollitons and singletons not in the manual pages, they are the really uglies... You are not going to tell me that you checked all manual entires for the 8148 functions, did you? Cheers Thomas From eleberg@REDACTED Mon Apr 29 12:33:32 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Mon, 29 Apr 2002 12:33:32 +0200 (MET DST) Subject: xref Message-ID: <200204291033.g3TAXWU21731@cbe.ericsson.se> > From: Sean Hinde > > > > Peter H|gfeldt wrote: > > ...deleted > > > > Coming from a Prolog background, it never ceases to amaze me why > > the Erlang compiler (and experienced Erlang programmers) insist > > on having singleton variable warnings turned off... > > Could it be because they are almost undocumented? All I could find was a > mention in the compiler release notes and an entry in erl_lint (which I have > never even opened before, and probably wouldn't if it didn't appear in a > documentation search on "warn_unused_vars") > > Perhaps R9 will bring a list of ALL useful compiler flags into the COMPILER > documentation. an inexperienced user is the kind of person that will benefit most from compiler warnings. aforementioned inexperience makes this the least likely person to be able to turn them on. therefore: compiler warnings should be turned _on_ by default experienced programmers that know what they are doing can turn them off when needed. bengt From joe@REDACTED Mon Apr 29 12:44:51 2002 From: joe@REDACTED (Joe Armstrong) Date: Mon, 29 Apr 2002 12:44:51 +0200 (CEST) Subject: Shock horror In-Reply-To: <3CCD1F77.31C6A296@cslab.ericsson.se> Message-ID: On Mon, 29 Apr 2002, Thomas Arts wrote: > Joe Armstrong wrote: > > > > Complexity Shock Horror .... > > > > I have found to my horror and amazement that that our beloved > > Erlang system is far more complex than it should be ... > > > > ... it all started when I started reading systools.erl ... > > > > Warning - timid souls should not read on for this is a tale of > > horror that will chill your very entrails and make you doubt your sanity > > I was brave enough to scroll... > > > During the writing, thereof, I discovered that there were not only a > > large number of singletons (I had hoped that I had stumbled across the > > only one) but also a large number of "nollitons" - exported functions > > that *nobody* calls. > > > > For your edification and delight, the numbers are: > > > > #exported functions = 8148 > > 4632 functions do not need to be exported (nollitons) > > 2225 functions can be moved (singletons) > > 1291 functions cannot be moved > > > > Pretty stinky stuff, ej wot. > > But not the nollitons. If you write a library, you write it for the > nollitons! Users are going to call these functions. > calender:date_to_greorgian_date/1 may be a nollition, it is supposed to > be that. Yes, silly me ... :-) I was just overwhelmed by horror :-) A quick peep gives the impression that there is a lot of obscure junk that never should have been written (mea culpa) never have beeen exported and should never be called. The problem is that some of the nollotons are so obscure that that should never have been exported - my feeling is that a lot of them are exported just to allow spawn to work - a hang back to the days before spawn(Fun). I'd really like to know which nollitons are not called by a major application - these are canditates for removal. The problem with systems is not adding new stuff - it's removing old junk that is never used. > > Thus, the concern are the nollitons and singletons not in the manual > pages, they are the really uglies... You are not going to tell me > that you checked all manual entires for the 8148 functions, did you? No - whould that I could - that would require a tighter integration of the documentaion and code than is used today. Hopefully this will be improved in "son of Erlang". > > Cheers > Thomas > /Joe From Sean.Hinde@REDACTED Mon Apr 29 13:00:22 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 29 Apr 2002 12:00:22 +0100 Subject: xref Message-ID: <402DD461F109D411977E0008C791C312039F6AA1@imp02mbx.one2one.co.uk> > > > From: Sean Hinde > > > > > > > Peter H|gfeldt wrote: > > > > ...deleted > > > > > > Coming from a Prolog background, it never ceases to amaze me why > > > the Erlang compiler (and experienced Erlang programmers) insist > > > on having singleton variable warnings turned off... > > > > Could it be because they are almost undocumented? All I > could find was a > > mention in the compiler release notes and an entry in > erl_lint (which I have > > never even opened before, and probably wouldn't if it > didn't appear in a > > documentation search on "warn_unused_vars") > > > > Perhaps R9 will bring a list of ALL useful compiler flags > into the COMPILER > > documentation. > > an inexperienced user is the kind of person that will benefit > most from > compiler warnings. aforementioned inexperience makes this the least > likely person to be able to turn them on. > > therefore: > compiler warnings should be turned _on_ by default > > experienced programmers that know what they are doing can turn them > off when needed. Yes. I meant to add this suggestion also. I wonder who the "aforementioned inexperience" was aimed at :) Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From eleberg@REDACTED Mon Apr 29 13:09:17 2002 From: eleberg@REDACTED (Bengt Kleberg) Date: Mon, 29 Apr 2002 13:09:17 +0200 (MET DST) Subject: xref Message-ID: <200204291109.g3TB9HU08349@cbe.ericsson.se> > From: Sean Hinde ...deleted > Yes. I meant to add this suggestion also. I wonder who the "aforementioned > inexperience" was aimed at :) mostly at myself. secondly to others that are inexperienced. especially not to Sean Hinde and others that send informative answers to erlang-questions. bengt From etxuwig@REDACTED Mon Apr 29 13:26:22 2002 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 29 Apr 2002 13:26:22 +0200 (MET DST) Subject: Shock horror In-Reply-To: Message-ID: On Mon, 29 Apr 2002, Joe Armstrong wrote: >On Mon, 29 Apr 2002, Thomas Arts wrote: >> Thus, the concern are the nollitons and singletons not in the >> manual pages, they are the really uglies... You are not going >> to tell me that you checked all manual entires for the 8148 >> functions, did you? > > No - whould that I could - that would require a tighter >integration of the documentaion and code than is used today. >Hopefully this will be improved in "son of Erlang". Some analysis can be made, through some rather perverted processing of the on-line documentation. I included some support in CCviewer for that, as I implemented a function to lookup all external calls to exported functions in a lib. I thought it might be useful to indicate if a called function was undocumented. My approach was to scan the HTML for e.g (which BTW doesn't exist in mnesia.html, even though mnesia:activity/2 is a documented exported function). The documentation is not quite consistent to this level of detail, but most of the time, it produces the expected results. The decidedly cludgey code is presented below, if you want to reuse it. /Uffe process_body(Str, Mod, Tab) -> process_body(Str, Mod, Tab, false). process_body(" case scan_name(T) of {Name, NameStr, Arity, Rest} -> case Rest of ">" ++ T1 -> case lists:prefix(NameStr ++ "(", T1) of true -> ets:insert(Tab, {{Mod, list_to_atom(Name), Arity}, interface}), process_body(T1, Mod, Tab, true); false -> ?dbg("~p (~p) not a prefix of ~p~n", [NameStr, Mod, lists:sublist(T1, 1, 10)]), process_body(T1, Mod, Tab, Flag) end; _ -> ?dbg("Rest (~p) was ~p~n", [Mod, lists:sublist(Rest, 1, 10)]), process_body(Rest, Mod, Tab, Flag) end; {false, Rest} -> process_body(Rest, Mod, Tab, Flag) end; process_body([H|T], Mod, Tab, Flag) -> process_body(T, Mod, Tab, Flag); process_body([], Mod, Tab, Flag) -> Flag. scan_name("erlang:" ++ [H|T]) when H>=$a, H=<$z -> %% Some BIFs are not auto-exported scan_name(T, [H], [H|":gnalre"]); scan_name([H|T]) when H>=$a, H=<$z -> scan_name(T, [H], [H]); scan_name("'" ++ T) -> scan_name(T, [$'], ";sopa&"); scan_name("'" ++ T) -> scan_name(T, [$'], ";93#&"); scan_name("Module:" ++ T) -> %% This is a definition of a behaviour callback function -- skip {false, T}; scan_name(Other) -> {false, Other}. scan_name([$"|T], Acc, StrAcc) -> {false, T}; scan_name("'%" ++ [H|T], Acc, StrAcc) when H>=$0, H=<$9 -> Name = lists:reverse([$'|Acc]), NameStr = lists:reverse(";sopa&" ++ Acc), scan_arity(T, Name, NameStr, [H]); scan_name("'%" ++ [H|T], Acc, StrAcc) when H>=$0, H=<$9 -> case lists:reverse([$'|Acc]) of Name = [$'|_] -> NameStr = lists:reverse(";93#&" ++ Acc), scan_arity(T, Name, NameStr, [H]); _ -> {false, T} end; scan_name("%" ++ [H|T], Acc, StrAcc) when H>=$0, H=<$9 -> Name = lists:reverse(Acc), NameStr = lists:reverse(StrAcc), scan_arity(T, Name, NameStr, [H]); scan_name([H|T], Acc, StrAcc) -> scan_name(T, [H|Acc], [H|StrAcc]); scan_name([], Acc, StrAcc) -> {false, []}. scan_arity([H|T], Name, NameStr, Acc) when H>=$0, H=<$9 -> scan_arity(T, Name, NameStr, [H|Acc]); scan_arity([$"|T], Name, NameStr, Acc) -> {Name, NameStr, list_to_integer(Acc), T}; scan_arity([], Name, NameStr, Acc) -> {false, []}. -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From mbj@REDACTED Mon Apr 29 13:46:07 2002 From: mbj@REDACTED (Martin Bjorklund) Date: Mon, 29 Apr 2002 13:46:07 +0200 (CEST) Subject: Shock horror In-Reply-To: References: Message-ID: <20020429.134607.74740061.mbj@bluetail.com> Joe Armstrong wrote: > Now this function calls > > systools_lib:file_term2binary/2 > > and I could not understand why the code for this had been placed in > a *different* module - surely *nobody* would want to call > systools_lib:file_term2binary/2 - it's so obscure that nobody would > ever think to use it. And it's not even documented (systools_lib) has > no man pages - so the chances that anybody would ever even think of > using this function are minuscule. I can't answer for that particular function, but surely you can't mean that singletons are so bad? One case that someone mentioned is when a function is part of the documented API. Another case is when you structure you're application in a set of modules, with just one (or a few) "exported" modules. The rest of the modules are internal. An example of a singelton function could be a function which encapsulates a call to an internal server. Another example would be when a function (which is called just once) logically belongs to a specific module. Of course a better module system could make things look better, but personally I don't think it's a big deal. /martin From Sean.Hinde@REDACTED Mon Apr 29 13:45:28 2002 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 29 Apr 2002 12:45:28 +0100 Subject: xref Message-ID: <402DD461F109D411977E0008C791C312039F6AA2@imp02mbx.one2one.co.uk> > > Yes. I meant to add this suggestion also. I wonder who the > "aforementioned > > inexperience" was aimed at :) > > mostly at myself. secondly to others that are inexperienced. > especially > not to Sean Hinde and others that send informative answers to > erlang-questions. Only jesting. For sure I consider myself inexperienced when it comes to compiler options - I only became aware of warn_unused_vars when Bjorn started using it in Wings ;) Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From vlad_dumitrescu@REDACTED Tue Apr 30 06:37:17 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 30 Apr 2002 06:37:17 +0200 Subject: compiler options Message-ID: Hi, good people! The recent discussions about compiler warnings and such, revived a question that I think might be interesting for others too. I find the trace mechanism very useful, but am frustrated that it only works for tracing external calls... Wouldn't it be a nice feature (or maybe it is just undocumented?) to have a compiler directive "-compile(remote_calls)." or something that will make all local function calls to get compiled as if they were remote? This way one could trace local calls without having to change the code. best regards, Vlad _________________________________________________________________ MSN Foto ?r det enklaste s?ttet att dela eller skaffa papperskopior av dina foton: http://photos.msn.com/support/worldwide.aspx From denise.stack@REDACTED Tue Apr 30 07:42:28 2002 From: denise.stack@REDACTED (Denise Stack (EEI)) Date: Tue, 30 Apr 2002 13:42:28 +0800 Subject: Shock horror References: Message-ID: <3CCE2EC4.235622A4@eei.ericsson.se> Hi, this could almost be amusing, if it didn't reinforce the opinion that Erlang is getting more complex with each release.... I ran anal:go(all) using a version of R7B and found that firstly I had to change the source code from xref:analyse/3 to xref:analyze/3. Somewhere between tools-1.6.3 and tools-2.0.1 the undocumented introduction of the alternate forms took place. Then the numbers of exported function calls of each type seems to have increased to a rather large degree: Current complexity= 7418 4185 functions do not need to be exported 2070 functions can be moved 1163 functions cannot be moved /Denise. Joe Armstrong wrote: > > Complexity Shock Horror .... > > I have found to my horror and amazement that that our beloved > Erlang system is far more complex than it should be ... > > ... it all started when I started reading systools.erl ... > > Warning - timid souls should not read on for this is a tale of > horror that will chill your very entrails and make you doubt your sanity > > .... > > (scroll the page for more) > > I wanted to change > > systools:script2boot/1 > > Now this function calls > > systools_lib:file_term2binary/2 > > and I could not understand why the code for this had been placed in > a *different* module - surely *nobody* would want to call > systools_lib:file_term2binary/2 - it's so obscure that nobody would > ever think to use it. And it's not even documented (systools_lib) has > no man pages - so the chances that anybody would ever even think of > using this function are minuscule. > > I thought to myself - "I'll do a Xref analysis to find out if > anybody calls systools_lib:file_term2binary/2" - this turned out to be > more difficult than I had imagined - xref once small and easy to use has > grown in complexity since I last used it to the point where it is almost > (but not quite) impossible to use. > > < unusability - but *that* is another question>> > > After a few false starts and guesses to what xref did I was able to > analyse the system to see who called "systools_lib:file_term2binary/2" - > and my intuition was correct: > > systools_lib:file_term2binary/2 is only called from systools.erl > > Now I might be completely "out and cycling" here (as my Swedish > friends would say) - but IMMVHO (Most very :-) if it is the case > that only one other module calls an exported function then the > function could be MOVED to the place from whence it was called. > > A case of > > "Whither wert tho called oh systools_lib:file_term2binary/2? > > "From only systools.erl" > > "Then go ye thence" > > So I thought to myself - How many exported functions are "singletons" > (by that I means functions which are only called from one external > module) - To answer this I wrote a little program... > > During the writing, thereof, I discovered that there were not only a > large number of singletons (I had hoped that I had stumbled across the > only one) but also a large number of "nollitons" - exported functions > that *nobody* calls. > > For your edification and delight, the numbers are: > > #exported functions = 8148 > 4632 functions do not need to be exported (nollitons) > 2225 functions can be moved (singletons) > 1291 functions cannot be moved > > Pretty stinky stuff, ej wot. > > IMHO every time a nolliton or singleton is used the system become > more difficult to understand and more difficult to structure and more > difficult optimise - "module at a time" compilers do not like external > functions - and thinking up sensible names for them is a pain in the > nether regions. > > Even worse I don't even know if we can remove the buggers - perhaps > (horrors) some application actually calls an undocumented nolliton - > removing (say) all nollitons might awaken the the great God of > backwards incompatibility - their might be much gnashing and grinding > of teeth and wailing and crying if we did this ... > > Before the age utopic bliss is achieved (thank you Thomas) we could > perhaps check to see if any of the BIG applications call the nasty > little nollitons and singletons ... > > Do they? > > Run the enclosed program to see (adding you own own application > modules to the set of stuff that is analysed) > > /Joe > > PS cannot anything be done about this, apart from a total re-write > using Richards heirarchical module system (which I guess we should do > at the same time :-) > > ------------------------------------------------------------------------ > Name: anal.erl > anal.erl Type: Plain Text (TEXT/PLAIN) > Encoding: BASE64 From siri@REDACTED Tue Apr 30 08:47:05 2002 From: siri@REDACTED (Siri Hansen) Date: Tue, 30 Apr 2002 08:47:05 +0200 (MEST) Subject: compiler options In-Reply-To: References: Message-ID: <15566.15187.775831.623331@durin> Hi Vlad! You don't need a compiler directive to trace local calls. Try the using the 'local' flag with erlang:trace_pattern/3, or if using dbg, try dbg:tpl(...) instead of dbg:tp(...). Regards /siri Vlad Dumitrescu wrote: > Hi, good people! > > The recent discussions about compiler warnings and such, revived a question > that I think might be interesting for others too. > > I find the trace mechanism very useful, but am frustrated that it only works > for tracing external calls... Wouldn't it be a nice feature (or maybe it is > just undocumented?) to have a compiler directive "-compile(remote_calls)." > or something that will make all local function calls to get compiled as if > they were remote? This way one could trace local calls without having to > change the code. > > best regards, > Vlad > > _________________________________________________________________ > MSN Foto ?r det enklaste s?ttet att dela eller skaffa papperskopior av dina > foton: http://photos.msn.com/support/worldwide.aspx From vlad_dumitrescu@REDACTED Tue Apr 30 09:03:29 2002 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 30 Apr 2002 09:03:29 +0200 Subject: compiler options Message-ID: >From: Siri Hansen >You don't need a compiler directive to trace local calls. Try the >using the 'local' flag with erlang:trace_pattern/3, or if using dbg, >try dbg:tpl(...) instead of dbg:tp(...). Yes, of course... how silly of me! [dunking head against the table] Thanks. regards, Vlad _________________________________________________________________ Chatta med kompisar online, prova MSN Messenger: http://messenger.msn.com From joe@REDACTED Tue Apr 30 10:39:20 2002 From: joe@REDACTED (Joe Armstrong) Date: Tue, 30 Apr 2002 10:39:20 +0200 (CEST) Subject: Shock horror In-Reply-To: <3CCE2EC4.235622A4@eei.ericsson.se> Message-ID: On Tue, 30 Apr 2002, Denise Stack (EEI) wrote: > Hi, > this could almost be amusing, if it didn't reinforce the opinion that > Erlang is getting more complex with each release.... > Just for fun I computed the transitive closure of the module call graph starting from init.erl - If you include {stdlib, kernel, sasl} then init.erl calls directly or indirectly 91 different modules. If you include *all* the applications this goes up to 113. I actually performed a similar analysis a few years ago, in a paper I wrote dated April 24 1997 I found that the transitive closure of init included 38 modules - so yes the complexity *is* increasing with time. This means that a) Things may load slowly b) It becomes increasingly difficult to ship stand-alone applications since nobody is really sure of what code is needed. A consequence of c) is the *ship everything* mentality. I'm going to take a good hard look at the system to see if we can't identify a minimal kernel ... /Joe From joe@REDACTED Tue Apr 30 15:43:22 2002 From: joe@REDACTED (Joe Armstrong) Date: Tue, 30 Apr 2002 15:43:22 +0200 (CEST) Subject: Help needed Message-ID: Further to my previous mails I need to know which functions in the standard system are used by your applications. I want to find out if we can simplify the system by removing all the crud that is never used. I have included an analyse program - this program computes the set of all MFA's in the standard system which are called by a given set of applications. I would be grateful if you you run this program on your applications and send me the results - I need these results to help me figure out how the system can be simplified. To run this program edit the module (the instructions are in the file) then run it "anal2:run()" and then post me the resultant file (call_analysis.txt) Once you send me your anlysis I can take the grand union of all these files and compute the set of things that got called. The set of things that are exported - the set of things that are called is the *interesting* thing. Note: I am particularly keen that users with large applications send me their results. /Joe -------------- next part -------------- -module(anal2). -export([test/0, run/0]). %% To run this program %% 1) edit the function my_apps() with your applications %% 2) run anal2:run() %% 3) post the resulting file to joe2sics.se -import(lists, [foldl/3, foreach/2, map/2, sum/1, member/2, sort/1]). %% Edit the next line with your applications my_apps() -> [x1, x2, x4]. %% edit this with your Identifier id() -> "My project identifier". %% like AXD301 :-) %% test() -- test the system %% run() -- the full run test() -> go(libs(cos), libs(big)). run() -> go(my_apps(), libs(all)). libs(small) -> [stdlib, kernel, sasl]; libs(big) -> [erl_interface,mnemosyne,sasl,appmon,eva,mnesia,snmp,asn1, gs,mnesia_session,ssl,odbc,stdlib,compiler,ic,toolbar, inets,os_mon,tools,parsetools,tv,debugger,kernel,pman, runtime_tools]; libs(cos) -> [cosEvent,cosFileTransfer,cosNotification,cosProperty,cosTime, cosTransactions]; libs(all) -> libs(big) ++ libs(cos). go(MyApps, SysLibs) -> {ok, P} = xref:start(a), M1 = add_libs(P, SysLibs), io:format("~nStandard libraries have ~w modules~n", [length(M1)]), M2 = add_libs(P, MyApps), io:format("~nApplication libraries have ~w modules~n", [length(M2)]), D = used_calls(P, M2, M1, dict:new()), D1 = dict:to_list(D), D2 = lists:sort(fun({_,N},{_,M}) -> N > M end, D1), {ok, S} = file:open("call_analysis.txt", write), io:format(S, "~p.~n", [{id(), D2}]), file:close(S), Sum = sum(map(fun({_,N}) -> N end, D1)), io:format("Standard system functions are called ~w times~n", [Sum]), io:format("call_analysis.txt created -- please send to joe@REDACTED~n"), xref:stop(P). used_calls(P, [Mod|T], M1, Dict) -> E = Mod:module_info(exports), E1 = remove_locals(E), %% io:format("Here E1=: ~p~n", [E1]), Dict2 = foldl(fun({Func,Arity}, Dict1) -> case xref:analyse(P, {call,{Mod,Func,Arity}}) of {ok, L1} -> update_dict(L1, M1, Dict1); X-> io:format("oops:~p ~p~n", [{Mod,Func,Arity}, X]), Dict1 end end, Dict, E1), used_calls(P, T, M1, Dict2); used_calls(P, [], M1, Dict) -> Dict. update_dict([Key={M,F,A}|T], Sys, Dict) -> case member(M, Sys) of true -> case dict:find(Key, Dict) of error -> D1 = dict:store(Key, 1, Dict), update_dict(T, Sys, D1); {ok, N } -> D1 = dict:store(Key, N+1, Dict), update_dict(T, Sys, D1) end; false -> update_dict(T, Sys, Dict) end; update_dict([], _, D) -> D. add_libs(P, L) -> foldl(fun(I, A) -> Dir = code:lib_dir(I) ++ "/ebin", io:format(".", []), case xref:add_directory(P, Dir, [{warnings,false}]) of {ok, X} -> X ++ A; _ -> A end end, [], L). remove_locals([{module_info,_}|T]) -> remove_locals(T); remove_locals([H|T]) -> [H|remove_locals(T)]; remove_locals([]) -> []. From jamesh@REDACTED Tue Apr 30 17:35:34 2002 From: jamesh@REDACTED (James Hague) Date: Tue, 30 Apr 2002 10:35:34 -0500 Subject: Shock horror Message-ID: > This means that > > a) Things may load slowly > b) It becomes increasingly difficult to ship stand-alone > applications since nobody is really sure of what code is needed. Are crusty old modules ever going to be removed? Crypto, for example, has been completely replaced by built-in functions. It's trivially easy to convert old code to use BIFs instead of crypto, but I suspect it will still be there several releases from now.