From kent@REDACTED Wed Nov 1 00:25:40 2000 From: kent@REDACTED (Kent Boortz) Date: 01 Nov 2000 00:25:40 +0100 Subject: Patches for R7B-0 In-Reply-To: Taavi Talvik's message of "Wed, 1 Nov 2000 00:39:14 +0200 (EET)" References: Message-ID: > I do not know Ericsson policy towards Erlang development, but cvs > repository (read-only) would be nice. It opens lot of possibilities > for distribution (cvs, cvsup, cvsweb). It will probably also accelerate > development of Erlang as a language and surrounding libraries. We don't have any plans to do this at this time, sorry, kent From vladdu@REDACTED Wed Nov 1 08:58:36 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Wed, 1 Nov 2000 08:58:36 +0100 Subject: JInterface help needed Message-ID: Hi again! I have tried to tinker with JInterface, and I have some wonderings: - are there any full examples to compare with? - OtpServer is marked as deprecated. The examples in the documentation use it nevertheless, as opposed to OtpSelf who is client-only. Does OtpSelf have now all functionality from OtpServer too? If yes, the docs should be updated too... - I want to create a similar package as JInterface, but for another programming language (Borland Delphi), because I don't like Java that much and Corba would be an overkill... I think that converting JInterface more or less directly might be a good way to get a jumpstart - does anyone have done or tried something similar? any pitfalls? best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobbe@REDACTED Wed Nov 1 09:40:08 2000 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 01 Nov 2000 09:40:08 +0100 Subject: IG for c++ In-Reply-To: luc's message of "Mon, 30 Oct 2000 10:14:03 +0100" References: <39FD3BDB.5E8A7C6D@europemail.com> Message-ID: > now, my problem : i d like to wrap a C++ lib. I think I remember it was done by someone, a long time ago. > - a) adding # ifdef _cplusplus , external "C" {.... at the begining and > end of headers files. supposely no big deal. This was the way it was done I belive. > how complex is the grammar extension ? the parser ? is it generated with > Yecc ? (the history from the doc tends to make me thinking the opposite, > but there is a .y files in the sources ? The grammar is described by a yecc file (igparser.yrl). > (the history from the doc tends to make me thinking the opposite, > but there is a .y files in the sources ? Well, at the time IG was written, the Erlang compiler couldn't compile the resulting .erl file, produced from a ANSI-C.yrl grammar. So igparser.yrl has been growing by adding rules to it when needed. BTW: If someone would be interested, here is the ANSI-C yecc grammar: http://www.bluetail.com/~tobbe/ansi_c.yrl Cheers /Tobbe From vladdu@REDACTED Wed Nov 1 14:02:43 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Wed, 1 Nov 2000 14:02:43 +0100 Subject: Erlang external format Message-ID: Hi! Is the documentation about the external format provided in the distribution? If it is, I don't seem to find it... If not, where could I find it? regards Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke@REDACTED Wed Nov 1 14:18:42 2000 From: luke@REDACTED (Luke Gorrie) Date: 01 Nov 2000 14:18:42 +0100 Subject: Erlang external format In-Reply-To: "Vlad Dumitrescu"'s message of "Wed, 1 Nov 2000 14:02:43 +0100" References: Message-ID: "Vlad Dumitrescu" writes: > Is the documentation about the external format provided in the distribution? > If it is, I don't seem to find it... If not, where could I find it? I found the java source code to the otp.erlang package to be a pretty good reference. I also made a partial Emacs Lisp implementation which I think is pretty readable: http://www.javagroup.org/luke/erlext.el Cheers, Luke From kent@REDACTED Wed Nov 1 15:49:37 2000 From: kent@REDACTED (Kent Boortz) Date: 01 Nov 2000 15:49:37 +0100 Subject: Erlang external format In-Reply-To: "Vlad Dumitrescu"'s message of "Wed, 1 Nov 2000 14:02:43 +0100" References: Message-ID: Do you mean "otp_src_R7B-0/erts/emulator/internal_doc/erl_ext_dist.txt", i.e. the format used by the distribution protocol? kent From Kenneth.Browne@REDACTED Wed Nov 1 17:03:37 2000 From: Kenneth.Browne@REDACTED (Kenneth Browne (EEI)) Date: Wed, 1 Nov 2000 17:03:37 +0100 Subject: http security using mod_security Message-ID: Hi, I'm trying to set up a web server with ALL the security features that inets has to offer. I have an existing server to work from. In the config file for this server the AuthDBType is set to plain. I want to use the security features of mod_security. All I know so far is that I have to change AuthDBType plain to AuthDBType mnesia. How do I set up the rest??? I think I have to create httpd_users, and httpd_groups, but I don't know where to start ??!. -Ken. From Chandrashekhar.Mullaparthi@REDACTED Wed Nov 1 17:28:21 2000 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Wed, 1 Nov 2000 16:28:21 -0000 Subject: http security using mod_security Message-ID: <402DD461F109D411977E0008C791C31202A79714@imp02mbx.one2one.co.uk> Hi Ken, The record definitions for httpd_group and httpd_user are in $ROOTDIR/lib/inets-/src/mod_auth.hrl Create these tables in mnesia and populate them with your user and group data. I guess you know what httpd_groups and httpd_users mean cos you already are using the config file to specify these. I presume you are looking at enabling SSL. cheers, Chandru -----Original Message----- From: Kenneth Browne (EEI) [mailto:Kenneth.Browne@REDACTED] Sent: 1 November 2000 16:04 To: 'erlang-questions@REDACTED' Subject: http security using mod_security Hi, I'm trying to set up a web server with ALL the security features that inets has to offer. I have an existing server to work from. In the config file for this server the AuthDBType is set to plain. I want to use the security features of mod_security. All I know so far is that I have to change AuthDBType plain to AuthDBType mnesia. How do I set up the rest??? I think I have to create httpd_users, and httpd_groups, but I don't know where to start ??!. -Ken. NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From vladdu@REDACTED Thu Nov 2 08:33:15 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Thu, 2 Nov 2000 08:33:15 +0100 Subject: Erlang external format References: Message-ID: > Do you mean "otp_src_R7B-0/erts/emulator/internal_doc/erl_ext_dist.txt", > i.e. the format used by the distribution protocol? Yep... and I'm feeling terribly ashamed that I overlooked it... Now I even remember I had read it for a while ago... thanks Vlad From Chandrashekhar.Mullaparthi@REDACTED Thu Nov 2 12:10:23 2000 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Thu, 2 Nov 2000 11:10:23 -0000 Subject: Create table in a transaction Message-ID: <402DD461F109D411977E0008C791C31202A79717@imp02mbx.one2one.co.uk> I can't create a table within a transaction. Why is that?? A comment in mnesia_schema.erl says that a "very special transaction is used when we want to manipulate the schema". Basically what I want to do is: * Do some checks * Update table_1 * create table_2 * Make entries in table_2 in one single transaction. I'm failing at step 3. tia, Chandru NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From dgud@REDACTED Thu Nov 2 13:23:40 2000 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 2 Nov 2000 13:23:40 +0100 (MET) Subject: Create table in a transaction In-Reply-To: <402DD461F109D411977E0008C791C31202A79717@imp02mbx.one2one.co.uk> References: <402DD461F109D411977E0008C791C31202A79717@imp02mbx.one2one.co.uk> Message-ID: <14849.23756.906303.184933@gargle.gargle.HOWL> Sorry, but you can't do schema_transactions inside a normal transaction. schema_transaction's include create_table move_table_copy add_table_copy change_table_copy del_table transform_table .. I got some requests on this but it is a lot of work do it rigth with current implementation.. /Dan Chandrashekhar Mullaparthi writes: > > I can't create a table within a transaction. Why is that?? A comment in > mnesia_schema.erl says that a "very special transaction is used when we want > to manipulate the schema". Basically what I want to do is: > > * Do some checks > * Update table_1 > * create table_2 > * Make entries in table_2 > > in one single transaction. I'm failing at step 3. > > tia, > Chandru > From clinton@REDACTED Thu Nov 2 13:49:28 2000 From: clinton@REDACTED (Clinton Byrne) Date: Thu, 2 Nov 2000 12:49:28 +0000 Subject: make problems Message-ID: <20001102124928.A23210@checkaprice.demon.co.uk> Hi there I am trying to install new erlang otp_src_R7b-0 on a solaris machine 5.7 When i run ./configure, at the end i get an error about it not being able to create the directory /usr/local/erlang/otp_src_R7B-0/lib/gs/c_src/lib/tcl7.6/unix. It then goes on about "i assume that there is standalone support" The Makefile is created but when i run make i get an rc: Command not found error. What is this rc command I apologise if my questions seem futile but i am new to the solaris system Thany thnks for your help Cheers Clinton From kent@REDACTED Thu Nov 2 14:53:41 2000 From: kent@REDACTED (Kent Boortz) Date: 02 Nov 2000 14:53:41 +0100 Subject: make problems In-Reply-To: Clinton Byrne's message of "Thu, 2 Nov 2000 12:49:28 +0000" References: <20001102124928.A23210@checkaprice.demon.co.uk> Message-ID: > When i run ./configure, at the end i get an error about it not being > able to create the directory > /usr/local/erlang/otp_src_R7B-0/lib/gs/c_src/lib/tcl7.6/unix. It > then goes on about "i assume that there is standalone support" This I haven't seen before and can't think of a reason. Maybe I can figure it out if you add add "set -x" to otp_src_R7B-0/lib/gs/c_src/lib/tk4.2/unix/configure and send me the output. > The Makefile is created but when i run make i get an rc: Command not found > error. What is this rc command I think this is becuase of a bug in the configure script. The symbol AR was never set when 'ar' was nog found. Make sure you have a 'ar' program in your path. Try it and get back if you still have problems. kent From per@REDACTED Thu Nov 2 15:25:48 2000 From: per@REDACTED (Per Hedeland) Date: Thu, 2 Nov 2000 15:25:48 +0100 (CET) Subject: make problems In-Reply-To: References: Message-ID: <200011021425.eA2EPmw14581@tordmule.bluetail.com> Kent Boortz wrote: > >> When i run ./configure, at the end i get an error about it not being >> able to create the directory >> /usr/local/erlang/otp_src_R7B-0/lib/gs/c_src/lib/tcl7.6/unix. It >> then goes on about "i assume that there is standalone support" > >This I haven't seen before and can't think of a reason. I think you always get this - it's just a leftover from the original tcl/tk build system, and can be safely ignored - this is the exact text (from running configure on FreeBSD 4.1): == Warning: Your libtcl76.a is not yet created in the directory /usr/local/src/otp_src_R7B-0/lib/gs/c_src/lib/tcl7.6/unix, so I cannot determine this. For now I just assume there is standalone support. If you get an error later during the build of wish.standalone, then first compile Tcl7.6 with standalone support. >> The Makefile is created but when i run make i get an rc: Command not found >> error. What is this rc command > >I think this is becuase of a bug in the configure script. The symbol >AR was never set when 'ar' was nog found. Make sure you have a 'ar' >program in your path. Try it and get back if you still have problems. Yes, you need /usr/ccs/bin in your $PATH to build most any source package on Solaris. The bug should be fixed though, it has come up before - perhaps something like the below (totally untested!:-). --Per Hedeland per@REDACTED --- erts/autoconf/configure.in.ORIG Wed Sep 13 14:14:20 2000 +++ erts/autoconf/configure.in Thu Nov 2 15:23:50 2000 @@ -139,7 +139,10 @@ fi AC_PROG_LN_S -AC_CHECK_PROG(AR, ar, ar) +AC_CHECK_PROG(AR, ar, ar, notfound) +if test "$AR" = "notfound"; then + AC_MSG_ERROR([No 'ar' command found in PATH]) +fi dnl dnl We can live with Solaris /usr/ucb/install From Sean.Hinde@REDACTED Thu Nov 2 17:29:23 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 2 Nov 2000 16:29:23 -0000 Subject: Trace on Variable assignment Message-ID: <402DD461F109D411977E0008C791C312565286@imp02mbx.one2one.co.uk> Hi all, One of the things I really like in the Ericsson AXE-10 environment is the ability to trace on changes to a variable. I've often found myself wishing for this in the Erlang trace mechanism. 1) Has anyone found a nice way of achieving this (apart from the obvious io:format)? 2) Are there any plans to introduce such a thing? Rgds, Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From Gerald.Biederbeck@REDACTED Thu Nov 2 17:37:55 2000 From: Gerald.Biederbeck@REDACTED (Gerald Biederbeck) Date: Thu, 02 Nov 2000 17:37:55 +0100 Subject: gen_server:handle_call & -ifdef Message-ID: <3A019863.9FD0828D@eede.ericsson.se> Hi, I wrote a gen_server and tried to compile it: the source code is something like this: > -ifdef(erlang_debug). > > handle_call(aaa, From, State) -> > Reply = aaa, > {reply, Reply, State}; > > -endif. > > handle_call(Request, From, State) -> > Reply = ok, > {reply, Reply, State}. The error I got was: > ./ifdef.erl:91: unterminated '-ifdef' I assume that it must have something to do with "not ending with a dot" before '-endif.', because the following works: > -ifdef(erlang_debug). > > handle_call(aaa, From, State) -> > Reply = aaa, > {reply, Reply, State}; > > handle_call(Request, From, State) -> > Reply = ok, > {reply, Reply, State}. > > -else. > > handle_call(Request, From, State) -> > Reply = ok, > {reply, Reply, State}. > > -endif. Is there any documentation for this '-ifdef().'??? Is the second way as I am supposed to do it? Any help and comments are welcome! Regards /Gerry From klacke@REDACTED Thu Nov 2 17:46:40 2000 From: klacke@REDACTED (Klacke) Date: Thu, 2 Nov 2000 17:46:40 +0100 Subject: Trace on Variable assignment In-Reply-To: <402DD461F109D411977E0008C791C312565286@imp02mbx.one2one.co.uk>; from Sean.Hinde@one2one.co.uk on Thu, Nov 02, 2000 at 04:29:23PM -0000 References: <402DD461F109D411977E0008C791C312565286@imp02mbx.one2one.co.uk> Message-ID: <20001102174640.A28422@bluetail.com> On Thu, Nov 02, 2000 at 04:29:23PM -0000, Sean Hinde wrote: > Hi all, > > One of the things I really like in the Ericsson AXE-10 environment is the > ability to trace on changes to a variable. I've often found myself wishing > for this in the Erlang trace mechanism. Not much point in that ehh .... since we can't change the value of a variable ??? /klacke -- Claes Wikstrom Bluetail AB http://www.bluetail.com From Sean.Hinde@REDACTED Thu Nov 2 18:12:47 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 2 Nov 2000 17:12:47 -0000 Subject: Trace on Variable assignment Message-ID: <402DD461F109D411977E0008C791C312565287@imp02mbx.one2one.co.uk> Klacke, > > One of the things I really like in the Ericsson AXE-10 > environment is the > > ability to trace on changes to a variable. I've often found > myself wishing > > for this in the Erlang trace mechanism. > > > Not much point in that ehh .... since we can't change the value > of a variable ??? Thanks for the tip. My subject was "Trace on variable assignment". In R7B we can see the values of function parameters but not assignment within functions. IMHO this would be nice. Any sensible views? Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From aba3600@REDACTED Thu Nov 2 19:05:00 2000 From: aba3600@REDACTED (Andy with Recycled Electrons) Date: Thu, 2 Nov 2000 12:05:00 -0600 (CST) Subject: Trace on Variable assignment In-Reply-To: <402DD461F109D411977E0008C791C312565287@imp02mbx.one2one.co.uk> Message-ID: > > > One of the things I really like in the Ericsson AXE-10 > > environment is the > > > ability to trace on changes to a variable. I've often found > > myself wishing > > > for this in the Erlang trace mechanism. > > > > Not much point in that ehh .... since we can't change the value > > of a variable ??? > > Thanks for the tip. My subject was "Trace on variable assignment". > > In R7B we can see the values of function parameters but not assignment > within functions. IMHO this would be nice. > > Any sensible views? This may not be sensible, but I am curious... What do we log, other than name and value assigned? - Scope? - Do we insert this information other outbound debugger information, in one windown, or file? Sincerely, Andy Allen Recycled Electrons email: andy@REDACTED From Sean.Hinde@REDACTED Thu Nov 2 19:46:58 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 2 Nov 2000 18:46:58 -0000 Subject: Trace on Variable assignment Message-ID: <402DD461F109D411977E0008C791C31256528B@imp02mbx.one2one.co.uk> Andy, > This may not be sensible, but I am curious... > > What do we log, other than name and value assigned? At the moment you can trace events (function calls and messages particularly) which contain values which may become variable assignments.. You can't actually trace the actual event of a value being assigned to a variable, or trigger tracing for assignment of a specific variable. > - Scope? I guess one would need to provide the mod:func/n or fun within which the variable is assigned in the trace spec and include this in the trace output. > - Do we insert this information other outbound debugger > information, in > one windown, or file? Raw tracing information is sent as messages to either the process which called erlang:trace/3 or to a different process or port defined in the {tracer, Tracer} option in the Flags option. PMAN uses this stuff to provide its GUI traces. The docs are those for erlang:trace/3, and some info on Match specs in the ERTS section User's Guide > > Sincerely, > > Andy Allen > Recycled Electrons > email: andy@REDACTED > > Rgds, Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From Sean.Hinde@REDACTED Thu Nov 2 19:59:20 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 2 Nov 2000 18:59:20 -0000 Subject: Trace on Variable assignment Message-ID: <402DD461F109D411977E0008C791C31256528C@imp02mbx.one2one.co.uk> Let me rephrase my question. Are there any plans to implement selective tracing of variable ASSIGNMENT? e.g erlang:trace_var({Mod, Func}, 'Varname', Matchspec, Flags). Rgds, Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From R.Mascarell@REDACTED Thu Nov 2 22:56:10 2000 From: R.Mascarell@REDACTED (Rosa Mascarell Dauder) Date: Thu, 2 Nov 2000 22:56:10 +0100 Subject: OTP on top of SuSE Message-ID: <13rSLC-1h1J4qC@fwd01.sul.t-online.com> Hello I try to install OTP-R7B on top of Suse 7.0 and it does not work properly. I have checked the same thing with OTP-R6 on top of Suse 7.0 and the result is the same (it does not work). I have been working with my programs OTP-R6 on top of Suse 6.2 and there was not problems. Have any of you faced the same problems? Which is the reason for so rare behaviour of Suse? Cheers From dg@REDACTED Thu Nov 2 23:17:31 2000 From: dg@REDACTED (David Gould) Date: Thu, 2 Nov 2000 14:17:31 -0800 Subject: OTP on top of SuSE In-Reply-To: <13rSLC-1h1J4qC@fwd01.sul.t-online.com>; from R.Mascarell@t-online.de on Thu, Nov 02, 2000 at 10:56:10PM +0100 References: <13rSLC-1h1J4qC@fwd01.sul.t-online.com> Message-ID: <20001102141731.A6465@archimedes.oak.suse.com> On Thu, Nov 02, 2000 at 10:56:10PM +0100, Rosa Mascarell Dauder wrote: > > Hello > > I try to install OTP-R7B on top of Suse 7.0 and it does not work > properly. I have checked the same thing with OTP-R6 on top of Suse 7.0 > and the result is the same (it does not work). > > I have been working with my programs OTP-R6 on top of Suse 6.2 and there > was not problems. > > Have any of you faced the same problems? Which is the reason for so rare > behaviour of Suse? > > Cheers Hi, could you let me have some more information about your problems with OTP on SuSE 7.0? I would be happy to try to help figure out and fix anything that is not working. -dg -- David Gould dg@REDACTED SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380 From swight@REDACTED Thu Nov 2 23:29:30 2000 From: swight@REDACTED (s. n. wight) Date: Thu, 02 Nov 2000 14:29:30 -0800 Subject: OTP on top of SuSE Message-ID: <3A01EACA.34D9D088@verticalnet.com> i:Exit :PrevPg :NextPg ?:Help I've had no problems with either SuSE 6.4 or 7.0 on various Pentium boxes, building from source. I haven't tried the RPMs though. The source installation process is very consistent, in my experience. -steve On Thu, Nov 02, 2000 at 10:56:10PM +0100, Rosa Mascarell Dauder wrote: > > > Hello > > I try to install OTP-R7B on top of Suse 7.0 and it does not work > properly. I have checked the same thing with OTP-R6 on top of Suse 7.0 and the > result is the same (it does not work). > > I have been working with my programs OTP-R6 on top of Suse 6.2 and there > was not problems. > > Have any of you faced the same problems? Which is the reason for so rare > behaviour of Suse? > > Cheers From scott@REDACTED Fri Nov 3 06:15:21 2000 From: scott@REDACTED (Scott Lystig Fritchie) Date: Thu, 02 Nov 2000 23:15:21 -0600 Subject: Trace on Variable assignment In-Reply-To: Message of "Thu, 02 Nov 2000 17:12:47 GMT." <402DD461F109D411977E0008C791C312565287@imp02mbx.one2one.co.uk> Message-ID: <200011030515.XAA77198@snookles.snookles.com> Sean's wish is on our wishlist in the Sendmail EUC '00 paper. I might have called them "conditional breakpoints". Ah, no, I said, "conditional watchpoint". Hrm. "Conditional breakpoint" would've been better, I think. Editing seems to work much like hindsight does.... The alternative right now is to modify the code you're debugging to something like: Want_to_watch = Whatever(), if Want_to_watch = desired_term() -> ok; % Breakpoint here true -> ok end, ... which is annoying. And if the compiler were sufficiently aggressive, you might be surprised by having your breakpoint disappear. -Scott From tobbe@REDACTED Fri Nov 3 07:36:37 2000 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 03 Nov 2000 07:36:37 +0100 Subject: Trace on Variable assignment In-Reply-To: Scott Lystig Fritchie's message of "Thu, 02 Nov 2000 23:15:21 -0600" References: <200011030515.XAA77198@snookles.snookles.com> Message-ID: Ok, here is a possible workaround: It is possible to write conditional breakpoints in the debugger. However, in a complex system it may not be possible to 'stop' the execution at a break point. The solution is to write the conditional break point so that it sends a message somewhere and have it always return false (i.e it won't trigger the debugger). Cheers /Tobbe From etxuwig@REDACTED Fri Nov 3 09:52:44 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 3 Nov 2000 09:52:44 +0100 (MET) Subject: Create table in a transaction In-Reply-To: <14849.23756.906303.184933@gargle.gargle.HOWL> Message-ID: On Thu, 2 Nov 2000, Dan Gudmundsson wrote: > >Sorry, but you can't do schema_transactions inside a normal transaction. > >schema_transaction's include >create_table >move_table_copy >add_table_copy >change_table_copy >del_table >transform_table >.. > >I got some requests on this but it is a lot of work do it rigth >with current implementation.. > >/Dan But wouldn't it be possible to perform normal table updates from within a schema transaction? I haven't followed the complete thread, but it does seem as if schema_transaction calls mnesia:transaction/1, and that mnesia_tm.erl doesn't really care if schema transactions are combined with other operations. My mnesia_schema patch in the rdbms contrib exports mnesia_schema:schema_transaction/1, and has a few hacks to support multiple calls to write_table_property/2 within one schema transaction. You could try calling normal table ops within schema_transaction and see what happens. Note, though, that schema_transaction can't be called from within a transaction. If you want to try this, you'd also have to call create_table a bit differently. Here's an example from some code I've written: initialise_class(Class) -> {Attrs, TableProps, UserProps} = Class:describe(), F = fun() -> create_table( Class, table_properties(Attrs, TableProps)), rdbms:do_add_properties(UserProps, Class) end, mnesia_schema:schema_transaction(F). create_table(Name, Properties) -> Cs = mnesia_schema:list2cs([{name, Name}|Properties]), mnesia_schema:do_create_table(Cs). /Uffe >Chandrashekhar Mullaparthi writes: > > > > I can't create a table within a transaction. Why is that?? A comment in > > mnesia_schema.erl says that a "very special transaction is used when we want > > to manipulate the schema". Basically what I want to do is: > > > > * Do some checks > > * Update table_1 > > * create table_2 > > * Make entries in table_2 > > > > in one single transaction. I'm failing at step 3. > > > > tia, > > Chandru > > > -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From raimo@REDACTED Fri Nov 3 10:26:18 2000 From: raimo@REDACTED (Raimo Niskanen) Date: Fri, 03 Nov 2000 10:26:18 +0100 Subject: gen_server:handle_call & -ifdef References: <3A019863.9FD0828D@eede.ericsson.se> Message-ID: <3A0284BA.7E4924F1@erix.ericsson.se> Hi Gerry, there is some documentation in "Erlang Extensions since 4.4", link from http://erlang.org/doc/r7b/doc/index.html. This, unfortunately, says nothing about the behagiour You encountered. There is also the Erlang specification, that slowly is getting out of date but still is the best there is. It is found at http://erlang.org/download/erl_spec47.ps.gz, gzipped Postscript, sorry. There the behaviour is stated, perhaps not too clearly, in sections 7.1 and 7.4. In short, the preprocessor reads a sequence of TokenSequences. A TokenSequence is terminated by a full stop ("."), so an "-ifdef()." directive is a TokenSequence, and an "-endif." too, and what comes before, in between and after must also be terminated with a full stop. Too bad. One standard trick is to conditionally define a debug printout macro like this: -ifdef(erlang_debug). -define(dbg_out(Term), io:format("~p~n", [Term])). -else. -define(dbg_out(Term), ok). -endif. , but that won't help You, but a similar trick might: -ifdef(erlang_debug). -define(handle_call_aaa, handle_call(aaa, From, State) -> Reply = aaa, {reply, Reply, State};). -else. -define(handle_call_aaa, ). -endif. . . ?handle_call_aaa handle_call(Request, From, State) -> Reply = ok, {reply, Reply, State}. , or this more generic macro hackery: -ifdef(erlang_debug). -define(dbg(X), X). -else. -define(dbg(X), ). -endif. . . ?dbg(handle_call(aaa, From, State) -> begin Reply = aaa, {reply, Reply, State} end;) handle_call(Request, From, State) -> Reply = ok, {reply, Reply, State}. this is on thin ice, however. E.g You need the begin .. end construct to keep together the argument to the dbg macro, and You cannot have more that one guard since then You need commas, which split the argument to the dbg macro into two. That can be solved with a dbg macro with more arguments, for the guards, and now it gets really ugly. Good luck, anyway. / Raimo Niskanen, Erlang/OTP Gerald Biederbeck wrote: > > Hi, > > I wrote a gen_server and tried to compile it: > the source code is something like this: > > > -ifdef(erlang_debug). > > > > handle_call(aaa, From, State) -> > > Reply = aaa, > > {reply, Reply, State}; > > > > -endif. > > > > handle_call(Request, From, State) -> > > Reply = ok, > > {reply, Reply, State}. > > The error I got was: > > > ./ifdef.erl:91: unterminated '-ifdef' > > I assume that it must have something to do > with "not ending with a dot" before '-endif.', > because the following works: > > > -ifdef(erlang_debug). > > > > handle_call(aaa, From, State) -> > > Reply = aaa, > > {reply, Reply, State}; > > > > handle_call(Request, From, State) -> > > Reply = ok, > > {reply, Reply, State}. > > > > -else. > > > > handle_call(Request, From, State) -> > > Reply = ok, > > {reply, Reply, State}. > > > > -endif. > > Is there any documentation for this '-ifdef().'??? > Is the second way as I am supposed to do it? > > Any help and comments are welcome! > > Regards > /Gerry From Chandrashekhar.Mullaparthi@REDACTED Fri Nov 3 11:05:30 2000 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Fri, 3 Nov 2000 10:05:30 -0000 Subject: Create table in a transaction Message-ID: <402DD461F109D411977E0008C791C31202A79725@imp02mbx.one2one.co.uk> I tried running normal table ops(mnesia:write/1) within the schema transaction. But the transaction aborts with {aborted, {no_exists, TableName}} - which I think is understandable. I haven't read thru the code - but I think schema changes are probably not committed until the schema transaction is completed - which is why mnesia:write complains that it cant find the table. Though I don't understand why schema transactions are different from normal transactions. Maybe I'll go thru the code.....once I get ccviewer installed and running! Chandru -----Original Message----- From: Ulf Wiger [mailto:etxuwig@REDACTED] Sent: 3 November 2000 08:53 To: Dan Gudmundsson Cc: Chandrashekhar Mullaparthi; 'Erlang mailing list' Subject: Re: Create table in a transaction On Thu, 2 Nov 2000, Dan Gudmundsson wrote: > >Sorry, but you can't do schema_transactions inside a normal transaction. > >schema_transaction's include >create_table >move_table_copy >add_table_copy >change_table_copy >del_table >transform_table >.. > >I got some requests on this but it is a lot of work do it rigth >with current implementation.. > >/Dan But wouldn't it be possible to perform normal table updates from within a schema transaction? I haven't followed the complete thread, but it does seem as if schema_transaction calls mnesia:transaction/1, and that mnesia_tm.erl doesn't really care if schema transactions are combined with other operations. My mnesia_schema patch in the rdbms contrib exports mnesia_schema:schema_transaction/1, and has a few hacks to support multiple calls to write_table_property/2 within one schema transaction. You could try calling normal table ops within schema_transaction and see what happens. Note, though, that schema_transaction can't be called from within a transaction. If you want to try this, you'd also have to call create_table a bit differently. Here's an example from some code I've written: initialise_class(Class) -> {Attrs, TableProps, UserProps} = Class:describe(), F = fun() -> create_table( Class, table_properties(Attrs, TableProps)), rdbms:do_add_properties(UserProps, Class) end, mnesia_schema:schema_transaction(F). create_table(Name, Properties) -> Cs = mnesia_schema:list2cs([{name, Name}|Properties]), mnesia_schema:do_create_table(Cs). /Uffe >Chandrashekhar Mullaparthi writes: > > > > I can't create a table within a transaction. Why is that?? A comment in > > mnesia_schema.erl says that a "very special transaction is used when we want > > to manipulate the schema". Basically what I want to do is: > > > > * Do some checks > > * Update table_1 > > * create table_2 > > * Make entries in table_2 > > > > in one single transaction. I'm failing at step 3. > > > > tia, > > Chandru > > > -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From etxuwig@REDACTED Fri Nov 3 11:44:53 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 3 Nov 2000 11:44:53 +0100 (MET) Subject: Create table in a transaction In-Reply-To: <402DD461F109D411977E0008C791C31202A79725@imp02mbx.one2one.co.uk> Message-ID: On Fri, 3 Nov 2000, Chandrashekhar Mullaparthi wrote: >I tried running normal table ops(mnesia:write/1) within the schema >transaction. But the transaction aborts with {aborted, {no_exists, >TableName}} - which I think is understandable. I haven't read thru the code >- but I think schema changes are probably not committed until the schema >transaction is completed - which is why mnesia:write complains that it cant >find the table. Though I don't understand why schema transactions are >different from normal transactions. Oh, you're trying to write to the very table that you're creating? No, that won't work. As I understand it, table writes go into a temporary ets store before prepare_commit, but create_table seems to take effect in prepare_commit, and thus doesn't exist before that. To handle that, mnesia_tm would have to peek at the requested ops and figure out that the table you're writing to is about to be created. I think Dan is right, this is complicated. Schema transactions are different from table transactions in a few respects, but the main difference is that you have to be much more careful when messing with the schema. This calls for a heavier transaction protocol, the ability to follow through with the transaction even if the requesting client dies, etc. Personally, I don't think I quite fathom the complexity, so perhaps Dan, H?kan or Klacke could give a better explanation. >Maybe I'll go thru the code.....once I >get ccviewer installed and running! > >Chandru (: /Uffe > >-----Original Message----- >From: Ulf Wiger [mailto:etxuwig@REDACTED] >Sent: 3 November 2000 08:53 >To: Dan Gudmundsson >Cc: Chandrashekhar Mullaparthi; 'Erlang mailing list' >Subject: Re: Create table in a transaction > > >On Thu, 2 Nov 2000, Dan Gudmundsson wrote: > >> >>Sorry, but you can't do schema_transactions inside a normal transaction. >> >>schema_transaction's include >>create_table >>move_table_copy >>add_table_copy >>change_table_copy >>del_table >>transform_table >>.. >> >>I got some requests on this but it is a lot of work do it rigth >>with current implementation.. >> >>/Dan > >But wouldn't it be possible to perform normal table updates from >within a schema transaction? > >I haven't followed the complete thread, but it does seem as if >schema_transaction calls mnesia:transaction/1, and that mnesia_tm.erl >doesn't really care if schema transactions are combined with other >operations. > >My mnesia_schema patch in the rdbms contrib exports >mnesia_schema:schema_transaction/1, and has a few hacks to support >multiple calls to write_table_property/2 within one schema >transaction. You could try calling normal table ops within >schema_transaction and see what happens. > >Note, though, that schema_transaction can't be called from within a >transaction. If you want to try this, you'd also have to call >create_table a bit differently. Here's an example from some code I've >written: > >initialise_class(Class) -> > {Attrs, TableProps, UserProps} = Class:describe(), > F = fun() -> > create_table( > Class, table_properties(Attrs, TableProps)), > rdbms:do_add_properties(UserProps, Class) > end, > mnesia_schema:schema_transaction(F). > > >create_table(Name, Properties) -> > Cs = mnesia_schema:list2cs([{name, Name}|Properties]), > mnesia_schema:do_create_table(Cs). > > > > >/Uffe > > >>Chandrashekhar Mullaparthi writes: >> > >> > I can't create a table within a transaction. Why is that?? A comment in >> > mnesia_schema.erl says that a "very special transaction is used when we >want >> > to manipulate the schema". Basically what I want to do is: >> > >> > * Do some checks >> > * Update table_1 >> > * create table_2 >> > * Make entries in table_2 >> > >> > in one single transaction. I'm failing at step 3. >> > >> > tia, >> > Chandru >> > >> > > -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From Sean.Hinde@REDACTED Fri Nov 3 12:21:26 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Fri, 3 Nov 2000 11:21:26 -0000 Subject: Trace on Variable assignment Message-ID: <402DD461F109D411977E0008C791C31256528F@imp02mbx.one2one.co.uk> Thanks for the suggestions, they are neater than io:format everywhere for debugging :) I had more in mind though being able to set up traces (or conditional watchpoints if you like) in a running system without needing to change the code. I don't think it should introduce too much overhead - 1 bit set per variable which is checked on each assignment to that variable.. The match syntax would seem to offer a plenty rich enough selection method for setting conditions after this initial trigger. Sean > -----Original Message----- > From: Torbjorn Tornkvist [mailto:tobbe@REDACTED] > Sent: 3 November 2000 06:37 > To: Scott Lystig Fritchie > Cc: erlang-questions@REDACTED > Subject: Re: Trace on Variable assignment > > > > Ok, here is a possible workaround: > > It is possible to write conditional breakpoints in the debugger. > However, in a complex system it may not be possible to 'stop' > the execution at a break point. The solution is to write the > conditional break point so that it sends a message somewhere > and have it always return false (i.e it won't trigger the > debugger). > > Cheers /Tobbe > NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From etxuwig@REDACTED Fri Nov 3 12:45:16 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 3 Nov 2000 12:45:16 +0100 (MET) Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: <20001102174640.A28422@bluetail.com> Message-ID: On Thu, 2 Nov 2000, Klacke wrote: >On Thu, Nov 02, 2000 at 04:29:23PM -0000, Sean Hinde wrote: >> Hi all, >> >> One of the things I really like in the Ericsson AXE-10 environment is the >> ability to trace on changes to a variable. I've often found myself wishing >> for this in the Erlang trace mechanism. > > >Not much point in that ehh .... since we can't change the value >of a variable ??? Of course, many variables are conceptually the same, except we create a new instance: X = foo(...), X1 = bar(X), Some people would prefer: X = foo(...), NewX = bar(X), And the runtime system can't know that X1 is a modified version of X. X = foo(...), % [0] is implicit X[1] = bar(X), ... or perhaps X = foo(...), % \0 is implicit X\1 = bar(X), ... would allow trace on "changes" to a variable, and also introduce a standard way of describing something that occurs frequently in most Erlang code I've seen. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From etxuwig@REDACTED Fri Nov 3 13:00:35 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 3 Nov 2000 13:00:35 +0100 (MET) Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: Message-ID: On Fri, 3 Nov 2000, Ulf Wiger wrote: >X = foo(...), % [0] is implicit >X[1] = bar(X), >... > >or perhaps > >X = foo(...), % \0 is implicit >X\1 = bar(X), >... > > >would allow trace on "changes" to a variable, and also introduce a >standard way of describing something that occurs frequently in >most Erlang code I've seen. > >/Uffe Since I posted this without thinking much, I paused and thought about it afterwards. One common source of bugs (and very hard to find) is when "changing" a variable and forgetting to pass the latest instance. An example from application_controller.erl: handle_call({unload_application, AppName}, _From, S) -> case keysearch(AppName, 1, S#state.running) of {value, _} -> {reply, {error, {running, AppName}}, S}; false -> case get_loaded(AppName) of {true, _} -> NewS = unload(AppName, S), cntrl(AppName, S, {ac_application_unloaded, AppName}), {reply, ok, NewS}; Now it possibly won't matter in this case that cntrl/3 is called with S instead of NewS (cntrl will look at S#state.control, which isn't changed by unload/2), but I'd say it'd be a lot better to pass NewS anyway to avoid confusion. If the function could be rewritten as: handle_call({unload_application, AppName}, _From, S) -> case keysearch(AppName, 1, S#state.running) of {value, _} -> {reply, {error, {running, AppName}}, S}; false -> case get_loaded(AppName) of {true, _} -> S[1] = unload(AppName, S), cntrl(AppName, S, {ac_application_unloaded, AppName}), {reply, ok, S[1]}; a compiler could easily produce a warning stating that we're passing an old instance of S, since this is almost always a bug, and can easily be avoided in the cases when it it's intentional. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From tobbe@REDACTED Fri Nov 3 13:29:28 2000 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 03 Nov 2000 13:29:28 +0100 Subject: Trace on Variable assignment In-Reply-To: Sean Hinde's message of "Fri, 3 Nov 2000 11:21:26 -0000" References: <402DD461F109D411977E0008C791C31256528F@imp02mbx.one2one.co.uk> Message-ID: > I had more in mind though being able to set up traces (or conditional > watchpoints if you like) in a running system without needing to change the > code. What about a guard: watch/1 which could be combined with the trace bif ? Example: foo(X,Y) when watch(Y) -> case bar(X) of {Z,W} when watch(W) -> .... end. When running trace on the process executing foo we could then get info about Y and W . Just a thought... /Tobbe From Sean.Hinde@REDACTED Fri Nov 3 14:10:10 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Fri, 3 Nov 2000 13:10:10 -0000 Subject: Trace on Variable assignment Message-ID: <402DD461F109D411977E0008C791C312565293@imp02mbx.one2one.co.uk> > > I had more in mind though being able to set up traces (or > conditional > > watchpoints if you like) in a running system without > needing to change the > > code. > > What about a guard: watch/1 which could be combined with > the trace bif ? > Just a thought... /Tobbe I'm thinking about the situation when the customer/local support guys are asked to run a trace to feed back info about their system to a supplier/developer. You could generate a patch and get them to load it, but even better would be able to send them something to type at the shell to do somethng like: "Every time the transaction ID is divisible by 100, print that value and the values of these other variables". The equivalent AXE-10 ese would be something like: on var a do: print var a, pr var b, print ia, pri time; (my memory is a bit rusty so this probably isn't quite the right syntax) ia would be instruction address i.e. where in the code the variable is set or changed - our equivalent of m:f :-)) AXE10 doesn't have selective tracing on vars, they just limit the size of a trace buffer, so we could do even better. - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From Jens.Peder.Terjesen@REDACTED Fri Nov 3 16:36:57 2000 From: Jens.Peder.Terjesen@REDACTED (Jens Peder Terjesen (ETO)) Date: Fri, 3 Nov 2000 16:36:57 +0100 Subject: Passing argument from the command line Message-ID: Hi. This seems to work (dialog with Unix shell): {etojpt_impro_baseline}: adp {687} $ erl -boot start_clean -sname testnode < io:format("test~n"). > EOF Eshell V4.9.1.1 (abort with ^G) (testnode@REDACTED)1> test ok (testnode@REDACTED)2> ** Terminating erlang ** {etojpt_impro_baseline}: adp {688} $ Or perhaps easier in a shell script (attached). Invoke as: cmdlinetest Jens -----Original Message----- From: Mickael Remond [mailto:mickael.remond@REDACTED] Sent: 12. oktober 2000 14:23 To: erlang-questions@REDACTED Subject: Passing argument from the command line It seems that the argument of the Erlang command line are always list of atoms... Is it right or am I missing something ? In fact, whith this fact you need to design your functions specifically if you want them to be called directly from the command line and from the Erlang shell. For example: I was building a makefile to transform .ehtml into .html files. The command I am using is: erl -s ehtml file index -s init stop And it does not work from the command line. I have changed the following code in ehtml.erl: file(F) when list(F) -> file(F ++ ".ehtml", F ++ ".html"). into: % Called from the command line file([F|Empty]) when atom(F), Empty==[] -> file(atom_to_list(F)); % Called from the Erlang Shell file(F) when list(F) -> file(F ++ ".ehtml", F ++ ".html"). And the command line is working. Am I missing something or must I make sure that all function that need to be command line compliant should accept list of atoms ? Thank you for help. -- Micka?l R?mond -------------- next part -------------- A non-text attachment was scrubbed... Name: cmdlinetest Type: application/octet-stream Size: 79 bytes Desc: not available URL: From alexis@REDACTED Fri Nov 3 18:24:54 2000 From: alexis@REDACTED (=?iso-8859-1?Q?Alexis_L=EA-Qu=F4c?=) Date: Fri, 3 Nov 2000 12:24:54 -0500 Subject: Erlang running on different OSs. Message-ID: Greetings, I'm trying to gather information about the pros and cons of running Erlang on Solaris vs. Linux vs. FreeBSD. What is people's experience with these platforms, both in development and production? Solaris for instance is infintely more expensive than linux or bsd; is there an incentive to spending the money on Solaris? I'm not specifically looking for hard figures; day-to-day experience is informative as well. By the way, I'm not trying to start a OS Holy War... -- Alexis L?-Qu?c -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sean.Hinde@REDACTED Fri Nov 3 20:02:04 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Fri, 3 Nov 2000 19:02:04 -0000 Subject: Trace on Variable assignment Message-ID: <402DD461F109D411977E0008C791C3125652A2@imp02mbx.one2one.co.uk> > > What about a guard: watch/1 which could be combined with > > the trace bif ? > OK, I thought a bit more about what I am asking for, looked at the beam assembly from a tiny program to see what is held about variable names (nothing), and reflected on how this might be implemented. I guess what I am asking for is pretty compiler/emulator unfriendly, which is why we have source level debuggers after all :) Some possibilities: 1) Tobbes watch/1 guard. This would make it easier to add trace possibilities in production code for key variables (gen_server States for example). A compiler option could force this to be included for every variable assignment in a module, much like the old trace option for local function calls. It also doesn't allow tracing of A in: {A, B} = case lic(X,Y) of X1 when X1 < 0 -> {1, X1}; X2 -> {2, X2} end. 2) Something which could be added as an option to the existing function call/signal trace mechanism to also send contents of selected current variables. This would partly solve the triggering problem, though not which data goes with which variable name, and no good for return values or anywhere else where there is no following function call. 3) A compiler option which includes the variable name data in the relevant places and invokes different beam ops which check for tracing every time a new value is stored in whatever place the runtime stores these things. - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From bjowi@REDACTED Sat Nov 4 00:26:26 2000 From: bjowi@REDACTED (=?ISO-8859-1?Q?Bj=F6rn Wingman?=) Date: Sat, 4 Nov 2000 00:26:26 +0100 (MET) Subject: Sockets on IRIX Message-ID: <200011032326.AAA23327@sture.lysator.liu.se> Hello, I'm having problems opening sockets with erlang R7B on IRIX 6.5. On solaris everything works fine, but on irix gen_tcp:connect always dies with {error,timeout}. This is how I call it: Conn = gen_tcp:connect(Host, Port, [list, {packet, raw},{reuseaddr,false},{active,false}]), /Bj?rn Wingman From enano@REDACTED Sat Nov 4 15:01:12 2000 From: enano@REDACTED (Miguel Barreiro Paz) Date: Sat, 4 Nov 2000 15:01:12 +0100 (CET) Subject: Erlang running on different OSs. In-Reply-To: Message-ID: Hi, > I'm trying to gather information about the pros and cons of running > Erlang on Solaris vs. Linux vs. FreeBSD. What is people's experience > with these platforms, both in development and production? Solaris for As was previously reported in this list, Solaris UFS is notoriusly slow, and single-threaded beam machines will suffer when doing disk I/O; Veritas VxFS should be much faster, but I have never tried it. Linux ext2 fs (and reiserfs, if you feel a bit brave) are far faster. Linux filesystems are evolving rapidly, with reiserfs, SGI XFS and IBM JFS struggling to get into the official tree ASAP. UFS is essentially the same as a decade ago. Now, if for some reason you need 64 CPUs in a single box, hotplug CPUs, or several *really* large fiberchannel diskarrays, yes, I would consider a highend Sun with Solaris. At least for this year. Regards, Miguel From vances@REDACTED Sun Nov 5 01:46:56 2000 From: vances@REDACTED (Vance Shipley) Date: Sat, 4 Nov 2000 19:46:56 -0500 Subject: FW: Erlang running on different OSs. Message-ID: Alexis L?-Qu?c writes: } } I'm trying to gather information about the pros and cons of running } Erlang on Solaris vs. Linux vs. FreeBSD. What is people's experience } with these platforms, both in development and production? Solaris for } instance is infintely more expensive than linux or bsd; is there an } incentive to spending the money on Solaris? I'm not specifically looking } for hard figures; day-to-day experience is informative as well. By the } way, I'm not trying to start a OS Holy War... Solaris is infinitely more expensive than Linux? I suppose that is literally true as a Linux distribution can be free if you ftp it from somewhere. Solaris has a cost in that they only distribute on CD and charge $75 for the media kit. A Solaris 8 binary license for any number of machines with up to 8 CPUs is free for home or office use. Solaris does not imply using a Sparc architecture either. http://www.sun.com/software/solaris/binaries/ I have used Solaris x86 as the OS for a number of my commercial products. I have also used SCO Openserver, SCO Unixware, FreeBSD and most recently Redhat Linux. I found Solaris the most difficult to deal with as far as administration is concerned. It was dream to port software to though. Unixware was a bit better admin wise but horribly worse to port to. FreeBSD is a very nice OS but unfortunately ignored and as such it suffers from a lack of vendor support for drivers of the more esoteric sort which we tend to need for our telephony servers. Linux is pretty good to port to, and at least the Redhat distribution is easy to administer. Today I use Solaris & Redhat for all my products. Solaris is used when I need drivers that aren't available for Linux or when it's a large and expensive machine which justifies it. Linux is always my preference for embedded system and other smaller systems. -Vance Motivity Telecom Inc. From bauerd@REDACTED Sun Nov 5 02:56:22 2000 From: bauerd@REDACTED (David W. Bauer Jr.) Date: Sat, 4 Nov 2000 20:56:22 -0500 (EST) Subject: Distributed Erlang In-Reply-To: Message-ID: This may seem a simple question, but I am a bit confused on how exactly to run erlang in a distributed environment. Specifically what I would like to do is run an erlang node on a server, and then generate requests to it from a java created OtpNode on a remote client. I understand that epmd needs to be running.. the confusing part to me is the registration of the nodes to a single instance of epmd. For example, I intend to have many servers (order 10^4) and many more java nodes (order 10^6) with a load balanced middle man server containing the locations of the backend erlang servers. As each server comes online I would like for them to be known to each other and the world through the middle man node index server. Is this even possible? I don't understand how the routing actually works. David ~~~ ~~ ~~~~ _o URL: http://www.david-bauer.com ~~~ ~~~~ ~~ _'|<,_ ~~~~ ~~~ ~~~~ (*)/ (*) From bauerd@REDACTED Sun Nov 5 04:43:51 2000 From: bauerd@REDACTED (David W. Bauer Jr.) Date: Sat, 4 Nov 2000 22:43:51 -0500 (EST) Subject: inets 2.5.1 In-Reply-To: Message-ID: I keep getting this error when starting inets as stated on the web page: feynman ~/inets: erl -config conf/inets.config Erlang (BEAM) emulator version 5.0.1 [source] Eshell V5.0.1 (abort with ^G) 1> application:start(inets). {error,{shutdown,{inets_sup,start,[normal,[]]}}} =INFO REPORT==== 4-Nov-2000::22:42:34 === application: inets exited: {shutdown,{inets_sup,start,[normal,[]]}} type: temporary 2> I simply made a symlink from the examples/server_root dir to /var/tmp/, which should make all the paths ok. Then I copied the inets.config file from the website. I also tried creating my own files and directories from scratch and receive the same error. Thanks, David ~~~ ~~ ~~~~ _o URL: http://www.david-bauer.com ~~~ ~~~~ ~~ _'|<,_ ~~~~ ~~~ ~~~~ (*)/ (*) From tobbe@REDACTED Sun Nov 5 18:22:07 2000 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 05 Nov 2000 18:22:07 +0100 Subject: inets 2.5.1 In-Reply-To: "David W. Bauer Jr."'s message of "Sat, 4 Nov 2000 22:43:51 -0500 (EST)" References: Message-ID: > feynman ~/inets: erl -config conf/inets.config Try and see what happends if you start it like: erl -boot start_sasl -config conf/inets.config Cheers /Tobbe From bob@REDACTED Mon Nov 6 01:21:24 2000 From: bob@REDACTED (Bob) Date: Sun, 5 Nov 2000 14:21:24 -1000 Subject: Bluetail Ticket Tracker Message-ID: <200011060021.eA60LjE50663@hades.cslab.ericsson.net> Aloha Tobbe, I just got btt running on windows for use in a new project. Nice work...thank you very much. bob From vladdu@REDACTED Mon Nov 6 10:51:49 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 6 Nov 2000 10:51:49 +0100 Subject: external format Message-ID: Good morning to you all! I have a question about the external format... Something seems to be weird about it... Comparing the documentation and the code in for example erl_interface/encode_long.c --------------------------------------------------------------------------- 2.15. SMALL_BIG_EXT (110) 1 1 1 n +-----+-------+------+------------------+ | 110 | n | Sign | d(0) ... d(n-1) | +-----+-------+------+------------------+ 2.16. LARGE_BIG_EXT (111) 1 4 1 n +-----+-------+------+------------------+ | 111 | n | Sign | d(0) ... d(n-1) | +-----+-------+------+------------------+ --------------------------------------------------------------------------- put8(s,ERL_SMALL_BIG_EXT); put8(s,4); /* len = four bytes */ put8(s, p < 0); /* save sign separately */ put32le(s, abs(p)); /* OBS: Little Endian, and p now positive */ --------------------------------------------------------------------------- Why a four-byte length for a SMALL_BIG_EXT? Why isn't LARGE_BIG_EXT used at all? Is there any support for the large integers in C code? I didn't find any... The GNU MP library could be used here, if needed. regards, /Vlad -------------------------------------------------------------- For God's sake, Smithers! It's not rocket science, it's just brain surgery! -------------------------------------------------------------- From kent@REDACTED Mon Nov 6 12:36:37 2000 From: kent@REDACTED (Kent Boortz) Date: 06 Nov 2000 12:36:37 +0100 Subject: external format In-Reply-To: "Vlad Dumitrescu"'s message of "Mon, 6 Nov 2000 10:51:49 +0100" References: Message-ID: > Why a four-byte length for a SMALL_BIG_EXT? It is one byte telling us we have a four byte integer encoded. > Why isn't LARGE_BIG_EXT used at all? > > Is there any support for the large integers in C code? I didn't find any... > The GNU MP library could be used here, if needed. We have no inteface to a specific multiple precision library like GMP. A possibility could be to add a '--with-gmp' option to configure and add a function similar to the function below (code not tested). Maybe there should be a ei_encode_longlong() also where we want a 64 bit integer on a 32 bit machine but don't want to use a bignum package. Hmm...the code in ei_encode_long() isn't even correct for a 64 bit machine :-( kent #ifdef WITH_GMP #include #ifdef __GNU_MP__ >= 3 int ei_encode_bignum(char *buf, int *index, mpz_t *n) { char *s = buf + *index; char *s0 = s; size_t limbs = mpz_size(n); size_t size_in_bytes = limbs * sizeof(mp_limb_t); size_t i; /* Could test for small integers and code into ERL_SMALL_INTEGER_EXT and ERL_INTEGER_EXT but the format does not require that we code into the smallest possible format [XXX but I think it should /kent] */ if (size_in_bytes < 256) { if (!buf) return 3 + size_in_bytes; put8(s,ERL_SMALL_BIG_EXT); put8(s,size_in_bytes); /* length fits into one byte */ put8(s, mpz_sgn(n) < 0); /* save sign separately */ } else { if (!buf) return 6 + size_in_bytes; put8(s,ERL_LARGE_BIG_EXT); put32be(s,4); /* XXX not clear that big endian */ put8(s, mpz_sgn(n) < 0); /* save sign separately */ } /* XXX In future GMP implementations the limb size will not be fixed to 32 or 64 bits */ /* XXX I assume limb numers starts from 1, do they? */ #ifdef sizeof(mp_limb_t) == 4 for (i = 1; i <= limbs; i++) { mp_limb_t limb = mpz_getlimbn(mpz_t n, mp_size_t i); put8(s, limb & 0xff); put8(s, (limb >> 8) & 0xff); put8(s, (limb >> 16) & 0xff); put8(s, (limb >> 24) & 0xff); } #else #ifdef sizeof(mp_limb_t) == 8 for (i = 1; i <= limbs; i++) { mp_limb_t limb = mpz_getlimbn(mpz_t n, mp_size_t i); put8(s, limb & 0xff); put8(s, (limb >> 8) & 0xff); put8(s, (limb >> 16) & 0xff); put8(s, (limb >> 24) & 0xff); put8(s, (limb >> 32) & 0xff); put8(s, (limb >> 40) & 0xff); put8(s, (limb >> 48) & 0xff); put8(s, (limb >> 56) & 0xff); } #else This is an error....... #endif /* limb size 8 */ #endif /* limb size 4 */ *index += s-s0; return 0; } #endif /* __GNU_MP__ >= 3 */ #endif /* WITH_GMP */ From Sean.Hinde@REDACTED Mon Nov 6 13:50:12 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 6 Nov 2000 12:50:12 -0000 Subject: Erlang running on different OSs. Message-ID: <402DD461F109D411977E0008C791C3125652A9@imp02mbx.one2one.co.uk> > As was previously reported in this list, Solaris UFS is > notoriusly > slow, and single-threaded beam machines will suffer when > doing disk I/O; > Veritas VxFS should be much faster, but I have never tried > it. We us VxFS on our Erlang machines and are getting impressive results. It's not cheap though.. Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From raimo@REDACTED Mon Nov 6 14:22:22 2000 From: raimo@REDACTED (Raimo Niskanen) Date: Mon, 06 Nov 2000 14:22:22 +0100 Subject: Sockets on IRIX References: <200011032326.AAA23327@sture.lysator.liu.se> Message-ID: <3A06B08E.5ED019F2@erix.ericsson.se> We have a slight problem with the name lookup. For some reasons (performance, historical, ...) we use an own DNS client written in Erlang, and it seems that this client does not work well on all platforms {error, timeout}. I am of course not certain that this is the problem, it also depends of the contents of the /etc/hosts, /etc/resov.conf, /etc/host.conf, /etc/nsswitch.conf, /etc/irs.conf, etc. files. There is a (undocumented) way to override the emulator's default behaviour, which might be needed in this case: Create a file ".inetrc" in Your home directory, in the current working directory or in the ${OTP_ROOT}/bin directory (I will come back to this later), with the contents: {lookup, ["native"]}. This will force all name lookups to be done through an external port program that uses the native "gethostbyname" and such library calls. Since all name querys are passed through a port program (for thread safety reasons), performance may be lower, but certanly not noticabely. There are some other places to put this ".inetrc" file, ask again if this is necessary, or read the source, /lib/kernel/src/inet_config.erl. The $OTP_ROOT directory can be found by starting Erlang with "erl -emu_args", and copy the first argument after the '-root' switch. / Raimo Niskanen, Erlang/OTP Bj?rn Wingman wrote: > > Hello, > > I'm having problems opening sockets with erlang R7B on IRIX 6.5. On > solaris everything works fine, but on irix gen_tcp:connect always dies > with {error,timeout}. This is how I call it: > > Conn = gen_tcp:connect(Host, Port, > [list, {packet, raw},{reuseaddr,false},{active,false}]), > > /Bj?rn Wingman From Peter.Andersson@REDACTED Mon Nov 6 18:14:15 2000 From: Peter.Andersson@REDACTED (Peter Andersson) Date: Mon, 06 Nov 2000 17:14:15 +0000 Subject: HTTP 3xx response Message-ID: <3A06E6E7.8D8DF98A@eei.ericsson.se> Hi folks, I've been playing around with Joe's contributed WWW tools a bit. Fascinating what you can do with only a few lines of Erlang code using this library! I have a question, though, which I hope is easy to answer for anyone who has programmed web client applications before (which I haven't). When you get an HTTP 3xx (e.g. 302) response which indicates a URI redirection, it states in RFC1945 that you will get a reference to the new URL in the "entity body" of the response. The RFC also explains that you will only get an entity body in the response if you explicitly request for it. What I can't figure out is what the request should look like. As far as I understand it should be a normal HTTP GET with an "entity header" on some relevant format. I've tried a few different variants of such a header without success. Anyone!? Best regards /Peter From doug@REDACTED Mon Nov 6 18:56:29 2000 From: doug@REDACTED (Doug Bagley) Date: 06 Nov 2000 11:56:29 -0600 Subject: HTTP 3xx response In-Reply-To: Peter Andersson's message of "Mon, 06 Nov 2000 17:14:15 +0000" References: <3A06E6E7.8D8DF98A@eei.ericsson.se> Message-ID: Peter Andersson writes: > Hi folks, > > I've been playing around with Joe's contributed WWW tools a bit. Fascinating > what you can do with only a few lines of Erlang code using this library! I have > a question, though, which I hope is easy to answer for anyone who has programmed > web client applications before (which I haven't). > > When you get an HTTP 3xx (e.g. 302) response which indicates a URI redirection, > it states in RFC1945 that you will get a reference to the new URL in the "entity > body" of the response. The RFC also explains that you will only get an entity > body in the response if you explicitly request for it. What I can't figure out > is what the request should look like. As far as I understand it should be a > normal HTTP GET with an "entity header" on some relevant format. I've tried a > few different variants of such a header without success. > > Anyone!? As a practical matter, I believe it doesn't really matter what's in the client request, beyond being HTTP/1.0 or better. Client requests a page: GET / HTTP/1.0 Servers return "redirects" with a response like this: HTTP/1.0 302 Moved Temporarily Date: Mon, 06 Nov 2000 17:52:16 GMT Server: Apache/1.3.12 (TRS-80) mod_perl/1.22 Location: http://some.other.place/you/should/go/to Content-Type: text/html; charset=iso-8859-1 Connection: close (there may be some optional HTML content here) Your client will want to now go to the URL in the Location header Cheers, Doug From daniel.neri@REDACTED Mon Nov 6 19:12:13 2000 From: daniel.neri@REDACTED (Daniel Neri) Date: 06 Nov 2000 19:12:13 +0100 Subject: HTTP 3xx response In-Reply-To: Peter Andersson's message of "Mon, 06 Nov 2000 17:14:15 +0000" References: <3A06E6E7.8D8DF98A@eei.ericsson.se> Message-ID: Peter Andersson writes: > When you get an HTTP 3xx (e.g. 302) response which indicates a URI > redirection, it states in RFC1945 that you will get a reference to > the new URL in the "entity body" of the response. Actually you'll get the new location in the "Location" header of the response. The reference included in the body is typically just a hyperlink, in case the client software cannot handle the redirection automatically. Real world (almost) example: ,---- | $ telnet foo.example.org http | Trying 10.10.10.10... | Connected to foo.example.org. | Escape character is '^]'. | GET / HTTP/1.0 | Host: foo.example.org | | HTTP/1.1 302 Found | Date: Mon, 06 Nov 2000 17:47:49 GMT | Server: Apache/1.3.9 (Unix) PHP/3.0.11 mod_ssl/2.4.9 OpenSSL/0.9.4 | Location: http://www.example.com/bar | Connection: close | Content-Type: text/html | | | | 302 Found | |

Found

| The document has moved here.

|

|
Apache/1.3.9 Server at foo.example.org Port 80
| `---- (Names and IPs have been changed to protect the innocent ;-) Best wishes, --Daniel -- Daniel Neri mailto:dn@REDACTED Sigicom AB, Sweden http://www.sigicom.com From bauerd@REDACTED Tue Nov 7 02:00:04 2000 From: bauerd@REDACTED (David W. Bauer Jr.) Date: Mon, 6 Nov 2000 20:00:04 -0500 (EST) Subject: inets 2.5.1 In-Reply-To: Message-ID: feynman /home1/bauerd/inets: ll total 28 drwxr-xr-x 2 bauerd users 4096 Nov 4 21:30 auth drwxr-xr-x 2 bauerd users 4096 Nov 4 21:27 cgi-bin drwxr-xr-x 2 bauerd users 4096 Nov 4 22:40 conf drwxr-xr-x 2 bauerd users 4096 Nov 4 22:24 htdocs drwxr-xr-x 2 bauerd users 4096 Nov 4 21:25 icons drwxr-xr-x 2 bauerd users 4096 Nov 4 21:22 logs drwxr-xr-x 2 bauerd users 4096 Nov 4 22:36 ssl feynman /home1/bauerd/inets: erl -boot start_sasl -config conf/inets.config Erlang (BEAM) emulator version 5.0.1 [source] Eshell V5.0.1 (abort with ^G) 1> =PROGRESS REPORT==== 6-Nov-2000::18:29:12 === supervisor: {local,sasl_safe_sup} started: [{pid,<0.31.0>}, {name,alarm_handler}, {mfa,{alarm_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 6-Nov-2000::18:29:12 === supervisor: {local,sasl_safe_sup} started: [{pid,<0.32.0>}, {name,overload}, {mfa,{overload,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 6-Nov-2000::18:29:12 === supervisor: {local,sasl_sup} started: [{pid,<0.30.0>}, {name,sasl_safe_sup}, {mfa,{supervisor, start_link, [{local,sasl_safe_sup},sasl,safe]}}, {restart_type,permanent}, {shutdown,infinity}, {child_type,supervisor}] =PROGRESS REPORT==== 6-Nov-2000::18:29:12 === supervisor: {local,sasl_sup} started: [{pid,<0.33.0>}, {name,release_handler}, {mfa,{release_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 6-Nov-2000::18:29:12 === application: sasl started_at: nonode@REDACTED 1> halt(). feynman /home1/bauerd/inets: David ~~~ ~~ ~~~~ _o URL: http://www.david-bauer.com ~~~ ~~~~ ~~ _'|<,_ ~~~~ ~~~ ~~~~ (*)/ (*) On 5 Nov 2000, Torbjorn Tornkvist wrote: # #> feynman ~/inets: erl -config conf/inets.config # #Try and see what happends if you start it like: # # erl -boot start_sasl -config conf/inets.config # #Cheers /Tobbe # From armesto@REDACTED Wed Nov 8 19:42:30 2000 From: armesto@REDACTED (Armesto) Date: Wed, 8 Nov 2000 16:42:30 -0200 Subject: "Turbo Tab" Message-ID: <000801c049b3$adaacf00$9b0964a0@jonathan> Hello, My name is Jo?o Armesto. I'm from Brazil. I want to know something about a program called "Turbo tab". Someone told me that this program was like a plug in for Excell. I can't find it on the net. If you know anything please send me an answer back. Thank you, Jo?o Armesto -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonb@REDACTED Thu Nov 9 09:24:49 2000 From: simonb@REDACTED (Simon Bennett) Date: Thu, 09 Nov 2000 08:24:49 +0000 Subject: "Turbo Tab" References: <000801c049b3$adaacf00$9b0964a0@jonathan> Message-ID: <3A0A5F51.C9677FD0@terminus.ericsson.se> Hi You are looking for Erlang the unit of telephony traffic rather than Erlang the language. I think what you are looking for is on the Westbay Erlang site at: http://www.erlang.com/excel.html I hope this helps. Simon Bennett Information Systems Consultant ___________________________________________________________________ Simon Bennett E-mail: simonb@REDACTED Ericsson Intracom http://www.ericsson.co.uk/UK/intracom 1 Bede Island Road Voice (UK) 0116 2542400 Leicester Voice (int) +44 116 2542400 England Voice ECN: 832 707 ext 232 LE2 7EU Fax: +44 (0)116 2046111 ___________________________________________________________________ > Armesto wrote: > > Hello, > > My name is Jo?o Armesto. I'm from Brazil. I want to know something > about a program called "Turbo tab". Someone told me that this > program was like a plug in for Excell. > I can't find it on the net. > If you know anything please send me an answer back. > > Thank you, > > Jo?o Armesto From bjowi@REDACTED Thu Nov 9 13:25:05 2000 From: bjowi@REDACTED (=?ISO-8859-1?Q?Bj=F6rn Wingman?=) Date: Thu, 9 Nov 2000 13:25:05 +0100 (MET) Subject: Sockets on IRIX In-Reply-To: <3A06B08E.5ED019F2@erix.ericsson.se> (message from Raimo Niskanen on Mon, 06 Nov 2000 14:22:22 +0100) References: <200011032326.AAA23327@sture.lysator.liu.se> <3A06B08E.5ED019F2@erix.ericsson.se> Message-ID: <200011091225.NAA23094@sture.lysator.liu.se> > There is a (undocumented) way to override the emulator's default > behaviour, which might be needed in this case: Create a file ".inetrc" > in Your home directory, in the current working directory or in the > ${OTP_ROOT}/bin directory (I will come back to this later), with the > contents: > {lookup, ["native"]}. Yes, that solved it. Thanks. Does anyone know the real cause of the problem? (Just interested) /Bj?rn Wingman From rv@REDACTED Thu Nov 9 13:46:51 2000 From: rv@REDACTED (Robert Virding) Date: Thu, 09 Nov 2000 13:46:51 +0100 Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: Your message of "Fri, 03 Nov 2000 13:00:35 +0100." Message-ID: <200011091246.NAA32652@trana.bluetail.com> Ulf Wiger writes: >On Fri, 3 Nov 2000, Ulf Wiger wrote: > >>X = foo(...), % [0] is implicit >>X[1] = bar(X), >>... >> >>or perhaps >> >>X = foo(...), % \0 is implicit >>X\1 = bar(X), >>... >> >> >>would allow trace on "changes" to a variable, and also introduce a >>standard way of describing something that occurs frequently in >>most Erlang code I've seen. >> >>/Uffe > >Since I posted this without thinking much, I paused and thought about >it afterwards. > >One common source of bugs (and very hard to find) is when "changing" a >variable and forgetting to pass the latest instance. An example from >application_controller.erl: > >... > >a compiler could easily produce a warning stating that we're passing >an old instance of S, since this is almost always a bug, and can >easily be avoided in the cases when it it's intentional. I ALWAYS try to explicit and name the first occurrence as XXX0 and last occurrence as XXXn, and make sure I NEVER number variables which are not changed. Just to make it easier to see which variables are meant to be changed. I think you should be very careful when adding a new syntax for something which is not a new feature. These are still just variables. Due to Erlang's (lack of) scoping there could be problems with such a scheme. How hard should lint handle these things? Is it an error to write? X[3] = foo(X[2]), X[10] = bar(X[3]), If this is really something which people would like lint to check and warn I would prefer just to use the variable-name-ending-with-index convention. Lint already checks for singeton variables if you ask it, just use the option 'warn_unused_vars'. It is, however, a bit of a sledgehammer. It ignores variables starting with "_", eg. _Temp. Robert -- Robert Virding Tel: +46 (0)8 545 55 017 Alteon Web Systems Email: rv@REDACTED S:t Eriksgatan 44 WWW: http://www.bluetail.com/~rv SE-112 34 Stockholm, SWEDEN "Folk s?ger att jag inte bryr mig om n?gonting, men det skiter jag i". From etxuwig@REDACTED Thu Nov 9 14:46:40 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 9 Nov 2000 14:46:40 +0100 (MET) Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: <200011091246.NAA32652@trana.bluetail.com> Message-ID: On Thu, 9 Nov 2000, Robert Virding wrote: >I ALWAYS try to explicit and name the first occurrence as XXX0 and last >occurrence as XXXn, and make sure I NEVER number variables which are not >changed. Just to make it easier to see which variables are meant to be >changed. Yes, this is a sound approach. But it doesn't really address the problem of identifying the type of bugs I described. Using the 'unused_vars' option would not, for example catch the "bug" in application_controller, since all variables are in fact used. >I think you should be very careful when adding a new syntax for >something which is not a new feature. These are still just variables. Of course one should be careful. I'm merely making a quick suggestion. But I don't really understand the "still just variables" argument. Just like we've added a syntax for addressing part of a data structure (X[N] could of course easily be interpreted as trying to address the Nth element in an array), we'd be adding a notion of "history" to a variable, instead of just trying to give hints using a loose naming convention. Since an instantiated variable cannot be changed - and we do in fact often want to be able to "update" a data structure - adding a notion of instance numbering doesn't seem too far-fetched to me. (Not to say that I'm 100% convinced that my suggestion is the best one. It may indeed create more problems than it solves.) >Due to Erlang's (lack of) scoping there could be problems with such a >scheme. If you say so. You're welcome to educate me about what those scoping problems would be. After all, these are still just variables. ;) >How hard should lint handle these things? Is it an error to >write? > > X[3] = foo(X[2]), > X[10] = bar(X[3]), Uhmm, it probably shouldn't be. However, X[3] = foo(X[2]), X[10] = bar(X[2]) should be considered suspicious. Lint would catch that, though. I didn't know about the 'unused_vars' option. Another way to go could be to implement some "variable highlighting", similar to the parens matching in emacs. This would make it much easier to see that your numbering is not correct. >If this is really something which people would like lint to check and >warn I would prefer just to use the variable-name-ending-with-index >convention. Meaning that Lint should split atoms and try to make sense of your naming conventions? Then, code like the following from snmp_misc.erl would be in for a surprise: is_tmask_match(TAddr1, TAddr2, []) -> true; is_tmask_match([H1 | T1], [H2 | T2], [M1 | M2]) -> if (H1 band M1) == (H2 band M1) -> is_tmask_match(T1, T2, M2); true -> false end. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From etxuwig@REDACTED Thu Nov 9 14:53:35 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 9 Nov 2000 14:53:35 +0100 (MET) Subject: variable naming conventions Message-ID: As I peeked into snmp_misc.erl, the following function caught my eye: %% Check if a Tag is a member in a TagList. Tags and TagLists are defined %% in SNMP-TARGET-MIB is_tag_member(Tag, TagList) -> check_tag_list(TagList, [], lists:reverse(Tag)). check_tag_list([32 | T], Res, Gat) -> tag_delimiter_found(Res, Gat, T); check_tag_list([9 | T], Res, Gat) -> tag_delimiter_found(Res, Gat, T); check_tag_list([13 | T], Res, Gat) -> tag_delimiter_found(Res, Gat, T); check_tag_list([11 | T], Res, Gat) -> tag_delimiter_found(Res, Gat, T); check_tag_list([Char | T], Res, Gat) -> check_tag_list(T, [Char | Res], Gat); check_tag_list([], Res, Gat) -> tag_delimiter_found(Res, Gat, []). tag_delimiter_found(Gat, Gat, T) -> true; tag_delimiter_found(_Res, Gat, []) -> false; tag_delimiter_found(_Res, Gat, T) -> check_tag_list(T, [], Gat). It took me a while to understand what the heck was the meaning with the variable "Gat". Finally, I realized that it was "Tag" backwards, since check_tag_list/3 is called with lists:reverse(Tag). Way to go! (: A short comment would have saved me 30 seconds of confusion. Personally, I would have gone with something like ReversedTag. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From raimo@REDACTED Thu Nov 9 15:05:39 2000 From: raimo@REDACTED (Raimo Niskanen) Date: Thu, 09 Nov 2000 15:05:39 +0100 Subject: Sockets on IRIX References: <200011032326.AAA23327@sture.lysator.liu.se> <3A06B08E.5ED019F2@erix.ericsson.se> <200011091225.NAA23094@sture.lysator.liu.se> Message-ID: <3A0AAF33.9B3BACFE@erix.ericsson.se> I would also be interested if anyone knows the real cause, since I probably will have to fix this in release R8. / Raimo Niskanen, Erlang/OTP Bj?rn Wingman wrote: > > > There is a (undocumented) way to override the emulator's default > > behaviour, which might be needed in this case: Create a file ".inetrc" > > in Your home directory, in the current working directory or in the > > ${OTP_ROOT}/bin directory (I will come back to this later), with the > > contents: > > > {lookup, ["native"]}. > > Yes, that solved it. Thanks. Does anyone know the real cause of the > problem? (Just interested) > > /Bj?rn Wingman From simonb@REDACTED Thu Nov 9 15:07:55 2000 From: simonb@REDACTED (Simon Bennett) Date: Thu, 09 Nov 2000 14:07:55 +0000 Subject: variable naming conventions References: Message-ID: <3A0AAFBB.4C2720D1@terminus.ericsson.se> > It took me a while to understand what the heck was the meaning with > the variable "Gat". Finally, I realized that it was "Tag" backwards, > since check_tag_list/3 is called with lists:reverse(Tag). Now should it be Tag[2] = lists:reverse(Tag[1]), check_tag_list(TagList, [], Tag[2]). or Gat[2] = lists:reverse(Tag[1]), check_tag_list(TagList, [], Gat[2]). or [2]gaT = lists:reverse(Tag[1]), check_tag_list(TagList, [], [2]gaT). :-) Simon From vladdu@REDACTED Thu Nov 9 15:30:06 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Thu, 9 Nov 2000 15:30:06 +0100 Subject: Variable instances (Re: Trace on Variable assignment) References: Message-ID: Just my 2 ?re :-) For the compiler and the language proper, these naming issues are not interesting at all. They are just an utility feature, to help us along. This means that it should be only necessary to accept variable names that end in (for example) "[]" or "____" or something else, and then rewrite the tools (lint, etc) that will use that format... Am I wrong here? It should not be a big deal for fixing the token parser, and the rest relies anyway on the developers actually using the feature. I, for one, prefer having names like AdjustedArgument rather than like Argument[5]... that is - when I don't just overuse X, Y, A and I :-) /Vlad -------------------------------------------------------------- For God's sake, Smithers! It's not rocket science, it's just brain surgery! -------------------------------------------------------------- From etxuwig@REDACTED Thu Nov 9 16:04:08 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 9 Nov 2000 16:04:08 +0100 (MET) Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: Message-ID: On Thu, 9 Nov 2000, Vlad Dumitrescu wrote: >I, for one, prefer having names like AdjustedArgument rather than like >Argument[5]... that is - when I don't just overuse X, Y, A and I :-) Personally, I'd like to use subscripts for instance numbering, but they're so hard to type... Perhaps we should start writing our Erlang code in MS Word? (= Names like NewX are great if you only change X once - they become a bit contrived in the following iterations: NewNewX? EvenNewerX? It's when you start having more than 3-4 changes of the same variable in the same function that it's easy to lose track. (Yeah I know it's a crummy way to write code in a single-assignment language, but I've run into so many examples where it's really tricky to come up with a better way.) /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From vladdu@REDACTED Thu Nov 9 16:28:21 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Thu, 9 Nov 2000 16:28:21 +0100 Subject: Variable instances (Re: Trace on Variable assignment) References: Message-ID: > It's when you start having more than 3-4 changes of the same variable > in the same function that it's easy to lose track. It's not so easy (especially into code written by someone else) to keep track of X[1],... X[5] either... If X[i] is used in more contexts than to produce X[i+1], then my opinion is that it should get a descriptive name... /Vlad From stephane.leibovitsch@REDACTED Thu Nov 9 16:35:17 2000 From: stephane.leibovitsch@REDACTED (=?iso-8859-1?Q?St=E9phane?= Leibovitsch) Date: Thu, 09 Nov 2000 16:35:17 +0100 Subject: Question about lists:foldl() Message-ID: <3A0AC435.80422BAC@idealx.com> Hello everybody, I have a little problem with the function lists:foldl() or lists:foldr(). When I try this, I get an error message, but I don't understand why : 1> lists:foldl( fun (x,y)->x+y end,2 ,[3,4,5]). ** exited: {function_clause,[{erl_eval,'-inside-a-shell-fun-',[3,2]}, {erl_eval,expr,3}]} ** Do you have an idea ? Thanks, St?phane Leibovitsch -- St?phane Leibovitsch stephane.leibovitsch@REDACTED From Sean.Hinde@REDACTED Thu Nov 9 16:35:57 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 9 Nov 2000 15:35:57 -0000 Subject: Variable instances (Re: Trace on Variable assignment) Message-ID: <402DD461F109D411977E0008C791C3125652EC@imp02mbx.one2one.co.uk> > It's when you start having more than 3-4 changes of the same variable > in the same function that it's easy to lose track. > (Yeah I know it's a crummy way to write code in a single-assignment > language, but I've run into so many examples where it's really tricky > to come up with a better way.) In my various peeks into the OTP sources I've grown quite used seeing the Var0 Var1 Var2 progression, and also started to use it by default myself. The issues brought up here seem to be readability and maintainability as much as the avoidance of "potential" bugs of the kind noted in application_controller. Maybe a note in some coding styles part of the documentation (and/or new book) would go some part of the way to bring this into the normal vernacular of Erlang, and help avoid Gats confusions. http://www.erlang.se/doc/programming_rules.shtml#REF10726 could be updated to start with.. - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From tobbe@REDACTED Thu Nov 9 16:39:57 2000 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 09 Nov 2000 16:39:57 +0100 Subject: Question about lists:foldl() In-Reply-To: Stéphane Leibovitsch's message of "Thu, 09 Nov 2000 16:35:17 +0100" References: <3A0AC435.80422BAC@idealx.com> Message-ID: Change to upprcase, as in: 1> lists:foldl( fun (X,Y)->X+Y end,2 ,[3,4,5]). 14 Cheers /Tobbe From vances@REDACTED Thu Nov 9 18:24:41 2000 From: vances@REDACTED (Vance Shipley) Date: Thu, 9 Nov 2000 12:24:41 -0500 Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: <200011091246.NAA32652@trana.bluetail.com> Message-ID: } If this is really something which people would like lint to check and } warn I would prefer just to use the variable-name-ending-with-index } convention. Lint already checks for singeton variables if you ask it, } just use the option 'warn_unused_vars'. It is, however, a bit of a } sledgehammer. It ignores variables starting with "_", eg. _Temp. This pokes at a pet peeve of mine. When I reverse engineered the AbsForm I wanted to have the code serve to document it. I wanted to match on: {clause,_Line,[{_Type,_Line,Arg1},{_Type,_Line,Arg2}],_Guard,ClauseList} I had thought that by prepending an underscore the variable was anonymous. I quickly learned that it is not, only a single underscore is treated as anonymous. I would prefer that any variable with a leading underscore was treated as anonymous so that the above would work if Arg2 had a different line number than Arg1 or the types of the arguments were different. -Vance From etxuwig@REDACTED Fri Nov 10 10:36:09 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 10 Nov 2000 10:36:09 +0100 (MET) Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: Message-ID: On Thu, 9 Nov 2000, Vlad Dumitrescu wrote: >> It's when you start having more than 3-4 changes of the same variable >> in the same function that it's easy to lose track. > >It's not so easy (especially into code written by someone else) to keep >track of X[1],... X[5] either... Yeah, well I'm not thrilled about the look of it either. I was kinda hoping that someone would come up with a better syntax. My general thrust was that a Lint program should be able to determine _unequivocally_ that one variable is a newer version of another one. Simply using a naming convention doesn't really cut it when projects get sufficiently large, in my opinion. Besides, the convention is already polluted, since patterns like ([H1|T1], [H2|T2]) are used quite frequently. But I agree that giving the problem some attention and agreeing on a convention (I'd vote for Robert's Style), would be an important step in the right direction. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From richardc@REDACTED Fri Nov 10 12:23:33 2000 From: richardc@REDACTED (Richard Carlsson) Date: Fri, 10 Nov 2000 12:23:33 +0100 (MET) Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: Message-ID: On Thu, 9 Nov 2000, Vance Shipley wrote: > } If this is really something which people would like lint to check and > } warn I would prefer just to use the variable-name-ending-with-index > } convention. Lint already checks for singeton variables if you ask it, > } just use the option 'warn_unused_vars'. It is, however, a bit of a > } sledgehammer. It ignores variables starting with "_", eg. _Temp. > > This pokes at a pet peeve of mine. > > When I reverse engineered the AbsForm I wanted to have the code serve to > document it. I wanted to match on: > > {clause,_Line,[{_Type,_Line,Arg1},{_Type,_Line,Arg2}],_Guard,ClauseList} > > I had thought that by prepending an underscore the variable was anonymous. > I quickly learned that it is not, only a single underscore is treated as > anonymous. I would prefer that any variable with a leading underscore was > treated as anonymous so that the above would work if Arg2 had a different > line number than Arg1 or the types of the arguments were different. Treating any underscore-prefixed variables as anonymous would break a lot of existing code. However, a nice compromise could be to let the compiler warn about unused variables (when the `warn_unused_vars' option is set) *unless* the variable is underscore-prefixed. That means that typical errors like: S1 = foo(S0), S2 = bar(S0), S3 = foo(S2), will be warned about (S1 is not used), but no complaints would be issued about your example {clause,_Line,[{_Type,... /Richard Carlsson Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From etxuwig@REDACTED Fri Nov 10 14:40:47 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 10 Nov 2000 14:40:47 +0100 (MET) Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: Message-ID: On Fri, 10 Nov 2000, Richard Carlsson wrote: >However, a nice compromise could be to let the compiler >warn about unused variables (when the `warn_unused_vars' option is set) >*unless* the variable is underscore-prefixed. > >That means that typical errors like: > > S1 = foo(S0), > S2 = bar(S0), > S3 = foo(S2), > >will be warned about (S1 is not used), but no complaints would be issued >about your example {clause,_Line,[{_Type,... > > /Richard Carlsson Hmmm, I tried it on my own code. Since I've never liked the _Var convention (since they are actually bound, something that can cause very obscure bugs), I have lots of variables for documentation purposes only. Relying on the compiler to eliminate unnecessary variable bindings, I've come to do that even more. Thus, I get so many warnings from the linter that the 'warn_unused_vars' option becomes unwieldy. In our work on writing design rules, we've never been able to agree on a recommendation for "don't care" variables. Some like to annotate with underscores, others have tried it, but recoiled in horror when they've had to chase down weird pattern-matching bugs (not understanding from the start that they were actually binding variables). Others, like Peter Lundell, hate "don't care" variables (even '_' which is truly "don't care" but doesn't let you clarify what kind of variable it should be), and never use them at all. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From rv@REDACTED Fri Nov 10 15:55:32 2000 From: rv@REDACTED (Robert Virding) Date: Fri, 10 Nov 2000 15:55:32 +0100 Subject: Variable instances (Re: Trace on Variable assignment) In-Reply-To: Your message of "Fri, 10 Nov 2000 14:40:47 +0100." Message-ID: <200011101455.PAA03161@trana.bluetail.com> Ulf Wiger writes: > >Thus, I get so many warnings from the linter that the >'warn_unused_vars' option becomes unwieldy. > >In our work on writing design rules, we've never been able to agree on >a recommendation for "don't care" variables. Some like to annotate >with underscores, others have tried it, but recoiled in horror when >they've had to chase down weird pattern-matching bugs (not >understanding from the start that they were actually binding >variables). Others, like Peter Lundell, hate "don't care" variables >(even '_' which is truly "don't care" but doesn't let you clarify >what kind of variable it should be), and never use them at all. The same thing happens to me, that is why I called it a sledgehammer. I very seldom use don't care variables, even the real one, preferring to always give a variable a name, even if I don't use it. I don't really like annotating with underscores, although I suppose I could learn if I wanted to. It would be difficult to get lint to automatically check chaining of variables without some proper convention (or syntax). Just doing the numbers at the end variable names could give very confusing results. What you would want is some mechanism to automatically fixing the chaining through a number of calls, like Prolog DCGs, but I haven't seen a system which is easy to use and can handle many extra variables. They would probably be very confusing to new users. Robert From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sean.Hinde@REDACTED Mon Nov 13 12:44:54 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 13 Nov 2000 11:44:54 -0000 Subject: Interrupting passive socket recv Message-ID: <402DD461F109D411977E0008C791C31256531E@imp02mbx.one2one.co.uk> Trying to be as precise as possible about an idea, here goes: I'm thinking about an application in which my Erlang node might get flooded with replies to a query it has sent over a socket. This situation would appear to lend itself to a passive gen_tcp:recv/2 call rather than an active socket so that the message buffer doesn't chew up all the memory of my machine while it tries to deal with the flood. The problem with passive recv is that as far as I can make out the only way to make the process waiting in recv state look at Erlang messages is to time out the recv every so often (every few millsecs to make it responsive) and call receive. This would appear to be pretty inefficient. It would be very nice to have some setup (either in the socket library, or as an extra to the normal Erlang receive?) where a rec{v | eive} with *passive* semantics could return either a packet or an Erlang message. So EITHER: An enhancement to the active socket mode where the part of a virtual "message buffer" holding excess tcp/ip packets is held out at the far end of the socket rather than filling the local Erlang message buffer. OR An enhancement to gen_tcp:recv where the recv can be interrupted on receipt of an Erlang message I'd be very interested to hear of any ways others have found to get around this problem efficiently, and if not, I'd like to propose something like it as an enhancement to OTP. - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From vladdu@REDACTED Mon Nov 13 14:34:30 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 14:34:30 +0100 Subject: distribution not working Message-ID: Hi again! This time it is a FAQ type of question, but I can't find the answer... I am running 2 nodes on the same machine. The distribution works okay when running with short names, but not when running with long ones... why is that? I am running on Windows, and on a LAN. Does it have to do with DNS and such? thanks in advance Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu@REDACTED Mon Nov 13 10:39:29 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 10:39:29 +0100 Subject: JInterface bug? Message-ID: Hi! After playing a while with JInterface, I noticed a possible bug in OtpNode$Acceptor. I run JDK 1.3 on Windows. The constructor ends with publishPort(); acceptor.start(); I get a nullPointerException on the last line, but all works well if it is changed to start(); or this.start(); The reason is of course that since the constructor is not ended yet, OtpNode.acceptor is still null... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From not.for.email@REDACTED Mon Nov 13 17:16:27 2000 From: not.for.email@REDACTED (Gordon Beaton) Date: 13 Nov 2000 16:16:27 GMT Subject: JInterface bug? References: Message-ID: <8up44r$38s$1@news.du.uab.ericsson.se> On 13 Nov 2000 09:39:29 GMT, Vlad Dumitrescu wrote: > After playing a while with JInterface, I noticed a possible bug in > OtpNode$Acceptor. I run JDK 1.3 on Windows. > > The constructor ends with > publishPort(); > acceptor.start(); > > I get a nullPointerException on the last line, but all works well if it > is changed to > start(); > or > this.start(); > > The reason is of course that since the constructor is not ended yet, > OtpNode.acceptor is still null... The bug has been known since one day after r7b was released, and the fix is exactly as you have described it. There is *supposed* to be a patch somewhere... /gordon -- g o r d o n . b e a t o n @ e r i c s s o n . c o m software architecture laboratory ericsson research stockholm, sweden From vladdu@REDACTED Mon Nov 13 14:34:30 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Nov 2000 14:34:30 +0100 Subject: distribution not working Message-ID: Hi again! This time it is a FAQ type of question, but I can't find the answer... I am running 2 nodes on the same machine. The distribution works okay when running with short names, but not when running with long ones... why is that? I am running on Windows, and on a LAN. Does it have to do with DNS and such? thanks in advance Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob@REDACTED Mon Nov 13 17:46:02 2000 From: jakob@REDACTED (Jakob Cederlund =?iso-8859-1?Q?på?= UAB) Date: Mon, 13 Nov 2000 17:46:02 +0100 Subject: distribution not working In-Reply-To: Message-ID: <5.0.0.25.0.20001113174414.00b75eb0@mail> At 14:34 2000-11-13 +0100, you wrote: >Hi again! > >This time it is a FAQ type of question, but I can't find the answer... > >I am running 2 nodes on the same machine. The distribution works okay when >running with short names, but not when running with long ones... why is >that? I am running on Windows, and on a LAN. Does it have to do with DNS >and such? > >thanks in advance >Vlad There was an issue when using long names and DHCP on Windows. This is fixed in R7B. Please notify if you get the same problems using R7B. /Jakob From Sean.Hinde@REDACTED Mon Nov 13 12:44:54 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 13 Nov 2000 11:44:54 -0000 Subject: Interrupting passive socket recv Message-ID: <402DD461F109D411977E0008C791C31256531E@imp02mbx.one2one.co.uk> Trying to be as precise as possible about an idea, here goes: I'm thinking about an application in which my Erlang node might get flooded with replies to a query it has sent over a socket. This situation would appear to lend itself to a passive gen_tcp:recv/2 call rather than an active socket so that the message buffer doesn't chew up all the memory of my machine while it tries to deal with the flood. The problem with passive recv is that as far as I can make out the only way to make the process waiting in recv state look at Erlang messages is to time out the recv every so often (every few millsecs to make it responsive) and call receive. This would appear to be pretty inefficient. It would be very nice to have some setup (either in the socket library, or as an extra to the normal Erlang receive?) where a rec{v | eive} with *passive* semantics could return either a packet or an Erlang message. So EITHER: An enhancement to the active socket mode where the part of a virtual "message buffer" holding excess tcp/ip packets is held out at the far end of the socket rather than filling the local Erlang message buffer. OR An enhancement to gen_tcp:recv where the recv can be interrupted on receipt of an Erlang message I'd be very interested to hear of any ways others have found to get around this problem efficiently, and if not, I'd like to propose something like it as an enhancement to OTP. - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From luke@REDACTED Mon Nov 13 18:03:05 2000 From: luke@REDACTED (Luke Gorrie) Date: 13 Nov 2000 18:03:05 +0100 Subject: Interrupting passive socket recv In-Reply-To: Sean Hinde's message of "Mon, 13 Nov 2000 11:44:54 -0000" References: <402DD461F109D411977E0008C791C31256531E@imp02mbx.one2one.co.uk> Message-ID: Sean Hinde writes: > Trying to be as precise as possible about an idea, here goes: > > I'm thinking about an application in which my Erlang node might get flooded > with replies to a query it has sent over a socket. > > This situation would appear to lend itself to a passive gen_tcp:recv/2 call > rather than an active socket so that the message buffer doesn't chew up all > the memory of my machine while it tries to deal with the flood. I think the {active, once} feature would be good for this, but at a glance it appears to be undocumented (?) but present in R7B (and older versions I think). My understanding is that you make a socket {active, once}, either as an option in connect/3 or later with setopts/2, it will send you one packet "actively" and then immediately switch to passive mode. When you receive the packet in your erlang code, you can set the socket back to {active, once} again for the next packet. I guess this is what you need. Example usage connecting to the "echo" daemon: ,---- | 5> {ok, S} = gen_tcp:connect("localhost", 7, [{active, once}]). | {ok,#Port<0.7>} | 6> gen_tcp:send(S, "foo"). | ok | 7> flush(). | Shell got {tcp,#Port<0.7>,"foo"} | ok | 8> gen_tcp:send(S, "bar"). | ok | 9> flush(). | ok | 10> inet:setopts(S, [{active, once}]). | ok | 11> flush(). | Shell got {tcp,#Port<0.7>,"bar"} | ok `---- Cheers, Luke From Sean.Hinde@REDACTED Mon Nov 13 20:31:30 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 13 Nov 2000 19:31:30 -0000 Subject: Interrupting passive socket recv Message-ID: <402DD461F109D411977E0008C791C312565323@imp02mbx.one2one.co.uk> Luke, > I think the {active, once} feature would be good for this, but at a > glance it appears to be undocumented (?) but present in R7B (and older > versions I think). This would indeed appear to do the job - thanks very much for the tip. Cheers, Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From sgelkins@REDACTED Tue Nov 14 11:54:29 2000 From: sgelkins@REDACTED (Steve Elkins) Date: Tue, 14 Nov 2000 05:54:29 -0500 Subject: Python in Erlang Message-ID: <3A1119E5.700D5B41@bellsouth.net> Hi, My manager is attracted to Python. Has anyone ever tried embedding it in Erlang? python:eval("whatever") or some such thing? I'd be interested in hearing any experience reports. Thanks, Steve From Peter.Andersson@REDACTED Tue Nov 14 12:04:37 2000 From: Peter.Andersson@REDACTED (Peter Andersson) Date: Tue, 14 Nov 2000 11:04:37 +0000 Subject: Interrupting passive socket recv References: <402DD461F109D411977E0008C791C31256531E@imp02mbx.one2one.co.uk> Message-ID: <3A111C45.C01C6AC7@eei.ericsson.se> Hi Sean, Just a few thoughts... What if you spawn a separate process just to handle the receiving of TCP messages? To avoid flooding this process (in case your main application doesn't request the data quickly enough), the socket should be in passive mode. Your main application process will have normal response times since it is the separate process that does the waiting if nothing comes in over the socket. The protocol between the main process and the receiving one must, of course, be asynchronous. If you need to abort the gen_tcp:recv() then perhaps you can just kill the separate process. I don't know if this is a possible workaround. I guess it depends mainly on the behaviour of your application. Synchronisation between different events, like multiple TCP receives, should still be possible even if the main process communicates asynchronously with the "workers". Regards /Peter Sean Hinde wrote: > > Trying to be as precise as possible about an idea, here goes: > > I'm thinking about an application in which my Erlang node might get flooded > with replies to a query it has sent over a socket. > > This situation would appear to lend itself to a passive gen_tcp:recv/2 call > rather than an active socket so that the message buffer doesn't chew up all > the memory of my machine while it tries to deal with the flood. > > The problem with passive recv is that as far as I can make out the only way > to make the process waiting in recv state look at Erlang messages is to time > out the recv every so often (every few millsecs to make it responsive) and > call receive. This would appear to be pretty inefficient. > > It would be very nice to have some setup (either in the socket library, or > as an extra to the normal Erlang receive?) where a rec{v | eive} with > *passive* semantics could return either a packet or an Erlang message. > > So EITHER: > > An enhancement to the active socket mode where the part of a virtual > "message buffer" holding excess tcp/ip packets is held out at the far end of > the socket rather than filling the local Erlang message buffer. > > OR > > An enhancement to gen_tcp:recv where the recv can be interrupted on receipt > of an Erlang message > > I'd be very interested to hear of any ways others have found to get around > this problem efficiently, and if not, I'd like to propose something like it > as an enhancement to OTP. > > - Sean > > NOTICE AND DISCLAIMER: > This email (including attachments) is confidential. If you have received > this email in error please notify the sender immediately and delete this > email from your system without copying or disseminating it or placing any > reliance upon its contents. We cannot accept liability for any breaches of > confidence arising through use of email. Any opinions expressed in this > email (including attachments) are those of the author and do not necessarily > reflect our opinions. We will not accept responsibility for any commitments > made by our employees outside the scope of our business. We do not warrant > the accuracy or completeness of such information. From mickael.remond@REDACTED Tue Nov 14 12:26:21 2000 From: mickael.remond@REDACTED (Mickael Remond) Date: 14 Nov 2000 12:26:21 +0100 Subject: Python in Erlang In-Reply-To: Steve Elkins's message of "Tue, 14 Nov 2000 05:54:29 -0500" References: <3A1119E5.700D5B41@bellsouth.net> Message-ID: <87lmumre02.fsf@western.ird.idealx.com> On Tue, 14 Nov 2000, sgelkins@REDACTED wrote: > Hi, > > My manager is attracted to Python. Has anyone ever tried > embedding it in Erlang? python:eval("whatever") or some > such thing? I'd be interested in hearing any experience > reports. You can find a proof of concept binding at : http://csmctmto.interpoint.net/didx/python_erlang.html We tried this binding but it was not sufficent for our need and is difficult to build and to use. Finally, we are just made a specific API to call our Erlang from Python via socket communication. This approach is working well for us. The datatype are very similar and are easy to map, so the datatype conversion is ok. If someone is interested, we might clean up our code, make it more generic and release it. -- Micka?l R?mond - mickael.remond@REDACTED - http://IDEALX.com - +33 (1) 44 42 00 38 From Sean.Hinde@REDACTED Tue Nov 14 13:04:01 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 14 Nov 2000 12:04:01 -0000 Subject: Interrupting passive socket recv Message-ID: <402DD461F109D411977E0008C791C312565330@imp02mbx.one2one.co.uk> Peter, > Just a few thoughts... What if you spawn a separate process > just to handle the > receiving of TCP messages? To avoid flooding this process (in Yes, I also thought a bit about this solution. The drawback is that it introduces an extra message transfer as the recv process will have to send the replies back to my marshalling process which knows who asked the query and so can return the answer to the right place. Killing the recv process is also a bit nasty as well, though it does raise the additional question of how one interrupts a gen_tcp:accept. This is an issue for code upgrades as well as a general programming issue. The options seem to be the same as documented for recv - timeout and retry to allow space for other Erlang messages to be received - which is pretty horrible (lost connections) Any more tricks up anyones sleeve for this one? Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From bjorn@REDACTED Tue Nov 14 13:35:18 2000 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 14 Nov 2000 13:35:18 +0100 Subject: Interrupting passive socket recv In-Reply-To: Luke Gorrie's message of "13 Nov 2000 18:03:05 +0100" References: <402DD461F109D411977E0008C791C31256531E@imp02mbx.one2one.co.uk> Message-ID: Luke Gorrie writes: > Sean Hinde writes: > > > Trying to be as precise as possible about an idea, here goes: > > > > I'm thinking about an application in which my Erlang node might get flooded > > with replies to a query it has sent over a socket. > > > > This situation would appear to lend itself to a passive gen_tcp:recv/2 call > > rather than an active socket so that the message buffer doesn't chew up all > > the memory of my machine while it tries to deal with the flood. > > I think the {active, once} feature would be good for this, but at a > glance it appears to be undocumented (?) but present in R7B (and older > versions I think). We will document this feature in R8 (and perhaps some other hidden features as well). /Bj?rn -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From tobbe@REDACTED Tue Nov 14 14:25:04 2000 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 14 Nov 2000 14:25:04 +0100 Subject: Interrupting passive socket recv In-Reply-To: Bjorn Gustavsson's message of "14 Nov 2000 13:35:18 +0100" References: <402DD461F109D411977E0008C791C31256531E@imp02mbx.one2one.co.uk> Message-ID: > We will document this feature in R8 (and perhaps some other hidden features > as well). Like the: inet:setopts(Socket, [{bit8, clear}]) inet:getopts(Socket, [bit8]) stuff... ;-) /Tobbe From Chandrashekhar.Mullaparthi@REDACTED Tue Nov 14 14:28:41 2000 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Tue, 14 Nov 2000 13:28:41 -0000 Subject: Interrupting passive socket recv Message-ID: <402DD461F109D411977E0008C791C31202A79765@imp02mbx.one2one.co.uk> Another suggestion would be to make gen_tcp:recv take a message pattern which it should send back to the controlling process. In R6B, the call to gen_tcp:recv ends in this function: call(S, Request) -> Tag = make_ref(), Pid = S#socket.pid, Pid ! {call, self(), Tag, Request}, receive {Tag, Reply} -> Reply; {'EXIT', Pid, Reason} -> {error, closed}; {tcp_closed, S} -> {error, closed} end. Now if this is extended to: call(S, Request, MyPattern) -> Tag = make_ref(), Pid = S#socket.pid, Pid ! {call, self(), Tag, Request}, receive {Tag, Reply} -> Reply; {'EXIT', Pid, Reason} -> {error, closed}; {tcp_closed, S} -> {error, closed}; {MyPattern, Mesg} -> {MyPattern, Mesg} end. So I can call: gen_tcp:recv(SocketRef, Length, my_message) so that all messages to my process in the format {my_message, Something} are given to me as a result. This is pretty restrictive in the sense that your messages have to conform to a certain structure, you can specify only one pattern.... Multiple/Arbitrary patterns can be specified if clause guards are extended to take a user defined fun. In that case, the above function can be written as: call(S, Request, UserDefinedPredicateFun) -> Tag = make_ref(), Pid = S#socket.pid, Pid ! {call, self(), Tag, Request}, receive {Tag, Reply} -> Reply; {'EXIT', Pid, Reason} -> {error, closed}; {tcp_closed, S} -> {error, closed}; Message when UserDefinedPredicateFun(Message) -> Message end. cheers, Chandru > -----Original Message----- > From: Sean Hinde [mailto:Sean.Hinde@REDACTED] > Sent: 14 November 2000 12:04 > To: 'Peter Andersson' > Cc: 'Erlang Questions' > Subject: RE: Interrupting passive socket recv > > > Peter, > > > Just a few thoughts... What if you spawn a separate process > > just to handle the > > receiving of TCP messages? To avoid flooding this process (in > > Yes, I also thought a bit about this solution. The drawback is that it > introduces an extra message transfer as the recv process will > have to send > the replies back to my marshalling process which knows who > asked the query > and so can return the answer to the right place. > > Killing the recv process is also a bit nasty as well, though > it does raise > the additional question of how one interrupts a > gen_tcp:accept. This is an > issue for code upgrades as well as a general programming > issue. The options > seem to be the same as documented for recv - timeout and > retry to allow > space for other Erlang messages to be received - which is > pretty horrible > (lost connections) > > Any more tricks up anyones sleeve for this one? > > Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From alexis@REDACTED Tue Nov 14 17:30:36 2000 From: alexis@REDACTED (Alexis Le-Quoc) Date: Tue, 14 Nov 2000 11:30:36 -0500 Subject: Python in Erlang References: <3A1119E5.700D5B41@bellsouth.net> <87lmumre02.fsf@western.ird.idealx.com> Message-ID: <3A1168AC.D1FBEA67@neomeocorp.com> Mickael Remond wrote: > > On Tue, 14 Nov 2000, sgelkins@REDACTED wrote: > > > Hi, > > > > My manager is attracted to Python. Has anyone ever tried > > embedding it in Erlang? python:eval("whatever") or some > > such thing? I'd be interested in hearing any experience > > reports. > > You can find a proof of concept binding at : > > http://csmctmto.interpoint.net/didx/python_erlang.html > > We tried this binding but it was not sufficent for our need and is difficult > to build and to use. > > Finally, we are just made a specific API to call our Erlang from Python via socket > communication. This approach is working well for us. The datatype are very > similar and are easy to map, so the datatype conversion is ok. > > If someone is interested, we might clean up our code, make it more generic and > release it. > > -- > Micka?l R?mond - mickael.remond@REDACTED > - http://IDEALX.com > - +33 (1) 44 42 00 38 Greetings, I've spent some time trying to build python_erlang and I can't say I made any significant progress (granted I did not look into SWIG deep enough). The problem I need to solve is to interface a python server with some erlang code and I'm thinking of using sockets to work around the difficulty of building the binding. If you've already written some code to handle that and if you're willing to publish it, I think that's great; I'm interested. I was also wondering whether there existed a "standard" way of managing non-erlang nodes (C-node, Java nodes or Python nodes), i.e. a protocol to start and stop them, so as to integrate them into a reliable architecture of nodes. Yours, -- Alexis Le-Quoc From alexis@REDACTED Tue Nov 14 19:08:37 2000 From: alexis@REDACTED (Alexis Le-Quoc) Date: Tue, 14 Nov 2000 13:08:37 -0500 (EST) Subject: Jinterface newbie question Message-ID: Greetings, A question from a JInterface newbie... I'm trying to create a node in java using the following code: import com.ericsson.otp.erlang.*; public class NeomeoNode { public static void main(String[] args) throws java.io.IOException { OtpNode node = new OtpNode("node1", "neomeo"); } } It could hardly been made simpler but I think I'm missing something since I get a NullPointerException at line 613 of OtpNode.java. OtpNode.java:613 reads acceptor.start() where acceptor is a static Acceptor initialized to null. The weird thing is that line 613 is part of the Acceptor constructor... I'm trying to understand how: acceptor = new Acceptor() is supposed to work if the Acceptor constructor refers to a non-null reference to acceptor. A sort of chicken-and-egg problem. What am I missing here? -- Alexis Le-Quoc From sgelkins@REDACTED Wed Nov 15 02:35:46 2000 From: sgelkins@REDACTED (Steve Elkins) Date: Tue, 14 Nov 2000 20:35:46 -0500 Subject: Python in Erlang References: <3A1119E5.700D5B41@bellsouth.net> <87lmumre02.fsf@western.ird.idealx.com> Message-ID: <3A11E872.AC373520@bellsouth.net> Mickael Remond wrote: > On Tue, 14 Nov 2000, sgelkins@REDACTED wrote: > > My manager is attracted to Python. Has anyone ever tried > > embedding it in Erlang? python:eval("whatever") or some > > such thing? I'd be interested in hearing any experience > > reports. > > You can find a proof of concept binding at : > > http://csmctmto.interpoint.net/didx/python_erlang.html > > We tried this binding but it was not sufficent for our need and is difficult > to build and to use. Thanks, I should have said that I knew about this. I have some users who would like to use Python as their scripting language (everyone understands OOP, or at thinks so), but the application cries out for Erlang: lots of nodes, lots of threads per node, reliability a must, etc. So what I'm considering is calling Python from Erlang to handle user scripting and letting Erlang handle the rest. > Finally, we are just made a specific API to call our Erlang from Python via socket > communication. This approach is working well for us. The datatype are very > similar and are easy to map, so the datatype conversion is ok. And something in the opposite direction might work for us. Regards, Steve From not.for.email@REDACTED Wed Nov 15 08:18:01 2000 From: not.for.email@REDACTED (Gordon Beaton) Date: 15 Nov 2000 07:18:01 GMT Subject: Jinterface newbie question References: Message-ID: <8utdb9$gtd$1@news.du.uab.ericsson.se> On 14 Nov 2000 18:08:37 GMT, Alexis Le-Quoc wrote: > A question from a JInterface newbie... I'm trying to create a node in java > using the following code: > > import com.ericsson.otp.erlang.*; > > public class NeomeoNode { > public static void main(String[] args) throws java.io.IOException { > OtpNode node = new OtpNode("node1", "neomeo"); > } > } > > It could hardly been made simpler but I think I'm missing something since > I get a NullPointerException at line 613 of OtpNode.java. > > OtpNode.java:613 reads acceptor.start() where acceptor is a static > Acceptor initialized to null. The weird thing is that line 613 is part of > the Acceptor constructor... I'm trying to understand how: > acceptor = new Acceptor() is supposed to work if the Acceptor constructor > refers to a non-null reference to acceptor. A sort of chicken-and-egg > problem. What am I missing here? There is an error in the code, as was mentioned just yesterday on this list. Change line 613 to read "this.start()" instead. /gordon -- g o r d o n . b e a t o n @ e r i c s s o n . c o m software architecture laboratory ericsson research stockholm, sweden From bparsia@REDACTED Wed Nov 15 15:45:18 2000 From: bparsia@REDACTED (Bijan Parsia) Date: Wed, 15 Nov 2000 09:45:18 -0500 (EST) Subject: Inets performance (especially comparative) Message-ID: Hello, Does anyone have any figures, or even just a general sense, of how an Inets server compares, performancewise, with a similar Apache or AOLServer setup? In general, I'm interested in accounts on all aspects from folks who've had comparative experiences, even if anecdotal. Is there a list of inets based sites, anywhere? Cheers, Bijan Parsia From enano@REDACTED Wed Nov 15 21:11:46 2000 From: enano@REDACTED (Miguel Barreiro Paz) Date: Wed, 15 Nov 2000 21:11:46 +0100 (CET) Subject: file:read_file in R7B Message-ID: Hi, file:read_file/1 under R7B takes up an insane amount of memory, while it seemed to be far more reasonable in R6B. Is this a known bug? (or, probably, am I missing something?) Regards, Miguel From jamesh@REDACTED Thu Nov 16 00:14:39 2000 From: jamesh@REDACTED (James Hague) Date: Wed, 15 Nov 2000 17:14:39 -0600 Subject: Duplicate files in R7B for Windows? Message-ID: <3.0.32.20001115171439.010371a4@volition-inc.com> The following files are in both ./bin and ./erts-5.0.1/bin of the R7B distribution for Windows: beam.dll (604K) erl.exe (37K) erlc.exe (20K) werl.exe (37K) Why? I think this was true of R6 as well. James From yoel@REDACTED Thu Nov 16 12:35:18 2000 From: yoel@REDACTED (Yoel Jacobsen) Date: Thu, 16 Nov 2000 11:35:18 -0000 Subject: Real broadcast? Message-ID: <000801c04fc1$4c959dd0$ee445ac2@eandm.co.il> Is there any REAL broadcast function in OTP? (something like abcast but one that may not be aware of the recipient nodes, like using *.*.*.255 in class C IP broadcasting)? Thanks, Yoel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sean.Hinde@REDACTED Thu Nov 16 12:23:53 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 16 Nov 2000 11:23:53 -0000 Subject: Duplicate files in R7B for Windows? Message-ID: <402DD461F109D411977E0008C791C312565348@imp02mbx.one2one.co.uk> James, > The following files are in both ./bin and ./erts-5.0.1/bin of the R7B > distribution for Windows: > It allows you to have multiple versions of erts installed and change between them by moving files to bin (which is what the Install routine does - erts/etc/unix/Install.src) Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From matthias@REDACTED Thu Nov 16 15:24:19 2000 From: matthias@REDACTED (matthias@REDACTED) Date: Thu, 16 Nov 2000 15:24:19 +0100 (CET) Subject: file:read_file in R7B In-Reply-To: References: Message-ID: <14867.60947.460693.451287@corelatus.com> Miguel Barreiro Paz writes: > file:read_file/1 under R7B takes up an insane amount of memory, > while it seemed to be far more reasonable in R6B. Is this a known > bug? (or, probably, am I missing something?) Can you be a bit more specific about the problem, e.g. how big is the file you're reading, how are you measuring memory, and what constitutes an "insane" amount? One way which R7 differs from R6 is that many things involving binaries execute very slowly (and gobble memory) **in the shell**. For instance, doing {ok, Bin} = file:read_file("/usr/share/dict/words"). in the shell causes my beam emulator to jump to about 20Mb. Doing the same thing in a program, or even in different way in the shell: {ok, Bin} = file:read_file("/usr/share/dict/words"), z. does not show unexpected memory consumption. Taking a guess, this is because the shell has an interpreter for binary operations. Matthias From klacke@REDACTED Thu Nov 16 14:32:47 2000 From: klacke@REDACTED (Klacke) Date: Thu, 16 Nov 2000 14:32:47 +0100 Subject: file:read_file in R7B In-Reply-To: <14867.60947.460693.451287@corelatus.com>; from matthias@corelatus.com on Thu, Nov 16, 2000 at 03:24:19PM +0100 References: <14867.60947.460693.451287@corelatus.com> Message-ID: <20001116143247.B22214@bluetail.com> On Thu, Nov 16, 2000 at 03:24:19PM +0100, matthias@REDACTED wrote: > Miguel Barreiro Paz writes: > > > file:read_file/1 under R7B takes up an insane amount of memory, > > while it seemed to be far more reasonable in R6B. Is this a known > > bug? (or, probably, am I missing something?) > > Can you be a bit more specific about the problem, e.g. how big is the > file you're reading, how are you measuring memory, and what > constitutes an "insane" amount? > > One way which R7 differs from R6 is that many things involving > binaries execute very slowly (and gobble memory) **in the shell**. For > instance, doing > > {ok, Bin} = file:read_file("/usr/share/dict/words"). > > in the shell causes my beam emulator to jump to about 20Mb. Doing the > same thing in a program, or even in different way in the shell: > > {ok, Bin} = file:read_file("/usr/share/dict/words"), z. > > does not show unexpected memory consumption. > > Taking a guess, this is because the shell has an interpreter for > binary operations. It's because the shell keeps a histrory list of old values. These values are accessible trough i.e v(-3) to get 3 values back. Thus the binary returned in 'Bin' above is kept in the history list, and thus not freed for a while. Killing the shell with exit() will make it drop the the history list. /klacke -- Claes Wikstrom -- Caps is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke -- From mbj@REDACTED Thu Nov 16 14:42:29 2000 From: mbj@REDACTED (Martin Bjorklund) Date: Thu, 16 Nov 2000 14:42:29 +0100 Subject: file:read_file in R7B In-Reply-To: Your message of "Thu, 16 Nov 2000 14:32:47 +0100" <20001116143247.B22214@bluetail.com> References: <20001116143247.B22214@bluetail.com> Message-ID: <20001116144229E.mbj@bluetail.com> Klacke wrote: > It's because the shell keeps a histrory list of old > values. These values are accessible trough i.e v(-3) to get > 3 values back. Thus the binary returned in 'Bin' above > is kept in the history list, and thus not freed for a while. > > Killing the shell with exit() will make it drop the the history list. > > {ok, Bin} = file:read_file("/usr/share/dict/words"), z. ... and in this case it's smaller because the shell doesn't have to print the binary. /martin From Sean.Hinde@REDACTED Thu Nov 16 14:47:35 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 16 Nov 2000 13:47:35 -0000 Subject: file:read_file in R7B Message-ID: <402DD461F109D411977E0008C791C31256534F@imp02mbx.one2one.co.uk> > > Miguel Barreiro Paz writes: > > > > > file:read_file/1 under R7B takes up an insane amount of memory, > > > while it seemed to be far more reasonable in R6B. Is this a known > > > bug? (or, probably, am I missing something?) > > I also noticed aditional memory usage in the context of huge mnesia transactions. I heard somewhere that the move to threaded file i/o adds an extra data copy (even if threads are not enabled) which would lead to extra memory usage. Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From enano@REDACTED Thu Nov 16 15:05:03 2000 From: enano@REDACTED (Miguel Barreiro Paz) Date: Thu, 16 Nov 2000 15:05:03 +0100 (CET) Subject: file:read_file in R7B In-Reply-To: <14867.60888.860676.973837@corelatus.com> Message-ID: Hi, > One way which R7 differs from R6 is that many things involving > binaries execute very slowly (and gobble memory) **in the shell**. For > instance, doing It was the shell, certainly: I was reading several files in the 5-15 MByte range and noticed the beam machine was growing a lot. A clean shell evaluating {ok,B}=file:read_file("15_MByte_file"). made the beam unix process grow to 350 MBytes physical (and over 1GB virtual). I've just checked that {ok,B}=file:read_file("15_MByte_file"),ok. works as expected, and whole beam process grows to just some 17MB. So, it looks like the new binary pretty-printer in the R7B shell is a bit less efficient than it used to be :) Fool me. Regards, Miguel From arndt@REDACTED Thu Nov 16 17:22:30 2000 From: arndt@REDACTED (Arndt Jonasson) Date: 16 Nov 2000 16:22:30 GMT Subject: file:read_file in R7B References: , <14867.60947.460693.451287@corelatus.com> Message-ID: <8v11k6$nmk$1@news.du.uab.ericsson.se> In article <14867.60947.460693.451287@REDACTED>, wrote: > [...] > >One way which R7 differs from R6 is that many things involving >binaries execute very slowly (and gobble memory) **in the shell**. For >instance, doing > > {ok, Bin} = file:read_file("/usr/share/dict/words"). > >in the shell causes my beam emulator to jump to about 20Mb. Doing the >same thing in a program, or even in different way in the shell: > > {ok, Bin} = file:read_file("/usr/share/dict/words"), z. > >does not show unexpected memory consumption. > >Taking a guess, this is because the shell has an interpreter for >binary operations. There have been other wrong guesses too. I experimented a little, and it seems to be the case that io:format("~P", [Largebinary, 40]) does not consume immense amounts of memory, while io:format("~P", [{ok, Largebinary}, 40]) does. -- Arndt Jonasson Ericsson Utvecklings AB arndt@REDACTED ?T2/UAB/F/P +46 8 719 75 87 126 25 Stockholm From hans@REDACTED Fri Nov 17 12:19:15 2000 From: hans@REDACTED (Hans Nilsson) Date: Fri, 17 Nov 2000 12:19:15 +0100 (MET) Subject: sockets and multiple interfaces Message-ID: How do I bind a socket to a certain interface in Erlang? (In C the function setsockopt(2) the option SO_BINDTODEVICE is used to bind the socket to for example "eth0". I can't find this in the Erlang source code.) /Hans Nilsson From klacke@REDACTED Fri Nov 17 14:19:43 2000 From: klacke@REDACTED (Klacke) Date: Fri, 17 Nov 2000 14:19:43 +0100 Subject: sockets and multiple interfaces In-Reply-To: ; from hans@erix.ericsson.se on Fri, Nov 17, 2000 at 12:19:15PM +0100 References: Message-ID: <20001117141943.A2145@bluetail.com> On Fri, Nov 17, 2000 at 12:19:15PM +0100, Hans Nilsson wrote: > > How do I bind a socket to a certain interface in Erlang? > > (In C the function setsockopt(2) the option SO_BINDTODEVICE is used to > bind the socket to for example "eth0". I can't find this in the Erlang > source code.) > Option {ip, Ipddr} will bind the socket to the interface which has ipaddress IpAddr. I think we have some documentation to do regarding all the funky options which can be use set sockets in various modes. There's now a very large number of undocumented options and it's not trivial to read the code in order to find out what's existing. /klacke -- Claes Wikstrom -- Caps is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke -- From luke@REDACTED Fri Nov 17 15:53:45 2000 From: luke@REDACTED (Luke Gorrie) Date: 17 Nov 2000 15:53:45 +0100 Subject: distribution and funs Message-ID: Hi there, We're getting some emulator crashes triggered in the erlang distribution code, and the problem seems to be that we're trying to send a fun to a C program that uses erl_interface. In the function encode_size_struct2 of external.c, the emulator aborts if you try to encode a fun for a connection that doesn't have the DFLAG_FUN_TAGS flag, which erl_interface connections don't. I guess better behaviour would be to crash the erlang process instead. I don't know my way around the emulator code so I hereby chicken out and report it as a bug :-) You're probably wondering why we would want to send a fun to a C program :-) it's actually happening accidentally; we're sending the result of a 'catch', and are catching an {'EXIT', {badmatch, X}} where X contains a fun. Cheers, Luke From Chandrashekhar.Mullaparthi@REDACTED Fri Nov 17 17:08:22 2000 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Fri, 17 Nov 2000 16:08:22 -0000 Subject: bug in mnesia_frag.erl Message-ID: <402DD461F109D411977E0008C791C31202A7978D@imp02mbx.one2one.co.uk> Hi, There is a bug in mnesia_frag:all_keys/4 all_keys(ActivityId, Opaque, Tab, LockKind) -> Match = [mnesia:all_keys(ActivityId, Opaque, Frag, LockKind) || Frag <- frag_names(Tab)], lists:flatten(Match). This function returns incorrect results when the index into a table is a list. So if a table has entries with indices, [1], [2], [3], the above function returns [1,2,3] instead of [[1], [2], [3]]. The last line should be: lists:concat(Match). cheers, Chandru NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From matthias@REDACTED Fri Nov 17 20:54:42 2000 From: matthias@REDACTED (matthias@REDACTED) Date: Fri, 17 Nov 2000 20:54:42 +0100 (CET) Subject: The real reason why file:read_file in R7B guzzles memory In-Reply-To: <20001116144229E.mbj@bluetail.com> References: <20001116143247.B22214@bluetail.com> <20001116144229E.mbj@bluetail.com> Message-ID: <14869.36098.659229.611270@corelatus.com> Hi, Miguel Barreiro observed that file:read_file/1 seemed to be unexpectedly memory hungry. It has nothing to do with the history list, nor is it the natural consequence of printing. It's a bug in the io library. Matthias ---------------------------------------------------------------------- Reproducing the bug 1> {ok, Bin} = file:read_file("/usr/share/dict/words"), z. 2> io_lib:fwrite("~P", [Bin, 7]), z. 3> io_lib:fwrite("~P", [{ok, Bin}, 7]), z. line 3 takes an unreasonably long time and an unreasonable amount of memory, while line 2 does not. (So Martin is technically right when he says it's because we're printing the binary---though the real problem is that we're printing the _whole_ binary) Removing the bug One way is to change the clause in io_lib_pretty:write_length for binaries to write_length(Bin, D, Acc, Max) when binary(Bin) -> Acc; I'm not sure what the 'depth' rules are, but the result looks reasonable. The old clause was write_length(Bin, D, Acc, Max) when binary(Bin) -> Acc + length(io_lib:write(Bin)); This performs badly because it causes io_lib:write/1 to generate a list representing the whole binary. In R6 it performed ok because binaries were always written as a short string. From vladdu@REDACTED Sun Nov 19 00:05:36 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Sun, 19 Nov 2000 00:05:36 +0100 Subject: Java nodes Message-ID: Hi! hope you have/had a nice weekend! I have (finally! :-) fully connected a Java node to an Erlang one. I however wonder why the Java node doesn't appear in the nodes() list... regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From INTERFAC@REDACTED Sun Nov 19 03:01:27 2000 From: INTERFAC@REDACTED (INTERFAC) Date: Sun, 19 Nov 2000 03:01:27 +0100 (CET) Subject: newbie erlang programmer has a newbie problem.. :) Message-ID: <1613931685ea.1685ea161393@teleline.es> hi all, first of all, greetings to all people in the list, this is my first email.. What i'm trying is a very simple program, thought i cannot resolve, since i've just started with erlang. Its a tcp server that only has to tell to the clients that "you are user number X", and when there are 4 users connected, reject them with a message like: "there are finnaly 4 users, bye!". i have an initial code like this: -------------------------- -module (server). -export ([start/1,beginserver/1]). start(Port) -> spawn(server, beginserver, [Port]). beginserver(Port) -> {ok, Lsock} = gen_tcp:listen(Port, [binary, {packet, 0},{active, false},{backlog,4}]), serverloop(Lsock,1). serverloop(Lsock, Nuser) -> {ok, Sock} = gen_tcp:accept(Lsock), io:format ("welcome to SuperServer 0.0\nyou are user #~w\n", [Nuser]), serverloop(Lsock, Nuser+1). -------------- but doesnt works. Anyone could help me? thanks in advance, Diego Fernandez Spain ___________________________________________________________________ Consigue tu e-mail gratuito TERRA.ES Haz click en http://www.terra.es/correo/ From dgud@REDACTED Mon Nov 20 09:44:50 2000 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 20 Nov 2000 09:44:50 +0100 (MET) Subject: bug in mnesia_frag.erl In-Reply-To: <402DD461F109D411977E0008C791C31202A7978D@imp02mbx.one2one.co.uk> References: <402DD461F109D411977E0008C791C31202A7978D@imp02mbx.one2one.co.uk> Message-ID: <14872.58498.761931.864089@gargle.gargle.HOWL> Thanks, I'll take a look at it. /Dan Chandrashekhar Mullaparthi writes: > Hi, > > There is a bug in mnesia_frag:all_keys/4 > > all_keys(ActivityId, Opaque, Tab, LockKind) -> > Match = [mnesia:all_keys(ActivityId, Opaque, Frag, LockKind) > || Frag <- frag_names(Tab)], > lists:flatten(Match). > > This function returns incorrect results when the index into a table is a > list. So if a table has entries with indices, [1], [2], [3], the above > function returns [1,2,3] instead of [[1], [2], [3]]. > > The last line should be: > > lists:concat(Match). > > cheers, > Chandru From tobbe@REDACTED Mon Nov 20 09:39:58 2000 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 20 Nov 2000 09:39:58 +0100 Subject: Java nodes In-Reply-To: "Vlad Dumitrescu"'s message of "Sun, 19 Nov 2000 00:05:36 +0100" References: Message-ID: > I have (finally! :-) fully connected a Java node to an Erlang one. > I however wonder why the Java node doesn't appear in the nodes() > list... I'm not sure how it works with Java, but I imagine Java nodes are regarded in the same way as C-nodes, i.e as "hidden-nodes and thus doesn't show up in the nodes list. The reason for this is that several packages in OTP (I think: global, pg, ...) are relying on that all nodes in nodes/0 are Erlang ones. Cheers /Tobbe From etxuwig@REDACTED Mon Nov 20 10:40:05 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 20 Nov 2000 10:40:05 +0100 (MET) Subject: newbie erlang programmer has a newbie problem.. :) In-Reply-To: <1613931685ea.1685ea161393@teleline.es> Message-ID: Hi. It does seem to work as written, but you probably want to do something with the tcp connection as well. To run your program, I started two erlang shells: one to run server:start(8805), and one to run gen_tcp:connect({127,0,0,1},8805,[binary,{packet,0}]). In the first shell, the following output occurred: 1> server:start(8805). <0.85.0> welcome to SuperServer 0.0 you are user #1 Of course, this is all the program can do at the moment. Below is an example of your program extended to simply echo the caller's input: -module (server). -export ([start/1,beginserver/1]). -export([server/1]). start(Port) -> proc_lib:spawn_link(server, beginserver, [Port]). beginserver(Port) -> {ok, Lsock} = gen_tcp:listen(Port, [binary, {packet, 0}, {active, false}, {backlog, 4}]), accept_loop(Lsock,1). accept_loop(Lsock, Nuser) -> {ok, Sock} = gen_tcp:accept(Lsock), WelcomeStr = ["welcome to SuperServer 0.0\nyou are user #", integer_to_list(Nuser), "\n"], io:format (WelcomeStr), gen_tcp:send(Sock, WelcomeStr), Pid = proc_lib:spawn(server, server, [Sock]), gen_tcp:controlling_process(Sock, Pid), Pid ! continue, accept_loop(Lsock, Nuser+1). server(Sock) -> %% the 'continue' message is simply to make absolutely sure that %% this process can't enter serverloop before the call to %% controlling_process/2 receive continue -> serverloop(Sock) after 10000 -> exit(timeout) end. serverloop(Sock) -> case gen_tcp:recv(Sock, 0) of {ok, B} -> gen_tcp:send(Sock, ["you wrote: ", B]), serverloop(Sock); {error, closed} -> exit(normal) end. In my second shell, I get the following: 1> {ok,Sock} = gen_tcp:connect({127,0,0,1},8805,[binary,{packet,0}]). {ok,{socket,<0.51.0>,#Port<0.11>,inet_tcp}} 2> gen_tcp:send(Sock,"hello"). ok 3> receive {tcp,Sock,Bin} -> binary_to_list(Bin) after 0 -> nothing end. "you wrote: hello" 4> gen_tcp:send(Sock,"hello again"). ok 5> f(Bin),receive {tcp,Sock,Bin} -> binary_to_list(Bin) after 0 -> nothing end. "you wrote: hello again" On Sun, 19 Nov 2000, INTERFAC wrote: >hi all, > >first of all, greetings to all people in the list, this is my first >email.. > >What i'm trying is a very simple program, thought i cannot resolve, >since i've just started with erlang. Its a tcp server that only has to >tell to the clients that "you are user number X", and when there are 4 >users connected, reject them with a message like: "there are finnaly 4 >users, bye!". > >i have an initial code like this: >-------------------------- > >-module (server). >-export ([start/1,beginserver/1]). > >start(Port) -> > spawn(server, beginserver, [Port]). > >beginserver(Port) -> > {ok, Lsock} = gen_tcp:listen(Port, [binary, {packet, 0},{active, >false},{backlog,4}]), > serverloop(Lsock,1). > >serverloop(Lsock, Nuser) -> > {ok, Sock} = gen_tcp:accept(Lsock), > io:format ("welcome to SuperServer 0.0\nyou are user #~w\n", >[Nuser]), > serverloop(Lsock, Nuser+1). > >-------------- >but doesnt works. Anyone could help me? > >thanks in advance, >Diego Fernandez >Spain > > ___________________________________________________________________ >Consigue tu e-mail gratuito TERRA.ES > Haz click en http://www.terra.es/correo/ > > -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From klacke@REDACTED Mon Nov 20 10:40:38 2000 From: klacke@REDACTED (Klacke) Date: Mon, 20 Nov 2000 10:40:38 +0100 Subject: newbie erlang programmer has a newbie problem.. :) In-Reply-To: <1613931685ea.1685ea161393@teleline.es>; from INTERFAC@teleline.es on Sun, Nov 19, 2000 at 03:01:27AM +0100 References: <1613931685ea.1685ea161393@teleline.es> Message-ID: <20001120104038.A3839@bluetail.com> > > -module (server). > -export ([start/1,beginserver/1]). > > start(Port) -> > spawn(server, beginserver, [Port]). > > beginserver(Port) -> > {ok, Lsock} = gen_tcp:listen(Port, [binary, {packet, 0},{active, > false},{backlog,4}]), > serverloop(Lsock,1). > > serverloop(Lsock, Nuser) -> > {ok, Sock} = gen_tcp:accept(Lsock), > io:format ("welcome to SuperServer 0.0\nyou are user #~w\n", > [Nuser]), > serverloop(Lsock, Nuser+1). > > -------------- Looks just fine to me. /klacke -- Claes Wikstrom -- Caps is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke -- From rv@REDACTED Mon Nov 20 11:51:41 2000 From: rv@REDACTED (Robert Virding) Date: Mon, 20 Nov 2000 11:51:41 +0100 Subject: The real reason why file:read_file in R7B guzzles memory In-Reply-To: Your message of "Fri, 17 Nov 2000 20:54:42 +0100." <14869.36098.659229.611270@corelatus.com> Message-ID: <200011201051.LAA20639@trana.bluetail.com> matthias@REDACTED writes: >Hi, ... >Removing the bug > > One way is to change the clause in io_lib_pretty:write_length > for binaries to > > write_length(Bin, D, Acc, Max) when binary(Bin) -> > Acc; > > I'm not sure what the 'depth' rules are, but the result > looks reasonable. The old clause was > > write_length(Bin, D, Acc, Max) when binary(Bin) -> > Acc + length(io_lib:write(Bin)); > > This performs badly because it causes io_lib:write/1 to > generate a list representing the whole binary. In R6 it > performed ok because binaries were always written as a short > string. You have found the right place, but have misinterpreted the write_length/ 1 function. It must return the total length needed to write a thing but it also has the maximum allowed length included as an argument so that it can bail early. The calling function uses this length to determine if the the whole thing will fit on the current line or if it must be broken up into separate lines. %% write_length(Term, Depth, Accumulator, MaxLength) -> integer() %% Calculate the print length of a term, but exit when length becomes %% greater than MaxLength. By returning just the accumulator you have in fact stated that printing a binary takes zero characters, which is not quite correct. Try printing io:fwrite("~P", [{ok, Bin, 3}, 20]). to see the difference. A quick and dirty solution would be to claim that binaries always take lots of space and always fill up the available space: write_length(Bin, D, Acc, Max) when binary(Bin) -> Max; A better solution would probably be something like: write_length(Bin, D, Acc, Max) when binary(Bin) -> if D < 0 -> %Used to print all Acc + 4 + 4*size(Bin); true -> Acc + 4 + 4*(D+1) end; which is fast but accurate enough. The existing binary code is actually WRONG, which I can comfortably say having written everything except the binary stuff. :-) This is actually a general problem with formatted printing, you have to print it to know what it looks like before you know how to print it. Robert From mickael.remond@REDACTED Mon Nov 20 19:48:00 2000 From: mickael.remond@REDACTED (Mickael Remond) Date: 20 Nov 2000 19:48:00 +0100 Subject: Python in Erlang In-Reply-To: Alexis Le-Quoc's message of "Tue, 14 Nov 2000 11:30:36 -0500" References: <3A1119E5.700D5B41@bellsouth.net> <87lmumre02.fsf@western.ird.idealx.com> <3A1168AC.D1FBEA67@neomeocorp.com> Message-ID: <87pujqh44f.fsf@western.ird.idealx.com> On Tue, 14 Nov 2000, alexis@REDACTED wrote: > I've spent some time trying to build python_erlang and I can't say I > made any significant progress (granted I did not look into SWIG deep > enough). The problem I need to solve is to interface a python server > with some erlang code and I'm thinking of using sockets to work around > the difficulty of building the binding. If you've already written some > code to handle that and if you're willing to publish it, I think that's > great; I'm interested. Ok. The code cleaning and packaging is on the way... Stay tuned ! -- Micka?l R?mond - mickael.remond@REDACTED - http://IDEALX.com - +33 (1) 44 42 00 38 From mickael.remond@REDACTED Mon Nov 20 19:54:26 2000 From: mickael.remond@REDACTED (Mickael Remond) Date: 20 Nov 2000 19:54:26 +0100 Subject: Python in Erlang In-Reply-To: Steve Elkins's message of "Tue, 14 Nov 2000 20:35:46 -0500" References: <3A1119E5.700D5B41@bellsouth.net> <87lmumre02.fsf@western.ird.idealx.com> <3A11E872.AC373520@bellsouth.net> Message-ID: <87lmueh3tp.fsf@western.ird.idealx.com> On Tue, 14 Nov 2000, sgelkins@REDACTED wrote: > Thanks, I should have said that I knew about this. I have some users who > would like to use Python as their scripting language (everyone understands > OOP, or at thinks so), but the application cries out for Erlang: lots of > nodes, lots of threads per node, reliability a must, etc. So what I'm > considering is calling Python from Erlang to handle user scripting and > letting Erlang handle the rest. > >> Finally, we are just made a specific API to call our Erlang from Python via >> socket communication. This approach is working well for us. The datatype >> are very similar and are easy to map, so the datatype conversion is ok. > > And something in the opposite direction might work for us. I think the opposite is far less interesting because: - You can call os:command - You can use Erlang ports if you need to exchange data between apps. This approach maps perfectly with Erlang way of building apps (Message passing). In fact, the port could be wrapped into python classes to make it easier and almost transparent, but we don't need yet to call python code from Erlang. (Maybe the next step, who knows ?) -- Micka?l R?mond - mickael.remond@REDACTED - http://IDEALX.com - +33 (1) 44 42 00 38 From bauerd@REDACTED Mon Nov 20 22:20:51 2000 From: bauerd@REDACTED (David W. Bauer Jr.) Date: Mon, 20 Nov 2000 16:20:51 -0500 (EST) Subject: Java nodes In-Reply-To: Message-ID: >From the erlang jinterface website on class OtpEpmd: Provides methods for registering, unregistering and looking up nodes with the Erlang portmapper daemon (Epmd). For each registered node, Epmd maintains information about the port on which incoming connections are accepted, as well as which versions of the Erlang communication protocolt the node supports. Nodes wishing to contact other nodes must first request information from Epmd before a connection can be set up, however this is done automatically by OtpSelf.connect() when necessary. The methods publishPort() and unPublishPort() will fail if an Epmd process is not running on the localhost. Additionally lookupPort() will fail if there is no Epmd process running on the host where the specified node is running. See the Erlang documentation for information about starting Epmd. This class contains only static methods, there are no constructors. Hope this helps. David ~~~ ~~ ~~~~ _o URL: http://www.david-bauer.com ~~~ ~~~~ ~~ _'|<,_ ~~~~ ~~~ ~~~~ (*)/ (*) On Sun, 19 Nov 2000, Vlad Dumitrescu wrote: #Hi! #hope you have/had a nice weekend! # #I have (finally! :-) fully connected a Java node to an Erlang one. I however wonder why the Java node doesn't appear in the nodes() list... # #regards, #Vlad # From Chandrashekhar.Mullaparthi@REDACTED Tue Nov 21 13:33:06 2000 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Tue, 21 Nov 2000 12:33:06 -0000 Subject: Key iteration support for fragmented tables Message-ID: <402DD461F109D411977E0008C791C31202A79796@imp02mbx.one2one.co.uk> Hi, I need mnesia:dirty_first and mnesia:dirty_next for fragmented tables. Right now mnesia:first just looks in the first fragment and if that is empty returns '$end_of_table'. The same with mnesia:dirty_next. This can be easily extended to look in each fragment in case of a fragmented table - which I have done - but I dont think it will make any sense in a table of type ordered_set. Any comments, anyone?? So as not to affect performance for dirty_first and dirty_next on unfragmented tables, two separate functions frag_dirty_first and frag_dirty_next can be written. cheers, Chandru --------- dirty_first(Tab) when atom(Tab), Tab /= schema -> FP = mnesia:table_info(Tab, frag_properties), Frags = case lists:keysearch(n_fragments, 1, FP) of {value, {n_fragments, Frags_1}} -> lists:seq(2, Frags_1); _ -> [] end, TNames = [Tab]++[ list_to_atom(lists:flatten(io_lib:format("~p_frag~p", [Tab,X]))) || X <- Frags ], Fun = fun(X, '$end_of_table') -> dirty_rpc(X, mnesia_lib, db_first, [X]); (X, Acc) -> Acc end, lists:foldl(Fun, '$end_of_table', TNames); dirty_first(Tab) -> abort({bad_type, Tab}). dirty_next(Tab, Key) when atom(Tab), Tab /= schema -> FP = mnesia:table_info(Tab, frag_properties), Frags = case lists:keysearch(n_fragments, 1, FP) of {value, {n_fragments, Frags_1}} -> lists:seq(2, Frags_1); _ -> [] end, TNames = [Tab]++[ list_to_atom(lists:flatten(io_lib:format("~p_frag~p", [Tab,X]))) || X <- Frags ], Fun = fun(X, '$end_of_table') -> dirty_rpc(X, mnesia_lib, db_next_key, [X, Key]); (X, Acc) -> Acc end, lists:foldl(Fun, '$end_of_table', TNames); dirty_next(Tab, Key) -> abort({bad_type, Tab}). NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From radhia@REDACTED Tue Nov 21 16:10:21 2000 From: radhia@REDACTED (Radhia Cousot) Date: Tue, 21 Nov 2000 16:10:21 +0100 Subject: Static Analysis Symposium 2001, Paris : 1st CfP Message-ID: <3A1A905D.C3F8067E@lix.polytechnique.fr> -------------- next part -------------- ========My apologies for duplicates of this announcement========= ================================================================= = = = First Call For Papers = = = = 8th INTERNATIONAL STATIC ANALYSIS SYMPOSIUM = = = = = = La Sorbonne, Paris = = 16-18 July, 2001 = = = = http://www.ens.fr/sas01/ = = = ================================================================= Static Analysis is increasingly recognized as a fundamental technique for high performance implementations and verification systems of high-level programming languages. The series of Static Analysis Symposia has served as the primary venue for presentation of theoretical, practical and applicative in the area. The Eigth International Static Analysis Symposium (SAS2'01) will be held at La Sorbonne in Paris and followed immediately at La Mutualite by the Thirteenth Conference on Computer Aided Verification (CAV'01, http://www.lsv.ens-cachan.fr/cav01/}. Previous symposia were held in Santa Barbara, Venice, Pisa, Paris, Aachen, Glasgow and Namur. The technical program for SAS'01 will consist of invited lectures, tutorials, panels, presentations of refereed papers, and software demonstrations. Contributions are welcome on all aspects of Static Analysis, including, but not limited to abstract interpretation data flow analysis verification systems optimizing compilers abstract domains program specialization theoretical frameworks type inference abstract model checking complexity analysis abstract testing security analysis Submissions can address any programming paradigm, including concurrent, constraint, functional, imperative, logic and object-oriented programming. Survey papers that present some aspect of the above topics with a new coherence are also welcome. Submitted papers must not substantially overlap with papers that have been published or that are simultaneously submitted to a journal or a conference with a refereed proceedings. Submitted papers should be at most 15 single space 11-point font pages excluding bibliography and well-marked appendices. Program committee members are not required to read any appendices, and so a paper should be intelligible without them. The papers should be submitted as PostScript documents that are interpretable by Ghostscript and/or in PDF format, and they must be printable on both US letter and A4 paper; to facilitate this, extensive use of special fonts and colors should be avoided. Submissions should arrive by February 15, 2001. All submissions must be done electronically at http://www.ens.fr/sas01/. Authors will be notified of the acceptance or rejection of their papers by April 2, 2001. Final versions of the accepted papers must be received in electronic form by April 30, 2001. Important Dates: Submission: February 15, 2001. Notification: April 2, 2001. Final Version: April 30, 2001. Program Chair: Patrick Cousot Ecole Normale Superieure Departement d'Informatique 45, Rue d'Ulm 75230 Paris Cedex 05, France Email: sas01@REDACTED Phone: & + 33 1 44 32 20 64 Fax: & + 33 1 44 32 21 52 Program Committee: M. Bruynooghe (KU, Leuven) P. Cousot (ENS, Paris) G. Fil'e (Padova) M. Hagiya (Tokyo) C. Hankin (IC, London) L. Hendren (McGill, Montreal) M. Hermenegildo (UPM, Madrid) N. Jones (DIKU, Denmark) J. Larus (Microsoft, Redmond) J. Palsberg (Purdue) S. Sagiv (Tel Aviv) D. Sands (Chalmers, Goteborg) D. Schmidt (Kansas S.) M.L. Soffa (Pittsburgh) H. Sondergaard (Melbourne) R. Wilhelm (Saarbruken) K. Yi (KAIST, Taejon) General Chair: Radhia Cousot CNRS & Ecole polytechnique rcousot@REDACTED From etxuwig@REDACTED Wed Nov 22 10:50:51 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 22 Nov 2000 10:50:51 +0100 (MET) Subject: clarification on single assignment Message-ID: I read a paper on SAC (Single Assignment C): "Multiple assignments within a block are permitted, i.e. an identifier may be used more than once on the left-hand side of an assignment. This does not contradict the functional paradigm since multiple assignments are equivalent to nested (non-recursive) LET expressions. Thus, the scope of an identifier simply extends over the sequence of statements between two consecutive assignments to it. With this interpretation in mind, it is perfectly legitimate to call SAC a single assignment language. The Chuch Rosser property can nevertheless be guaranteed at the level of entire blocks if they are taken as basic units of strictly sequential computations." http://www.informatik.uni-kiel.de/~sacbase/papers/sac-overview-norwich-94.ps.gz I don't know exactly what all that means. I'm trying to figure out if its anything more than a cop-out. It did strike me, however, that if they were right (assuming the message is that SAC's version of single assignment is as good as anybody else's), it ought to work for Erlang too, since all Erlang functions are basic units of strictly sequential computations. Thus, we can reuse variable names in a function and lose nothing. It also opens up for wonderful operators like ++ (oops! we already have that) +=, =+ etc. ;) /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From mbj@REDACTED Wed Nov 22 11:05:06 2000 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 22 Nov 2000 11:05:06 +0100 Subject: clarification on single assignment In-Reply-To: Your message of "Wed, 22 Nov 2000 10:50:51 +0100 (MET)" References: Message-ID: <20001122110506C.mbj@bluetail.com> Ulf Wiger wrote: > > I read a paper on SAC (Single Assignment C): [...] > Thus, we can reuse variable names in a function and lose nothing. But Erlang doesn't even have assignment in the first place! '=' means match, which binds unbound variables. For example, A = 1, A = 2 % badmatch, or reassign? match is of course more powerful than assignment. So, you'd need to introduce an assignment operator. The compiler could translate it into a match, and also generate a new variable name each time: A := 1, A := 2 ===> A_0 = 1, A_1 = 2 Ugly indeed! Join the Non-Assignment Generation! /martin From etxuwig@REDACTED Wed Nov 22 11:05:53 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 22 Nov 2000 11:05:53 +0100 (MET) Subject: event-based XML parsing Message-ID: Down to more earthly matters, I've published a new version of xmerl, with an example of an event-based interface to the XML processor. It seems to work quite well for very large files. The example event-based parser is 122 lines of Erlang code (not counting the actual processor, which is 1971 LOC). The trick to parsing large XML files without using up lots of memory is an accumulator hook function which accumulates nothing: AccF = fun(X, Acc, S) -> {Acc, S} end, All the data is instead handled in a user-provided event hook function. The README.html file has much more documentation. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From etxuwig@REDACTED Wed Nov 22 11:17:46 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 22 Nov 2000 11:17:46 +0100 (MET) Subject: clarification on single assignment In-Reply-To: <20001122110506C.mbj@bluetail.com> Message-ID: On Wed, 22 Nov 2000, Martin Bjorklund wrote: >But Erlang doesn't even have assignment in the first place! '=' means >match, which binds unbound variables. For example, > A = 1, > A = 2 % badmatch, or reassign? > >match is of course more powerful than assignment. No argument from me, except that in the Erlang white paper, and in many other places, Erlang is described as a single-assignment language: "In contrast to, for example C variables, Erlang variables can only be assigned once - when a variable has been bound to a value, we cannot bind it to a new value." Following your line of reasoning, we should change this do something like: "In contrast to, for example C, Erlang does not have an assignment operator - variables are automatically bound via pattern matching. When a variable has been bound to a value, we cannot bind it to a new value." Or is that too confusing? /Uffe (who doesn't really need or want an assignment operator) -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From mbj@REDACTED Wed Nov 22 11:24:41 2000 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 22 Nov 2000 11:24:41 +0100 Subject: clarification on single assignment In-Reply-To: Your message of "Wed, 22 Nov 2000 11:17:46 +0100 (MET)" References: Message-ID: <20001122112441M.mbj@bluetail.com> Ulf Wiger wrote: > On Wed, 22 Nov 2000, Martin Bjorklund wrote: > "In contrast to, for example C variables, Erlang variables can only be > assigned once - when a variable has been bound to a value, we cannot > bind it to a new value." Call it want you want; my point was that if you want to implement what you suggested, an assignment operator, separate from match, is needed. /martin From rv@REDACTED Wed Nov 22 11:38:00 2000 From: rv@REDACTED (Robert Virding) Date: Wed, 22 Nov 2000 11:38:00 +0100 Subject: clarification on single assignment In-Reply-To: Your message of "Wed, 22 Nov 2000 10:50:51 +0100." Message-ID: <200011221038.LAA27789@trana.bluetail.com> Ulf Wiger writes: > >I read a paper on SAC (Single Assignment C): > >"Multiple assignments within a block are permitted, i.e. an identifier >may be used more than once on the left-hand side of an assignment. >This does not contradict the functional paradigm since multiple >assignments are equivalent to nested (non-recursive) LET expressions. >Thus, the scope of an identifier simply extends over the sequence of >statements between two consecutive assignments to it. With this >interpretation in mind, it is perfectly legitimate to call SAC a >single assignment language. The Chuch Rosser property can nevertheless >be guaranteed at the level of entire blocks if they are taken as basic >units of strictly sequential computations." > >http://www.informatik.uni-kiel.de/~sacbase/papers/sac-overview-norwich-94.ps.gz > >I don't know exactly what all that means. I'm trying to figure out if >its anything more than a cop-out. It did strike me, however, that if >they were right (assuming the message is that SAC's version of single >assignment is as good as anybody else's), it ought to work for Erlang >too, since all Erlang functions are basic units of strictly sequential >computations. No, it will not work in Erlang. The trouble is that Erlang has no variable scope and in SAC they relied on this to be able to call it single-assignment. So in SAC (whatever the syntax is): x = ; ; x = ; ; would have the same semantics as let x = in let x = in This works because of variable scoping. This also means that there are no problems with assigning variables in multiple branches. Of course, if you want we could always add proper variable scoping. :-) >Thus, we can reuse variable names in a function and lose nothing. >It also opens up for wonderful operators like ++ (oops! we already >have that) +=, =+ etc. ;) Robert From etxuwig@REDACTED Wed Nov 22 11:50:45 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 22 Nov 2000 11:50:45 +0100 (MET) Subject: clarification on single assignment In-Reply-To: <20001122112441M.mbj@bluetail.com> Message-ID: On Wed, 22 Nov 2000, Martin Bjorklund wrote: >Call it want you want; my point was that if you want to implement what >you suggested, an assignment operator, separate from match, is needed. My "suggestion" was a joke. I was mainly trying to figure out how the SAC people could get away with reassigning variables and still calling it "single-assignment", but I also wanted some comments on the notion that if SAC is right in claiming that they have single assignment, then calling Erlang a single-assignment language is confusing. I could have been clearer but that wouldn't have as much fun. You gave one answer: Erlang doesn't have assignment at all. Robert gave another: Erlang has single assignment without scoping. I prefer the "non-assignment" explanation, as it is easier to understand. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From sabry@REDACTED Wed Nov 22 17:10:27 2000 From: sabry@REDACTED (Amr Sabry) Date: Wed, 22 Nov 2000 11:10:27 -0500 Subject: Call for Participation (Continuations Workshop CW'01) Message-ID: <200011221610.LAA10554@dogfish.cs.indiana.edu> Call for Participation The Third ACM SIGPLAN Workshop on Continuations (CW'01) London, England, Jan. 16, 2001 Collocated with POPL '01 (Jan. 17, 2001 -- Jan. 19, 2001) http://www.cs.indiana.edu/~sabry/cw01/ The notion of continuations is ubiquitous in many different areas of computer science, including category theory, compilers, logic, operating systems, programming, and semantics. Following on the 1992 and 1997 ACM SIGPLAN Workshops on Continuations (http://www.brics.dk/~cw97/), we are organizing a new workshop to provide a forum for the presentation and discussion of new results and work in progress aimed at a better understanding of the nature of continuations, the relation of continuations to other areas of logic and computer science, and exciting new applications of continuations in contexts such as mobile threads, simulation, distributed systems, graphical user interfaces, and education. The workshop will include seven contributed papers and two invited talks. To register for the workshop, please go to the POPL 2001 web page. Prelimimary Programme: Session I: 9:00-10:15 Invited Speaker: Chris Wadsworth Session II: 10:30-12:00 Local CPS conversion in a direct-style compiler, John Reppy Interconnecting Between CPS Terms and Non-CPS Terms, Jung-taek Kim and Kwangkeun Yi Comparing Control Constructs by Typing Double-barrelled CPS Transforms, Hayo Thielecke 12:00-2:00 Lunch Session III: 2:00-3:15 Invited Speaker: TBA Session IV: 3:30-5:30 Towards Logical Understanding of Delimited Continuations, Yukiyoshi Kameyama CPS Transformation of Beta-Redexes, Olivier Danvy and Lasse R. Nielsen An Extensional CPS Transform, Andrzej Filinski The Affine Usage of Continuations, Josh Berdine, Peter W. O'Hearn, Hayo Thielecke From richardc@REDACTED Wed Nov 22 17:28:48 2000 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 22 Nov 2000 17:28:48 +0100 (MET) Subject: Core Erlang specification now stable Message-ID: The Core Erlang language specification and a set of basic tools can now be found at: http://www.csd.uu.se/projects/hipe/cerl/ There is currently work going on to make the core language representation used in the OTP/Erlang compiler (as of R7) conform to the specification, and also to make it possible to add user-defined program transformation passes on the Core Erlang level. /Richard Carlsson, The High-Performance Erlang Project Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From jim@REDACTED Wed Nov 22 20:07:54 2000 From: jim@REDACTED (Jim Larson) Date: Wed, 22 Nov 2000 11:07:54 -0800 Subject: clarification on single assignment In-Reply-To: Your message of "Wed, 22 Nov 2000 11:50:45 +0100." Message-ID: <200011221907.LAA51239@eme110-115.Sendmail.COM> In message you write: >On Wed, 22 Nov 2000, Martin Bjorklund wrote: > >>Call it want you want; my point was that if you want to implement what >>you suggested, an assignment operator, separate from match, is needed. > >My "suggestion" was a joke. I was mainly trying to figure out >how the SAC people could get away with reassigning variables and >still calling it "single-assignment", but I also wanted some comments >on the notion that if SAC is right in claiming that they have single >assignment, then calling Erlang a single-assignment language is >confusing. I could have been clearer but that wouldn't have as much >fun. In case someone takes your joke seriously, let me say that as an Erlang user, the annoyance of using versioned variables ("Var0", "Var1", ..., "VarN") is outweighed by the safety of having the compiler warn me about accidental reuse of variables. Note the limitations on what the SAC folks can do with renaming/rescoping. There's no way they can clean up the following: len = 0; while (getchar() != EOF) ++len; printf("standard input length is %d\n", len); since there's no static way to determine how many times the loop will run. Jim From matthias@REDACTED Wed Nov 22 20:43:13 2000 From: matthias@REDACTED (matthias@REDACTED) Date: Wed, 22 Nov 2000 20:43:13 +0100 (CET) Subject: problems with the emacs mode and the binary syntax Message-ID: <14876.8657.512496.257417@corelatus.com> Hi, I'd be eternally grateful (well...) if someone who actually understands how to write emacs modes told me how to fix the erlang mode so that it indents binaries correctly. Here are a couple of examples where it doesn't do what I expect: a() -> <<>>, bla. IMO, the 'bla' should be in the same column as the binary. Also, if I type b() -> <<>> and then hit ';', the electric stuff puts up '->' instead of 'b() ->'. Matthias From jamesh@REDACTED Wed Nov 22 20:42:43 2000 From: jamesh@REDACTED (James Hague) Date: Wed, 22 Nov 2000 13:42:43 -0600 Subject: clarification on single assignment Message-ID: <3.0.32.20001122134243.0102b200@volition-inc.com> Robert Virding wrote: >No, it will not work in Erlang. The trouble is that Erlang has no >variable scope and in SAC they relied on this to be able to call it >single-assignment. So in SAC (whatever the syntax is): > > x = ; > ; > x = ; > ; > >would have the same semantics as > let x = in > > let x = in > > >This works because of variable scoping. This also means that >there are no problems with assigning variables in multiple >branches. Forgetting about matching vs. assignment, wouldn't just defining "x = ;" as having the same semantics as "let x = in ..." be enough? In effect, each assignment starts a new variable scope. When does this fall down? James From happi@REDACTED Thu Nov 23 09:43:36 2000 From: happi@REDACTED (Erik (Happi) Johansson) Date: Thu, 23 Nov 2000 09:43:36 +0100 Subject: clarification on single assignment In-Reply-To: <3.0.32.20001122134243.0102b200@volition-inc.com> Message-ID: > Forgetting about matching vs. assignment, wouldn't just defining "x = > ;" as having the same semantics as "let x = in ..." be > enough? In effect, each assignment starts a new variable scope. > When does > this fall down? When you introduce the same var in different branches of a case or if: case Foo of 1 -> X = a; 2 -> X = b; _ -> X = c end, bar(X) This kind of use is discourage by the compiler but allowed and can be rewritten as: X = case Foo of 1 -> a; 2 -> b; _ -> c end, bar(X) But it gets hairier (but not impossible) when you introduce several variables in a case... /Erik From rv@REDACTED Thu Nov 23 10:02:19 2000 From: rv@REDACTED (Robert Virding) Date: Thu, 23 Nov 2000 10:02:19 +0100 Subject: clarification on single assignment In-Reply-To: Your message of "Wed, 22 Nov 2000 13:42:43 CST." <3.0.32.20001122134243.0102b200@volition-inc.com> Message-ID: <200011230902.KAA31165@trana.bluetail.com> James Hague writes: >Robert Virding wrote: > >Forgetting about matching vs. assignment, wouldn't just defining "x = >;" as having the same semantics as "let x = in ..." be >enough? In effect, each assignment starts a new variable scope. When does >this fall down? Apart from scopes you would also get problems when the "assignment" is really a match, for example: X = foo(), X = bar(), ... While it would be possible to say that the second match just rebinds X it would be incompatible with the matching today. Now I don't know how oftern people use this matching property, indeed the compiler warns about it just because it is uncommon and not what is commonly wanted, but it would probably break code, and in a very obscure manner. Anyway then you wouldn't get the easy access you have to old values "for free" as you do today. :-) Anyway without loops it really isn't that much of a pain. Robert From rv@REDACTED Thu Nov 23 12:00:56 2000 From: rv@REDACTED (Robert Virding) Date: Thu, 23 Nov 2000 12:00:56 +0100 Subject: clarification on single assignment In-Reply-To: Your message of "Thu, 23 Nov 2000 10:30:10 +0100." <14876.58274.706540.708271@corelatus.com> Message-ID: <200011231100.MAA31494@trana.bluetail.com> matthias@REDACTED writes: > > Martin> But Erlang doesn't even have assignment in the first > Martin> place! '=' means match, which binds unbound variables. > >The record syntax goes a long way towards implying assignment > > Variable#type{name = value} > >I don't see how that can be explained in terms of pattern >matching without digging into how it's actually implemented. > >Matthias > >(Not posted to the mailing list because I don't want to start a >discussion about records. There might still be people out there who >don't know about them ;-) I'll send my reply there so that they find out, also the the reply might be interesting. Anyway it's good with traffic in erlang-questions. What Variable#type{name = value} really means is, of course, create a new record of type #type which is a copy of Variable except for the field 'name' which has a new value. I will admit, however, that the syntax for record updates and matches in general does look a lot like assignments in most languages. I will also admit that most uses of match are for assignment, or at least a destructuring assignment, i.e. you pull the value apart and assign variable to parts of it. That is why the compiler warns. I personally don't miss being able to reassign variables, but that probably is dew to that I have not had it for so long that it is not something I think about. It is only important when it changes. Like on which side of the road you drive. Robert From daniel.neri@REDACTED Thu Nov 23 13:54:50 2000 From: daniel.neri@REDACTED (Daniel Neri) Date: 23 Nov 2000 13:54:50 +0100 Subject: problems with the emacs mode and the binary syntax In-Reply-To: matthias@corelatus.com's message of "Wed, 22 Nov 2000 20:43:13 +0100 (CET)" References: <14876.8657.512496.257417@corelatus.com> Message-ID: matthias@REDACTED writes: > I'd be eternally grateful (well...) if someone who actually > understands how to write emacs modes told me how to fix the erlang > mode so that it indents binaries correctly. The erlang-mode.el included in R7B (source) actually groks the bit syntax (I think this was mentioned at the EUC), but I noticed yesterday, when I tried the bit syntax myself for the first time, that the byte-compiled file seems to be left over from an older release. Try recompiling it (or simply remove the .elc file). Regards, --Daniel -- Daniel Neri mailto:dn@REDACTED Sigicom AB, Sweden http://www.sigicom.com From matthias@REDACTED Thu Nov 23 14:20:04 2000 From: matthias@REDACTED (matthias@REDACTED) Date: Thu, 23 Nov 2000 14:20:04 +0100 (CET) Subject: clarification on single assignment In-Reply-To: <200011231100.MAA31494@trana.bluetail.com> References: <14876.58274.706540.708271@corelatus.com> <200011231100.MAA31494@trana.bluetail.com> Message-ID: <14877.6532.166737.132320@corelatus.com> Martin> '=' means match, which binds unbound variables. Matthias>The record syntax goes a long way towards implying assignment Robert writes > I'll send my reply there [the mailing list] ... Anyway it's > good with traffic in erlang-questions. Syntax discussions seem to involve the same small group of people over and over again. I'd guess the rest aren't interested. > What > > Variable#type{name = value} > > really means is, of course, create a new record of type #type which is > a copy of Variable except for the field 'name' which has a new > value. The strange thing about pattern matching with records is that no pattern matching actually occurs unless you're already in the context of another pattern match. That leads me to wonder how the second '=' in an expression like A = B#type{name = value} % A unbound, B bound, for this example can be a pattern match. What are the operator's arguments? What is its precedence? Why* can I write Value = 3, B = #type{}, A = B#type{name = Value}. but not B = #type{name = 3}, A = B#type{name = Value}, Value. Pattern matching is supposed to bind unbound variables. If the second '=' really were a pattern matching operator, A would be the same as B, Value would be 3. Maybe it's "restricted pattern matching". Matthias * because the chapter on records doesn't say you can... From richardc@REDACTED Fri Nov 24 11:31:44 2000 From: richardc@REDACTED (Richard Carlsson) Date: Fri, 24 Nov 2000 11:31:44 +0100 (MET) Subject: clarification on single assignment In-Reply-To: <14877.6532.166737.132320@corelatus.com> Message-ID: On Thu, 23 Nov 2000 matthias@REDACTED wrote: > The strange thing about pattern matching with records is that no > pattern matching actually occurs unless you're already in the context > of another pattern match. Maybe you mean that the '=' in record field definitions should be read as the generic match operator? Then would it be less confusing if the syntax for records looked something like this?: A = B#type{name is value, foo is X, ...} In record field descriptors ` = ', the '=' is just a separator symbol, not an operator. It has no precedence, and does not need one, since `' must be an atom. > Why* can I write > > Value = 3, > B = #type{}, > A = B#type{name = Value}. > > but not > > B = #type{name = 3}, > A = B#type{name = Value}, > Value. > > Pattern matching is supposed to bind unbound variables. If the second > '=' really were a pattern matching operator, A would be the same as B, > Value would be 3. Maybe it's "restricted pattern matching". Because the expression `A = B#type{...}' is a "match expression", in which the left hand side is a pattern, and the right hand side is *any expression*. Here, the `=' is an operator which is left-associative and has a certain precedence compared to other infix operators. If the match expression regarded both sides as patterns (which can contain free variables, to become bound), it would constitute a *unification* operation, as found in Prolog, which has much more complicated semantics. For example, if in your expression: A = B#type{name = Value} both `A' and `Value' are allowed to be free variables, then what about: A = foo(Value) (where foo is some function)? Should we evaluate `foo' like a logic program would, passing it the *unbound* variable `Value'? No - this makes the behaviour of programs difficult to understand and adds a runtime cost. Erlang is a strict functional language for precisely the reason that this model is well understood, makes programs easier to understand and to predict the behaviour of, and can be efficiently implemented. However, the reader must be able to distinguish between patterns and expressions in the syntax. /Richard Carlsson Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From mbj@REDACTED Fri Nov 24 12:05:12 2000 From: mbj@REDACTED (Martin Bjorklund) Date: Fri, 24 Nov 2000 12:05:12 +0100 Subject: yecc bug Message-ID: <20001124120512K.mbj@bluetail.com> Here's a small fix to parsetools/include/yeccpre.hrl which creates better printouts for some parse errors: 95c95 < yecctoken2string({Cat, _, Val}) -> io_lib:format('~w', [Val]); --- > yecctoken2string({Cat, _, Val}) -> io_lib:format('~p', [Val]); [also, it looks like this code is duplicated into yeccparser.erl - that module should probably include yeccpre.hrl instead] So you don't have to see: ../c_src/reg_proto.x:204 : syntax error before: [115,117,98,115,99,114,101,115] /martin From rv@REDACTED Fri Nov 24 12:13:26 2000 From: rv@REDACTED (Robert Virding) Date: Fri, 24 Nov 2000 12:13:26 +0100 Subject: clarification on single assignment In-Reply-To: Your message of "Thu, 23 Nov 2000 14:20:04 +0100." <14877.6532.166737.132320@corelatus.com> Message-ID: <200011241113.MAA02351@trana.bluetail.com> matthias@REDACTED writes: > >The strange thing about pattern matching with records is that no >pattern matching actually occurs unless you're already in the context >of another pattern match. > >That leads me to wonder how the second '=' in an expression like > > A = B#type{name = value} % A unbound, B bound, for this example > >can be a pattern match. What are the operator's arguments? What is its >precedence? > >Why* can I write > > Value = 3, > B = #type{}, > A = B#type{name = Value}. > >but not > > B = #type{name = 3}, > A = B#type{name = Value}, > Value. > >Pattern matching is supposed to bind unbound variables. If the second >'=' really were a pattern matching operator, A would be the same as B, >Value would be 3. Maybe it's "restricted pattern matching". The syntax of '=', the match operator, is = and the semantics is that you FIRST evaluate the expression THEN you take the result of that evaluation and match the pattern against it. It is definitely not the same as '=', the unification operator, in logic languages. In Erlang there is also the restriction that a variable must have been bound to a value before it van be used. DON'T confuse the '=' in records with the match operator, all it does is couple a field name with a value/pattern. You could use any symbol there, for example B#type{name |-| 3} or, if you are really perverse, B#type{name should be coupled to 3}. So this means that in your last example what you are trying to do is: B = #type{name = 3}, Create a record of type #type where field 'name' has value 3 and bind B to the record. A = B#type{name = Value}, Create a copy of the value of B where field 'name' now has the value of the unbound variable Value. Value Return the value of the unbound variable Value. Which, of course, according to the rules does not work. The first example, of course, works because you bind the variables before you use them. It is actually described quite clearly in the Erlang book, pp 14, 21-22. This is in the public domain part. Records are described in the document "Erlang Extensions Since 4.4". Both are available from www.erlang.org in either PDF os PostScript formats. Robert From hakan@REDACTED Fri Nov 24 13:22:34 2000 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 24 Nov 2000 13:22:34 +0100 (MET) Subject: clarification on single assignment In-Reply-To: <200011241113.MAA02351@trana.bluetail.com> Message-ID: On Fri, 24 Nov 2000, Robert Virding wrote: rv> DON'T confuse the '=' in records with the match operator, all it does rv> is couple a field name with a value/pattern. You could use any rv> symbol there, for example B#type{name |-| 3} or, if you are really rv> perverse, B#type{name should be coupled to 3}. You mean as perverse as the spurious ';' separator? ;-) The semantics of the '=' operator depends of its context, but the '.' could not be reused as separator between function clauses!? rv> So this means that in your last example what you are trying to do is: rv> rv> B = #type{name = 3}, rv> Create a record of type #type where field 'name' has value 3 rv> and bind B to the record. rv> A = B#type{name = Value}, rv> Create a copy of the value of B where field 'name' now has the rv> value of the unbound variable Value. rv> Value rv> Return the value of the unbound variable Value. rv> rv> Which, of course, according to the rules does not work. The first rv> example, of course, works because you bind the variables before you use rv> them. Perverse or not, I think that the different semantics of the '=' operator in its various contexts (match/assign), is a little bit confusing. The bad example below does not work as you already pointed out, but both the ugly ones does. It is not intuitive. -module(equal). -compile(export_all). -record(type, {name}). good() -> Value = 3, B = #type{}, A = B#type{name = Value}. %% bad() -> %% B = #type{name = 3}, %% A = B#type{name = Value}, %% Value. ugly() -> B = #type{name = 3}, fun(A = #type{name = Value}) -> Value end(B). ugly2() -> B = #type{name = 3}, case B of A = #type{name = Value} -> Value end. /H?kan From vances@REDACTED Sat Nov 25 04:13:32 2000 From: vances@REDACTED (Vance Shipley) Date: Fri, 24 Nov 2000 22:13:32 -0500 Subject: dynamically loaded drivers in R7B Message-ID: I am putting together a dynamically linked and have seen some conflict between the documentation and the header file erl_driver.h. erl_driver.h: typedef struct erl_drv_entry { int (*init)(void); /* called at system start up for statically linked drivers, and after loading for dynamically loaded drivers */ ... That makes sense however the erl_ddll documentation says: The init function in struct driver_entry is not used anymore. After the driver is loaded, the function struct driver_entry *driver_init(void *) is called with handle as argument. If the operating system loader cannot find a function called driver_init, the driver will not be loaded. Now even to further muddy the waters erl_driver.h has: /* * This macro is used to name a dynamic driver's init function in * a way that doesn't lead to conflicts. This is crucial when using * operating systems that has one namespace for all symbols * (e.g. VxWorks). Example: if you have an dynamic driver C source * file named echo_drv.c, you use the macro like this: * * DRIVER_INIT(echo_drv) * { * .... * } * * This function well be called by the Erlang I/O system when the driver is load ed. * It must initialize a ErlDrvEntry structure and return a pointer to it. */ #if defined(VXWORKS) # define DRIVER_INIT(DRIVER_NAME) ErlDrvEntry* DRIVER_NAME ## _init(void) #elif defined(__WIN32__) # define DRIVER_INIT(DRIVER_NAME) __declspec(dllexport) ErlDrvEntry* driver_i nit(void) #else # define DRIVER_INIT(DRIVER_NAME) ErlDrvEntry* driver_init(void) #endif So which is it? What does myt function get named in my_drv.c and what value do I give my_drv_entry.init? -Vance From raimo@REDACTED Mon Nov 27 12:01:29 2000 From: raimo@REDACTED (Raimo Niskanen) Date: Mon, 27 Nov 2000 12:01:29 +0100 Subject: dynamically loaded drivers in R7B References: Message-ID: <3A223F09.A6C0B502@erix.ericsson.se> I have inserted some answers below. / Raimo Niskanen, Erlang/OTP Vance Shipley wrote: > > I am putting together a dynamically linked and have seen some conflict > between the documentation and the header file erl_driver.h. > > erl_driver.h: > > typedef struct erl_drv_entry { > int (*init)(void); /* called at system start up for statically > linked drivers, and after loading for > dynamically loaded drivers */ > ... > > That makes sense however the erl_ddll documentation says: > > The init function in struct driver_entry is not used anymore. After the driver > is loaded, the function struct driver_entry *driver_init(void *) is called with > handle as argument. If the operating system loader cannot find a function called > driver_init, the driver will not be loaded. > Well, the text should say that the init function in struct driver_entry is not _needed_ anymore. It it _is_, however, called, so there are two functions for the same purpose - confusion. Alas! I am sorry. For statically linked drivers only the struct driver_entry init function is called, and for dynamically linked drivers both are called. Since it is tricky to get a statically linked driver into the runtime system, this matter may be of small importance. > Now even to further muddy the waters erl_driver.h has: > > /* > * This macro is used to name a dynamic driver's init function in > * a way that doesn't lead to conflicts. This is crucial when using > * operating systems that has one namespace for all symbols > * (e.g. VxWorks). Example: if you have an dynamic driver C source > * file named echo_drv.c, you use the macro like this: > * > * DRIVER_INIT(echo_drv) > * { > * .... > * } > * > * This function well be called by the Erlang I/O system when the driver is load > ed. > * It must initialize a ErlDrvEntry structure and return a pointer to it. > */ > > #if defined(VXWORKS) > # define DRIVER_INIT(DRIVER_NAME) ErlDrvEntry* DRIVER_NAME ## _init(void) > #elif defined(__WIN32__) > # define DRIVER_INIT(DRIVER_NAME) __declspec(dllexport) ErlDrvEntry* driver_i > nit(void) > #else > # define DRIVER_INIT(DRIVER_NAME) ErlDrvEntry* driver_init(void) > #endif > > So which is it? What does myt function get named in my_drv.c and what > value do I give my_drv_entry.init? > > -Vance If I dare guess You do not compile for VxWorks then Your init function will be named driver_init. In the event I am wrong, it will be named my_drv_init. In R7, it is allowed (i reccon) to set my_drv_entry.init to NULL, and it will not be called be skipped. This was not allowed earlier, since setting my_drv_entry.init to a function that does nothing is not hard. The important is that driver_init must return the address to Your initialized struct my_drv_entry. From etxuwig@REDACTED Mon Nov 27 12:48:51 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 27 Nov 2000 12:48:51 +0100 (MET) Subject: threads - use them as much as you can Message-ID: I can't resist - reading about Java and Swing, I came across the following passage: "The first rule of using threads is this: avoid them if you can. Threads can be difficult to use, and they tend to make programs harder to debug. To avoid the possibility of deadlock, you must take extreme care that any threads you create don't invoke any methods on Swing components." http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html This is certainly in stark contrast with the Erlang adage: "Use one parallel process to model each truly concurrent activity in the real world" http://www.erlang.se/doc/programming_rules.shtml#REF34191 Perhaps a bit more should be made of this...? (: /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From sam@REDACTED Mon Nov 27 13:11:33 2000 From: sam@REDACTED (Samuel Tardieu) Date: Mon, 27 Nov 2000 13:11:33 +0100 Subject: threads - use them as much as you can In-Reply-To: ; from etxuwig@etxb.ericsson.se on Mon, Nov 27, 2000 at 12:48:51PM +0100 References: Message-ID: <2000-11-27-13-11-33+trackit+sam@inf.enst.fr> On 27/11, Ulf Wiger wrote: | Perhaps a bit more should be made of this...? (: Mmm, tempting but not as easy as it looks like: Erlang processes are really processes (no memory shared with other processes), while Java threads are really threads (one of them can change a bit of memory that another thread is using). From thomasl@REDACTED Mon Nov 27 14:31:16 2000 From: thomasl@REDACTED (Thomas Lindgren) Date: Mon, 27 Nov 2000 14:31:16 +0100 Subject: threads - use them as much as you can In-Reply-To: <2000-11-27-13-11-33+trackit+sam@inf.enst.fr> (message from Samuel Tardieu on Mon, 27 Nov 2000 13:11:33 +0100) References: <2000-11-27-13-11-33+trackit+sam@inf.enst.fr> Message-ID: <200011271331.OAA01420@lammgam.bluetail.com> > Mmm, tempting but not as easy as it looks like: Erlang processes are really > processes (no memory shared with other processes), while Java threads > are really threads (one of them can change a bit of memory that another > thread is using). An Erlang process need not be an OS process or even a thread. We must distinguish language-level processes from OS-level processes. A thread is often considered a light-weight process (i.e., cheap to create, schedule or destroy) enclosed by an operating system process, which handles resource management, access control, address space mapping, etc. We can call this the "administrative" view. (Note that two OS processes often can share memory using various forms of trickery, e.g., with shmem() or mmap(), so shared-memory == thread vs message-passing == process is not a valid categorization.) Erlang/OTP uses something simpler than the administrative view. In the current Erlang/OTP implementation, an Erlang process is simply a record with pointers to the memory allocated by the process (heap, stack, ...). When an Erlang process is scheduled to run, the runtime system loads the appropriate data and jumps to the indicated function. When the Erlang process yields (by hanging in 'receive' or by its time slice/reduction-counter going to zero), the process information is stored back in the record again whereafter a new process record is selected to run. Note that the running process is not interrupted, but may yield gracefully at some well-known points in the code. Thus, an Erlang/OTP node runs entirely _sequentially_, but multiplexes Erlang processes internally. To the user, this seems like concurrent execution. The disadvantage of this solution is that it does not transparently exploit SMP. However, you can overcome that by running several Erlang nodes on a single SMP host, communicating using distributed Erlang or perhaps sockets. Furthermore, there are efficiency advantages to the current model. First, since scheduling occurs only at safe points, there is no need to protect updates to shared data with locks. Second, since Erlang does not permit messing around with the stack, there is no need to allocate huge areas per thread for stack space. (The latter is an advantage of the language, rather than the implementation.) Erlang/OTP processes are thus in fact even cheaper than OS-level threads, or Java threads. Not to mention more convenient than either. Thomas -- Thomas Lindgren thomasl+junk@REDACTED Alteon WebSystems http://www.bluetail.com From etxuwig@REDACTED Mon Nov 27 14:55:35 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 27 Nov 2000 14:55:35 +0100 (MET) Subject: threads - use them as much as you can In-Reply-To: <2000-11-27-13-11-33+trackit+sam@inf.enst.fr> Message-ID: On Mon, 27 Nov 2000, Samuel Tardieu wrote: >On 27/11, Ulf Wiger wrote: > >| Perhaps a bit more should be made of this...? (: > >Mmm, tempting but not as easy as it looks like: Erlang processes are >really processes (no memory shared with other processes), while Java >threads are really threads (one of them can change a bit of memory >that another thread is using). Well, what I meant was that it's perhaps not made clear enough that handling concurrency in Erlang is so much simpler than in, say, Java, that people simply don't believe you when you try to explain it. Whether Erlang processes are implemented as OS threads (it has been done experimentally) or in a VM is beside the point. The point is that the user doesn't have to care, and concurrency is incredibly much easier to handle in Erlang than in Java. I dug up some quotes from comp.lang.functional: "Definitely. But I think one should not forget that any productivity measures done by Ericsson must be put in context: Ericsson develops telephone switches and Erlang is a language specifically designed for highly concurrent/distribute applications (in fact, playing with Erlang gives you the impression that concurrent programming becomes a kid's game) I really beleive that a fair share of Ericsson's productivity gains for Erlang-based software parts origine from its superb concurrency features." (Simon Helsen) http://x69.deja.com/getdoc.xp?AN=645013883&CONTEXT=975330549.164626482&hitnum=0 "Personally I think that Erlang is successful because of the concurrency etc. and *not* because of any connection to FP." (Joe Armstrong) http://x69.deja.com/getdoc.xp?AN=546370696&CONTEXT=975330549.164626482&hitnum=5 "It is interesting to note that the properties of the Erlang have been found to be very suitable for many types of applications. Concurrency is so powerful it is surprising that other functional languages have been so slow to catch on. Yes, I know that there other concurrent functional languages, but not the big ones." (Robert Virding) http://x69.deja.com/getdoc.xp?AN=546393082&CONTEXT=975330549.164626482&hitnum=21 What I'm trying to get at is that we may not be making the point strongly enough that the CSP paradigm that Erlang uses is an extremely powerful model for building complex applications, and that as soon as you must support concurrency in your application, Erlang leaves languages like Java in the dust. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From sam@REDACTED Mon Nov 27 15:18:15 2000 From: sam@REDACTED (Samuel Tardieu) Date: Mon, 27 Nov 2000 15:18:15 +0100 Subject: threads - use them as much as you can In-Reply-To: ; from etxuwig@etxb.ericsson.se on Mon, Nov 27, 2000 at 02:55:35PM +0100 References: <2000-11-27-13-11-33+trackit+sam@inf.enst.fr> Message-ID: <2000-11-27-15-18-15+trackit+sam@inf.enst.fr> On 27/11, Ulf Wiger wrote: | Well, what I meant was that it's perhaps not made clear enough that | handling concurrency in Erlang is so much simpler than in, say, Java, | that people simply don't believe you when you try to explain it. | Whether Erlang processes are implemented as OS threads (it has been | done experimentally) or in a VM is beside the point. The point is that | the user doesn't have to care, and concurrency is incredibly much | easier to handle in Erlang than in Java. I agree with you and Thomas (I know that Erlang processes are not OS processes, thanks :-), but the strong point are IMO: - absence of global variables - mailboxes between processes Sam From thomasl@REDACTED Mon Nov 27 15:46:01 2000 From: thomasl@REDACTED (Thomas Lindgren) Date: Mon, 27 Nov 2000 15:46:01 +0100 Subject: threads - use them as much as you can In-Reply-To: <2000-11-27-15-18-15+trackit+sam@inf.enst.fr> (message from Samuel Tardieu on Mon, 27 Nov 2000 15:18:15 +0100) References: <2000-11-27-13-11-33+trackit+sam@inf.enst.fr> <2000-11-27-15-18-15+trackit+sam@inf.enst.fr> Message-ID: <200011271446.PAA01722@lammgam.bluetail.com> > I agree with you and Thomas (I know that Erlang processes are not OS > processes, thanks :-), ... Just providing some ammo, then :-) As for global variables, I have two words: Ets. Tables. Thomas -- Thomas Lindgren thomasl+junk@REDACTED Alteon WebSystems http://www.bluetail.com From tony@REDACTED Mon Nov 27 17:01:43 2000 From: tony@REDACTED (Tony Rogvall) Date: Mon, 27 Nov 2000 17:01:43 +0100 Subject: sockets and multiple interfaces References: <20001117141943.A2145@bluetail.com> Message-ID: <3A228566.4BBC0998@bluetail.com> Klacke wrote: > On Fri, Nov 17, 2000 at 12:19:15PM +0100, Hans Nilsson wrote: > > > > How do I bind a socket to a certain interface in Erlang? > > > > (In C the function setsockopt(2) the option SO_BINDTODEVICE is used to > > bind the socket to for example "eth0". I can't find this in the Erlang > > source code.) > > > > Option {ip, Ipddr} will bind the socket to the > interface which has ipaddress IpAddr. > Use the new name {ifaddr, Ipaddr} instead !!! -- /Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: tony.vcf Type: text/x-vcard Size: 333 bytes Desc: Card for Tony Rogvall URL: From Sean.Hinde@REDACTED Mon Nov 27 16:24:08 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 27 Nov 2000 15:24:08 -0000 Subject: threads - use them as much as you can Message-ID: <402DD461F109D411977E0008C791C3125653BF@imp02mbx.one2one.co.uk> > | Well, what I meant was that it's perhaps not made clear enough that > | handling concurrency in Erlang is so much simpler than in, > say, Java, Has anyone looked at the Real Time Java specs? They introduce asynch message passing, mailboxes, proper timers, nice close down of threads without deadlock (Gee!) and fix the garbage collector. Sun seem to be very keen to get into the telecoms space for 3rd Generation mobile services with their JAIN initiative, and Real time java is part of that. http://java.sun.com/aboutJava/communityprocess/jsr/jsr_001_real_time.html It looks to be the ammo the Java proponents need.. Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From Sean.Hinde@REDACTED Mon Nov 27 16:24:38 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 27 Nov 2000 15:24:38 -0000 Subject: threads - use them as much as you can Message-ID: <402DD461F109D411977E0008C791C3125653C0@imp02mbx.one2one.co.uk> > -----Original Message----- > From: Thomas Lindgren [mailto:thomasl@REDACTED] > Sent: 27 November 2000 14:46 > To: sam@REDACTED > Cc: etxuwig@REDACTED; erlang-questions@REDACTED > Subject: Re: threads - use them as much as you can > > As for global variables, I have two words: Ets. Tables. > While we are talking ets... I'm looking at an app which needs to store big chunks of data for a short period before forwarding them on. There is a choice between some tuple list structure to keep track of several of these blobs and dig them out when they need to be sent, or ets. Ets involves data copying so is non optimal. Lookup within a keyed tuple list is slow for many entries. What I need is hashed lookup without data copying of 'tuple lists'.. Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From jamesh@REDACTED Mon Nov 27 16:36:28 2000 From: jamesh@REDACTED (James Hague) Date: Mon, 27 Nov 2000 09:36:28 -0600 Subject: threads - use them as much as you can Message-ID: <3.0.32.20001127093627.0102bdd8@volition-inc.com> I see the Java warning as more along the lines of "don't use threads when you don't really need them" more than "don't ever use threads." For example, if you were writing code to process user input for a window full of controls, you could: 1. Model each control as a thread/process. 2. Don't use threads and simply scan through a list of controls when input is detected. There's a certain prettiness to #1, but if the controls don't really operate in an asynchronous manner, then #2 is perfectly valid and simpler in most languages. I think that Erlang comes into its own when you have an application that's similar to an operating system, with tasks starting and stopping constantly, each doing something fairly independent of the rest of the tasks. A web server is a good example, as are telephone exchanges. In the window example above, there aren't lots of independently executing tasks, but rather a collection of object-like entities where the benefit of separation into processes is one of dividing a large global state into smaller, more clearly defined spaces. But it isn't clear that processes offer much over objects in this case, especially as processes have more ovehead (message passing vs. subroutine calls). I expect that most Java progammers who use threads are using a only handful of threads, possibly only two. The exceptions are those unfortunate Java programmers trying to write web servers and such :) James From richardc@REDACTED Mon Nov 27 16:36:54 2000 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 27 Nov 2000 16:36:54 +0100 (MET) Subject: storing big chunks of data In-Reply-To: <402DD461F109D411977E0008C791C3125653C0@imp02mbx.one2one.co.uk> Message-ID: > While we are talking ets... I'm looking at an app which needs to store big > chunks of data for a short period before forwarding them on. There is a > choice between some tuple list structure to keep track of several of these > blobs and dig them out when they need to be sent, or ets. > > Ets involves data copying so is non optimal. Lookup within a keyed tuple > list is slow for many entries. > > What I need is hashed lookup without data copying of 'tuple lists'.. Try GB trees (http://www.erlang.org/user.html#gb_trees-1.1). /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From etxuwig@REDACTED Mon Nov 27 16:38:28 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 27 Nov 2000 16:38:28 +0100 (MET) Subject: threads - use them as much as you can In-Reply-To: <402DD461F109D411977E0008C791C3125653C0@imp02mbx.one2one.co.uk> Message-ID: Sean, You should try the different user contributions on www.erlang.org. There is also an erlang implementation of linear hashing (I haven't released mine as Open Source, partly because I thought Robert would release his first). My linear hashing implementation uses the dynarray-1.0 structure for fast read/write of tuple trees. My benchmarking indicates that you can beat ets with an erlang-based hash table if your objects are large enough (say > 1KByte). If you want to try the linear hashing program, I can send it to you. /Uffe On Mon, 27 Nov 2000, Sean Hinde wrote: > > >> -----Original Message----- >> From: Thomas Lindgren [mailto:thomasl@REDACTED] >> Sent: 27 November 2000 14:46 >> To: sam@REDACTED >> Cc: etxuwig@REDACTED; erlang-questions@REDACTED >> Subject: Re: threads - use them as much as you can >> >> As for global variables, I have two words: Ets. Tables. >> > >While we are talking ets... I'm looking at an app which needs to store big >chunks of data for a short period before forwarding them on. There is a >choice between some tuple list structure to keep track of several of these >blobs and dig them out when they need to be sent, or ets. > >Ets involves data copying so is non optimal. Lookup within a keyed tuple >list is slow for many entries. > >What I need is hashed lookup without data copying of 'tuple lists'.. > >Sean > > > >NOTICE AND DISCLAIMER: >This email (including attachments) is confidential. If you have received >this email in error please notify the sender immediately and delete this >email from your system without copying or disseminating it or placing any >reliance upon its contents. We cannot accept liability for any breaches of >confidence arising through use of email. Any opinions expressed in this >email (including attachments) are those of the author and do not necessarily >reflect our opinions. We will not accept responsibility for any commitments >made by our employees outside the scope of our business. We do not warrant >the accuracy or completeness of such information. > > -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From bjorn@REDACTED Mon Nov 27 16:45:39 2000 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 27 Nov 2000 16:45:39 +0100 Subject: threads - use them as much as you can In-Reply-To: Ulf Wiger's message of "Mon, 27 Nov 2000 16:38:28 +0100 (MET)" References: Message-ID: Ulf Wiger writes: > Sean, > > You should try the different user contributions on www.erlang.org. > There is also an erlang implementation of linear hashing (I haven't > released mine as Open Source, partly because I thought Robert would > release his first). My linear hashing implementation uses the > dynarray-1.0 structure for fast read/write of tuple trees. The dict and sets modules in R7 use linear hashing. /Bj?rn -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From sam@REDACTED Mon Nov 27 17:13:04 2000 From: sam@REDACTED (Samuel Tardieu) Date: Mon, 27 Nov 2000 17:13:04 +0100 Subject: threads - use them as much as you can In-Reply-To: <200011271446.PAA01722@lammgam.bluetail.com>; from thomasl@bluetail.com on Mon, Nov 27, 2000 at 03:46:01PM +0100 References: <2000-11-27-13-11-33+trackit+sam@inf.enst.fr> <2000-11-27-15-18-15+trackit+sam@inf.enst.fr> <200011271446.PAA01722@lammgam.bluetail.com> Message-ID: <2000-11-27-17-13-04+trackit+sam@inf.enst.fr> On 27/11, Thomas Lindgren wrote: | As for global variables, I have two words: Ets. Tables. Yup, which are clean as far as concurrent access is concerned. Java is not. From thomasl@REDACTED Mon Nov 27 17:28:12 2000 From: thomasl@REDACTED (Thomas Lindgren) Date: Mon, 27 Nov 2000 17:28:12 +0100 Subject: threads - use them as much as you can In-Reply-To: <2000-11-27-17-13-04+trackit+sam@inf.enst.fr> (message from Samuel Tardieu on Mon, 27 Nov 2000 17:13:04 +0100) References: <2000-11-27-13-11-33+trackit+sam@inf.enst.fr> <2000-11-27-15-18-15+trackit+sam@inf.enst.fr> <200011271446.PAA01722@lammgam.bluetail.com> <2000-11-27-17-13-04+trackit+sam@inf.enst.fr> Message-ID: <200011271628.RAA02085@lammgam.bluetail.com> > | As for global variables, I have two words: Ets. Tables. > > Yup, which are clean as far as concurrent access is concerned. Java is not. Well, to a limited extent. Most individual operations (insert, lookup, update_counter, ...) appear to be atomic, which is good. On the other hand, the ets man page for R7B states "This module provides very limited support for concurrent updates." It then explains safe_fixtable, and tells us to use mnesia if locking or transactions are required. The problem appears to be first/next. A related problem is how to construct a simple, guaranteed read-modify-write function on a (public) ets-table, even involving a single location. Is there some way to do that in Erlang without involving mnesia? (Needless to say, I've fiddled a bit with this and failed.) Thomas -- Thomas Lindgren thomasl+junk@REDACTED Alteon WebSystems http://www.bluetail.com From etxuwig@REDACTED Mon Nov 27 17:33:49 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 27 Nov 2000 17:33:49 +0100 (MET) Subject: threads - use them as much as you can In-Reply-To: <402DD461F109D411977E0008C791C3125653BF@imp02mbx.one2one.co.uk> Message-ID: On Mon, 27 Nov 2000, Sean Hinde wrote: >http://java.sun.com/aboutJava/communityprocess/jsr/jsr_001_real_time.html > >It looks to be the ammo the Java proponents need.. I must say that a first quick glance at the document triggered the same reaction that I've had from day 1 with Java: "Yawn". (Which doesn't really help me now that I am honestly trying to get into Java programming for GUIs.) Seriously, though (even though it _was_ a serious yawn), the makers of Java got concurrency wrong from the start. Trying to fix it later while maintaining backward compatibility is going to be a real challenge. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From etxuwig@REDACTED Mon Nov 27 17:41:21 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 27 Nov 2000 17:41:21 +0100 (MET) Subject: threads - use them as much as you can In-Reply-To: <200011271628.RAA02085@lammgam.bluetail.com> Message-ID: On Mon, 27 Nov 2000, Thomas Lindgren wrote: >A related problem is how to construct a simple, guaranteed read-modify-write >function on a (public) ets-table, even involving a single location. >Is there some way to do that in Erlang without involving mnesia? >(Needless to say, I've fiddled a bit with this and failed.) We've suggested a simple mutex lock on the ets table, such that ets:mutex(Table, F = fun()) is thread safe, assuming that all accesses to Table are mutex:ed. One use for this would be implementing modulo counters based on ets:update_counter/3. A problem of course arises if F doesn't stick to one table. Then you get into deadlock territory. If you didn't allow nested mutex:es, you'd be a bit better off. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From Timo.Weiss@REDACTED Mon Nov 27 19:08:34 2000 From: Timo.Weiss@REDACTED (Timo Weiss) Date: Mon, 27 Nov 2000 19:08:34 +0100 Subject: No subject Message-ID: <9D494CF815CE9E489A73D536CC3525081F32EF@mailer1.solutions.local> I'm going to realice a project to configure a Ericsson-WAP-Phones over SMS. Can you help me with documentations, also from the pdu? Thanx for help ! Timo Weiss KOMSA SOLUTIONS GMBH Niederfrohnaer Weg 1 09232 Hartmannsdorf Tel: +49 (0)3722 713 96 738 Internet: http://komsa-solutions.com eMail: timo.weiss@REDACTED +++ Ein Unternehmen der KomSa Gruppe +++ From Sean.Hinde@REDACTED Mon Nov 27 20:50:27 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 27 Nov 2000 19:50:27 -0000 Subject: threads - use them as much as you can Message-ID: <402DD461F109D411977E0008C791C3125653C1@imp02mbx.one2one.co.uk> Uffe, >(Which doesn't really help me now that I am honestly trying to get >into Java programming for GUIs.) I sympathise. It looks like Ericsson's new "Service Creation Environment" for Intelligent Networks will require us to write service logic in Java (there's no GUI!). Also the JAIN initiative from Sun seems likely to adopted by the 3gpp standards group as their standard service creation API. You never know, by next year I may be trying to peddle the old "non programmer" writes IN service in Java myth :-) (Actually - no, never again!). >Seriously, though (even though it _was_ a serious yawn), the makers of >Java got concurrency wrong from the start. Trying to fix it later >while maintaining backward compatibility is going to be a real >challenge. Agreed, but there appears to be a serious amount of will power and resourcing behind this. At the moment attempting to write anything asynchronous and multithreaded seems to be extremely painful because the Java language and runtime provide only hindrance. If the platform is fixed sufficiently to allow "normal" Java programmers to do this stuff safely then maybe it will become the platform of choice for "responsive" non blocking clients and servers..? They have also included some things Erlang doesn't have which the "Hard Real Time" crew use including: * Many thread priorities with timely pre-emption when higher priority threads become runnable (e.g. by receiving an async message). * The ability to set a maximum possible runtime to be used by a thread before the system kills it and notifies the initiator. There might even be something we can learn from their work ;) - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From bauerd@REDACTED Mon Nov 27 21:18:09 2000 From: bauerd@REDACTED (David W. Bauer Jr.) Date: Mon, 27 Nov 2000 15:18:09 -0500 (EST) Subject: threads - use them as much as you can In-Reply-To: Message-ID: I wish I had gotten on this thread sooner.. I find that most people should stay away from threads in general because in order to use them you have to determine areas where parallelism can be exploited. If you cannot do that well, then you will really derive no benefit from them. Erlang tries to make this easier, however is dangerous because of the way the concurrency works. For example, many processes trying to work with a single process can be very harmful to performance. One nice thing about Erlang is that it allows for many more processes than most OS limits (which I think is about 64K for most before the fork bomb). David ~~~ ~~ ~~~~ _o URL: http://www.david-bauer.com ~~~ ~~~~ ~~ _'|<,_ ~~~~ ~~~ ~~~~ (*)/ (*) From etxuwig@REDACTED Mon Nov 27 22:22:20 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 27 Nov 2000 22:22:20 +0100 (MET) Subject: threads - use them as much as you can In-Reply-To: <402DD461F109D411977E0008C791C3125653C1@imp02mbx.one2one.co.uk> Message-ID: On Mon, 27 Nov 2000, Sean Hinde wrote: >They have also included some things Erlang doesn't have which the "Hard Real >Time" crew use including: > >* Many thread priorities with timely pre-emption when higher priority >threads become runnable (e.g. by receiving an async message). Yes, I was intrigued by the idea of immediate preemption for high-priority threads. This might be handy. As for many thread priority levels, I remain unconvinced. In AXD 301, we've settled on job scheduling/prioritization. Basically, programmers get to decide what consitutes a job, or a work unit. We have a simple but efficient job scheduler which implements a weighted round robin on a configurable number of job queues. Perhaps the reason why this works so well for us is that a switch is very much job based - as is e.g. a web server. It really doesn't matter how many threads are involved in the completion of a task: when a job has been accepted by the system, it needs to be finished in a timely manner; a job that cannot be accepted should be rejected as soon as possible. Using this scheme, we've achieved absolutely remarkable load tolerance figures: our system can operate at 95% throughput even at 150% load, and yields 40% throughput at 1000% load!! Regarding process priorities, we keep it very simple. Just about all processes operate at normal priority. Processes that act as message dispatchers are set to high priority, since they do not create any work themselves, but rather act as drivers. We don't use low priority at all, partly because we've found that if you have hundreds of normal priority processes and only a few low priority processes, the low priority processes will actually get higher priority than the normal priority processes. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From maurice@REDACTED Mon Nov 27 22:54:36 2000 From: maurice@REDACTED (Maurice Castro) Date: Tue, 28 Nov 2000 08:54:36 +1100 (EST) Subject: threads - use them as much as you can In-Reply-To: <402DD461F109D411977E0008C791C3125653C1@imp02mbx.one2one.co.uk> from Sean Hinde at "Nov 27, 2000 07:50:27 pm" Message-ID: <200011272154.IAA00446@parallel.serc.rmit.edu.au> Sean Hinde writes: > > Agreed, but there appears to be a serious amount of will power and > resourcing behind this. At the moment attempting to write anything > asynchronous and multithreaded seems to be extremely painful because the > Java language and runtime provide only hindrance. If the platform is fixed > sufficiently to allow "normal" Java programmers to do this stuff safely then > maybe it will become the platform of choice for "responsive" non blocking > clients and servers..? > I am prepared to make the following bold statement: Adding stuff to Java is not likely to bring the benefits of Erlang. This statement can be justified by realising that the strengths of Erlang come as much from what has been left out of the language as what has been included. The key item left out of Erlang that aids the development of concurrent applications the absence of shared memory between processes/threads (I will come back to ETS tables later). Shared memory is almost always the hardest resource to manage in a concurrent system as it requires each programmer to be mindful of the *conventions of use* of that memory. Any programmer interacting with that memory item who violates the conventions or if the conventions are flawed will be able to directly damage the other users of the shared resource. Furthermore, as it is memory, it tends to be hard to track down the misuse. Erlang avoids these problems in 2 ways. The first is that without shared memory a process / thread cannot directly upset the internals of another process / thread. The second is that every shared resource in Erlang has a managing process so that it is generally easy to find where all the access rules are for a particular shared resource. The introduction of shared objects only partly aids the shared memory user. To some extent shared objects allow the access rules to be localised, however, this usually requires the author of the shared object to take into account not only the single process behaviour (ie all that our Erlang shared resource manager needs to) but the interactions between multiple processes accessing the object. Furthermore, if the objects lock resources deadlock can easily be achieved by the users of the objects attempting to reserve access to shared objects in different orders. This is made still worse as programmers are encouraged to believe that the operation of an object can be rewritten without regard for the use of an object so long as they leave the external interface alone. So if a Java programmer wants the benefits of Erlang all s/he has to do is give up sharing, use message passing exclusively and avoid in place updates. (Ooops, forgot Last Call Optimization :) ) Maurice Castro PS. ETS tables can currently be modeled as an Erlang process accessed via a set of access functions. From lennart.ohman@REDACTED Mon Nov 27 23:06:59 2000 From: lennart.ohman@REDACTED (Lennart =?iso-8859-1?Q?=D6hman?=) Date: Mon, 27 Nov 2000 23:06:59 +0100 Subject: No subject References: <9D494CF815CE9E489A73D536CC3525081F32EF@mailer1.solutions.local> Message-ID: <3A22DB03.A7F651E2@home.se> Hi Timo, I believe you want to register with what Ericsson calls its Developers Zone, available (some where :-) at www.ericsson.se. There is also one deeper level called Ericsson Alliance Program which your company/organization can enter in order to get hold of specifications prior to their official release. Regards, Lennart Timo Weiss wrote: > > I'm going to realice a project to configure a Ericsson-WAP-Phones over SMS. > Can you help me with documentations, also from the pdu? > > Thanx for help ! > > Timo Weiss > > KOMSA SOLUTIONS GMBH > Niederfrohnaer Weg 1 > 09232 Hartmannsdorf > Tel: +49 (0)3722 713 96 738 > > Internet: http://komsa-solutions.com > eMail: timo.weiss@REDACTED > +++ Ein Unternehmen der KomSa Gruppe +++ ----------------------------------------------------------- Lennart Ohman phone : +46-(0)8-587 623 27 Sjoland&Thyselius Telecom AB cellular: +46-(0)70-552 6735 Sehlstedtsgatan 6 fax : +46-(0)8-667 8230 SE-115 28, STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From lennart.ohman@REDACTED Mon Nov 27 23:10:13 2000 From: lennart.ohman@REDACTED (Lennart =?iso-8859-1?Q?=D6hman?=) Date: Mon, 27 Nov 2000 23:10:13 +0100 Subject: No subject References: <9D494CF815CE9E489A73D536CC3525081F32EF@mailer1.solutions.local> Message-ID: <3A22DBC5.3C01E81A@home.se> Hi Timo, I believe you want to register with what Ericsson calls its Developers Zone, available (some where :-) at www.ericsson.se. There is also one deeper level called Ericsson Alliance Program which your company/organization can enter in order to get hold of specifications prior to their official release. Regards, Lennart Timo Weiss wrote: > > I'm going to realice a project to configure a Ericsson-WAP-Phones over SMS. > Can you help me with documentations, also from the pdu? > > Thanx for help ! > > Timo Weiss > > KOMSA SOLUTIONS GMBH > Niederfrohnaer Weg 1 > 09232 Hartmannsdorf > Tel: +49 (0)3722 713 96 738 > > Internet: http://komsa-solutions.com > eMail: timo.weiss@REDACTED > +++ Ein Unternehmen der KomSa Gruppe +++ ----------------------------------------------------------- Lennart Ohman phone : +46-(0)8-587 623 27 Sjoland&Thyselius Telecom AB cellular: +46-(0)70-552 6735 Sehlstedtsgatan 6 fax : +46-(0)8-667 8230 SE-115 28, STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From lennart.ohman@REDACTED Mon Nov 27 23:11:15 2000 From: lennart.ohman@REDACTED (Lennart =?iso-8859-1?Q?=D6hman?=) Date: Mon, 27 Nov 2000 23:11:15 +0100 Subject: No subject References: <9D494CF815CE9E489A73D536CC3525081F32EF@mailer1.solutions.local> Message-ID: <3A22DC03.1FE5752@home.se> Hi Timo, I believe you want to register with what Ericsson calls its Developers Zone, available (some where :-) at www.ericsson.se. There is also one deeper level called Ericsson Alliance Program which your company/organization can enter in order to get hold of specifications prior to their official release. Regards, Lennart Timo Weiss wrote: > > I'm going to realice a project to configure a Ericsson-WAP-Phones over SMS. > Can you help me with documentations, also from the pdu? > > Thanx for help ! > > Timo Weiss > > KOMSA SOLUTIONS GMBH > Niederfrohnaer Weg 1 > 09232 Hartmannsdorf > Tel: +49 (0)3722 713 96 738 > > Internet: http://komsa-solutions.com > eMail: timo.weiss@REDACTED > +++ Ein Unternehmen der KomSa Gruppe +++ ----------------------------------------------------------- Lennart Ohman phone : +46-(0)8-587 623 27 Sjoland&Thyselius Telecom AB cellular: +46-(0)70-552 6735 Sehlstedtsgatan 6 fax : +46-(0)8-667 8230 SE-115 28, STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From ingela@REDACTED Tue Nov 28 09:10:51 2000 From: ingela@REDACTED (Ingela Anderton) Date: Tue, 28 Nov 2000 09:10:51 +0100 (MET) Subject: No subject References: <9D494CF815CE9E489A73D536CC3525081F32EF@mailer1.solutions.local> <3A22DC03.1FE5752@home.se> Message-ID: <200011280810.JAA24290@townsend.ericsson.se> Try, http://www.ericsson.com/developerszone/join_edz.asp Lennart \hman wrote: > Hi Timo, > > I believe you want to register with what Ericsson calls its Developers > Zone, available (some where :-) at www.ericsson.se. There is also one > deeper level called Ericsson Alliance Program which your > company/organization > can enter in order to get hold of specifications prior to their official > release. > > > Regards, > Lennart > > > Timo Weiss wrote: > > > > I'm going to realice a project to configure a Ericsson-WAP-Phones over SMS. > > Can you help me with documentations, also from the pdu? > > > > Thanx for help ! > > > > Timo Weiss > > > > KOMSA SOLUTIONS GMBH > > Niederfrohnaer Weg 1 > > 09232 Hartmannsdorf > > Tel: +49 (0)3722 713 96 738 > > > > Internet: http://komsa-solutions.com > > eMail: timo.weiss@REDACTED > > +++ Ein Unternehmen der KomSa Gruppe +++ > > > ----------------------------------------------------------- > Lennart Ohman phone : +46-(0)8-587 623 27 > Sjoland&Thyselius Telecom AB cellular: +46-(0)70-552 6735 > Sehlstedtsgatan 6 fax : +46-(0)8-667 8230 > SE-115 28, STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED > -- /m.v.h Ingela //The highway of life is always under construction. // |\ _,,,--,,_ ,) /,`.-'`' -, ;-;;' |,4- ) )-,_ ) /\ '---''(_/--' (_/-' Ericsson Utvecklings AB Phone : +46 8 719 18 13 Open Systems (f.d. Erlang Systems) Cellular/Mobile: +46 70 636 78 68 Torshamnsgatan 39 B Box 1214 http://www.erlang.se S-164 28 KISTA, SWEDEN ingela@REDACTED From Erik.Reitsma@REDACTED Tue Nov 28 09:29:51 2000 From: Erik.Reitsma@REDACTED (Erik Reitsma (ELN)) Date: Tue, 28 Nov 2000 09:29:51 +0100 Subject: Language for service logic, was: RE: threads - use them as much a s you can Message-ID: <3921BC22FF85D2118C950008C75D94A00CC9634E@enlrynt302.etm.ericsson.se> > >(Which doesn't really help me now that I am honestly trying to get > >into Java programming for GUIs.) > > I sympathise. It looks like Ericsson's new "Service Creation > Environment" > for Intelligent Networks will require us to write service > logic in Java > (there's no GUI!). Also the JAIN initiative from Sun seems > likely to adopted > by the 3gpp standards group as their standard service > creation API. As far as I know not JAIN but Parlay is already adopted by 3gpp. Parlay is CORBA based, and could therefore support other languages "as well as" Java. However, the platform on which the services are supposed to run (TelORB/Jambala) only supports C++ and Java. I don't see anybody porting Erlang to it. And why should you want to do it, when OTP provides all that TelORB provides? *Erik. From etxuwig@REDACTED Tue Nov 28 09:50:58 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 28 Nov 2000 09:50:58 +0100 (MET) Subject: threads - use them as much as you can In-Reply-To: Message-ID: On Mon, 27 Nov 2000, David W. Bauer Jr. wrote: >I wish I had gotten on this thread sooner.. I find that most people >should stay away from threads in general because in order to use >them you have to determine areas where parallelism can be exploited. >If you cannot do that well, then you will really derive no benefit >from them. I think this depends a bit on your perspective. If your programming domain is e.g. math intensive stuff or editors, it's not immediately obvious what Erlang's style of concurrency will bring. Erlang is not really about exploiting parallelism in your programs. The processes are a bit too heavy for that. It's more about threads of control, which is a perfectly natural way of thinking about systems like a telephone switch. Once you have properly implemented control threads (Communicating Sequential Processes, CSP, are, in my humble opinion the current state of the art), you start realising that these threads can be used to much more benefit than increasing the concurrency in your system: - inherent in the "thread of control" concept is the philosophy of doing one thing and doing it well: once you isolate independent (they don't have to be concurrent) tasks, you can assign a process to each, and this process has the luxury of concentrating on one thing alone, which makes programming much easier. - a thread also becomes a way of encapsulating exceptions. If a programming error causes a process to crash, this will not necessarily affect anything else in the system, since the process was doing one thing only, and had its own memory. - finally, since we still have to detect process crashes, Erlang's concept of process linking and monitoring gives us a simple but powerful mechanism to structure our system so that it recovers automatically from errors. This leads to the "let it crash" philosophy, so popular among Erlang programmers. When I started learning Erlang, I made a list of the characteristics of OO, and a corresponding list of the characteristics of process- oriented programming. I found that they were roughly equivalent in terms of expressive power. With some more years of experience, I want to add that this holds with a very important distinction: OO wants to build on the commonalities between different components in the system, and really maximize dependencies through inheritance and the "everything is an object" motto. The CSP model combined with functional programming basically does the complete opposite: each process has its own environment, and the majority of functions are totally side-effect free. Personally, I am very much in favour of the latter, as it makes it much easier to decomposition your problems and then reason about the results. /Uffe -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From sam@REDACTED Tue Nov 28 11:01:11 2000 From: sam@REDACTED (Samuel Tardieu) Date: Tue, 28 Nov 2000 11:01:11 +0100 Subject: threads - use them as much as you can In-Reply-To: ; from etxuwig@etxb.ericsson.se on Mon, Nov 27, 2000 at 10:22:20PM +0100 References: <402DD461F109D411977E0008C791C3125653C1@imp02mbx.one2one.co.uk> Message-ID: <2000-11-28-11-01-11+trackit+sam@inf.enst.fr> Another nice thing about processes in Erlang is how they map onto objects. At the beginning of OO programming, programmers were told "Look, it is so nice, you do not call subprograms, you send messages to objects which will then react to those messages". This view was flawed, as the object was not reacting at all (it had no thread of control on its own), it just provided the caller with what to do (the method's code). In Erlang, you really send messages to objects, you do not execute yourself the code that they supply. Erlang processes are real objects. From simonb@REDACTED Tue Nov 28 12:09:54 2000 From: simonb@REDACTED (Simon Bennett) Date: Tue, 28 Nov 2000 11:09:54 +0000 Subject: threads - use them as much as you can References: <402DD461F109D411977E0008C791C3125653C1@imp02mbx.one2one.co.uk> <2000-11-28-11-01-11+trackit+sam@inf.enst.fr> Message-ID: <3A239282.AC897261@terminus.ericsson.se> Samuel Tardieu wrote: > > Another nice thing about processes in Erlang is how they map onto objects. > > At the beginning of OO programming, programmers were told "Look, it is > so nice, you do not call subprograms, you send messages to objects which > will then react to those messages". This view was flawed, as the object > was not reacting at all (it had no thread of control on its own), it just > provided the caller with what to do (the method's code). > > In Erlang, you really send messages to objects, you do not execute yourself > the code that they supply. Erlang processes are real objects. In UML (Unified Modeling Language) a distinction is made between 'active objects' and ordinary objects. Active objects have their own thread of control and can be sent messages asynchronously. Something similar is also true in Rational Rose RealTime (formerly ObjecTime Developer), which I believe is becoming the UML RealTime standard. It is possible to distinguish between classes (capsules in Rose RT, actors in OTD), which will be instantiated into objects that have their own thread and are modelled as state machines, and data classes which are bog-standard O-O classes. Capsules communicate via ports, and each port is associated with a protocol defined in terms of a set of messages that can be exchanged between ports that use that protocol. It would be interesting to be able to model systems in Rose RT and then generate Erlang from the model to provide a framework for the code, mapping capsules to gen_fsms or gen_servers, using the protocols to define the messages that are sent, and using the containment hierarchy in Rose RT to map to a supervision hierarchy. Having written multi-threading/-processing code in C, Java and Erlang, I know which model of concurrency I find easiest! Simon ___________________________________________________________________ Simon Bennett E-mail: simonb@REDACTED Ericsson Intracom http://www.ericsson.co.uk/UK/intracom 1 Bede Island Road Voice (UK) 0116 2542400 Leicester Voice (int) +44 116 2542400 England Voice ECN: 832 707 ext 232 LE2 7EU Fax: +44 (0)116 2046111 ___________________________________________________________________ From Sean.Hinde@REDACTED Tue Nov 28 13:15:56 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 28 Nov 2000 12:15:56 -0000 Subject: Language for service logic, was: RE: threads - use them as mu ch a s you can Message-ID: <402DD461F109D411977E0008C791C3125653CA@imp02mbx.one2one.co.uk> > As far as I know not JAIN but Parlay is already adopted by > 3gpp. Parlay is CORBA based, and could therefore support > other languages "as well as" Java. This is true, and the 2.1 CORBA IDL for Parlay compiles almost perfectly with IC (there is a single shadowed include which generates an error) > However, the platform on which the services are supposed to > run (TelORB/Jambala) only supports C++ and Java. I don't see > anybody porting Erlang to it. And why should you want to do > it, when OTP provides all that TelORB provides? Yes, OTP provides all that TelORB provides except: * Full hardware and software 24*7 call out support via the local Ericsson support agencies. * c7 INAP, CAMEL Interfaces kept fully up to date with all the latest changes in the standards. * It seems to guarantee that if one service invocation goes haywire or crashes this cannot affect any other invocations (even endless loop scenarios are catered for with a max lifetime parameter). I guess these are all pretty specific issues to my small application area but they are certainly important. It would be nice to see Erlang ported though :-) Anyway I've already said too much I'm sure. - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From luke@REDACTED Tue Nov 28 13:29:13 2000 From: luke@REDACTED (Luke Gorrie) Date: 28 Nov 2000 13:29:13 +0100 Subject: threads - use them as much as you can In-Reply-To: Samuel Tardieu's message of "Tue, 28 Nov 2000 11:01:11 +0100" References: <402DD461F109D411977E0008C791C3125653C1@imp02mbx.one2one.co.uk> <2000-11-28-11-01-11+trackit+sam@inf.enst.fr> Message-ID: Samuel Tardieu writes: > At the beginning of OO programming, programmers were told "Look, it is > so nice, you do not call subprograms, you send messages to objects which > will then react to those messages". This view was flawed, as the object > was not reacting at all (it had no thread of control on its own), it just > provided the caller with what to do (the method's code). Somewhere between the two, Eiffel has (at least on paper) a really interesting CSP-like way of doing communication. I can't help but talk about it every time concurrency comes up. IIRC, you have some nodes (I think Eiffel calls them CPUs), and each object belongs to one of them. A node (like an Erlang process) is a single thread of execution which is shared by the objects it hosts. Suppose you're an object. When you call a method on another object that's node-local, you jump into its code directly. But: when you call a method on a remote object, you essentially send a message to it asking for the method to run, and block waiting for a reply. On the receiver's end, it accepts the message only when a) the preconditions of the method are met, and b) the node isn't busy running some other method. The fun bit is (a), because if for instance you call the 'get' method of a queue object, it might have a precondition like "not empty", meaning that your call will block until there's something on the queue for you to get - just the same sort of lovely CSP-style implied synchronization you get with guarded receives in Erlang. Most significantly perhaps, it avoids the big problem in Java of having multiple threads mucking with the same objects at the same time - IMO the essential thing that makes java concurrency so hard. They also do clever stuff with lazy synchronization of nodes. You can asynchronously fire off some side-effect-only methods, and then automatically block until they finish the next time you query some state from an object on the node. I've never used an Eiffel that implemented this "SCOOP" concurrency, so I dunno if it actually works. That keeps me very curious - an excellent implementation strategy for a niche language! Thank you for your patience :-) Cheers, Luke From Peter.Andersson@REDACTED Tue Nov 28 13:59:35 2000 From: Peter.Andersson@REDACTED (Peter Andersson) Date: Tue, 28 Nov 2000 12:59:35 +0000 Subject: threads - use them as much as you can References: <402DD461F109D411977E0008C791C3125653C1@imp02mbx.one2one.co.uk> <2000-11-28-11-01-11+trackit+sam@inf.enst.fr> <3A239282.AC897261@terminus.ericsson.se> Message-ID: <3A23AC37.BD957E6B@eei.ericsson.se> Simon Bennett wrote: > > Something similar is also true in Rational Rose RealTime (formerly > ObjecTime Developer), which I believe is becoming the UML RealTime > standard. It is possible to distinguish between classes (capsules in > Rose RT, actors in OTD), which will be instantiated into objects that > have their own thread and are modelled as state machines, and data > classes which are bog-standard O-O classes. A bog-standard class? Is that like peat? :-) > > It would be interesting to be able to model systems in Rose RT and then > generate Erlang from the model to provide a framework for the code, > mapping capsules to gen_fsms or gen_servers, using the protocols to > define the messages that are sent, and using the containment hierarchy > in Rose RT to map to a supervision hierarchy. I know of at least one project using Rational Rose as a modelling tool for a system being partly implemented in Erlang. They're not using the Rose RT features you describe, though, as far as I know, but model interfaces in the system using UML and generate all interfaces (stub and skeleton code) via IDL to Erlang (IC). It is possible to generate interface code for both inter- and intra process communication. Neat idea I think. Very useful for documenting important interfaces (both internal and external) and achiving consistency between the docs and the physical code in a large system. Also, it opens up the system so that broker communication between different parts of it is easily integrated. I.e. you can for example generate Erlang server code and, say, C client stubs from the UML spec and use a suitable broker mechanism to achieve the communication (like the Orber, or some other interface system IC has backend for). That was a bit of a side track from this "thread thread" really. What is "the industry" using for developing concurrent, (soft) realtime software applications (like tele/datacom control systems) these days anyway? (The small part of it not using Erlang, that is ;-). I guess it's C and C++ on top of a multitasking OS or on top of some threaded SW platform that is the most common. What other concurrent high-level languages than Erlang are being used in commercial projects, if any? Regards /Peter From Sean.Hinde@REDACTED Tue Nov 28 14:39:32 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 28 Nov 2000 13:39:32 -0000 Subject: threads - use them as much as you can Message-ID: <402DD461F109D411977E0008C791C3125653CC@imp02mbx.one2one.co.uk> > What is "the industry" using for developing concurrent, > (soft) realtime software > applications (like tele/datacom control systems) these days > anyway? (The small > part of it not using Erlang, that is ;-). I guess it's C and > C++ on top of a > multitasking OS or on top of some threaded SW platform that > is the most common. > What other concurrent high-level languages than Erlang are > being used in > commercial projects, if any? It is interesting that Java is being pushed very hard into the internet server application market. This is exactly where concurrency is nice if you want to have systems which are responsive and resilient to some back end systems slowing down. My experience of this type of thing is that even getting the concept or value of a multithreaded application server over to Java app guys is hard (denial followed by intransigence and claims of impossibility). The view seems to be that if it blocks you just get a faster machine - which demonstrates no real understanding of the timeline aspects of the overall application. Then you need lots of load balancing switches :) to force multithreading into a pool of application instances listening on different ports to get any throughput! EJB seems to be the big buzzword and that isn't natively multithreaded at all. The strength of this stuff though is the ever growing libraries of APIs to almost every protocol under the sun, which Erlang can't compete with off the shelf. Sigh.. - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From jamesh@REDACTED Tue Nov 28 18:02:59 2000 From: jamesh@REDACTED (James Hague) Date: Tue, 28 Nov 2000 11:02:59 -0600 Subject: threads - use them as much as you can Message-ID: <3.0.32.20001128110258.01048eec@volition-inc.com> Samuel Tardieu wrote: >At the beginning of OO programming, programmers were >told "Look, it is so nice, you do not call subprograms, >you send messages to objects which will then react to >those messages". This view was flawed, as the object >was not reacting at all (it had no thread of control >on its own), it just provided the caller with what to >do (the method's code). That is an excellent point. The message passing terminology always bothered me, as it seemed to be an elaborate way of saying "subroutine call." How has Erlang worked for applications in which processes are used to model static objects, rather than parallel processes? Erlang is one of the nicest languages I have ever used, but I'm not using the language in it's intended domain. I use it as a general purpose alternative to Python and such, where processes provided an elaborate way of catching errors (for example, spawning off a compiler task and putting the error reporting in the controlling process). I can see interesting some applications of Erlang that use processes heavily, but not in a truly concurrent way (e.g. a video game with a process per onscreen object). The potential overhead of message passing in such situations has put me off. I should run some experiments. James From kent@REDACTED Tue Nov 28 18:22:44 2000 From: kent@REDACTED (Kent Boortz) Date: 28 Nov 2000 18:22:44 +0100 Subject: Patches for R7B-0 Message-ID: More patches for R7B-0 The numbers beginning with "OTP-" are internal tracking numbers that we use that are not very useful to you. But keeping them makes it more easy for us to identify the changes we have made patches for. You use something like % cd otp_src_R7B-0/ % zcat ../patches/patch-R7B-0-*.diff.gz | patch -p1 to patch your source. Let me know if there are any problems adding the patches. The description of the previous patches and the list below is found in http://www.erlang.org/download/patches/README kent http://www.erlang.org/download/patches/patch-R7B-0-007-configure.diff.gz -------- Updated the README file how to install the documentation. -------- Terminate configure if 'ar' command is not found. OTP-3785 For newer versions of gcc the value of GCCLIB_PATH is set incorrectly. In fact, it is not needed and now removed. http://www.erlang.org/download/patches/patch-R7B-0-008-compiler.diff.gz OTP-3748 The compiler would sometimes reorder bit syntax clauses causing them to be execute in the wrong order. This has been corrected. http://www.erlang.org/download/patches/patch-R7B-0-009-erl_interface.diff.gz OTP-3772 Changed back the return values from erl_send() and erl_reg_send() to 1 (as they used to be). http://www.erlang.org/download/patches/patch-R7B-0-010-jinterface.diff.gz OTP-3721 An error in the constructor for OtpNode has been fixed. http://www.erlang.org/download/patches/patch-R7B-0-011-kernel.diff.gz OTP-3763 inet_res:nslookup/4 has been made backwards compatible. OTP-3769 When making rpc:call to a function that in its turn spawn_linked some child process, the rpc server killed the child process when the called function returned. This is now corrected. http://www.erlang.org/download/patches/patch-R7B-0-012-mnesia.diff.gz OTP-3584 transform_table now supports indexes, but the dirty_index_* operations may exit when the index is rebuilt. The memory usage has been improved for set and ordered_set tables. OTP-3762 Same as OTP-3584 above. OTP-3761 New iteration functions has been added i.e. foldl/3 foldr/3 foldl/4 foldr/4, together with dirty_last/1 and dirty_prev/2 for ordered_set tables. http://www.erlang.org/download/patches/patch-R7B-0-013-sasl.diff.gz OTP-3767 A printout has been added in release_handler when install_release fails. http://www.erlang.org/download/patches/patch-R7B-0-014-stdlib.diff.gz OTP-3766 When doing a rpc:call to a remote node calling a function whos process gets killed by another process e.g. due to a link, the process calling rpc:call hanged. This bug is now fixed. From etxuwig@REDACTED Tue Nov 28 18:39:44 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 28 Nov 2000 18:39:44 +0100 (MET) Subject: threads - use them as much as you can In-Reply-To: <3.0.32.20001128110258.01048eec@volition-inc.com> Message-ID: There was a military troop simulator written in Erlang as a student project. The project was a success, and I have forgotten why it didn't go further. Anyway, it simulated movements of up to 100 troops in varying terrain. "Process-based Simulation of Interactive Agents in a Dynamic Terrain" Samuel Tronje UU/CSD, 1995 I think it does seem like an interesting approach for a certain type of video games. /Uffe On Tue, 28 Nov 2000, James Hague wrote: >How has Erlang worked for applications in which processes are used to model >static objects, rather than parallel processes? Erlang is one of the >nicest languages I have ever used, but I'm not using the language in it's >intended domain. I use it as a general purpose alternative to Python and >such, where processes provided an elaborate way of catching errors (for >example, spawning off a compiler task and putting the error reporting in >the controlling process). I can see interesting some applications of >Erlang that use processes heavily, but not in a truly concurrent way (e.g. >a video game with a process per onscreen object). The potential overhead >of message passing in such situations has put me off. I should run some >experiments. > >James > > -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From kent@REDACTED Tue Nov 28 18:22:44 2000 From: kent@REDACTED (Kent Boortz) Date: 28 Nov 2000 18:22:44 +0100 Subject: Patches for R7B-0 Message-ID: More patches for R7B-0 The numbers beginning with "OTP-" are internal tracking numbers that we use that are not very useful to you. But keeping them makes it more easy for us to identify the changes we have made patches for. You use something like % cd otp_src_R7B-0/ % zcat ../patches/patch-R7B-0-*.diff.gz | patch -p1 to patch your source. Let me know if there are any problems adding the patches. The description of the previous patches and the list below is found in http://www.erlang.org/download/patches/README kent http://www.erlang.org/download/patches/patch-R7B-0-007-configure.diff.gz -------- Updated the README file how to install the documentation. -------- Terminate configure if 'ar' command is not found. OTP-3785 For newer versions of gcc the value of GCCLIB_PATH is set incorrectly. In fact, it is not needed and now removed. http://www.erlang.org/download/patches/patch-R7B-0-008-compiler.diff.gz OTP-3748 The compiler would sometimes reorder bit syntax clauses causing them to be execute in the wrong order. This has been corrected. http://www.erlang.org/download/patches/patch-R7B-0-009-erl_interface.diff.gz OTP-3772 Changed back the return values from erl_send() and erl_reg_send() to 1 (as they used to be). http://www.erlang.org/download/patches/patch-R7B-0-010-jinterface.diff.gz OTP-3721 An error in the constructor for OtpNode has been fixed. http://www.erlang.org/download/patches/patch-R7B-0-011-kernel.diff.gz OTP-3763 inet_res:nslookup/4 has been made backwards compatible. OTP-3769 When making rpc:call to a function that in its turn spawn_linked some child process, the rpc server killed the child process when the called function returned. This is now corrected. http://www.erlang.org/download/patches/patch-R7B-0-012-mnesia.diff.gz OTP-3584 transform_table now supports indexes, but the dirty_index_* operations may exit when the index is rebuilt. The memory usage has been improved for set and ordered_set tables. OTP-3762 Same as OTP-3584 above. OTP-3761 New iteration functions has been added i.e. foldl/3 foldr/3 foldl/4 foldr/4, together with dirty_last/1 and dirty_prev/2 for ordered_set tables. http://www.erlang.org/download/patches/patch-R7B-0-013-sasl.diff.gz OTP-3767 A printout has been added in release_handler when install_release fails. http://www.erlang.org/download/patches/patch-R7B-0-014-stdlib.diff.gz OTP-3766 When doing a rpc:call to a remote node calling a function whos process gets killed by another process e.g. due to a link, the process calling rpc:call hanged. This bug is now fixed. From jamesh@REDACTED Tue Nov 28 19:00:25 2000 From: jamesh@REDACTED (James Hague) Date: Tue, 28 Nov 2000 12:00:25 -0600 Subject: threads - use them as much as you can Message-ID: <3.0.32.20001128120024.01048440@volition-inc.com> Ulf Wiger wrote: >As for many thread priority levels, I remain unconvinced >In AXD 301, we've settled on job scheduling/prioritization. >Basically, programmers get to decide what consitutes a job, >or a work unit. We have a simple but efficient job scheduler >which implements a weighted round robin on a configurable >number of job queues. So you have Erlang code that determines which job gets to run and when? That's slick. I tend to think of Erlang in terms of the raw capabilities of the language, not thinking about how things would change if I added some simple layers of abstraction :) James From bauerd@REDACTED Tue Nov 28 21:08:51 2000 From: bauerd@REDACTED (David W. Bauer Jr.) Date: Tue, 28 Nov 2000 15:08:51 -0500 (EST) Subject: threads - use them as much as you can In-Reply-To: <402DD461F109D411977E0008C791C3125653CC@imp02mbx.one2one.co.uk> Message-ID: The work that I am doing is replacing Java based web apps with Erlang. And you are right, erlang is a much more suitable solution because it allows me to handle millions of requests without doing any real work in the application. I simply took the inets web server, embed it in a node, and then use it to create requests into the node. Very slick of erlang.. because I could have apache outside of the node sending requests to inets if I wanted. David ~~~ ~~ ~~~~ _o URL: http://www.david-bauer.com ~~~ ~~~~ ~~ _'|<,_ ~~~~ ~~~ ~~~~ (*)/ (*) On Tue, 28 Nov 2000, Sean Hinde wrote: #> What is "the industry" using for developing concurrent, #> (soft) realtime software #> applications (like tele/datacom control systems) these days #> anyway? (The small #> part of it not using Erlang, that is ;-). I guess it's C and #> C++ on top of a #> multitasking OS or on top of some threaded SW platform that #> is the most common. #> What other concurrent high-level languages than Erlang are #> being used in #> commercial projects, if any? # #It is interesting that Java is being pushed very hard into the internet #server application market. This is exactly where concurrency is nice if you #want to have systems which are responsive and resilient to some back end #systems slowing down. # #My experience of this type of thing is that even getting the concept or #value of a multithreaded application server over to Java app guys is hard #(denial followed by intransigence and claims of impossibility). The view #seems to be that if it blocks you just get a faster machine - which #demonstrates no real understanding of the timeline aspects of the overall #application. # #Then you need lots of load balancing switches :) to force multithreading #into a pool of application instances listening on different ports to get any #throughput! # #EJB seems to be the big buzzword and that isn't natively multithreaded at #all. # #The strength of this stuff though is the ever growing libraries of APIs to #almost every protocol under the sun, which Erlang can't compete with off the #shelf. # #Sigh.. # #- Sean # # # #NOTICE AND DISCLAIMER: #This email (including attachments) is confidential. If you have received #this email in error please notify the sender immediately and delete this #email from your system without copying or disseminating it or placing any #reliance upon its contents. We cannot accept liability for any breaches of #confidence arising through use of email. Any opinions expressed in this #email (including attachments) are those of the author and do not necessarily #reflect our opinions. We will not accept responsibility for any commitments #made by our employees outside the scope of our business. We do not warrant #the accuracy or completeness of such information. # # From ruy@REDACTED Tue Nov 28 22:21:45 2000 From: ruy@REDACTED (Ruy de Queiroz) Date: Tue, 28 Nov 2000 18:21:45 -0300 (EST) Subject: WoLLIC'2001 - Call for Papers Message-ID: [please post. apologies for multiple copies] Call for Papers 8th Workshop on Logic, Language, Information and Computation (WoLLIC'2001) July 31 to August 3, 2001 Scientific Co-Sponsorship: IGPL, FoLLI, ASL, SBC, SBL Bras?lia, Brazil (NEW!: (MODEST) STUDENT GRANTS) THE EVENT The "8th Workshop on Logic, Language, Information and Computation" (WoLLIC'2001), the eighth version of a series of workshops which started in 1994 with the aim of fostering interdisciplinary research in pure and applied logic, will be held in Bras?lia, Brazil, from July 31st to August 3rd 2001. SCOPE Contributions are invited in the form of short papers (10 A4 10pt pages) in all areas related to logic, language, information and computation, including: pure logical systems, proof theory, model theory, algebraic logic, type theory, category theory, constructive mathematics, lambda and combinatorial calculi, program logic and program semantics, logics and models of concurrency, logic and complexity theory, nonclassical logics, nonmonotonic logic, logic and language, discourse representation, logic and artificial intelligence, automated deduction, foundations of logic programming, logic and computation, and logic engineering. SCIENTIFIC SPONSORSHIP The 8th WoLLIC'2001 has the scientific sponsorship of the Association for Symbolic Logic (ASL), the Interest Group in Pure and Applied Logics (IGPL), the European Association for Logic, Language and Information (FoLLI), the Sociedade Brasileira de Computa??o (SBC), and the Sociedade Brasileira de L?gica (SBL). THE LOCATION Bras?lia, the youthful capital of Brazil - famous for its innovating architecture and futuristic urbanism, is situated in the geographical center of the country, inside the Brazilian Cerrados that is a rich Tropical Savannah, with a unique and diverse flora and fauna. In August, during the Brazilian winter, the weather is dry with an average temperature of 22 C, that makes ideal aquatic sports and visits to the natural attractions of the city as the Zoo, the Botanical Garden and the National Park. GUEST SPEAKERS There will be a number of guest speakers, including: Walter Carnielli (State Univ Campinas, Brazil) Bruno Courcelle (Univ Bordeaux 1, France) Gilles Dowek (INRIA, France) Petr Hajek (Inst Computer Sci, Czech Acad of Sciences, Czech Republic) Dexter Kozen (Cornell Univ, USA) (TO BE CONFIRMED) Jouko V??n?nen (Helsinki Univ, Finland) SUBMISSION Papers (up to 10 pages A4 10pt, sent preferably in postscript format by e-mail to wollic@REDACTED, or in 5(five) copies to postal address) must be RECEIVED by APRIL 2nd, 2001 by one of the Chairs of the Organising Committee. Papers must be ANONYMOUS (a separate identification page must be included), written in English and give enough detail to allow the programme committee to assess the merits of the work. Papers should start with a brief statement of the issues, a summary of the main results, and a statement of their significance and relevance to the workshop. References and comparisons with related work is also expected. Technical development directed to the specialist should follow. Results must be unpublished and not submitted for publication elsewhere, including the proceedings of other symposia or workshops. One author of each accepted paper will be expected to attend the conference in order to present it. Authors will be notified of acceptance by MAY 7th, 2001, and final versions will have to be delivered (in LaTeX format) by MAY 31st, 2001. The abstracts of the papers will be published in a "Conference Report" section of the Logic Journal of the IGPL (ISSN 1367-0751) (Oxford Univ Press) as part of the meeting report. Papers presented at the meeting will be invited for submission (in full version) to the Logic Journal of the IGPL (http://www.oup.co.uk/igpl/). STUDENT GRANTS WoLLIC'2001 will make available modest grants to graduate students in logic and to recent PhDs so that they may attend the meeting in Bras?lia. To be considered for a grant, please (1) send a letter of application, and (2) ask your thesis supervisor to send a brief recommendation letter. The application letter should be brief (one page) and should include (1) your name, (2) your home institution, (3) your thesis supervisor's name, (4) a one-paragraph description of your studies and work in logic, (5) your estimate of the travel expenses you will incur, (6) (for citizens or residents of Brazil) citizenship or visa status, and (7) (voluntary) indication of your gender and minority status. Only modest grants will be possible, partially covering travel costs and perhaps some of the living expenses during the meeting. Women and members of minority groups are strongly encouraged to apply. In addition to funds provided by WoLLIC, it is expected that this program of student grants will be supported by a grant from the Brazilian National Council for the Scientific and Technological Development (CNPq); CNPq funds may be awarded only to students at Brazilian universities and to citizens and permanent residents of Brazil. Application by email is encouraged; put "WoLLIC grant application" in the subject line of your message. Applications and recommendations should be received before the deadline of MARCH 1st, 2001, by one of the Co-Chairs of the Organising Committee. IMPORTANT DATES Submission: APRIl 2nd, 2001 Notification of acceptance/rejection: MAY 7th, 2001 Delivery of final (in LaTeX): MAY 31st, 2001 PROGRAMME COMMITTEE John Baldwin (Univ Illinois at Chicago, USA) Mads Dam (Swedish Inst Computer Sci, Sweden) Marcelo Finger (Univ Sao Paulo, Brazil) Edward Hermann Haeusler (Pont Cathol Univ Rio de Janeiro, Brazil) David Israel (SRI International, USA) Fairouz Kamareddine (Heriot-Watt Univ, Scotland) Claude Kirchner (LORIA & INRIA, France) Phokion Kolaitis (Univ Calif at Santa Cruz, USA) Daniel Leivant (Indiana Univ, USA) Michael Moortgat (Utrecht Univ, The Netherlands) Pavel Pudl?k (Maths Inst, Czech Acad. of Sciences, Czech Rep) ORGANISING COMMITTEE Mauricio Ayala-Rincon (UnB) (Co-Chair) Sandra A. de Amo (UFU) Ana Teresa de Castro Martins (UFC) Anjolina G. de Oliveira (UFPE/UFBA) Hayd?e W. Poubel (UnB) Ruy de Queiroz (UFPE) (Co-Chair) Renata Wassermann (USP) FURTHER INFORMATION Contact one of the Co-Chairs of the Organising Committee: Ruy de Queiroz, Centro de Inform?tica, Univ. Federal de Pernambuco, CP 7851, 50732-970 Recife, PE, Brazil. E-mail: ruy@REDACTED, tel.: (+55 81) 3271-8430, fax: (+55 81) 3271-8438. Mauricio Ayala Rincon, Departamento de Matem?tica, Universidade de Bras?lia, 70910-900 Bras?lia, DF, Brazil. E-mail: ayala@REDACTED, tel.: (+55 61) 307-2441, fax: (+55 61) 273-2737. WEB PAGE http://www.cin.ufpe.br/~wollic/wollic2001/ ------- From vladdu@REDACTED Tue Nov 28 23:46:03 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Tue, 28 Nov 2000 23:46:03 +0100 Subject: the OO metaphor Message-ID: The "thread thread" is very interesting, and talking about OO reminded me of an idea I got... I think it's not a very bad one, so I will share it with you, to see what you think. The OO methodology can be easily applied to Erlang, once one gets to ffel the pulse of the language. There is however one thing that is missing, and that I think it could be useful. That thing is inheritance. The natural way for inheritance to be implemented in Erlang isn't the C++ way, but the CLOS way, through some kind of generic functions. A better name than inheritance might be "shared implementation between modules". An example might be appropriate. -module(base). fun1(blip) -> foo; fun1(A) -> {empty, A}. ==== and (the syntax is just a proposal) -module(base_extended). -extend({base, [fun1]}). fun1({help}) -> hohoho; -inherited(). %% need not be always present fun1(_) -> false. The meaning would be that the clauses of base:fun1 are imported into the ones of base_extended:fun1, allowing some of them or all to be overriden. The gain would be for example that when extending the lists module, one only needs to write implementations for the functions that are different. There are problems with the above way of doing it, I know. One might want to reorder clauses, or to keep only part of the inherited ones... But it is the general idea that I'd like to discuss. As someone said earlier (Ulf I think), this creates dependencies between modules. This isn't always a Good Thing. But on the other hand, when writing a gen_server, there is a dependency upon the gen_server module... When trying to implement a module based on another (and that can be used instead of the other), avoiding to write 50 stub functions that just delegate he job for the 2 or 3 that need rewriting is kind of a waste. Plus att the compiler might be able to optimize the calls. It's almost midnight, and I'm not very sure I managed to explain properly. I look forward to find out what a wonderful idea you all thin this is :-) Or alternatively, to find out why it is such a bad idea! regards, Vlad _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From Sean.Hinde@REDACTED Wed Nov 29 00:21:27 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 28 Nov 2000 23:21:27 -0000 Subject: the OO metaphor Message-ID: <402DD461F109D411977E0008C791C3125653D8@imp02mbx.one2one.co.uk> Vlad, Interesting idea. My 10 penneth would be simply that one of the things I Really Like about erlang is that when reading someone elses program (or my own sometimes:) everything I need to know is there in front of me. There is no need to go searching through great heaps of inheritance stuff to get the full picture. My (so far very limited) attempts to understand a Java program had me flying around for ages trying to find exactly which version of a function in which source file was actually being called (I dare say it is very obvious to an experienced programmer, but it is certainly not in one place) To my mind the maintainability gains of having everything spelt out in front of me (or the exact module and hence file name of external calls) does far outweigh the advantages of inheritance. (Sorry to be so negative so quickly, maybe some of the other guys who aren't still working at this time of night and whose brains are not fried can take your idea and fly with it?) - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From lennart.ohman@REDACTED Mon Nov 27 23:19:25 2000 From: lennart.ohman@REDACTED (Lennart =?iso-8859-1?Q?=D6hman?=) Date: Mon, 27 Nov 2000 23:19:25 +0100 Subject: No subject References: <9D494CF815CE9E489A73D536CC3525081F32EF@mailer1.solutions.local> Message-ID: <3A22DDED.8BDC43CB@home.se> Hi Timo, I believe you want to register with what Ericsson calls its Developers Zone, available (some where :-) at www.ericsson.se. There is also one deeper level called Ericsson Alliance Program which your company/organization can enter in order to get hold of specifications prior to their official release. Regards, Lennart Timo Weiss wrote: > > I'm going to realice a project to configure a Ericsson-WAP-Phones over SMS. > Can you help me with documentations, also from the pdu? > > Thanx for help ! > > Timo Weiss > > KOMSA SOLUTIONS GMBH > Niederfrohnaer Weg 1 > 09232 Hartmannsdorf > Tel: +49 (0)3722 713 96 738 > > Internet: http://komsa-solutions.com > eMail: timo.weiss@REDACTED > +++ Ein Unternehmen der KomSa Gruppe +++ ----------------------------------------------------------- Lennart Ohman phone : +46-(0)8-587 623 27 Sjoland&Thyselius Telecom AB cellular: +46-(0)70-552 6735 Sehlstedtsgatan 6 fax : +46-(0)8-667 8230 SE-115 28, STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From qramika@REDACTED Wed Nov 29 07:59:01 2000 From: qramika@REDACTED (Karlsson Mikael) Date: Wed, 29 Nov 2000 07:59:01 +0100 (MET) Subject: threads - use them as much as you can Message-ID: <200011290659.HAA02079@nic.era-a.ericsson.se> Luke Gorrie writes . . > Samuel Tardieu writes: > > > At the beginning of OO programming, programmers were told "Look, it is > > so nice, you do not call subprograms, you send messages to objects which > > will then react to those messages". This view was flawed, as the object > > was not reacting at all (it had no thread of control on its own), it just > > provided the caller with what to do (the method's code). > > Somewhere between the two, Eiffel has (at least on paper) a really > interesting CSP-like way of doing communication. I can't help but talk > about it every time concurrency comes up. . . > Cheers, > Luke > Talking about other languages.. O'Haskell is an attempt to extend a functional language, Haskell, with object-orientation and concurrency. See: http://www.cs.chalmers.se/~nordland/ohaskell/ /Mikael From qramika@REDACTED Wed Nov 29 10:46:48 2000 From: qramika@REDACTED (Karlsson Mikael) Date: Wed, 29 Nov 2000 10:46:48 +0100 (MET) Subject: the OO metaphor Message-ID: <200011290946.KAA06611@nic.era-a.ericsson.se> "Vlad Dumitrescu" writes: . . > An example might be appropriate. > > -module(base). > > fun1(blip) -> foo; > fun1(A) -> {empty, A}. > > ==== and (the syntax is just a proposal) > > -module(base_extended). > -extend({base, [fun1]}). > > fun1({help}) -> hohoho; > -inherited(). %% need not be always present > fun1(_) -> false. . . > regards, > Vlad > Hi Vlad, Without extending the erlang syntax, how about something like?: -module(extend_test). -export([test1/1,test2/1]). %% Basic framework stuff extend_f(A,B) ->[A|B]. eval_f([H|T],A) -> case catch H(A) of {'EXIT',{function_clause,_}} -> eval_f(T,A); B -> B end; eval_f([],A) -> empty. %% Example fun1(blip) -> foo. fun2({help}) -> hohoho. base_f() ->[fun fun2/1,fun fun1/1]. test1(A) -> eval_f(base_f(),A). test2(A) -> Extended_f = extend_f(fun(blip) -> boo end, base_f()), eval_f(Extended_f, A). ------ Running the example: 21> extend_test:test1(blip). foo 22> extend_test:test2(blip). boo 23> extend_test:test1({help}). hohoho 24> extend_test:test2({help}). hohoho 25> extend_test:test2(snip). empty I can understand that there are some flawns, you have to do stuff in runtime, and naming is maybe not consistent with OO, but maybe something to build on... Regards Mikael From etxuwig@REDACTED Wed Nov 29 11:00:10 2000 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 29 Nov 2000 11:00:10 +0100 (MET) Subject: the OO metaphor In-Reply-To: Message-ID: On Tue, 28 Nov 2000, Vlad Dumitrescu wrote: >The "thread thread" is very interesting, and talking about OO >reminded me of an idea I got... I think it's not a very bad one, so >I will share it with you, to see what you think. > >The OO methodology can be easily applied to Erlang, once one gets to >ffel the pulse of the language. There is however one thing that is >missing, and that I think it could be useful. That thing is >inheritance. I might then as well share something that I started hacking on a few weeks ago. It seems to have come to a stop, so this might be a good time to see if there's any interest in continuing... I called it system_erlang. I tried to address the following: - my old idea of extending the receive statement to automatically handle system messages - API inheritance, resolved at module load time - fast-path execution, inspired by work I've seen on forwarding engines, the Erlang processor, and the new filtering mechanisms in OTP R7B (also Thomas Lingren's ongoing work.) Comments are much appreciated. /Uffe %% Sample erlang module -module(syserl). -export([foo/0, bar/0]). %-import_directives(otp, [$extend_receive/1]). %-export_to(Module, [Function/Arity]). %-bounded_time([Function/Arity]). %%% About system directives %%% When building large complex erlang systems, one often wants to control %%% the use of interfaces and seamlessly add support for system messages. %%% %%% Richard O'Keefe's suggestion of -export_to/2 is a good idea, e.g. %%% because it allows hiding of "internal" exports, and restricted use of %%% functions exported for a special purpose (e.g. application:set_env/3). %%% %%% I'd also like to be able to inherit interfaces from another module: %%% an example is when writing a mnesia access module in order to redefine %%% only a few access functions in mnesia; today one must redefine them all, %%% even if the majority of functions will simply call the default mnesia %%% function. This forces the maintainer of a mnesia access module to update %%% their module every time a new access function is added to mnesia - even %%% if this particular function is of no interest to the access module in %%% question. %%% %%% Redefining message reception is difficult to do seamlessly: %%% - if it's done in a library module, there is no room for selective receive %%% - if it's done via a macro, variable binding becomes a problem. Also one %%% must implement all the sys.erl callbacks, which is error prone. %%% %%% My approach is to introduce system directives, allowing each module to %%% "enhance" keywords and inherit interfaces. In the example below, I have %%% defined a keyword, system_receive, which can be used in place of 'receive'. %%% It should be possible to also redefine 'receive', but most likely, the %%% special feature of handling system messages would be used only in a few %%% functions (the main event loop or certain states.) %%% The interface inheritance could also mean that I wouldn't have to write %%% the special sys.erl callback functions, which eliminates a source of %%% errors. %%% %%% These system directives look pretty much like normal erlang functions, %%% (except for the illegal function names) but are callable only by the VM. %%% For this, the compiler may have to insert some helper function to help %%% the loader make the calls (e.g. $fast_path/2 needs to be called once for %%% each function.) %%% %%% An issue to discuss is how/if to make a distinction between compiler %%% directives and system directives. For example, inheriting the interface %%% of another module should be a system directive, in the sense that it %%% should be resolved at runtime - not compile-time. Enabling fast-path %%% execution might be handled by the compiler, but this requires knowledge %%% about other modules, if we are to allow inter-module calls in fast-path %%% processing. Making it a system directive would probably imply some kind %%% of JIT. %%% System directives. %%% So far, we define four system directives: %%% - $extend_receive(MyReceiveKeyword) -> ....... %%% This is used to define our own message reception semantics. The most %%% useful variant will be to %%% - $receive(), which is used in $extend_receive/1 to mark where the %%% original receive clauses go. %%% %%% - $inherit_api(FromModule) -> all | [Exceptions]. %%% This is used to include the exported functions of FromModule as %%% part of the exported functions in this module. %%% %%% - $fast_path(Function, Arity) -> hard | {hard, ExitFunction} | soft | none. %%% This is used to identify functions that are candidates for fast-path %%% compilation. The return value specifies what should happen if %%% fast-path execution fails (which could possibly be when it %%% encounters a side-effect or a function of unknown complexity): %%% - 'hard' means simply exit; %%% - {hard, ExitFunction} means that ExitFunction should be called %%% (Example: a device processor performs fast-path analysis; failure %%% leads to the packet being sent to a (slow path) control processor) %%% - 'soft' means that fast-path failure triggers a slow-path %%% (normal erlang) re-run %%% - 'none' means normal erlang - allowed for completeness only. $extend_receive(system_receive) -> receive Msg when element(1, Msg) == system, size(Msg) == 6 -> sys:handle_system_messages(...); $receive() end. $inherit_api(foo) -> %% inherit all exported functions from foo.erl, except foo:fooey/1, which %% is redefined in our module (runtime error if no such function is %% exported), and foo:buggy/0, which is not available through this module. %% syserl:buggy() will IOW cause exit({undef, _}). [{redefine, [fooey/1]}, {exclude, [buggy/0]}]; $inherit_api(bar) -> %% no special instructions, i.e. inherit all exported functions from bar.erl all. -- Ulf Wiger tfn: +46 8 719 81 95 Senior System Architect mob: +46 70 519 81 95 Strategic Product & System Management ATM Multiservice Networks Data Backbone & Optical Services Division Ericsson Telecom AB From Peter.Andersson@REDACTED Wed Nov 29 11:19:52 2000 From: Peter.Andersson@REDACTED (Peter Andersson) Date: Wed, 29 Nov 2000 10:19:52 +0000 Subject: the OO metaphor References: Message-ID: <3A24D848.B891D0B7@eei.ericsson.se> Hi Vlad, I remember reading a paper on this subject (or something similar) a few years back. It was written by Torbj?rn Keisu (Ericsson Software Architecture Lab), I believe. Now, I can't remember exactly what OO issues were discussed in that paper. What worse is, I can't even find it anymore! Does anyone know where it's stored? I'm writing a simple event driven simulator "engine" in Erlang at the moment, just for fun (nerd pride! :-). I've done similar things in Java and C++ before and I thought I was going to run into the "oh, I really wish I had inheritance for this" feeling quite often. I thought I would think up smart alternatives (or resembling constructs) along the way. An OO programming style using ADTs is easily accomplished in Erlang. You don't need to have a "one object per process" model for this. Normal "buy-sell" relations between objects are also easily handled. It's inheritance and polymorphy that might be hard to do, but so far I haven't really given that so much thought (proves how much planning went in to this project before execution, huh! ;-). Now, I probably will run into more of these questions as I start writing a simulator application on top of the engine (that's really when I start modelling "real world" entities and relations). As of yet I've only actually dealt with concurrency issues. For many of the features I'm trying to implement in the engine, concurrency is a must and of course I find that Erlang is the perfect language for the job! My idea is, by the way, to allow objects to be implemented to run on an engine process or on one or more dedicated processes in a dynamic fashion. I'm looking forward to start experimenting with this, but so far I'm only half way with the engine. It's great fun! /Peter Vlad Dumitrescu wrote: > > The "thread thread" is very interesting, and talking about OO reminded me of > an idea I got... I think it's not a very bad one, so I will share it with > you, to see what you think. > > The OO methodology can be easily applied to Erlang, once one gets to ffel > the pulse of the language. There is however one thing that is missing, and > that I think it could be useful. That thing is inheritance. > > The natural way for inheritance to be implemented in Erlang isn't the C++ > way, but the CLOS way, through some kind of generic functions. A better name > than inheritance might be "shared implementation between modules". An > example might be appropriate. > > -module(base). > > fun1(blip) -> foo; > fun1(A) -> {empty, A}. > > ==== and (the syntax is just a proposal) > > -module(base_extended). > -extend({base, [fun1]}). > > fun1({help}) -> hohoho; > -inherited(). %% need not be always present > fun1(_) -> false. > > The meaning would be that the clauses of base:fun1 are imported into the > ones of base_extended:fun1, allowing some of them or all to be overriden. > The gain would be for example that when extending the lists module, one only > needs to write implementations for the functions that are different. > > There are problems with the above way of doing it, I know. One might want to > reorder clauses, or to keep only part of the inherited ones... But it is the > general idea that I'd like to discuss. > > As someone said earlier (Ulf I think), this creates dependencies between > modules. This isn't always a Good Thing. But on the other hand, when writing > a gen_server, there is a dependency upon the gen_server module... When > trying to implement a module based on another (and that can be used instead > of the other), avoiding to write 50 stub functions that just delegate he job > for the 2 or 3 that need rewriting is kind of a waste. Plus att the compiler > might be able to optimize the calls. > > It's almost midnight, and I'm not very sure I managed to explain properly. > > I look forward to find out what a wonderful idea you all thin this is :-) > > Or alternatively, to find out why it is such a bad idea! > > regards, > Vlad > _____________________________________________________________________________________ > Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From icsm2001@REDACTED Wed Nov 29 11:25:43 2000 From: icsm2001@REDACTED (icsm2001 (NESI)) Date: Wed, 29 Nov 2000 11:25:43 +0100 (MET) Subject: IEEE Int.Conf. Software Maintenance., Florence,Italy,ICSM2001 Message-ID: <200011291025.LAA28832@dsiI.dsi.unifi.it> Dear Colleague I would like to invite you at the IEEE International Conference on Software Maintenance, 2001, and associated workshops: SCAM, WESS, WSE, etc. next November 2001 in Florence, Italy. Outstanding Keynotes such as: Prof. David Lorge Parnas and Prof. Dieter Rombach. Industrial papers and experiences, reseach papers and award, tutorials, tool expositions, dissertation forum and award, workshops, panels, and other exciting activities have been planned. I hope that this CFPs could be useful for your work. Please forward the following to anybody who you think may be interested. Apologies if you have already seen this. If you would like to be removed from our list please send an email to icsm2001@REDACTED with REMOVE in the subject. ICSM2001 Paolo Nesi (General Chair) =_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_= CALL---FOR---PAPER$ IEEE International Conference on Software Maintenance 2001 FLORENCE, ITALY, 6-10 November 2001 http://www.dsi.unifi.it/icsm2001 Theme: Systems and Software Evolution in the era of the Internet =_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_= Sponsored by IEEE Supported bt the: EC-IST, University of Florence, O-Group ICSM is the major international conference in the field of software and systems maintenance, evolution, and management. In the era of the Internet, businesses and end-users have invested in new technologies and small and large software organizations around the world are looking for Internet related solutions to evolve and maintain their new Internet software products. Internet technologies are strongly impacting system architectures and business processes and rules. In some cases businesses and end-users have been overwhelmed trying to keep up with software development and evolution processes and practices. In addition to novel solutions to enable the life-cycle of new web-based software systems, huge investments are necessary to migrate aginglegacy applications to web-enabled contemporary systems. ICSM 2001 will address these major changes in the software landscape and their impact on maintenance and evolution. The focus of the conference will be to explore the new challenges that the Internet, as a driver for business changes, poses for software maintenance, and the new opportunities it opens as infrastructure and enabling technology. The purpose of the conference is to promote discussion and interaction between researchers and practitioners. We are particularly interested in exchanging concepts, prototypes, research ideas, and other results which could contribute to the academic arena and also benefit business and the industrial community. ICSM 2001 will be participatory, with working collaborative sessions and presentations of industry projects. ICSM 2001 will bring together researchers, practitioners, developers and users of tools, technology transfer experts, and project managers. The Conference will be held in conjunction with: WESS -- the seventh Workshop on Empirical Studies of Software Maintenance. SCAM -- Source Code Analysis and Manipulation WSE -- Workshop on WEBsite Evolution Other workshops are welcome according to the limited available slots. Topics of interest include but are not restricted to the following aspects of maintenance and evolution: - Methods and theories -Processes and strategies - Organizational frameworks -Life cycle and process control - Design for maintenance -Tools and environments - Internet and distributed systems -Multimedia systems - User interface evolution -Commercial off-the-shelf (COTS) - Third party maintenance -Freeware and open source applications - Program comprehension -Software and system visualization - Knowledge based systems -Formal methods - Impact of new software practices -Empirical studies - Software reusability -Programming languages - Source code analysis and manipulation -Testing and regression testing - Models and methods for error prediction -Measurement of software - Maintenance and/or productivity metrics -Preventive maintenance - Personnel aspects of maintenance -Reengineering and reverse engineering - Version and configuration management -Legal aspects and standards - Management and organization -Remote, tele-work, and co-operative applications RESEARCH PAPERS Research papers should describe original and significant work in the research and practice of software maintenance. Research case studies, empirical research, and experiments are particularly welcome. We also welcome papers that present leading edge and novel ideas in maintenance. Papers should be 2000 - 5000 words in length, in English. Submit them in PDF or PostScript via email to icsm2001@REDACTED by 15 January 2001. A prize of the Journal of Software Maintenance will be assigned at the Best submitted Paper. INDUSTRIAL APPLICATIONS We welcome proposals for presentations of Industrial Applications. These can be experience reports from real projects, industrial practices and models, or tool demonstrations. Submit proposals for Industrial Application presentations via email to icsm2001.industry@REDACTED by 12 March 2001. Industrial Applications proposals will be reviewed by a dedicated sub-committee of the program committee and a 1 page summary of accepted proposals will be included in the conference proceedings. EXPOSITION AREA An exposition are is present in which tools realted to industrial applications can be shown. Please contact: nesi@REDACTED 1 page summary of accepted tools will be included in the conference proceedings. DISSERTATION FORUM We welcome submissions of young researchers that have delivered their dissertation (degree, master or Ph.D.) in the last three years. Please submit the PDF of the dissertation to icsm2001@REDACTED by 15 January 2001. An Award and a full support to attend the conference will be given to the prize winner. Two other free registrations will be assigned at the second and third. 4 pages summary of accepted dissertations will be included in the conference proceedings and a special forum section will be organised at the conference. TUTORIALS Tutorials should present software maintenance and evolution topics of interest to practitioners. Tutorials may be full-day or half-day in length. Submit tutorial proposals via email to icsm2001.tutorial@REDACTED by 12 February 2001. 1 page summary of accepted tutorial will be included in the conference proceedings. IMPORTANT DATES, DEADLINES Research Paper submission 15 January 2001, notification of acceptance 1 June 2001 Dissertation submission 15 January 2001 Industrial Application submission 12 March 2001 Tools request and submission 12 March 2001 Tutorial submission 12 February 2001 ------------------------------ General chair: Paolo Nesi, University of Florence, Italy, nesi@REDACTED Financial chair: Vaclav Rajlich, Wayne State University, USA, vtr@REDACTED Program co-chairs: Gerardo Canfora, University of Sannio, Italy, gerardo.canfora@REDACTED Anneliese von Mayrhauser, Colorado State University, USA, avm@REDACTED Tutorials co-chairs: Lionel C. Briand, Carleton University, briand@REDACTED Alessandro Fantechi, University of Florence, Italy, Fantechi@REDACTED Industrial Applications co-chairs: Panagiotis K. Linos, Butler University, Department of Computer Science and Software Engineering, Indianapolis USA, linos@REDACTED, www.butler.edu/~linos Harry Sneed, Independent Consultant, Germany, Harry.Sneed@REDACTED Chris Verhoef, Free University Amsterdam, NL, x@REDACTED Publicity co-chairs: Nicholas Zvegintzov (General Co-chair), Software Management Network, USA, zvegint@REDACTED Malcolm Munro (Co-chair for Europe), University of Durham, UK, malcolm.munro@REDACTED William Cheng-Chung Chu (Co-chair for East), TungHai University, Taiwan, chu@REDACTED Local Arrangements co-chairs: Fabrizio Fioravanti, University of Florence, Italy, fioravan@REDACTED Pierfrancesco Bellini (Industrial Applications, and Demos), University of Florence, Italy, bellini@REDACTED Marius Bogdan Spinu, University of Florence, Italy, spinu@REDACTED -------------------------------------------------------------------------------------------------------------- From Chandrashekhar.Mullaparthi@REDACTED Wed Nov 29 12:35:08 2000 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Wed, 29 Nov 2000 11:35:08 -0000 Subject: the OO metaphor Message-ID: <402DD461F109D411977E0008C791C31202A797D8@imp02mbx.one2one.co.uk> I think polymorphism can be implemented by modelling objects using records, and a field in the record specifying the module which implements the interface exported by the object. -record(object, {interface, instance}). -record(rectangle, {length, width}). -record(circle, {radius}). To create an object of type rectangle - you would write #object{interface=rectangle, instance=#rectangle{length=2, width=3}}. To create a circle - #object{interface=circle, instance=#circle{radius=4}}. So if you have a shape and want to draw it: Shape#object{interface=I, instance=Obj}, Action=draw, apply(I, Action, [Obj]) or apply(I, Action, [Obj, ]) as the case may be. Now if you have a base class called shape - you can call functions defined in it from your "derived class implementation". You can even store an instance of your "base class object" in the instance of your "derived class object" like.. -record(rectangle, {length, width, shape}). RTTI can be supported by exporting a function called type from the interface module!! As for being able to override functions in other modules, maybe the existing "-import" directive can be extended. -module(my_module). -import(Mod, Func/Arity). will import all clauses of the specified function. If this module defines a function with the same name and arity, that will "override" the implementation of the imported function. And in case none of the clauses in the "overridden" version match the call, it can be routed to Mod:Func(...). This will also cover the case where no implementation is provided for imported functions by my_module. -import(Mod, all). will import all functions from module Mod. Chandru NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From tobbe@REDACTED Wed Nov 29 12:56:02 2000 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 29 Nov 2000 12:56:02 +0100 Subject: the OO metaphor In-Reply-To: Karlsson Mikael's message of "Wed, 29 Nov 2000 10:46:48 +0100 (MET)" References: <200011290946.KAA06611@nic.era-a.ericsson.se> Message-ID: Just for the record. Someone once implemented inheritance in Erlang by writing his own error_handler. So assume you want inherit from another module x.erl the add a function base/0 in your y.erl module. Then, let's say x:foo/0 exists but not y:foo/0. When calling y:foo/0 the (tailor-made) error_handler will be invoked. The error_handler extracts the 'base-class' by calling X=y:base/0 and then calls X:foo/0, etc... Cheers /Tobbe From Peter.Andersson@REDACTED Wed Nov 29 14:12:18 2000 From: Peter.Andersson@REDACTED (Peter Andersson) Date: Wed, 29 Nov 2000 13:12:18 +0000 Subject: the OO metaphor References: <402DD461F109D411977E0008C791C31202A797D8@imp02mbx.one2one.co.uk> Message-ID: <3A2500B2.3EA06BFF@eei.ericsson.se> Hi Chandru, Thanks for the input! Actually I already use the representation you suggest, with slight modification. I have a tuple of a Ref and a State record representing an object and, like in your example, do apply to "invoke" it by using a type field in Ref (your version is cleaner!). I didn't really think of this as polymorhism, but I guess that's exactly what it is, as far as "invokation" is concerned anyway. Deferring functions is the hard part to do nicely, I guess. I don't know which alternative I would prefer, using funs, an extended import directive or a modified error handler. I think the most important thing is that the code is still readable and not too complicated to debug (like Sean said). Writing a control framework for invoking the objects with a simple catch to determine if the function is deferred or not, is tempting. But maybe a mandatory interface function for each class module which returns a list of the functions the sub class module redefines (and from which super class) can make the code clearer. Also, perhaps this way the control framework could do the invokations in a more "controlled" way, rather than acting upon trapped faults. For the record, I *have* to say that I only find this interesting in the case I want to use Erlang to implement something for solving a problem in the domain of *both* OO and concurrency, like this simulator thing of mine. I *want* to use Erlang for any type of concurrent implementation, but if the problem is pure OO, I think I'll choose an OO language to implement the solution in. I find it much more common, though, that the problems I'm interested in can (and should be) solved with a "functional approach". In these cases I'm glad to not have to bother with any OO constructs and overhead. Regards /Peter Chandrashekhar Mullaparthi wrote: > > I think polymorphism can be implemented by modelling objects using records, > and a field in the record specifying the module which implements the > interface exported by the object. > > -record(object, {interface, instance}). > > -record(rectangle, {length, width}). > -record(circle, {radius}). > > To create an object of type rectangle - you would write > #object{interface=rectangle, instance=#rectangle{length=2, width=3}}. > > To create a circle - > #object{interface=circle, instance=#circle{radius=4}}. > > So if you have a shape and want to draw it: > > Shape#object{interface=I, instance=Obj}, > Action=draw, > apply(I, Action, [Obj]) or > apply(I, Action, [Obj, ]) as the case may be. > > Now if you have a base class called shape - you can call functions defined > in it from your "derived class implementation". You can even store an > instance of your "base class object" in the instance of your "derived class > object" like.. > > -record(rectangle, {length, width, shape}). > > RTTI can be supported by exporting a function called type from the interface > module!! > > As for being able to override functions in other modules, maybe the existing > "-import" directive can be extended. > > -module(my_module). > -import(Mod, Func/Arity). > > will import all clauses of the specified function. If this module defines a > function with the same name and arity, that will "override" the > implementation of the imported function. And in case none of the clauses in > the "overridden" version match the call, it can be routed to Mod:Func(...). > This will also cover the case where no implementation is provided for > imported functions by my_module. > > -import(Mod, all). will import all functions from module Mod. > > Chandru > > NOTICE AND DISCLAIMER: > This email (including attachments) is confidential. If you have received > this email in error please notify the sender immediately and delete this > email from your system without copying or disseminating it or placing any > reliance upon its contents. We cannot accept liability for any breaches of > confidence arising through use of email. Any opinions expressed in this > email (including attachments) are those of the author and do not necessarily > reflect our opinions. We will not accept responsibility for any commitments > made by our employees outside the scope of our business. We do not warrant > the accuracy or completeness of such information. From Sean.Hinde@REDACTED Wed Nov 29 16:07:51 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Wed, 29 Nov 2000 15:07:51 -0000 Subject: the OO metaphor Message-ID: <402DD461F109D411977E0008C791C3125653E1@imp02mbx.one2one.co.uk> Peter, > Erlang for any type of concurrent implementation, but if the > problem is pure OO, I'd be interested to see an example of what you consider to be a pure OO problem, or if not, what criteria you would apply to decide which would be the most appropriate methodology Rgds, Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From Peter.Andersson@REDACTED Wed Nov 29 18:13:07 2000 From: Peter.Andersson@REDACTED (Peter Andersson) Date: Wed, 29 Nov 2000 17:13:07 +0000 Subject: the OO metaphor References: <402DD461F109D411977E0008C791C3125653E1@imp02mbx.one2one.co.uk> Message-ID: <3A253923.509C494A@eei.ericsson.se> Hi Sean, Darn, I should never have used the words 'any' or 'pure' - that's asking for trouble! :) It's more the nature of the problem itself and the model of a possible solution to it, that points me in some sort of direction, I guess. I have no formal criterias to use and I try to be objective and learn from my own and others experience. I've heard motivations for using an object oriented model and implementation for "any" type of problem because it gives you modularity, encapsulated information, etc. I don't agree with this at all. I can achieve most of these features with any language really, it's more a matter of programming style. Ok, an OO model and implementation may force me to encapsulate data and define clear relationships between my entities and therefore help me produce robust and maintainable code. However, if I need to twist a straightforward and intuitive model around to fit it into an OO model, I think this only results in even bigger problems. Especially if I start defining unintuitive inheritance relationships between classes just to avoid redefining methods! To model "real/fantasy world" objects and relations, I belive OO methods can be very helpful. If I didn't need the concurrency features of my simulator system, I would implement it in an OO language. Why? Because I use what very much looks like an OO model to define the world I'm going to simulate and it feels more intuitive to implement the system using a language with existing OO support rather than to think up new Erlang constructs that enable e.g. class inheritance. This probably doesn't answer your question at all. I think someone with more experience of working with OO modelling and implementation could give you more relevant examples of when OO methology is the best to use. Someone once worked hard on convincing me that design patterns was the most important thing that had ever happened to the world of computing and that without OO languages, design patterns could not be applied. I read a bit about these patterns and I thought they were abstract enough to be applied to any model to be implemented by most languages that have good modularity support. /Peter Sean Hinde wrote: > > Peter, > > > Erlang for any type of concurrent implementation, but if the > > problem is pure OO, > > I'd be interested to see an example of what you consider to be a pure OO > problem, or if not, what criteria you would apply to decide which would be > the most appropriate methodology > > Rgds, > Sean > > NOTICE AND DISCLAIMER: > This email (including attachments) is confidential. If you have received > this email in error please notify the sender immediately and delete this > email from your system without copying or disseminating it or placing any > reliance upon its contents. We cannot accept liability for any breaches of > confidence arising through use of email. Any opinions expressed in this > email (including attachments) are those of the author and do not necessarily > reflect our opinions. We will not accept responsibility for any commitments > made by our employees outside the scope of our business. We do not warrant > the accuracy or completeness of such information. From mike@REDACTED Wed Nov 29 18:37:27 2000 From: mike@REDACTED (Mike Williams) Date: 29 Nov 2000 17:37:27 GMT Subject: the OO metaphor References: <200011290946.KAA06611@nic.era-a.ericsson.se>, Message-ID: <903esn$132$1@news.du.uab.ericsson.se> In article , tobbe@REDACTED (Torbjorn Tornkvist) writes: |> |> Just for the record. Someone once implemented |> inheritance in Erlang by writing his own error_handler. True, but definitely NOT TO BE RECOMMENDED!!! Just to start with, standard code loading stops working. It also encourages a horrible, incomprehensible programming style and every time the error handler is invoked you get a huge processing overhead. I had to get rid of the "Someone who once implemented inheritance" this way from the project concerned before I could return it to some limitted form of sanity. /Mike From Sean.Hinde@REDACTED Wed Nov 29 21:32:28 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Wed, 29 Nov 2000 20:32:28 -0000 Subject: the OO metaphor Message-ID: <402DD461F109D411977E0008C791C3125653EE@imp02mbx.one2one.co.uk> Hi Peter, Not a comment on pureness really, just interested. > I think this only results in even bigger problems. Especially > if I start defining > unintuitive inheritance relationships between classes just to > avoid redefining > methods! The bit I struggle with is that it is all very nice designing a clean object hierarchy with nicely encapsulated data, but by the time the system has reached release 23 and every second requirement is orthogonal to the last few this all falls apart and the system starts to resembles linguine. FP/Erlang doesn't prevent this, but it seems to allow much more flexibility to glue things together in different easily understood and maintainable ways without breaking the underlying methodology in the ways you describe. My observation of any number of decent sized custom IT systems/projects is that there seems to be a maximum number of iterations they can go through before (cost of change / unreliability) > (cost of throwing them away and starting again). Anything which delays this cutoff time is of enormous value as the inevitable consequence is delay in providing new functionality with the resulting negative impact on a business (not to mention the straight financial and management cost). See press for details! I guess this is little different for the company making widgets containing software. Rant over - I'm sure this is all done to death in comp.lang.{functional || object} anyway. - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From tobbe@REDACTED Wed Nov 29 23:26:13 2000 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 29 Nov 2000 23:26:13 +0100 Subject: the OO metaphor In-Reply-To: mike@erix.ericsson.se's message of "29 Nov 2000 17:37:27 GMT" References: <200011290946.KAA06611@nic.era-a.ericsson.se> <903esn$132$1@news.du.uab.ericsson.se> Message-ID: > I had to get rid of the "Someone who once implemented inheritance" > this way from the project concerned before I could return it to some > limitted form of sanity. ....laugh....more laugh... :-) /Tobbe From vladdu@REDACTED Thu Nov 30 00:31:53 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Thu, 30 Nov 2000 00:31:53 +0100 Subject: the OO metaphor Message-ID: Wow, what a response! :-) Always nice to be able to start a debate! I sat and told a bedtime story to my son, while thinking about this OO/Relang issue... and when opening the mail and reading it, I was struck by the similarity between what I wanted to say and what Ulf said. Polymorphism and up to a point inheritance can be easily simulated in Erlang, if one uses direct messages to processes. But the recommended and better way is to have a functional wrapper that will communicate with the process, and by using it one has to rewrite all the delegation functions, which is tedious and a maintenance problem. The similarity I was talking about lies in that I came up thinking in terms of interfaces too, and inheriting/extending them. My 10 ?re of inspiration tonight amount to the insight that there are 2 logical kinds of modules: function libraries (like lists) and interfaces to processes. The latter correspond roughly to an object interface in the OO metaphor, while the former are just a gathering of related code. The latter are also the ones one would want to be able to extend transparently (i.e. inherit from the object and use it polymorphically). $inherit_api (or something similar) would be a nice and clean way to handle this issue. On the other hand, interfaces that are shared like this create also problems: for example, what happens if an interface that is extended by many other has to be changed in a non-compatible way? There are solutions, of course - the point is that there may be more things to think about than one sees first... Just don't ask me where do I want to get to with all this... I wish I remembered the conclusion myself! :-) To comment on Ulf's system_erlang ideas, I think those mechanisms would be useful, and might even provide support for more things than those they are intended for. regards, Vlad _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From vladdu@REDACTED Thu Nov 30 00:37:08 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Thu, 30 Nov 2000 00:37:08 +0100 Subject: patches Message-ID: will the patches be incorporated in a new release? or is it just up to each one of us to recompile? Personally I'd prefer a R7B-1 release, precompiled and ready to run... regards, Vlad _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From Peter.Andersson@REDACTED Thu Nov 30 10:49:54 2000 From: Peter.Andersson@REDACTED (Peter Andersson) Date: Thu, 30 Nov 2000 09:49:54 +0000 Subject: JIT Message-ID: <3A2622C2.D8705E31@eei.ericsson.se> Hi folks, Could anyone tell me something about the JIT (just in time compiler) component of the Java VM? I haven't worked with Java myself and don't really know any details about its VM. I have heard claims that the JIT makes Java code (or parts of it?) run very fast and that the runtime compilation itself (from byte->native code, I guess) has virtually no overhead from an application point of view. I would like to know more. E.g. how does JIT relate to HiPE? /Peter From rv@REDACTED Thu Nov 30 11:22:46 2000 From: rv@REDACTED (Robert Virding) Date: Thu, 30 Nov 2000 11:22:46 +0100 Subject: clarification on single assignment In-Reply-To: Your message of "Fri, 24 Nov 2000 13:22:34 +0100." Message-ID: <200011301022.LAA17600@trana.bluetail.com> Hakan Mattsson writes: > >You mean as perverse as the spurious ';' separator? ;-) Well, actually the semantics of the "spurious ';' separator" is quite clear and consistent, it is a sequential or operator between clauses. Perhaps you are referring to the fact that it is a separator and not a terminator, personally I have never had any trouble with that. I suppose we could make it a terminator if you really want, however, if you are willing to go through all code and add one to each final clause in every function definition and if/case/receive. :-) Otherwise trying writing as I have seen Richard O'Keefe does: case of -> ... ; -> ... ; -> ... end, which looks a little odd but is very logical. I don't think Erlang mode supports it though. >The semantics of the '=' operator depends of its context, but the '.' >could not be reused as separator between function clauses!? What is wrong with a whole function as one unit and not as a disjoint collection of clauses? It is much clearer than allowing clauses to be separated. The trouble with generally using '.' as an operator is that it can occur within a token, a float, and using it as operator can cause confusion. Prolog has/had it as the list operator so you could write a.b.c.d.[] instead of [a,b,c,d]. How do you parse 1.2.3.4.[]? Forcing blanks occasionally sucks. (I know it is necessary now, but it still sucks) >Perverse or not, I think that the different semantics of the '=' >operator in its various contexts (match/assign), is a little bit >confusing. The bad example below does not work as you already pointed >out, but both the ugly ones does. It is not intuitive. Yes, I know, '=' is used in three contexts: Explicit match operator Couple record field name to value/pattern Aliases in patterns. The trouble is that there is a limited number of symbols on the keyboard so there will be overloading. > ugly() -> > B = #type{name = 3}, > fun(A = #type{name = Value}) -> Value end(B). > > ugly2() -> > B = #type{name = 3}, > case B of > A = #type{name = Value} -> Value > end. I personally can't conceive why anyone would write aliases in patterns in that direction, I always do it the other way: ugly() -> B = #type{name = 3}, fun(#type{name = Value}=A) -> Value end(B). Writing it this way means you have the same semantics as for a normal explicit match, take the value of "A" and match it with the record ... This then only gives two uses. I was much to lenient with the syntax and didn't realise what people would do with it. Though after all these years you would think that I would learn. It ought to be changed. So remember: ALWAYS WRITE PATTERN ALIASES AS =!! Hmm, maybe lint should warn? :-) Robert From kent@REDACTED Thu Nov 30 12:19:13 2000 From: kent@REDACTED (Kent Boortz) Date: 30 Nov 2000 12:19:13 +0100 Subject: patches In-Reply-To: "Vlad Dumitrescu"'s message of "Thu, 30 Nov 2000 00:37:08 +0100" References: Message-ID: We will create Linux binary RPM's and FreeBSD packages from the latest source release together with the latest patches. I'm just completing the scripts to create them without manually altering specification files etc. Is binary packages like that what you preferred? We will create new source releases mainly when the bootstrap compiler need changes. We can't patch BEAM files with the Unix patch program. The windows version is a problem. I have no solution how to create new OpenSource Windows binary releases at the moment. kent From mickael.remond@REDACTED Thu Nov 30 12:47:49 2000 From: mickael.remond@REDACTED (Mickael Remond) Date: 30 Nov 2000 12:47:49 +0100 Subject: patches In-Reply-To: Kent Boortz's message of "30 Nov 2000 12:19:13 +0100" References: Message-ID: <87r93tfzq2.fsf@western.ird.idealx.com> On 30 Nov 2000, kent@REDACTED wrote: > We will create Linux binary RPM's and FreeBSD packages from the latest > source release together with the latest patches. I'm just completing > the scripts to create them without manually altering specification > files etc. Is binary packages like that what you preferred? In fact, what I personnaly prefers is a source package with the newest patch applied, so that I can recompile the source code without worrying about applying all the patches. -- Micka?l R?mond - mickael.remond@REDACTED - http://IDEALX.com - +33 (1) 44 42 00 38 From vladdu@REDACTED Thu Nov 30 13:02:31 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Thu, 30 Nov 2000 13:02:31 +0100 Subject: patches Message-ID: >Is binary packages like that what you preferred? >The windows version is a problem. I have no solution how to create >new OpenSource Windows binary releases at the moment. Yes, and :-( because it was Windows I most wanted... I can compile the distribution on my machine, but I feel a little unsure whether the results are correct or not. It seems to work, but the sizes of the binaries are slightly different... thanks anyway. Vlad _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com From kent@REDACTED Thu Nov 30 15:48:30 2000 From: kent@REDACTED (Kent Boortz) Date: 30 Nov 2000 15:48:30 +0100 Subject: patches In-Reply-To: Mickael Remond's message of "30 Nov 2000 12:45:52 +0100" References: <87vgt5fztb.fsf@western.ird.idealx.com> Message-ID: > In fact, what I personnaly prefers is a source package with the newest patch > applied, so that I can recompile the source code without worrying about > applying all the patches. Ok, we discussed this and decided to change the way we release the OpenSource Erlang/OTP: 1. We release fully tested source base releases. This is R7B-0, R8A-0, i.e. those ending in "-0". 2. We release selected source snapshots. This is snapshots that contains important changes and that passed the testing. These snapshots will be named R7B-1, R7B-2, ...... 3. We will release combined patches, i.e. one large patch that patch from R7B-0 to R7B-1, a second one from R7B-1 to R7B-2 etc. Note that the result after patching will not be *exactly* the same as the snapshot. Some precompiled BEAM files in the bootstrap part may differ. 4. When a move from one source release to the next require changes in the bootstrap compiler, then there will be no patch to upgrade. This forces a complete source release download with the correct binary BEAM files. 5. Binary releases for Linux, FreeBSD and Windows will be built from the complete source snapshots, i.e. not from a base source release with applied patches. Is this ok? kent From jamesh@REDACTED Thu Nov 30 16:31:13 2000 From: jamesh@REDACTED (James Hague) Date: Thu, 30 Nov 2000 09:31:13 -0600 Subject: Bit syntax endianness confusion Message-ID: <3.0.32.20001130093112.01049ee0@volition-inc.com> Suppose I have a binary that contains a 32-bit word stored in big endian (network) order. This word contains three fields in this order: 10 bits, 4 bits, and 18 bits. Matching this is easy: <> = Binary. Now, suppose this word is stored in little endian order. How would I match it? This isn't right: <> = Binary. Or is it? Actually, how would the following be interpeted: <> = Binary. where the first and last fields are little endian but the middle one isn't? I get the impression that the "little" qualifier reverses bitfields, but I need something higher level than that. I want to be able to say that the entire word is stored in little endian order. Do I need to do some swizzling first, by interpreting the binary as four bytes, creating a new binary with the bytes reversed, and then matching against the original pattern? James From boisvert@REDACTED Thu Nov 30 16:32:49 2000 From: boisvert@REDACTED (Alex Boisvert) Date: Thu, 30 Nov 2000 07:32:49 -0800 Subject: threads - use them as much as you can Message-ID: <3A267321.2CBF101D@intalio.com> I'm picking up a thread from this week to ask further questions. I'm new to Erlang and I couldn't find the answers in the documentation. The background context is that I'm currently investigating Erlang's ability to scale on a significant database-related (lots of I/O, lots of parallel execution) research project. In this regard I have two questions: 1) Multiprocessing (SMP) I understand Erlang's processes are not necessarily bound to operating systems (native) processes or threads (and see the benefits). What I would like to know is if the implementation(s) actually make use of native threads (or processes) to achieve parallel execution on SMP systems? Of course, this may vary from one OS to another. 2) Scalable I/O Do the underlying I/O mechanisms of the VM use scalable I/O primitives such as select() or poll()? (or aio_*() -- asynchronous I/O). Also, this question is somewhat tied to the first, since if only one native threads is used and regular blocking I/O is used, then all processes would be "suspended" until that particular I/O completes. Any information or pointers to RTFM will be appreciated. alex. From mickael.remond@REDACTED Thu Nov 30 16:59:25 2000 From: mickael.remond@REDACTED (Mickael Remond) Date: 30 Nov 2000 16:59:25 +0100 Subject: patches In-Reply-To: Kent Boortz's message of "30 Nov 2000 15:48:30 +0100" References: <87vgt5fztb.fsf@western.ird.idealx.com> Message-ID: <87aeahfo2q.fsf@western.ird.idealx.com> On 30 Nov 2000, kent@REDACTED wrote: > Ok, we discussed this and decided to change the way we release the > OpenSource Erlang/OTP: [...] > Is this ok? Yes. This sounds to be a very good scheme. -- Micka?l R?mond - mickael.remond@REDACTED - http://IDEALX.com - +33 (1) 44 42 00 38 From alexis@REDACTED Thu Nov 30 17:37:46 2000 From: alexis@REDACTED (=?iso-8859-1?Q?Alexis_L=EA-Qu=F4c?=) Date: Thu, 30 Nov 2000 11:37:46 -0500 Subject: patches References: <87vgt5fztb.fsf@western.ird.idealx.com> Message-ID: <001001c05aeb$df3041b0$38fea8c0@neomeo.com> A newbie question: Are there any issues with the BEAM files being different? I'm not very familiar with the Erlang build process (aside from having run ./configure; make; make install), but it seems that having different bootstraping code could lead to different results. Alexis Le-Quoc ----- Original Message ----- From: "Kent Boortz" To: "Mickael Remond" Cc: Sent: Thursday, November 30, 2000 9:48 Subject: Re: patches [...] > 3. We will release combined patches, i.e. one large patch that > patch from R7B-0 to R7B-1, a second one from R7B-1 to R7B-2 > etc. Note that the result after patching will not be *exactly* > the same as the snapshot. Some precompiled BEAM files in the > bootstrap part may differ. [....] From Sean.Hinde@REDACTED Thu Nov 30 18:35:52 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 30 Nov 2000 17:35:52 -0000 Subject: threads - use them as much as you can Message-ID: <402DD461F109D411977E0008C791C312565407@imp02mbx.one2one.co.uk> Alex, > 1) Multiprocessing (SMP) You are correct that Erlang processes exist entirely within the virtual machine. It is certainly possible to run more than one instance of Erlang (with different node names) on a single machine and use Erlang message passing to communicate between them. Shared memory and native Erlang threads are in the realms of research at the moment. > 2) Scalable I/O > > Do the underlying I/O mechanisms of the VM use scalable I/O primitives > such as select() or poll()? (or aio_*() -- asynchronous I/O). As I understand the VM uses select but in a way that returns immediately. The virtual machine scheduler check regularly for input. Language level i/o operations are implemented such that only a limited chunk of the i/o is carried out at one time by the libraries/VM, which normally guarantees that it doesn't block for very long. (however looking at a file over a slow NFS mount for example can hang the emulator). > Also, this question is somewhat tied to the first, since if only one > native threads is used and regular blocking I/O is used, then all > processes would be "suspended" until that particular I/O completes. In R7B (the current release) there is a new feature which introduces a pool of native threads for i/o operations but this is disabled by default. This will get around the hanging problem but at the moment is supposed to be quite slow for database work due to the large amount of context switching involved (I've not tested it myself yet so don't know the scale). I guess this will improve in forthcoming releases. http://www.erlang.org/doc/current/doc/highlights.html Having said all that from your brief description your application seems to be well and truly the kind of application Erlang is designed for. Welcome! -Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From Sean.Hinde@REDACTED Thu Nov 30 20:33:37 2000 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 30 Nov 2000 19:33:37 -0000 Subject: sockets and multiple interfaces Message-ID: <402DD461F109D411977E0008C791C31256540A@imp02mbx.one2one.co.uk> Guys, > > Option {ip, Ipddr} will bind the socket to the > > interface which has ipaddress IpAddr. > > > > Use the new name {ifaddr, Ipaddr} instead !!! It would also be a nice feature to be able to restrict access to a set of originating IP adresses or address ranges (as a basic security mechanism). I've no idea if or how this is supported by the underlying OS. Some nice option like {accept_from, [{10,1,2,3}, {10,2,0,0}]} would do it :) In my application at the moment I accept the connection and if it is not from an allowed address disconnect it immediately. I have seen an unfriendly client doing retries as fast as it can running on a very fast machine knock a node over. Views? Feasibility? - Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From vladdu@REDACTED Thu Nov 30 23:55:31 2000 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Thu, 30 Nov 2000 23:55:31 +0100 Subject: patches Message-ID: >Ok, we discussed this and decided to change the way we release the >OpenSource Erlang/OTP: sounds good to me! (although having an out-of-the-box compileable-on-WIndows distribution would be even better :-) /Vlad _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com