From matthias@REDACTED Wed Dec 10 10:01:42 2003 From: matthias@REDACTED (matthias@REDACTED) Date: Wed, 10 Dec 2003 10:01:42 +0100 Subject: how does timer: deal with real-time clock changes? Message-ID: <16342.57590.292461.513559@antilipe.corelatus.se> Hi, On R7B-3 on PPC-linux, I just noticed that if I evaluate timer:apply_interval(1000, io, fwrite, ["."]). and then wind back the system time by a large amount (two months), the timer seems to stop/freeze/die. Winding the time forward by two months causes the timer to execute io:fwrite as fast as it can, i.e. without a pause, forever (well, at least as long as I watched). Doing the same thing on R8A on my desktop seems to cause the timer to stop/freeze in both cases. It seems reasonable for the timer to mess up one interval when the time is changed, but it doesn't seem reasonable for it to freeze or go wild. Anyone know what's going on? Workaround? Matthias From gunilla@REDACTED Mon Dec 1 11:34:35 2003 From: gunilla@REDACTED (Gunilla Arendt) Date: Mon, 01 Dec 2003 11:34:35 +0100 Subject: editor References: Message-ID: <3FCB193B.7CF6F8E3@erix.ericsson.se> There is no way to configure the GS editor to write '*' instead of the typed character, you have to use your work-around. (I don't think the underlying Tk text widget has such a feature, either) / Gunilla WILLIAMS Dominic wrote: > > > I would like a GS editor object to send keypress events, but > > without actually entering the typed characters in the editor window. > > OK, I found a way: the editor has {enable,false}, and I catch events by putting {keypress,true} on the window containing the editor. > > I am still interested if there is a way to do it such that the event comes from the editor, not from the window... > > Thanks, > > Dominic Williams. From gerd@REDACTED Mon Dec 1 14:03:54 2003 From: gerd@REDACTED (Gerd Flaig) Date: Mon, 01 Dec 2003 14:03:54 +0100 Subject: Out of space in dist table Message-ID: Hi, our production systems (running R8B) regularly deny access for new nodes and output the message 'Out of space in dist table'. I remember there has been a problem with dist table entries not being recycled, but I think that should be fixed in R8B. This happens every few days, which may be connected to the fact that new nodes enter and leave the system in roughly five minute intervals. Is this a known problem? Goodbyte, Gerd. -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From gerd@REDACTED Mon Dec 1 14:19:40 2003 From: gerd@REDACTED (Gerd Flaig) Date: Mon, 01 Dec 2003 14:19:40 +0100 Subject: Out of space in dist table In-Reply-To: (Gerd Flaig's message of "Mon, 01 Dec 2003 14:03:54 +0100") References: Message-ID: Gerd Flaig writes: > our production systems (running R8B) regularly deny access for new > nodes and output the message 'Out of space in dist table'. I remember > there has been a problem with dist table entries not being recycled, > but I think that should be fixed in R8B. to be exact: The problem existed in R8B-0 and was reportedly fixed in R8B-2 (see OTP-4244). Goodbyte, Gerd. -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From bjorn@REDACTED Mon Dec 1 14:35:16 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 01 Dec 2003 14:35:16 +0100 Subject: Out of space in dist table In-Reply-To: References: Message-ID: Only hidden nodes will be re-cycled. Hidden nodes are usually written the erl_interface library. Ordinary Erlang nodes are not hidden. The R9B and R9C releases contains a better solution to the problem; the former limit of 255 nodes has been removed. /Bjorn Gerd Flaig writes: > Gerd Flaig writes: > > > our production systems (running R8B) regularly deny access for new > > nodes and output the message 'Out of space in dist table'. I remember > > there has been a problem with dist table entries not being recycled, > > but I think that should be fixed in R8B. > > to be exact: The problem existed in R8B-0 and was reportedly fixed in > R8B-2 (see OTP-4244). > > Goodbyte, Gerd. > -- > Gerd Flaig Technik gerd@REDACTED > Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe > Physics is like sex: sure, it may give some practical results, > but that's not why we do it. -- Richard Feynman > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From gerd@REDACTED Mon Dec 1 15:11:50 2003 From: gerd@REDACTED (Gerd Flaig) Date: Mon, 01 Dec 2003 15:11:50 +0100 Subject: Out of space in dist table In-Reply-To: (Bjorn Gustavsson's message of "01 Dec 2003 14:35:16 +0100") References: Message-ID: Bjorn Gustavsson writes: > The R9B and R9C releases contains a better solution to the problem; > the former limit of 255 nodes has been removed. thank you, I hope there are no upgrade blockers on our systems... Do you know of a Debian Woody package of R9C? Goodbyte, Gerd. -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From gerd@REDACTED Mon Dec 1 19:20:14 2003 From: gerd@REDACTED (Gerd Flaig) Date: Mon, 01 Dec 2003 19:20:14 +0100 Subject: Sybase interface Message-ID: Hi, soon I'll have to interface to Sybase (12.5). I found[1] that Daniesc Schutte already wrote a low level interface and I suspect it might also be possible via ODBC. Googling revealed no further hints. Any recommendations on the way to go? Goodbyte, Gerd. [1] http://article.gmane.org/gmane.comp.lang.erlang.general/2580/match=sybase -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From vances@REDACTED Mon Dec 1 20:56:42 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 1 Dec 2003 14:56:42 -0500 Subject: Supervisor starts children in parallel Message-ID: <20031201195642.GC54605@frogman.motivity.ca> The supervisor behaviour seems to start it's children in parallel. I have a supervisor with two children in a one_for_all strategy. This causes a chicken and egg problem when these processes act as a pair. If they were started synchronously and in order there wouldn't be a problem. It would be very handy if there were a flag to specify either a synchronous or asynchronous startup. How do folks deal with this? -Vance From hal@REDACTED Mon Dec 1 21:19:26 2003 From: hal@REDACTED (Hal Snyder) Date: Mon, 01 Dec 2003 14:19:26 -0600 Subject: Sybase interface In-Reply-To: (Gerd Flaig's message of "Mon, 01 Dec 2003 19:20:14 +0100") References: Message-ID: <874qwkl29d.fsf@ghidra.vail> Gerd Flaig writes: > soon I'll have to interface to Sybase (12.5). I found[1] that > Daniesc Schutte already wrote a low level interface and I suspect it > might also be possible via ODBC. Googling revealed no further hints. > > Any recommendations on the way to go? We used ODBC on Linux and the experience was painful. ODBC adds at least one 3rd party vendor, licensing hassles, proprietary software, and documentation of variable usability. YMMV. We are now using a simple Erlang port to connect to an Oracle database using the command line tool (SQLPlus - like Sybase's isql) at the other end of the port. No coding to vendor API libraries, no ODBC. For the app in question, timing for the database hits is not critical so we can get away with this approach. From lennart.ohman@REDACTED Mon Dec 1 21:19:21 2003 From: lennart.ohman@REDACTED (=?ISO-8859-1?Q?Lennart_=D6hman?=) Date: Mon, 01 Dec 2003 21:19:21 +0100 Subject: Supervisor starts children in parallel In-Reply-To: <20031201195642.GC54605@frogman.motivity.ca> References: <20031201195642.GC54605@frogman.motivity.ca> Message-ID: <3FCBA249.6020106@st.se> Hmm, the next child is not supposed start until the previous ones init-phase has acknowledged back to the supervisor (i.e my_callback_modle:init(...) has returned {ok,DataStructure}. Some people wanting a more concurrent start usually make their init phases empty and keep a state in the DataStrcture. They then send a cast to change that state into "operational mode" for the worker process in some kind of order which is not equavalent to the start-order. But that was not your problem, rather the opposite!? /Lennart Vance Shipley wrote: > The supervisor behaviour seems to start it's children in parallel. > I have a supervisor with two children in a one_for_all strategy. > This causes a chicken and egg problem when these processes act as > a pair. If they were started synchronously and in order there > wouldn't be a problem. It would be very handy if there were a > flag to specify either a synchronous or asynchronous startup. > > How do folks deal with this? > > -Vance -- ------------------------------------------------------------- Lennart Ohman phone : +46-8-587 623 27 Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735 Sehlstedtsgatan 6 fax : +46-8-667 8230 SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From vances@REDACTED Mon Dec 1 21:24:57 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 1 Dec 2003 15:24:57 -0500 Subject: Supervisor starts children in parallel In-Reply-To: <3FCBA249.6020106@st.se> References: <20031201195642.GC54605@frogman.motivity.ca> <3FCBA249.6020106@st.se> Message-ID: <20031201202457.GE54605@frogman.motivity.ca> Well in that case I must revisit why I came to that conclusion. I must be mistaken. Thanks, I feel better now. :) -Vance On Mon, Dec 01, 2003 at 09:19:21PM +0100, Lennart ?hman wrote: } Hmm, } the next child is not supposed start until the previous ones init-phase } has acknowledged back to the supervisor (i.e my_callback_modle:init(...) } has returned {ok,DataStructure}. From sean.hinde@REDACTED Mon Dec 1 21:35:47 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 1 Dec 2003 20:35:47 +0000 Subject: Supervisor starts children in parallel In-Reply-To: <20031201195642.GC54605@frogman.motivity.ca> References: <20031201195642.GC54605@frogman.motivity.ca> Message-ID: On 1 Dec 2003, at 19:56, Vance Shipley wrote: > > The supervisor behaviour seems to start it's children in parallel. > I have a supervisor with two children in a one_for_all strategy. > This causes a chicken and egg problem when these processes act as > a pair. If they were started synchronously and in order there > wouldn't be a problem. It would be very handy if there were a > flag to specify either a synchronous or asynchronous startup. I must admit I thought that the children were started one after the other in a synchronous manner - at least as far as completing the init function of each of the gen_servers. You are using start_link rather than spawn_link to start the children? Sean From ulf.wiger@REDACTED Mon Dec 1 22:30:45 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 01 Dec 2003 22:30:45 +0100 Subject: Supervisor starts children in parallel In-Reply-To: <20031201195642.GC54605@frogman.motivity.ca> References: <20031201195642.GC54605@frogman.motivity.ca> Message-ID: The supervisor starts children in series, assuming that you use proc_lib:start_link/3 to start each child. /Uffe On Mon, 1 Dec 2003 14:56:42 -0500, Vance Shipley wrote: > > The supervisor behaviour seems to start it's children in parallel. > I have a supervisor with two children in a one_for_all strategy. > This causes a chicken and egg problem when these processes act as > a pair. If they were started synchronously and in order there > wouldn't be a problem. It would be very handy if there were a > flag to specify either a synchronous or asynchronous startup. > > How do folks deal with this? > > -Vance -- Ulf Wiger From sean.hinde@REDACTED Mon Dec 1 22:32:30 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 1 Dec 2003 21:32:30 +0000 Subject: Disable CTRL G Message-ID: Hi, I am greatly enthused by the new restricted shell mode in R9C - I see our systems getting safer by the day. I now find myself wondering if it is possible to start an Erlang node with the CTRL-G handler disabled. As far as I can make out from a read of the most accurate documentation I could find (the source to user_drv.erl) this is not something very easy to do at present, but I may be mistaken. It would be almost enough to be able to remove the 'q' option from the CTRL-G handler.. Any ideas anyone? Sean From DANIESC.SCHUTTE@REDACTED Tue Dec 2 05:17:23 2003 From: DANIESC.SCHUTTE@REDACTED (DANIESC SCHUTTE) Date: Tue, 02 Dec 2003 06:17:23 +0200 Subject: Sybase interface Message-ID: Good morning all, we will make the new version of the Sybase 12.5 low level interface SOURCE available during the course of this week. We are just hunting a small memory leak :). Would someone else like it as well? regards Daniel >>> Gerd Flaig 12/01/03 08:20PM >>> Hi, soon I'll have to interface to Sybase (12.5). I found[1] that Daniesc Schutte already wrote a low level interface and I suspect it might also be possible via ODBC. Googling revealed no further hints. Any recommendations on the way to go? Goodbyte, Gerd. [1] http://article.gmane.org/gmane.comp.lang.erlang.general/2580/match=sybase -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman ##################################################################################### The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy all copies. ##################################################################################### From ulf.wiger@REDACTED Tue Dec 2 09:46:53 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 02 Dec 2003 09:46:53 +0100 Subject: Supervisor starts children in parallel In-Reply-To: <3FCBA249.6020106@st.se> References: <20031201195642.GC54605@frogman.motivity.ca> <3FCBA249.6020106@st.se> Message-ID: On Mon, 01 Dec 2003 21:19:21 +0100, Lennart ?hman wrote: > Hmm, > the next child is not supposed start until the previous ones init-phase > has acknowledged back to the supervisor (i.e my_callback_modle:init(...) > has returned {ok,DataStructure}. > > Some people wanting a more concurrent start usually make their init > phases empty and keep a state in the DataStrcture. They then send a > cast to change that state into "operational mode" for the worker process > in some kind of order which is not equavalent to the start-order. Since the topic of complex start dependencies was brought up... The suave OTP way to do this is to use start phases. You start your processes with minimal work done in the init functions, then you write some code in the application callback module. In the .app file, you fill in the start_phases attribute {mod, {MyMod, Args}}, {start_phases, [{Phase, PhaseArgs}|...]} Then, the function MyMod:start_phase(Phase, Type, PhaseArgs) will be called once the processes are started. From here, you can make gen_server calls to your processes in an orderly fashion, and perhaps finish off by globally registering the processes. Everything is synchronous, and since the start_phase function executes in a separate process (the application starter process), it can talk to all the worker processes without locking problems or race conditions. See erl -man application for details. /Uffe -- Ulf Wiger, Senior System Architect EAB/UPD/S From joe@REDACTED Tue Dec 2 15:35:07 2003 From: joe@REDACTED (Joe Armstrong) Date: Tue, 2 Dec 2003 15:35:07 +0100 (CET) Subject: ANNOUNCMENT Message-ID: Hello everybody, My life as a perpetual student is scheduled to end at 10.00 on Friday. On Friday (yes THIS Friday) at 10.00 I will "defend" [1] my thesis. The defence will take place at 10.00 at the IT Universitet KTH Kista (Forum) Sal 4. (this is building 39 on http://www.kth.se/om/kartor_adresser/itu.html) A summary and instructions on how to get to the IT university can be found in the nailleaf at: http://www.sics.se/~joe/thesis/spikblad.html Executive summary of the summary: Q: How can we program stuff that works despite the fact we will have errors in our programs? A: Like this ... [details omitted] Q: Does it work? A: Yes Q: Prove it? A: [details omitted] Q: Can I have my Ph.D now? A: ? /Joe [1] - I don't really now what this means - something to do with knights in shining armor and dragons and things. From div@REDACTED Tue Dec 2 15:42:15 2003 From: div@REDACTED (Carl-Johan Kihlbom) Date: Tue, 2 Dec 2003 15:42:15 +0100 Subject: Advanced Regexps? In-Reply-To: <20031122213256.GA15661@localhost.localdomain> References: <5.1.0.14.1.20031122133234.00bb1338@online.no> <20031122213256.GA15661@localhost.localdomain> Message-ID: Is there any way to do advanced regular expressions in Erlang? I've looked at the regexp and gregexp modules, but their implementations of regular expressions are very limited. I would really like to match word boundaries, etc. like you can in Perl et al. I guess I could run a Perl script from Erlang, but I can't require that the user has Perl installed. Any ideas? Best regards, Carl-Johan Kihlbom Software Engineering & Management IT University of G?teborg From peppe@REDACTED Tue Dec 2 16:31:49 2003 From: peppe@REDACTED (Peter Andersson) Date: Tue, 02 Dec 2003 16:31:49 +0100 Subject: Disable CTRL G References: Message-ID: <3FCCB065.3B6266F6@erix.ericsson.se> Sean, The restricted shell mode + "ignore break" is indeed there for protection against simple operator mistakes. Pressing 'q' and stopping the node in e.g. an attempt to exit the job control (JCL) mode, could very well happen by mistake. So, speaking of mistakes, not being able to disable the JCL quit option - that's one for sure. Bugger. Here's my suggestion: The ignore break flag, erl +Bi, is already used for disabling ^C break/stop of the system. Let's have the same flag also disable any shell shortcut for stopping the system (that'd be the JCL quit option). After all, it's the same kind of "halt by accident" from the shell that we'd be trying to avoid. Do you agree? If so, I'll get to it. Until it's fixed, you know ^G in a primitive Erlang shell (erl -oldshell) will only restart the current evaluator, not bring up the JCL menu? So you get no halt() shortcuts when using a restricted oldshell ignoring break (erl -oldshell -stdlib restricted_shell +Bi). /Peppe Ericsson AB, Erlang/OTP Sean Hinde wrote: > > Hi, > > I am greatly enthused by the new restricted shell mode in R9C - I see > our systems getting safer by the day. > > I now find myself wondering if it is possible to start an Erlang node > with the CTRL-G handler disabled. As far as I can make out from a read > of the most accurate documentation I could find (the source to > user_drv.erl) this is not something very easy to do at present, but I > may be mistaken. > > It would be almost enough to be able to remove the 'q' option from the > CTRL-G handler.. > > Any ideas anyone? > Sean From hal@REDACTED Tue Dec 2 16:41:06 2003 From: hal@REDACTED (Hal Snyder) Date: Tue, 02 Dec 2003 09:41:06 -0600 Subject: ANNOUNCMENT In-Reply-To: (Joe Armstrong's message of "Tue, 2 Dec 2003 15:35:07 +0100 (CET)") References: Message-ID: <87y8tvkz1p.fsf@ghidra.vail> Joe Armstrong writes: > Hello everybody, > > My life as a perpetual student is scheduled to end at 10.00 on > Friday. > > On Friday (yes THIS Friday) at 10.00 I will "defend" [1] my thesis. ... > [1] - I don't really now what this means - something to do with > knights in shining armor and dragons and things. Wish I could be there. Best of luck! Hony soit qui mal y pense. From luke@REDACTED Tue Dec 2 16:55:51 2003 From: luke@REDACTED (Luke Gorrie) Date: 02 Dec 2003 16:55:51 +0100 Subject: ANNOUNCMENT In-Reply-To: References: Message-ID: Joe Armstrong writes: > On Friday (yes THIS Friday) at 10.00 I will "defend" [1] my thesis. Drinks thursday then? http://www.ai.mit.edu/~shivers/grad-advice.html From sean.hinde@REDACTED Tue Dec 2 17:12:16 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Tue, 2 Dec 2003 16:12:16 +0000 Subject: Disable CTRL G In-Reply-To: <3FCCB065.3B6266F6@erix.ericsson.se> References: <3FCCB065.3B6266F6@erix.ericsson.se> Message-ID: <4C47879A-24E2-11D8-AA06-000A95927CCE@mac.com> Peter, > The restricted shell mode + "ignore break" is indeed there for > protection against simple operator mistakes. Pressing 'q' and stopping > the node in e.g. an attempt to exit the job control (JCL) mode, could > very well happen by mistake. Indeed. It has. > > So, speaking of mistakes, not being able to disable the JCL quit option > - that's one for sure. Bugger. > > Here's my suggestion: The ignore break flag, erl +Bi, is already used > for disabling ^C break/stop of the system. Let's have the same flag > also > disable any shell shortcut for stopping the system (that'd be the JCL > quit option). After all, it's the same kind of "halt by accident" from > the shell that we'd be trying to avoid. Do you agree? If so, I'll get > to > it. I think that there is a distinction between "Safe" JCL functions and "Unsafe" JCL functions. I would categorise safe ones as: c i k j s ? | h and unsafe as r [node] and q Other peoples definitions of safe/unsafe might be different. I guess the ultimate solution would be to be able to define a function in the restricted shell callback to allow or deny each of these options or even to drop back to an old_shell like mode where CTRL-G just gives you a new shell if you have buggered up the old one in some way. A minimal solution could well be to link this to the +Bi option, or perhaps better to provide a +G [i] option. > Until it's fixed, you know ^G in a primitive Erlang shell (erl > -oldshell) will only restart the current evaluator, not bring up the > JCL > menu? So you get no halt() shortcuts when using a restricted oldshell > ignoring break (erl -oldshell -stdlib restricted_shell +Bi). Actually this shell looks OK for operator usage - I quite like the fact that multiline commands do not give you back the 1> prompt until they are terminated. Alternatively this might lead to more confusion ("The shell has died, I'll have to restart the node!"). Let's go for some sensible way to neuter CTRL-G and I'll experiment with old_shell in the meantime. Thanks very much, Sean From Bengt.Kleberg@REDACTED Tue Dec 2 17:13:14 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Tue, 02 Dec 2003 17:13:14 +0100 Subject: Advanced Regexps? In-Reply-To: References: <5.1.0.14.1.20031122133234.00bb1338@online.no> <20031122213256.GA15661@localhost.localdomain> Message-ID: <3FCCBA1A.6080101@ericsson.com> Carl-Johan Kihlbom wrote: > Is there any way to do advanced regular expressions in Erlang? I've > looked at the regexp and gregexp modules, but their implementations of > regular expressions are very limited. I would really like to match word > boundaries, etc. like you can in Perl et al. since i do not know perl i would like to ask if you mean that perl has a special regexp for matching word boundaries? (ie, not [\s]+[a-zA-Z]+[\s]+ , but something else). bengt From hal@REDACTED Tue Dec 2 18:09:48 2003 From: hal@REDACTED (Hal Snyder) Date: Tue, 02 Dec 2003 11:09:48 -0600 Subject: Advanced Regexps? In-Reply-To: <3FCCBA1A.6080101@ericsson.com> (Bengt Kleberg's message of "Tue, 02 Dec 2003 17:13:14 +0100") References: <5.1.0.14.1.20031122133234.00bb1338@online.no> <20031122213256.GA15661@localhost.localdomain> <3FCCBA1A.6080101@ericsson.com> Message-ID: <87ptf7kuxv.fsf@ghidra.vail> Bengt Kleberg writes: > Carl-Johan Kihlbom wrote: >> Is there any way to do advanced regular expressions in Erlang? I've >> looked at the regexp and gregexp modules, but their implementations >> of regular expressions are very limited. I would really like to >> match word boundaries, etc. like you can in Perl et al. > since i do not know perl i would like to ask if you mean that perl has > a special regexp for matching word boundaries? (ie, not > [\s]+[a-zA-Z]+[\s]+ , but something else). Another Erlang project for some long weekend... http://www.weitz.de/regex-coach/ While I think I understand regexes, the screenshots in this app are intriguing and the whole thing is done in Common Lisp. It would be interesting to port PCRE as has been done with CL: http://weitz.de/cl-ppcre/ Or has someone done this already? From fillemanjong@REDACTED Tue Dec 2 22:05:13 2003 From: fillemanjong@REDACTED (fille manjong) Date: Tue, 02 Dec 2003 21:05:13 +0000 Subject: Compiling R9C in Debian Woody Message-ID: Hi, I am trying to compile R9C in Debian woody and get the error "undefined reference to `erts_restore_x87'" (See excerpt below) My environment is User mode linux linuxuml-2.4.18-45 and root_fs_woody.bz2 (modified to with gcc 3.04) from http://sourceforge.net/project/showfiles.php?group_id=13751 Compiling R9C in the host environment, which is Redhat 8.0 and gcc 2.95, works without problems. Any suggestions to why I get this error? Best Regards, Anders gcc -g -O2 -I/mnt/leafuml/OTP/otp_src_R9C-0/erts/i686-pc-linux-gnu -DSHARED_HEAP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DHIPE_ARCHITECTURE=x86 -Ibeam -Isys/unix -Isys/common -Ii686-pc-linux-gnu -Ii686-pc-linux-gnu/shared -Izlib -Ihipe -Idrivers/common -Idrivers/unix -I../etc/unix -c drivers/unix/ttsl_drv.c -o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/ttsl_drv.o gcc -o /mnt/leafuml/OTP/otp_src_R9C-0/bin/i686-pc-linux-gnu/beam.shared \ -Wl,-export-dynamic /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_main.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/preload.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_pbifs.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/benchmark.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_alloc.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_mtrace.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_alloc_util.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_goodfit_alloc.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bestfit_alloc.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_afit_alloc.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_instrument.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_init.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_atom_table.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bif_table.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bif_info.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bif_op.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bif_os.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bif_lists.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bif_trace.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bif_wrap.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_trace.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/copy.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/utils.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/bif.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/io.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_debug.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_md5.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_message.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_process.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_process_dict.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_arith.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/time.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_time_sup.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/external.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/dist.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/binary.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_db.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_db_util.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_db_hash.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_db_tree.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/fix_alloc.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/big.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hash.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/index.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/atom.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/module.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/export.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/register.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/break.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_async.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/sys_threads.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/ggc.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_gc.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_posix_str.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bits.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_math.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_vector.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_term.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_fun.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_bif_port.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_node_tables.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_process_dump.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/beam_emu.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/beam_opcodes.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/beam_load.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/beam_bif_load.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/beam_debug.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/beam_bp.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/beam_catches.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/sys.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/driver_tab.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/unix_efile.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/gzio.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/elib_malloc.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/elib_memmove.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/erl_mseg.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/unix_ddll_drv.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/sys_float.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_bif0.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_bif1.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_bif2.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_debug.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_mode_switch.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_native_bif.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_x86_glue.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_x86_bifs.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_x86_signal.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_x86_stack.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/efile_drv.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/ddll_drv.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/inet_drv.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/zlib_drv.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/ram_file_drv.o /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/ttsl_drv.o -lncurses -lresolv -ldl -lm -L/mnt/leafuml/OTP/otp_src_R9C-0/erts/obj/i686-pc-linux-gnu -lz /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_x86_bifs.o: In function `nbif_handle_fp_exception': /mnt/leafuml/OTP/otp_src_R9C-0/erts/obj.shared.beam/i686-pc-linux-gnu/hipe_x86_bifs.o(.text+0x717): undefined reference to `erts_restore_x87' collect2: ld returned 1 exit status make[3]: *** [/mnt/leafuml/OTP/otp_src_R9C-0/bin/i686-pc-linux-gnu/beam.shared] Error 1 make[3]: Leaving directory `/mnt/leafuml/OTP/otp_src_R9C-0/erts/emulator' make[2]: *** [shared] Error 2 make[2]: Leaving directory `/mnt/leafuml/OTP/otp_src_R9C-0/erts/emulator' make[1]: *** [shared] Error 2 make[1]: Leaving directory `/mnt/leafuml/OTP/otp_src_R9C-0/erts' make: *** [emulator] Error 2 _________________________________________________________________ Hitta r?tt k?pare p? MSN K?p & S?lj http://www.msn.se/koposalj From kent@REDACTED Wed Dec 3 04:56:23 2003 From: kent@REDACTED (Kent Boortz) Date: 03 Dec 2003 04:56:23 +0100 Subject: Advanced Regexps? In-Reply-To: <3FCCBA1A.6080101@ericsson.com> References: <5.1.0.14.1.20031122133234.00bb1338@online.no> <20031122213256.GA15661@localhost.localdomain> <3FCCBA1A.6080101@ericsson.com> Message-ID: Bengt Kleberg writes: > since i do not know perl i would like to ask if you mean that perl has > a special regexp for matching word boundaries? (ie, not > [\s]+[a-zA-Z]+[\s]+ , but something else). >From "man perlre" Perl defines the following zero-width assertions: \b Match a word boundary \B Match a non-(word boundary) \A Match only at beginning of string \Z Match only at end of string, or before newline at the end \z Match only at end of string \G Match only at pos() (e.g. at the end-of-match position of prior m//g) A word boundary ("\b") is a spot between two characters that has a "\w" on one side of it and a "\W" on the other side of it (in either order), counting the imaginary characters off the beginning and end of the string as matching a "\W". . . It has other additions as well, like the modifiers m Treat string as multiple lines. That is, change "^" and "$" from matching the start or end of the string to matching the start or end of any line anywhere within the string. s Treat string as single line. That is, change "." to match any character whatsoever, even a newline, which normally it would not match. It is also possible to specify if '*' and '+' are to be eager or not. Perl has lots of more extensions that makes the expressions short and powerful, kent From mikpe@REDACTED Wed Dec 3 13:34:48 2003 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 3 Dec 2003 13:34:48 +0100 Subject: Compiling R9C in Debian Woody In-Reply-To: References: Message-ID: <16333.55400.710608.115748@alkaid.it.uu.se> fille manjong writes: > Hi, > > I am trying to compile R9C in Debian woody and get the error "undefined > reference to `erts_restore_x87'" (See excerpt below) > My environment is User mode linux linuxuml-2.4.18-45 and root_fs_woody.bz2 > (modified to with gcc 3.04) from > http://sourceforge.net/project/showfiles.php?group_id=13751 > Compiling R9C in the host environment, which is Redhat 8.0 and gcc 2.95, > works without problems. > > Any suggestions to why I get this error? In the ./configure step, did it or did it not detect support for reliable floating-point exceptions? HiPE requires reliable f.p. exceptions on Linux/x86. If they aren't available, a linkage error like the one you showed will occur. What does `uname -s` and `uname -m` say in your UML environment? If your UML environment doesn't provide reliable f.p. exceptions, then you should use ./configure --disable-hipe. On an unrelated note: gcc-3.0 is known to have bugs related to it generating code that touches stack slots _below_ the stack pointer. Please switch to a saner compiler, like 3.2.3 or 3.3.2. /Mikael From peppe@REDACTED Wed Dec 3 15:27:05 2003 From: peppe@REDACTED (Peter Andersson) Date: Wed, 03 Dec 2003 15:27:05 +0100 Subject: Disable CTRL G References: <3FCCB065.3B6266F6@erix.ericsson.se> <4C47879A-24E2-11D8-AA06-000A95927CCE@mac.com> Message-ID: <3FCDF2B9.9B67A144@erix.ericsson.se> Sean, I can see the advantages of being able to disable the JCL menu. I don't like the idea of having the restricted shell callbacks handle JCL commands. Since you would disable the JCL quit option for the same reasons you would disable ^C, I still believe +Bi should switch them both off. I'd choose to introduce a new start option to give ^G a shell restart behaviour (like oldshell) instead of JCL mode, like you suggest. You'd have the possibility to force all interaction from the shell to go via the prompt or you could choose to have JCL mode enabled but without the risky 'q' option. Sounds ok? /Peppe Sean Hinde wrote: > > Peter, > > > The restricted shell mode + "ignore break" is indeed there for > > protection against simple operator mistakes. Pressing 'q' and stopping > > the node in e.g. an attempt to exit the job control (JCL) mode, could > > very well happen by mistake. > > Indeed. It has. > > > > > So, speaking of mistakes, not being able to disable the JCL quit option > > - that's one for sure. Bugger. > > > > Here's my suggestion: The ignore break flag, erl +Bi, is already used > > for disabling ^C break/stop of the system. Let's have the same flag > > also > > disable any shell shortcut for stopping the system (that'd be the JCL > > quit option). After all, it's the same kind of "halt by accident" from > > the shell that we'd be trying to avoid. Do you agree? If so, I'll get > > to > > it. > > I think that there is a distinction between "Safe" JCL functions and > "Unsafe" JCL functions. I would categorise safe ones as: > > c > i > k > j > s > ? | h > > and unsafe as r [node] and q > > Other peoples definitions of safe/unsafe might be different. I guess > the ultimate solution would be to be able to define a function in the > restricted shell callback to allow or deny each of these options or > even to drop back to an old_shell like mode where CTRL-G just gives you > a new shell if you have buggered up the old one in some way. > > A minimal solution could well be to link this to the +Bi option, or > perhaps better to provide a +G [i] option. > > > Until it's fixed, you know ^G in a primitive Erlang shell (erl > > -oldshell) will only restart the current evaluator, not bring up the > > JCL > > menu? So you get no halt() shortcuts when using a restricted oldshell > > ignoring break (erl -oldshell -stdlib restricted_shell +Bi). > > Actually this shell looks OK for operator usage - I quite like the fact > that multiline commands do not give you back the 1> prompt until they > are terminated. Alternatively this might lead to more confusion ("The > shell has died, I'll have to restart the node!"). > > Let's go for some sensible way to neuter CTRL-G and I'll experiment > with old_shell in the meantime. > > Thanks very much, > > Sean From mlogan@REDACTED Wed Dec 3 20:34:56 2003 From: mlogan@REDACTED (Martin J. Logan) Date: 03 Dec 2003 13:34:56 -0600 Subject: Sybase interface In-Reply-To: References: Message-ID: <1070480096.12371.1194.camel@dhcp-lom-194-186.futuresource.com> I wrestled with odbc at one time and it was a monumental hassle. On Mon, 2003-12-01 at 12:20, Gerd Flaig wrote: > Hi, > > soon I'll have to interface to Sybase (12.5). I found[1] that Daniesc > Schutte already wrote a low level interface and I suspect it might > also be possible via ODBC. Googling revealed no further hints. > > Any recommendations on the way to go? > > Goodbyte, Gerd. > > [1] http://article.gmane.org/gmane.comp.lang.erlang.general/2580/match=sybase From D.WILLIAMS@REDACTED Thu Dec 4 09:47:33 2003 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Thu, 4 Dec 2003 09:47:33 +0100 Subject: Trouble with ei... Message-ID: Hello, I am trying to connect to an Erlang node from a C program, using ei. I wrote a simple server: -module(server). -export([start/0,loop/0]). start() -> register(spike,spawn(server,loop,[])). loop() -> receive quit -> bye; Other -> io:format("~p~n",[Other]), loop() end. Which works when called from another erlang node. However, the following C program exits without errors, but nothing appears on the server's output... #include "erl_interface.h" #include "ei.h" int main() { ei_cnode ec; ei_connect_init(&ec, "pcwilliams", "vaccin", 1); int fd = ei_connect(&ec, "node2@REDACTED"); if (fd < 0) erl_err_quit("connect failed"); ei_x_buff x; ei_x_new_with_version(&x); ei_x_encode_atom(&x, "hello_from_c"); int res = ei_reg_send(&ec, fd, "spike", x.buff, x.index); if (res < 0) erl_err_quit("send failed"); ei_x_free(&x); return 0; } My configuration is W2K, R9C. I tried long and short node names, to no avail. When I use a bad cookie, the server reports an attempted connection from unauthorized node, and the C program exits with an error. So the program seems to be connecting to the Erlang node, but the message is not getting through to the server. Any suggestions? Thanks, Dominic Williams. From banat82@REDACTED Wed Dec 3 17:15:41 2003 From: banat82@REDACTED (mohammad banat) Date: Wed, 3 Dec 2003 08:15:41 -0800 (PST) Subject: behaviour Message-ID: <20031203161541.16453.qmail@web41813.mail.yahoo.com> what are the number of behaviours existing in erlang /otp and how i can use behaviour in order to implement design patterns? > > > espacially the pattern reactor i want to know how i can implement it using erlang? > can i implement it using behaviour ? > > how i can determine the applicable behaviour to a pattern , ihave to know what all behaviours do? > > i need to know which erlang version that i have to use inorder to write an applications using erlang/otp and if this version supported with the the needed behaviours to start develping a gate way > > > what is the behaviours needed to implement these patterns(reactor,router,active object,half-sync/half-async,connector,acceptorservice configuration) --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now -------------- next part -------------- An HTML attachment was scrubbed... URL: From fillemanjong@REDACTED Thu Dec 4 08:05:21 2003 From: fillemanjong@REDACTED (fille manjong) Date: Thu, 04 Dec 2003 07:05:21 +0000 Subject: Compiling R9C in Debian Woody Message-ID: Thanks, with ./configure --disable-hipe the error disappeared uname -s -> Linux uname -m -> i686 I will continue with changing gcc version according to your recommendation. /Anders >From: Mikael Pettersson >To: "fille manjong" >CC: erlang-questions@REDACTED >Subject: Re: Compiling R9C in Debian Woody >Date: Wed, 3 Dec 2003 13:34:48 +0100 > >fille manjong writes: > > Hi, > > > > I am trying to compile R9C in Debian woody and get the error "undefined > > reference to `erts_restore_x87'" (See excerpt below) > > My environment is User mode linux linuxuml-2.4.18-45 and >root_fs_woody.bz2 > > (modified to with gcc 3.04) from > > http://sourceforge.net/project/showfiles.php?group_id=13751 > > Compiling R9C in the host environment, which is Redhat 8.0 and gcc >2.95, > > works without problems. > > > > Any suggestions to why I get this error? > >In the ./configure step, did it or did it not detect support for >reliable floating-point exceptions? > >HiPE requires reliable f.p. exceptions on Linux/x86. If they aren't >available, a linkage error like the one you showed will occur. > >What does `uname -s` and `uname -m` say in your UML environment? > >If your UML environment doesn't provide reliable f.p. exceptions, >then you should use ./configure --disable-hipe. > >On an unrelated note: gcc-3.0 is known to have bugs related to it >generating code that touches stack slots _below_ the stack pointer. >Please switch to a saner compiler, like 3.2.3 or 3.3.2. > >/Mikael _________________________________________________________________ L?ttare att hitta dr?mresan med MSN Resor http://www.msn.se/resor/ From dhanasekaran.c@REDACTED Thu Dec 4 06:38:07 2003 From: dhanasekaran.c@REDACTED (Chenniappan,Dhanasekaran [DBA]) Date: Thu, 4 Dec 2003 11:08:07 +0530 Subject: Atom generation Message-ID: <46206018C119D611A0C2000255D4191B705459@NTSERVER> hi, I have a process that has to be created as multiple instances and register with different names, Now my problem is i am not able to craete the process names on runtime for register(Atoms like proc1,proc2,...). Please help me in this process. with Tx dhanas From Bengt.Kleberg@REDACTED Thu Dec 4 14:00:28 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Thu, 04 Dec 2003 14:00:28 +0100 Subject: behaviour In-Reply-To: <20031203161541.16453.qmail@web41813.mail.yahoo.com> References: <20031203161541.16453.qmail@web41813.mail.yahoo.com> Message-ID: <3FCF2FEC.6060901@ericsson.com> mohammad banat wrote: > what are the number of behaviours existing in erlang /otp and how i > can use behaviour in order to implement design patterns? for OTP Design Principles, including behaviours, see http://erlang.org/doc/r9c/doc/design_principles/part_frame.html i would recommend a course on otp since it is rather difficult to grasp it on your own. bengt From Bengt.Kleberg@REDACTED Thu Dec 4 14:09:33 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Thu, 04 Dec 2003 14:09:33 +0100 Subject: Atom generation In-Reply-To: <46206018C119D611A0C2000255D4191B705459@NTSERVER> References: <46206018C119D611A0C2000255D4191B705459@NTSERVER> Message-ID: <3FCF320D.9070501@ericsson.com> Chenniappan,Dhanasekaran [DBA] wrote: > hi, > I have a process that has to be created as multiple instances and register > with different names, Now my problem is i am not able to craete the process > names on runtime for register(Atoms like proc1,proc2,...). Please help me in > this process. 1 make sure that the number of processes is bounded since there is an upper limit on the number of atoms in the system. the limit is large (hundreds of thousands), but it exists. 2 do this: Nr = erlang:integer_to_list( N ), Atom = erlang:list_to_atom( lists:append( "proc", Nr ) ), bengt From vlad_dumitrescu@REDACTED Thu Dec 4 14:54:15 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 4 Dec 2003 14:54:15 +0100 Subject: Atom generation References: <46206018C119D611A0C2000255D4191B705459@NTSERVER> <3FCF320D.9070501@ericsson.com> Message-ID: From: "Bengt Kleberg" > Chenniappan,Dhanasekaran [DBA] wrote: > > hi, > > I have a process that has to be created as multiple instances and register > > with different names, Now my problem is i am not able to craete the process > > names on runtime for register(Atoms like proc1,proc2,...). Please help me in > > this process. > > 1 make sure that the number of processes is bounded since there is an > upper limit on the number of atoms in the system. the limit is large > (hundreds of thousands), but it exists. If this can't be ensured [1], then it might be better to use a separate process that maps something like {proc, 2} to a pid and use it as a proxy to the worker processes. [1] If the processes are that many, I suppose that having registered names become quite meaningless -- one could use the pid instead just as well. regards Vlad From sean.hinde@REDACTED Thu Dec 4 16:41:08 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Thu, 4 Dec 2003 15:41:08 +0000 Subject: Disable CTRL G In-Reply-To: <3FCDF2B9.9B67A144@erix.ericsson.se> References: <3FCCB065.3B6266F6@erix.ericsson.se> <4C47879A-24E2-11D8-AA06-000A95927CCE@mac.com> <3FCDF2B9.9B67A144@erix.ericsson.se> Message-ID: <47740696-2670-11D8-B0F3-000A95927CCE@mac.com> On 3 Dec 2003, at 14:27, Peter Andersson wrote: > > Sean, > > I can see the advantages of being able to disable the JCL menu. I don't > like the idea of having the restricted shell callbacks handle JCL > commands. > > Since you would disable the JCL quit option for the same reasons you > would disable ^C, I still believe +Bi should switch them both off. I'd > choose to introduce a new start option to give ^G a shell restart > behaviour (like oldshell) instead of JCL mode, like you suggest. You'd > have the possibility to force all interaction from the shell to go via > the prompt or you could choose to have JCL mode enabled but without the > risky 'q' option. Sounds ok? > Yep. I'd go for that - I never used the other options except to kill off the currently running shell process anyway. Ta muchly, Sean From mlogan@REDACTED Thu Dec 4 16:54:35 2003 From: mlogan@REDACTED (Martin J. Logan) Date: 04 Dec 2003 09:54:35 -0600 Subject: Atom generation In-Reply-To: <46206018C119D611A0C2000255D4191B705459@NTSERVER> References: <46206018C119D611A0C2000255D4191B705459@NTSERVER> Message-ID: <1070553274.12371.1204.camel@dhcp-lom-194-186.futuresource.com> Dhanas, in general it is not a good practice to register processes that are not static i.e processes that you would not name in hard coded fashion and put in your supervision tree. Processes that are spawned per some run time stimulus are not good candidates for registration. If you need to reference them via some piece of information other than their pid() it is advisable to create a mapping from that piece of info to the processes pid. Ets is a nice store for such mappings. Cheers, Martin On Wed, 2003-12-03 at 23:38, Chenniappan,Dhanasekaran [DBA] wrote: > hi, > I have a process that has to be created as multiple instances and register > with different names, Now my problem is i am not able to craete the process > names on runtime for register(Atoms like proc1,proc2,...). Please help me in > this process. > > with Tx > dhanas > From ncharpentier@REDACTED Thu Dec 4 23:00:02 2003 From: ncharpentier@REDACTED (Nicolas Charpentier) Date: Thu, 04 Dec 2003 23:00:02 +0100 Subject: Trouble with ei... In-Reply-To: References: Message-ID: <3FCFAE62.5020105@free.fr> WILLIAMS Dominic wrote: > Hello, > > I am trying to connect to an Erlang node from a C program, using ei. > <.../...> > Which works when called from another erlang node. > However, the following C program exits without errors, but nothing > appears on the server's output... > <.../...> > > My configuration is W2K, R9C. > Any suggestions? > Hi, I'm trying your sample and I get a strange behavior. Your client succeeds to send message to the server but not at all the attempts. I patch your client adding a loop sending a long for (long i(0); i!=100;i++) { ei_x_buff x; ei_x_new_with_version(&x); ei_x_encode_long(&x, i); int res = ei_reg_send(&ec, fd, "spike", x.buff, x.index); if (res < 0) erl_err_quit("send failed"); ei_x_free(&x); } When I launch the client one time, nothing append, but if I repeat the operation several times, the server write the messages on his output. I don't have any explanations.... Regards, Nicolas Charpentier From lennart.ohman@REDACTED Fri Dec 5 00:38:12 2003 From: lennart.ohman@REDACTED (=?ISO-8859-1?Q?Lennart_=D6hman?=) Date: Fri, 05 Dec 2003 00:38:12 +0100 Subject: behaviour In-Reply-To: <20031203161541.16453.qmail@web41813.mail.yahoo.com> References: <20031203161541.16453.qmail@web41813.mail.yahoo.com> Message-ID: <3FCFC564.8000408@st.se> Dear Mohammad, there is a master thesis work on design patterns and Erlang at my web-site: http://www.st.se/telecom/eng/projects/master_thesis_patterns.pdf Maybe it can be of some inspiration. Best Regards, Lennart mohammad banat wrote: > what are the number of behaviours existing in erlang /otp and how i > can use behaviour in order to implement design patterns? > > > > > > espacially the pattern reactor i want to know how i can implement it > using erlang? > > can i implement it using behaviour ? > > > > how i can determine the applicable behaviour to a pattern , ihave to > know what all behaviours do? > > > > i need to know which erlang version that i have to use inorder to > write an applications using erlang/otp and if this version supported with > the the needed behaviours to start develping a gate way > > > > > > what is the behaviours needed to implement these > patterns(reactor,router,active > object,half-sync/half-async,connector,acceptorservice > configuration) > > ------------------------------------------------------------------------ > Do you Yahoo!? > Free Pop-Up Blocker - Get it now > -- ------------------------------------------------------------- Lennart Ohman phone : +46-8-587 623 27 Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735 Sehlstedtsgatan 6 fax : +46-8-667 8230 SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From nhead@REDACTED Sun Dec 7 00:04:05 2003 From: nhead@REDACTED (nhead@REDACTED) Date: Sun, 7 Dec 2003 00:04:05 +0100 Subject: Erlang on RTEMS ... Message-ID: <20031207000405.5288027b.nhead@houbits.com> Does anyone have information or experience with porting Erlang to the RTEMS system? There seems to have been a small hint of such a thing by Matthias Lang several years ago, but I could find no evidence of it coming to fruition ... Thanks in advance, Nigel Head From bry@REDACTED Mon Dec 8 12:10:13 2003 From: bry@REDACTED (bryan) Date: Mon, 8 Dec 2003 12:10:13 +0100 Subject: ejabberd In-Reply-To: <3FCF320D.9070501@ericsson.com> Message-ID: <004d01c3bd7b$da81c2b0$2001a8c0@bryans> Are there any benchmarks as to how ejabberd on various platforms compares with jabberd on various platforms? From matthias@REDACTED Mon Dec 8 13:12:48 2003 From: matthias@REDACTED (Matthias Lang) Date: Mon, 8 Dec 2003 13:12:48 +0100 Subject: Erlang on RTEMS ... In-Reply-To: <20031207000405.5288027b.nhead@houbits.com> References: <20031207000405.5288027b.nhead@houbits.com> Message-ID: <16340.27328.966949.11535@antilipe.corelatus.se> nhead@REDACTED writes: > Does anyone have information or experience with porting Erlang to > the RTEMS system? There seems to have been a small hint of such > a thing by Matthias Lang several years ago, but I could find no > evidence of it coming to fruition ... Assuming you're referring to this discussion on the mailing list: http://www.erlang.org/ml-archive/erlang-questions/200002/msg00012.html It was Samuel Tardieu (i.e. not me) who was talking of porting Erlang to RTEMS. I don't recall hearing any progress report, so I assume he lost interest. Matthias From alexey@REDACTED Mon Dec 8 13:22:15 2003 From: alexey@REDACTED (Alexey Shchepin) Date: Mon, 08 Dec 2003 14:22:15 +0200 Subject: ejabberd In-Reply-To: <004d01c3bd7b$da81c2b0$2001a8c0@bryans> (bry@xdocs.dk's message of "Mon, 8 Dec 2003 12:10:13 +0100") References: <004d01c3bd7b$da81c2b0$2001a8c0@bryans> Message-ID: <871xrfts7c.fsf@office.sevcom.net> Hello, bryan! On Mon, 8 Dec 2003 12:10:13 +0100, you said: b> Are there any benchmarks as to how ejabberd on various platforms b> compares with jabberd on various platforms? On jabber.ru it works with approximately 4 times less CPU load than jabberd14 (FreeBSD, ~450 users online). From spearce@REDACTED Tue Dec 9 05:17:29 2003 From: spearce@REDACTED (Shawn Pearce) Date: Mon, 8 Dec 2003 23:17:29 -0500 Subject: atoms vs. integers Message-ID: <20031209041729.GA29444@spearce.org> Very stupid question, I think I know the answer already, but since everyone knows there's no such thing as a stupid question, let me prove it wrong by asking one: >From a performance point, which is faster, ints or atoms? I realize both are exactly one word in size in the emulator, and that atoms are supposed to be unified in the atom table, so all occurances of the atom say 'finished' is at the same memory address, and thus have the same term value. I'm basically planning on stuffing a large number of 2 tuples holding {Key, Atom} into an ets table, and doing lots of pattern matching on the Atoms coming back. A large amount of code is going to something along: case ets:lookup(reg_tab, Key) of [{_, finished}] -> ...; [{_, not_done}] -> ...; [] -> ... end. My guess is that since these are comparing terms, its just a comparsion of two words, which is dirt cheap. What about sending these over the wire then in distributed messages to other nodes? I'm going to use Erlang distribution rather than UBF or some other solution as I'm going to be using the distribution for what it was originally designed for: tightly coupling systems that are already tightly coupled. No reason to reinvent the wheel here. (Besides, I want the monitoring and linking Erlang offers!) >From what I know, atoms would be slower here, as the receiver would need to lookup the matching atom on the other end. If I used ints, I could use macros ?FINISHED and ?NOT_DONE, but of course this is not very Erlangish. I might still use the macros, but start out with atoms under them, and then can either globally search and replace the macros out if I'm ok with the atom transfer performance, or change the macros to ints. To answer my own question: don't optimize now, just write the code, make it correct, profile, and put off optimizing as long as possible. :) However, I don't want my program to expend a lot of time looking up atoms when I'm going to be having hundreds of nodes passing around tens of thousands of messages per second to each other with these two atoms in them. On a related note, how do bigints compare to just using a tuple of small ints or a binary? I'm thinking about both term storage and the header(s) required for the term, GC, cost to move between ets and back, etc. I don't need to perform math on it once created, just perform comparsions for ordering. Creation can be easily hidden down within a function, much like make_ref(). I can't use make_ref() however because I need certain assurances about ordering of values. These values are the Keys above - I basically need about 96 bits wide of data space within any given Key, which means a tuple of 4 elements, a bigint of 3, or a binary of 12 bytes (3 words). I need to be able to shove thousands of these into an ets set, but they will have a high degree of common bits. Its a given that of the 96 bits, the same 80 will be common with all other Key values in the ets table. I can organize the Key any way I chose to get better hashing from ets if any ets masters have words of wisdom to share... one thought I have had is to pull out those 80 or so common bits and store them somehow 'globally', then put just the 16 differing bits in the table. Every so often however it is necessary to rebuild this table, and update the 80 common bits. Unfortunately, Erlang does not really offer a great way to share this GlobalCommon80 with all interested processes (which can be in the hundreds) on each node. Short of putting them into an ets table, or sending a broadcast message. So this solution is not good, unless it would dramatically improve ets performance, outweighing the cost of manging GlobalCommon80. -- Shawn. From lennart.ohman@REDACTED Tue Dec 9 05:39:19 2003 From: lennart.ohman@REDACTED (=?ISO-8859-1?Q?Lennart_=D6hman?=) Date: Tue, 09 Dec 2003 05:39:19 +0100 Subject: atoms vs. integers In-Reply-To: <20031209041729.GA29444@spearce.org> References: <20031209041729.GA29444@spearce.org> Message-ID: <3FD551F7.6070501@st.se> Hi! (a lot cut away... :-) > ... > What about sending these over the wire then in distributed messages to > other nodes? I'm going to use Erlang distribution rather than UBF or > ... Try doing term_to_binary/1 on what you intend to send and you'll see what you are really sending. > ... > On a related note, how do bigints compare to just using a tuple of > small ints or a binary? I'm thinking about both term storage and > ... http://www.erlang.org/doc/r9c/doc/efficiency_guide/part_frame.html Integer (big numbers) 3..N words Tuple 2 words + the size of each element ------------------------------------------------------------- Lennart Ohman phone : +46-8-587 623 27 Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735 Sehlstedtsgatan 6 fax : +46-8-667 8230 SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From spearce@REDACTED Tue Dec 9 06:11:20 2003 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 9 Dec 2003 00:11:20 -0500 Subject: atoms vs. integers In-Reply-To: <3FD551F7.6070501@st.se> References: <20031209041729.GA29444@spearce.org> <3FD551F7.6070501@st.se> Message-ID: <20031209051120.GA29559@spearce.org> Lennart ?hman wrote: > Hi! > (a lot cut away... :-) > > ... > >What about sending these over the wire then in distributed messages to > >other nodes? I'm going to use Erlang distribution rather than UBF or > > ... > > Try doing term_to_binary/1 on what you intend to send and you'll see what > you are really sending. Thanks, that gave me what I knew it would give me. An ei formatted message wherein the atom is a string. :-) Meanwhile the normal ints 1 and 2 were formatted as <<131,97,1>> and <<131,97,2>>, that is, two bytes to transfer the one very tiny int. Atoms seem to have at least a header of 3 bytes, followed by the characters that make up the atom. (That 3 byte header is excluding the 131 ei version marker.) I'm going to use macros, and decide this later. I think its stupid to use ints here, this is why Erlang has atoms - but from a performance point of view, I'd be using just 1 bit in C. :-) I think its in the critical loop as far as communication goes, enough to possibly justify the more difficult to debug 1/2 vs. atoms 'finished'/'not_finished'. > >... > >On a related note, how do bigints compare to just using a tuple of > >small ints or a binary? I'm thinking about both term storage and > > ... > > http://www.erlang.org/doc/r9c/doc/efficiency_guide/part_frame.html > > Integer (big numbers) 3..N words > Tuple 2 words + the size of each element Thanks, I had forgotten about this table. Looks like they would be the same size for the same 96 bits of storage. It'd be better off with the bigint then, as its ordering semantics would be more 'natural' for someone else to understand, than the concept of ordering tuples... (Despite the fact that tuples can in fact be ordered!) -- Shawn. From ulf.wiger@REDACTED Tue Dec 9 08:12:45 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 09 Dec 2003 08:12:45 +0100 Subject: atoms vs. integers In-Reply-To: <20031209051120.GA29559@spearce.org> References: <20031209041729.GA29444@spearce.org> <3FD551F7.6070501@st.se> <20031209051120.GA29559@spearce.org> Message-ID: On Tue, 9 Dec 2003 00:11:20 -0500, Shawn Pearce wrote: > Lennart ?hman wrote: >> Hi! >> (a lot cut away... :-) >> > ... >> >What about sending these over the wire then in distributed messages to >> >other nodes? I'm going to use Erlang distribution rather than UBF or >> > ... >> >> Try doing term_to_binary/1 on what you intend to send and you'll see >> what you are really sending. > > Thanks, that gave me what I knew it would give me. An ei formatted > message wherein the atom is a string. :-) This is almost the whole truth. If you use Distributed Erlang, there will be an atom cache that in effect sends only references to atoms (they have to be sent once of course.) > I'm going to use macros, and decide this later. I think its stupid > to use ints here, this is why Erlang has atoms - but from a performance > point of view, I'd be using just 1 bit in C. :-) I think its in the > critical loop as far as communication goes, enough to possibly justify > the more difficult to debug 1/2 vs. atoms 'finished'/'not_finished'. Macros do have the advantage that you get a compile-time check for typos etc. The disadvantage is of course, as you mention, the slightly less descriptive debugging output, but this is more a result of using integers rather than atoms. I've seen macros like: -define(true, true). Not sure it's something I want to recommend, but it does give you some minimal compile-time type checking. (: /Uffe -- EAB/UPD/S Ulf Wiger Senior System Architect, ENGINE MGW From Bengt.Kleberg@REDACTED Tue Dec 9 08:24:01 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Tue, 09 Dec 2003 08:24:01 +0100 Subject: atoms vs. integers In-Reply-To: <20031209041729.GA29444@spearce.org> References: <20031209041729.GA29444@spearce.org> Message-ID: <3FD57891.4040207@ericsson.com> Shawn Pearce wrote: > Very stupid question, I think I know the answer already, but since > everyone knows there's no such thing as a stupid question, let me i rememeber having seen a disprof of that some years ago. here it is: http://www.glasswings.com.au/comics/ozyandmillie/2000/om20001105.html this is way off topic, and only shows the incredible amount of useless information that can be stored and retrived from a human brain. bengt From samirterawi@REDACTED Tue Dec 9 00:00:09 2003 From: samirterawi@REDACTED (Samir Terawi) Date: Mon, 8 Dec 2003 15:00:09 -0800 (PST) Subject: behaviour Message-ID: <20031208230009.48888.qmail@web41906.mail.yahoo.com> hello , i will be thankfull if u can send me the way supported with code about how to implement adesign pattern in the form of erlang behaviour like the tokenizer behaviour , i need the code of it inorder to help me in writting another kinds of design patterns . it will be very kind of you to help me best regards --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjarne@REDACTED Tue Dec 9 18:34:01 2003 From: bjarne@REDACTED (=?Windows-1252?Q?Bjarne_D=E4cker?=) Date: Tue, 09 Dec 2003 18:34:01 +0100 Subject: EUC'2003 proceedings Message-ID: <001c01c3be7a$a30c84a0$ba1269d4@segeltorp> The complete proceedings from the Erlang/OTP User Conference 2003 are now available at http://www.erlang.se/euc/03/ I would like to thank the presenters, the participants and the organisers for making this such a successful event. Bjarne D?cker, EUC'2003 chairman -------------- next part -------------- An HTML attachment was scrubbed... URL: From banat82@REDACTED Tue Dec 9 22:20:03 2003 From: banat82@REDACTED (mohammad banat) Date: Tue, 9 Dec 2003 13:20:03 -0800 (PST) Subject: Fwd: user defined behaviours Message-ID: <20031209212003.42166.qmail@web41804.mail.yahoo.com> Note: forwarded message attached. --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: mohammad banat Subject: user defined behaviours Date: Tue, 9 Dec 2003 13:18:04 -0800 (PST) Size: 1509 URL: From spearce@REDACTED Tue Dec 9 23:36:24 2003 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 9 Dec 2003 17:36:24 -0500 Subject: atoms vs. integers In-Reply-To: References: <20031209041729.GA29444@spearce.org> <3FD551F7.6070501@st.se> <20031209051120.GA29559@spearce.org> Message-ID: <20031209223624.GB29559@spearce.org> Ulf Wiger wrote: > >>Try doing term_to_binary/1 on what you intend to send and you'll see > >>what you are really sending. > > > >Thanks, that gave me what I knew it would give me. An ei formatted > >message wherein the atom is a string. :-) > > This is almost the whole truth. If you use Distributed Erlang, > there will be an atom cache that in effect sends only references > to atoms (they have to be sent once of course.) Ah, well, if the distribution protocol is that smart, then I guess atoms aren't really all that much slower than ints, once you get them sent over the first time. That being the case, using atoms is better than using ints, just for the sake of making it easier to write and debug the code, especially once in production when lots of things are going wrong. This comment was what I was hoping to hear, thank you Ulf. > >I'm going to use macros, and decide this later. I think its stupid > >to use ints here, this is why Erlang has atoms - but from a performance > >point of view, I'd be using just 1 bit in C. :-) I think its in the > >critical loop as far as communication goes, enough to possibly justify > >the more difficult to debug 1/2 vs. atoms 'finished'/'not_finished'. > > Macros do have the advantage that you get a compile-time check > for typos etc. The disadvantage is of course, as you mention, > the slightly less descriptive debugging output, but this is more > a result of using integers rather than atoms. > > I've seen macros like: > > -define(true, true). That'll work assuming one says ?true rather than true in the code. So easy to get it wrong! Yea, I'm not too big on the macros myself to just hide the atoms. I think its pretty silly. On the other hand, it makes it easy to switch from int to atom and back. -- Shawn. From ok@REDACTED Wed Dec 10 01:59:26 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 10 Dec 2003 13:59:26 +1300 (NZDT) Subject: atoms vs. integers Message-ID: <200312100059.hBA0xQRN005664@atlas.otago.ac.nz> Lennart Ohman wrote: Try doing term_to_binary/1 on what you intend to send and you'll see what you are really sending. Is that entirely true? My understanding was that terms sent between nodes exploited an atom cache, so that sending the same term twice may be considerably cheaper than sending the same bytes twice. That's certainly what the Erlang 4.7 specification description of Erlang term encoding seemed to imply. From Bengt.Kleberg@REDACTED Wed Dec 10 11:57:03 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Wed, 10 Dec 2003 11:57:03 +0100 Subject: Fwd: user defined behaviours In-Reply-To: <20031209212003.42166.qmail@web41804.mail.yahoo.com> References: <20031209212003.42166.qmail@web41804.mail.yahoo.com> Message-ID: <3FD6FBFF.8090904@ericsson.com> mohammad banat wrote: > hello plaese if you can provide me the implementation of the gen_event > behaviour or the implementation of any user defined behaviours inorder > to help me in building some user defined behaviours please take a look at OTP Design Principles (http://erlang.org/doc/r9c/doc/design_principles/part_frame.html). moreover, the paper ''Design Patterns for Simulations in Erlang OTP'' might prove valuable. the url for this paper was meniton on the list just a short while (not before november) ago. bengt From kramer@REDACTED Wed Dec 10 08:21:11 2003 From: kramer@REDACTED (Reto Kramer) Date: Tue, 9 Dec 2003 23:21:11 -0800 Subject: Question relating to trace/debug/log OTP features Message-ID: <6E43068C-2AE1-11D8-BDCA-000393B64312@acm.org> I'm puzzled by the many facilities OTP contains to generate trace-, debug- and log information. Perhaps someone could point me to an overview/tutorial of what the mechanisms are that you recommend I use for a brand new development. What's missing the most in the docs (or I could not find it) is how the various mechanisms relate to each other (e.g. which ones are basic services that high level trace/log services leverage, which ones are "old" and still there for backwards compatibility). Specifically I need 3 things: 1. error/warning/info/detail messages that the end user should see in production. 2. debug information. 3. more debug information (free form, not tied to gen_* entry/exit/state-change) For (1) I use error_logger currently, is there an alternative I should consider? Sometimes I'd like to be able to show customers more levels of granularity (currently error and info are available, I need warning and detail as well) without having to resort to the debug level data in (2) and (3). Is there a way to add another level to the current 2 (error/info/...)? Is there an Erlang/OTP philosophy to only having 2 levels? For (2) I use sys:trace(Mod,true) to enable *DBG* messages for gen_* behaviour and for my own (along section 6.2.1 "Special processes" of the "design principles" doc). However sometimes I'd like to show additional *DBG* messages of my own in callback modules that I pass to gen_* behaviour - how can I do that (i.e. what do I call inside the callback module to generate a *DBG* event? For (3) I currently use a macro to enable/disable io:format calls (the old style "recompile with debug" story). Is there a facility in OTP that I can use to enable dumping of debug information at runtime w/o recompiling (I'm quite happy to accept the performance penalty, my application is not performance critical)? E.g. can I use sys:trace in arbitrary code and through that get the dynamic enable/disable? In addition, does anyone have examples code or tutorial on the following (or advice as to when to use): - disk_log and disk_log_wrapper (i.e. vs. the error_logger info/error messages) - seq_trace and the observer/ttb (R9C). Specifically are seq_trace and ttb the basis and observer the visualizer? How do I invoke the observer (R9C docs are silent on that)? - How does et (et_collector, selector, viewer) relate to the observer/ttb/seq_trace facilities? How does it relate to sys:trace? I'm hoping that some OTP expert can help me understand these facilities and their relation and when to use what (ideally by example/experience). Perhaps someone could talk about the OTP history and how the many powerful mechanisms were motivated (various projects, timing, ...) Thanks in advance for helping me navigate the Zoo. - Reto _________________ A distributed system is a system in which I can't do my work because some computer has failed that I've never even heared of . -- Leslie Lamport -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3064 bytes Desc: not available URL: From Bengt.Kleberg@REDACTED Wed Dec 10 11:56:57 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Wed, 10 Dec 2003 11:56:57 +0100 Subject: behaviour In-Reply-To: <20031208230009.48888.qmail@web41906.mail.yahoo.com> References: <20031208230009.48888.qmail@web41906.mail.yahoo.com> Message-ID: <3FD6FBF9.4080604@ericsson.com> Samir Terawi wrote: > hello , i will be thankfull if u can send me the way supported with code > about how to implement adesign pattern in the form of erlang behaviour the paper ''Design Patterns for Simulations in Erlang OTP'' might prove valuable. the url for this paper was mention on the list just a short while (not before november) ago. moreover, take a look at OTP Design Principles (http://erlang.org/doc/r9c/doc/design_principles/part_frame.html). bengt From kostis@REDACTED Wed Dec 10 18:25:44 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 10 Dec 2003 18:25:44 +0100 (MET) Subject: Small poll Message-ID: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> I was wondering whether the Erlang user community would care to comment on the following: In a function like: test(A) -> a + 42. which is either crap (arguably) or a typo (A vs a), how many Erlang users: 1. Are content with the current situation where the compiler happily compiles this program 2. Would like to see a warning, but a .beam file generated nevetheless 3. Would prefer if the compiler in R10 refused to compile it Notice I am not talking about any serious attempt to static type checking, but for really "basic" checks. Kostis. From samirterawi@REDACTED Wed Dec 10 15:32:31 2003 From: samirterawi@REDACTED (Samir Terawi) Date: Wed, 10 Dec 2003 06:32:31 -0800 (PST) Subject: please help me Message-ID: <20031210143231.50059.qmail@web41906.mail.yahoo.com> dear sir, madam I NEED HELP I need to learn how can I implement my own erlang behaviours. I need to learn the""SYNTAX"" that I need, so I can complete my graduated project. samir terawi. --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad_dumitrescu@REDACTED Wed Dec 10 20:22:59 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 10 Dec 2003 20:22:59 +0100 Subject: Small poll References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: Hi, > test(A) -> > a + 42. For the "A vs a" problem, there is already a warning being issued. Possibly the full warnings options should be enabled by default? Since both a and 42 are constants, I feel it would be easy (besides useful) to be able to detect it at compile time. The operation should even be evaluated at compile time, IMHO. regards, Vlad From sean.hinde@REDACTED Wed Dec 10 20:22:49 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Wed, 10 Dec 2003 19:22:49 +0000 Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: <3DD916D6-2B46-11D8-B4DF-000A95927CCE@mac.com> On 10 Dec 2003, at 17:25, Kostis Sagonas wrote: > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it 3 please. This is not feature I want anyone here relying on :-) Sean From luke@REDACTED Wed Dec 10 20:30:44 2003 From: luke@REDACTED (Luke Gorrie) Date: 10 Dec 2003 20:30:44 +0100 Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: Kostis Sagonas writes: > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it I would like (2). (1) would be a bit weird since there are already warnings for e.g. unused functions, but (3) might be annoying if I know test/1 is broken but want to poke around some other functions. Is this coming from the type-analysis stuff mentioned in the EUC HiPE presentation? If so, to firmly put myself into broken-record-mode :-), I think what CMUCL does with the type information it discovers is pretty nice -- warnings like this and optional "efficiency-notes". And if you end up doing optional efficiency-notes in HiPE, as in foo.erl:10: Bit-syntax pattern is not byte-aligned - not native-compiling foo.erl:20: Can't determine operand types in "X*Y*Z" - not inlining '*' then I promise to hack up a fancy Emacs front-end like CMUCL has http://www.bluetail.com/~luke/misc/lisp/slime-shot.png .. though I won't suggest we have to make the compiler so unpredictable as to require efficiency-notes just so that the Emacs mode can be fancier :-) (And of course Emacs needs to know a little more than just the line number to figure out what to underline..) From taavi@REDACTED Wed Dec 10 20:33:50 2003 From: taavi@REDACTED (Taavi Talvik) Date: Wed, 10 Dec 2003 21:33:50 +0200 (EET) Subject: Small poll In-Reply-To: Message-ID: <20031210213226.X27146-100000@valu.uninet.ee> On Wed, 10 Dec 2003, Vlad Dumitrescu wrote: > > test(A) -> > > a + 42. > > For the "A vs a" problem, there is already a warning being issued. Possibly > the full warnings options should be enabled by default? > > Since both a and 42 are constants, I feel it would be easy (besides useful) > to be able to detect it at compile time. The operation should even be > evaluated at compile time, IMHO. Exactly. And if compile time evaluation fails, give compile time error {badarith,....}. best regards, taavi From hal@REDACTED Wed Dec 10 20:36:06 2003 From: hal@REDACTED (Hal Snyder) Date: Wed, 10 Dec 2003 13:36:06 -0600 Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> (Kostis Sagonas's message of "Wed, 10 Dec 2003 18:25:44 +0100 (MET)") References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: <877k144g9l.fsf@ghidra.vail> Kostis Sagonas writes: > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it We don't do that, ergo, no preference. I'd rather see cond added. :-) From cpressey@REDACTED Wed Dec 10 21:25:15 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 10 Dec 2003 12:25:15 -0800 Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: <20031210122515.72af0c5a.cpressey@catseye.mine.nu> On Wed, 10 Dec 2003 18:25:44 +0100 (MET) Kostis Sagonas wrote: > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it 5. Would prefer it returned the atom 'a42' (PerLang/I! Yesss!!!) (Dark humour aside... I think #2 makes the most sense.) -Chris From luna@REDACTED Wed Dec 10 22:02:16 2003 From: luna@REDACTED (Daniel Luna) Date: Wed, 10 Dec 2003 22:02:16 +0100 (CET) Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: On Wed, 10 Dec 2003, Kostis Sagonas wrote: > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it > > Notice I am not talking about any serious attempt to static > type checking, but for really "basic" checks. I would choose 2, which btw is the behaviour you get in this case if you have set ERL_COMPILER_OPTIONS="[warn_unused_vars]". In the case where you don't get that warning (for instance by using the variable earlier in the function) I still like option 2. It would be easy (and nice) to add a warning at all points where constant propagation detects a possible (probable?) run-time error. I use the word possible since I would like the warning in the case test(A,B) -> case B of true -> a + 42; _ -> A. The above function is also a good example of why option 3 is bad. There might actually be a reason that the programmer wants to generate a run-time error in the case that B is true (I can't think of one, but...). Anyway it would be bad to disallow program lines that might actually never even be reached. btw Since I am delurking I should probably say hi to the list. Hi list. I am a last year student at Uppsala University, studying Computer Science and Mathematics (in no particular order of preference). I recently took a course in compiler techniques where we rewrote the constant propagation pass on the ICode level for HiPE. This made me interested in Erlang so I started lurking here. My email log says that I have been lurking since July, but in reality I have been deleting more than I have read; increasing my read/delete ratio steadily. Up to almost 1 the last week (or "division by zero exception" depending on how you count). #Luna -- Daniel Luna | Top reasons that I have a beard: luna@REDACTED | a) Laziness. http://www.update.uu.se/~luna/ | b) I can. Don't look at my homepage (it stinks).| c) I can get away with it. From thomasl_erlang@REDACTED Wed Dec 10 22:31:38 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 10 Dec 2003 13:31:38 -0800 (PST) Subject: Small poll In-Reply-To: Message-ID: <20031210213138.92673.qmail@web41901.mail.yahoo.com> --- Luke Gorrie wrote: > Kostis Sagonas writes: > > > I was wondering whether the Erlang user community > would care > > to comment on the following: > > > > In a function like: > > > > test(A) -> > > a + 42. > > > > which is either crap (arguably) or a typo (A vs > a), how many > > Erlang users: > > > > 1. Are content with the current situation where > the compiler > > happily compiles this program > > 2. Would like to see a warning, but a .beam file > generated > > nevetheless > > 3. Would prefer if the compiler in R10 refused to > compile it I prefer (2) with an OPTIONAL warning, and otherwise concur with Luke. CMUCL:s user interaction is the most sophisticated I know of, so building on efficiency notes etc. sounds like a good idea. (As a principle, it is a bad idea to leave the programmer guessing about what sort of tweaks should be made for good performance.) However, there are some problems. First, it should be noted that Common Lisp has a much richer type system than Erlang. Expressing that something is a fixnum or a specialized sort of tuple is tedious in Erlang. Second, the various type annotations one might want to make are probably easier and more elegantly done with macros in CL than in Erlang. Some easy way of communicating those to the compiler is probably needed. In short, the compiler-user interaction is worth some careful thinking. Best, Thomas PS. As regards warnings in general, I would like two more options: - Warn when a variable occurrence is matched rather than bound. This has turned out to be a bug more often than I would have liked. - Warn about unknown compiler options (currently just ignored) __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ From jonathan@REDACTED Wed Dec 10 22:41:05 2003 From: jonathan@REDACTED (jonathan@REDACTED) Date: Wed, 10 Dec 2003 21:41:05 -0000 Subject: (Fwd) Re: Small poll Message-ID: <3FD792F1.10359.6A8ACE@localhost> > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it I would have thought that the majority of work for either 2 or 3 is detecting the condition, so once you've implemented either, the other is trivial. So isn't controlling the response generated via a compiler flag, probably with option 3 the default, the most workable solution? - Jonathan Coupe From taavi@REDACTED Wed Dec 10 22:44:39 2003 From: taavi@REDACTED (Taavi Talvik) Date: Wed, 10 Dec 2003 23:44:39 +0200 (EET) Subject: Small poll In-Reply-To: Message-ID: <20031210233545.V29347-100000@valu.uninet.ee> On Wed, 10 Dec 2003, Daniel Luna wrote: > It would be easy (and nice) to add a warning at all points where constant > propagation detects a possible (probable?) run-time error. I use the word > possible since I would like the warning in the case > > test(A,B) -> > case B of > true -> a + 42; > _ -> A. > > The above function is also a good example of why option 3 is bad. There > might actually be a reason that the programmer wants to generate a > run-time error in the case that B is true (I can't think of one, but...). > Anyway it would be bad to disallow program lines that might actually never > even be reached. Still disagree. Erlang specification does not disallow optimizing compilers, which try to evaluate constant expressions compile time. Language allready has special construct for throwing exceptions - throw(...). Why not force explicit usage of throw() instead of obscure evaluation side effects? best regards, taavi From erlang@REDACTED Thu Dec 11 03:16:37 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Wed, 10 Dec 2003 23:16:37 -0300 Subject: Code Reviewing Needed Message-ID: <018f01c3bf8c$d240e1e0$0f00a8c0@daniel> Hi, Is there anyone with good experience in Erlang for code reviewing, willing to travel to South America? Regards, daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From p0rj2el602@REDACTED Thu Dec 11 04:39:00 2003 From: p0rj2el602@REDACTED (Lon Willett) Date: Thu, 11 Dec 2003 04:39:00 +0100 Subject: Small poll In-Reply-To: <20031210233545.V29347-100000@valu.uninet.ee> References: <20031210233545.V29347-100000@valu.uninet.ee> Message-ID: <5821-94666@sneakemail.com> On ons, 2003-12-10 at 18:25, Kostis Sagonas wrote: > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it I liked the "perlang" suggestion ;-). Seriously, my preference (in order) would be: #2, #3, #1. Or maybe #3 by default, but a compiler option to use #2. I see three uses for writing such code: 1. As a programmer, one wants to know what exceptions will be generated by certain error conditions, and/or how your program will react to them. So one writes a little code that artificially generates such errors. Such code is never released to the world. 2. As a tester, one may want to do much the same thing. I'm not really sure that this case is really distinct from the first one, but in my mind it is a different part of the process. Also, testers tend to be rather less well versed in the subtleties of compiler behaviour, and thus less capable of doing tricky things to "fool" the compiler. 3. One wants to generate a particular error in precisely the "standard" format, regardless of how the internals of the erlang system may change in future releases. I believe that case #3 is so rare that it is unimportant (or perhaps it is even non-existent). But while they are not something that I would raise a fuss about, I'm not sure that the first two cases should be ignored. Just the other day, I was doing weird things to see what kind of NaNs libm/pentium produce at runtime. I think I fooled gcc into actually performing the nasty operations at run time instead of compile time (and maybe it generates the same result even when it optimises the operations away), but I may have made a mistake. It's nicer when one doesn't have to play games with the compiler. (BTW, the semantics of floating point in erlang seem to be rather messed up. Is their any intention to clean it up some time? I usually just try to pretend that erlang doesn't have floats). On ons, 2003-12-10 at 22:44, Taavi Talvik wrote: > Still disagree. Erlang specification does not disallow optimizing > compilers, which try to evaluate constant expressions compile time. > > Language allready has special construct for throwing exceptions - > throw(...). > > Why not force explicit usage of throw() instead of obscure evaluation > side effects? I agree that an explicit exit() is almost always better. But isn't exit() what you want, not throw()? If so, this demonstrates the point that people aren't really so aware of the correct way to simulate errors. So it might be better (occasionally) if they can just write straightforward code to generate a desired error condition. /Lon From nhead@REDACTED Thu Dec 11 08:47:26 2003 From: nhead@REDACTED (nhead@REDACTED) Date: Thu, 11 Dec 2003 08:47:26 +0100 Subject: Erlang on RTEMS ... In-Reply-To: <16340.27328.966949.11535@antilipe.corelatus.se> References: <20031207000405.5288027b.nhead@houbits.com> <16340.27328.966949.11535@antilipe.corelatus.se> Message-ID: <20031211084726.01ad8880.nhead@houbits.com> On Mon, 8 Dec 2003 13:12:48 +0100 Matthias Lang wrote: > ... > It was Samuel Tardieu (i.e. not me) who was talking of porting Erlang > to RTEMS. I don't recall hearing any progress report, so I assume he > lost interest. Thanks Matthias, sorry for the false attribution. I guess maybe I'll try and find the time to look at it myself -- I'm sure there's a reason why it never happened! N. From ulf.wiger@REDACTED Thu Dec 11 07:11:23 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 11 Dec 2003 07:11:23 +0100 Subject: Small poll In-Reply-To: <5821-94666@sneakemail.com> References: <20031210233545.V29347-100000@valu.uninet.ee> <5821-94666@sneakemail.com> Message-ID: Lon, you saved me a lot of typing. I agree with all of what you wrote. /Uffe On Thu, 11 Dec 2003 04:39:00 +0100, Lon Willett wrote: > On ons, 2003-12-10 at 18:25, Kostis Sagonas wrote: >> I was wondering whether the Erlang user community would care >> to comment on the following: >> >> In a function like: >> >> test(A) -> >> a + 42. >> >> which is either crap (arguably) or a typo (A vs a), how many >> Erlang users: >> >> 1. Are content with the current situation where the compiler >> happily compiles this program >> 2. Would like to see a warning, but a .beam file generated >> nevetheless >> 3. Would prefer if the compiler in R10 refused to compile it > > I liked the "perlang" suggestion ;-). > > Seriously, my preference (in order) would be: #2, #3, #1. Or maybe #3 > by default, but a compiler option to use #2. > > I see three uses for writing such code: > > 1. As a programmer, one wants to know what exceptions will be generated > by certain error conditions, and/or how your program will react to > them. So one writes a little code that artificially generates such > errors. Such code is never released to the world. > > 2. As a tester, one may want to do much the same thing. I'm not really > sure that this case is really distinct from the first one, but in my > mind it is a different part of the process. Also, testers tend to be > rather less well versed in the subtleties of compiler behaviour, and > thus less capable of doing tricky things to "fool" the compiler. > > 3. One wants to generate a particular error in precisely the "standard" > format, regardless of how the internals of the erlang system may change > in future releases. > > I believe that case #3 is so rare that it is unimportant (or perhaps it > is even non-existent). But while they are not something that I would > raise a fuss about, I'm not sure that the first two cases should be > ignored. > > Just the other day, I was doing weird things to see what kind of NaNs > libm/pentium produce at runtime. I think I fooled gcc into actually > performing the nasty operations at run time instead of compile time (and > maybe it generates the same result even when it optimises the operations > away), but I may have made a mistake. It's nicer when one doesn't have > to play games with the compiler. > > (BTW, the semantics of floating point in erlang seem to be rather messed > up. Is their any intention to clean it up some time? I usually just > try to pretend that erlang doesn't have floats). > > On ons, 2003-12-10 at 22:44, Taavi Talvik wrote: >> Still disagree. Erlang specification does not disallow optimizing >> compilers, which try to evaluate constant expressions compile time. >> >> Language allready has special construct for throwing exceptions - >> throw(...). >> >> Why not force explicit usage of throw() instead of obscure evaluation >> side effects? > > I agree that an explicit exit() is almost always better. But isn't > exit() what you want, not throw()? If so, this demonstrates the point > that people aren't really so aware of the correct way to simulate > errors. So it might be better (occasionally) if they can just write > straightforward code to generate a desired error condition. > > /Lon > -- Ulf Wiger From vlad_dumitrescu@REDACTED Thu Dec 11 08:47:09 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 11 Dec 2003 08:47:09 +0100 Subject: Small poll References: <20031210233545.V29347-100000@valu.uninet.ee> <5821-94666@sneakemail.com> Message-ID: Hi, From: "Lon Willett" > 1. As a programmer, one wants to know what exceptions will be generated > by certain error conditions, and/or how your program will react to > them. So one writes a little code that artificially generates such > errors. Such code is never released to the world. In such a case, I'd rather have a default configuration that doesn't support such things (for production code) and a compiler option that makes it accept such erroneous code. regards, Vlad From francesco@REDACTED Thu Dec 11 08:44:42 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Thu, 11 Dec 2003 07:44:42 +0000 Subject: please help me References: <20031210143231.50059.qmail@web41906.mail.yahoo.com> Message-ID: <3FD8206A.5000109@erlang-consulting.com> Is this a University course being given somewhere? I always smile whenever Trinity College in Dublin gives Erlang courses, as you see the referrer logs to my site include searches on solutions which are obviously related to excercises. Regards, Francesco -- http://www.erlang-consulting.com Samir Terawi wrote: > dear sir, madam > I NEED HELP > I need to learn how can I implement my own erlang behaviours. > I need to learn the""SYNTAX"" that I need, so I can complete my > graduated project. > samir terawi. > ------------------------------------------------------------------------ > Do you Yahoo!? > New Yahoo! Photos - easier uploading and sharing > From peter@REDACTED Thu Dec 11 09:11:03 2003 From: peter@REDACTED (Peter Lund) Date: Thu, 11 Dec 2003 09:11:03 +0100 (CET) Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: <29650.149.254.120.139.1071130263.squirrel@www.lundata.se> I am certainly putting my money on no 1! The case when "a + 32" craches my code will be easily detected the first time I run that piece of code, and since I *do* test my code before delivery, this is a non-problem. I would not like having anyone wasting their valuable time improving the compiler to catch this and also wasting more CPU power on everyones computer when compiling. /Peter > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it > > Notice I am not talking about any serious attempt to static > type checking, but for really "basic" checks. > > Kostis. From Bengt.Kleberg@REDACTED Thu Dec 11 09:42:47 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Thu, 11 Dec 2003 09:42:47 +0100 Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: <3FD82E07.7050905@ericsson.com> Kostis Sagonas wrote: > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it i choose 3. bengt From joe@REDACTED Thu Dec 11 10:09:44 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 11 Dec 2003 10:09:44 +0100 (CET) Subject: Pgagmas (was Re: Small poll) In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: Well ... a + 42 IS legal code, it might be part of a test suit to test that the run-time exception handling stuff works. We need pragmas :-) a + 42 generates a hard compiler error (not like to today) and refuses to compile ie your (3) PRAGMA deliberate_error a + 42 END works like (1) This is what I called "intentionality" in my thesis :-) - the thing is you don't know why the programmer wrote 42+a - there are two cases a) The programmer knew it was an error, or, b) It was an error Adding a pragma allows the best of both worlds, :-) /DrJoe :-) On Wed, 10 Dec 2003, Kostis Sagonas wrote: > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it > > Notice I am not talking about any serious attempt to static > type checking, but for really "basic" checks. > > Kostis. > From D.WILLIAMS@REDACTED Thu Dec 11 10:20:39 2003 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Thu, 11 Dec 2003 10:20:39 +0100 Subject: Small poll Message-ID: > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it Hello, I am quite content with the current situation. I always compile with [warn_unused_vars], and even if A were used elsewhere I would detect the runtime error in my unit tests. Please don't make compile times any longer! Regards, Dominic Williams. From massimo.cesaro@REDACTED Thu Dec 11 10:16:32 2003 From: massimo.cesaro@REDACTED (Massimo Cesaro) Date: 11 Dec 2003 10:16:32 +0100 Subject: please help me In-Reply-To: <3FD8206A.5000109@erlang-consulting.com> References: <20031210143231.50059.qmail@web41906.mail.yahoo.com> <3FD8206A.5000109@erlang-consulting.com> Message-ID: <1071134193.1458.111.camel@xam> On Thu, 2003-12-11 at 08:44, Francesco Cesarini wrote: > Is this a University course being given somewhere? I always smile > whenever Trinity College in Dublin gives Erlang courses, as you see the > referrer logs to my site include searches on solutions which are > obviously related to excercises. > > Regards, > Francesco > -- > http://www.erlang-consulting.com Francesco, your mention of an Erlang course at a college triggered my consideration: Both Samir and Banat before (I guess they are collegues), asked the "syntax" for writing behaviours. Banat also asked how to implement some design patterns like connector/acceptor, active object, reactor and service control manager using Erlang. Solving the syntax problem is easy: just take a look of the source code of gen_server or another behaviour to see that writing behaviours is not rocket science. As for writing the well known patterns mentioned: they are all documented and implemented in C++ in the open source ACE C++ toolkit authored by D.C.Schmidt. I used to work with ACE for nearly all my telecomm related projects because several communication building blocks are there and they are portable as well. Then, this year I "discovered" Erlang *and* OTP: I was amazed to see that not only in OTP all the problems solved by the patterns in ACE have a solution. But usually the way they are implemented in Erlang is several order of magnitude simpler to understand and manage that the counterparts in C++, and usually even richer in features (the distribution features spring to mind). I think that comparing Erlang behaviours to C++ design patterns should be done very carefully because of the differences in the underlying conceptual model. Coming from a 10+ experience with C++, my biggest problem when approaching Erlang/OTP was to change my mindset. "Forgetting" about OO development and start "thinking" in Erlang.That was the moment I become productive, and I realized the power in OTP. I hope that the college teacher will be thinking in Erlang before asking to the students what could be nothing more than an intellectual exercise. Massimo > > Samir Terawi wrote: > > > dear sir, madam > > I NEED HELP > > I need to learn how can I implement my own erlang behaviours. > > I need to learn the""SYNTAX"" that I need, so I can complete my > > graduated project. > > samir terawi. > > ------------------------------------------------------------------------ > > Do you Yahoo!? > > New Yahoo! Photos - easier uploading and sharing > > > > > > From bjorn@REDACTED Thu Dec 11 10:25:19 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 11 Dec 2003 10:25:19 +0100 Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: We in the Erlang/OTP group at Ericsson have also discussed this question recently. For the R10B release, we will probably change the compiler according to #2 or #3. It is not hard that hard to do. What we will do is to keep line number information a bit longer so that the optimization passes that can easily detect this kind of type error also has access to the original line number when writing the message. In the Erlang/OTP group, there are different opinions whether #2 or #3 is the best way to go. Personally, I think that #2 is the way to go, but most others in the Erlang/OTP group seem to favor #3. /Bj?rn Gustavsson, Erlang/OTP, Ericsson AB Kostis Sagonas writes: > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it > > Notice I am not talking about any serious attempt to static > type checking, but for really "basic" checks. > > Kostis. > From bjorn@REDACTED Thu Dec 11 10:28:30 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 11 Dec 2003 10:28:30 +0100 Subject: (Fwd) Re: Small poll In-Reply-To: <3FD792F1.10359.6A8ACE@localhost> References: <3FD792F1.10359.6A8ACE@localhost> Message-ID: jonathan@REDACTED writes: > I would have thought that the majority of work for either 2 or 3 is > detecting the condition, so once you've implemented either, the other > is trivial. So isn't controlling the response generated via a > compiler flag, probably with option 3 the default, the most workable > solution? > > - Jonathan Coupe > Correct. My opinion is that #2 (a warning) should be implemented, then there should be a compiler option to make all warnings errors (like in C compilers). /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From pascal.brisset@REDACTED Thu Dec 11 10:33:47 2003 From: pascal.brisset@REDACTED (Pascal Brisset) Date: Thu, 11 Dec 2003 10:33:47 +0100 Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: <20031211093008.58F0054001A9@mwinf0602.wanadoo.fr> > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it I wanted to answer "3, of course" until I realized the follow-up poll questions might be embarrassing. - Suppose we reject a+42. Then what about: test(A) -> a<42. This is exactly the same typo. Can we also detect it and still allow < between arbitrary terms (e.g. keys in data structures) ? The ML way would be to declare < with the type: '<'(T,T) -> bool(). and allow the programmer to explicitly widen the type of operands to term() when needed. But this does not make sense without a clear notion of type inference (i.e. what is the type of 'a' ? atom() ? The atom 'a' ? a|42 ?). - More generally, the verification will not be complete. How do we explain the rationale when a programmer complains "Hey, the compiler caught this mistake, but not that one" ? - Should the compiler also reject: test(A) -> if a+42 == 0 -> true; a+42 =/= 0 -> false; true -> fish end. In other words, do people occasionally rely on the fact that exceptions are silently ignored in guards, possibly in more elaborate ways than above ? All things considered, obviously even a local, partial typechecker would be welcome. And since Christmas is approaching, #1 on my wishlist would be a tool which unifies in a consistent way: - a syntax for function and data type declarations - erldoc - typechecking - uniqatom - xref - user-definable, typed behaviours, as in: %% File: gen_server.bhv +defbehaviour gen_server(InitArg, State, Request, Result). +type handle_call(Request, {pid(),term()}, State) -> {reply, Result, State} | {reply, Result, State, timeout_val()} | {noreply, State} | {noreply, State, timeout_val()} | {stop, Reason, Result, State} | {stop, Reason, State}. - warnings related to the emulation of destructive updates with single assignment, as in: handle_call({set,NewValue}, From, State) -> State1 = State#state{val=NewValue}, State2 = State1#state{timestamp=now()}, {reply, ok, State1}. % Catch this. -- Pascal From D.WILLIAMS@REDACTED Thu Dec 11 10:35:29 2003 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Thu, 11 Dec 2003 10:35:29 +0100 Subject: Pgagmas (was Re: Small poll) Message-ID: Hi Joe, > We need pragmas :-) And macros, and conditional compilation, and packages... Pity, I was enjoying Erlang, now I might as well go back to C++. > This is what I called "intentionality" in my thesis :-) How did your "defense" go? > /DrJoe :-) Well, apparently! Congratulations, Dr! Regards, Dominic Williams. From Erik.Stenman@REDACTED Thu Dec 11 10:41:40 2003 From: Erik.Stenman@REDACTED (Erik Stenman) Date: Thu, 11 Dec 2003 10:41:40 +0100 Subject: Small poll In-Reply-To: <29650.149.254.120.139.1071130263.squirrel@www.lundata.se> Message-ID: <200312110941.hBB9f4M13115@hades.cslab.ericsson.net> You must be kidding, right? As it is now the compiler always does constant propagation and folding. If you write: A = 1 + 2, you get A = 3, in the compiled beam code. (These types of expressions do come up, especially if you are using macros...) The problem is that if you write a + 1, then the compiler has to spend extra time compiling the expression, handling the special case that constant folding does not work, and produce larger code than necessary. > I would not like having anyone wasting their valuable time > improving the compiler to catch this This already has to be cached and handled by the compiler. > and also wasting more > CPU power on everyones computer when compiling. More CPU power is probably used today in order to 'fix' this special case, at least for native code. Erik > -----Original Message----- > From: owner-erlang-questions@REDACTED > [mailto:owner-erlang-questions@REDACTED] On Behalf Of Peter Lund > Sent: Thursday,11 December, 2003 09:11 > To: kostis@REDACTED > Cc: erlang-questions@REDACTED > Subject: Re: Small poll > > I am certainly putting my money on no 1! > > The case when "a + 32" craches my code will be easily > detected the first time I run that piece of code, and since I > *do* test my code before delivery, this is a non-problem. I > would not like having anyone wasting their valuable time > improving the compiler to catch this and also wasting more > CPU power on everyones computer when compiling. > > /Peter > > > which is either crap (arguably) or a typo (A vs a), how many Erlang > > users: > > > > 1. Are content with the current situation where the compiler > > happily compiles this program > > 2. Would like to see a warning, but a .beam file generated > > nevetheless > > 3. Would prefer if the compiler in R10 refused to compile it > > > > Notice I am not talking about any serious attempt to static type > > checking, but for really "basic" checks. > > > > Kostis. > > > > From peter@REDACTED Thu Dec 11 11:19:55 2003 From: peter@REDACTED (Peter Lund) Date: Thu, 11 Dec 2003 11:19:55 +0100 (CET) Subject: Small poll In-Reply-To: <200312110941.hBB9f4M13115@hades.cslab.ericsson.net> References: <29650.149.254.120.139.1071130263.squirrel@www.lundata.se> <200312110941.hBB9f4M13115@hades.cslab.ericsson.net> Message-ID: <3726.149.254.120.139.1071137995.squirrel@www.lundata.se> If the effort (in sence of valuable time) already has been made, then it is obviously a good thing to have it doing 2 by default and 3 by adding some compiler directive. Erik Stenman wrote: > You must be kidding, right? > > As it is now the compiler always does constant propagation and folding. > If you write: > A = 1 + 2, > you get > A = 3, > in the compiled beam code. > (These types of expressions do come up, especially if you are using > macros...) > > The problem is that if you write > a + 1, > then the compiler has to spend extra time compiling the expression, > handling the > special case that constant folding does not work, and produce larger > code than necessary. > >> I would not like having anyone wasting their valuable time >> improving the compiler to catch this > > This already has to be cached and handled by the compiler. > >> and also wasting more >> CPU power on everyones computer when compiling. > > More CPU power is probably used today in order to 'fix' this > special case, at least for native code. > > Erik From vlad_dumitrescu@REDACTED Thu Dec 11 11:17:52 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 11 Dec 2003 11:17:52 +0100 Subject: Small poll References: <200312110941.hBB9f4M13115@hades.cslab.ericsson.net> Message-ID: Erm, a side question: since the question comes from the Hipe group, I feel compelled to check if it refers to the compiler in general or just the Hipe variant? regards, Vlad From peter@REDACTED Thu Dec 11 11:46:32 2003 From: peter@REDACTED (Peter Lund) Date: Thu, 11 Dec 2003 11:46:32 +0100 (CET) Subject: Pgagmas (was Re: Small poll) In-Reply-To: References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: <53869.149.254.120.139.1071139592.squirrel@www.lundata.se> > /DrJoe :-) Congratulations!! It was certainly a PhD that was overdue for some time now... :) /Peter From joe@REDACTED Thu Dec 11 15:56:26 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 11 Dec 2003 15:56:26 +0100 (CET) Subject: please help me In-Reply-To: <1071134193.1458.111.camel@xam> Message-ID: On 11 Dec 2003, Massimo Cesaro wrote: ... cut > As for writing the well known patterns mentioned: they are all > documented and implemented in C++ in the open source ACE C++ toolkit > authored by D.C.Schmidt. I used to work with ACE for nearly all my > telecomm related projects because several communication building blocks > are there and they are portable as well. Then, this year I "discovered" > Erlang *and* OTP: I was amazed to see that not only in OTP all the > problems solved by the patterns in ACE have a solution. But usually the > way they are implemented in Erlang is several order of magnitude simpler > to understand and manage that the counterparts in C++, and usually even > richer in features (the distribution features spring to mind). Shameless plug here: read chapter 4 of my thesis "Programming Techniques" and chapter 6 "Building an application" Chapter 4 shows how to "abstract out" concurrency - so you can write concurrent things (like client server models) with sequential plug-in code. Section 6.1.1 "How behaviours are written" goes into detail of the callback style of programming that is the basis for all behaviours. Once you've understood the basic idea you should find it easy to roll your own "custom" behaviours. The thesis is on-line at http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf /Joe From erlang@REDACTED Thu Dec 11 16:52:05 2003 From: erlang@REDACTED (Erlang Questions) Date: Thu, 11 Dec 2003 12:52:05 -0300 Subject: Mnesia whole table locked Message-ID: <006c01c3bffe$bc39f860$2100a8c0@mnesia> Hi, I've found in a mnesia:info(). (see attach) a lot of Lock: {{tarifftable,'______WHOLETABLE_____'}, My questions: 1. Why does it happen? 2. How can I prevent this situation? 3. How can I solve this? since my Mnesia data base is behaving a little strange since then Thanks a lot, Carlos.- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mnesia_info-plat0-db01.txt URL: From hakan@REDACTED Thu Dec 11 18:48:10 2003 From: hakan@REDACTED (Hakan Mattsson) Date: Thu, 11 Dec 2003 18:48:10 +0100 (MET) Subject: Mnesia whole table locked In-Reply-To: <006c01c3bffe$bc39f860$2100a8c0@mnesia> Message-ID: Carlos> Hi, I've found in a mnesia:info(). (see attach) a lot of Carlos> Carlos> Lock: {{tarifftable,'______WHOLETABLE_____'}, Carlos> Carlos> My questions: Carlos> Carlos> 1. Why does it happen? All operations that performs an exhaustive search of a Mnesia table can potentially grab a table lock. Typically it is operations like mnesia:match_object/3, mnesia:fold/3 and friends, but also Mnemosyne queries. Carlos> 2. How can I prevent this situation? Carlos> 3. How can I solve this? You need to analyze the access patterns that you have in your application. Avoid exhaustive searches in Mnesia in general and Mnemosyne in particular. Try to use key based lookup as far as possible (use mnesia:match_object/3 with a bound key or mnesia:read/2 directly). You could also consider dirty access if you have other means of synchronizing your access of the database. Carlos> since my Mnesia data base is behaving a little strange since then What do you mean with behaving strange? /H?kan --- H?kan Mattsson Ericsson High Availability Software, DBMS Internals http://www.erlang.org/~hakan/ From mbj@REDACTED Thu Dec 11 10:30:46 2003 From: mbj@REDACTED (Martin Bjorklund) Date: Thu, 11 Dec 2003 10:30:46 +0100 (CET) Subject: Small poll In-Reply-To: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: <20031211.103046.35872869.mbj@bluetail.com> Kostis Sagonas wrote: > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it I vote for #2 (followed by #3 + flag to force compilation, followed by #1, followed by plain #3). /martin From kostis@REDACTED Thu Dec 11 02:37:42 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 11 Dec 2003 02:37:42 +0100 (MET) Subject: Small poll In-Reply-To: Mail from 'Taavi Talvik ' dated: Wed, 10 Dec 2003 21:33:50 +0200 (EET) Message-ID: <200312110137.hBB1bgSX009022@hamberg.it.uu.se> Glad to receive so many responses. Let me reply on a few of them. > On Wed, 10 Dec 2003, Vlad Dumitrescu wrote: > > > > test(A) -> > > > a + 42. > > > > For the "A vs a" problem, there is already a warning being issued. Possibly > > the full warnings options should be enabled by default? First of all, let's disconnect this thread from "unused_variables" (although the warning **SHOULD** be turned on by default). Let's say that the program was: test(A) -> bar(A), a + 42. > > Since both a and 42 are constants, I feel it would be easy (besides useful) > > to be able to detect it at compile time. The operation should even be > > evaluated at compile time, IMHO. > > Exactly. And if compile time evaluation fails, give compile time error > {badarith,....}. Regardless of whether this is evaluated at compile time or not, there are still three options as I wrote in my previous mail: 1. the compiler happily compiles this program, but simply replaces a + 42 with a call to spit {badarith,....} 2. generate a warning, but also byte code. 3. the compiler refuses to compile such erroneous code. I will try to make a case for 3 below. Option 1, seems strange to me: The compiler has found out that a particular evaluation will result in an error, but does not inform its user about it and moreover generates more code (in terms of space) than that needed for the expression "a + 42" (if the expression is statically evaluated to badarith) or refuses to do work at compile time, leaving this work for run-time (which is what the BEAM compiler currently does). Option 2 on the surface seems a reasonable choice, but is it really ? I claim that at least 90% of all such cases are programming errors. As Taavi mentioned, if the programmer _really_ wants to generate an error, there is throw() and the a + 42 can be its argument (either as a string or as a tuple). Seems much, much cleaner to me. Now let me tell you why I am interested in 3: In the context of generating native code, it is really a nuisance to have to handle all sorts of illegal combinations of arguments to "basic" primitives like "+". Moreover, in the case of HiPE, because the compiler is (much) more sophisticated than the BEAM one, it actually discovers quite a lot more cases of such errors. Currently, we try our best to "immitate" the behaviour of the BEAM compiler, but in sleepless nights like this one, I keep wondering whether there should really be a limit to the level of naivety one pretends to show, or shouldn't there be? (Just in case it is not obvious, this is a more general issue, not just related to the simple "a+42" case I chose to illustrate my point.) Cheers, Kostis. PS. I am curious whether Eric Newhuis could elaborate on: > But we presently rely on this behavior and do not > treat it as a warning. Exactly how do you "rely" on this? From it2bajo@REDACTED Thu Dec 11 13:10:52 2003 From: it2bajo@REDACTED (Johannes Baldursson) Date: Thu, 11 Dec 2003 13:10:52 +0100 Subject: Text encoding problems Message-ID: <000601c3bfdf$d4d5a7d0$8b2d1081@ituniv238> Hi! I am currently developing an agent in erlang which takes news items from three different web sites and puts them in an RSS-file. My problem is that these sites use different text encodings, which becomes a huge problem when they are put in the same XML-file. Does anyone how to get through this problem? Can erlang convert the character encoding in some way? // Johannes Baldursson -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Thu Dec 11 11:47:02 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 11 Dec 2003 11:47:02 +0100 (MET) Subject: Small poll Message-ID: <200312111047.hBBAl2Qp011455@hamberg.it.uu.se> I've sent the following at about 3:00 last night, but have not seen it in the list yet. I am re-sending it again; apologies if you get it twice. Kostis. --------------------------------------------------------------------- Glad to receive so many responses. Let me reply on a few of them. > On Wed, 10 Dec 2003, Vlad Dumitrescu wrote: > > > > test(A) -> > > > a + 42. > > > > For the "A vs a" problem, there is already a warning being issued. Possibly > > the full warnings options should be enabled by default? First of all, let's disconnect this thread from "unused_variables" (although the warning **SHOULD** be turned on by default). Let's say that the program was: test(A) -> bar(A), a + 42. > > Since both a and 42 are constants, I feel it would be easy (besides useful) > > to be able to detect it at compile time. The operation should even be > > evaluated at compile time, IMHO. > > Exactly. And if compile time evaluation fails, give compile time error > {badarith,....}. Regardless of whether this is evaluated at compile time or not, there are still three options as I wrote in my previous mail: 1. the compiler happily compiles this program, but simply replaces a + 42 with a call to spit {badarith,....} 2. generate a warning, but also byte code. 3. the compiler refuses to compile such erroneous code. I will try to make a case for 3 below. Option 1, seems strange to me: The compiler has found out that a particular evaluation will result in an error, but does not inform its user about it and moreover generates more code (in terms of space) than that needed for the expression "a + 42" (if the expression is statically evaluated to badarith) or refuses to do work at compile time, leaving this work for run-time (which is what the BEAM compiler currently does). Option 2 on the surface seems a reasonable choice, but is it really ? I claim that at least 90% of all such cases are programming errors. As Taavi mentioned, if the programmer _really_ wants to generate an error, there is throw() and the a + 42 can be its argument (either as a string or as a tuple). Seems much, much cleaner to me. Now let me tell you why I am interested in 3: In the context of generating native code, it is really a nuisance to have to handle all sorts of illegal combinations of arguments to "basic" primitives like "+". Moreover, in the case of HiPE, because the compiler is (much) more sophisticated than the BEAM one, it actually discovers quite a lot more cases of such errors. Currently, we try our best to "immitate" the behaviour of the BEAM compiler, but in sleepless nights like this one, I keep wondering whether there should really be a limit to the level of naivety one pretends to show, or shouldn't there be? (Just in case it is not obvious, this is a more general issue, not just related to the simple "a+42" case I chose to illustrate my point.) Cheers, Kostis. PS. I am curious whether Eric Newhuis could elaborate on: > But we presently rely on this behavior and do not > treat it as a warning. Exactly how do you "rely" on this? From kent@REDACTED Thu Dec 11 23:56:58 2003 From: kent@REDACTED (Kent Boortz) Date: 11 Dec 2003 23:56:58 +0100 Subject: Small poll In-Reply-To: <200312111047.hBBAl2Qp011455@hamberg.it.uu.se> References: <200312111047.hBBAl2Qp011455@hamberg.it.uu.se> Message-ID: Kostis Sagonas writes: > I've sent the following at about 3:00 last night, but have not seen > it in the list yet. I am re-sending it again; apologies if you get > it twice. The delay is because you are not a member of the list using the address . I have to manually approve your postings each time (and today I had no access to my mail). You joined the list as , Do you want to change address or use both? kent From luke@REDACTED Fri Dec 12 00:00:07 2003 From: luke@REDACTED (Luke Gorrie) Date: 12 Dec 2003 00:00:07 +0100 Subject: Small poll In-Reply-To: <200312110137.hBB1bgSX009022@hamberg.it.uu.se> References: <200312110137.hBB1bgSX009022@hamberg.it.uu.se> Message-ID: Kostis Sagonas writes: > Now let me tell you why I am interested in 3: > > In the context of generating native code, it is really a nuisance > to have to handle all sorts of illegal combinations of arguments > to "basic" primitives like "+". Moreover, in the case of HiPE, > because the compiler is (much) more sophisticated than the BEAM > one, it actually discovers quite a lot more cases of such errors. > Currently, we try our best to "immitate" the behaviour of the BEAM > compiler, but in sleepless nights like this one, I keep wondering > whether there should really be a limit to the level of naivety > one pretends to show, or shouldn't there be? Another option would be "2.5". Suppose the function is: foo(A) -> X = a+42, bar(X). having detected the problem you could compile it as essentially: foo(A) -> throw({badarith, a, 42}). Would that ease the compiler work any? Some other compilers do exactly this. I know because once, due to a type-inferencer bug, I got a message like: Error: 42 is not an integer. because the compiler had wrongly convinced itself that a variable could never be bound to an integer, but at runtime when the error was generated it actually was :-) From enewhuis@REDACTED Fri Dec 12 00:10:34 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 11 Dec 2003 17:10:34 -0600 Subject: Fwd: Small poll Message-ID: <3955BD62-2C2F-11D8-8E78-000A95D9A520@futuresource.com> >> PS. I am curious whether Eric Newhuis could elaborate on: >> >>> But we presently rely on this behavior and do not >>> treat it as a warning. >> >> Exactly how do you "rely" on this? >> > > Wonder not. Sorry; I misinterpreted your query. I thought this was > an "undefined variable" issue. Since it is not I hereby redact my > statement. > > On the other hand I am glad to hear that HIPE does more checking. The > Engineer in me wants as many constraints as are possible to enforce so > I can avoid writing a number of runtime tests. Yes I love Erlang. > But I sure do miss the days of defining my own rules in C++ and > letting the compiler check them for me. Please keep up the good work > with the HIPE compiler. > > Sincerely, > Eric > From ok@REDACTED Fri Dec 12 00:30:09 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 12 Dec 2003 12:30:09 +1300 (NZDT) Subject: Small poll Message-ID: <200312112330.hBBNU8vg043805@atlas.otago.ac.nz> Concerning test(A) -> a + 42. /* 1 */ I like to have tools that I can form mental models of. Suppose we have a compiler that catches the clause above. Now let's change it: test(A) -> X = a, X + 42. /* 2 */ Now /* 2 */ _ought_ to have exactly the same semantics as /* 1 */. But will it? Not if the compiler lets /* 2 */ past but rejects /* 1 */. To be consistent, the compiler had better do some kind of data flow analysis. But then we bring in test(A) -> f(A) + 42. /* 3 */ f(A) -> a. Apart from tracing, run time, and number of reductions, we'd expect /* 3 */ to behave just like /* 1 */. Is it proposed that the compiler will catch this also? Now we're into inter-procedural data flow analysis. In order to predict which clauses will be rejected and which will be allowed through, suddenly I have to know more than syntax rules and variable scope, I have to know quite a bit about how the compiler works. Now let's try another one. This one is NOT expected to have the same semantics as /* 1 */, /* 2 */, or /* 3 */. test(A) -> if 0==0 -> A+42 ; 1==0 -> a+42 end. /* 4 */ Why should the compiler warn about a+42 when there is no possibility of that expression ever being evaluated? In order to figure out whether /* 4 */ will be accepted or rejected, I have to know whether the compiler does its weak type checking before or after dead code elimination. A compiler can warn about anything. There's nothing to stop a compiler saying "Warning: your PC has a camera, you are UGLY." or even "Warning: code compiled on Friday 13 may not work" or "Warning: I've seen this before and I didn't like it then either". But *inconsistent* rejection is another matter entirely. Consider the following Haskell program as an analogue: module Main(main) where main = print (x `div` x) x :: Int x = 0 This is guaranteed to produce an error at run time. Guaranteed. 0 is not a legal right argument for `div`; this is just like the fact that 'a' is not a legal argument for + . I tried this program with three different Haskell compilers. All of them were completely silent about it at compile time. All of them gave a run time exception. Yet some of them do quite serious unfolding; at least one of them _must_ have noticed that I was asking for (0 `div` 0). My vote would therefore be for option 2: warn about it but still generate code. From luke@REDACTED Fri Dec 12 02:48:25 2003 From: luke@REDACTED (Luke Gorrie) Date: 12 Dec 2003 02:48:25 +0100 Subject: Small poll In-Reply-To: <200312110137.hBB1bgSX009022@hamberg.it.uu.se> References: <200312110137.hBB1bgSX009022@hamberg.it.uu.se> Message-ID: Kostis Sagonas writes: > 1. the compiler happily compiles this program, but simply replaces > a + 42 with a call to spit {badarith,....} (Oops, I see you were way ahead of me already. I was too eager to share that '42 not integer' anecdote :-)) From ok@REDACTED Fri Dec 12 03:01:16 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 12 Dec 2003 15:01:16 +1300 (NZDT) Subject: Small poll Message-ID: <200312120201.hBC21GVT046388@atlas.otago.ac.nz> Kostis Sagonas wrote: Option 2 on the surface seems a reasonable choice, but is it really ? I claim that at least 90% of all such cases are programming errors. And a warning from the compiler tells the programmer about it. In the context of generating native code, it is really a nuisance to have to handle all sorts of illegal combinations of arguments to "basic" primitives like "+". But choosing option 3 does not remove this requirement. -module(foo). -export(bar/1). bar(X) -> X + 42. a+42 is *not* the typical case. This is. And it is precisely in this case that you have no idea what X is going to be. The following cases are surely legal: fixnum + fixnum -- add, may overflow and generate bignum fixnum + bignum -- call out-of-line code fixnum + flonum -- convert, add, box (lazily) bignum + fixnum -- call out-of-line code bignum + bignum -- call out-of-line code bignum + flonum -- call out-of-line code flonum + fixnum -- convert, add, box (lazily) flonum + bignum -- call out-of-line code flonum + flonum -- add, box (lazily) By box (lazily) I mean that the compiler may leave the result in a floating-point register and only box it when/if it is returned or included in a data structure. With 9 legal cases, surely handling one more ("none of the above") is no big deal. There would appear to be the following interesting cases: (1) The compiler can prove that X and Y are fixnums: addcc X, Y, result bpvs,pn %icc,overflow_handler nop (2) The compiler can prove that X is a fixnum and Y a flonum: (get X into an fp register as 32-bit integer; get Y into an fp reg.) fitod fX, fX fadd fX, fY, fresult (3) The compiler can prove that X is a flonum and Y a fixnum: (get Y into fp reg as 32-bit integer; get X into fp reg.) fitod fY, fY fadd fX, fY, fresult (4) The compiler can prove that X and Y are both flonums fadd fX, fY, fresult (5) None of the above taddcc X, Y, result bpvc,pt %icc,1f nop call general_case nop 1: Or, on a machine without tagged add, or X, Y, result andcc result, 3, %g0 bpnz,pn 1f add X, Y, result bpvc,pt %icc,2f nop 1: call general_case nop 2: This can be simplified a bit. Suppose Y, for example, is a constant which will bit as an immediate operand. Then andcc X, 3, %g0 bpnz,pn 1f add X, immedY, result bpvc,pt %icc,2f nop 1: call general_case set immedY, Y 2: But it really can't be simplified _much_. The problem with (1), of course, is that just because the operands of + are both fixnums doesn't mean the result is; the result could be a fixnum or a bignum, so when you do X+X+X the second add has to be the general case (simplified because we don't need the 'or'; we know X is still fixnum, but we _don't_ know that X+X is). There are only three ways I can think of to get an integer calculation down to a single instruction: (1) Use taddcctv, which traps on overflow, and put the general case in the trap handler. However, that does nasty things to an Ultra's pipeline and is now a deprecated instruction. Keeps the code short, though. This only works for add, subtract, and compare, of course, and isn't available for most machines. (2) Use some really amazing interval analysis as well as type inference. Erlang doesn't give you much to get started with, though. About the only thing I can think of is that starting with size(_) and counting down towards 0 should be safe. (3) Stop supporting Erlang, and implement a related language in which only fixnums exist, no bignums. (There was some discussion at one time about having the Erlang standard only require 64-bit integers, but even those would count as bignums on a 32-bit machine.) Of course this would cause great problems interoperating with C, Java, CORBA, and so on (C99, Java, and CORBA all require 64-bit integers, don't they?), so that won't do. Moreover, in the case of HiPE, because the compiler is (much) more sophisticated than the BEAM one, it actually discovers quite a lot more cases of such errors. That's great. So issue a lot more warnings. The BEAM and HiPE compilers should accept *exactly* the same language. (Although HiPE could "accept" some files in the sense of giving up and leaving them as BEAM.) But "accept" is not the same as "not warn about". I keep wondering whether there should really be a limit to the level of naivety one pretends to show, or shouldn't there be? This is an argument against option 1. It is NOT an argument for option 3. Option 2 (complain loudly but accept, compatibly with BEAM, and generate code which generates compatible run-time behaviour) is also non-naive. From cpressey@REDACTED Fri Dec 12 04:47:56 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 11 Dec 2003 19:47:56 -0800 Subject: ANN: erlxec (was: Re: small poll) Message-ID: <20031211194756.41b4883c.cpressey@catseye.mine.nu> On Thu, 11 Dec 2003 10:20:39 +0100 "WILLIAMS Dominic" wrote: > Please don't make compile times any longer! If it's the slowness of "erlc" that's got you down, you might want to check out "erlxec": http://catseye.webhop.net/projects/erlxec-2003.1211/ http://catseye.webhop.net/projects/erlxec-2003.1211.tgz (Those who are Tragically Firewalled may have better luck trying http://www3.telus.net/~cpressey/distfiles/erlxec-2003.1211.tgz instead.) erlxec is basically a rewrite, in C, of a Perl script I was working on a couple of months ago called 'tellerl'. erlxec is like erl_call, except optimized for running Erlang functions as if they were utility programs, from the operating system shell. The logic goes kind of like this: - The startup and shutdown times of the BEAM emulator are dismal. - But that's forgivable, because it's primarily for long-running tasks, not short-lived utilities. - But "erlc" is a short-lived utility and it starts a BEAM emulator. - But you can get around that by using c(module) in EShell. - But you can't do that inside a Makefile without, uhm, starting a BEAM emulator. - But you can start a BEAM emulator in the background first, then use erl_call. - But erl_call doesn't understand when you change the current working directory and/or environment variables, and other little things. - So write a little program like erl_call except different. It's still at the proof-of-concept stage, but the proof is in the pudding (or test run, as the case may have it) (drum roll, please): - A rebuild of the entire Jungerl, with "ERLC := /usr/local/bin/erlc", took 10 minutes 24 seconds on my machine. - With "ERLC := erlxec erlc" it took only 5 minutes 4 seconds. The source code (erlxec.c) more than likely has some FreeBSDisms in it; I'd greatly appreciate some help making it more portable, even if it's only a report of how it fails to compile on Linux and other systems. -Chris From bjorn@REDACTED Fri Dec 12 10:55:02 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 12 Dec 2003 10:55:02 +0100 Subject: Compiler warnings in R10B Message-ID: We will change default warning behaviour in the Erlang compiler in R10B like this: When using 'erlc', by default warnings will be turned on. To disable all warnings, use the '-W0' flag. To turn on maximum warnings, use '-Wall'. When using either 'erlc' or the Erlang compiler from the shell, by default 'warn_unused_vars' is turned on. (Use 'nowarn_unused_vars' to turn it off.) We will probably also introuduce an option to turn warnings to errors. At the same, we will look at how certains warning can be turned off. For instance, if you deliberately name a function 'size/1' in a module, it should be possible to turn off the warning that you are re-defining a BIF. /Bjorn -- /Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bjorn@REDACTED Fri Dec 12 11:08:21 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 12 Dec 2003 11:08:21 +0100 Subject: Small poll In-Reply-To: <200312110137.hBB1bgSX009022@hamberg.it.uu.se> References: <200312110137.hBB1bgSX009022@hamberg.it.uu.se> Message-ID: Kostis Sagonas writes: [...] > Now let me tell you why I am interested in 3: > > In the context of generating native code, it is really a nuisance > to have to handle all sorts of illegal combinations of arguments > to "basic" primitives like "+". Moreover, in the case of HiPE, > because the compiler is (much) more sophisticated than the BEAM > one, it actually discovers quite a lot more cases of such errors. > Currently, we try our best to "immitate" the behaviour of the BEAM > compiler, but in sleepless nights like this one, I keep wondering > whether there should really be a limit to the level of naivety > one pretends to show, or shouldn't there be? > We in the OTP team are planning for the R10B release to generate more warnings for suspect code. We will do that in one of the Core Erlang passes (which is common pass used for both threaded Beam code and native HiPE code). At the same time as the warning is generated, the offending code will be replaced with an explicit failure (e.g. erlang:fault/2), that should be no problem for the later HiPE passes to handle. Thus, the work only needs to be done once. As I have already written in a previous answer, we have different opinions within the Erlang/OTP team at Ericsson whether #2 or #3 is the best solution, but as someone pointed out, most of work is in detecting the suspect code anyway. Either #2 or #3 will be implemented in the common parts of the compiler in R10B. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From Bengt.Kleberg@REDACTED Fri Dec 12 11:39:06 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Fri, 12 Dec 2003 11:39:06 +0100 Subject: Compiler warnings in R10B In-Reply-To: References: Message-ID: <3FD99ACA.10003@ericsson.com> Bjorn Gustavsson wrote: > We will change default warning behaviour in the Erlang > compiler in R10B like this: > > When using 'erlc', by default warnings will be turned on. > To disable all warnings, use the '-W0' flag. To turn on > maximum warnings, use '-Wall'. > thank you very much. i hope for a default of '-Wall' some time in the future. bengt From hal@REDACTED Fri Dec 12 12:41:49 2003 From: hal@REDACTED (Hal Snyder) Date: Fri, 12 Dec 2003 05:41:49 -0600 Subject: Network benchmark Message-ID: <87k752z2iq.fsf@ghidra.vail> Of course, while Erlang could do session setup and teardown, it is much too slow to handle the media streams in VoIP, right? We started wondering about this "obvious fact" while Lennart was here this week. Below is a test program to bite off chunks of data from a file already read into memory, format them in RTP packets, and write to UDP as fast as possible, to get an upper limit on speed. We ran it on a 2MB or so file. Here are the results (destination IP address changed): > file_to_rtp:send(F,{10,1,1,1},0,40000). {read,{ok,<<2024386 bytes>>}} {1071,227577,57003} {{12,249,8,82},40000,#Port<0.111>,<<2024386 bytes>>,0,0} {bytes,2024386,packets,12653} elapsed_sec 0.252 bits_per_sec 64171492.9 ok Considering that a typical voice channel is 64000 bits/sec, that is about 1000 x faster than we need, and close to line speed for the 100baseTX interface used. BTW, the OS is FreeBSD-5.0. CPU: Pentium 4 (1816.18-MHz 686-class CPU) ... real memory = 268419072 (255 MB) I'd be interested in reports from other platforms, including Sparc and Win32. Running the program a second time may be faster due to having the file paged in. Of course, we need to see how many other activities can go on in a node when handling RTP - scheduler granularity may be a problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: file_to_rtp.erl Type: application/octet-stream Size: 1545 bytes Desc: file_to_rtp.erl URL: From sean.hinde@REDACTED Fri Dec 12 13:37:50 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Fri, 12 Dec 2003 12:37:50 +0000 Subject: Network benchmark In-Reply-To: <87k752z2iq.fsf@ghidra.vail> References: <87k752z2iq.fsf@ghidra.vail> Message-ID: On 12 Dec 2003, at 11:41, Hal Snyder wrote: > Of course, while Erlang could do session setup and teardown, it is > much too slow to handle the media streams in VoIP, right? We started > wondering about this "obvious fact" while Lennart was here this week. > > Below is a test program to bite off chunks of data from a file already > read into memory, format them in RTP packets, and write to UDP as fast > as possible, to get an upper limit on speed. We ran it on a 2MB or so > file. Here are the results (destination IP address changed): > >> file_to_rtp:send(F,{10,1,1,1},0,40000). > {read,{ok,<<2024386 bytes>>}} > {1071,227577,57003} > {{12,249,8,82},40000,#Port<0.111>,<<2024386 bytes>>,0,0} > {bytes,2024386,packets,12653} > elapsed_sec 0.252 bits_per_sec 64171492.9 > ok > > Considering that a typical voice channel is 64000 bits/sec, that is > about 1000 x faster than we need, and close to line speed for the > 100baseTX interface used. > > BTW, the OS is FreeBSD-5.0. > CPU: Pentium 4 (1816.18-MHz 686-class CPU) > ... > real memory = 268419072 (255 MB) > > I'd be interested in reports from other platforms, including Sparc and > Win32. Running the program a second time may be faster due to having > the file paged in. > > Of course, we need to see how many other activities can go on in a > node when handling RTP - scheduler granularity may be a problem. > > We have a HTTP proxy here which will happily stream 50Mbits/sec through the erlang node - all traffic coming in and out of the same 100BaseT interface (this was on my 1GHz Powerbook). I'd say that this was pretty reasonable. I also tried running this with a few hundred clients pulling the same large file from the web server, and overall throughput didn't slow down all that much. What you might need to be careful of in your small benchmark is that the inet driver internally queues a certain amount of data so you would see the send completed from the Erlang side before the data was actually sent out to the network. A larger file would perhaps give a better reading. Recently Luke mentioned doing some profiling of the whole system doing something similar - I wonder how he got on - Luke? Sean From bry@REDACTED Fri Dec 12 14:13:53 2003 From: bry@REDACTED (bryan) Date: Fri, 12 Dec 2003 14:13:53 +0100 Subject: erlang and dde In-Reply-To: <000601c3bfdf$d4d5a7d0$8b2d1081@ituniv238> Message-ID: <001301c3c0b1$ca9b36e0$2001a8c0@bryans> Hi, I have a situation that requires building a DDE (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/ winui/windowsuserinterface/dataexchange/dynamicdataexchange.asp) monitor and making it accessible via the command line. The monitor needs to be able to be queried for specific events, and return the data related to those events. I was thinking that Erlang might be a good solution, as I worry about having a lot of possible messages being exchanged. So has anyone done anything with using Erlang to monitor DDE? -------------- next part -------------- An HTML attachment was scrubbed... URL: From enano@REDACTED Fri Dec 12 14:26:44 2003 From: enano@REDACTED (Miguel Barreiro) Date: Fri, 12 Dec 2003 14:26:44 +0100 (CET) Subject: Network benchmark In-Reply-To: <87k752z2iq.fsf@ghidra.vail> References: <87k752z2iq.fsf@ghidra.vail> Message-ID: Hal, > Of course, while Erlang could do session setup and teardown, it is > much too slow to handle the media streams in VoIP, right? We started > wondering about this "obvious fact" while Lennart was here this week. I've faced the same situation with video streaming and the Erlang runtime is fast enough for sending several tens of megabits of MPEG-2 video as Transport Streams over UDP with relatively low jitter. The opposite, however (receiving streams and parsing braindead headers such as those in MPEG PS/PES packets) involves quite a bit of bitsyntax matching and is relatively inefficient. > Of course, we need to see how many other activities can go on in a > node when handling RTP - scheduler granularity may be a problem. VoIP granularity requirements are tighter than those of video, but still you may be happily surprised. Regards, Miguel From vlad_dumitrescu@REDACTED Fri Dec 12 16:03:24 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 12 Dec 2003 16:03:24 +0100 Subject: erlang and dde References: <001301c3c0b1$ca9b36e0$2001a8c0@bryans> Message-ID: > So has anyone done anything with using Erlang to monitor DDE? Hi, Not me :-) It might be cool, even if I thought DDE was dead and buried ;-) I think a good way to handle this is to write a port program that will act as the DDE-enabled application and let it just dump the requests to the Erlang side for processing. But I feel it's going to be quite tricky to map the DDE protocol to the asynchronous Erlang style... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke@REDACTED Fri Dec 12 16:23:55 2003 From: luke@REDACTED (Luke Gorrie) Date: 12 Dec 2003 16:23:55 +0100 Subject: Network benchmark In-Reply-To: References: <87k752z2iq.fsf@ghidra.vail> Message-ID: Sean Hinde writes: > We have a HTTP proxy here which will happily stream 50Mbits/sec > through the erlang node - all traffic coming in and out of the same > 100BaseT interface (this was on my 1GHz Powerbook). [...] > Recently Luke mentioned doing some profiling of the whole system doing > something similar - I wonder how he got on - Luke? I haven't done anything more, but we have had Erlang merrily pushing through ~100Mbps of ethernet frames on PC hardware. It was proxying between a Linux 'tap' ethernet interface and a UDP socket, and not doing any decoding of the packets at all. IIRC it was a 2.4Ghz CPU and the CPU cost was about one percent per megabit - seemed to scale linearly and used the whole CPU to push ~100Mbps. In that benchmark the data was originating locally on the machine, coming in the tap interface, then being sent through UDP over a real network. The total load on the box would presumably be somewhat higher if we were proxying between two real networks, due to the extra work for the kernel. Profiler-wise, IIRC about ~60% of the time was spent in kernel space, and from 'strace' Erlang seemed to be doing reasonable system calls, so I was pretty happy with Erlang's overall performance. >From Hal's report it's exciting to think you could have high throughput while actually bit-syntax hacking the packets as they went through! -Luke From enewhuis@REDACTED Fri Dec 12 16:59:22 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 12 Dec 2003 09:59:22 -0600 Subject: Network benchmark In-Reply-To: References: <87k752z2iq.fsf@ghidra.vail> Message-ID: <271BF507-2CBC-11D8-95E1-000A95D9A520@futuresource.com> > I haven't done anything more, but we have had Erlang merrily pushing > through ~100Mbps of ethernet frames on PC hardware. For what its worth we've been peaking at 512 Mbps in our Erlang system and plan on going higher. We run cool at over 128 Mbps. > From Hal's report it's exciting to think you could have high > throughput while actually bit-syntax hacking the packets as they went > through! We bit-syntax parse and store in ETS all of that traffic. (Well we're not actually storing the whole stream. It is a transaction stream that mutates the data in the ETS tables.) From hal@REDACTED Fri Dec 12 18:23:41 2003 From: hal@REDACTED (Hal Snyder) Date: Fri, 12 Dec 2003 11:23:41 -0600 Subject: Network benchmark - header parsing In-Reply-To: (Miguel Barreiro's message of "Fri, 12 Dec 2003 14:26:44 +0100 (CET)") References: <87k752z2iq.fsf@ghidra.vail> Message-ID: <87he0654rm.fsf_-_@ghidra.vail> Miguel Barreiro writes: > I've faced the same situation with video streaming and the Erlang > runtime is fast enough for sending several tens of megabits of > MPEG-2 video as Transport Streams over UDP with relatively low > jitter. > > The opposite, however (receiving streams and parsing braindead > headers such as those in MPEG PS/PES packets) involves quite a bit > of bitsyntax matching and is relatively inefficient. We are certainly interested in parsing headers efficiently. SIP headers should permit the same sort of optimization that's done with {packet,http} - in fact it doesn't look too hard to make something general in which the header names could be loaded after startup. What sort of header munging is the slow part for your inbound processing? I am favorably impressed with bit syntax performance, to put it mildly. But, reflecting on recent mention on this list about regexes, would a set of regexes-for-binaries ops would help speed things up? From luke@REDACTED Fri Dec 12 19:01:19 2003 From: luke@REDACTED (Luke Gorrie) Date: 12 Dec 2003 19:01:19 +0100 Subject: Small poll In-Reply-To: <200312120201.hBC21GVT046388@atlas.otago.ac.nz> References: <200312120201.hBC21GVT046388@atlas.otago.ac.nz> Message-ID: "Richard A. O'Keefe" writes: > There are only three ways I can think of to get an integer calculation > down to a single instruction: [...] > (2) Use some really amazing interval analysis as well as type inference. > Erlang doesn't give you much to get started with, though. About the > only thing I can think of is that starting with size(_) and counting > down towards 0 should be safe. Related to the "Network benchmark" thread: one place in Erlang that you get precise integer-size type information is with the bit syntax, e.g. "<> = Bin, X + Y" adds two 16-bit fixnums. Is that a single-instruction case? It's possible to imagine a heavy duty optimizer generating fast code for e.g. checksumming an IP packet, doing lots of 16-bit arithmetic on values coming out of a binary. No idea if that's practical, but maybe something to drool over in idle hours ;-) By the way, at EUC Thomas Lindgren mentioned the bother of taking care of "bump reductions" in loops, and Tony Rogvall said something to the effect of "or we could get rid of bump_reductions and do it properly instead." What would be the "proper" way? Cheers, Luke From luke@REDACTED Sat Dec 13 00:50:57 2003 From: luke@REDACTED (Luke Gorrie) Date: 13 Dec 2003 00:50:57 +0100 Subject: Network benchmark In-Reply-To: <271BF507-2CBC-11D8-95E1-000A95D9A520@futuresource.com> References: <87k752z2iq.fsf@ghidra.vail> <271BF507-2CBC-11D8-95E1-000A95D9A520@futuresource.com> Message-ID: Eric Newhuis writes: > For what its worth we've been peaking at 512 Mbps in our Erlang system > and plan on going higher. We run cool at over 128 Mbps. I want a computer like yours. :-) From enano@REDACTED Sun Dec 14 18:17:46 2003 From: enano@REDACTED (Miguel Barreiro) Date: Sun, 14 Dec 2003 18:17:46 +0100 (CET) Subject: Network benchmark - header parsing In-Reply-To: <87he0654rm.fsf_-_@ghidra.vail> References: <87k752z2iq.fsf@ghidra.vail> <87he0654rm.fsf_-_@ghidra.vail> Message-ID: > We are certainly interested in parsing headers efficiently. SIP > headers should permit the same sort of optimization that's done with > {packet,http} - in fact it doesn't look too hard to make something > general in which the header names could be loaded after startup. > > What sort of header munging is the slow part for your inbound > processing? MPEG PES headers are binary and clearly intended to be processed in hardware. As a short introduction, a PS ("program stream" - what you store on a DVD, for instance) is a sequence of "packs". Each "pack" may contain an almost arbitrary number of PES ("packetized elementary streams") packets. The first packet in any pack may be a system header. Several important values (system clock references) are stored on pack headers. The catch is that pack headers contain no length information: you have to read each packet (of variable length), parse it, and check whether you have reached the end of the pack. To make things worse, clocks are stored in a fashion as "most significant part in multiples of 900KHz split into three parts: 3 bits here, 15 bits there, 15 bits there... least significant part in multiples of 27MHz, up to 22 bits, over there... and finally a variable amount of stuffing before actual video/audio payload". Smoke at ISO meetings must be really funny. It's not the same as parsing HTTP or SIP headers. > I am favorably impressed with bit syntax performance, to put it > mildly. But, reflecting on recent mention on this list about regexes, > would a set of regexes-for-binaries ops would help speed things up? In this case, it would save a fair number of matchings. It might be worthwhile or not depending on relative efficiency to "normal" bitsyntax matching. From erlang@REDACTED Mon Dec 15 09:06:40 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Mon, 15 Dec 2003 08:06:40 +0000 Subject: Network benchmark - header parsing In-Reply-To: References: <87k752z2iq.fsf@ghidra.vail> <87he0654rm.fsf_-_@ghidra.vail> Message-ID: <20031215080640.04ffcdfc.erlang@manderp.freeserve.co.uk> Someone mention SIP parsing using bit-syntax? I'm currently writing a SIP message parser using pattern matching on lists. I was wondering if anyone would be kind enough to share their thoughts and experience about using binaries instead. How would I handle syntax such as: Timestamp = "Timestamp" HCOLON 1*( DIGIT ) ["." *( DIGIT )] [LWS delay] delay = *( DIGIT ) ["." *( DIGIT )] LWS = [*WSP CRLF] 1*WSP Doing this in list pattern matching is easy. I'm concerned that if I pattern-matched a binary, I would end up making many copies of the binary. Or am I imagining false problems which don't exist? I notice that the Megaco stack uses a link-in C driver that is generated using lex. Would this be the most effective way of parsing SIP, instead on parsing a list? Pete. On Sun, 14 Dec 2003 18:17:46 +0100 (CET) Miguel Barreiro wrote: > > > We are certainly interested in parsing headers efficiently. SIP > > headers should permit the same sort of optimization that's done with > > {packet,http} - in fact it doesn't look too hard to make something > > general in which the header names could be loaded after startup. > > > > What sort of header munging is the slow part for your inbound > > processing? > > MPEG PES headers are binary and clearly intended to be processed in > hardware. As a short introduction, a PS ("program stream" - what you store > on a DVD, for instance) is a sequence of "packs". Each "pack" may contain > an almost arbitrary number of PES ("packetized elementary streams") > packets. The first packet in any pack may be a system header. Several > important values (system clock references) are stored on pack headers. The > catch is that pack headers contain no length information: you have to > read each packet (of variable length), parse it, and check whether you > have reached the end of the pack. To make things worse, clocks are stored > in a fashion as "most significant part in multiples of 900KHz split into > three parts: 3 bits here, 15 bits there, 15 bits there... least > significant part in multiples of 27MHz, up to 22 bits, over there... and > finally a variable amount of stuffing before actual video/audio payload". > Smoke at ISO meetings must be really funny. > > It's not the same as parsing HTTP or SIP headers. > > > I am favorably impressed with bit syntax performance, to put it > > mildly. But, reflecting on recent mention on this list about regexes, > > would a set of regexes-for-binaries ops would help speed things up? > > In this case, it would save a fair number of matchings. It might be > worthwhile or not depending on relative efficiency to "normal" > bitsyntax matching. > > -- "The Tao of Programming flows far away and returns on the wind of morning." From alexey@REDACTED Mon Dec 15 14:05:27 2003 From: alexey@REDACTED (Alexey Shchepin) Date: Mon, 15 Dec 2003 15:05:27 +0200 Subject: Mnesia crash Message-ID: <8765gigrjc.fsf@office.sevcom.net> Hi! Few days ago there was power failure on jabber.ru with working ejabberd. After system was started, ejabberd loaded without problems. But yesterday, after restarting using init:restart(), the following errors appears in log: =ERROR REPORT==== 2003-12-15 00:12:21 === ** dets: Bug was found when accessing table roster, ** dets: operation was {lookup_keys,[{"xxxxx", {"xxxxxxxxx","icq.jabber.ru",[]}}]} and reply was {1,'EXIT'}. =ERROR REPORT==== 2003-12-15 00:12:22 === Mnesia('ejabberd@REDACTED'): ** ERROR ** (core dumped to file: "/usr/home/ermine/server/ejabberd/src/MnesiaCore.ejabberd@REDACTED") ** FATAL ** mnesia_locker crashed: {badarg, [{erlang, '++', [{badarith, [{dets_v9,slot_position,1}, {dets_v9,eval_work_list,2}, {dets,update_cache,2}, {dets,stream_end,5}, {dets,do_apply_op,4}, {proc_lib,init_p,5}]}, [{roster, {"xxxxx", {"xxxxxxxx", "icq.jabber.ru", []}}, "xxxxx", ... {lists,append,2}, {mnesia_locker, set_read_lock_on_all_keys, 6}, {mnesia_locker,loop,1}, {mnesia_sp,init_proc,4}, {proc_lib,init_p,5}]} state: [<0.85.0>] Is this is because of previous crash, or this is bug in dets or mnesia? Information that probably needed: Erlang version: R9C OS: FreeBSD 4.9 Result of mnesia:schema(roster): -- Properties for roster table --- access_mode -> read_write active_replicas -> ['ejabberd@REDACTED'] arity -> 10 attributes -> [uj,user,jid,name,subscription,ask,groups,xattrs,xs] checkpoints -> [] commit_work -> [{index,set,[{3,{dets,{roster,index,3}}}]}] cookie -> {{1067,256640,401479},'ejabberd@REDACTED'} disc_copies -> [] disc_only_copies -> ['ejabberd@REDACTED'] frag_properties -> [] index -> [3] load_by_force -> false load_node -> 'ejabberd@REDACTED' load_order -> 0 load_reason -> local_only local_content -> false master_nodes -> [] memory -> 30050014 ram_copies -> [] record_name -> roster record_validation -> {roster,10,set} setorbag -> set size -> 131139 snmp -> [] storage_type -> disc_only_copies subscribers -> [] user_properties -> [] version -> {{4,0},{'ejabberd@REDACTED',{1067,260145,62112}}} where_to_commit -> [{'ejabberd@REDACTED',disc_only_copies}] where_to_read -> 'ejabberd@REDACTED' where_to_write -> ['ejabberd@REDACTED'] wild_pattern -> {roster,'_','_','_','_','_','_','_','_','_'} {index,3} -> {roster,index,3} MnesiaCore contains some private info, so I not include it here (I can send it to one of Erlang developers). From mwilligs@REDACTED Mon Dec 15 14:16:20 2003 From: mwilligs@REDACTED (mwilligs@REDACTED) Date: Mon, 15 Dec 2003 10:16:20 -0300 (PYST) Subject: Residential Gateway Message-ID: <2323.65.198.40.11.1071494180.squirrel@unimail.uninet.com.py> Does anybody know any residential gateway that speaks h248? Thanks From massimo.cesaro@REDACTED Mon Dec 15 14:41:57 2003 From: massimo.cesaro@REDACTED (Massimo Cesaro) Date: 15 Dec 2003 14:41:57 +0100 Subject: Residential Gateway In-Reply-To: <2323.65.198.40.11.1071494180.squirrel@unimail.uninet.com.py> References: <2323.65.198.40.11.1071494180.squirrel@unimail.uninet.com.py> Message-ID: <1071495726.1422.23.camel@xam> On Mon, 2003-12-15 at 14:16, mwilligs@REDACTED wrote: > Does anybody know any residential gateway that speaks h248? > Thanks Audiocodes MP-104 and MP-108 (http://www.audiocodes.com), 4 and 8 ports. There is also a 2 ports version, they sell it on demand. Massimo From banat82@REDACTED Mon Dec 15 21:05:21 2003 From: banat82@REDACTED (mohammad banat) Date: Mon, 15 Dec 2003 12:05:21 -0800 (PST) Subject: question Message-ID: <20031215200521.32937.qmail@web41808.mail.yahoo.com> hello, please i just want to ask can i implement these patterns reactor,router,active object,half-sync/half-async,connector,acceptor,service configuration) using erlang???????????? --------------------------------- Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Mon Dec 15 22:38:47 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 15 Dec 2003 22:38:47 +0100 Subject: question In-Reply-To: <20031215200521.32937.qmail@web41808.mail.yahoo.com> References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> Message-ID: These patterns are to a large extent tied to OO. You need to understand the patterns -- or more to the point, understand why you need them. Then, based on your understanding of Erlang (or any other non-OO language) figure out how you can accomplish the task without them, while still getting the job done elegantly. (: Or simply forget about those patterns and approach Erlang with an open mind. Then, you may revisit those patterns after having written some programs in Erlang, and you will find that you solved those problems more elegantly without thinking about it much. Perhaps not the answer you were hoping for, but you really shouldn't do object-oriented programming by the book in Erlang. An OO language would be much better for that. Some of the behaviours you will find basically implemented already. For example, gen_event seems awfully similar to the reactor pattern. I found descriptions of some of the patterns you mention at http://www.cs.wustl.edu/~schmidt/patterns-ace.html I didn't try to go through your entire list, but: The 'active object' pattern is a good example of how something that Erlang programmers do almost on a daily basis can become horribly complex in a programming environment that wasn't designed with concurrency in mind. Compare with regular Erlang processes and e.g. the gen_server behaviour, and you will find much more powerful, but also much more intuitive constructs than the 'active object' design pattern. /Uffe On Mon, 15 Dec 2003 12:05:21 -0800 (PST), mohammad banat wrote: > hello, > > please i just want to ask > > can i implement these patterns reactor,router,active > object,half-sync/half-async,connector,acceptor,service configuration) > using erlang???????????? > > > --------------------------------- > Do you Yahoo!? > New Yahoo! Photos - easier uploading and sharing -- Ulf Wiger From erlang@REDACTED Mon Dec 15 23:17:21 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Mon, 15 Dec 2003 19:17:21 -0300 Subject: gen_server References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> Message-ID: <00d601c3c359$51ff3010$1e00a8c0@design> When calling gen_server:call, does it blocks the gen_server process? >From another point of view does gen_server solve the pattern of multiple clients requests calling in a synchronous way (gen_server:call)? For each client a process should be spawned. Thanks, Eduardo Figoli From lennart.ohman@REDACTED Mon Dec 15 23:48:47 2003 From: lennart.ohman@REDACTED (=?ISO-8859-15?Q?Lennart_=D6hman?=) Date: Mon, 15 Dec 2003 23:48:47 +0100 Subject: gen_server In-Reply-To: <00d601c3c359$51ff3010$1e00a8c0@design> References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> Message-ID: <3FDE3A4F.4040604@st.se> A client making a request using gen_server:call (hopefully hidden in an API function) waits until a response is sent back from the gen_server process. That response (message) makes the gen_server:call function return a return value. /Lennart Inswitch Solutions - Erlang Evaluation wrote: > When calling gen_server:call, does it blocks the gen_server process? > > From another point of view does gen_server solve the pattern of multiple > clients requests calling in a synchronous way (gen_server:call)? > For each client a process should be spawned. > > Thanks, > Eduardo Figoli > > -- ------------------------------------------------------------- Lennart Ohman phone : +46-8-587 623 27 Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735 Sehlstedtsgatan 6 fax : +46-8-667 8230 SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From erlang@REDACTED Tue Dec 16 00:04:03 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Mon, 15 Dec 2003 20:04:03 -0300 Subject: gen_server References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> <3FDE3A4F.4040604@st.se> Message-ID: <00e201c3c35f$c1ba7e40$1e00a8c0@design> Hi Lennart, Suppose Pid0 is the gen_server Pid I execute in two different processes (clients): - Pid1 gen_server:call to Pid0 gen_server - Pid2 gen_server:call to Pid0 gen_server Is the gen_server blocked while processing Pid1 or Pid2 request? The pattern is clients calling a server, so the implementation of gen_server (behavior) should resolve this problem in some way (spawning processes for each client sync. request for example). As far as I know this is what OO design patterns implementation are supposed to solve. Does OTP behavior in Erlang mean the same as OO design patterns? Thanks again, Eduardo Figoli ----- Original Message ----- From: "Lennart ?hman" To: "Inswitch Solutions - Erlang Evaluation" Cc: Sent: Monday, December 15, 2003 7:48 PM Subject: Re: gen_server > A client making a request using gen_server:call (hopefully > hidden in an API function) waits until a response is sent > back from the gen_server process. That response (message) > makes the gen_server:call function return a return value. > > /Lennart > > Inswitch Solutions - Erlang Evaluation wrote: > > > When calling gen_server:call, does it blocks the gen_server process? > > > > From another point of view does gen_server solve the pattern of multiple > > clients requests calling in a synchronous way (gen_server:call)? > > For each client a process should be spawned. > > > > Thanks, > > Eduardo Figoli > > > > > > -- > ------------------------------------------------------------- > Lennart Ohman phone : +46-8-587 623 27 > Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735 > Sehlstedtsgatan 6 fax : +46-8-667 8230 > SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED > From sean.hinde@REDACTED Tue Dec 16 00:10:15 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 15 Dec 2003 23:10:15 +0000 Subject: gen_server In-Reply-To: <00d601c3c359$51ff3010$1e00a8c0@design> References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> Message-ID: On 15 Dec 2003, at 22:17, Inswitch Solutions - Erlang Evaluation wrote: > > When calling gen_server:call, does it blocks the gen_server process? > > From another point of view does gen_server solve the pattern of > multiple > clients requests calling in a synchronous way (gen_server:call)? > For each client a process should be spawned. I think what you are looking for is the gen_server:reply/2 function. The normal pattern of usage is to spawn a new worker process in your handle_call/2 and instead of returning {reply, Reply, New_state} you return {noreply, State}. This leaves the gen_server unblocked ready for new call requests, and the calling process blocked awaiting the result of its call Once the worker process has completed its work it can call gen_server:reply(To, Reply) where To is the original caller reference received in the handle_call/2. Alternatively, and what I normally do, is to store the From ref and the Pid of the spawned process in an ets table owned by the main gen_server process. The worker process then casts the answer back via the main gen_server process which does the gen_server:reply/2. This way if the worker process crashes the main gen_server can trap the 'EXIT' message, lookup the Pid/From, and send an error response back to the original caller. I think perhaps gen_server:reply needs to be added to the FAQ, or maybe a chapter devoted to this model somewhere in the docs - I have had to explain it many times and it is far too useful to not have prominence. Sean From mlogan@REDACTED Tue Dec 16 00:35:33 2003 From: mlogan@REDACTED (Martin J. Logan) Date: 15 Dec 2003 17:35:33 -0600 Subject: gen_server In-Reply-To: <00e201c3c35f$c1ba7e40$1e00a8c0@design> References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> <3FDE3A4F.4040604@st.se> <00e201c3c35f$c1ba7e40$1e00a8c0@design> Message-ID: <1071531332.21893.21.camel@dhcp-lom-194-186.futuresource.com> On Mon, 2003-12-15 at 17:04, Inswitch Solutions - Erlang Evaluation wrote: > Hi Lennart, > > Suppose Pid0 is the gen_server Pid > > I execute in two different processes (clients): > - Pid1 gen_server:call to Pid0 gen_server > - Pid2 gen_server:call to Pid0 gen_server > > Is the gen_server blocked while processing Pid1 or Pid2 request? The gen server is a single process i.e a single "thread". Consequently if you make a call from pid1 the gen server is going to service that request and send back a response before it ever pulls the request sent by pid2 out of its(pid0) mailbox. This is assuming that the request made by pid1 got arrived in the mailbox of pid0 first. Basically the first request will be totally serviced and the the second request will be serviced in the same manner. > > The pattern is clients calling a server, so the implementation of gen_server > (behavior) should resolve this problem in some way (spawning processes for > each client sync. request for example). > As far as I know this is what OO design patterns implementation are supposed > to solve. Does OTP behavior in Erlang mean the same as OO design patterns? > This is not what the gen_server should do, and it is in fact what it does not do:-) The gen server is a just a loop that receives messages and executes user specific code sequentially for each message. If you want to solve the problem that you speak of it sounds like you want a few gen_* type processes. Think concurrent tcp server. One "listener" that spawns a handler for each concurrent connection. That sounds like what you want. Cheers, Martin > Thanks again, > Eduardo Figoli > > > > > > > > > ----- Original Message ----- > From: "Lennart ?hman" > To: "Inswitch Solutions - Erlang Evaluation" > Cc: > Sent: Monday, December 15, 2003 7:48 PM > Subject: Re: gen_server > > > > A client making a request using gen_server:call (hopefully > > hidden in an API function) waits until a response is sent > > back from the gen_server process. That response (message) > > makes the gen_server:call function return a return value. > > > > /Lennart > > > > Inswitch Solutions - Erlang Evaluation wrote: > > > > > When calling gen_server:call, does it blocks the gen_server process? > > > > > > From another point of view does gen_server solve the pattern of multiple > > > clients requests calling in a synchronous way (gen_server:call)? > > > For each client a process should be spawned. > > > > > > Thanks, > > > Eduardo Figoli > > > > > > > > > > -- > > ------------------------------------------------------------- > > Lennart Ohman phone : +46-8-587 623 27 > > Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735 > > Sehlstedtsgatan 6 fax : +46-8-667 8230 > > SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED > > From robert.virding@REDACTED Tue Dec 16 09:08:18 2003 From: robert.virding@REDACTED (Robert Virding) Date: Tue, 16 Dec 2003 09:08:18 +0100 Subject: Small poll References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> Message-ID: <003101c3c3ab$c3a1f160$2100a8c0@virding.org> I have read through the discussion on this suggestion and found it a little strange, to say the least. There are a few points I would like to make: 1. If I understood Richard correctly he means that the compiler should be careful when it can't do things consistently, in this case warn about a a construction which will generate an error. He also gave some equivalent code to "a+42" which the compiler would not warn about. His first case, "X = a, X+42" is especially funny as the compiler will generate exactly the same code for it, as it has some simple constant propagation in it. I completely agree with Richard. 2. As Dr. Joe (again congratulations Joe) points out "a+42" IS LEGAL ERLANG! Sorry for shouting but the point must be stressed. How can any one seriously suggest that the compiler disallow legal code? You are actually changing the semantics of the language when you do this. Are you aware of this fact? 3. What is the point is the compiler transforming it to exit({badarith,...})? What are you exactly gaining by doing it? Not saving code anyway, and hardly runtime either. So my suggestion would be #2, generate a warning. I say that the compiler should disallow illegal code and allow all legal code while warning for potentially stupid things. It should NEVER disallow legal code. Sorry Bjorn but this also includes a compiler option which transforms all warnings to errors. Do you seriously mean that it should be illegal to have singleton variables, unused functions, bad calls to format etc? It is one thing to warn, but to disallow? The compiler should help me and not hinder me by trying to be too stupidly smart. As example just look at what Word/Outlook Express do for some really terrifying examples. This is somewhat similar to the syntax change suggestion a while back try and catch the case where there was a missing blank in X =<<...>>. Sorry for getting worked up about this but I wish people would think through their suggestions a bit more and consider the deeper implications of them. Finally one definite reason not to outlaw a+42 is that it is one of my standard ways of generating an error in code, being much shorter to write than exit(some_bogus_exit_value). I also use 1=2 (N.B. only one =). Which should also be banned I suppose. Robert P.S. If things like this are added to the compiler then it is time for an alternate compiler. ----- Original Message ----- From: "Kostis Sagonas" To: Sent: Wednesday, December 10, 2003 6:25 PM Subject: Small poll > I was wondering whether the Erlang user community would care > to comment on the following: > > In a function like: > > test(A) -> > a + 42. > > which is either crap (arguably) or a typo (A vs a), how many > Erlang users: > > 1. Are content with the current situation where the compiler > happily compiles this program > 2. Would like to see a warning, but a .beam file generated > nevetheless > 3. Would prefer if the compiler in R10 refused to compile it > > Notice I am not talking about any serious attempt to static > type checking, but for really "basic" checks. > > Kostis. From luke@REDACTED Tue Dec 16 09:45:59 2003 From: luke@REDACTED (Luke Gorrie) Date: 16 Dec 2003 09:45:59 +0100 Subject: Small poll In-Reply-To: <003101c3c3ab$c3a1f160$2100a8c0@virding.org> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> <003101c3c3ab$c3a1f160$2100a8c0@virding.org> Message-ID: "Robert Virding" writes: > Finally one definite reason not to outlaw a+42 is that it is one of my > standard ways of generating an error in code, being much shorter to > write than exit(some_bogus_exit_value). I also use 1=2 (N.B. only one > =). I've often wondered how many different ways people do this. I do 1/0, Klacke does a=b, you do 1=2., ..... :-) From Bengt.Kleberg@REDACTED Tue Dec 16 10:32:39 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Tue, 16 Dec 2003 10:32:39 +0100 Subject: Small poll In-Reply-To: <003101c3c3ab$c3a1f160$2100a8c0@virding.org> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> <003101c3c3ab$c3a1f160$2100a8c0@virding.org> Message-ID: <3FDED137.5050801@ericsson.com> Robert Virding wrote: ...deleted > 2. As Dr. Joe (again congratulations Joe) points out "a+42" IS LEGAL ERLANG! Sorry for shouting but the point must be stressed. How can any one seriously suggest that the compiler disallow legal code? You are actually changing the semantics of the language when you do this. Are you aware of this fact? i did not know ''a+42'' was legal. i thought it generated an error. ...deleted > Finally one definite reason not to outlaw a+42 is that it is one of my standard ways of generating an error in code, being much shorter to write than exit(some_bogus_exit_value). i think that a+42, with a comment stating that this is indeed intended to cause an error, and an explanation why you want an error here, is probably longer than erlang:exit(why_you_want_an_error). presumably you do not suggest putting a+42, without any explanation, into the source? > P.S. If things like this are added to the compiler then it is time for an alternate compiler. i think this is a very good suggestion. if it frightens anybody i would like to mention that it was egcs that became gcc-2. bengt From joe@REDACTED Tue Dec 16 11:58:58 2003 From: joe@REDACTED (Joe Armstrong) Date: Tue, 16 Dec 2003 11:58:58 +0100 (CET) Subject: Small poll In-Reply-To: <003101c3c3ab$c3a1f160$2100a8c0@virding.org> Message-ID: > 2. As Dr. Joe (again congratulations Joe) points out "a+42" IS LEGAL ERLANG! Sorry for shouting but the point must be stressed. How can any one seriously suggest that the compiler disallow legal code? You are actually changing the semantics of the language when you do this. Are you aware of this fact? > Quite right. As I pointed out before there can be two possible reasons why the programmer wrote a+42. 1) The programmer made an error, or, 2) The programmer wants the system to raise an exception. THERE IS NO WAY THE COMPILER KNOWS WHICH OF THESES TWO CASES APPLIES (Sorry for shouting) Conclusion: You must tell the compiler (ie the compiler needs to know the programmer's intention - << what I call intentionality >>) There are two ways of telling the compiler: a) add pragmas to Erlang pragma(bad_code) a+42 end b) add a known wrapper that the compiler understands for example make a function this_is_not_an_error(X) -> X. and then call it thus: this_is_not_an_error( a + 42) Method b) needs no syntactic changes to the language, and (I guess) a very simple change to the compiler. If we adopt b) then the compiler should reasonably behave as follows: a+42 Produces a warning and compiles the code correctly this_is_not_an_error(a+42) Compiles the code correctly with no warning In both cases the function is compiled - the only difference is whether you warn or not. Robert is entirely right - legal code must ALWAYS be correctly compiled --- the compiler should never try to outguess the programmer and guess that this was an error - half our test suits would stop working if this were the case. /Joe From vlad_dumitrescu@REDACTED Tue Dec 16 13:29:52 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 16 Dec 2003 13:29:52 +0100 Subject: gen_server References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> Message-ID: From: "Sean Hinde" > Alternatively, and what I normally do, is to store the From ref and the > Pid of the spawned process in an ets table owned by the main gen_server > process. The worker process then casts the answer back via the main > gen_server process which does the gen_server:reply/2. This way if the > worker process crashes the main gen_server can trap the 'EXIT' message, > lookup the Pid/From, and send an error response back to the original > caller. > > I think perhaps gen_server:reply needs to be added to the FAQ, or maybe > a chapter devoted to this model somewhere in the docs - I have had to > explain it many times and it is far too useful to not have prominence. Just a thought: from my experience this pattern is used quite a lot, so it might be useful to incorporate it in the basic gen_server. For example, one could use gen_server:spawn_worker that will also handle the bookkeeping and also handle worker exits behind the scenes. Some hooks can be provided for customization. Would it be wrth the trouble? regards, /Vlad From goran.bage@REDACTED Tue Dec 16 15:00:11 2003 From: goran.bage@REDACTED (Goran Bage) Date: Tue, 16 Dec 2003 15:00:11 +0100 Subject: Small poll In-Reply-To: References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> <003101c3c3ab$c3a1f160$2100a8c0@virding.org> Message-ID: <3FDF0FEB.1000901@mobilearts.se> Luke Gorrie wrote: > "Robert Virding" writes: > > > I've often wondered how many different ways people do this. I do 1/0, > Klacke does a=b, you do 1=2., ..... :-) > Ahh, now you are getting somwhere, let's discuss which is the fastest :-) :-) -- -- Goran ------------------------- May the Snow be with you ---- Goran Bage, MobileArts, www.mobilearts.se Tj?rhovsgatan 56, SE-116 28 Stockholm, Sweden email:goran.bage@REDACTED, phone: +46 733 358405 From vances@REDACTED Wed Dec 17 00:55:44 2003 From: vances@REDACTED (Vance Shipley) Date: Tue, 16 Dec 2003 18:55:44 -0500 Subject: gen_server In-Reply-To: References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> Message-ID: <20031216235544.GH4719@frogman.motivity.ca> On Mon, Dec 15, 2003 at 11:10:15PM +0000, Sean Hinde wrote: } } Alternatively, and what I normally do, is to store the From ref and the } Pid of the spawned process in an ets table owned by the main gen_server Ah but that's cheating isn't it? :) Here's what I do: -behaviour(gen_server). init(_) -> {ok, gb_trees:empty()}. handle_call(Fun, From, State) -> Pid = proc_lib:spawn(Fun), {noreply, gb_trees:insert(Pid, From)}. handle_info({Pid, Result}, State) -> gen_server:reply(gb_trees:get(Pid, State), Result), {noreply, gb_trees:delete(Pid, State)}. -Vance From robert.virding@REDACTED Wed Dec 17 01:02:57 2003 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 17 Dec 2003 01:02:57 +0100 Subject: Small poll References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> <003101c3c3ab$c3a1f160$2100a8c0@virding.org> <3FDED137.5050801@ericsson.com> Message-ID: <000901c3c431$209ce2a0$2100a8c0@virding.org> From: "Bengt Kleberg" > Robert Virding wrote: > ...deleted > > 2. As Dr. Joe (again congratulations Joe) points out "a+42" IS LEGAL ERLANG! Sorry for shouting but the point must be stressed. How can any one seriously suggest that the compiler disallow legal code? You are actually changing the semantics of the language when you do this. Are you aware of this fact? > > i did not know ''a+42'' was legal. i thought it generated an error. It is a perfectly legal expression but when evaluated it generates an error. As errors are a part of Erlangs semantics you can't go and just eliminate any expression which might generate one. If you do that then you are changing the semantics of the language. Also doing it in an ad hoc way in the compiler by catching expressions which just happen to be easy to detect would be very confusing. I mean why flag a+42 and not A=a,A+42 which is also very simple and just as likely to cause an error. A compiler should disallow illegal code, do its best with legal code and try to be helpful by warning about legal, but potentially confusing or with misleading results, code or constructions. That is why the compiler's warnings should stay as warnings and never become errors. > presumably you do not suggest putting a+42, without any explanation, > into the source? Well, it's pretty obvious that if you write something like a+42 in your code then you're intending it to fail. I mean there are limits. :-) I usually document code which is not plainly obvious and which I feel I might have difficulty remembering what it did at a later date, or does something tricky and smart. This and a comment at the beginning of the function usually suffices. I am of the opinion that having to many comments tends to make everything difficult to read. Also having a comment standard helps to keep comments short. Read through the compiler and parts of the libraries (the more basic ones) to see how I code. Robert From luke@REDACTED Wed Dec 17 01:17:02 2003 From: luke@REDACTED (Luke Gorrie) Date: 17 Dec 2003 01:17:02 +0100 Subject: Small poll In-Reply-To: <000901c3c431$209ce2a0$2100a8c0@virding.org> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> <003101c3c3ab$c3a1f160$2100a8c0@virding.org> <3FDED137.5050801@ericsson.com> <000901c3c431$209ce2a0$2100a8c0@virding.org> Message-ID: "Robert Virding" writes: > That is why the compiler's warnings should stay as warnings and never > become errors. To properly enforce this, perhaps we should also suppress the warnings? #!/usr/bin/awk -f BEGIN { status = 0 } { print $0 } /Warning:/ { status = 1 } END { exit(status) } ;-) From kostis@REDACTED Wed Dec 17 01:36:10 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 17 Dec 2003 01:36:10 +0100 (MET) Subject: Small poll In-Reply-To: Mail from '"Robert Virding" ' dated: Tue, 16 Dec 2003 09:08:18 +0100 Message-ID: <200312170036.hBH0aA6X008815@hamberg.it.uu.se> Robert Virding wrote a mail quoting my mail, and he finished it as follows: > ... deleted ... > > Sorry for getting worked up about this but I wish people would think > through their suggestions a bit more and consider the deeper > implications of them. > > Finally one definite reason not to outlaw a+42 is that it is one of my > standard ways of generating an error in code, being much shorter to > write than exit(some_bogus_exit_value). I will try to avoid the temptation of replying directly to the first statement above, and instead reply to the following question of Robert. > 3. What is the point is the compiler transforming it to > exit({badarith,...})? What are you exactly gaining by doing it? > Not saving code anyway, and hardly runtime either. Ah, Robert, you seem to have very limited imagination... let me help you here. Consider the code: -module(a42). -export([test/0]). test() -> catch f(), ok. f() when a+42 == 0 -> %% extremely long sequence of code here ok_1; f() -> Y = ackerman(), % very long computation here % (without side-effects) X = a+42, mod:funct(X,Y), %% possibly lots more other code here ok_2. ackerman() -> .... QUESTION 1 ---------- Do the "semantics" of Erlang (BTW, I would really like to see them formally specified before people use this term again) allow a compiler to transform the code above to just: -module(a42). -export([test/0]). test() -> ok. QUESTION 2 ---------- Can the savings in time and code space be made arbitrarily big, or not? QUESTIONS 3-N ------------- - Do the two occurrences of "a+42" need to be treated differently by the compiler in the above example, or not? - Is "a+42" an expression that always generates an error in Erlang? (as far as the user is concerned) - Is it just me that finds this Erlang-ism confusing to say the least? (I.e., is this a user-friendly language design?) Kostis. PS. I am very well aware that the subject has shifted from warnings vs. errors to something else now, but I could not resist. Apologies. From ok@REDACTED Wed Dec 17 05:22:27 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 17 Dec 2003 17:22:27 +1300 (NZDT) Subject: Small poll Message-ID: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> Is it clear to everyone that "This code must raise an exception at run time" and "This code is in error" are different? Let me give an Interlisp example first. In Interlisp-D, there was a built-in function (SHOULDNT). For example, you might define the factorial function like this: [PUTDQ FACTORIAL (LAMBDA (N) (IF (> N 1) THEN (* N (FACTORIAL (- N 1))) ELSE IF (>= N 0) THEN 1 ELSE (SHOULDNT] Now the call to (SHOULDNT) must raise an exception at run time, and if the call is _executed_ that indicates an error in the way the function is used, but it isn't an error in the program to _have_ the call sitting there. An Interlisp compiler that rejected code containing (SHOULDNT) would have rejected every Interlisp program I ever wrote. The C equivalent of (SHOULDNT) is abort(). Not, by the way, assert(0). Is it also clear that "This code is obviously silly" and "This code must raise an exception at run time" are different? Lint warns about things that are clearly silly, yet perfectly legal, and perfectly harmless. For example, x == y; as a C statement is perfectly well defined, and quite harmless, yet lint warns about it because you probably didn't mean it. A C compiler which refused to compile such a program would not be helpful, it would be buggy. It is possible to make (=)-for-(==) and (==)-for-(=) errors in Erlang, and lint checking for Erlang might warn about them even though they are legal. Whether a particular piece of apparent silliness is worth warning about is an empirical question: how often do programmers make the kind of mistake that results in an instance of that pattern, and how often do they intend it? I have no idea what kinds of mistakes are commonest in Erlang. It would be interesting to find out. I've worked on a couple of compilers for languages that supported exception handling. (I _think_ mine was the first paper on doing this for Prolog, except that Quintus insisted on yanking it from the conference after it was accepted.) Exception handling can be very tricky to get right. (There's a debate raging in the Clean mailing list at this moment.) ANSI Smalltalk exception handling is a case in point; to me it seems insanely complicated, and it's not clear that Squeak has got it 100% right yet. This means that especially when you are maintaining compilers, you _need_ simple test cases which are certain to cause exceptions because that's what you're testing. From valentin@REDACTED Wed Dec 17 08:22:20 2003 From: valentin@REDACTED (Valentin) Date: Wed, 17 Dec 2003 09:22:20 +0200 Subject: gen_server References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> Message-ID: <01c001c3c46e$82af5080$0100a8c0@moneymaker> From: "Vlad Dumitrescu" > > Just a thought: from my experience this pattern is used quite a lot, so it might > be useful to incorporate it in the basic gen_server. For example, one could use > gen_server:spawn_worker that will also handle the bookkeeping and also handle > worker exits behind the scenes. Some hooks can be provided for customization. > > Would it be wrth the trouble? > I do this a lot, but I think it would be a bad idea to make this a part of existing gen_server (imagine how many ets tables can be created this way), instead, why not make a completely new behaviour that incorporates this functionality (i.e. gen_spawner, that is gen_server with a twist). Valentin. From vlad_dumitrescu@REDACTED Wed Dec 17 08:32:12 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 17 Dec 2003 08:32:12 +0100 Subject: gen_server References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> <01c001c3c46e$82af5080$0100a8c0@moneymaker> Message-ID: From: "Valentin" > I do this a lot, but I think it would be a bad idea to make this a part of > existing gen_server (imagine how many ets tables can be created this way), > instead, why not make a completely new behaviour that incorporates this > functionality (i.e. gen_spawner, that is gen_server with a twist). Oh, yes, of course. I was not meaning to use ets tables always, this part should be customizable. By default, we would get the normal gen_server, so that nothing is broken. I don't think there is a need for a new behaviour, because they look exactly the same to the client, who doesn't care about the implementation. regards /Vlad From vlad_dumitrescu@REDACTED Wed Dec 17 08:59:45 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 17 Dec 2003 08:59:45 +0100 Subject: Distel, the other way around Message-ID: Hi, I got this idea that might not be new (but then I'd love to hear why it doesn't work). I suppose Luke should have been thinking about something like this. I think I am not alone when I wish there was a nicer interface to Erlang than the shell, visually and functionally. Distel is a great tool, but what I'd like to see is more like how Mozart/Oz does it: the integration is tighter, and there are colors ;-) This is why I thought: why not use Distel the other way around, to drive Emacs from Erlang. If we can call Emacs functions from Erlang, then we can build a nice front-end. One way to do this would be to implement something like the ncurses API, that talks to Emacs. There might even exist an Emacs package that implements this, even if I couldn't find it yet. Another way, the more interesting one, is to open up Emacs with all its functionality to Erlang. How on earth do that without growing old while writing interfaces, you ask? We can just send to a Distel buffer something like Buffer ! {execute, do_something, Args} (or a rpc call if we want an answer) where do_something should be an elisp function. This can be encapsulated into emacs:call(Buffer, do_something, Args), or even nicer into an emacs:do_something(Buffer, Args). The latter could be either transformed by a parse_transform (nah!) or caught by emacs:undefined_function/2 who will know what to do. Is this reasonable? regards, Vlad From vlad_dumitrescu@REDACTED Wed Dec 17 09:02:22 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 17 Dec 2003 09:02:22 +0100 Subject: OT: A very interesting book Message-ID: Maybe this is old news, but Eric S. Raymond wrote a book recently, "The Art of Unix Programming", which I found very interesting to read. It handles mostly the cultural aspects of programming, and why things are how they are. The book can be found online at http://www.faqs.org/docs/artu/ regards, Vlad From Bengt.Kleberg@REDACTED Wed Dec 17 09:46:21 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Wed, 17 Dec 2003 09:46:21 +0100 Subject: gen_server In-Reply-To: <20031216235544.GH4719@frogman.motivity.ca> References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> <20031216235544.GH4719@frogman.motivity.ca> Message-ID: <3FE017DD.4020609@ericsson.com> Vance Shipley wrote: ...deleted > init(_) -> > {ok, gb_trees:empty()}. > > handle_call(Fun, From, State) -> > Pid = proc_lib:spawn(Fun), > {noreply, gb_trees:insert(Pid, From)}. thank you for an example using a new module i did not know of. since this is the first time i see gb_trees i am ofcourse very uncertain, but perhaps it should have been: {noreply, gb_trees:insert(Pid, From, State)}. ...deleted bengt From Bengt.Kleberg@REDACTED Wed Dec 17 09:50:14 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Wed, 17 Dec 2003 09:50:14 +0100 Subject: Distel, the other way around In-Reply-To: References: Message-ID: <3FE018C6.1080900@ericsson.com> Vlad Dumitrescu wrote: > Hi, > > I got this idea that might not be new (but then I'd love to hear why it doesn't > work). I suppose Luke should have been thinking about something like this. > > I think I am not alone when I wish there was a nicer interface to Erlang than > the shell, visually and functionally. Distel is a great tool, but what I'd like > to see is more like how Mozart/Oz does it: the integration is tighter, and there > are colors ;-) > > This is why I thought: why not use Distel the other way around, to drive Emacs > from Erlang. If we can call Emacs functions from Erlang, then we can build a > nice front-end. ...deleted for more inspiration you might want to look at libsmg that comes with wily (http://www.cs.yorku.ca/~oz/wily). it has the neccessary functions to use wily as a frontend to another program. bengt From Bengt.Kleberg@REDACTED Wed Dec 17 10:09:05 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Wed, 17 Dec 2003 10:09:05 +0100 Subject: Small poll In-Reply-To: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> Message-ID: <3FE01D31.7060808@ericsson.com> Richard A. O'Keefe wrote: > Is it clear to everyone that > > "This code must raise an exception at run time" > > and > > "This code is in error" > > are different? ...deleted yes, i think i understand. you are saying that some code should be ok to compile, even if it will always crash at run time. would it seem very strange if i did not agree? because i do not, even though i have not ever written a compiler. perhaps this is why? > > Is it also clear that > > "This code is obviously silly" > > and > > "This code must raise an exception at run time" > > are different? yes, here we do agree. a large part of my code is obviously silly, and yet there are not many run time exceptions. atleast not after i have run the test cases. bengt From Bengt.Kleberg@REDACTED Wed Dec 17 10:14:18 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Wed, 17 Dec 2003 10:14:18 +0100 Subject: Small poll In-Reply-To: <200312170036.hBH0aA6X008815@hamberg.it.uu.se> References: <200312170036.hBH0aA6X008815@hamberg.it.uu.se> Message-ID: <3FE01E6A.6030502@ericsson.com> Kostis Sagonas wrote: ...deleted > - Is it just me that finds this Erlang-ism confusing to say > the least? (I.e., is this a user-friendly language design?) i take the last question as beeing directed to any reader of the list, and not to mr virding in particular. i apologise if i am mistaken. i find erlang to be very user unfriendly in its syntax. the semantics are beyond me, but some scope rules are terrible. bengt From joachim.durchholz@REDACTED Wed Dec 17 10:26:42 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Wed, 17 Dec 2003 10:26:42 +0100 Subject: Small poll In-Reply-To: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> Message-ID: <3FE02152.9090909@web.de> Richard A. O'Keefe wrote: > > The C equivalent of (SHOULDNT) is abort(). Not, by the way, assert(0). If that's the case, SHOULDNT shouldn't be in the language. After all, forcing the execution of the program to a halt is unmodular: the caller might want to run the code and try an alternate strategy. (Heck, that's what Erlang is all about: surviving faulty code that does thing's that shouldn't happen.) > Is it clear to everyone that > > "This code must raise an exception at run time" > > and > > "This code is in error" > > are different? This classification isn't complete, and I think the ongoing discussion is at least partially senseless because wrong distinctions of this kind are constantly being made. Actually, Erlang has more failure modes (and this list may not even be complete): 1. Erroneous code that's rejected by the compiler. This includes stuff like "1 = 2 3". 2. Code that will raise an exception. Example: "1 = 2". 3. Code that will terminate the process. Essentially, that's code that doesn't catch all exceptions that may occur. 4. Code that will terminate the Erlang node. 5. Code that will terminate all communicating Erlang nodes. Category 2 is what most confusion comes from: depending personal definitions, one may consider it erroneous or not (and either definition makes sense, depending on the point of view). There's another source of confusion: Some people here argue that a compiler shouldn't change the semantics of the language, but is that indeed the case? Both syntax and semantics of Erlang have changed over the years, in in an upwards-compatible fashion. > Is it also clear that > > "This code is obviously silly" > > and > > "This code must raise an exception at run time" > > are different? Lint warns about things that are clearly silly, > yet perfectly legal, and perfectly harmless. For example, > x == y; > as a C statement is perfectly well defined, and quite harmless, > yet lint warns about it because you probably didn't mean it. > A C compiler which refused to compile such a program would not > be helpful, it would be buggy. A C compiler would emit a warning and be compliant. If I were to decide, I'd adopt a similar policy: issue warnings about constructs like 1=2. However, I dislike somethine entirely different about them. There's clearly a need to make a computation fail, and different people use different idioms to express is. Some say 1=2, others say a+0, and I saw mentions a handful others. While that's neat, it's also an unnecessary maintenance obstacle. Whenever a maintainer sees such code, he has to (a) find out what this code does (which will take more time than usual because he'll have to revisit the usual assumption that code isn't written for raising exception), (b) figure out whether the code is raising the exception intentionally or not. There are two additional disadvantages: (c) it's impossible to do a grep to see whether any temporary exception-raisers were accidentally left in some code that's considered ready for production release, and (d) if the code does raise an exception, it will give the maintainer wrong information: the true error is that the system is trying to execute unwritten code, but the system will give a different error message. I'm quite mystified why there isn't a "niy" (not implemented yet) or "tbd" (to be determined) routine, that explicitly raises an exception saying "fatal error: trying to execute code that has not yet been written" (or something similar). Once such a routine is in place, the question whether changing the semantics of obviously silly constructs is a no-brainer: if there's no useful purpose for them, their semantics is irrelevant and can be changed. One may adopt a more conservative approach and maintain compatibility with legacy code, so a warning would probably be more appropriate. An even better option would be if that warning could be turned into an error for those shops who want strict discipline (not all shops need that, but sometimes there are good reasons to turn on the equivalent of -Wall --warnings-as-errors). > It is possible to make (=)-for-(==) and (==)-for-(=) errors in > Erlang, and lint checking for Erlang might warn about them even > though they are legal. > > Whether a particular piece of apparent silliness is worth warning > about is an empirical question: how often do programmers make the > kind of mistake that results in an instance of that pattern, and > how often do they intend it? And, more importantly: how easy is it to make the compiler detect that pattern, and how likely is it that the compiler will make errors when identifying such patterns? > I've worked on a couple of compilers for languages that supported > exception handling. (I _think_ mine was the first paper on doing this > for Prolog, except that Quintus insisted on yanking it from the conference > after it was accepted.) Exception handling can be very tricky to get > right. (There's a debate raging in the Clean mailing list at this moment.) > ANSI Smalltalk exception handling is a case in point; to me it seems > insanely complicated, and it's not clear that Squeak has got it 100% right > yet. This means that especially when you are maintaining compilers, you > _need_ simple test cases which are certain to cause exceptions because > that's what you're testing. There's always the explicit exception raising statement. Any language that has exceptions should have such a statement, and Erlang does it right. Actually, I don't think that generating a test case should be a problem, ever. There's always the possibility to do unit testing. You'll have to structure the compiler so that it has units to be tested, but this restructuring will clean up the compiler considerably, making is more stable and reliable, so this is a good idea anyway. Loss of test cases due to changes in language syntax or semantics is just an indicator that the compiler is badly structured IMNSHO. Regards, Jo From Bengt.Kleberg@REDACTED Wed Dec 17 10:32:18 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Wed, 17 Dec 2003 10:32:18 +0100 Subject: Small poll In-Reply-To: <000901c3c431$209ce2a0$2100a8c0@virding.org> References: <200312101725.hBAHPiwN004261@hamberg.it.uu.se> <003101c3c3ab$c3a1f160$2100a8c0@virding.org> <3FDED137.5050801@ericsson.com> <000901c3c431$209ce2a0$2100a8c0@virding.org> Message-ID: <3FE022A2.3000809@ericsson.com> Robert Virding wrote: ...deleted > It is a perfectly legal expression but when evaluated it generates an error. As errors are a part of Erlangs semantics you can't go and just eliminate any expression which might generate one. may i continue to respectfully belive that code that will _always_ generate an error should stop the compilation? ...deleted >A compiler should disallow illegal code, do its best with legal code and try to be helpful by warning about legal, but potentially confusing or with misleading results, code or constructions. this is something i can fully agree with. i just happen to think that ''do its best'' in the case of only ''a+42'' is to not compile it. ...deleted > Well, it's pretty obvious that if you write something like a+42 in your code then you're intending it to fail. I mean there are limits. :-) I usually document code which is not plainly obvious and which I feel I might have difficulty remembering what it did at a later date, or does something tricky and smart. This and a comment at the beginning of the function usually suffices. I am of the opinion that having to many comments tends to make everything difficult to read. Also having a comment standard helps to keep comments short. Read through the compiler and parts of the libraries (the more basic ones) to see how I code. you are much to kind to me. if i write ''a+42'' it is because i am making a stupid mistake, nothing else. probably i intended it to be ''A+42''. your comment standard seems very good. i hope that i am using it (or something similar). i am aware of the benefits i can draw from reading more code. actually, that would be from reading more code written by somebody better than me (at writing code, ofcourse). but this is always the case in the basic erlang libraries. still, when time permits some thing like that, i ususally write some code instead. stupid behaviour. bengt From joachim.durchholz@REDACTED Wed Dec 17 10:36:44 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Wed, 17 Dec 2003 10:36:44 +0100 Subject: Distel, the other way around In-Reply-To: References: Message-ID: <3FE023AC.50004@web.de> Vlad Dumitrescu wrote: > I think I am not alone when I wish there was a nicer interface to Erlang than > the shell, visually and functionally. Distel is a great tool, but what I'd like > to see is more like how Mozart/Oz does it: the integration is tighter, and there > are colors ;-) It's a nice interface. > This is why I thought: why not use Distel the other way around, to drive Emacs > from Erlang. If we can call Emacs functions from Erlang, then we can build a > nice front-end. Urk. Emacs, while certainly powerful, is pretty much unusable to the average Windows programmer. If you want to lose all market share of Erlang on the Windows platform, make this the standard interface. (Actually this is was one of the major limiting factors for my productivity on Mozart/Oz - I had all intentions of learning Emacs in the process, but doing this at the same time as learning Mozart/Oz proved to be too distracting, so I was stuck at a quite basic level of Emacs expertise and productivity.) Better devote the developer resources to other things (like building better front-ends). Or, if integration with Emacs is a must, add integration with other IDEs at the same time (MS Visual Studio comes to mind, and this Borland thingie that I forgot the name of). And keep these integrations up-do-date - it's no use if the initial release supports all kinds of IDE, and all but one are left unmaintained after that. Just my 2c. Regards, Jo From mickael.remond@REDACTED Wed Dec 17 10:40:44 2003 From: mickael.remond@REDACTED (Mickael Remond) Date: Wed, 17 Dec 2003 10:40:44 +0100 Subject: gen_server In-Reply-To: <1071531332.21893.21.camel@dhcp-lom-194-186.futuresource.com> References: <00e201c3c35f$c1ba7e40$1e00a8c0@design> <1071531332.21893.21.camel@dhcp-lom-194-186.futuresource.com> Message-ID: <20031217094044.GD16863@cgey.com> * Martin J. Logan [2003-12-15 17:35:33 -0600]: > On Mon, 2003-12-15 at 17:04, Inswitch Solutions - Erlang Evaluation > wrote: > > Hi Lennart, > > > > Suppose Pid0 is the gen_server Pid > > > > I execute in two different processes (clients): > > - Pid1 gen_server:call to Pid0 gen_server > > - Pid2 gen_server:call to Pid0 gen_server > > > > Is the gen_server blocked while processing Pid1 or Pid2 request? > > The gen server is a single process i.e a single "thread". Consequently > if you make a call from pid1 the gen server is going to service that > request and send back a response before it ever pulls the request sent > by pid2 out of its(pid0) mailbox. This is assuming that the request made > by pid1 got arrived in the mailbox of pid0 first. Basically the first > request will be totally serviced and the the second request will be > serviced in the same manner. Gen_server are basically used to protect resources. Those resources are for example often stored in the gen_server state. You should ask you one question: Do you really need a gen_server in the situation you are describing ? Most of the time, when you are thinking about having a "parallel gen_server", you do not need a gen_server. Try to see if a simple function call from each process (Pid1 and Pid2 in your example) are not what you really want. Regards, -- Micka?l R?mond http://www.erlang-projects.org/ From vlad_dumitrescu@REDACTED Wed Dec 17 11:26:43 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 17 Dec 2003 11:26:43 +0100 Subject: Distel, the other way around References: <3FE023AC.50004@web.de> Message-ID: Hi, From: "Joachim Durchholz" > Urk. Emacs, while certainly powerful, is pretty much unusable to the > average Windows programmer. If you want to lose all market share of > Erlang on the Windows platform, make this the standard interface. Doesn't need to be the standard interface. Not even necessarily used as an IDE - but as an output media, or a GUI. Using directly all Lisp functions in the way I proposed before could work, but of course one would need to be an Emacs hacker to build something nice. For simple use, a simpler API would probably be enough. > Or, if integration with Emacs is a must, add integration with other IDEs > at the same time (MS Visual Studio comes to mind, and this Borland > thingie that I forgot the name of). And keep these integrations > up-do-date - it's no use if the initial release supports all kinds of > IDE, and all but one are left unmaintained after that. There is an ongoing effort to make an Eclipse plugin, which I suppose would be good enough (it's portable and the Java node functionality is better than the EmacsLisp one) regards, Vlad p.s. The Borland thingie - you mean BuilderX? If yes, I'm not sure if one can use it for non-C++ projects. From bry@REDACTED Wed Dec 17 11:42:10 2003 From: bry@REDACTED (bryan) Date: Wed, 17 Dec 2003 11:42:10 +0100 Subject: Distel, the other way around In-Reply-To: <3FE023AC.50004@web.de> Message-ID: <000f01c3c48a$6ece9870$2001a8c0@bryans> >Urk. Emacs, while certainly powerful, is pretty much unusable to the >average Windows programmer. If you want to lose all market share of >Erlang on the Windows platform, make this the standard interface. >(Actually this is was one of the major limiting factors for my >productivity on Mozart/Oz - I had all intentions of learning Emacs in >the process, but doing this at the same time as learning Mozart/Oz >proved to be too distracting, so I was stuck at a quite basic level of >Emacs expertise and productivity.) well I found xemacs with Moz to be quite useful, nonetheless I would prefer if the two were not tied so tightly together. From joe@REDACTED Wed Dec 17 12:08:23 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 17 Dec 2003 12:08:23 +0100 (CET) Subject: Small poll In-Reply-To: <200312170036.hBH0aA6X008815@hamberg.it.uu.se> Message-ID: On Wed, 17 Dec 2003, Kostis Sagonas wrote: > Robert Virding wrote a mail quoting my mail, and he finished it as > follows: > > > ... deleted ... > > > > Sorry for getting worked up about this but I wish people would think > > through their suggestions a bit more and consider the deeper > > implications of them. > > > > Finally one definite reason not to outlaw a+42 is that it is one of my > > standard ways of generating an error in code, being much shorter to > > write than exit(some_bogus_exit_value). > > I will try to avoid the temptation of replying directly to the first > statement above, and instead reply to the following question of Robert. > > > 3. What is the point is the compiler transforming it to > > exit({badarith,...})? What are you exactly gaining by doing it? > > Not saving code anyway, and hardly runtime either. > > > Ah, Robert, you seem to have very limited imagination <<<< limited imagination -- never - I've never heard anybody accuse Robert of limited imagination before -- he has his little quirks, we all do, but limited imagination is not among them... deciding to totally rewrite the compiler one week before it's to be released and a month after the last final-final code stop might be a more appropriate failing :-) >>>> >... let me help > you here. Consider the code: > > -module(a42). > -export([test/0]). > > test() -> > catch f(), > ok. > > f() when a+42 == 0 -> > %% extremely long sequence of code here > ok_1; > f() -> > Y = ackerman(), % very long computation here > % (without side-effects) > X = a+42, > mod:funct(X,Y), > %% possibly lots more other code here > ok_2. > > ackerman() -> .... > > > QUESTION 1 > ---------- > Do the "semantics" of Erlang (BTW, I would really like to see them > formally specified before people use this term again) allow a compiler > to transform the code above to just: > > -module(a42). > -export([test/0]). > > test() -> > ok. ABSOLUTELY NOT - the programs mean *completely* different things. In your example the compiler writers job is to make sure that ackerman() gets evaluated as quicky as possible - it is NOT to change the meaning of the program. Programs are ONLY correct wrt to specifications - period - end of story. Here is the spec (which you didn't show us :-) << Write me a program, that performs a long and evolved computation (say by calling the ackerman function) - then generate an error and return ok. This is to be used in a regression test where we test the speed-up introduce by our new big-num acceleration hardware. >> One good property that a programming language should have is "predictability" the programmer should be able to naively understand the (space-time) consequences of their code - break this rule and you are in trouble. I *hate* compilers that make assumptions about my code and optimize away my so-called "mistakes". If the programmer tells the system to do something stupid then it should do something stupid. << aside -- why is this: Once upon a time I had to program a "radar controller" when I worked for the Eiscat scientific association. The radar controller had lots of lamps on the front panel. The hardware guys wanted me to write an *incorrect* program which would cause the red error lamp on the front panel to light up. This proved *impossible* because a "smart" compiler refused all programs which were incorrect and thus I could not write a test program that light the red lamp. I struggled for weeks - eventual we had to throw away all the control software and re-write it from scratch so that I could write "incorrect" programs. Moral - the system should do *exactly* what you tell it and nothing else >> > > QUESTION 2 > ---------- > Can the savings in time and code space be made arbitrarily big, or not? No - the compiler/run-time system should make the code do exactly what the programmer said the code should do - what one should optimize are the artificial artifacts introduced by compilation - ie minimize garbage collection times, instruction dispatching times etc. > > QUESTIONS 3-N > ------------- > - Do the two occurrences of "a+42" need to be treated differently > by the compiler in the above example, or not? No > - Is "a+42" an expression that always generates an error in Erlang? > (as far as the user is concerned) Yes > - Is it just me that finds this Erlang-ism confusing to say > the least? (I.e., is this a user-friendly language design?) I don't find this strange at all - I guess it's just you :-) /Joe > > > Kostis. > > PS. I am very well aware that the subject has shifted from > warnings vs. errors to something else now, but I could > not resist. Apologies. > From luke@REDACTED Wed Dec 17 14:36:06 2003 From: luke@REDACTED (Luke Gorrie) Date: 17 Dec 2003 14:36:06 +0100 Subject: Distel, the other way around In-Reply-To: References: Message-ID: "Vlad Dumitrescu" writes: > I think I am not alone when I wish there was a nicer interface to Erlang than > the shell, visually and functionally. Distel is a great tool, but what I'd like > to see is more like how Mozart/Oz does it: the integration is tighter, and there > are colors ;-) What makes the integration tighter (apart from the colours :-)? We'll soon show them who's boss! (well maybe not that soon.. few things to do :-) > This is why I thought: why not use Distel the other way around, to drive Emacs > from Erlang. If we can call Emacs functions from Erlang, then we can build a > nice front-end. The way Distel works it that an Emacs buffer is a process. Erlang can send a message to an Emacs buffer, and the buffer then receives it (with `erl-receive') and decides what to do. So all of the mechanisms are available -- it's just a matter of doing the cool stuff with them. Here's how to write an RPC server process in Distel / Emacs Lisp: (defun rpc-server () "Start an RPC server process with registered name 'rpc-server'. The process will be an emacs buffer called '*reg rpc-server*'." (interactive) (erl-spawn (erl-register 'rpc-server) (&rpc-loop))) (defun &rpc-loop () "RPC server loop: receive an expression in a message and evaluate it. Log all the expressions we get in our buffer." (erl-receive () ((['eval expression] (insert (format "Evalulating %S\n" expression)) (ignore-errors (eval expression)))) (&rpc-loop))) This is roughly equivalent to Erlang: rpc_server() -> spawn(fun() -> register(rpc_server, self()), rpc_server_loop() end). rpc_server_loop() -> receive {eval, Expr} -> io:format("Evaluating ~p~n", [Expr]), catch eval(Expr) end, rpc_server_loop(). (The Elisp code is tested, the Erlang isn't -- and note that `eval' is a builtin in Elisp.) If you do `M-x rpc-server' it starts the server process in a buffer called "*reg rpc-server*". Unfortunately, you can't send a message from Erlang to Emacs using a registered name "{foo, node@REDACTED} ! ..." syntax -- probably just because Distel connects as a hidden node. So in Erlang you need to somehow get the PID of the Elisp process. One way is to do an RPC from Emacs to Erlang that prints the pid, here on Erlang node x@REDACTED: (erl-send-rpc 'x@REDACTED 'io 'format (list "Emacs RPC server pid: ~p~n" (list (erl-whereis 'rpc-server)))) Which will print (in Emacs, because stdio/group_leader is redirected) a message like: Emacs RPC server pid: <4408.2.0> Then in the Erlang shell you can write: P = pid(4408, 2, 0), P ! {eval, [message, "This is a small lisp program that prints a message"]}. which runs the Elisp program (message "This ...") in Emacs. You see the message in the minibuffer area. Cheers, Luke From vlad_dumitrescu@REDACTED Wed Dec 17 14:46:27 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 17 Dec 2003 14:46:27 +0100 Subject: Distel, the other way around References: Message-ID: From: "Luke Gorrie" > What makes the integration tighter (apart from the colours :-)? We'll > soon show them who's boss! That's the spirit! :-) Well, I'm not really a Moz heavy user, but they have no separate shell, the whole UI is done inside Emacs. I'd not recommend going that far (like Joachim pointed out). Also there is a system browser where values can be inspected - more or less like a live interactive session. Would be cool to see in real-time how the state of a process changes, for example. > The way Distel works it that an Emacs buffer is a process. Erlang can > send a message to an Emacs buffer, and the buffer then receives it > (with `erl-receive') and decides what to do. So all of the mechanisms > are available -- it's just a matter of doing the cool stuff with them. Yes, I know there are. I was about to try to give it a try, but then thought "what if there's something flawed in my assumptions? I'll ask first". > Here's how to write an RPC server process in Distel / Emacs Lisp: > ...deleted... Thanks, that saved me a lot of trial-and-error :-) > Unfortunately, you can't send a message from Erlang to Emacs using a > registered name "{foo, node@REDACTED} ! ..." syntax -- probably just > because Distel connects as a hidden node. So in Erlang you need to > somehow get the PID of the Elisp process. Another way is to have on the Erlang side a known connection point and let the Emacs process register itself. Then we can create an Erlang wrapper around it. regards, Vlad From luke@REDACTED Wed Dec 17 15:12:57 2003 From: luke@REDACTED (Luke Gorrie) Date: 17 Dec 2003 15:12:57 +0100 Subject: Distel, the other way around In-Reply-To: References: Message-ID: "Vlad Dumitrescu" writes: > Well, I'm not really a Moz heavy user, but they have no separate shell, the > whole UI is done inside Emacs. I'd not recommend going that far (like Joachim > pointed out). But there's no such thing as going "too far" in adding better Emacs-based support for Erlang. It makes Emacs users happy, and it doesn't affect anybody else. It sounds like Oz _only_ supports Emacs? That's a decision with more serious consequences (i.e. only tasteful programmers will use it ;-). > Another way is to have on the Erlang side a known connection point and let the > Emacs process register itself. Then we can create an Erlang wrapper around it. Yes, that is a better idea! Emacs could say something like: (erl-send-rpc 'node@REDACTED 'erlang_rpc 'start_link (list erl-self)) meaning: rpc:cast(node@REDACTED, erlang_rpc, start_link, [self()])). Then in erlang_rpc.erl: start_link(EmacsPid) -> .... From joachim.durchholz@REDACTED Wed Dec 17 16:55:02 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Wed, 17 Dec 2003 16:55:02 +0100 Subject: Distel, the other way around In-Reply-To: References: Message-ID: <3FE07C56.9000200@web.de> Luke Gorrie wrote: > > It sounds like Oz _only_ supports Emacs? Um, well, yes and no. You can always run the compiler from the command line, and use some other editor (vi, or even some of the Windows editors) to jump to erroneous lines. Problem is: Mozart tutorials tend to assume you're living in emacs. Some interesting tools were available just for the emacs environment and wouldn't work standalone. Nothing serious, actually - you can always work around that. But every workaround takes an extra hour. Or an extra day. After several repetitions of this, the enthusiasm is used up and alternatives start to look more interesting... Regards, Jo From vances@REDACTED Wed Dec 17 18:06:05 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 17 Dec 2003 12:06:05 -0500 Subject: gen_server In-Reply-To: <3FE017DD.4020609@ericsson.com> References: <20031215200521.32937.qmail@web41808.mail.yahoo.com> <00d601c3c359$51ff3010$1e00a8c0@design> <20031216235544.GH4719@frogman.motivity.ca> <3FE017DD.4020609@ericsson.com> Message-ID: <20031217170605.GJ4719@frogman.motivity.ca> On Wed, Dec 17, 2003 at 09:46:21AM +0100, Bengt Kleberg wrote: } perhaps it should have been: } {noreply, gb_trees:insert(Pid, From, State)}. You of course correct. -Vance From cpressey@REDACTED Wed Dec 17 19:25:55 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 17 Dec 2003 10:25:55 -0800 Subject: Small poll In-Reply-To: <3FE01D31.7060808@ericsson.com> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> <3FE01D31.7060808@ericsson.com> Message-ID: <20031217102555.19572317.cpressey@catseye.mine.nu> On Wed, 17 Dec 2003 10:09:05 +0100 Bengt Kleberg wrote: > yes, i think i understand. you are saying that some code should be ok > to compile, even if it will always crash at run time. > would it seem very strange if i did not agree? because i do not, even > though i have not ever written a compiler. perhaps this is why? Bengt, I could be wrong, but I think it is more likely that it's because you aren't used to writing Erlang code in the "let it crash" style. In this style, you write code very aggressively. You might have a function like (this is just an example, not meant to do anything useful:) foo(Bar) -> ok = file:setcwd(moo(Bar)), {ok, File} = file:open(zoo(Bar)), {ok, Records} = read_records(File), ok = file:close(File), Records. So, the intent of the function is clearly to fail outright with 'badmatch' if anything goes wrong. foo/1's callers presumably wrap their calls to foo (or their calls to whatever eventually calls foo) in a catch. (Or the process that calls foo/1 is spawned, with the spawning process linked/monitoring/trapping errors...) The point is that foo/1 can fail, but that it's not *fatal*, in the sense that the program keeps running. Now what if we want a flag that disables this function? Maybe eventually we'll read the flag from a file, but for testing purposes, we'll just define it as a constant in the source: baz_mode() -> true. foo(Bar) -> false = baz_mode(), ok = file:setcwd(moo(Bar)), [...] Records. Just as clearly as the previous example I hope, the intent of that line of code is to disable the function if we are in baz mode, not to stop the program from being compilable if we are in baz mode! :) Where "let it crash" style is supported in Erlang, it's not always graceful ('try' may improve that, if it ever gets added,) but it usually results in much clearer code, because the assumptions/assertions are made explicit. But even if you don't use it, you have to recognize that many programmers do, and for the "let it crash" style to work, code has to be allowed to crash at runtime, even when it "can't be right". -Chris From jamesh@REDACTED Wed Dec 17 20:49:17 2003 From: jamesh@REDACTED (James Hague) Date: Wed, 17 Dec 2003 13:49:17 -0600 Subject: Small poll Message-ID: I've been following this thread with interest. My gut feeling is that it's a can of worms that's best left closed. Why warn about this case, but not slightly more complex cases? Depending on the kind of optimizations the compiler does, you might be able to get warnings about some of the these, but you'll still never get constant propagation across module boundaries, for example. And "a + 42" as a legitimate mistake on the programmer's part is much, much rarer than a simple fat-fingering of the name of a function in a another module and having the compiler accept it anyway (note: I'm not suggesting that this should be addressed!). James From pascal.brisset-ml@REDACTED Wed Dec 17 21:17:35 2003 From: pascal.brisset-ml@REDACTED (Pascal Brisset) Date: Wed, 17 Dec 2003 21:17:35 +0100 Subject: Small poll In-Reply-To: <20031217102555.19572317.cpressey@catseye.mine.nu> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> <3FE01D31.7060808@ericsson.com> <20031217102555.19572317.cpressey@catseye.mine.nu> Message-ID: <20031217201351.2DBA9C000109@mwinf0302.wanadoo.fr> Chris Pressey writes: > foo(Bar) -> > ok = file:setcwd(moo(Bar)), > {ok, File} = file:open(zoo(Bar)), > {ok, Records} = read_records(File), > ok = file:close(File), > Records. > > So, the intent of the function is clearly to fail outright with > 'badmatch' if anything goes wrong. foo/1's callers presumably wrap > their calls to foo (or their calls to whatever eventually calls foo) in > a catch. [...] Note that if foo/1's caller catches failures from read_records/1, file descriptors will be leaked. Days later, the beam process runs out of descriptors and strange things happen. Been there. What would seasoned Erlangers recommend to avoid this ? -- Pascal From cpressey@REDACTED Wed Dec 17 21:28:33 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 17 Dec 2003 12:28:33 -0800 Subject: Small poll In-Reply-To: <20031217201351.2DBA9C000109@mwinf0302.wanadoo.fr> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> <3FE01D31.7060808@ericsson.com> <20031217102555.19572317.cpressey@catseye.mine.nu> <20031217201351.2DBA9C000109@mwinf0302.wanadoo.fr> Message-ID: <20031217122833.6240951f.cpressey@catseye.mine.nu> On Wed, 17 Dec 2003 21:17:35 +0100 Pascal Brisset wrote: > Chris Pressey writes: > > foo(Bar) -> > > ok = file:setcwd(moo(Bar)), > > {ok, File} = file:open(zoo(Bar)), > > {ok, Records} = read_records(File), > > ok = file:close(File), > > Records. > > > > So, the intent of the function is clearly to fail outright with > > 'badmatch' if anything goes wrong. foo/1's callers presumably wrap > > their calls to foo (or their calls to whatever eventually calls > > foo) in a catch. [...] > > Note that if foo/1's caller catches failures from read_records/1, > file descriptors will be leaked. Days later, the beam process runs > out of descriptors and strange things happen. Been there. > > What would seasoned Erlangers recommend to avoid this ? Well, I am not a seasoned Erlanger[1], but I imagine most of them would recommend spawning foo/1 into it's own process, then monitoring it or linking to it. Then, when the process running foo/1 dies, its filehandles and other resources will be deallocated (IIRC.) -Chris [1] I just come with a little wasabi on the side. From luke@REDACTED Wed Dec 17 21:31:39 2003 From: luke@REDACTED (Luke Gorrie) Date: 17 Dec 2003 21:31:39 +0100 Subject: Small poll In-Reply-To: References: Message-ID: James Hague writes: > And "a + 42" as a legitimate mistake on the programmer's part is > much, much rarer than a simple fat-fingering of the name of a > function in a another module and having the compiler accept it > anyway (note: I'm not suggesting that this should be addressed!). I guess xref addresses this. There's also a compiler option I've been wanting that could handle it. I would like an option to generate a M:module_info(calls) that returns a list of calls made by each function in the module. Returns: [{Function, Arity, [Callee]}] Callee = {Module, Function, Arity} This way it would be easy to write a program that loads all modules in the code path and reports all calls to functions that can't be found. (I must admit that I rarely have this particular problem, possibly because I use M-TAB and M-/ to complete my function names.) I really want it as a way to write a who_calls(M,F,A)->[{M,F,A}] function that could be used by Emacs for a "reverse tags lookup". who_calls would expect all relevant modules to be loaded and do a fold over them to find all callers. Then I can present the results in a "hyperlinked" buffer and save myself a lot of grep'ery. I've been meaning to hack this up as a parse transform using syntax_tools and use it in the Jungerl. But if it's something the OTP group would be interested in, I could look at putting it in the compiler..? -Luke From kostis@REDACTED Thu Dec 18 00:01:18 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 18 Dec 2003 00:01:18 +0100 (MET) Subject: Small poll In-Reply-To: Mail from 'James Hague ' dated: Wed, 17 Dec 2003 13:49:17 -0600 Message-ID: <200312172301.hBHN1Iv5028223@hamberg.it.uu.se> James Hague wrote: > I've been following this thread with interest. > > My gut feeling is that it's a can of worms that's best left closed. > Why warn about this case, but not slightly more complex cases? Sorry to suddently turn this thread into a political one, but the above argument seems to me an argument of the form: "Why try to eliminate some social injustices, since we are never going to eliminate them all (especially the most subtle ones)." Just think about it... Cheers, Kostis. From jamesh@REDACTED Thu Dec 18 00:32:12 2003 From: jamesh@REDACTED (James Hague) Date: Wed, 17 Dec 2003 17:32:12 -0600 Subject: Small poll Message-ID: Kostis Sagonas wrote: > > My gut feeling is that it's a can of worms that's best left closed. > > Why warn about this case, but not slightly more complex cases? > > Sorry to suddently turn this thread into a political one, but the > above argument seems to me an argument of the form: > > "Why try to eliminate some social injustices, since we are never > going to eliminate them all (especially the most subtle ones)." > > Just think about it... First, you can't compare software and social injustices. You just can't. Well, okay, you just did, but it's not meaningful :) Second, software is a battle against complexity. In this particular case you're adding a check and a warning about something that's (A) a rare occurrence, (B) going to bomb out immediately the first time you test the function, and (C) detected at compile time in specific circumstances and not detected in others. To provide a warning for this, you are adding additional code to the compiler. Is it worth it? I would buy that, yes, it makes sense because "a + 42" is a typical newbie mistake, and we're probably not talking about a lot of additional code to warn about this. But it's also a typical newbie mistake to use an atom in a function header, like "first({x,y}) -> x", and that can't be warned against. So it's hit-or-miss about what can be warned about and what can't. This is what I meant about a can of worms. It is more straightforward to dismiss the issue, rather than going down a long road of adding warnings for all kinds of things that may or may not be errors, because realistically this is a minor issue. Again, this has nothing to do with social injustices. You don't engineer laws the same way you engineer software. James From kostis@REDACTED Thu Dec 18 00:52:45 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 18 Dec 2003 00:52:45 +0100 (MET) Subject: Small poll In-Reply-To: Mail from 'James Hague ' dated: Wed, 17 Dec 2003 17:32:12 -0600 Message-ID: <200312172352.hBHNqjlo000716@hamberg.it.uu.se> James Hague wrote: > > > > "Why try to eliminate some social injustices, since we are never > > going to eliminate them all (especially the most subtle ones)." > > > > Just think about it... > > First, you can't compare software and social injustices. You just can't. First of all, I am not comparing them with "software" but with "software errors". To me, the analogy is a very good one. In the same way that we cannot eliminate all social injustices, we cannot eliminate all software errors. However, trying to is a worthwhile cause, and achieving partial success is probably better than doing nothing about it. The analogy is even better if you take into account that most often than not, there is no unanimous agreement about what really constitutes an injustice or an error. > Second, software is a battle against complexity. In this particular case > you're adding a check and a warning about something that's (A) a rare > occurrence, (B) going to bomb out immediately the first time you test the > function, and (C) detected at compile time in specific circumstances and not > detected in others. To provide a warning for this, you are adding > additional code to the compiler. Is it worth it? You are obviously not a compiler writer, are you? In this particular case, we are actually talking about *eliminating* (in the case of the BEAM compiler) and *avoiding adding* (in the case of HiPE) lots of stupid code that is now special-handling the case of "a+42" (and generating instructions with very weird argument types). If you do not believe me, just look at the sources. Best, Kostis. From mickael.remond@REDACTED Thu Dec 18 09:59:04 2003 From: mickael.remond@REDACTED (Mickael Remond) Date: Thu, 18 Dec 2003 09:59:04 +0100 Subject: Erlang SNMP and os_mon questions Message-ID: <20031218085904.GA5927@cgey.com> Hello, I have discovered a whole new part of Erlang/OTP I never used before: SNMP support. I have started writing a small tutorial to get started. However I have failed to guess how to use os_mon_snmp. I manage to get the watermarks figure but I fail to get the real figure. I can also get Erlang VM information such as erlNodeName, ... Here is the init sequence I am using: application:start(sasl), application:start(mnesia), application:start(os_mon), application:start(snmp), otp_mib:load(snmp_master_agent), os_mon_mib:init(snmp_master_agent). And here is the agent debug message log when I try to get the LoadSystemTotalMemory. =ERROR REPORT==== 18-Dec-2003::09:57:20 === ** User error: Invalid return value {'EXIT',{bad_snmp_key,[{loadTable,[110,111,110,111,100,101,64,110,111,104,111,115,116]},[110,111,110,111,100,101,64,110,111,104,111,115,116],integer]}} from {os_mon_mib,load_table,[]} (get_next) ** SNMP NET-IF LOG: reply pdu: {pdu,'get-response',99204045,genErr,1,[{varbind,[1,3,6,1,4,1,193,19,3,2,2,1,3,1,2],'NULL','NULL',1}]} ** SNMP NET-IF INFO: time in agent: 39911 mysec ** SNMP NET-IF LOG: got paket from {127,0,0,1}:32850 ** SNMP NET-IF MPD LOG: v1, community: public ** SNMP NET-IF LOG: got pdu {pdu,'get-request',99204046,noError,0,[{varbind,[1,3,6,1,4,1,193,19,3,2,2,1,3,1,2],'NULL','NULL',1}]} ** SNMP NET-IF LOG: reply pdu: {pdu,'get-response',99204046,noSuchName,1,[{varbind,[1,3,6,1,4,1,193,19,3,2,2,1,3,1,2],'NULL','NULL',1}]} ** SNMP NET-IF INFO: time in agent: 7771 mysec I probably forgot something, but I cannot find anything more in the documentation. Does someone know here how to make os_mon snmp run properly ? Thank you in advance for your help. -- Micka?l R?mond http://www.erlang-projects.org/ From bjorn@REDACTED Thu Dec 18 10:00:03 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 18 Dec 2003 10:00:03 +0100 Subject: New compiler warnings in R10B Message-ID: Inspired by the discussion in the "Small Poll" thread, I decided to start implementing new compiler warnings right away. (It was planned to be done in R10B anyway.) This is still a work in progress, but the warnings produced so far has been useful. What I've done is to change the optimization and code-generation passes to emit warnings if they discover something funny. That is not hard to do. The only reason we haven't done it before is that the line number of the offending line in the source code wasn't available. Now it is. Now to some examples! 1. CLAUSES THAT CANNOT BE REACHED ================================= Here is your typical factorial calculation module: -module(fact). -export([fact/1]). fact(N) -> fact(N, 1). fact(N, Acc0) -> Acc = Acc0 * N, fact(N-1, Acc); fact(0, Acc) -> Acc. Compiling it, we get the following warning: $ erlc fact.erl /home/bjorn/test/fact.erl:10: Warning: this clause cannot match because the previous clause always matches Line 10 is the last line in the module. It will not be reached because the first clause is always chosen. We found many warnings of this type in the OTP. Most of them are probably not bugs, but just redundant code. For instance, in inet.erl: . . . getaddrs_tm(Address, Family, Timer) -> . . . getaddrs_tm(_,_,_) -> {error, einval}. The last clause will actually never get executed. 2. BAD EXPRESSIONS ================== There are also warnings for expression that cannot be evaluated without causing an exception. Here is an example module: 01 -module(buggy). 02 03 -compile(export_all). 04 05 a() -> 06 42+an_atom. 07 08 b() -> 09 A = 'I am just an atom', 10 foo(), 11 42+A. 12 13 c() -> 14 42+an_integer(). 15 16 an_integer() -> 17 he_he_i_am_not_a_real_integer. 18 19 foo() -> 20 'I am just pretending to do some work'. There will be different warnings depending on how much optimization is turned off. I you turn off optimization, you will get no warnings. $ erlc +no_copt buggy.erl $ (Note: In general, there is never any need to turn off optimizations. It will buy you very little time and the default optimizations are in general "safe" - they don't change the meaning of your program in any way.) With the default settings, we'll get two warnings. $ erlc buggy.erl /home/bjorn/test/buggy.erl:6: Warning: this expression would cause a 'badarith' exception at run-time /home/bjorn/test/buggy.erl:11: Warning: this expression would cause a 'badarith' exception at run-time $ If we turn on inlining, we'll get one more warning. $ erlc +inline buggy.erl /home/bjorn/test/buggy.erl:6: Warning: this expression would cause a 'badarith' exception at run-time /home/bjorn/test/buggy.erl:11: Warning: this expression would cause a 'badarith' exception at run-time /home/bjorn/test/buggy.erl:14: Warning: this expression would cause a 'badarith' exception at run-time $ After inlining, the expression at line 14 is now 42+ he_he_i_am_not_a_real_integer /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From Bengt.Kleberg@REDACTED Thu Dec 18 10:15:51 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Thu, 18 Dec 2003 10:15:51 +0100 Subject: Small poll In-Reply-To: References: Message-ID: <3FE17047.6040102@ericsson.com> Luke Gorrie wrote: ...deleted > There's also a compiler option I've been wanting that could handle > it. I would like an option to generate a M:module_info(calls) that > returns a list of calls made by each function in the module. > > Returns: [{Function, Arity, [Callee]}] > Callee = {Module, Function, Arity} > > This way it would be easy to write a program that loads all modules in > the code path and reports all calls to functions that can't be found. this would be a very good thing to have as a helper. today i manage by cheating. i am not using the code path, but the source code directly. > (I must admit that I rarely have this particular problem, possibly > because I use M-TAB and M-/ to complete my function names.) in wily one can cut-and-paste with a mouse chord. it is rare to write any text more than once. different solution to the same problem. > I really want it as a way to write a who_calls(M,F,A)->[{M,F,A}] > function that could be used by Emacs for a "reverse tags lookup". > who_calls would expect all relevant modules to be loaded and do a fold > over them to find all callers. Then I can present the results in a > "hyperlinked" buffer and save myself a lot of grep'ery. would this find: erlang:apply( module, function, [arg]), my current grep on the source will find it. and ofcourse, the real problem: Module:Function(Arg) any ideas on how to find these without running the code? bengt From Bengt.Kleberg@REDACTED Thu Dec 18 10:29:06 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Thu, 18 Dec 2003 10:29:06 +0100 Subject: Small poll In-Reply-To: <20031217102555.19572317.cpressey@catseye.mine.nu> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> <3FE01D31.7060808@ericsson.com> <20031217102555.19572317.cpressey@catseye.mine.nu> Message-ID: <3FE17362.2030600@ericsson.com> Chris Pressey wrote: ...deleted > In this style, you write code very aggressively. You might have a > function like (this is just an example, not meant to do anything > useful:) > > foo(Bar) -> > ok = file:setcwd(moo(Bar)), > {ok, File} = file:open(zoo(Bar)), > {ok, Records} = read_records(File), > ok = file:close(File), > Records. in this case i think the compiler will complain about read_records/1 beeing unknown :-) seriously, if i have a module which _only_ contains (exported) functions that will always fail at runtime i do think the compiler should refuse to compile it. (btw: i think the compiler should refuse to compile a module without any exported functions, too) if some of the (exported) functions might work at runtime, then the compiler should compile, but warn about the always failing functions. ...deleted > But even if you don't use it, you have to recognize that many > programmers do, and for the "let it crash" style to work, code has to be > allowed to crash at runtime, even when it "can't be right". yes, i am all for letting code crash. i just do not think it is usefull to let the compiler produce code for a module that will always crash because potentially correct code is written in such a way as to produce a runtime error. use erlang:throw/1 or erlang:exit/1 if an runtime error is what you want. bengt From tomas.pihl@REDACTED Thu Dec 18 10:40:06 2003 From: tomas.pihl@REDACTED (Tomas Pihl) Date: Thu, 18 Dec 2003 10:40:06 +0100 (MET) Subject: Erlang SNMP and os_mon questions In-Reply-To: <20031218085904.GA5927@cgey.com> References: <20031218085904.GA5927@cgey.com> Message-ID: On Thu, 18 Dec 2003, Mickael Remond wrote: > And here is the agent debug message log when I try to get the > LoadSystemTotalMemory. > > =ERROR REPORT==== 18-Dec-2003::09:57:20 === > ** User error: Invalid return value > {'EXIT',{bad_snmp_key,[{loadTable,[110,111,110,111,100,101,64,110,111,104,111,115,116]},[110,111,110,111,100,101,64,110,111,104,111,115,116],integer]}} > from {os_mon_mib,load_table,[]} (get_next) bad_snmp_key comes from mnesia so it seems you have to do a create_table on loadTable before you access it. --Tomas Pihl tomas.pihl@REDACTED From taavi@REDACTED Thu Dec 18 12:35:55 2003 From: taavi@REDACTED (Taavi Talvik) Date: Thu, 18 Dec 2003 13:35:55 +0200 (EET) Subject: A plea for help from Erlang gurus Message-ID: <20031218133114.Y22502-100000@valu.uninet.ee> I have system, which tries to classify events based on their properties. And I am trying to simplify writing some special code for acting on property lists. I would like to write modules/rules in fashion of: Arg = [{key,value}, {key, value}, ...] % % Add {importance,'not so important'} when event is at night % important_event(Arg@REDACTED="linkDown") when Arg@REDACTED > 0 and Arg@REDACTED < 8 -> Arg@REDACTED = 'not so important event', Arg; % % Add {importance,'very important'} to property list % when there is {event_type, "linkDown"} in passed in property list % important_event(Arg@REDACTED="linkDown") -> Arg@REDACTED = 'very important event', Arg. This is basicly to extend pattern matching and guard tests to property list(assocative arrays) and add easy way to access those properties. What is best way to proceed: extend erl_scan and erl_parse generate extended parse tree analyze parse tree with help of syntax_tools find "array accesses" replace them with access functions or case statements in pattern matching and test guards output new code.. Any pointers to papers, code examples doing something similiar, ideas how erlang 'guru' will handle above are very much appreciated. What is reasonable way to start with this? best regards, taavi PS. I have never done anything like this before except classical exercise to write simple calculator with lex and yacc. From ulf.wiger@REDACTED Thu Dec 18 13:38:18 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 18 Dec 2003 13:38:18 +0100 Subject: New compiler warnings in R10B In-Reply-To: References: Message-ID: On 18 Dec 2003 10:00:03 +0100, Bjorn Gustavsson wrote: > Inspired by the discussion in the "Small Poll" thread, > I decided to start implementing new compiler warnings > right away. (It was planned to be done in R10B anyway.) > $ erlc fact.erl > /home/bjorn/test/fact.erl:10: Warning: this clause cannot match because > the previous clause always matches Superb! This is quite a common newbie error, and also (I believe) reasonably common even among experienced programmers. > There will be different warnings depending on how much optimization > is turned off. I you turn off optimization, you will get no warnings. OK, a bit quirky, but I can live with that. (: Nice work. /Uffe -- Ulf Wiger, Senior System Architect EAB/UPD/S From ulf.wiger@REDACTED Thu Dec 18 14:19:06 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 18 Dec 2003 14:19:06 +0100 Subject: A plea for help from Erlang gurus In-Reply-To: <20031218133114.Y22502-100000@valu.uninet.ee> References: <20031218133114.Y22502-100000@valu.uninet.ee> Message-ID: Given your proposed syntax, you will have to change the grammar. There are several good reasons to avoid this. However: 1> erl_scan:string("A@REDACTED = foo. "). {ok,[{var,1,'A@REDACTED'},{'=',1},{atom,1,foo},{dot,1}],1} This can be interpreted in two ways: - your syntax is (almost) legal erlang code, which is a good thing, because you don't really have to hack erl_scan. - it's (almost) legal erlang code, which is a bad thing, because your patterns may conflict with existing code. (: (BTW, the syntax highlighter in Emacs doesn't expect @ in variable names, and stops highlighting the variable name before the @.) The (almost) legal part is because you introduce new variable names in the guards, which is disallowed by the existing grammar. Thus, your code, as written, doesn't compile. I would propose the following (assuming you still want to go through with your idea ;): Change the syntax slightly so that it becomes really legal erlang: important_event(Arg@REDACTED="linkDown") when Arg@REDACTED > 0 and Arg@REDACTED < 8 -> could instead become: important_event([event_type="linkDown", time=T] = Arg@@) when T > 0 and T < 8 -> [{importance, 'not so important event'}|Arg]; %% I decided to peel off the @@ from the variable name. %% This might be a really bad idea. Feel free to rant about it. and then, using a parse_transform, changed into: important_event(Arg) -> case proplists:lookup(event_type, Arg) of {_, "linkDown"} -> case proplists:lookup(time, Arg) of {_, T} when T > 0 and T < 8 -> [{importance, 'not so important event'}|Arg]; _ -> ... end; none -> ... % exit(function_clause) or continue with other % clauses. end. I would not allow a "destructive update" construct like Arg@REDACTED = 'not so important event', Arg; As I couldn't think of an update construct that would be legal code and still intuitive, I propose simply leaking the representation of the proplist and prepending the new property to original list. The thing to make convenient was the decomposition, right? Updating property lists is already really easy. /Uffe On Thu, 18 Dec 2003 13:35:55 +0200 (EET), Taavi Talvik wrote: > > I have system, which tries to classify events based on > their properties. And I am trying to simplify writing > some special code for acting on property lists. > > I would like to write modules/rules in fashion of: > > Arg = [{key,value}, {key, value}, ...] > > % > % Add {importance,'not so important'} when event is at night > % > important_event(Arg@REDACTED="linkDown") when Arg@REDACTED > 0 and > Arg@REDACTED < 8 -> > Arg@REDACTED = 'not so important event', > Arg; > > % > % Add {importance,'very important'} to property list > % when there is {event_type, "linkDown"} in passed in property list > % > important_event(Arg@REDACTED="linkDown") -> > Arg@REDACTED = 'very important event', > Arg. > > This is basicly to extend pattern matching and guard tests > to property list(assocative arrays) and add easy way to access > those properties. > > What is best way to proceed: > > extend erl_scan and erl_parse > generate extended parse tree > > analyze parse tree with help of syntax_tools > find "array accesses" > replace them with access functions or case statements > in pattern matching and test guards > > output new code.. > > Any pointers to papers, code examples doing something similiar, > ideas how erlang 'guru' will handle above are very much appreciated. > > What is reasonable way to start with this? > > best regards, > taavi > > PS. I have never done anything like this before except classical > exercise to write simple calculator with lex and yacc. > -- Ulf Wiger, Senior System Architect EAB/UPD/S From jamesh@REDACTED Thu Dec 18 15:26:05 2003 From: jamesh@REDACTED (James Hague) Date: Thu, 18 Dec 2003 08:26:05 -0600 Subject: Small poll Message-ID: Kostis Sagonas wrote: > > In this particular > case, we are actually talking about *eliminating* (in the case of the > BEAM compiler) and *avoiding adding* (in the case of HiPE) lots of > stupid code that is now special-handling the case of "a+42" (and > generating instructions with very weird argument types). If you > do not believe me, just look at the sources. But you're only getting this win if you make this an error, not a warning, right? You'll still be "generating instructions with weird argument types" if you print a warning, then generate code. In fact, you're *adding* (what I suspect is a trivial amount of) code to print the warning. James From kostis@REDACTED Thu Dec 18 15:32:16 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 18 Dec 2003 15:32:16 +0100 (MET) Subject: Small poll In-Reply-To: Mail from 'James Hague ' dated: Thu, 18 Dec 2003 08:26:05 -0600 Message-ID: <200312181432.hBIEWG6b000334@hamberg.it.uu.se> James Hague wrote: > > But you're only getting this win if you make this an error, > not a warning, right? It should then come as to no suprise that I have made a case for the error over the warning in a previous mail of mine. Kostis. From luke@REDACTED Thu Dec 18 15:54:11 2003 From: luke@REDACTED (Luke Gorrie) Date: 18 Dec 2003 15:54:11 +0100 Subject: A plea for help from Erlang gurus In-Reply-To: <20031218133114.Y22502-100000@valu.uninet.ee> References: <20031218133114.Y22502-100000@valu.uninet.ee> Message-ID: Taavi Talvik writes: > I have system, which tries to classify events based on > their properties. And I am trying to simplify writing > some special code for acting on property lists. > > I would like to write modules/rules in fashion of: How about using a record instead of an association list? If you don't have too many distict fields, this would be quite neat, and let you write code pretty much like you describe. -Luke From bjorn@REDACTED Thu Dec 18 15:55:43 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 18 Dec 2003 15:55:43 +0100 Subject: Small poll In-Reply-To: <200312181432.hBIEWG6b000334@hamberg.it.uu.se> References: <200312181432.hBIEWG6b000334@hamberg.it.uu.se> Message-ID: When you print the error message, do you intend to print the line number of the offending expression in the source code? /Bjorn Kostis Sagonas writes: > James Hague wrote: > > > > But you're only getting this win if you make this an error, > > not a warning, right? > > It should then come as to no suprise that I have made a case > for the error over the warning in a previous mail of mine. > > Kostis. > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From taavi@REDACTED Thu Dec 18 16:34:12 2003 From: taavi@REDACTED (Taavi Talvik) Date: Thu, 18 Dec 2003 17:34:12 +0200 (EET) Subject: A plea for help from Erlang gurus In-Reply-To: Message-ID: <20031218171543.W30362-100000@valu.uninet.ee> On 18 Dec 2003, Luke Gorrie wrote: > Taavi Talvik writes: > > > I have system, which tries to classify events based on > > their properties. And I am trying to simplify writing > > some special code for acting on property lists. > > > > I would like to write modules/rules in fashion of: > > How about using a record instead of an association list? If you don't > have too many distict fields, this would be quite neat, and let you > write code pretty much like you describe. That's true. However there are too many fields. Or actually fields, which I do not know beforehand. Fiew of them can be standardised (ala event_source, time). But all of them cannot be standardized. Event from cisco router contains entirely different properties, than event from xDSL or events from coffe machine. And their classification is based on different rules. Maybe someone wants special treatment of event based on customer address, someone else wants classification based on time of day etc. It would be nice when end users themselves can add additional rules/scripts. Erlang is almost perfect match with it's pattern matching, guard tests and simple enough syntax. best regards, taavi From luke@REDACTED Thu Dec 18 16:45:50 2003 From: luke@REDACTED (Luke Gorrie) Date: 18 Dec 2003 16:45:50 +0100 Subject: A plea for help from Erlang gurus In-Reply-To: <20031218171543.W30362-100000@valu.uninet.ee> References: <20031218171543.W30362-100000@valu.uninet.ee> Message-ID: Taavi Talvik writes: > Erlang is almost perfect match with it's pattern matching, guard > tests and simple enough syntax. Considered AWK? It has a nice pattern matching syntax, first-class associative arrays, and no restrictions on guards. -Luke From kostis@REDACTED Thu Dec 18 16:52:14 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 18 Dec 2003 16:52:14 +0100 (MET) Subject: Small poll In-Reply-To: Mail from 'Bjorn Gustavsson ' dated: 18 Dec 2003 15:55:43 +0100 Message-ID: <200312181552.hBIFqEDA013977@hamberg.it.uu.se> > When you print the error message, do you intend to print the > line number of the offending expression in the source code? If possible, of course. When HiPE compiles code as a JIT (i.e. starting from BEAM code) this is not possible. When hipe compiles starting from source through Core Erlang, the line numbers will of course be printed. Kostis. From taavi@REDACTED Thu Dec 18 17:05:29 2003 From: taavi@REDACTED (Taavi Talvik) Date: Thu, 18 Dec 2003 18:05:29 +0200 (EET) Subject: A plea for help from Erlang gurus In-Reply-To: Message-ID: <20031218175252.P31627-100000@valu.uninet.ee> On 18 Dec 2003, Luke Gorrie wrote: > Taavi Talvik writes: > > > Erlang is almost perfect match with it's pattern matching, guard > > tests and simple enough syntax. > > Considered AWK? It has a nice pattern matching syntax, first-class > associative arrays, and no restrictions on guards. To be honest - no. AWK has no database, no snmp. Current working idea is following: event source -> annotation process -> -> classification/correlation process event source: collects events either from snmp traps, snmp measurements or some strange 3th party source annotation process: adds information to event based of fact source (database) or programmatically match cisco_1234 specific event match interface down event query database for customer info (based on portindex) add customer information query specific router for last 15 minute statistics add statistics information match on customer importance add "red color" .. classification/correlation: something similiar to above, but using existing events as one fact store. Currently this is done in pure eElang. In my dreams I wanted elegant matching (and properties access) functionality and still keeping power of language. best regards, taavi From svg@REDACTED Thu Dec 18 17:14:11 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Thu, 18 Dec 2003 21:14:11 +0500 (YEKT) Subject: A plea for help from Erlang gurus In-Reply-To: <20031218171543.W30362-100000@valu.uninet.ee> References: <20031218171543.W30362-100000@valu.uninet.ee> Message-ID: <20031218.211411.13161718.svg@surnet.ru> Good day, taavi> It would be nice when end users themselves can add additional taavi> rules/scripts. There is something magic under the heaven. Only few days ago I'd decided to write something like Minsky LGI (Law Governed Interaction) for my system. It seems you've got your notation from the same source. I inform you if I get some progress. Best Regards, Vladimir Sekissov Taavi Talvik writes: taavi> > taavi> > > I have system, which tries to classify events based on taavi> > > their properties. And I am trying to simplify writing taavi> > > some special code for acting on property lists. taavi> > > taavi> > > I would like to write modules/rules in fashion of: taavi> > taavi> > How about using a record instead of an association list? If you don't taavi> > have too many distict fields, this would be quite neat, and let you taavi> > write code pretty much like you describe. taavi> taavi> That's true. However there are too many fields. Or actually taavi> fields, which I do not know beforehand. Fiew of them can be taavi> standardised (ala event_source, time). But all of them cannot be taavi> standardized. taavi> taavi> Event from cisco router contains entirely different taavi> properties, than event from xDSL or events from coffe machine. And taavi> their classification is based on different rules. Maybe someone taavi> wants special treatment of event based on customer address, someone taavi> else wants classification based on time of day etc. taavi> taavi> It would be nice when end users themselves can add additional taavi> rules/scripts. taavi> taavi> Erlang is almost perfect match with it's pattern matching, guard taavi> tests and simple enough syntax. taavi> taavi> best regards, taavi> taavi taavi> From klacke@REDACTED Thu Dec 18 22:05:44 2003 From: klacke@REDACTED (klacke@REDACTED) Date: Thu, 18 Dec 2003 22:05:44 +0100 Subject: New yaws release - 1.40 Message-ID: <20031218210544.GA744@hyber.org> Folks, I'm happy to give you a new release of yaws just in time for Christmas. Lots and lots of changes this time. - New easy to configure webmail application - ssi with variable expansion inside EHTML structures. This the way to go when we generate dynamic java/javascript - reverse proxy implementation - new and better docs, embedded mode and ssi documented Relnotes, new docs and code at http://yaws.hyber.org /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From cpressey@REDACTED Thu Dec 18 21:03:58 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 18 Dec 2003 12:03:58 -0800 Subject: Small poll In-Reply-To: <3FE17362.2030600@ericsson.com> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> <3FE01D31.7060808@ericsson.com> <20031217102555.19572317.cpressey@catseye.mine.nu> <3FE17362.2030600@ericsson.com> Message-ID: <20031218120358.34b6ee34.cpressey@catseye.mine.nu> On Thu, 18 Dec 2003 10:29:06 +0100 Bengt Kleberg wrote: > Chris Pressey wrote: > > But even if you don't use it, you have to recognize that many > > programmers do, and for the "let it crash" style to work, code has > > to be allowed to crash at runtime, even when it "can't be right". > > yes, i am all for letting code crash. i just do not think it is > usefull to let the compiler produce code for a module that will always > crash because potentially correct code is written in such a way as to > produce a runtime error. > > use > erlang:throw/1 > or > erlang:exit/1 > if an runtime error is what you want. You're of course entitled to hold any opinion you wish, but I really have to say that I disagree, and that I can't quite see your reasoning. In Erlang as we know it, a + 42 generates an exception. An exception is by definition not a show-stopper; it can be caught and acted upon. But by changing it into a compile-time error, you're not even giving the program an *opportunity* to crash. This runs against the "let it crash" philosophy in my book. Also, by forcing the programmer to write throw(blah) to cause an exception, you're making them *make* it crash, which also runs counter to "let it crash" - the programmer needn't exert such explicit effort. To once again attempt to illustrate the difference: foo() = (catch bar()). bar() -> true = some_assertion_which_may_or_may_not_be_constant(), stuff(). ...versus... foo() = (catch bar()). bar() -> case some_assertion_which_may_or_may_not_be_constant() of true -> stuff(); false -> throw(badarg) end. I'd much rather write (and read) the first version than the second. Maybe it's just me, but I think it's more concise, more direct, and just generally clearer. I also don't think it makes sense for the compilation itself to succeed or fail based solely on whether some_assertion_which_may_or_may_not_be_constant() is (detectably) constant or not. That's why I'd much rather it be merely a compile-time warning. I'm all for getting as much information about possible errors as early as possible - but I'm not in favour of dramatic shifts in how this information would affect what is and what is not "legal Erlang". -Chris From erlang@REDACTED Fri Dec 19 08:37:40 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 19 Dec 2003 07:37:40 +0000 Subject: Small poll In-Reply-To: <20031218120358.34b6ee34.cpressey@catseye.mine.nu> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> <3FE01D31.7060808@ericsson.com> <20031217102555.19572317.cpressey@catseye.mine.nu> <3FE17362.2030600@ericsson.com> <20031218120358.34b6ee34.cpressey@catseye.mine.nu> Message-ID: <20031219073740.5dbca1fd.erlang@manderp.freeserve.co.uk> On the "let it crash" vein of the topic, I'm writing a SIP message parser. I ended up writing functions and code that only match positively with lexemes, letting the parser "crash" on mismatches, and catching to retry with alternative lexemes where multiple matches may occur. It makes the lexer *much* easier to read and debug! In the end the parser exclusively uses only pattern matching and function clauses. No "if" or "case" or any other syntactic sugar. And it reads very clearly! (well, for me at least!) Adding clauses containing exit, throw or returning {error,ErrCode} just adds clutter with no advantage whatsoever. Pete. On Thu, 18 Dec 2003 12:03:58 -0800 Chris Pressey wrote: > On Thu, 18 Dec 2003 10:29:06 +0100 > Bengt Kleberg wrote: > > > Chris Pressey wrote: > > > But even if you don't use it, you have to recognize that many > > > programmers do, and for the "let it crash" style to work, code has > > > to be allowed to crash at runtime, even when it "can't be right". > > > > yes, i am all for letting code crash. i just do not think it is > > usefull to let the compiler produce code for a module that will always > > crash because potentially correct code is written in such a way as to > > produce a runtime error. > > > > use > > erlang:throw/1 > > or > > erlang:exit/1 > > if an runtime error is what you want. > > You're of course entitled to hold any opinion you wish, but I really > have to say that I disagree, and that I can't quite see your reasoning. > > In Erlang as we know it, a + 42 generates an exception. An exception is > by definition not a show-stopper; it can be caught and acted upon. But > by changing it into a compile-time error, you're not even giving the > program an *opportunity* to crash. This runs against the "let it crash" > philosophy in my book. > > Also, by forcing the programmer to write throw(blah) to cause an > exception, you're making them *make* it crash, which also runs counter > to "let it crash" - the programmer needn't exert such explicit effort. > > To once again attempt to illustrate the difference: > > foo() = (catch bar()). > bar() -> > true = some_assertion_which_may_or_may_not_be_constant(), > stuff(). > > ...versus... > > foo() = (catch bar()). > bar() -> > case some_assertion_which_may_or_may_not_be_constant() of > true -> stuff(); > false -> throw(badarg) > end. > > I'd much rather write (and read) the first version than the second. > Maybe it's just me, but I think it's more concise, more direct, and just > generally clearer. I also don't think it makes sense for the > compilation itself to succeed or fail based solely on whether > some_assertion_which_may_or_may_not_be_constant() is (detectably) > constant or not. That's why I'd much rather it be merely a compile-time > warning. > > I'm all for getting as much information about possible errors as early > as possible - but I'm not in favour of dramatic shifts in how this > information would affect what is and what is not "legal Erlang". > > -Chris > > -- "The Tao of Programming flows far away and returns on the wind of morning." From dhanasekaran.c@REDACTED Fri Dec 19 05:36:33 2003 From: dhanasekaran.c@REDACTED (Chenniappan,Dhanasekaran [DBA]) Date: Fri, 19 Dec 2003 10:06:33 +0530 Subject: open_port function problem. Message-ID: <46206018C119D611A0C2000255D4191B705465@NTSERVER> hai, we are working on erlang port communication program which communicate with c .exe . for that we use open_port like "open_port({spawn, ExtPrg}, [{packet, 2}])," our problem is when we are sending number 26 through that port the port get closed.what may be possibly wrong with this. and when we give 10 through buffer it always prints we assume that it may be due to ascii property of 10 & 13 which is new line and cairrage return respectively, but how can these things be handled effectively,there is no clue regarding the port close when sending 26. Evenn the example foo also reflect the same resullt. Please give us an solution in this problem. regards dhanas From ingela@REDACTED Fri Dec 19 09:18:19 2003 From: ingela@REDACTED (Ingela Anderton) Date: Fri, 19 Dec 2003 09:18:19 +0100 Subject: open_port function problem. References: <46206018C119D611A0C2000255D4191B705465@NTSERVER> Message-ID: <16354.46155.875903.980690@gargle.gargle.HOWL> Maybe you should read the documentation a bit closer ;) http://www.erlang.org/doc/r9c/doc/index.html >From man page of the module erlang: port_command(Port, Data) [...] Failure: badarg if Port is not an open port or the registered name of an open port, or if Data is not an I/O list. An I/O list is a binary or a (possibly) deep list of binaries or integers in the range 0 through 255. [...] Chenniappan,Dhanasekaran [DBA] wrote: > hai, > > we are working on erlang port communication program which communicate with > c .exe . for that we use open_port like > "open_port({spawn, ExtPrg}, [{packet, 2}])," > > our problem is when we are sending number 26 through that port the port get > closed.what may be possibly wrong with this. and when we give 10 through > buffer it always prints we assume that it may be due to ascii property of 10 > & 13 which is new line and cairrage return respectively, but how can these > things be handled effectively,there is no clue regarding the port close when > sending 26. Evenn the example foo also reflect the same resullt. Please give > us an solution in this problem. > > regards > dhanas -- /m.v.h Ingela //The highway of life is always under construction. // |\ _,,,--,,_ ,) /,`.-'`' -, ;-;;' |,4- ) )-,_ ) /\ '---''(_/--' (_/-' Ericsson AB - OTP team Cellular/Mobile: +46 70 636 78 68 From joachim.durchholz@REDACTED Fri Dec 19 09:50:40 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Fri, 19 Dec 2003 09:50:40 +0100 Subject: open_port function problem. In-Reply-To: <46206018C119D611A0C2000255D4191B705465@NTSERVER> References: <46206018C119D611A0C2000255D4191B705465@NTSERVER> Message-ID: <3FE2BBE0.4000208@web.de> Chenniappan,Dhanasekaran [DBA] wrote: > hai, > > we are working on erlang port communication program which communicate with > c .exe . for that we use open_port like > "open_port({spawn, ExtPrg}, [{packet, 2}])," > > our problem is when we are sending number 26 through that port the port get > closed.what may be possibly wrong with this. and when we give 10 through > buffer it always prints we assume that it may be due to ascii property of 10 > & 13 which is new line and cairrage return respectively, but how can these > things be handled effectively,there is no clue regarding the port close when > sending 26. Evenn the example foo also reflect the same resullt. Please give > us an solution in this problem. You're probably working on a Windows system, and the port got opened in text mode. Under Windows, text mode file handles will interpret code 10 (newline) as line end (and store the bytes 13 and 10, carriage return and newline, to establish conformance with Windows conventions). Code 26 is Control-Z, which means end-of-file (this is a really ancient convention but kept for compatibility). To get rid of these effects, open the port in "binary" mode; in this mode, no translation takes place. Text mode interpretation may happen both on the sending and receiving end of the pipe. IOW you should not only check the Erlang side of things, but also the C side. Actually, when I think of it, it's most likely that you're just using the stdin handle in the C program, which is always opened in text mode for you; you have to change its mode (not sure how to do this, you're probably in for an extensive search in MSDN). Keep us posted on results, this might be an interesting information snippet to be added to the Erlang documentation :-) HTH Jo From ingela@REDACTED Fri Dec 19 10:13:49 2003 From: ingela@REDACTED (Ingela Anderton) Date: Fri, 19 Dec 2003 10:13:49 +0100 Subject: open_port function problem. References: <46206018C119D611A0C2000255D4191B705465@NTSERVER> <3FE2BBE0.4000208@web.de> Message-ID: <16354.49485.527970.707810@gargle.gargle.HOWL> Joachim Durchholz wrote: > Chenniappan,Dhanasekaran [DBA] wrote: > > sending 26. Evenn the example foo also reflect the same > > resullt. Please Humm ... my interpretation of sending foo is that the atom foo was sent, but maybe I was reading to much in to it. If what was sent was "foo" and the system used is windows you have a valid point below. > You're probably working on a Windows system, and the port got opened in > text mode. > Under Windows, text mode file handles will interpret code 10 (newline) > as line end (and store the bytes 13 and 10, carriage return and newline, > to establish conformance with Windows conventions). Code 26 is > Control-Z, which means end-of-file (this is a really ancient convention > but kept for compatibility). > > To get rid of these effects, open the port in "binary" mode; in this > mode, no translation takes place. > > Text mode interpretation may happen both on the sending and receiving > end of the pipe. IOW you should not only check the Erlang side of > things, but also the C side. > Actually, when I think of it, it's most likely that you're just using > the stdin handle in the C program, which is always opened in text mode > for you; you have to change its mode (not sure how to do this, you're > probably in for an extensive search in MSDN). > > Keep us posted on results, this might be an interesting information > snippet to be added to the Erlang documentation :-) Well yes this is true, maybe we should add something about the wonderful world of windows to the documentation! -- /m.v.h Ingela Ericsson AB - OTP team From vlad_dumitrescu@REDACTED Fri Dec 19 10:49:42 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 19 Dec 2003 10:49:42 +0100 Subject: open_port function problem. References: <46206018C119D611A0C2000255D4191B705465@NTSERVER> <3FE2BBE0.4000208@web.de> Message-ID: From: "Joachim Durchholz" > Actually, when I think of it, it's most likely that you're just using > the stdin handle in the C program, which is always opened in text mode > for you; you have to change its mode (not sure how to do this, you're > probably in for an extensive search in MSDN). That's an easy one :-) Use from io.h int _setmode ( int handle, int mode ); details at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_crt__setmode.asp regards, Vlad From ok@REDACTED Mon Dec 22 04:58:44 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 22 Dec 2003 16:58:44 +1300 (NZDT) Subject: Small poll Message-ID: <200312220358.hBM3wiRA164239@atlas.otago.ac.nz> Kostis Sagonas wrote: Sorry to suddently turn this thread into a political one, but the above argument seems to me an argument of the form: "Why try to eliminate some social injustices, since we are never going to eliminate them all (especially the most subtle ones)." Just think about it... Well yes, I have thought about it, and the analogy is invalid. A much more interesting and possibly more fruitful analogy is to the "human factors and safety of interfaces" stuff one often sees popping up in comp.risks. If you automate too much, people get to rely on the machine, and then the automation has to be _really_ good. If you have alarms that keep going off, people start ignoring them, and then really bad things happen, because some of the alarms aren't false. It seems that there's an optimal level of human involvement in checking; too much and people can't do it, too little and people do even less than they should. It is important for people to have a clear understanding of what the machine will check (so they don't have to) and what it won't (so they DO have to). A question I asked a couple of times in this year's functional programming exam paper had the general form - description of data structure - set up the type declarations in Haskell! - how much of the data structure invariants were you able to tell the Haskell compiler about, and why? - finish the job! Whatever you end up doing, it is a human factors disaster if the BEAM compiler and the HiPE compiler disagree, because then people will not be able to form a coherent mental model of what will be checked by machine and what they must check in their inspections. From vlad_dumitrescu@REDACTED Mon Dec 22 09:56:14 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 22 Dec 2003 09:56:14 +0100 Subject: using terminal control codes Message-ID: Erm, forget about it, it works if outputting using io:format("~s",[...]). /Vlad ----- Original Message ----- From: Vlad Dumitrescu To: - Erlang Questions Sent: Saturday, December 20, 2003 8:43 PM Subject: using terminal control codes hi all, I tried to use terminal control codes (ANSI/VT100) to beautify the screen output, but it doesn't work. Would it be difficult to make it work? Where should I begin? I know that in the general case this would require a lot of fiddling with termcap and friends, but for now I'd only want to play with what works on my screen. Thanks in advance, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad_dumitrescu@REDACTED Sat Dec 20 20:43:46 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Sat, 20 Dec 2003 20:43:46 +0100 Subject: using terminal control codes Message-ID: hi all, I tried to use terminal control codes (ANSI/VT100) to beautify the screen output, but it doesn't work. Would it be difficult to make it work? Where should I begin? I know that in the general case this would require a lot of fiddling with termcap and friends, but for now I'd only want to play with what works on my screen. Thanks in advance, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Fri Dec 19 23:28:07 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 19 Dec 2003 17:28:07 -0500 Subject: gen_server/gen_fsm trap exit signals? Message-ID: <20031219222807.GC13447@frogman.motivity.ca> I have discovered the following descrepancy between observed and documented behaviour in gen_server and gen_fsm. The documentation for both gen_server and gen_fsm states: "Note that a gen_fsm does not trap exit signals automatically, this must be explicitly initiated in the callback module." Later in describing the terminate callback it states: "If the gen_server is part of a supervision tree and is ordered by its supervisor to terminate, this function will be called with Reason=shutdown if the following conditions apply: o the gen_server has been set to trap exit signals, and o the shutdown strategy as defined in the supervisor's child specification is an integer timeout value, not brutal_kill. Otherwise, the gen_server will be immediately terminated." So what I have always assumed is that it was neccesary to use the following init/1 callback: init(Arg) -> ... %% trap exit signals process_flag(trap_exit, true), ... {ok, State}. However that doesn't prove to be neccessary in R9C. Consider the following gen_server module: -module(server). -export([init/1, handle_call/3, terminate/2]). -behaviour(gen_server). init(_) -> {ok, []}. handle_call(assert, _From, State) -> a = b, {reply, not_reached, State}; handle_call({stop, Reason}, _From, State) -> {stop, Reason, State}; terminate(Reason, State) -> io:fwrite("Called terminate(~w, ~w)~n", [Reason, State]). This is what results when it's run: 1> gen_server:call(S, {stop, normal}). Called terminate(normal, []) ** exited: {normal,{gen_server,call,[<0.39.0>,{stop,normal}]}} ** The handle_call/3 function clause returns {stop, normal, State} so the gen_fsm calls terminate to do an orderly shutdown. 3> gen_server:call(S, assert). Called terminate({{badmatch,b},[{server,handle_call,3},{proc_lib,init_p,5}]}, []) =ERROR REPORT==== 19-Dec-2003::17:03:42 === ** Generic server <0.56.0> terminating ** Last message in was assert ** When Server state == [] ** Reason for termination == ** {{badmatch,b},[{server,handle_call,3},{proc_lib,init_p,5}]} ** exited: {{badmatch,b},[{server,handle_call,3},{proc_lib,init_p,5}]} ** I did not expect this to call terminate as it is not trapping exit signals. It doesn't appear to matter whether or not process_flag(trap_exit, true is called at all. It behaves the same each way. Adding the following test shows that the current value is false: init(_) -> OldValue = process_flag(trap_exit, true), io:format("Old value of trap_exit flag was ~w.~n"), {ok, []}. 1> gen_fsm:start_link(fsm, [], []). Old value of trap_exit flag was false. So while I'm content with the staus quo it does seem that the documentation could have these statements removed as they no longer seem to apply. -Vance From vances@REDACTED Sat Dec 20 01:54:24 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 19 Dec 2003 19:54:24 -0500 Subject: gen_server/gen_fsm trap exit signals? In-Reply-To: <20031219222807.GC13447@frogman.motivity.ca> References: <20031219222807.GC13447@frogman.motivity.ca> Message-ID: <20031220005424.GD13447@frogman.motivity.ca> Never mind .... :) OK, I now see that the point of the second text is to say that the supervisor will not be polite unless the trap_exit flag is true. I was reading a little bit more into it. With process_flag(trap_exit, true) I see: 1> supervisor:terminate_child(Sup, fsm). fsm called terminate(shutdown, loop, []) ok Whereas without it I get: 2> supervisor:terminate_child(Sup, fsm). ok -Vance On Fri, Dec 19, 2003 at 05:28:07PM -0500, Vance Shipley wrote: } } It doesn't appear to matter whether or not process_flag(trap_exit, true) } is called at all. It behaves the same each way. From Bengt.Kleberg@REDACTED Fri Dec 19 10:53:38 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Fri, 19 Dec 2003 10:53:38 +0100 Subject: Small poll In-Reply-To: <20031218120358.34b6ee34.cpressey@catseye.mine.nu> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> <3FE01D31.7060808@ericsson.com> <20031217102555.19572317.cpressey@catseye.mine.nu> <3FE17362.2030600@ericsson.com> <20031218120358.34b6ee34.cpressey@catseye.mine.nu> Message-ID: <3FE2CAA2.2030907@ericsson.com> Chris Pressey wrote: ...deleted > In Erlang as we know it, a + 42 generates an exception. An exception is > by definition not a show-stopper; it can be caught and acted upon. But > by changing it into a compile-time error, you're not even giving the > program an *opportunity* to crash. This runs against the "let it crash" > philosophy in my book. as i see it (ie, really subjective thinking will follow here): i think ''let it crash'' is a good idea. i think it is such a good idea that i want it to happen as soon as possible. in this case*, as soon as possible is during compilation. *quick reminder: all exported functions in the module will crash, there are no alternative ways for them to maybe succeed. > Also, by forcing the programmer to write throw(blah) to cause an > exception, you're making them *make* it crash, which also runs counter > to "let it crash" - the programmer needn't exert such explicit effort. i am advocating erlang:throw() as a better solution than ''a+42'' to force a crash. i am not advocating erlang:throw() as a replacement for mistyping ''A+42'' :-) bengt From vlad_dumitrescu@REDACTED Mon Dec 22 13:09:05 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 22 Dec 2003 13:09:05 +0100 Subject: using terminal control codes Message-ID: Hi again, now I'm a little more focused :-) Did anyone try to compile & use slang with Erlang on Windows? I've been fiddling with what's on Jungerl, but the problem is with the slang driver, of course. Any hints? Thanks in advance, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.durchholz@REDACTED Fri Dec 19 10:04:58 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Fri, 19 Dec 2003 10:04:58 +0100 Subject: Small poll In-Reply-To: <20031218120358.34b6ee34.cpressey@catseye.mine.nu> References: <200312170422.hBH4MRRX105156@atlas.otago.ac.nz> <3FE01D31.7060808@ericsson.com> <20031217102555.19572317.cpressey@catseye.mine.nu> <3FE17362.2030600@ericsson.com> <20031218120358.34b6ee34.cpressey@catseye.mine.nu> Message-ID: <3FE2BF3A.3020700@web.de> Chris Pressey wrote: > Bengt Kleberg wrote: > >> Chris Pressey wrote: >> >> yes, i am all for letting code crash. i just do not think it is >> usefull to let the compiler produce code for a module that will >> always crash because potentially correct code is written in such a >> way as to produce a runtime error. >> >> use erlang:throw/1 or erlang:exit/1 if an runtime error is what you >> want. > > You're of course entitled to hold any opinion you wish, but I really > have to say that I disagree, and that I can't quite see your > reasoning. > > In Erlang as we know it, a + 42 generates an exception. An exception > is by definition not a show-stopper; it can be caught and acted upon. > But by changing it into a compile-time error, you're not even giving > the program an *opportunity* to crash. This runs against the "let it > crash" philosophy in my book. I think you're misunderstanding Chris. I don't remember him advocating adding a _ = throw ("No pattern matched for function foo") clause to every function. He's advocating replacing a + 42 with throw ("Not Implemented Yet") and I'd like to join in: `throw' tells the reader that the error was intentional, and its argument provides information why the crash was programmed and whether that's a temporary or permanent decision. That's *far* better than `a + 42'. `a + 42' is a cute trick - and cute tricks should be avoided since they make software less maintainable, at least in my experience; software should explicitly state what it does, and not rely on implicit behaviour - I know that both constructing and deciphering cute tricks can give enormous mental satisfaction, but the downside is that the code will be readable for a slightly smaller fraction of programmers, and that's an unacceptable side effect. IMHO. Regards, Jo From joachim.durchholz@REDACTED Mon Dec 22 14:21:45 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Mon, 22 Dec 2003 14:21:45 +0100 Subject: using terminal control codes In-Reply-To: References: Message-ID: <3FE6EFE9.7030406@web.de> Vlad Dumitrescu wrote: > Hi again, > > now I'm a little more focused :-) > > Did anyone try to compile & use slang with Erlang on Windows? I've been > fiddling with what's on Jungerl, but the problem is with the slang > driver, of course. You can't rely on control codes and escape sequences in Windows. On Win 9x, it depends on whether ANSI.SYS is loaded (and loading it is actually a bad idea because malware can reprogram the keyboard mapping, though that used to be more of a problem in DOS times). Not sure how things work out in Win NT/2K/XP. But, in general, doing fancy interface stuff "isn't done" in text mode on Windows. In other words, whatever you do on Windows, you can expect to run into problems because fixing the text interface was never important. Worse, you'll probably be quite on your own with any problems. If I were to port a Unix program with an elaborate text UI to Windows, /and/ wanted to be portable across Windows versions, I'd probably look for a VT100 emulation, and link the software up with that. There are several ways to emulate VT100: - install an X server and run an xterm. - I think there's a way to make Windows loopback the serial interface, without even going through the real hardware; if that's possible, one could use any serial terminal program (actually Windows comes with one). - maybe there's even a direct VT100 emulation available that communicates with the application via pipes (for NT/2K/XP) or Windows messages (for 9x). - set up an sshd under Windows (maybe using cygwin, though that's quite heavy) and connect PuTTY to localhost. - grab the terminal emulation of PuTTY (it's open source) and make it a standalone VT100 emulation. When programming for a specific flavor of Windows, I'd go digging in MSDN and see whether the control codes are available, before taking the VT100 route. If it's possible, that's much less work than the VT100 emulation route. Regards, Jo From vlad_dumitrescu@REDACTED Mon Dec 22 14:51:05 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 22 Dec 2003 14:51:05 +0100 Subject: using terminal control codes References: <3FE6EFE9.7030406@web.de> Message-ID: From: "Joachim Durchholz" > You can't rely on control codes and escape sequences in Windows. Thanks for the advice! As you probably saw from my other question, I am looking at using the slang library, which is portable. All the terminal emulation would provide some insulation, but it's quite heavy. I just want to play with a more advanced output from Erlang :-) regards, Vlad From jamesh@REDACTED Mon Dec 22 15:28:04 2003 From: jamesh@REDACTED (James Hague) Date: Mon, 22 Dec 2003 08:28:04 -0600 Subject: New compiler warnings in R10B Message-ID: >/home/bjorn/test/fact.erl:10: Warning: this >clause cannot match because the previous clause >always matches I like this a lot! Excellent! BTW, is there a running list somewhere of changes being made for R10B? In the daily build, perhaps? From klacke@REDACTED Tue Dec 23 01:10:15 2003 From: klacke@REDACTED (klacke@REDACTED) Date: Tue, 23 Dec 2003 01:10:15 +0100 Subject: dets fatal bug Message-ID: <20031223001015.GA17766@hyber.org> I've started to distrust dets: The following program: -module(detsloop). -compile(export_all). start(Arg) -> case catch (run(Arg)) of {'EXIT', Rsn} -> {ok, Out} = file:open("err", [append]), io:format(Out, "~p~n",[Rsn]); _ -> ok end. run([I]) -> Int = list_to_integer(atom_to_list(I)), case dets:open_file(a, [{file, "foooo"}]) of {ok, Name} -> dloop(Name, 1); Err -> ok = file:delete("foooo"), exit({Int, Err}) end. dloop(Name, I) -> dets:insert(Name, {I, akakaka,3.45, make_ref(), self(),"aaaaaaaaaaaaa", 33333333333333333333333333333333333}), dloop(Name, I+1). Run from the following pretty brutal shell script: (invoke shellscript with numeric arg) #!/bin/sh i=$1; while [ $i -gt 0 ]; do echo $i i=`expr $i - 1` erl -detached -s detsloop start $i sleep 6 killall -KILL beam sleep 1 done Will produce an err log containing a number of {8,{error,{not_a_dets_file,"foooo"}}} ..... entries, Thus KILL ing erlang while writing a detsfile corrupts the dets file beyond repair. Bad. Here is some system info: fs: reiserfs linux 2.6.0 erl: R9C-0 I've had similar behaviour on less exotic linuxen as well. /klacke -- Sending a bugreport without a fix :-( -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From klacke@REDACTED Tue Dec 23 01:19:41 2003 From: klacke@REDACTED (klacke@REDACTED) Date: Tue, 23 Dec 2003 01:19:41 +0100 Subject: The dets bug again Message-ID: <20031223001941.GA17889@hyber.org> I run my little test program on R7B and it worked like a charm, so dets is indeed broken in R9C It's a pretty bad program to have broken if you rely on mnesia for your user data ... to say the least. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From taj.khattra@REDACTED Tue Dec 23 04:58:57 2003 From: taj.khattra@REDACTED (Taj Khattra) Date: Mon, 22 Dec 2003 19:58:57 -0800 Subject: The dets bug again In-Reply-To: <20031223001941.GA17889@hyber.org> References: <20031223001941.GA17889@hyber.org> Message-ID: <20031223035857.GA13153@localhost.localdomain> On Tue, Dec 23, 2003 at 01:19:41AM +0100, klacke@REDACTED wrote: > I run my little test program on R7B and it worked like a > charm, so dets is indeed broken in R9C i was able to reproduce it too (linux 2.4.18, ext3 fs). when i modified the call to dets:open_file() to create a version 8 table instead dets:open_file(a, [{file, "foooo"}, {version, 8}]) it didn't produce any errors -taj From hasse@REDACTED Tue Dec 23 09:35:17 2003 From: hasse@REDACTED (Hans Bolinder) Date: Tue, 23 Dec 2003 09:35:17 +0100 Subject: dets fatal bug Message-ID: <16359.65093.509756.160269@gargle.gargle.HOWL> [Klacke:] > I've started to distrust dets: Sorry to hear that. Next release of Open Source Erlang will have the patch of stdlib/src/dets_v9.erl attached below. I trust you will report any further problems you encounter. Best regards, Hans Bolinder, Erlang/OTP -------------------- 215d214 < -define(NO_KEYS_POS, (?D_POS + 16)). 419c418 < {NewHead, InitSegment, [SegPointer, InitArrPart, ArrPartPointer]}; --- > {NewHead, InitSegment, [InitArrPart, SegPointer, ArrPartPointer]}; 1225c1224 < NoParts = no_parts(Head#head.m), --- > NoParts = no_parts(Head#head.next), 1589c1588,1592 < NoColls = case H1#head.no_collections of --- > FileHeader = file_header(H1, FreeListsPointer, ?CLOSED_PROPERLY), > dets_utils:pwrite(H1, [{0, FileHeader}]). > > file_header(Head, FreeListsPointer, ClosedProperly) -> > NoColls = case Head#head.no_collections of 1597,1598c1600 < FileHeader = file_header(H1, FreeListsPointer, ?CLOSED_PROPERLY, CW), < dets_utils:pwrite(H1, [{0, FileHeader}]). --- > file_header(Head, FreeListsPointer, ClosedProperly, CW). 2358a2361,2362 > NewNoObject = Head#head.no_objects + DeltaObjects, > NewHead = Head#head{no_objects = NewNoObject, no_keys = NewNoKeys}, 2361c2365 < NewNoKeys > Head#head.max_no_slots -> --- > NewNoKeys > NewHead#head.max_no_slots -> 2366c2370 < [{?NO_KEYS_POS, <>} | Ws] --- > [{0, file_header(NewHead, 0, ?NOT_PROPERLY_CLOSED)} | Ws] 2368,2369c2372 < NewNoObject = Head#head.no_objects + DeltaObjects, < {Head#head{no_objects = NewNoObject, no_keys = NewNoKeys}, NWs}. --- > {NewHead, NWs}. From chandrashekhar.mullaparthi@REDACTED Tue Dec 23 12:58:09 2003 From: chandrashekhar.mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Tue, 23 Dec 2003 11:58:09 +0000 Subject: Signed integers Message-ID: All, to_signed_int(Int, NumOctets) when integer(Int) -> NumBits = NumOctets * 8, <> = <>, SignedInt. 1> etopup_worker:to_signed_int(65535, 2). -1 Is there a better way to convert unsigned integers to signed integers? cheers Chandru From klacke@REDACTED Tue Dec 23 14:00:23 2003 From: klacke@REDACTED (klacke@REDACTED) Date: Tue, 23 Dec 2003 14:00:23 +0100 Subject: dets fatal bug In-Reply-To: <16359.65093.509756.160269@gargle.gargle.HOWL> References: <16359.65093.509756.160269@gargle.gargle.HOWL> Message-ID: <20031223130023.GA23886@hyber.org> On Tue, Dec 23, 2003 at 09:35:17AM +0100, Hans Bolinder wrote: > [Klacke:] > > I've started to distrust dets: > > Sorry to hear that. Next release of Open Source Erlang will have the > patch of stdlib/src/dets_v9.erl attached below. > Thanks alot, patch works perfect. Cheers /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From hal@REDACTED Tue Dec 23 20:38:05 2003 From: hal@REDACTED (Hal Snyder) Date: Tue, 23 Dec 2003 13:38:05 -0600 Subject: Network benchmark - header parsing In-Reply-To: <20031215080640.04ffcdfc.erlang@manderp.freeserve.co.uk> (Peter-Henry Mander's message of "Mon, 15 Dec 2003 08:06:40 +0000") References: <87k752z2iq.fsf@ghidra.vail> <87he0654rm.fsf_-_@ghidra.vail> <20031215080640.04ffcdfc.erlang@manderp.freeserve.co.uk> Message-ID: <87llp3s4te.fsf@ghidra.vail> Peter-Henry Mander writes: > Someone mention SIP parsing using bit-syntax? > > I'm currently writing a SIP message parser using pattern matching on > lists. I was wondering if anyone would be kind enough to share their > thoughts and experience about using binaries instead. How would I > handle syntax such as: > > Timestamp = "Timestamp" HCOLON 1*( DIGIT ) ["." *( DIGIT )] [LWS delay] > delay = *( DIGIT ) ["." *( DIGIT )] > LWS = [*WSP CRLF] 1*WSP > > Doing this in list pattern matching is easy. I'm concerned that if I > pattern-matched a binary, I would end up making many copies of the > binary. My efforts here so far are limited to thought experiments. :( But, last time I looked at header parsing for HTTP in erts/emulator/drivers/common/inet_drv.c I convinced myself SIP parsing was doable with a similar hack. > Or am I imagining false problems which don't exist? I suspect you are imagining real problems. > I notice that the Megaco stack uses a link-in C driver that is > generated using lex. That was news to me. Interesting! > Would this be the most effective way of parsing SIP, instead on > parsing a list? No doubt. Will experiment with it if time allows. From mkurkov@REDACTED Wed Dec 24 10:14:56 2003 From: mkurkov@REDACTED (Mikl Kurkov) Date: Wed, 24 Dec 2003 12:14:56 +0300 Subject: gs:start() problem Message-ID: <004301c3c9fe$6ac33500$52edaac3@MKurkov> Hi all! I'm new to Erlang and now playing with GUI system. Trying to invoke simple gs:start(), i've got error: =ERROR REPORT==== 24-Dec-2003::12:01:30 === Error in process <0.33.0> with exit value: {{badmatch,{error,enotsock}},[{gstk_p ort_handler,init,2}]} I have tcl 8.4 installed but after uninstalling it, i've got the same error. Same error I see when trying to invoke toolbar:start(). I'm using Win2000, Erlang\OTP R9C. On my home system (Win2000 too) all work perfectly. Any suggestions? -- Mikl Kurkov. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Wed Dec 24 21:44:39 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 24 Dec 2003 21:44:39 +0100 Subject: Small poll In-Reply-To: References: Message-ID: On 17 Dec 2003 21:31:39 +0100, Luke Gorrie wrote: > I really want it as a way to write a who_calls(M,F,A)->[{M,F,A}] > function that could be used by Emacs for a "reverse tags lookup". > who_calls would expect all relevant modules to be loaded and do a fold > over them to find all callers. Then I can present the results in a > "hyperlinked" buffer and save myself a lot of grep'ery. CCviewer does this, and also who_uses_record(R) and who_uses_macro(M). It keeps a RAM database which is incrementally updated as it discovers that source modules have changed. There are some built-in analyses that can be used through the web interface, like finding cyclical dependencies between modules (or functions), and listing all users of a particular application. I've been meaning to provide an API other than the web interface to facilitate static analysis on the fly, perhaps from Distel. What's been stopping me is that my maintenance effort for CCviewer is ~0 right now, and that suits me just fine. So unless someone really wants to start using it and doing weird and wonderful stuff with it, it stays the way it is. /Uffe -- Ulf Wiger From erlang@REDACTED Tue Dec 30 02:12:12 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Mon, 29 Dec 2003 22:12:12 -0300 Subject: Mnesia data capabilities Message-ID: <00ca01c3ce71$f9eab240$0f00a8c0@daniel> Hi, I would appreciate if anybody can give us some advice about mnesia, as we have seen certain limitations, in terms of mnesia tables and data size, which we can not precisely know. So, we wonder if there is an optimum relationship among the number of tables and the size of each table for a certain amount of records, of a certain size to be saved. Let me describe you our situation: we would like to migrate 10.000.000 records, from a file server to a mnesia database: The information on the file server, is in text format, (each line is a record of 100 bytes) as follows: It contains a complex directory structure, with 100.000 files, and each of the files has 100 lines of 100 bytes each. As I mentioned, each line is one "record" with phone user data. Initially, all we want to do is to remove the file server, so we are not creating a set of fields for each record. Instead, we are considering each record as a single piece of information. So, my question is how to build/distribute a set of tables in a "mnesia safe structure" that could hold this amount of records (10.000.000 records) in an optimum configuration We have initially considered the following alternatives: 1) Creating 1000 tables, with 10.000 records each. Tables have been created, but it crashes with "mnesia info", with the tables empty 2) 100 tables, with 100.000 records each 3) One huge table (10.000.000 records) partitioned Best Regards, daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwilligs@REDACTED Tue Dec 30 20:06:40 2003 From: mwilligs@REDACTED (mwilligs@REDACTED) Date: Tue, 30 Dec 2003 16:06:40 -0300 (PYST) Subject: Embed structure in Megaco Message-ID: <1603.65.198.40.11.1072811200.squirrel@unimail.uninet.com.py> We have the next megaco transaction: Step 1 MGC to RGW: MEGACO/1 [216.33.33.61]:27000 Transaction = 1234 { Context = - { Modify = TermA { Media { LocalControl { Mode = Receiveonly} }, DigitMap= Dmap1 {(2XXX)} Events = 1111 { al/of Embed {signals {cg/dt}, Events=1112 {al/on}, {dd/ce {Dmap1}}} } } } Can "signals" be an "Embed"'s parameter. If "signals" can be an "Embed"'s parameter, how can I encode it in Megaco-Erlang? In Megaco-Erlang we have: RequestedActions { keepActive eventDM secondEvent signalDescriptor ... } In this point 'secondEvent' (Embed) and 'signalDescriptor' (Signal) are in the same level. But, following 'secondEvent', we have: SecondEventDescriptor { requestID eventList } there is no 'signalDescriptor' in this structure. So, is the Transaction showed in the RFC wrong? From robert.virding@REDACTED Wed Dec 31 00:36:23 2003 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 31 Dec 2003 00:36:23 +0100 Subject: Small poll References: <200312220358.hBM3wiRA164239@atlas.otago.ac.nz> Message-ID: <004101c3cf2d$bc8f6d20$8300a8c0@virding.org> This discussion just goes on :-) I still have not seen any good reasons to change my viewpoint, in fact I have got a few to become even more restrictive: 1. a+42, 1=2, etc are all legal expressions even if they generate errors when evaluated. As errors have meaning in Erlang then you can't just forbid them. 2. Many of the warnings generated by the compiler have been chosen in an extremely ad hoc fashion, they were deemed useful by someone and easy to implement. There is really no clear policy for what is checked and what is not. I mean why check the arguments to io:format and not a host of other common library functions. Especially considering that io:format is easy to guard against. Richard O'Keefe wrote some good stuff about the problems of getting the right level of checking. 3. With this in mind then Bjorn's new checks are probably a bad idea, the warnings become even more ad hoc and difficult to understand. I wonder if maybe some of the existing warnings should be removed. I still say that many of the warnings give very little and some are a right pain.*** 4. You cannot have the option of forbidding legal code, no matter how stupid it may seem. The compiler must handle all legal code. Trying to guess and saying that 90% of the time the user wrote this then they made an error is not good enough. This is similat to the syntax change suggestion concerning =<< made earlier. 5. I wonder if it is good for the compiler to try and use warnings to enforce a certain programming style? *** Two warnings that really anoy me are unused vars and unused functions. I seldom use '_', the anonymous variable, but prefer to give all variables names so I know what they are, even if I don't use them later. I DON'T LIKE the _Varname convention so why should the compiler try and enforce. Of course the alternative would be to ALWAYS use it. That would teach the compiler to mind its own business. :-) When I define a data structure and its access functions I always define full range of access functions, even those which are not used. I think the structure and how it is intended to be used becomes clearer then. Having the compiler burn me with warnings is irritating to say the least. Yes I can wrap the unused ones in comments but then I don't get any checking. This has been done to me in the compiler code. Anyway what is wrong with defining unused functions? They don't hurt anyone and the compiler removes them from the code anyway. Robert From raphael.bellec@REDACTED Tue Dec 30 18:47:18 2003 From: raphael.bellec@REDACTED (Raphael Bellec) Date: Tue, 30 Dec 2003 18:47:18 +0100 Subject: trailing a growing file Message-ID: <001401c3cefc$f89439d0$1474010a@raphael> Hello, I am actually working on a multi-log multi-host monitoring (and reacting) system, made in erlang and I need some advice: I would like to read logs file as soon as data is written to them. I actually have found 2 ways for this purpose: - With Io module, pooling (each time I get an eof, I wait a small time then try again). - With ports, spawning "tail -f -n 1 /path/to/file", which is the method I currently use. Is there a other way to "receive" news lines as they are written in the file without pooling or using an external application? I read few messages saying that there was no blocking IO in erlang, but I think this was mainly from a VM perspective. (I will have few hundreds logs to monitor) I currently use the port solution and I sometimes have a "broken pipe" error, I think this is because of the "in" parameter in open_port, but I hat it sometime without this parameter, anybody have a more detailed explanation of what could happen ? Regards. Rapha?l. Ps: the subject is directly taken from a point in the erlang PLEAC which is still empty. Rapha?l Bellec Manobi France Cap Alpha Avenue de l'Europe, Clapiers 34940 Montpellier Cedex 09 T?l : + 33 (0) 4 67 59 36 56 Fax : + 33 (0) 4 67 59 30 10 E-mail : raphael.bellec@REDACTED --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.556 / Virus Database: 348 - Release Date: 26/12/2003 -------------- next part -------------- An HTML attachment was scrubbed... URL: From spearce@REDACTED Wed Dec 31 02:37:55 2003 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 30 Dec 2003 20:37:55 -0500 Subject: trailing a growing file In-Reply-To: <001401c3cefc$f89439d0$1474010a@raphael> References: <001401c3cefc$f89439d0$1474010a@raphael> Message-ID: <20031231013755.GA30880@spearce.org> tail -f just does the same thing you are doing by reading the log, hitting EOF, and waiting a short while. Classic UNIX/POSIX doesn't have a way to get new data from a file, or to find out when a file/directory is modified - applications just have to poll. FreeBSD and IRIX (that I know of) have methods where an application can open a directory or file, and tell the OS it is interested in being notified when a change is made. Then you read from it and carry on. Under IRIX this is called FAM (File Activity Monitor). I don't know what FreeBSD calls it; and to my knowledge Linux does not have support for this. If the log writer is another Erlang node I would suggest just sending the log data to the target node, as well as write it to disk. If the log writer is an external process, well, you are stuck. If it is a syslogd maintained file, perhaps you could put an Erlang node into the list of targets syslogd will write the logs to. If the log writer is anything else, you'll need to either patch the application (example would be with Apache build or reuse a mod_* that can send the logs over the network to an Erlang node), or just poll the log file... If it was me, I'd be polling from within Erlang using a raw file (so no extra process is started) rather than using a port to tail -f. Raphael Bellec wrote: > > Hello, > I am actually working on a multi-log multi-host monitoring (and > reacting) system, made in erlang and I need some advice: > > I would like to read logs file as soon as data is written to them. I > actually have found 2 ways for this purpose: > - With Io module, pooling (each time I get an eof, I wait a small time > then try again). > - With ports, spawning "tail -f -n 1 /path/to/file", which is the method > I currently use. > > Is there a other way to "receive" news lines as they are written in the > file without pooling or using an external application? I read few > messages saying that there was no blocking IO in erlang, but I think > this was mainly from a VM perspective. (I will have few hundreds logs to > monitor) > > I currently use the port solution and I sometimes have a "broken pipe" > error, I think this is because of the "in" parameter in open_port, but I > hat it sometime without this parameter, anybody have a more detailed > explanation of what could happen ? > > Regards. > > Rapha?l. > > Ps: the subject is directly taken from a point in the erlang PLEAC which > is still empty. -- Shawn. If a subordinate asks you a pertinent question, look at him as if he had lost his senses. When he looks down, paraphrase the question back at him. From carsten@REDACTED Wed Dec 31 02:58:07 2003 From: carsten@REDACTED (Carsten Schultz) Date: Wed, 31 Dec 2003 02:58:07 +0100 Subject: trailing a growing file In-Reply-To: <001401c3cefc$f89439d0$1474010a@raphael> References: <001401c3cefc$f89439d0$1474010a@raphael> Message-ID: <20031231015806.GA4521@penne.localnet> On Tue, Dec 30, 2003 at 06:47:18PM +0100, Raphael Bellec wrote: > I would like to read logs file as soon as data is written to them. I > actually have found 2 ways for this purpose: > > - With Io module, pooling (each time I get an eof, I wait a small > time then try again). > > - With ports, spawning "tail -f -n 1 /path/to/file", which is the > method I currently use. Just a note to help in the comparison of these two options: (GNU) tail (basically) works by checking every second (or whatever --sleep-interval is set to) if the file's size has changed. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.fu-mathe-team.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andrae.muys@REDACTED Wed Dec 31 04:50:36 2003 From: andrae.muys@REDACTED (Andrae Muys) Date: Wed, 31 Dec 2003 13:50:36 +1000 Subject: trailing a growing file In-Reply-To: <20031231013755.GA30880@spearce.org> References: <001401c3cefc$f89439d0$1474010a@raphael> <20031231013755.GA30880@spearce.org> Message-ID: <3FF2478C.7060905@braintree.com.au> Shawn Pearce wrote: > tail -f just does the same thing you are doing by reading the log, > hitting EOF, and waiting a short while. > > Classic UNIX/POSIX doesn't have a way to get new data from a file, or > to find out when a file/directory is modified - applications just have > to poll. > > FreeBSD and IRIX (that I know of) have methods where an application > can open a directory or file, and tell the OS it is interested in > being notified when a change is made. Then you read from it and > carry on. Under IRIX this is called FAM (File Activity Monitor). I > don't know what FreeBSD calls it; and to my knowledge Linux does not > have support for this. > > If the log writer is another Erlang node I would suggest just sending > the log data to the target node, as well as write it to disk. If the > log writer is an external process, well, you are stuck. If it is a > syslogd maintained file, perhaps you could put an Erlang node into the > list of targets syslogd will write the logs to. > > If the log writer is anything else, you'll need to either patch the > application (example would be with Apache build or reuse a mod_* that > can send the logs over the network to an Erlang node), or just poll > the log file... > > If it was me, I'd be polling from within Erlang using a raw file (so > no extra process is started) rather than using a port to tail -f. > > Other options include: Using a FIFO instead of a raw file, and using poll/select. Using dnotify under Linux to achieve a similar effect as IRIX's FAM. Note if the logfile is generated by syslogd, you can configure it to log to both a FIFO and a regular file. Andrae -- Andrae Muys Engineer Braintree Communications "Now, allowing captured continuations to be inspected and altered at runtime (including binding mutation, complete rebinding of scopes, and call tree mutation)... *that* is really evil. And, I should point out, quite useful." - Dan Sugalski From joachim.durchholz@REDACTED Wed Dec 31 09:51:35 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Wed, 31 Dec 2003 09:51:35 +0100 Subject: trailing a growing file In-Reply-To: <001401c3cefc$f89439d0$1474010a@raphael> References: <001401c3cefc$f89439d0$1474010a@raphael> Message-ID: <3FF28E17.8050605@web.de> Raphael Bellec wrote: > > I would like to read logs file as soon as data is written to them. Another approach: Organize things so that the log output goes to a pipe. Use the "tee" command to duplicate the output, one going to another pipe, the other going to the log file. Your application can then read the tee'd-off pipe, automatically blocking when there is no more input and automatically unblocking as soon as new input becomes available. HTH Jo From massimo.cesaro@REDACTED Wed Dec 31 10:42:53 2003 From: massimo.cesaro@REDACTED (Massimo Cesaro) Date: 31 Dec 2003 10:42:53 +0100 Subject: Managing C nodes from an Erlang application Message-ID: <1072863778.12272.71.camel@xam> In our Erlang application (built following the Design Principles guidelines) we have a mix of Erlang modules and nodes and C nodes. While it is simple to put under a supervision tree the Erlang parts, it is not clear to me how to start and stop C nodes from the application. Currently we just assume that the nodes are running and in the correct state at application boot, and we do this starting as daemons (we're under Linux) the C nodes using shell scripts. What we'd like to have is a common management both for Erlang and C nodes, like having the Pid of Cnodes, using whereis() for checking if the Cnode is registered, etc. Any suggestion on how to replace this shell script driven management of C node with something more robust and predictable ? Regards, Massimo Cesaro From serge@REDACTED Wed Dec 31 14:40:15 2003 From: serge@REDACTED (Serge Aleynikov) Date: Wed, 31 Dec 2003 08:40:15 -0500 Subject: Pattern matching vs. ETS lookups In-Reply-To: <1072863778.12272.71.camel@xam> References: <1072863778.12272.71.camel@xam> Message-ID: <3FF2D1BF.9050201@hq.idt.net> In implementing an application dealing with some binary protocol I ran into a question that I'd like to ask Erlang community. A binary protocol involves parsing a header which determines the function to be called, and a body of variable length. The main question is if the number of functions is large > 250, is it better (i.e. faster, more compact, more efficient?) to implement header/body parsing using hard-coded patterns: % Input types: <> f1(<<1, Body/binary>>) -> ...; f1(<<2, Body/binary>>) -> ...; f1(<<3, Body/binary>>) -> ...; ... f1(<<255, Body/binary>>) -> ... . or to have an ETS table tha would store tuples in the form: {FunctionID, BodyParsingFunction} where the ETS table (Table) would initially be populated with a function list, and later do: f(<>, Table) -> BodyParsingFunction = ets:lookup_element(Table, FunctionID, 2), BodyParsingFunction(Body). In the first case if the f1(<<255, ...>>) function is called, would the bytecode interpreter have to evaluate 255 overloaded function patterns before it can successfully invoke the last function in the list? Thanks. Serge From james@REDACTED Wed Dec 31 18:07:45 2003 From: james@REDACTED (James Hague) Date: Wed, 31 Dec 2003 11:07:45 -0600 Subject: Small poll Message-ID: <3FF2AE01.22648.24A12D@localhost> Robert Virding wrote: >2. Many of the warnings generated by the >compiler have been chosen in an extremely >ad hoc fashion, they were deemed useful by >someone and easy to implement. There is >really no clear policy for what is checked >and what is not. I mean why check the >arguments to io:format and not a host of >other common library functions. I tried to make this point in an earlier message, though I may not have succeeded. I don't really want to see the compiler cluttered up with a lot of checks for things that may or may not be errors, especially when: 1. There are many more things that are not checked (for example, any place where a newbie types "x" instead of "X"). Trying to catch them all seems like a long and unproductive road to go down. (Okay, I once complained about list comprehensions without generators being quietly compiled, but I'd argue that's invalid Erlang.) 2. Simple, interactive testing catches all of these errors anyway, even the ones that aren't warned about. Additionally, I think Erlang--both the language and implementation-- are on the verge of becoming too complicated. I think both could use some streamlining. Adding ad hoc warnings is a step in the other direction. From joachim.durchholz@REDACTED Wed Dec 31 20:53:12 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Wed, 31 Dec 2003 20:53:12 +0100 Subject: Small poll In-Reply-To: <3FF2AE01.22648.24A12D@localhost> References: <3FF2AE01.22648.24A12D@localhost> Message-ID: <3FF32928.5040208@web.de> James Hague wrote: > 2. Simple, interactive testing catches all of these errors anyway, > even the ones that aren't warned about. Experiences users will find them. Warnings are useful for those things that newbies often fall trap to: these should be warnings. Or at least warnings that can be switched on using a compiler option. Just my 2c. Regards, Jo