From alexis@REDACTED Thu Feb 1 03:48:37 2001 From: alexis@REDACTED (=?iso-8859-1?Q?Alexis_L=EA-Qu=F4c?=) Date: Wed, 31 Jan 2001 21:48:37 -0500 Subject: Curious behaviour in gen_tcp, an update... Possible bug in erts Message-ID: In erts/emulator/drivers/common/inet_drv.c:4026, there is a call to tcp_recv(desc, n). /*********************************/ if (tcp_recv(desc, n) == 0) { if (timeout == 0) async_error_am(INETP(desc), am_timeout); else { if (timeout != INET_INFINITY) driver_set_timer(desc->inet.port, timeout); sock_select(INETP(desc),(FD_READ|FD_CLOSE),1); } return ctl_reply(INET_REP_OK, tbuf, 2, rbuf, rsize); /*********************************/ The problem is that tcp_recv() can return -1 if the buf allocation (line 4518) fails, which happens when I try to read megabytes of data through the socket, using binaries. I don't have a patch available, but I suspect that adding a test for tcp_recv would be a fix, as well as the appropriate error/clean-up handler. I can provide test cases if requested (erlang and python). Also, I'm referring to the latest source code R7B-1. Cheers, Alexis From sakou@REDACTED Thu Feb 1 08:34:22 2001 From: sakou@REDACTED (sakou@REDACTED) Date: Thu, 01 Feb 2001 16:34:22 +0900 Subject: Bluetail Ticket Tracker questions Message-ID: <20010201163422sakou@mail.jp.fujitsu.com> Hi, I am searching web based bug tracking tool to use our project. Bluetail Ticket Tracker looks like better than other tools. But I have some question about BTT. 1. Is it possible to add a new field to form of a bug report? (ex. FREQUENCY,VERSION,,,) 2. Can BTT e-mail to inform the one who is assigned when someone issues a bug report? 3. Can you get a graphic chart? 4. Is it possible to search with any combination of field data of a bug report? Can regular expression be used when you do 'search'? 5. Can you attach any type of file (ascii,binary) to a bug report? Thanks From Chandrashekhar.Mullaparthi@REDACTED Thu Feb 1 12:57:09 2001 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Thu, 1 Feb 2001 11:57:09 -0000 Subject: Wishes: hex-output Message-ID: <402DD461F109D411977E0008C791C31203919938@imp02mbx.one2one.co.uk> These functions can probably be added to lists or string. to_lower(Str) -> to_lower(Str, []). to_lower([H|T], Acc) when H>=65, H =< 90 -> to_lower(T, [H+32|Acc]); to_lower([H|T], Acc) -> to_lower(T, [H|Acc]); to_lower([], Acc) -> lists:reverse(Acc). to_upper(Str) -> to_upper(Str, []). to_upper([H|T], Acc) when H>=97, H =< 122 -> to_upper(T, [H-32|Acc]); to_upper([H|T], Acc) -> to_upper(T, [H|Acc]); to_upper([], Acc) -> lists:reverse(Acc). regards, Chandru > -----Original Message----- > From: Robert Virding [mailto:rv@REDACTED] > Sent: 18 January 2001 10:14 > To: Erik Johansson > Cc: erlang-questions@REDACTED; Jouni.Ryno@REDACTED > Subject: Re: Wishes: hex-output > > > "Erik Johansson" writes: > > > >----- Original Message ----- > >From: > >> > >> If it's going to be late Christmas season, and one could make some > >> wishes, what about hex-output for io:format > >> > > > >Yes. I have always needed this. I use ~h and ~H. With the > patch below you > >can do: > >> io:format("~h 0x~H 16#~h\n", [51966, 51966, 51966]). > >cafe 0xCAFE 16#cafe > >> > > Seems reasonable. I'll add it. My only small qualm is that the > coupling ~h/~H does not mean the same thing as ~w/~W and ~p/~P, but I > suppose there is not real problem here. > > There should be probably be a matching hex-input flag for > io:fread. I > suppose I had better do that one as well. > > Robert > > 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 Feb 1 13:08:52 2001 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 01 Feb 2001 13:08:52 +0100 Subject: Wishes: hex-output In-Reply-To: Chandrashekhar Mullaparthi's message of "Thu, 1 Feb 2001 11:57:09 -0000" References: <402DD461F109D411977E0008C791C31203919938@imp02mbx.one2one.co.uk> Message-ID: Or alternatively: ucase([C|Cs]) when C>=$a,C=<$z -> [C-32|ucase(Cs)]; % a-z ucase([C|Cs]) -> [C|ucase(Cs)]; ucase([]) -> []. lcase([C|Cs]) when C>=$A,C=<$Z -> [C+32|lcase(Cs)]; % A-Z lcase([C|Cs]) -> [C|lcase(Cs)]; lcase([]) -> []. capw([C|Cs]) when C>=$a,C=<$z -> [C-32|lcase(Cs)]; capw(Cs) -> lcase(Cs). Cheers /Tobbe From Erik.Reitsma@REDACTED Thu Feb 1 13:23:38 2001 From: Erik.Reitsma@REDACTED (Erik Reitsma (ELN)) Date: Thu, 1 Feb 2001 13:23:38 +0100 Subject: Wishes: hex-output Message-ID: Or alternatively replace 32 with ($a-$A): ucase([C|Cs]) when C>=$a,C=<$z -> [C-($a-$A)|ucase(Cs)]; % a-z ucase([C|Cs]) -> [C|ucase(Cs)]; ucase([]) -> []. lcase([C|Cs]) when C>=$A,C=<$Z -> [C-($A-$a)|lcase(Cs)]; % A-Z lcase([C|Cs]) -> [C|lcase(Cs)]; lcase([]) -> []. capw([C|Cs]) when C>=$a,C=<$z -> [C-($a-$A)|lcase(Cs)]; capw(Cs) -> lcase(Cs). This only relies on $a-$z and $A-$Z being consecutive integer intervals, not on the distance between these intervals (which is 32 in case of ASCII). I just hope that the compiler will optimize $a-$A, otherwise this would require more computation... *Erik. From rv@REDACTED Thu Feb 1 13:32:05 2001 From: rv@REDACTED (Robert Virding) Date: Thu, 01 Feb 2001 13:32:05 +0100 Subject: Beam files, module beam_lib and source code In-Reply-To: Your message of "Wed, 24 Jan 2001 13:44:10 EST." Message-ID: <200102011232.NAA22069@trana.bluetail.com> Adding the fix for compile.erl which I posted a few weeks back to change the default behavior for debug_info in .beam files will not affect all the libraries built when building the system. However, if size is important then replace bootstrap/lib/compiler-3.0.1/ebin/compile.beam with a modified compile.beam. Next time the release is built then all the libraries will be stripped. This saves about 40% of the size of the system. Robert From vances@REDACTED Fri Feb 2 22:38:20 2001 From: vances@REDACTED (Vance Shipley) Date: Fri, 2 Feb 2001 16:38:20 -0500 Subject: reloading a linked in driver Message-ID: While writing a dynamically linked driver it occurred to me that it might be possible to reload a new version of the driver without first stopping it. This was a natural thing to want to do as I had an Erlang shell in one window and in another window I was making changes to the driver code. To be able to do live code change on a driver would be very advantageous in real life. I found that it worked. Sort of. If I make changes that keep the size consistent it works but if I make a change which would alter the offsets it crashes. I wonder if someone with a better knowledge of how this works could comment on the possibilities. An example: $ erl Erlang (BEAM) emulator version 5.0.1.1 [source] Eshell V5.0.1.1 (abort with ^G) 1> erl_ddll:load_driver("./", foo_drv). ok 2> Port = open_port({spawn, foo_drv}, []). #Port<0.8> 3> port_control(Port, 2, <<0>>). "foo" Now I make a simple change to the driver code so that it will return "bar" instead of "foo". Things work as hoped: 4> erl_ddll:load_driver("./", foo_drv). ok 5> port_control(Port, 2, <<0>>). "bar" Now I change the driver so that it returns "foobar" instead. This adds three bytes to the code. 6> erl_ddll:load_driver("./", foo_drv). ok 7> port_control(Port, 2, <<0>>). Segmentation Fault(coredump) $ It would really be very cool if there was a way to make this work. I have been very happy with the ability to make frequent code changes on live systems with Erlang. To be able to extend this benefit to the C language drivers would be a boon to us. -Vance From dg@REDACTED Sat Feb 3 01:42:13 2001 From: dg@REDACTED (David Gould) Date: Fri, 2 Feb 2001 16:42:13 -0800 Subject: Performance as a tcp proxy server? Message-ID: <20010202164213.A2814@archimedes.oak.suse.com> Hi, I am working with a busy database driven web site who have a performance problem: - several linux hosts runing apache and PHP and issuing SQL queries to - one hefty four cpu SMP linux host running Mysql When the site is busy, the apache instances open more and more connections and start new queries to the Mysql system, which leads to the Mysql server trying to handle several hundred queries at one time. Unhappily, Mysql bogs down very badly when there are lots of active threads. For example with only a few (ca. 10) connections, the Mysql system can handle several thousand queries per second. But, with many (eg 1000) connections, Mysql can only do a few hundred queries per second. That is, with large numbers of active queries, overall throughput decline by an order of magnitude. Since the slower the database goes, the more queries the webservers want to start, there is a nasty feedback effect. Mysql uses pthreads internally, and since this is on Linux, they map to Linux clone() threads, which are scheduled by the kernel and are quite a lot heavier than an Erlang process. To avoid the site meltdowns, I am proposing to limit the number of Mysql connections by placing a proxy process between the webservers (Mysql clients) and the Mysql server. This proxy will multiplex multiple sql client sessions onto each sql server connection. Bad ascii diagram ... Client ----\ Client ----\ \ Client ------- Proxy <====> Mysql Client ----/ / Client ----/ When a client sends a query, it must be queued until it can be sent on to the server. When a query is sent to the server, there may be some delay before the response. We need to continue accepting and queueing client queries during this time. When a response comes from the server it must be sent back to the client that originated the query, and the next queue query must be sent to the server. Sample dialog: Client A: - to proxy -> here is query A Proxy : Server is idle, mark it busy with qA and - to Server -> here is a query ... Client B: -> to proxy -> here is qB Proxy: hmm, server is busy, put qB on queue. Client C: -> to proxy -> here is qC Proxy: put qC on queue ... Server: - to proxy -> here is a partial result Proxy: -> to Client A -> here is part of response A Server: - to proxy -> here is the rest of the result Proxy: - to Client A -> here is the rest of rA Proxy: dequeue qB - to Server -> here is a query ... The query and especially the response may be any size (although here they are probably a few KB), so it is neccessary to handle partial queries and partial results. Also, the client does not have to read the whole response at once, so there may be some buffering needed. This all means that the proxy needs to understand enough of the mysql "on the wire" protocol to identify whole queries and whole sets of results, presumably by watching for whatever "end of message" markers there are in the packets. I am considering Erlang to write this proxy, it seems like it should be quite simple even using sockets and binaries that doing it in C. Although, there are some C libraries for this that do a bit of the heavy lifting. The performance constraints are roughly: - queries are a few hundred bytes. - I am guessing that responses are about one K bytes, but could sometimes be quite large (ie megs). - packets are handled as binaries, only a few bytes of header need looking at. - roughly 1000 client sessions. - roughly 10 to 40 server sessions. - it would be nice to handle thousands of queries per second. - the multiplexing proxy(s) can run on the webserver machines, one per apache, or on dedicated machines between the webservers and the sql machine. - network bandwidth is not a problem, hardware can be purchased if needed. Current machines are two and four cpu Zeons with 1GB to 4GB of memory. So, has anyone got any advice for me? Is it reasonable to expect Erlang to handle this? - How many tcp sockets can the emulator well? Hundreds? Thousands? - is it able to poll them efficiently? - what sort of traffic level can it cope with in terms of messages/bytes per second? (I realize this is an impossible question, but if the answer is "many KB per second", I have to give up, if it is "many MB per second", I have a hope.) Is there a preferred way to lay this sort of thing out into processes? I have a vague idea of a process per socket and some sort of queue manager process spawning a process for each query as it is activated. Thanks! -dg -- David Gould dg@REDACTED SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380 You left them alone in a room with a penguin?! Mr Gates, your men are already dead. From ashelton@REDACTED Mon Feb 5 10:17:31 2001 From: ashelton@REDACTED (Andrew Shelton) Date: Mon, 5 Feb 2001 20:17:31 +1100 (EST) Subject: List append buglet...? Message-ID: <200102050917.UAA01452@parallel.serc.rmit.edu.au> Greetings, Well, if it wasn't a bug it certainly was suprising behaviour. It also seems to violate the stdlib documentation. Since it's such a basic operation it took me a while to track down what was going on... Erlang (BEAM) emulator version 4.9.1 [source] Eshell V4.9.1 (abort with ^G) 1> []++[1]. [1] 2> []++{1}. {1} 3> At least it's simple to demonstrate. Apologies if this has been fixed in the most current. -- "Oh, drat these blasted computers. They're so naughty and complex. I could pinch them!" Marvin the Martian. My web page : http://www.serc.rmit.edu.au/~ashelton From pugliese@REDACTED Mon Feb 5 11:04:18 2001 From: pugliese@REDACTED (Rosario Pugliese) Date: Mon, 05 Feb 2001 11:04:18 +0100 Subject: PLI 2001 Announcement Message-ID: <3A7E7AA2.4CD171FD@dsi.unifi.it> [Apologies for multiple copies] ---------------------------------------------------------------- PLI 2001 Principles, Logics, and Implementations of high-level programming languages (Sponsored by ACM) Firenze, ITALY September 2 - 8, 2001 http://music.dsi.unifi.it/pli01/ The colloquium on Principles, Logics, and Implementations of high- level programming languages is a collection of conferences and workshops aimed at the advancement of high-level programming languages. The events composing PLI will cover a spectrum of topics important to language development and use, including issues such as semantics, design, analysis, implementation, and application. Theoretical issues relevant to language design and programming will be represented. Implementation questions will provide an emphasis on compilation methods, distributed computation and static debugging techniques. There will also be a focus on industrial and educational applications. Conferences: ICFP (September 3-5) Int. Conf. on Functional Programming General chair: Benjamin Pierce (Univ. Pennsylvania) Program chair: Xavier Leroy (INRIA Rocquencourt) PPDP (September 5-7) Int. Conf. on Principles and Practice of Declarative Programming Conference chair: Rocco De Nicola (Univ. Firenze) Program chair: Harald S?ndergaard (Univ. Melbourne) Workshops: ? Multi?language Infrastructure and Interoperability (BABEL) ? ERLANG Workshop ? Fixed Points in Computer Science (FICS) ? HASKELL Workshop ? Quantitative Aspects of Programming Languages (QAPL) ? Rule-Based Programming (RULE) ? Semantics, Applications, and Implementation of Program Generation (SAIG) ? Scheme and Functional Programming (SCHEME) ? Verification and Computational Logic (VCL) Submission deadline for ICFP and PPDP: March 15, 2001 Workshops chair: Betti Venneri (Univ. Firenze) Publicity chair: Rosario Pugliese (Univ. Firenze) Organizing Committee: Gianni Aguzzi (Univ. Firenze, co-chair), Giorgio Ghelli (Univ. Pisa, co-chair), Lorenzo Bettini (Univ. Firenze), Michele Loreti (Univ. Firenze), Dario Colazzo (Univ. Pisa) Contact Information: pli-inf@REDACTED Conference Venue: Auditorium Banca Toscana, Via Panciatichi, 87 (Firenze Nova), Firenze, ITALY From mickael.remond@REDACTED Mon Feb 5 11:14:22 2001 From: mickael.remond@REDACTED (Mickael Remond) Date: 05 Feb 2001 11:14:22 +0100 Subject: List append buglet...? In-Reply-To: <200102050917.UAA01452@parallel.serc.rmit.edu.au> References: <200102050917.UAA01452@parallel.serc.rmit.edu.au> Message-ID: <87vgqpa135.fsf@western.ird.idealx.com> On Mon, 5 Feb 2001, Andrew Shelton wrote: > Greetings, > > Well, if it wasn't a bug it certainly was suprising behaviour. It also > seems to violate the stdlib documentation. Since it's such a basic > operation it took me a while to track down what was going on... > > Erlang (BEAM) emulator version 4.9.1 [source] > > Eshell V4.9.1 (abort with ^G) > 1> []++[1]. > [1] > 2> []++{1}. > {1} > 3> > > At least it's simple to demonstrate. Apologies if this has been > fixed in the most curent. I do not know what you were expected exactly, but the behaviour of the list appending function is still the same in the last Erlang version (5.0.1.1). What is funny is that the function cannot be reversed: 8> {1}++[]. =ERROR REPORT==== 5-Feb-2001::10:59:22 === Error in process <0.34.0> with exit value: {badarg,[{erlang,append,[{1},[]]},{erl_eval,eval_op,3},{erl_eval,expr,3},{erl_eval,exprs,4},{shell,eval_loop,2}]} ** exited: {badarg,[{erlang,append,[{1},[]]}, {erl_eval,eval_op,3}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** Moreover, I discovered that the "++" operator is used in the lists:append/2 function. I thought that ++ was a syntaxic sugar for the lists:append function, but this does not seem to be the case. Thus, you get exactly the same result in the list append function. Apparently, only the first argument is check to see if this is a list. The second one is not checked and can be anything. If the first element is an empty list, so the second element is directly sent back. Thus, the lists:append function does not necessarily send back a list but can return anything. So, I think you are right, this is not consistent with the documentation, and I think this is not the wanted behaviour. -- Micka?l R?mond tel : (33)1.44.42.00.00 Chef de projet mob : (33)6.60.22.22.16 15 - 17 avenue de S?gur e-mail : mickael.remond@REDACTED 75007 - Paris web : http://IDEALX.com From jakob@REDACTED Mon Feb 5 12:49:46 2001 From: jakob@REDACTED (Jakob Cederlund =?iso-8859-1?Q?p=E5?= UAB) Date: Mon, 05 Feb 2001 12:49:46 +0100 Subject: reloading a linked in driver In-Reply-To: Message-ID: <5.0.2.1.0.20010205124740.00bb2ca0@mail> At the very least, you can give the new version another name. If the loaded driver is already loaded, it won't relink when you do load_driver/2. Unloading the driver first seems to work, but I suspect you don't want to do that. /Jakob From jakob@REDACTED Mon Feb 5 12:52:19 2001 From: jakob@REDACTED (Jakob Cederlund =?iso-8859-1?Q?p=E5?= UAB) Date: Mon, 05 Feb 2001 12:52:19 +0100 Subject: Wishes: hex-output In-Reply-To: References: <402DD461F109D411977E0008C791C31203919938@imp02mbx.one2one.co.uk> Message-ID: <5.0.2.1.0.20010205125120.00b5a080@mail> What about ????? etc? Would be better to go to the functions in the OS instead. /Jakob From rv@REDACTED Mon Feb 5 14:23:45 2001 From: rv@REDACTED (Robert Virding) Date: Mon, 05 Feb 2001 14:23:45 +0100 Subject: List append buglet...? In-Reply-To: Your message of "05 Feb 2001 11:14:22 +0100." <87vgqpa135.fsf@western.ird.idealx.com> Message-ID: <200102051323.OAA11308@trana.bluetail.com> Mickael Remond writes: >On Mon, 5 Feb 2001, Andrew Shelton wrote: >> Greetings, >> >> Well, if it wasn't a bug it certainly was suprising behaviour. It also >> seems to violate the stdlib documentation. Since it's such a basic >> operation it took me a while to track down what was going on... >> >> Erlang (BEAM) emulator version 4.9.1 [source] >> >> Eshell V4.9.1 (abort with ^G) >> 1> []++[1]. >> [1] >> 2> []++{1}. >> {1} >> 3> >> >> At least it's simple to demonstrate. Apologies if this has been >> fixed in the most curent. > >I do not know what you were expected exactly, but the behaviour of the list >appending function is still the same in the last Erlang version (5.0.1.1). Actually this is completely consistent with the behaviour of cons ([|]). Try doing: 1> [a|[]]. [a] 2> [a|b]. [a|b]. 3> There is nothing which forces the tail of a list to be a list or nil! So, as append/++ behave as if they were defined as: append([H|T], Rest) -> [H|append(T, Rest)]; append([], Rest) -> Rest. the result is quite correct, logical and consistent. Append is defined in section 3.2.2 of the book (which is in the down-loadable section). >What is funny is that the function cannot be reversed: >8> {1}++[]. See above. >Moreover, I discovered that the "++" operator is used in the lists:append/2 >function. I thought that ++ was a syntaxic sugar for the lists:append >function, but this does not seem to be the case. >Thus, you get exactly the same result in the list append function. Actually which is syntactic sugar for which is really irrelevant, lists:append is a function interface and '++' is special syntax for a common case. >Apparently, only the first argument is check to see if this is a list. The >second one is not checked and can be anything. See above >If the first element is an empty list, so the second element is directly sent >back. Thus, the lists:append function does not necessarily send back a list but >can return anything. > >So, I think you are right, this is not consistent with the documentation, and >I think this is not the wanted behaviour. Yes, it is consistent, but whether it is the wanted behaviour is another question. This definition of lists is the same as in Lisp and Prolog which were languages which strongly influenced the development Erlang. It would be difficult to change today as a change would have to be made to all list construction not just for append. Otherwise how would you efficiently handle cases like: List ++ [a|b] Deep-checking the second argument is not really feasible. 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 mickael.remond@REDACTED Mon Feb 5 14:38:16 2001 From: mickael.remond@REDACTED (Mickael Remond) Date: 05 Feb 2001 14:38:16 +0100 Subject: List append buglet...? In-Reply-To: <200102051323.OAA11308@trana.bluetail.com> References: <200102051323.OAA11308@trana.bluetail.com> Message-ID: <87hf298d2v.fsf@western.ird.idealx.com> On Mon, 05 Feb 2001, Robert Virding wrote: > > Yes, it is consistent, but whether it is the wanted behaviour is another > question. This definition of lists is the same as in Lisp and Prolog > which were languages which strongly influenced the development Erlang. > It would be difficult to change today as a change would have to be made > to all list construction not just for append. Otherwise how would you > efficiently handle cases like: > > List ++ [a|b] > > Deep-checking the second argument is not really feasible. Ok. Thank you for helping us to understand the behaviour of the append function. I did not think about linking that to the 'cons' behaviour and your answer is convincing: this is how the system is working and not a misbehaviour. Thank you. -- Micka?l R?mond tel : (33)1.44.42.00.00 Chef de projet mob : (33)6.60.22.22.16 15 - 17 avenue de S?gur e-mail : mickael.remond@REDACTED 75007 - Paris web : http://IDEALX.com From voudheus@REDACTED Mon Feb 5 17:44:21 2001 From: voudheus@REDACTED (Karel Van Oudheusden) Date: Mon, 05 Feb 2001 17:44:21 +0100 Subject: why concurrency in the first place? Message-ID: <3A7ED865.E36819DA@imec.be> Hello, I know this may sound like a naieve question but I would like to have a thorough answer any way :) "Why does an (Erlang) programmer have to program his application with concurrency explicitly in mind?" I also know (think) that this was the main intention of the Erlang language. Isn't it easier (cfr. Haskell) to free the programmer (=designer) from this burden? If a programmer has to specify it (as is the case in Erlang), he will typically overspecify his system (even if the processes are light weight). Process spawning and message passing are sources of impureness in Erlang. This was a pragmatic choice of the Erlang founders. Is this because it is (still) difficult for pure functional compilers to do a good job on extracting optimal concurrency from an initially pure functional specification? Does the Haskell compiler do a good job on this? I also want to make the following statement (please give feedback): "It is always easier to specify a system without explicit concurrency in mind." For example: programming in Haskell (which is almost similar to specifying) is done in a concurrency-independent way leaving the eventual implementation to have any degree of true concurrency, depending on what the compiler decides is best. And then a final question: if the application (or system) that has to be specified contains a high degree of non-manifest constructs (such as dynamic event behaviour which Erlang was typically designed for), does the concurrency extraction of the compiler become an even more difficult job? Stated otherwise, is the presence of non-manifest code a good reason to have the Erlang programmer explicitly define the concurrency of the system? Can Haskell for instance tackle non-manifest code efficiently? What is the status of this problem in the research community? thanx, Karel. P.S. I have looked at the "Erlang/OTP R7 - speed test of new inet driver" code the last couple of days. It can be found at: http://www.erlang.se/r7_inet_speed/index.shtm. I am relatively new to Erlang. I must say that this code is not very readable. I would typically choose to use more modules in my code. And I am very astonished about the different (light-weight) processes that are spawned every now and then. Perhaps somebody could explain to me when it is interesting (from a specification and implementation point of view) to use a seperate process to accomplish something. I have worked with multi-threaded languages previously, but I would have typically chosen other kinds of abstractions than the ones made here. And concluding from my above remarks, I now think a specification should contain no concurrency at all. From bjarne@REDACTED Mon Feb 5 18:45:37 2001 From: bjarne@REDACTED (Bjarne =?iso-8859-1?Q?D=E4cker?=) Date: Mon, 05 Feb 2001 18:45:37 +0100 Subject: why concurrency in the first place? References: <3A7ED865.E36819DA@imec.be> Message-ID: <3A7EE6C1.CB9BF571@erix.ericsson.se> Hello Karel Van Oudheusden wrote: > > I know this may sound like a naieve question but I would like to have a > thorough answer any way :) > "Why does an (Erlang) programmer have to program his application with > concurrency explicitly in mind?" Because many applications that Erlang is intended for are concurrent by nature. If you don't have some concepts for concurrency then you would have to program some sort of scheduler as part of the implementation. Best regards Bjarne From dg@REDACTED Mon Feb 5 19:16:48 2001 From: dg@REDACTED (David Gould) Date: Mon, 5 Feb 2001 10:16:48 -0800 Subject: Optimization of list comprehensions? Message-ID: <20010205101648.A10383@archimedes.oak.suse.com> I really like list comprehensions, they seem so, declarative. I am tempted to use them everywhere ;-) But, what does the compiler do with them? Does it generate better code for a list comprehension than for using lists:map()? Is it able to detect when a listcomp is used for its side effects alone and not build the result? For example, is: [io:format('~s~n', [Item]) | Item <- Items]. more or less effcient than: lists:foreach(fun(Item) -> io:format('~s~n', [Item])) end, Items). Oh yeah, is it better or worse style? -dg -- David Gould dg@REDACTED SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380 You left them alone in a room with a penguin?! Mr Gates, your men are already dead. From Sean.Hinde@REDACTED Mon Feb 5 19:56:07 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 5 Feb 2001 18:56:07 -0000 Subject: why concurrency in the first place? Message-ID: <402DD461F109D411977E0008C791C312039F5D3C@imp02mbx.one2one.co.uk> > Hello, > > > I know this may sound like a naieve question but I would like > to have a > thorough answer any way :) > "Why does an (Erlang) programmer have to program his application with > concurrency explicitly in mind?" > I also know (think) that this was the main intention of the Erlang > language. Concurrency is useful in the classic sense of making a multithreaded transaction or event based system which does not completely grind to a halt if a single transaction is very slow to finish. It is also useful where one has an application where many different tasks can continue in a loosely arranged way. For example one may want to have a global logging process which other parts of the system can simply fire messages into and then get on with what they were doing without waiting. (I'm sure there are many other better examples out there) Concurrency also provides a very natural way to express timeouts in an application. A process can send itself a message some time later to remind it to check on something while it gets on with handling other tasks. Message passing is also used for all I/O in Erlang (including transparent message passing to a process on another physical node) As you say message passing and processes are to all intents and purposes the only source of impurity in Erlang, and IMHO are much simpler to comrehend and more flexible than Monads (I see there are moves to introduce asynchronous exceptions, explicit concurrency, message passing and timers into Haskell which I must say don't look all that "beautiful". All these things were needed to produce a working Haskell HTTP server. See http://research.microsoft.com/Users/simonpj/ for a very interesting collection of papers). The message passing model of Erlang also provides a nice mechanism to decompose a large application into distinct sub applications with very clean APIs and interfaces between them. If you look through some of the source of the OTP system you will see many beautiful examples of the craft of Erlang programming and use of spawn and message passing. Particularly the MNESIA database system uses these concepts to incredible effect - many complex transactions can happen in parallel across different machines and still a user application can get real time access to any data. With regards to your point about whether a compiler can deduce the concurrency requirements of an application from a pure specification I doubt it at the moment. Certainly Haskell doesn't appear to do anything other than provide primitive support for concurrency in prototype versions. If only Erlang had something like the extraordinary type system of Haskell :-) - 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 hakanm@REDACTED Mon Feb 5 20:52:11 2001 From: hakanm@REDACTED (Hakan Millroth) Date: Mon, 05 Feb 2001 11:52:11 -0800 Subject: why concurrency in the first place? References: <3A7ED865.E36819DA@imec.be> Message-ID: <3A7F046B.FFB1ADE5@alteon.com> > Isn't it easier (cfr. Haskell) to free the programmer > (=designer) from this burden? If a programmer has to > specify it (as is the case in Erlang), he will typically > overspecify his system (even if the processes are light weight). I also thought so 10-15 years ago and so did a lot of otherwise reasonable people. However, declarative programming is about being able to control the execution of declarative statements. That is, programs should have a declarative interpretation but, in addition, you must be able to control how those statements are executed (e.g. concurrency). One of the early pioneers of declarative programming, Bob Kowalski, realized this from the beginning and always argued that Logic Programming is about both Logic and Control (equally true for Functional Programming). Unfortunately, many other researchers quickly forgot about the control aspects and focussed instead on "pure" approaches - to the effect that academic research in this area has had almost no impact on real-world programming in the last two decades. -- Hakan Hakan Millroth Nortel Networks / Alteon Websystems 50 Great Oaks Blvd. San Jose, CA 95119, USA From vances@REDACTED Mon Feb 5 21:03:32 2001 From: vances@REDACTED (Vance Shipley) Date: Mon, 5 Feb 2001 15:03:32 -0500 Subject: reloading a linked in driver In-Reply-To: Message-ID: I found that NOT loading the driver again worked: 3> port_control(Port, 2, <<0>>). "bar" Now copy new version of foo_drv.so over top of the old one. 4> port_control(Port, 2, <<0>>). "foobar" I'm happy now, although there is still much magic involved for me as I don't quite understand what is going on here. :) -Vance From jamesh@REDACTED Mon Feb 5 21:15:53 2001 From: jamesh@REDACTED (James Hague) Date: Mon, 5 Feb 2001 14:15:53 -0600 Subject: why concurrency in the first place? Message-ID: It sounds like two types of concurrency are being confused. The one type, which was promoted by Backus as one of the great benefits of functional programming, is when the compiler or run-time system determines which aspects of a program are parallel and handles them as such, presumably handing each one to a separater processor. If you don't have side effects, then this isn't terribly difficult to do. Maybe not worth it, but still doable. In Erlang, though, the concurrency is more like what you see in a multithreaded OS. If you want to run an application, you spawn a task. If you want to run fifty of the same applications, you spawn fifty tasks. But all fifty of those tasks need to interact with common resources at various points, so you need a way to deal with it. Most OSes use some form of resource locking, whereas Erlang uses a message passing scheme. It is tempting to convince oneself that everything in programming is messy and should be handled at a higher level, but that's not so easy to do in practice :) James From maurice@REDACTED Mon Feb 5 22:51:38 2001 From: maurice@REDACTED (Maurice Castro) Date: Tue, 6 Feb 2001 08:51:38 +1100 (EST) Subject: why concurrency in the first place? In-Reply-To: <3A7ED865.E36819DA@imec.be> from Karel Van Oudheusden at "Feb 5, 2001 05:44:21 pm" Message-ID: <200102052151.IAA02469@parallel.serc.rmit.edu.au> > Hello, > > > I know this may sound like a naieve question but I would like to have a > thorough answer any way :) > "Why does an (Erlang) programmer have to program his application with > concurrency explicitly in mind?" > I also know (think) that this was the main intention of the Erlang > language. > > Isn't it easier (cfr. Haskell) to free the programmer (=designer) from > this burden? If a programmer has to specify it (as is the case in > Erlang), he will typically overspecify his system (even if the processes > are light weight). Erlang is primarily a language for expressing soft real-time behaviours. Desirable features in such a language are explicit expression of concurrent operations, easily predictable performance, and no surprises for the programmer. Programming is the process of communicating, in a structured language, the intentions of the programmer to a compiler. The compiler then produces code that hopefully implements these intentions. Many of the translation steps in the process are flawed. The programmer may not understand the problem, he may not specify it correctly, or the translated code may interact in an unexpected way with the system. The intentions Erlang seeks to model explicitly include parallel operations, having the compiler work out what can be made parallel in fact seeks to hide the very thing the language is design to make explicit. Erlang happens to be a functional language to reduce the number of surprises for the programmer. Maurice Castro From reyes@REDACTED Mon Feb 5 23:32:04 2001 From: reyes@REDACTED (Arthur Reyes) Date: Mon, 5 Feb 2001 16:32:04 -0600 (CST) Subject: Erlang shell print depth and print length: how to change? Message-ID: <200102052232.QAA16281@siddhartha.uta.edu> Dear Erlang Friend: I need to inspect Erlang abstract syntax trees (ASTs) produced by epp:parse_file/3 and similar functions. When given the filename and path of a large Erlang source code file, epp:parse_file/3 returns a long list of deeply nested tuples. The returned list is often so long the Erlang shell elides the end of it with ellipses (...). The tuples are often so deeply nested the Erlang shell elides the deeper components with ellipses as well. If you know, please provide me a reference to modules and functions that allow the user of the Erlang shell to modify the shell's print depth and print length. Thank you. -- Arthur Alexander Reyes, Assistant Professor VOICE: (817) 272-7408 Dept. Computer Science & Engineering FAX: (817) 272-3784 University of Texas at Arlington http://www-cse.uta.edu/~reyes/ Box 19015, Arlington, TX 76019-0015 reyes@REDACTED From cpressey@REDACTED Tue Feb 6 00:40:22 2001 From: cpressey@REDACTED (Chris Pressey) Date: Mon, 05 Feb 2001 17:40:22 -0600 Subject: why concurrency in the first place? References: Message-ID: <3A7F39E6.81E45BA2@catseye.mb.ca> Hi, Allow me to introduce myself. My name is Chris Pressey and I'm one of the active members of the so-called 'esoteric programming' community, which experiments with computer languages in a non-industrial, non-academic setting. See http://www.catseye.mb.ca/ for more information. I'm somewhat new to Erlang (only written a couple of programs), and new to this list, but I thought I might chip in my two cents from a 'language design' perspective... James Hague wrote: > It sounds like two types of concurrency are being confused. [...] It's not really concurrency that's the issue - Perl, Erlang, and Haskell are all concurrent. It's the amount of abstraction between the programmer and the concurrency. In Perl, concurrency comes with a very low level of abstraction. The programmer must explicitly choose to 'fork', or whatever else is appropriate for whatever system the program happens to be runnning on. The programmer has total control & responsibility. This might be convenient for hacking, but it's awkward for writing portable, stable programs. In Haskell (as I understand it,) concurrency comes with an extremely high level of abstraction. The programmer has little control or reponsibility over when and how it happens. This might be convenient for mathematicians and logicians who have "more important" things to worry about, but it just gets in the way when writing production code which must meet certain demands. I've been attracted to Erlang recently because it's like the bowl of porridge that is "just right" in that story about that blonde girl and the three bears. Concurrency is neither intractably concrete like in Perl, nor intractably abstract like Haskell. It is instead at a very comfortable abstraction level, with a nice thin interface (essentially just spawn/send/receive) which makes it easy to be productive while writing concurrent code. Also it's probably important to remember that while the main drive to add concurrency to most programming languages is to allow more efficient algorithms to be written in them... the concurrency model in Erlang is actually for simulating real-world concurrency in a natural way. This difference in philosophy is probably what helps make the abstraction level for concurrency in Erlang so comfortable. _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From hal@REDACTED Tue Feb 6 01:22:41 2001 From: hal@REDACTED (Hal Snyder) Date: 05 Feb 2001 18:22:41 -0600 Subject: Performance as a tcp proxy server? In-Reply-To: David Gould's message of "Fri, 2 Feb 2001 16:42:13 -0800" References: <20010202164213.A2814@archimedes.oak.suse.com> Message-ID: <87snls8xta.fsf@ghidra.vail> David Gould writes: ... > To avoid the site meltdowns, I am proposing to limit the number of > Mysql connections by placing a proxy process between the webservers > (Mysql clients) and the Mysql server. This proxy will multiplex > multiple sql client sessions onto each sql server connection. > > Bad ascii diagram ... > > Client ----\ > Client ----\ \ > Client ------- Proxy <====> Mysql > Client ----/ / > Client ----/ > > When a client sends a query, it must be queued until it can be sent > on to the server. When a query is sent to the server, there may be > some delay before the response. We need to continue accepting and > queueing client queries during this time. When a response comes from > the server it must be sent back to the client that originated the > query, and the next queue query must be sent to the server. I can't answer the important questions about throughput and load limits, as our app is low traffic. But, our pilot Erlang project, put into production last summer, does something quite similar to your diagram, except that we are not only proxying and queuing, but also providing failover on redundant custom databases over WAN links. It has been extremely reliable, allowing support staff to sleep through near-weekly outages in any one of the remote servers. Warning: The principal programmer on the project turned into an FP zealot, and doesn't like C++, Java, or Perl any more. ;-) From richardc@REDACTED Tue Feb 6 09:37:54 2001 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 6 Feb 2001 09:37:54 +0100 (MET) Subject: Erlang shell print depth and print length: how to change? In-Reply-To: <200102052232.QAA16281@siddhartha.uta.edu> Message-ID: On Mon, 5 Feb 2001, Arthur Reyes wrote: > Dear Erlang Friend: > > I need to inspect Erlang abstract syntax trees (ASTs) produced by > epp:parse_file/3 and similar functions. > > When given the filename and path of a large Erlang source code file, > epp:parse_file/3 returns a long list of deeply nested tuples. > > The returned list is often so long the Erlang shell elides the end of > it with ellipses (...). The tuples are often so deeply nested the > Erlang shell elides the deeper components with ellipses as well. I would not go as far as to suggest that you try to modify the behaviour of the shell itself, but this would show you the whole structure: io:fwrite("~p", [epp:parse_file("foo.erl", [], [])]) If you want to analyse the syntax tree in more detail, I recommend my "syntax tools" package, which works as an abstract layer hiding the actual representation details. It also comes with a more advanced pretty-printer than the standard library 'erl_pp'. http://www.erlang.org/user.html#syntax_tools-1.0 /Richard Carlsson Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From richardc@REDACTED Tue Feb 6 09:55:35 2001 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 6 Feb 2001 09:55:35 +0100 (MET) Subject: Optimization of list comprehensions? In-Reply-To: <20010205101648.A10383@archimedes.oak.suse.com> Message-ID: On Mon, 5 Feb 2001, David Gould wrote: > I really like list comprehensions, they seem so, declarative. I am > tempted to use them everywhere ;-) > > But, what does the compiler do with them? > > Does it generate better code for a list comprehension than for using > lists:map()? Up until now, list comprehensions have not been efficiently compiled, but as of the coming R8 release they will be as efficient as the hand-coded versions, i.e.: do(Xs) -> [foo(X) || X <- Xs]. will be as quick as: do([X | Xs]) ->?[foo(X) | do(Xs)]; do([]) -> []. And in fact, there is some potential for generating even better code for list comprehensions than for explicitly recursive functions. > Is it able to detect when a listcomp is used for its side effects > alone and not build the result? For example, is: > > [io:format('~s~n', [Item]) | Item <- Items]. > > more or less effcient than: > > lists:foreach(fun(Item) -> io:format('~s~n', [Item])) end, Items). It could be done, but don't expect it to happen any time soon. (Actually, that sort of optimisation - a form of specialisation - applies to other code as well, not only list comprehensions.) > Oh yeah, is it better or worse style? I'd say the "foreach" version is better style in this case, since it is less obvious to the eye (even if it is actually the case) that the calls will be executed in the expected order in the list comprehension version. /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 Tue Feb 6 10:43:07 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 6 Feb 2001 10:43:07 +0100 (MET) Subject: Optimization of list comprehensions? In-Reply-To: <20010205101648.A10383@archimedes.oak.suse.com> Message-ID: On Mon, 5 Feb 2001, David Gould wrote: >I really like list comprehensions, they seem so, declarative. I am >tempted to use them everywhere ;-) Yes, they're nice. >But, what does the compiler do with them? > >Does it generate better code for a list comprehension than for using >lists:map()? Essentially, the list comprehension becomes a lists:map(). You can check for yourself by using the 'E' compiler option. Here's an example: *********************** lctest.erl -module(lctest). -author('etxuwig@REDACTED'). %%-compile(export_all). -export([lc1/1, lc2/2]). lc1(List) -> [foo(X) || X <- List, X > 17]. lc2(List1, List2) -> [foo({X, Y}) || X <- List1, Y <- List2, X > Y]. foo(X) -> X. *********************** erlc -E lctest.erl *********************** lctest.E -author(['etxuwig@REDACTED']). lc1(List) -> begin %0 = % fun-info: {78720207,[['%0','%1','X'],['%0','%1'],['%0']],[]} fun ([X|%1],%0) -> if X > 17 -> [foo(X)|%0(%1,%0)]; true -> %0(%1,%0) end; ([_|%1],%0) -> %0(%1,%0); ([],%0) -> [] end, %0(List,%0) end. lc2(List1,List2) -> begin %2 = % fun-info: {123483443,[['%2','%3','X'],['%2','%3'],['%2']],['List2 ']} fun ([X|%3],%2) -> begin %4 = % fun-info: {38130919,[['%4','%5','Y'],['%4','%5'] ,['%4']],['%2','%3','X']} fun ([Y|%5],%4) -> if X > Y -> [foo({X,Y})|%4(%5,%4)]; true -> %4(%5,%4) end; ([_|%5],%4) -> %4(%5,%4); ([],%4) -> %2(%3,%2) end, %4(List2,%4) end; ([_|%3],%2) -> %2(%3,%2); ([],%2) -> [] end, %2(List1,%2) end. foo(X) -> X. module_info() -> []. module_info(_) -> []. >Is it able to detect when a listcomp is used for its side effects >alone and not build the result? I don't recall seeing anything like that in the compiler (but I will admit I don't understand the compiler well enough to be sure.) >Oh yeah, is it better or worse style? Personally, I try to avoid using list comprehensions when I really don't care about the result, since lists:foreach/2 makes that point very clearly. /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 Tue Feb 6 10:56:29 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 6 Feb 2001 10:56:29 +0100 (MET) Subject: Erlang shell print depth and print length: how to change? In-Reply-To: <200102052232.QAA16281@siddhartha.uta.edu> Message-ID: On Mon, 5 Feb 2001, Arthur Reyes wrote: >Dear Erlang Friend: > >I need to inspect Erlang abstract syntax trees (ASTs) produced by >epp:parse_file/3 and similar functions. > >When given the filename and path of a large Erlang source code file, >epp:parse_file/3 returns a long list of deeply nested tuples. > >The returned list is often so long the Erlang shell elides the end >of it with ellipses (...). The tuples are often so deeply nested the >Erlang shell elides the deeper components with ellipses as well. > >If you know, please provide me a reference to modules and functions >that allow the user of the Erlang shell to modify the shell's print >depth and print length. What I usually do is this: {ok, Fd} = file:open("tempfile.txt", [write]), io:fwrite(Fd, "~p~n", [epp:parse_file(...)]), file:close(Fd). Then, I inspect the result using less or Emacs. /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 Tue Feb 6 11:10:02 2001 From: rv@REDACTED (Robert Virding) Date: Tue, 06 Feb 2001 11:10:02 +0100 Subject: Wishes: hex-output In-Reply-To: Your message of "Mon, 05 Feb 2001 12:52:19 +0100." <5.0.2.1.0.20010205125120.00b5a080@mail> Message-ID: <200102061010.LAA22517@trana.bluetail.com> Jakob Cederlund =?iso-8859-1?Q?p=E5?= UAB writes: >What about ????? etc? >Would be better to go to the functions in the OS instead. How do you mean? The i/o libraries are Latin-1 "aware" and print all printable characters. It is also permitted to use the letters from the "upper half" in atom and variable names without quoting. (Of course you can't quote variables) Robert From rv@REDACTED Tue Feb 6 11:30:48 2001 From: rv@REDACTED (Robert Virding) Date: Tue, 06 Feb 2001 11:30:48 +0100 Subject: Optimization of list comprehensions? In-Reply-To: Your message of "Mon, 05 Feb 2001 10:16:48 PST." <20010205101648.A10383@archimedes.oak.suse.com> Message-ID: <200102061030.LAA22607@trana.bluetail.com> David Gould writes: > >I really like list comprehensions, they seem so, declarative. I am tempted >to use them everywhere ;-) > >But, what does the compiler do with them? > >Does it generate better code for a list comprehension than for using >lists:map()? The current (R7) compiler does a reasonable job with and the code is comaprable to using lists:map. The new R8 compiler will do a better job, but it very much depends on what you do in the lc/map which is the faster. Lc's shouldn't be slower. >Is it able to detect when a listcomp is used for its side effects alone and >not build the result? For example, is: > > [io:format('~s~n', [Item]) | Item <- Items]. > >more or less effcient than: > > lists:foreach(fun(Item) -> io:format('~s~n', [Item])) end, Items). > >Oh yeah, is it better or worse style? The compiler does not detect if a comprehension is used for side effects alone. It is, however, definitely much worse style not to use lists:foreach or lists:map where appropriate. lists:foreach explicitly says "do this for each element and throw away the result" while comprehensions say "take elements from generators, filter out unwanted cases and build list of values like this". You should always try and be clear. Anyway we are looking at how to optimise calls to useful functions in the standard libraries, like lists:map and lists:foreach. 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 Tue Feb 6 11:57:30 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 6 Feb 2001 11:57:30 +0100 (MET) Subject: why concurrency in the first place? In-Reply-To: <3A7ED865.E36819DA@imec.be> Message-ID: On Mon, 5 Feb 2001, Karel Van Oudheusden wrote: >I know this may sound like a naieve question but I would like to >have a thorough answer any way :) "Why does an (Erlang) programmer >have to program his application with concurrency explicitly in >mind?" I also know (think) that this was the main intention of the >Erlang language. You bring up an important point. Here's an example, from the world for which Erlang was designed: In a telephone switch, a phone call is set up via control signals on a certain interface. Many calls are set up via the same interface. A handy model for a call setup activity is to split it into two parts, normally called the A (originating) and B (terminating) sides. To make things simple, lets say that we have the following components: a) signaling control link for A side b) A side "half-call" c) B side "half-call" d) resource management for A side interface e) resource management for B side interface f) signaling control link for B side (We've skipped routing, address analysis, and some other fun stuff) It's very easy to apply an Erlang process model to (a), (b), (c) and (f), actually. It nicely depicts the built-in concurrency in the problem. Modeling the problem as objects which may or may not be concurrent in the real world does not aid understanding in this case. Looking into, say, the A side half-call, you will find several independent state machines. They are not concurrent in one sense, as their state transitions are tightly coupled, but you can, for example replace one (protocol) layer 3 FSM with another. As it turns out, implementing these FSMs as separate processes in Erlang would be a mistake. Looking at resource management, (d) and (e), it's natural to view them as two instances of resource management. In the implementation, they are probably either one or two processes, depending on various issues (interface distribution, for example.) Bottom line? As we design these systems, we try to tell programmers to structure their code so that specific use of concurrency constructs is limited to a small part of the code. The Erlang model of concurrency helps us tie the problem specification to a concrete behaviour, while maintaining a very high level of abstraction. Since the Erlang programmer is offered a very "clean" programming environment -- no side effects, no other program poking around in your variables, etc. -- it's easy to concentrate on specifying the program logic, instead of worrying about administrative stuff (memory management, critical sections, and so on.) Then, you can quite easily map your program logic to a concrete implementation, using the built-in concurrency and distribution support. Thus, the step from "abstract" specification to "concrete" specification is very small. >Isn't it easier (cfr. Haskell) to free the programmer (=designer) >from this burden? If a programmer has to specify it (as is the case >in Erlang), he will typically overspecify his system (even if the >processes are light weight). My experience is this: If you spend too much time on your abstract model, without tying it down to a concrete implementation, you will most likely overspecify the system. If you structure your code reasonably well, you will be able to change the concurrency model several times along the way without much impact on the majority of your code; but putting it together and watching it run will also help you find the logical flaws in your "pure" code. >Process spawning and message passing are sources of impureness in >Erlang. This was a pragmatic choice of the Erlang founders. Is >this because it is (still) difficult for pure functional compilers >to do a good job on extracting optimal concurrency from an initially >pure functional specification? Does the Haskell compiler do a good >job on this? Getting the level of concurrency just right in a product such as the AXD 301, cannot be done by a compiler. I can almost guarantee that you will not get it right the first, or even second or third, time. You simply have to work the problem enough to figure out what works best. (http://www.ericsson.se/datacom/products/wan_core/axd301/index.shtml) >I also want to make the following statement (please give feedback): >"It is always easier to specify a system without explicit >concurrency in mind." For example: programming in Haskell (which >is almost similar to specifying) is done in a >concurrency-independent way leaving the eventual implementation to >have any degree of true concurrency, depending on what the compiler >decides is best. At one level of specification (abstract specification), you're right: explicit concurrency shouldn't enter the picture. Purely functional languages do very well in this area. But when taking the abstract model one step further to "concretion" (a terrible word that I just learned), things tend to get messy if your language doesn't support explicit concurrency. >I have looked at the "Erlang/OTP R7 - speed test of new inet driver" >code the last couple of days. It can be found at: >http://www.erlang.se/r7_inet_speed/index.shtm. I am relatively new >to Erlang. I must say that this code is not very readable. I would >typically choose to use more modules in my code. And I am very >astonished about the different (light-weight) processes that are >spawned every now and then. Just to be clear, what you're looking at there is not an abstract specification, nor a concrete specification -- it's deep-core hacking of functionality that you normally keep a safe distance away from any high-level modeling tools. I believe your point, though, is that the code could be written differently without loss of performance, but greatly benefiting readability. You're probably right. Too much industrial product code is butt-ugly when it could be a thing of beauty (the same thing goes for my programs.) This is something one has to learn to live with to some degree. This is how it usually works: 1. You have an idea; you don't know if it will work 2. You slap together a prototype and run it 3. Lo and behold: the idea worked 4. Now you want to make it beautiful... -- Sorry, no time -- lots of other problems to attack; if it works, don't mess with it. Once in a while, you actually _do_ get the time to make something really beautiful. Those are the moments... /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 Sean.Hinde@REDACTED Tue Feb 6 16:36:35 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 6 Feb 2001 15:36:35 -0000 Subject: why concurrency in the first place? Message-ID: <402DD461F109D411977E0008C791C312039F5D4B@imp02mbx.one2one.co.uk> Hello, Thinking a bit more about this it seems to me simply that concurrency is needed when a program needs to have some specific behaviour in the time domain. Many if not most of the IT programmers I have dealt with appear to have no real understanding of the time domain nature of any particular problem (real time or otherwise) - they think this is just down to bigger hardware or something else and they are only required to provide the logic. We are all the victims of this in our use of standard software which regularly shows unresponsive behaviour. Actually printing in the background was a pretty major achievement for word processors yet there are many other places where timeouts and concurrency would save us from an endless wait to regain control of our desktops. More seriously in the internet this lack of regard to the time domain leads to meltdowns and the world wide wait. These are problems which were solved in the telecoms world many decades ago for one simple reason: The time delay between someone answering the phone and the speech path being connected all the way back the originating end before the person says hello is absolutely critical to the user experience 'ello 'ello. This time was measured to be incredibly short (about 100 millisecs or so). The enormous efforts of the telephone industry to achieve this using customised hardware and custom programming languages leaves us with a rich set of tools where all these problems are already solved... So we find that only by providing easy to use and natural constructs for control of the time domain element apparent in almost all programming problems can we hope to overcome these problems. The rest of the IT world struggles on with inappropriate technology when the answer is now readily available thanks to Ericsson. And it's an FPL! - 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 radhia@REDACTED Tue Feb 6 18:34:26 2001 From: radhia@REDACTED (Radhia Cousot) Date: Tue, 06 Feb 2001 18:34:26 +0100 Subject: 8th Static Analysis Symposium : Last CFP Message-ID: <3A8035A2.39D2F51B@lix.polytechnique.fr> -------------- next part -------------- ========My apologies for duplicates of this announcement========= ================================================================= = = = 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 cpressey@REDACTED Tue Feb 6 23:17:21 2001 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 06 Feb 2001 16:17:21 -0600 Subject: Constructive criticism of Erlang Message-ID: <3A8077F1.6F136F62@catseye.mb.ca> Hi again. I hope that everyone can understand: it is because I love Erlang that I must critique it. Keep in mind that it is not only Erlang that is guilty of the flaws I list below - many other high-level languages are as well. (If I were to construct a list like this for Perl or C++ it could very well fill several volumes :-) Also, please excuse me if these issues have already been addressed in the newest versions of the language/revisions of the compiler. I realize I might not have much luck in catching the ear of anyone who is actually responsible for future design of the Erlang language, on this list - presumably, Ericsson is the responsible party for that, open-source does not mean open-design. However, I still think these are valid thoughts which might be interesting to Erlang programmers. 1. Having semicolons as statement seperators instead of statement terminators is basically *annoying* during program maintainance (while adding or removing a statement.) Having an extraneous semicolon (especially before an 'end' token) generate a warning rather than an error would be more pleasant. 2. I don't think I agree with the idea that only some "specially selected" functions should be allowed in guards. This makes guards semantically unorthogonal. I think guards should be thought of as mere syntactic sugar, and the compiler will choose what it determines to be the most efficient manner of implementing the guard. This would help in writing more readable programs. I understand this makes the compiler more complex though, but even under the current system, more BIFs should be allowed in guards. I don't see why I can't say "when element(N, T) == 0", for example; that's fairly lightweight, no? 3. Speaking of making the compiler complex, it would be great if it could deduce the legal set of types used by each argument in each function (perhaps using supplied predicate guards such as record/2), and complain at compile-time if it is ever violated in a subsequent function call. I believe this would be the simplest way to apply "strong typing" to Erlang (since it doesn't change any existing semantics of the language (except for those semantics that are already illegal anyway!)) There's no way it could catch all type errors (send, fun, etc.) but it would be a great step in that direction. And that's basically *it*. I'm a total cynic and I can only find *three* flaws in Erlang that are serious enough to annoy me. This language is a thing of beauty! There are other "features" I have in mind but I can tell that they are far enough beyond the scope of Erlang that adding them would result in a new, descendant language. This leads me to several questions, though. Just how "discouraged" is "discouraged" when it comes to Parse Transformations? Is there any example code for a Parse Transformation? (I imagine not, since it's discouraged.) I can see why this would be, Erlang is supposed to be a fairly predictable language. Playing with the grammar makes it less predictable, and thus should be avoided. I don't wholly disagree. But say I want to build my own numeric data type. Naturally my source will be more readable if I can overload the arithmetic operations +-*/ on it - could I express this as a parse transformation? Basically I'd be representing a numeric datum as a tuple, so I'd want to be able to translate {1, etc} + {2, etc} into mynumeric:add({1, etc}, {2, etc}). I'd be very interested in any feedback! _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From jakob@REDACTED Wed Feb 7 10:50:54 2001 From: jakob@REDACTED (Jakob Cederlund =?iso-8859-1?Q?p=E5?= UAB) Date: Wed, 07 Feb 2001 10:50:54 +0100 Subject: Fwd: Re: Wishes: hex-output Message-ID: <5.0.2.1.0.20010207104922.00bb6800@mail> I was only refering to: >ucase([C|Cs]) when C>=$a,C=<$z -> [C-32|ucase(Cs)]; /Jakob >At 11:10 2001-02-06 +0100, you wrote: >Jakob Cederlund =?iso-8859-1?Q?p=E5?= UAB writes: > >What about ????? etc? > >Would be better to go to the functions in the OS instead. > >How do you mean? The i/o libraries are Latin-1 "aware" and print all >printable characters. It is also permitted to use the letters from the >"upper half" in atom and variable names without quoting. (Of course you >can't quote variables) > > Robert From jakob@REDACTED Wed Feb 7 10:46:55 2001 From: jakob@REDACTED (Jakob Cederlund =?iso-8859-1?Q?p=E5?= UAB) Date: Wed, 07 Feb 2001 10:46:55 +0100 Subject: reloading a linked in driver In-Reply-To: References: Message-ID: <5.0.2.1.0.20010207104426.00bbc810@mail> At 15:03 2001-02-05 -0500, you wrote: >I found that NOT loading the driver again worked: This requires both your functions to be at the same place in the jump table, and all your global (and static) variables to be at the same place. Probably better to avoid it... /Jakob From thomasl@REDACTED Wed Feb 7 11:45:31 2001 From: thomasl@REDACTED (Thomas Lindgren) Date: Wed, 7 Feb 2001 11:45:31 +0100 Subject: Constructive criticism of Erlang In-Reply-To: <3A8077F1.6F136F62@catseye.mb.ca> (message from Chris Pressey on Tue, 06 Feb 2001 16:17:21 -0600) References: <3A8077F1.6F136F62@catseye.mb.ca> Message-ID: <200102071045.LAA01036@lammgam.bluetail.com> I got on a roll here :-) cpressey@REDACTED wrote: > I understand this makes the compiler more complex though, but even under > the current system, more BIFs should be allowed in guards. I don't see > why I can't say "when element(N, T) == 0", for example; that's fairly > lightweight, no? Guards should basically be side-effect free and guaranteed to terminate. Note that element/2 is permitted in guards (see p.29 of the Erlang book). > 3. Speaking of making the compiler complex, it would be great if it > could deduce the legal set of types used by each argument in each > function (perhaps using supplied predicate guards such as record/2), and > complain at compile-time if it is ever violated in a subsequent function > call. I believe this would be the simplest way to apply "strong typing" > to Erlang (since it doesn't change any existing semantics of the > language (except for those semantics that are already illegal anyway!)) > There's no way it could catch all type errors (send, fun, etc.) but it > would be a great step in that direction. Unfortunately, type checking of function calls can be difficult in general. For example, hot code loading means remote calls (between modules) do not have a statically known type. Take the following definition: f(X) -> m:g(X). Since m can be loaded at runtime, you can't say anything about what type X is expected to be. (In fact, it can change as new versions of m are loaded.) So you can't statically derive a type for f/1. There are a number of other problems as well. For example, what _is_ a 'type' in Erlang? In ordinary Hindley-Milner type inference, type constructors can't overlap: you thus know that F(x1,...,xn) always belongs to type T. But Erlang programs are not structured that way; for example, should we separate a tuple {data,X1,X2} from a tuple {A1,A2,A3} (where A1 could happen to be the atom 'data')? And there are some other problems as well. Despite my being a wet blanket above, there has been some work on type checking Erlang. Joe Armstrong and Thomas Arts worked on it at CSLab, as did Wadler and Marlow. Ander Lindgren did a Masters on it. Sven-Olof Nystr?m has had a stab more recently (I've even tested his code a bit :-). (Thomas Arts now works on verification of Erlang, which may be a more fruitful track, since it attacks the truly hair-tearingly difficult bugs.) Anyway, your message inspired me to look for more dark corners to be swept. Here are two: 1. I think records should be cleaned up. The underlying tuple-representation shines through too brightly, and the current operations are too weak (e.g., switching on record type is awkward). Not to mention that include-files are required. To be fair, a better definition is a bit tricky with hot code loading. (There are a couple of proposals being discussed; one by Richard O'Keefe seems to be the favorite.) 2. Another vast and poorly lit area is that of exceptions. Today, there is seldom any way of knowing what sorts of exceptions a function can throw, and the exceptions are usually uninformative (e.g., "badmatch" when you have half a dozen pattern matches in the indicated function). Thus, _using_ the exit reason to recover from an error is difficult. In practice, you print, log or ignore an exit today. I think we should take better advantage of exceptions than we do today. > Is there any example code for a Parse Transformation? (I imagine > not, since it's discouraged.) I think Mnemosyne uses parse transforms. Thomas -- Thomas Lindgren thomas+junk@REDACTED Alteon WebSystems From luke@REDACTED Wed Feb 7 12:04:23 2001 From: luke@REDACTED (Luke Gorrie) Date: 07 Feb 2001 12:04:23 +0100 Subject: Constructive criticism of Erlang In-Reply-To: Chris Pressey's message of "Tue, 06 Feb 2001 16:17:21 -0600" References: <3A8077F1.6F136F62@catseye.mb.ca> Message-ID: Chris Pressey writes: > Just how "discouraged" is "discouraged" when it comes to Parse > Transformations? Is there any example code for a Parse Transformation? > (I imagine not, since it's discouraged.) I can see why this would be, > Erlang is supposed to be a fairly predictable language. Playing with > the grammar makes it less predictable, and thus should be avoided. I > don't wholly disagree. Tobbe's "xx-1.0" on the User Contribution page at erlang.org has a parse transform module which you can read as an example of how to write them. Cheers, Luke From rv@REDACTED Wed Feb 7 12:04:44 2001 From: rv@REDACTED (Robert Virding) Date: Wed, 07 Feb 2001 12:04:44 +0100 Subject: Fwd: Re: Wishes: hex-output In-Reply-To: Your message of "Wed, 07 Feb 2001 10:50:54 +0100." <5.0.2.1.0.20010207104922.00bb6800@mail> Message-ID: <200102071104.MAA04828@trana.bluetail.com> Jakob Cederlund =?iso-8859-1?Q?p=E5?= UAB writes: >I was only refering to: > >>ucase([C|Cs]) when C>=$a,C=<$z -> [C-32|ucase(Cs)]; OK, that would have to be coded something like: ucase([C|Cs]) when C >= $a, C =< $z -> [C - ($a-$A)|ucase(Cs)]; ucase([C|Cs]) when C >= $?, C =< $?, C /= $? -> [C - ($? -$?)|ucase(Cs)]; >>At 11:10 2001-02-06 +0100, you wrote: >>Jakob Cederlund =?iso-8859-1?Q?p=E5?= UAB writes: >> >What about ????? etc? >> >Would be better to go to the functions in the OS instead. >> >>How do you mean? The i/o libraries are Latin-1 "aware" and print all >>printable characters. It is also permitted to use the letters from the >>"upper half" in atom and variable names without quoting. (Of course you >>can't quote variables) >> >> Robert > From rv@REDACTED Wed Feb 7 12:09:54 2001 From: rv@REDACTED (Robert Virding) Date: Wed, 07 Feb 2001 12:09:54 +0100 Subject: Fwd: Re: Wishes: hex-output In-Reply-To: Your message of "Wed, 07 Feb 2001 12:04:44 +0100." <200102071104.MAA04828@trana.bluetail.com> Message-ID: <200102071109.MAA04866@trana.bluetail.com> Robert Virding writes: >OK, that would have to be coded something like: > >ucase([C|Cs]) when C >= $a, C =< $z -> [C - ($a-$A)|ucase(Cs)]; >ucase([C|Cs]) when C >= $?, C =< $?, C /= $? -> > [C - ($? -$?)|ucase(Cs)]; Whoops, that should be: ucase([C|Cs]) when C >= $a, C =< $z -> [C - ($a-$A)|ucase(Cs)]; ucase([C|Cs]) when C >= $?, C =< $?, C /= $? -> [C - ($? -$?)|ucase(Cs)]; Note that the compiler will optimize the ($a-$A) and ($? -$?) expressions, but it can't handle the eqivalent C + $A -$a. Robert From Sean.Hinde@REDACTED Wed Feb 7 12:12:16 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Wed, 7 Feb 2001 11:12:16 -0000 Subject: Constructive criticism of Erlang Message-ID: <402DD461F109D411977E0008C791C312039F5D55@imp02mbx.one2one.co.uk> And there is erl_id_trans in the stdlib src directory. This appears to be there simply as an example of something which wil parse transform all legal code into exactly the same code! Sean > -----Original Message----- > From: Luke Gorrie [mailto:luke@REDACTED] > Sent: 7 February 2001 11:04 > To: Chris Pressey > Cc: Erlang-Questions Mailing List > Subject: Re: Constructive criticism of Erlang > > > Chris Pressey writes: > > > Just how "discouraged" is "discouraged" when it comes to Parse > > Transformations? Is there any example code for a Parse > Transformation? > > (I imagine not, since it's discouraged.) I can see why > this would be, > > Erlang is supposed to be a fairly predictable language. > Playing with > > the grammar makes it less predictable, and thus should be > avoided. I > > don't wholly disagree. > > Tobbe's "xx-1.0" on the User Contribution page at erlang.org has a > parse transform module which you can read as an example of how to > write them. > > Cheers, > Luke > 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 rv@REDACTED Wed Feb 7 12:27:05 2001 From: rv@REDACTED (Robert Virding) Date: Wed, 07 Feb 2001 12:27:05 +0100 Subject: Constructive criticism of Erlang In-Reply-To: Your message of "Tue, 06 Feb 2001 16:17:21 CST." <3A8077F1.6F136F62@catseye.mb.ca> Message-ID: <200102071127.MAA05019@trana.bluetail.com> Chris Pressey writes: > >1. Having semicolons as statement seperators instead of statement >terminators is basically *annoying* during program maintainance (while >adding or removing a statement.) Having an extraneous semicolon >(especially before an 'end' token) generate a warning rather than an >error would be more pleasant. To be consistent you would have to allow it before the final '.' of a function definition as well. Personally I still don't see the problem. :-) >2. I don't think I agree with the idea that only some "specially >selected" functions should be allowed in guards. This makes guards >semantically unorthogonal. I think guards should be thought of as mere >syntactic sugar, and the compiler will choose what it determines to be >the most efficient manner of implementing the guard. This would help in >writing more readable programs. The main criteria is that guard must be side-effect free and guaranteed to terminate. They should preferably also be bounded in time. >Just how "discouraged" is "discouraged" when it comes to Parse >Transformations? Is there any example code for a Parse Transformation? >(I imagine not, since it's discouraged.) I can see why this would be, >Erlang is supposed to be a fairly predictable language. Playing with >the grammar makes it less predictable, and thus should be avoided. I >don't wholly disagree. That was probably a mistake to explicitly discourage parse transforms. The reason was to keep the syntax predictable but there are some pretty neat things you could do. One thought I have had would be to do a much smarter macro package. >But say I want to build my own numeric data type. Naturally my source >will be more readable if I can overload the arithmetic operations +-*/ >on it - could I express this as a parse transformation? Basically I'd >be representing a numeric datum as a tuple, so I'd want to be able to >translate {1, etc} + {2, etc} into mynumeric:add({1, etc}, {2, etc}). You could express this as a parse transform but you might run into trouble with typing. How do you detect that you really want/need to overload a +-*/ ? Robert From raimo@REDACTED Wed Feb 7 15:49:10 2001 From: raimo@REDACTED (Raimo Niskanen) Date: Wed, 07 Feb 2001 15:49:10 +0100 Subject: why concurrency in the first place? References: <3A7ED865.E36819DA@imec.be> Message-ID: <3A816066.2F7D1C16@erix.ericsson.se> Karel Van Oudheusden wrote: > P.S. > I have looked at the "Erlang/OTP R7 - speed test of new inet driver" > code the last couple of days. It can be found at: > http://www.erlang.se/r7_inet_speed/index.shtm. I am relatively new to > Erlang. I must say that this code is not very readable. I would > typically choose to use more modules in my code. And I am very > astonished about the different (light-weight) processes that are spawned > every now and then. Perhaps somebody could explain to me when it is > interesting (from a specification and implementation point of view) to > use a seperate process to accomplish something. I have worked with > multi-threaded languages previously, but I would have typically chosen > other kinds of abstractions than the ones made here. And concluding > from my above remarks, I now think a specification should contain no > concurrency at all. It was a while now, but I feel I have to defend my code a bit. It is a quick hack to get some figures, not a programming example. Two or three modules instead of one might not have hurt, on the other hand all code in one module gives better overview. The many spawned processes probably comes from the fact that one of the things we wanted to see were how the scheduling was affected by the new inet driver. The new driver removed one intermediate process per socket, and effects of this might show up if there were many processes owning sockets executing in the emulator. So, somewhere in the code, an umbrella process is spawned, that spawn_links a lot of processes each owning a socket. The purpose of this umbrella process is that it is linked to all testing (socket owning) processes, and to see if any testing process fails, it is sufficient to monitor the umbrella process. It dies when any testing process dies, which kills all other testing processes. Another reason of complexity is that to get good measurement values, all tests should be run in a fresh node, so memory fragmentation effects becomes repeatable, e.g if the memory becomes fragmented, subsequent tests should not be affected. Therefore the slave:start_link calls, and the spawn(Node, ...) calls. Hope this gives some justification to why the code seems more complex than necessary. / Raimo Niskanen, Ericsson UAB, Erlang/OTP development From vladdu@REDACTED Wed Feb 7 21:11:24 2001 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Wed, 7 Feb 2001 21:11:24 +0100 Subject: why concurrency in the first place? References: Message-ID: Hi I find this discussion very interesting. But right now I'd like to ask something about something Ulf said: From: "Ulf Wiger" > Looking into, say, the A side half-call, you will find several > independent state machines. They are not concurrent in one sense, as > their state transitions are tightly coupled, but you can, for example > replace one (protocol) layer 3 FSM with another. As it turns out, > implementing these FSMs as separate processes in Erlang would be a > mistake. Why would it be a mistake? (I can think of some reasons, but I'd like to hear yours... :-) Is it the tight coupling? Efficiency? A design 'no-no'? regards, Vlad From cpressey@REDACTED Thu Feb 8 00:59:30 2001 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 07 Feb 2001 17:59:30 -0600 Subject: Constructive criticism of Erlang References: <3A8077F1.6F136F62@catseye.mb.ca> <200102071045.LAA01036@lammgam.bluetail.com> Message-ID: <3A81E162.10C27AFA@catseye.mb.ca> Thanks to everyone who responded. Thomas Lindgren wrote: > I got on a roll here :-) > cpressey@REDACTED wrote: > > I understand this makes the compiler more complex though, but even under > > the current system, more BIFs should be allowed in guards. I don't see > > why I can't say "when element(N, T) == 0", for example; that's fairly > > lightweight, no? > Guards should basically be side-effect free and guaranteed to > terminate. Note that element/2 is permitted in guards (see p.29 of the > Erlang book). Whoops, you're right. I jumped the gun here. My test code that "showed" that element/2 didn't work in a guard, was actually broken in a different way. My bad :-) > > 3. Speaking of making the compiler complex, it would be great if it > > could deduce the legal set of types used by each argument in each > > function (perhaps using supplied predicate guards such as record/2) [...] > Unfortunately, type checking of function calls can be difficult in > general. For example, hot code loading means remote calls (between > modules) do not have a statically known type. Take the following > definition: > f(X) -> m:g(X). > Since m can be loaded at runtime, you can't say anything about what > type X is expected to be. (In fact, it can change as new versions of m > are loaded.) So you can't statically derive a type for f/1. That's OK, I don't believe in type inference, really; I think it's too fancy to be warranted in many languages, and I think Erlang is one of those languages. If I define a (static, low-order) function (in this module) like this: foo(X) when atom(X) -> m:g(X); foo(X) when tuple(X) -> n:q(X). Then later I go and do something unwise like foo([a,2,3]); The compiler could (in this very limited instance) check that 'list' is not a member of the set 'atom, tuple' and reject that call (or at least produce a warning). If the guards were left out, then the compiler would have no way to check, and no warnings would appear (which would be like Erlang as it is now.) Now, this isn't some fancy inferred type scheme that tries to predict everything; it's more like explicit typing from Pascal (which does allow overlapping types; e.g. range types.) The important property, that you can build a "strong" sense of identity (checked at compile-time), underlies both systems. (You see, I appreciate and understand functional programming, but I'll never be an FP zealot, so I'm not sold on the FP school's ideas about type systems. In my experience the really useful languages are the ones that combine features from more than one heritage and/or paradigm. Like Erlang!) I'd never propose trying to take the dynamic type system out of Erlang - but supplementing it with a compile-time type checker of any sort would surely increase productivity, as potential errors could be caught without having to test the part of the program which contains the error. > Anyway, your message inspired me to look for more dark corners to be > swept. Here are two: > 1. I think records should be cleaned up. I realize records in Erlang leave a bit to be desired. I find it mildly annoying that I have to re-state the name of the record pretty much everywhere. I would probably find that less annoying if I were a 'Hungarian names' fan, but I'm not. Otherwise, include files for sharing structure declarations, transparency through to the underlying tuple, etc, are suboptimal, but also for the most part adequate, on par with other production languages. > I think we should take better advantage of exceptions than we do > today. I was considering trapping a "badarith" exception to try to accomplish overloading of +-*/, but that sounds like it's probably the wrong way to approach that one. Robert Virding wrote: > Chris Pressey writes: > >1. Having semicolons as statement seperators instead of statement > >terminators is basically *annoying* during program maintainance (while > >adding or removing a statement.) Having an extraneous semicolon > >(especially before an 'end' token) generate a warning rather than an > >error would be more pleasant. > To be consistent you would have to allow it before the final '.' of a > function definition as well. Personally I still don't see the problem. > :-) Sure, what the heck;. :-) The other option would be to make semicolons entirely optional - but I thought that might be a bit risque for Erlang (even though I'm sure the compiler and most humans could handle a semicolon-free source file with few problems.) > >2. I don't think I agree with the idea that only some "specially > >selected" functions should be allowed in guards. This makes guards > >semantically unorthogonal. I think guards should be thought of as mere > >syntactic sugar, and the compiler will choose what it determines to be > >the most efficient manner of implementing the guard. This would help in > >writing more readable programs. > The main criteria is that guard must be side-effect free and guaranteed > to terminate. They should preferably also be bounded in time. OK, I've been thinking about it. To me, the main criteria for a guard is that it *establishes the identity of the arguments* apropos to pattern-matching. Naturally, the methodology for establishing the identity of something should be side-effect free and guaranteed to terminate! I've noticed that most high-level language are made up of several sublanguages. Most languages have a "type system sublanguage": in Erlang guards serve this purpose, but the typing theme seems to go almost unspoken (in the docs I've read so far.) Most languages' type sublanguages are guaranteed to have certain properties - referential transparency is popular, so that specific types (or sets of types) can be predicted at compile-time. > >But say I want to build my own numeric data type. Naturally my source > >will be more readable if I can overload the arithmetic operations +-*/ > >on it - could I express this as a parse transformation? Basically I'd > >be representing a numeric datum as a tuple, so I'd want to be able to > >translate {1, etc} + {2, etc} into mynumeric:add({1, etc}, {2, etc}). > You could express this as a parse transform but you might run into > trouble with typing. How do you detect that you really want/need to > overload a +-*/ ? Good point; a record would of course be better here. If you don't care why I want to do this, you can stop reading here... but for the interested, my beef with Erlang - in fact nigh all modern programming languages - is that they enforce unnatural abstractions on the programmer. My case in point is if you say something like A = 3 This simple-looking statement doesn't actually correlate to the real-world very well, because in the real world the number 3 could mean a great many things. 3 meters? 3 feet? 300% of something else? 3 system failures? 3 stray cats? The programmer simply did not say. If the programmer did not bother to add a comment to clarify it, it might not be apparent from the source code, either. In other words, in real-world models, scalar numbers and units of measurement have a certain parity that should not be split; also, the most maintainable programs in the production sphere are the ones that are closest to their real-world models. Therefore, one of the most valuable things a production language can support is a way to store numbers with units of measurement. But almost no language does this. I once worked on writing my own language to serve this purpose, but it is simply too much work to write an entire full-featured language for such a small (but critical) concept. I began implementing the concept as a numeric type in languages such as Perl. Wherein it seems to work fine, but Perl has been proving to be, er, not the greatest language for real-world models in general. Erlang strikes me as being a much better fit. Partly because of a reason mentioned earlier on, the fact that Erlang types are dynamic, and can overlap: both properties are required to leverage units of measurement fully (I've done some experiments with strong typing and units of measurement, and the results are less than spectacular.) _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From etxuwig@REDACTED Thu Feb 8 09:15:40 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 8 Feb 2001 09:15:40 +0100 (MET) Subject: why concurrency in the first place? In-Reply-To: Message-ID: On Wed, 7 Feb 2001, Vlad Dumitrescu wrote: >Hi > >I find this discussion very interesting. > >But right now I'd like to ask something about something Ulf said: > >From: "Ulf Wiger" >> Looking into, say, the A side half-call, you will find several >> independent state machines. They are not concurrent in one sense, as >> their state transitions are tightly coupled, but you can, for example >> replace one (protocol) layer 3 FSM with another. As it turns out, >> implementing these FSMs as separate processes in Erlang would be a >> mistake. > >Why would it be a mistake? (I can think of some reasons, but I'd >like to hear yours... :-) > >Is it the tight coupling? Efficiency? A design 'no-no'? A couple of reasons: - error handling becomes slightly less straightforward - efficiency suffers because of extra message passing - latency is increased due to scheduling delays /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 cahill@REDACTED Thu Feb 8 14:37:41 2001 From: cahill@REDACTED (Adrian John Cahill) Date: Thu, 08 Feb 2001 13:37:41 +0000 Subject: snmp: subagent varbinds [] Message-ID: <3A82A125.C992A7AC@ocean.ucc.ie> HI, I am getting a generror() everytime i try to set a value in my MIB. I have looked through the snmp:trace , The set operation: succeedes at pahse_one then passes the consistency check I cannot see wether or not it passes the phase two: ** SNMP MASTER-AGENT SETLIB TRACE: consistency check: done ** SNMP MASTER-AGENT SET TRACE: set phase two: MyVarbinds: [{ivarbind,noError, {me,[1,3,6,1,3,7,2], variable, myName, {asn1_type, 'OCTET STRING', 0, 255, [], true, 'DisplayString', false}, 'read-write', {ex1,my_name,[]}, false, undefined, undefined}, {varbind, [1,3,6,1,3,7,2,0], 'OCTET STRING', "Ado", 1}}] SubagentVarbinds: [] ** SNMP MASTER-AGENT SETLIB LOG: apply: ex1,my_name,[set,"Ado"] ** SNMP MASTER-AGENT SETLIB LOG: returned: {'EXIT',{undef,[{ex1,my_name,[set,"Ado"]}, {snmp_set_lib,dbg_apply,3}, {snmp_set_lib,set_value_to_var_mibentry,2}, {snmp_set_lib,try_set,1}, {snmp_set,set_phase_two,2}, {snmp_agent,process_pdu,4}, {snmp_agent,handle_pdu,7}, {snmp_agent,handle_info,2}| more]}} It says the SubagentVarbinds are empty, which is what i would have thought they should be , BUT in the snmp_set.erl file i saw the %%% 1. SET REQUEST %%% %%% 1) Perform set_phase_one for all own vars %%% 2) Perform set_phase_one for all SAs %%% IF nok THEN 2.1 ELSE 3 %%% 2.1) Perform set_phase_two(undo) for all SAs that have performed %%% set_phase_one. %%% 3) Perform set_phase_two for all own vars %%% 4) Perform set_phase_two(set) for all SAs %%% IF nok THEN 4.1 ELSE 5 %%% 4.1) Perform set_phase_two(undo) for all SAs that have performed %%% set_phase_one but not set_phase_two(set). %%% 5) noError wing comment: It looks like step 2.1 is being executed ??? Am i reading this right?? if so has anyone got any suggestions as to how i should go about rectifying this problem. tia Adrian From mbj@REDACTED Thu Feb 8 17:16:46 2001 From: mbj@REDACTED (Martin Bjorklund) Date: Thu, 08 Feb 2001 17:16:46 +0100 Subject: snmp: subagent varbinds [] In-Reply-To: Your message of "Thu, 08 Feb 2001 13:37:41 +0000" <3A82A125.C992A7AC@ocean.ucc.ie> References: <3A82A125.C992A7AC@ocean.ucc.ie> Message-ID: <20010208171646L.mbj@bluetail.com> Adrian John Cahill wrote: > HI, > > I am getting a generror() everytime i try to set a value in my MIB. > I have looked through the snmp:trace , > The set operation: succeedes at pahse_one > then passes the consistency check > I cannot see wether or not it passes the phase two: It fails phase two. > ** SNMP MASTER-AGENT SETLIB LOG: > returned: {'EXIT',{undef,[{ex1,my_name,[set,"Ado"]}, Here's the error. The function ex1:my_name/2 is not defined (maybe you forgot to export my_name/2 from ex1?) /martin From spearce@REDACTED Thu Feb 8 19:39:32 2001 From: spearce@REDACTED (Shawn Pearce) Date: Thu, 8 Feb 2001 13:39:32 -0500 Subject: Constructive criticism of Erlang In-Reply-To: <200102071127.MAA05019@trana.bluetail.com>; from rv@bluetail.com on Wed, Feb 07, 2001 at 12:27:05PM +0100 References: <3A8077F1.6F136F62@catseye.mb.ca> <200102071127.MAA05019@trana.bluetail.com> Message-ID: <20010208133932.P1109@spearce.org> Robert Virding scrawled: > Chris Pressey writes: > >Just how "discouraged" is "discouraged" when it comes to Parse > >Transformations? Is there any example code for a Parse Transformation? > >(I imagine not, since it's discouraged.) I can see why this would be, > >Erlang is supposed to be a fairly predictable language. Playing with > >the grammar makes it less predictable, and thus should be avoided. I > >don't wholly disagree. > > That was probably a mistake to explicitly discourage parse transforms. > The reason was to keep the syntax predictable but there are some pretty > neat things you could do. One thought I have had would be to do a much > smarter macro package. > > >But say I want to build my own numeric data type. Naturally my source > >will be more readable if I can overload the arithmetic operations +-*/ > >on it - could I express this as a parse transformation? Basically I'd > >be representing a numeric datum as a tuple, so I'd want to be able to > >translate {1, etc} + {2, etc} into mynumeric:add({1, etc}, {2, etc}). > > You could express this as a parse transform but you might run into > trouble with typing. How do you detect that you really want/need to > overload a +-*/ ? I can see value in having +-*/ overloaded to some extent on a tuple, as we have two issues -- one is the same as Chris Pressey, we want to be able to keep unit information attached to the values being manipulated -- but the other is that Erlang really doesn't have a full numeric tower and therefore cannot operate as precisely as we'd like with decimal values. I wonder if erts could be extended to recognize that when it gets two tuples as the arguments of a math operator that it uses the first element of the first tuple as a package name, and calls a function from that package to deal with the mess: {useng, 12, 3} + {useng, 6, 2} .... -module(useng). add({useng, AFt, AIn}, {useng, BFt, BIn}) -> RIn = AIn + BIn, if RIn >= 12 -> {useng, AFt + BFt + 1, RIn - 12}; RIn < 12 -> {useng, AFt + BFt, RIn}; end. The other approach might be that there is some sort of table in the emulator that binds the functions and types. For instance, create an ets table that holds 2-tuples of the form: {{a_type, b_type}, {module, function}} where a_type and b_type are the first elements of the tuples given to the math operator. erts just does an ets table lookup for the key {a_type, b_type} and gets back the module and function to invoke via apply to handle the arith op. Yes, its slower than doing the math directly in the function, but it does let us poor users develop our own math packages for complex numbers. Of course, it also would let us add things that aren't really numeric... which some might say adding two records together (as I do above) isn't numeric.... -- Shawn. ``If this had been a real life, you would have received instructions on where to go and what to do.'' From cpressey@REDACTED Fri Feb 9 07:58:45 2001 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 09 Feb 2001 00:58:45 -0600 Subject: Error "mnemosyne query, missing transformation" Message-ID: <3A839525.CD8DE7B6@catseye.mb.ca> I've run across an error compiling Mnemosyne queries that I don't understand. My code looks like this: ... -record(product, { id = 0, name = "", description = "", ... }). ... mnesia:create_schema([node()]), mnesia:start(), mnesia:create_table(product, [{attributes, record_info(fields, product)}]), ... F = fun() -> mnemosyne:eval(query [P.name || P <- table(product), P.name = ProductName ] end) end, {atomic, T} = mnesia:transaction(F), ... When trying to compile this I get the rather unhelpful error message "mnemosyne query, missing transformation" (on the line containing the keyword 'query') for which I can find no more detailed description. (Which surprises me a bit, because this is essentially the example query given in the Mnesia documentation.) I'm using the otp_win32_R7B-0.exe release. This can't possibly be a bug, but I can't think of what I've overlooked in phrasing this query. Thanks in advance... _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From hakan@REDACTED Fri Feb 9 08:37:47 2001 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 9 Feb 2001 08:37:47 +0100 (MET) Subject: Error "mnemosyne query, missing transformation" In-Reply-To: <3A839525.CD8DE7B6@catseye.mb.ca> Message-ID: On Fri, 9 Feb 2001, Chris Pressey wrote: Chris> When trying to compile this I get the rather unhelpful error message Chris> "mnemosyne query, missing transformation" (on the line containing the Chris> keyword 'query') for which I can find no more detailed description. Chris> (Which surprises me a bit, because this is essentially the example query Chris> given in the Mnesia documentation.) Mnemosyne uses parse transforms to extend the Erlang syntax with queries. In order to tell the compiler that it should filter its internal form through Mnemosyne's parse transform function, you need to add the following line in the beginning of your module: -include_lib("mnemosyne/include/mnemosyne.hrl"). /H?kan --- H?kan Mattsson Ericsson Computer Science Laboratory http://www.ericsson.se/cslab/~hakan From gunilla@REDACTED Fri Feb 9 09:26:38 2001 From: gunilla@REDACTED (Gunilla Hugosson) Date: Fri, 09 Feb 2001 09:26:38 +0100 Subject: Erlang Workshop References: <3A81016C.24E64B72@erix.ericsson.se> <3A8107DA.12BB526@erix.ericsson.se> Message-ID: <3A83A9BE.EF8A17B3@erix.ericsson.se> Call for abstracts to the Erlang Workshop Firenze, September 2, 2001, in connection with PLI2001 (Principles, Logics, and Implementations of high-level programming languages). Scope Contributions are invited on experience with and applications of Erlang, critiques and proposals for extensions, design methods and structuring principles for large functional systems, implementation techniques, programming tools, verification methods, etc. Submitted abstracts should be 2-12 pages, and will be judged on the potential for an interesting presentation. Abstracts should in text, postscript or PDF format and send to workshop@REDACTED by May 15, 2001. Authors will be notified of acceptance by June 15, 2001. Authors of accepted abstracts are welcome to submit full papers or additional accompanying materials for inclusion in the informal proceedings by August 15, 2001. Home page of the Erlang workshop http://www.erlang.se/workshop/ Home page of PLI2001 http://music.dsi.unifi.it/pli01/ We are looking forward to an exciting workshop in the environment of PLI2001. Welcome Joe Armstrong, Alteon Websystems Bjarne D?cker, Ericsson Utvecklings AB John Hughes, Chalmers University of Technology Gunilla Hugosson, Ericsson Utvecklings AB (Programme committee) From cpressey@REDACTED Fri Feb 9 10:47:46 2001 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 09 Feb 2001 03:47:46 -0600 Subject: Error "mnemosyne query, missing transformation" References: Message-ID: <3A83BCC2.A4BE96CD@catseye.mb.ca> Hakan Mattsson wrote: > On Fri, 9 Feb 2001, Chris Pressey wrote: > Chris> When trying to compile this I get the rather unhelpful error message > Chris> "mnemosyne query, missing transformation" [...] > -include_lib("mnemosyne/include/mnemosyne.hrl"). Thank you. This might be a good thing to point out in the FAQ and/or section 2.2 of the Mnesia User's Guide. _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From phyllis.lower@REDACTED Sat Feb 10 01:08:09 2001 From: phyllis.lower@REDACTED (Phyllis G Lower) Date: Fri, 9 Feb 2001 18:08:09 -0600 Subject: Erlang C for Excel office 2000 Message-ID: Do you have a formula or add in for calculating Erlang C in Excel for office 2000? Phyllis Lower (405) 782-6103 From peter@REDACTED Sat Feb 10 13:09:47 2001 From: peter@REDACTED (Peter H|gfeldt) Date: Sat, 10 Feb 2001 13:09:47 +0100 (MET) Subject: Erlang C for Excel office 2000 In-Reply-To: Message-ID: erlang.org is for the programming language Erlang. Try the Telecom Traffic Online at www.erlang.com. /Peter ------------------------------------------------------------------------- Peter H?gfeldt e-mail : peter@REDACTED Open Telecom Platform On Fri, 9 Feb 2001, Phyllis G Lower wrote: > Do you have a formula or add in for calculating Erlang C in Excel for > office 2000? > > > Phyllis Lower > (405) 782-6103 > From cpressey@REDACTED Mon Feb 12 07:58:58 2001 From: cpressey@REDACTED (Chris Pressey) Date: Mon, 12 Feb 2001 00:58:58 -0600 Subject: Various (and almost completely unrelated) questions and opinions Message-ID: <3A8789B2.2C7AF20E@catseye.mb.ca> Thanks to everybody for your help; in the open-source spirit I'd like to give something back to the Erlang community. I've written some little Erlang modules in the course of learning Erlang, and they can be found at http://www.catseye.mb.ca/erlang/ They're nothing special, since there are already plenty of good examples of Erlang code out there, and none of these modules are suitable for any particular worthwhile application (except maybe Turtle Erlang?) If you happen to have a look at any of them, I'd be curious to know. Have I made any flagrant violations of coding style, convention etc? (Don't bother mentioning that I should have used yecc for VALGOL - I intentionally did it the hard way to see what it would be like.) Are there any namespace issues? Am I safe distributing these modules as modules, or should I wrap them into applications for more insurance? On general topics, are there any testimonials to the suitability of Erlang's Inets package as a web server outside of an embedded environment - for a real web site (with low-to-moderate traffic)? Are there any noteworthy Erlang projects outside of Erlang's assumed application domain? Specifically, I'm thinking of projects like retail accounting and online games like MUDs. On programming topics, is there any way (using the digraph module) to find a vertex (or edge) in a graph given its label (short of a linear search through the list that is returned by vertices())? (Using such a function would make Wumpus much cleaner.) Semicolons and commas would be nicer if extraneous ones were allowed, however I see now why it is more problematic to do so here, where semicolons and commas have very different semantics from each other. (Compare to Perl or C, where ; and , have almost the same semantics.) Speaking of which, if comma roughly means "and" and semicolon roughly means "or" then the following would make sense to me but is not considered legal by the compiler: fib(1; 2) -> 1; fib(N) when N > 2 -> fib(N-1) + fib(N-2). That may be too risque as well. Partly what I'd like to see is a sort of "Dangerous Erlang" which trades off some of the safety and predictability for flexibility and expressivity. Is there any other programming language out there which claims to be a descendant of Erlang, or lists Erlang as one of its influences? (Barring anything that claims it's a direct "subset" or "superset" or "extended subset" of Erlang) Whew! Sorry if that's too many questions at once. Thanks in advance for any help. _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From tobbe@REDACTED Mon Feb 12 09:35:42 2001 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 12 Feb 2001 09:35:42 +0100 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: Chris Pressey's message of "Mon, 12 Feb 2001 00:58:58 -0600" References: <3A8789B2.2C7AF20E@catseye.mb.ca> Message-ID: The code looks very nice. The only thing I have to say is that in, for example, turtle.erl you have to do the following: Shelly = turtle:new(), Shelly! {fd, 20}. I would have wrapped the message sending in an exported function: Shelly = turtle:new(), turtle:fd(Shelly, 20). That way you have one interface less to worry about. I like to encapsulate the message sending/receiving (i.e the protocol) within a single module (asynchronous messages can be taken care of by function call-backs). Cheers /Tobbe From cpressey@REDACTED Tue Feb 13 09:14:10 2001 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 13 Feb 2001 02:14:10 -0600 Subject: Various (and almost completely unrelated) questions and opinions References: <3A8789B2.2C7AF20E@catseye.mb.ca> Message-ID: <3A88ECD2.96E7C994@catseye.mb.ca> Torbjorn Tornkvist wrote: > The code looks very nice. Thanks. I only hope I can now apply my newly acquired Erlang programming skill to some truly useful purpose... like writing a multiplayer online game :-) More seriously, an Erlang spreadsheet (using GS, eval, and Mnesia) might also be an interesting project; more ambitious, actually potentially useful[1]. > The only thing I have to say is that in, for example, turtle.erl > you have to do the following: > Shelly = turtle:new(), > Shelly! {fd, 20}. > I would have wrapped the message sending in an exported function: > Shelly = turtle:new(), > turtle:fd(Shelly, 20). > That way you have one interface less to worry about. Now that I've read through chapter 5 of the book fully - I understand completely and have updated the code accordingly. > I like to encapsulate the message sending/receiving > (i.e the protocol) within a single module (asynchronous > messages can be taken care of by function call-backs). I see. I decided to make the turtle communication wait for a reply message, so that it could return an error code. The function abstraction is exactly what allows these sorts of design decisions to take place. _chris [1] One thing that bugs me about most commercial spreadsheets is that they make the user learn two very different "sublanguages" - one (pseudo)functional for the spreadsheet calculations, one imperative or object-oriented for the macro or scripting language. An Erlang spreadsheet application would use just one language, Erlang, as the language used in cell calculations, macros, and the implementation of the spreadsheet program itself. I believe this would result in a gentler learning curve, because what you learn about one area of the application you can more easily apply to other areas. -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From tobbe@REDACTED Tue Feb 13 10:37:25 2001 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 13 Feb 2001 10:37:25 +0100 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: Chris Pressey's message of "Tue, 13 Feb 2001 02:14:10 -0600" References: <3A8789B2.2C7AF20E@catseye.mb.ca> <3A88ECD2.96E7C994@catseye.mb.ca> Message-ID: > More seriously, an Erlang spreadsheet (using GS, eval, and Mnesia) might > also be an interesting project; more ambitious, actually potentially > useful[1]. That would be very cool ! JFYI: Tony (Rogvall) made a spreadsheet program some years back. However, I think it has rotten away now... Cheers /Tobbe From davidg@REDACTED Tue Feb 13 22:18:44 2001 From: davidg@REDACTED (David Gould) Date: Tue, 13 Feb 2001 13:18:44 -0800 Subject: Beam files, module beam_lib and source code In-Reply-To: <200102011232.NAA22069@trana.bluetail.com>; from Robert Virding on Thu, Feb 01, 2001 at 01:32:05PM +0100 References: <200102011232.NAA22069@trana.bluetail.com> Message-ID: <20010213131844.B28504@dnai.com> On Thu, Feb 01, 2001 at 01:32:05PM +0100, Robert Virding wrote: > Adding the fix for compile.erl which I posted a few weeks back to change > the default behavior for debug_info in .beam files will not affect all > the libraries built when building the system. However, if size is > important then replace bootstrap/lib/compiler-3.0.1/ebin/compile.beam > with a modified compile.beam. Next time the release is built then all > the libraries will be stripped. This saves about 40% of the size of > the system. Seems like it should be simple to write a tool to strip a beam file, maybe even the basis of one was posted a while back. Or am I missing something? -dg -- David Gould davidg@REDACTED 510 536 1443 If simplicity worked, the world would be overrun with insects. From matthias@REDACTED Tue Feb 13 22:56:49 2001 From: matthias@REDACTED (matthias@REDACTED) Date: Tue, 13 Feb 2001 22:56:49 +0100 (CET) Subject: Error "mnemosyne query, missing transformation" Message-ID: <14985.44449.871880.504905@corelatus.com> Hi, > > Chris> "mnemosyne query, missing transformation" [...] > > -include_lib("mnemosyne/include/mnemosyne.hrl"). > Thank you. This might be a good thing to point out in the FAQ and/or > section 2.2 of the Mnesia User's Guide. This seems like a good time to ask for a volunteer (with more mnesia experience than me, i.e. "some") to write a FAQ section or a standalone FAQ for mnesia. Matthias From rv@REDACTED Wed Feb 14 11:59:53 2001 From: rv@REDACTED (Robert Virding) Date: Wed, 14 Feb 2001 11:59:53 +0100 Subject: Beam files, module beam_lib and source code In-Reply-To: Your message of "Tue, 13 Feb 2001 13:18:44 PST." <20010213131844.B28504@dnai.com> Message-ID: <200102141059.LAA23871@trana.bluetail.com> David Gould writes: >On Thu, Feb 01, 2001 at 01:32:05PM +0100, Robert Virding wrote: >> Adding the fix for compile.erl which I posted a few weeks back to change >> the default behavior for debug_info in .beam files will not affect all >> the libraries built when building the system. However, if size is >> important then replace bootstrap/lib/compiler-3.0.1/ebin/compile.beam >> with a modified compile.beam. Next time the release is built then all >> the libraries will be stripped. This saves about 40% of the size of >> the system. > >Seems like it should be simple to write a tool to strip a beam file, maybe >even the basis of one was posted a while back. Or am I missing something? Yes, of course, it would be quite easy to write one. My main point was that I think the default should be to NOT include the debug info (which is in fact the complete source code) and have the user add it when needed. The fix I sent out did this, and the second message just said how to get this behaviour when building the system. Now, maybe, even if you have the fix you would like to build the system with all the debug info. There should definitely be a config flag for this, but the default should be off. IMAO Robert From centurion@REDACTED Wed Feb 14 18:09:28 2001 From: centurion@REDACTED (Juan A. Suárez Romero) Date: Wed, 14 Feb 2001 18:09:28 +0100 Subject: Design Patterns for Erlang Message-ID: <01021418382600.18691@aliana.dc.fi.udc.es> Hi all. I've been programming with Java during last years, but at present I'm learning Erlang, and it seems very powerful. In the development of my Java applications I used the Erich Gamma's Design Patterns book; but the patterns that appear in it are very based on inheritance and polymorphism, issues that Erlang hasn't. Somebody knows where could I find such patterns (or similar patterns) but applied to Erlang? Regards, J.A. ---------- Dept. of Computer Science University of A Corunna (Spain) From davidg@REDACTED Wed Feb 14 21:28:12 2001 From: davidg@REDACTED (David Gould) Date: Wed, 14 Feb 2001 12:28:12 -0800 Subject: Beam files, module beam_lib and source code In-Reply-To: <200102141059.LAA23871@trana.bluetail.com>; from Robert Virding on Wed, Feb 14, 2001 at 11:59:53AM +0100 References: <20010213131844.B28504@dnai.com> <200102141059.LAA23871@trana.bluetail.com> Message-ID: <20010214122812.A6885@dnai.com> On Wed, Feb 14, 2001 at 11:59:53AM +0100, Robert Virding wrote: > David Gould writes: > >On Thu, Feb 01, 2001 at 01:32:05PM +0100, Robert Virding wrote: > >> Adding the fix for compile.erl which I posted a few weeks back to change > >> the default behavior for debug_info in .beam files will not affect all > >> the libraries built when building the system. However, if size is > >> important then replace bootstrap/lib/compiler-3.0.1/ebin/compile.beam > >> with a modified compile.beam. Next time the release is built then all > >> the libraries will be stripped. This saves about 40% of the size of > >> the system. > > > >Seems like it should be simple to write a tool to strip a beam file, maybe > >even the basis of one was posted a while back. Or am I missing something? > > Yes, of course, it would be quite easy to write one. My main point was > that I think the default should be to NOT include the debug info (which > is in fact the complete source code) and have the user add it when > needed. Right. I didn't mean to dispute that the default should be off, I was just thinking about stripping an existing build without rebuilding it.... -dg -- David Gould davidg@REDACTED 510 536 1443 If simplicity worked, the world would be overrun with insects. From cpressey@REDACTED Wed Feb 14 22:19:56 2001 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 14 Feb 2001 15:19:56 -0600 Subject: Design Patterns for Erlang References: <01021418382600.18691@aliana.dc.fi.udc.es> Message-ID: <3A8AF67C.FFF3D871@catseye.mb.ca> "Juan A. Su?rez Romero" wrote: > Hi all. > I've been programming with Java during last years, but at present I'm learning > Erlang, and it seems very powerful. > In the development of my Java applications I used the Erich Gamma's > Design Patterns book; but the patterns that appear in it are very based on > inheritance and polymorphism, issues that Erlang hasn't. > Somebody knows where could I find such patterns (or similar patterns) but > applied to Erlang? I'm still a newbie to Erlang, but I've worked "across paradigms" before, touching on subjects such as patterns and equivalent notions in different paradigms. Here is how I see it (which hopefully isn't too misinformed): Instead of inheritance, Erlang uses behaviours (functions which take callback functions, as I understand it.) In this way a general module can provide an interface & framework, while specific functionality can be delegated to another module. Delegation is a little more general than inheritance, in that it doesn't denote identity (if A is a subclass of B, then A is a B; if A is a delegate of B, A is not necessarily a B.) Polymorphism is a slightly different matter. Erlang functions are polymorphic in the sense that they can accept arguments of differing types, like polymorphic functions in ML. But this isn't quite the same as the object-oriented sense. However, if the crucial aspect of polymorphism is that a single reference (or name) can refer to more than one kind of thing, then Erlang supports this, in a way, with dynamic typing. Either way, Erlang is not an object-oriented language, so putting either of these concepts into an Erlang program will require some explicit coding, although not as much as in a language such as C. I've wondered if, using structures and funs, one could build a more classically object-oriented structure into an Erlang program, storing funs in structure fields and calling them 'virtual methods;' but it seems like it might be just a waste of time. I'm pretty sure that delegation and polymorphic functions give the programmer nearly the same amount of expressive power as inheritance and polymorphic objects. I'm not certain that they generate the same patterns, but (at an educated guess) they are not too dissimilar, that with some work, they can be applied. Like I said, I'm still pretty new to Erlang, so I might be wrong in the above analysis, and if some really experienced Erlang guru contradicts it, believe them instead! _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From lennart.ohman@REDACTED Wed Feb 14 23:13:51 2001 From: lennart.ohman@REDACTED (Lennart =?iso-8859-1?Q?=D6hman?=) Date: Wed, 14 Feb 2001 23:13:51 +0100 Subject: Design Patterns for Erlang References: <01021418382600.18691@aliana.dc.fi.udc.es> Message-ID: <3A8B031F.A6B3D335@home.se> Hi Juan, at Sj?land & Thyselius Telecom in Stockholm we have done alot of work on design patterns and also one master thesis regarding the use of Erlang/OTP and design patterns focusing on simulations. I will place the report on our web for you to fetch. Best Regards, Lennart "Juan A. Su?rez Romero" wrote: > > Hi all. > > I've been programming with Java during last years, but at present I'm learning > Erlang, and it seems very powerful. > > In the development of my Java applications I used the Erich Gamma's > Design Patterns book; but the patterns that appear in it are very based on > inheritance and polymorphism, issues that Erlang hasn't. > > Somebody knows where could I find such patterns (or similar patterns) but > applied to Erlang? > > Regards, > > J.A. > > ---------- > Dept. of Computer Science > University of A Corunna (Spain) -- ------------------------------------------------------------- Lennart Ohman phone : +46-8-587 623 27 Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735 Sehlstedtsgatan 6 fax : +46-8-667 8230 SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From vances@REDACTED Wed Feb 14 23:56:34 2001 From: vances@REDACTED (Vance Shipley) Date: Wed, 14 Feb 2001 17:56:34 -0500 Subject: Compaq Tru64 UNIX In-Reply-To: <3A8B031F.A6B3D335@home.se> Message-ID: Has anyone ever ported Erlang/OTP to Compaq's Tru64 UNIX running on Alpha processors? How much grief should I expect? -Vance From gulias@REDACTED Thu Feb 15 09:14:10 2001 From: gulias@REDACTED (Victor M. Gulias) Date: 15 Feb 2001 09:14:10 +0100 Subject: Design Patterns for Erlang In-Reply-To: "Juan A. =?iso-8859-1?q?Su=E1rez?= Romero"'s message of "Wed, 14 Feb 2001 18:09:28 +0100" References: <01021418382600.18691@aliana.dc.fi.udc.es> Message-ID: "Juan A. Su?rez Romero" writes: > Hi all. > > I've been programming with Java during last years, but at present I'm learning > Erlang, and it seems very powerful. > > In the development of my Java applications I used the Erich Gamma's > Design Patterns book; but the patterns that appear in it are very based on > inheritance and polymorphism, issues that Erlang hasn't. > > Somebody knows where could I find such patterns (or similar patterns) but > applied to Erlang? First of all, OTP behaviours represent Erlang design patterns as long as they capture good solutions for common problems. Thus, I recommend you the 'Design Principles' section on Erlang documentation to learn about such standard Erlang patterns. In particular, 'gen_server' behaviour is worth read (both documentation and source code). In addition, most of GoF patterns (or variants) can also be implemented using Erlang, even though there is no object-orientation at all (who need objects? read Joe's comments about OO to understand what Erlang people think of objects). In the large project that we are developing at LFCIA, we have identified many problems that could be solved using, for instance, factory methods, mediators, observers, chain of responsability, and so on. Of course, in the implementation you should wisely use the expresiveness of functional programming (who needs to implement a factory class when you can define anonymous functions to perform the same task?). In particular, our monitoring system uses a monitor agent that performs the role of 'Mediator' to implement a variant of the 'Observer' pattern, separating the actual processing from visualization. If this material is interesting for all of you guys, I can write it down for Erlang PLI workshop or next EUC. Regards, -- Victor M. Gulias PS: Juan, I will include this material in my Ph.D. course on distributed functional programming. Of course, you are invited to attend -- just go upstairs (office 4.15) From richardc@REDACTED Thu Feb 15 09:27:06 2001 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 15 Feb 2001 09:27:06 +0100 (MET) Subject: Design Patterns for Erlang In-Reply-To: <01021418382600.18691@aliana.dc.fi.udc.es> Message-ID: On Wed, 14 Feb 2001, Juan A. Su?rez Romero wrote: > In the development of my Java applications I used the Erich Gamma's > Design Patterns book; but the patterns that appear in it are very based on > inheritance and polymorphism, issues that Erlang hasn't. > > Somebody knows where could I find such patterns (or similar patterns) but > applied to Erlang? There is a recent Master's thesis about design patterns and Erlang: ftp://ftp.csd.uu.se/pub/papers/masters-theses/0178-ekstrom.pdf /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 Thu Feb 15 10:40:02 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 15 Feb 2001 10:40:02 +0100 (MET) Subject: defining behaviours (Re: Design Patterns for Erlang) In-Reply-To: Message-ID: On Thu, 15 Feb 2001, Richard Carlsson wrote: >There is a recent Master's thesis about design patterns and Erlang: > > ftp://ftp.csd.uu.se/pub/papers/masters-theses/0178-ekstrom.pdf > > > /Richard Carlsson Good thesis (I've just browsed it.) I'm currently looking at how behaviours are defined. Personally, I don't like the idea of poking into otp_internal.erl in order to define a new behaviour. In practice, this means that users of OTP can't define their own patterns. I would like to propose the following: - The otp_internal:behaviours() function is simply scrapped. If a module defines a compiler directive -behaviour(B), then B should correspond to the name of the module implementing the behaviour. - In each behaviour, export a function B:behaviour_info(Category), for example like this: -module(gen_server). ... -export([behaviour_info/1]). behaviour_info(exports) -> [{init, 1}, {handle_call, 3}, {handle_cast, 2}, {handle_info, 2}, {terminate, 2}, {code_change, 3}]; behaviour_info(_) -> []. The catch-all clause is meant to facilitate additional categories. Furthermore, I'd like to introduce the following requirement: - A behaviour which wants a process must implement a function B:init_it/6, with the following arguments: init_it(Starter, Parent, Name, Mod, Args, Options) -> ... % expected never to return This is not a tough requirement to meet for existing behaviours. Only two behaviours do not do this already: supervisor and supervisor_bridge. In supervisor_bridge, the function could look like this: init_it(Starter, Parent, Name, Mod, Args, Options) -> IArgs = init_args(Args), gen_server:init_it(Starter, Parent, Name, Mod, IArgs, Options). init_args([Mod, StartArgs]) -> [Mod, StartArgs, self]; init_args([Mod, StartArgs, Name]) -> [Mod, StartArgs, Name]. That is, the function essentially calls gen_server:init_it/6, since supervisor_bridge is implemented as a gen_server. Why do this? Because I want to be able tell a supervisor to start a generic server, or other behaviour, and have the supervisor take care of actually starting the process. Three immediate advantages come to mind: - The supervisor can make sure that the process is started with spawn_link(); Today, if a gen_server is started with e.g. gen_server:start(), supervision will be ineffective (no link.) - The supervisor is able to execute in the started process before handing over control to the behaviour. This way, the supervisor can e.g. log information about _why_ the process is started (initial start?, restart?, escalated restart?) -- something that is not possible today. - The child start specification becomes more descriptive. Here's an example of what it could look like: {myServer, gen_server, [{module, myServer}, {args, []}, {regname, {local, myServer}}], permanent, 2000, worker, [myServer]} As you might have guessed, I've written such a supervisor. I will post it shortly. (As some of you know, we at AXD 301 also specify our permanent processes in the .app file, and let a central start function take care of building the supervision hierarchy. The reason for this is to make the process structure more visible.) A still open issue is whether behaviours which do _not_ want a process should also be allowed? Actually, we have one already: application. How would they be defined? Is there a need for additional rules? Comments are welcome. /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 kent@REDACTED Thu Feb 15 12:04:22 2001 From: kent@REDACTED (Kent Boortz) Date: 15 Feb 2001 12:04:22 +0100 Subject: Compaq Tru64 UNIX In-Reply-To: "Vance Shipley"'s message of "Wed, 14 Feb 2001 17:56:34 -0500" References: Message-ID: > Has anyone ever ported Erlang/OTP to Compaq's > Tru64 UNIX running on Alpha processors? > > How much grief should I expect? I haven't heard of a port to Tru64 Unix. How hard it is depends on what you mean - a true 64 bit port or running Erlang/OTP as a 32 bit program on a 64 bit OS. Back in 1995 I did a 32 bit test port to an AlphaStation 400 running Digital Unix (formerly OSF/1). If I remember correctly the main part of the work was to send the right flags to the C compiler and linker, clean up some non ANSI C code and rewrite small amount of C code. I may have forgot some problems doing the port but I expect that the improvements done in the system since makes it easier to do a port. A true 64 bit port is another story. Major changes has to be done. The heap and stack sizes will also be doubled if not some sort of "Erlang process base pointers" are added. kent Ref: http://tru64unix.compaq.com/faqs/publications/porting/HTML/solaris.html#_Toc414071399 http://tru64unix.compaq.com/faqs/publications/base_doc/DOCUMENTATION/V51_HTML/ARH9VCTE/PNTRPPXX.HTM From mickael.remond@REDACTED Thu Feb 15 16:06:33 2001 From: mickael.remond@REDACTED (Mickael Remond) Date: 15 Feb 2001 16:06:33 +0100 Subject: String data type Message-ID: <87u25wasue.fsf@western.ird.idealx.com> Hello, Some times ago, the Erlang people talked about adding the string type into the Erlang code. Is this still something that are interesting the OTP people ? This type would be needed by some of our project and I was thinking that maybe we could help on those aspects Do you have any idea on how to do it ? Do you know how hard it would be ? Thank you in advance for your support. -- Micka?l R?mond tel : (33)1.44.42.00.00 Projet Manager mob : (33)6.60.22.22.16 15 - 17 avenue de S?gur e-mail : mickael.remond@REDACTED 75007 - Paris web : http://IDEALX.com From vances@REDACTED Thu Feb 15 18:11:19 2001 From: vances@REDACTED (Vance Shipley) Date: Thu, 15 Feb 2001 12:11:19 -0500 Subject: Makefile and Erlang In-Reply-To: Message-ID: I wrote: > This is what I use in our Makefile (abreviated version attached): > > %.tar.gz: all %.boot > erl -noshell -s systools make_script $* -s erlang halt > erl -noshell -s systools make_tar $* -s erlang halt > > I use it as: > > $ make January2001.tar.gz > > where I have a release file named January2001.rel I've been trying to get this work but I'm left with one odd little problem. The resulting tar file is missing the .rel file. The interesting thing is if I fire up erl it works: Eshell V5.0.1.1 (abort with ^G) 1> systools:make_tar("February2001"). ok $ gunzip -c February2001.tar.gz | tar tvf - ... -rw-rw-r-- 501/501 206 2001-02-14 18:29:13 releases/February2001.rel There is something quite odd going on here. -Vance From Sean.Hinde@REDACTED Thu Feb 15 18:57:23 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 15 Feb 2001 17:57:23 -0000 Subject: Erlang Open Internet Platform Message-ID: <402DD461F109D411977E0008C791C312039F5D95@imp02mbx.one2one.co.uk> All, I have seen many comments in articles and even on the mailing list which take the position that Erlang/OTP is only of interest if you need to write telephone switch software. I wonder if takeup would be wider if the product were re-invented and renamed as an internet development platform? Just a passing thought.. - 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 vances@REDACTED Thu Feb 15 22:06:12 2001 From: vances@REDACTED (Vance Shipley) Date: Thu, 15 Feb 2001 16:06:12 -0500 Subject: Erlang Open Internet Platform In-Reply-To: <402DD461F109D411977E0008C791C312039F5D95@imp02mbx.one2one.co.uk> Message-ID: Sean Hinde writes: > I have seen many comments in articles and even on the mailing list which > take the position that Erlang/OTP is only of interest if you need to write > telephone switch software. ... Hmmm... I originally found Erlang 4-5 years ago when I was researching Finite State Machines and multi-threading. My original impression was that it was a user land package for implementing threads. Pretty far off I guess but back then there wasn't as much information available outside of Ericsson. My impression from the list has been that most people are in fact using Erlang for the language as opposed to the OTP environment. People are interested in the power of the language. Many people are interested in Mnesia it seems but not much is said about OTP. I had the thought a while back that we might want to have separate mailing lists for Erlang and OTP. > I wonder if takeup would be wider if the product were re-invented and > renamed as an internet development platform? The first thing that springs to mind is the past criticism of string handling in Erlang. That seemed to be a concern to those evaluating Erlang/OTP as a platform for web servers. -Vance From mickael.remond@REDACTED Thu Feb 15 22:45:25 2001 From: mickael.remond@REDACTED (Mickael Remond) Date: 15 Feb 2001 22:45:25 +0100 Subject: Erlang Open Internet Platform In-Reply-To: References: Message-ID: <87r90zpqmi.fsf@western.ird.idealx.com> On Thu, 15 Feb 2001, Vance Shipley wrote: > > My impression from the list has been that most people are in fact using > Erlang for the language as opposed to the OTP environment. People are > interested in the power of the language. Many people are interested in > Mnesia it seems but not much is said about OTP. I had the thought a > while back that we might want to have separate mailing lists for Erlang > and OTP. > In fact, OTP is a very difficult part of the Erlang langage compared to the core langage model. You need a certain experience in Erlang development before realizing that you can do really neat thing when you master the OTP stuff. My opinion is that mixing the two aspects together can help people digging into the OTP part. A lot of "advertised" feature of the langage are only fully accesible when you master behaviour. I had the chance to convince my company to invite an Erlang consultant (Francesco Cesarini) to teach us OTP and I must say that the result is pretty impressive. The quality of your code greatly improve when you start architecturing your process in a supervision tree for example. >> I wonder if takeup would be wider if the product were re-invented and >> renamed as an internet development platform? > > The first thing that springs to mind is the past criticism of string > handling in Erlang. That seemed to be a concern to those evaluating > Erlang/OTP as a platform for web servers. In fact, not only for developping Web server, but all kind of internet applications. It seems that XML is going to leak every as a formal syntax to express various grammar. The spread of XML is a factor that make be believe that we need to create a specific string type (XML is a tree data structure, but most often represented as a string, that you need to manipulate). This was what my previous message was about in fact, and maybe we could help on this specific topic. Regards, -- Micka?l R?mond tel : (33)1.44.42.00.00 Project Manager mob : (33)6.60.22.22.16 15 - 17 avenue de S?gur e-mail : mickael.remond@REDACTED 75007 - Paris web : http://IDEALX.com From mickael.remond@REDACTED Thu Feb 15 22:57:48 2001 From: mickael.remond@REDACTED (Mickael Remond) Date: 15 Feb 2001 22:57:48 +0100 Subject: defining behaviours (Re: Design Patterns for Erlang) In-Reply-To: References: Message-ID: <87lmr7pq1v.fsf@western.ird.idealx.com> On Thu, 15 Feb 2001, Ulf Wiger wrote: > On Thu, 15 Feb 2001, Richard Carlsson wrote: > >>There is a recent Master's thesis about design patterns and Erlang: >> >> ftp://ftp.csd.uu.se/pub/papers/masters-theses/0178-ekstrom.pdf >> >> >> /Richard Carlsson > > Good thesis (I've just browsed it.) I agree with you. Very interesting indeed. > I'm currently looking at how behaviours are defined. > Personally, I don't like the idea of poking into otp_internal.erl > in order to define a new behaviour. In practice, this means that > users of OTP can't define their own patterns. Again I agree. That was one of the first thing that stroke me when reading this text. > I would like to propose the following: > > - The otp_internal:behaviours() function is simply scrapped. > If a module defines a compiler directive -behaviour(B), then > B should correspond to the name of the module implementing the > behaviour. > > - In each behaviour, export a function B:behaviour_info(Category), > for example like this: You seem to be right. Maybe the OTP people could enlight us on this point, but it seems to be a good idea. > (As some of you know, we at AXD 301 also specify our permanent > processes in the .app file, and let a central start function take > care of building the supervision hierarchy. The reason for this is > to make the process structure more visible.) Making OTP in general more visible is a good thing. OTP is really improving your application design, especially thanks to behaviour and should be advertised. > A still open issue is whether behaviours which do _not_ want a > process should also be allowed? Actually, we have one already: > application. How would they be defined? Is there a need for > additional rules? Or, maybe we could extend the question ? Does the application need to be a behaviour or should it be something else ? Really, I have no answer yet. -- Micka?l R?mond tel : (33)1.44.42.00.00 Project Manager mob : (33)6.60.22.22.16 15 - 17 avenue de S?gur e-mail : mickael.remond@REDACTED 75007 - Paris web : http://IDEALX.com From bparsia@REDACTED Thu Feb 15 23:10:29 2001 From: bparsia@REDACTED (Bijan Parsia) Date: Thu, 15 Feb 2001 17:10:29 -0500 (EST) Subject: XML.com article on Functional Programming and XML Message-ID: Hey folks. I've written an overview article on Functional Programming and XML for XML.com, and it just came out! One of the things I specifically plug is Erlang, e.g., XMerL, IDX/Mnesia, etc. The article is very light in tone and aimed toward tantalizing folks unfamilar with FP. Please take a peek! And pass on any comments to me or the folks at ORA. Positive or negative feedback welcome. I'm hoping to produce some more hands-on Erlang articles for XML.com (e.g., building a simple CMS on Inets, XMerL, and IDX/Mnesia), so if anyone has suggestions, material, outlines for articles they'd like to write :), drop me a line! Cheers, Bijan Parsia. From cpressey@REDACTED Fri Feb 16 01:46:19 2001 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 15 Feb 2001 18:46:19 -0600 Subject: Erlang Open Internet Platform References: <402DD461F109D411977E0008C791C312039F5D95@imp02mbx.one2one.co.uk> Message-ID: <3A8C785B.10780145@catseye.mb.ca> Sean Hinde wrote: > All, > I have seen many comments in articles and even on the mailing list which > take the position that Erlang/OTP is only of interest if you need to write > telephone switch software. I wonder if takeup would be wider if the product > were re-invented and renamed as an internet development platform? OTP = Open Telecom Platform. Telecom = Telecommunications = communicating over a remote distance. In what way is the Internet not a form of telecommunications...? ;-) Also, there is so much hype around "internet solutions" these days; I was attracted to Erlang partly because it seems to be able to avoid that stigma by being more general than just that. I feel that Erlang should demonstrate to the world its strengths in an internet setting, by showing off applications such as the Wikie. If it can "walk the walk", it doesn't really matter how it's marketed. _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From lennart.ohman@REDACTED Fri Feb 16 09:08:04 2001 From: lennart.ohman@REDACTED (Lennart =?iso-8859-1?Q?=D6hman?=) Date: Fri, 16 Feb 2001 09:08:04 +0100 Subject: Design Patterns for Erlang References: Message-ID: <3A8CDFE4.6C347C66@st.se> Hi Juan, this is the report I "spoke" of. It is also available from our web now at http://www.st.se/telecom/projects /Lennart Richard Carlsson wrote: > > On Wed, 14 Feb 2001, Juan A. Su?rez Romero wrote: > > > In the development of my Java applications I used the Erich Gamma's > > Design Patterns book; but the patterns that appear in it are very based on > > inheritance and polymorphism, issues that Erlang hasn't. > > > > Somebody knows where could I find such patterns (or similar patterns) but > > applied to Erlang? > > There is a recent Master's thesis about design patterns and Erlang: > > ftp://ftp.csd.uu.se/pub/papers/masters-theses/0178-ekstrom.pdf > > /Richard Carlsson > > Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) > E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ ------------------------------------------------------------- Lennart Ohman phone : +46-8-587 623 27 Sjoland & Thyselius Telecom AB cellular: +46-70-552 6735 Sehlstedtsgatan 6 fax : +46-8-667 8230 SE-115 28 STOCKHOLM, SWEDEN email : lennart.ohman@REDACTED From mickael.remond@REDACTED Fri Feb 16 10:47:57 2001 From: mickael.remond@REDACTED (Mickael Remond) Date: 16 Feb 2001 10:47:57 +0100 Subject: XML.com article on Functional Programming and XML In-Reply-To: References: Message-ID: <87d7cjc62a.fsf@western.ird.idealx.com> On Thu, 15 Feb 2001, Bijan Parsia wrote: > Hey folks. > > I've written an overview article on Functional Programming and XML for > XML.com, and it just came out! > > One of the things I specifically plug is Erlang, e.g., XMerL, IDX/Mnesia, > etc. > > The article is very light in tone and aimed toward tantalizing folks > unfamilar with FP. Please take a peek! And pass on any comments to me or > the folks at ORA. Positive or negative feedback welcome. Oh. This is in fact a very nice article. The explaination of the relationship between functionnal programming langage and XML is excellent. In fact, I would be glad if you could allow me to translate this article in french for my Erlang page, by giving you the proper credit. (And I should probably warn ORA that I did so...) On the content side the explaination of XMLLambda and haXML was very useful because I did not knew this tool. Amongst the Erlang XML tools you now have the Sablatron binding, but I am prettyt sure that you wrote your article before the release of this tool. > I'm hoping to produce some more hands-on Erlang articles for XML.com > (e.g., building a simple CMS on Inets, XMerL, and IDX/Mnesia), so if > anyone has suggestions, material, outlines for articles they'd like to > write :), drop me a line! I have articles in mind about IDX-xmnesia. We are using this tool on real life problem and we are using it to store production data so this is today something more than a simple toy. But I agree with you that today, this is more a developper oriented tool than a user oriented tool and we need to make some effort to make it user/developper friendly and easy to use. This could be a way to dig deeper into XML and Erlang programming and to convince more XML people to have a look at Erlang. So stay tune for more information on IDX-xmnesia. -- Micka?l R?mond From rv@REDACTED Fri Feb 16 12:37:19 2001 From: rv@REDACTED (Robert Virding) Date: Fri, 16 Feb 2001 12:37:19 +0100 Subject: String data type In-Reply-To: Your message of "15 Feb 2001 16:06:33 +0100." <87u25wasue.fsf@western.ird.idealx.com> Message-ID: <200102161137.MAA32615@trana.bluetail.com> Mickael Remond writes: > >Hello, > >Some times ago, the Erlang people talked about adding the string type into the >Erlang code. >Is this still something that are interesting the OTP people ? > >This type would be needed by some of our project and I was thinking that maybe >we could help on those aspects > >Do you have any idea on how to do it ? >Do you know how hard it would be ? The first question is of course what do you *mean* by a string datatype? What type of operations do you intend to do on these strings? Binaries provide efficient storage of bytes and with the new bit-syntax you also get quite a good interface to access binaries. There are some things to watch when building but otherwies it works well. However there are not many libraries to do the same type of operations on binary strings as for normal list strings. One thing to remember though is that most of the low-level i/o modules and functions also accept lists of bytes and binaries for output so it is practical to use different handling for different parts of a message. For example I can pull apart a binary message, process the wrapper, pass the data straight through as a binary and recombine it on output with a new wrapper. Robert From Sean.Hinde@REDACTED Fri Feb 16 13:59:17 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Fri, 16 Feb 2001 12:59:17 -0000 Subject: Erlang Open Internet Platform Message-ID: <402DD461F109D411977E0008C791C312039F5D99@imp02mbx.one2one.co.uk> Chris Wrote> > OTP = Open Telecom Platform. Telecom = Telecommunications = > communicating over a remote distance. In what way is the > Internet not a > form of telecommunications...? ;-) Yes, but it seems that just about every Fred public wants to do "internet programming" whereas "Telecoms programming" is something else entirely. I certainly agree with comments that it is hard work to divine the power of OTP from the standard docs. Worth it but hard work indeed. I'd say they are clearly written though - maybe the difficulty simply comes from the large amount of 'internal reprogramming' needed to flip into that way of thinking.. Presentation as "Design Patterns" as in Ulf Ekstr?m's thesis may make things clearer. > Also, there is so much hype around "internet solutions" these days; I > was attracted to Erlang partly because it seems to be able to > avoid that > stigma by being more general than just that. That is very nice to hear. I hope this reflects a more general outlook.. > I feel that Erlang should demonstrate to the world its strengths in an > internet setting, by showing off applications such as the > Wikie. If it > can "walk the walk", it doesn't really matter how it's marketed. I tried to find some of the links and articles I have come across in the past which portrayed Erlang as some weird specialist telecoms systems development language but I only managed to find some pretty nice ones. How the internet changes when you glance away! Ulf has certainly been busy :) : http://whatis.techtarget.com/WhatIs_Definition_Page/0,4152,212072,00.html - 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 jj@REDACTED Fri Feb 16 15:26:32 2001 From: jj@REDACTED (Joao Jr.) Date: Fri, 16 Feb 2001 11:26:32 -0300 Subject: help! Message-ID: <008501c09824$767e30c0$356429a4@dis.unb.br> Hi, I'm beginner in erlang. I can't use module in erlang, always return message error like: Erlang (BEAM) emulator version 5.0.1 [threads] Eshell V5.0.1 (abort with ^G) 1> -module(demo). ** exited: {undef,[{shell_default,module,[demo]}, {shell,local_func,4}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** 2> What can I do? Thanks, Joao Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From etxuwig@REDACTED Fri Feb 16 15:51:43 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 16 Feb 2001 15:51:43 +0100 (MET) Subject: help! In-Reply-To: <008501c09824$767e30c0$356429a4@dis.unb.br> Message-ID: Hi! You use the -module(...) notation when writing a program. It is what is called a "compiler directive". It is only useful in a program file. What you are doing below is entering commands in the interactive Erlang shell. Here, you can call functions, evaluate expressions, and even assign values to variables, but you cannot use compiler directives. If you want to create a module named demo, create a file called demo.erl. At the top of the file, write "-module(demo)." Then you need to add an "-export(...) directive to be able to call functions from the outside. -module(demo). -export([foo/0]). foo() -> hello. Finally you compile demo.erl. You can do this from the interactive shell: 1> c(demo). {ok, demo} Then you can call your exported functions: 2> demo:foo(). hello /Uffe On Fri, 16 Feb 2001, Joao Jr. wrote: >Hi, I'm beginner in erlang. > >I can't use module in erlang, always return message error like: > > > >Erlang (BEAM) emulator version 5.0.1 [threads] > >Eshell V5.0.1 (abort with ^G) > >1> -module(demo). > >** exited: {undef,[{shell_default,module,[demo]}, > >{shell,local_func,4}, > >{erl_eval,expr,3}, > >{erl_eval,exprs,4}, > >{shell,eval_loop,2}]} ** > >2> > >What can I do? > >Thanks, Joao Jr. > > -- 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 Feb 16 15:55:48 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Fri, 16 Feb 2001 14:55:48 -0000 Subject: help! Message-ID: <402DD461F109D411977E0008C791C312039F5D9E@imp02mbx.one2one.co.uk> Joao, -module is a compiler directive which only has meaning within a source code file. So to have a module called demo you must first create a file called demo.erl (it must be called this - filenames and module names are linked with Erlang) which contains the -module(demo). entry and the source code for your module demo. The downloadable PDF of part 1 of the Erlang book covers these issues very nicely and is a good place to start: http://www.erlang.org/download/erlang-book-part1.pdf Good luck, Sean -----Original Message----- From: Joao Jr. [mailto:jj@REDACTED] Sent: 16 February 2001 14:27 To: erlang-questions@REDACTED Subject: help! Hi, I'm beginner in erlang. I can't use module in erlang, always return message error like: Erlang (BEAM) emulator version 5.0.1 [threads] Eshell V5.0.1 (abort with ^G) 1> -module(demo). ** exited: {undef,[{shell_default,module,[demo]}, {shell,local_func,4}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** 2> What can I do? Thanks, Joao Jr. 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 Fri Feb 16 16:28:36 2001 From: mike@REDACTED (Mike Williams) Date: 16 Feb 2001 15:28:36 GMT Subject: Erlang Open Internet Platform References: <402DD461F109D411977E0008C791C312039F5D95@imp02mbx.one2one.co.uk> Message-ID: <96jgv4$16r$1@news.du.uab.ericsson.se> In article <402DD461F109D411977E0008C791C312039F5D95@REDACTED>, Sean.Hinde@REDACTED (Sean Hinde) writes: |> I have seen many comments in articles and even on the mailing list which |> take the position that Erlang/OTP is only of interest if you need to write |> telephone switch software. I wonder if takeup would be wider if the product |> were re-invented and renamed as an internet development platform? I think there are two ways a programming language (and its runtime environment) becomes popular. 1) It solves a number of useful problems in an easy and time saving way 2) It is hyped hugely by some powerful player. Java, Ada, C++ (SUN, DoD, AT&T) are examples of way 2. FORTRAN, C, Perl (Formula Translation, HW near programming, Much better Scripting Language) are examples of way 1. Getting Erlang more widely spread is a 1) task. Ericsson is a very major player in the Telecoms marketplace, but not in the general computing field. But I hope you all agree that Erlang makes distributed, concurrent programming (so call Internet Programming) much easier. In this light, the "telecoms" background of Erlang works like a life-jacket made of lead. However we see that the number of hits on the Erlang.org site is steadily increasing. As more and more people find uses for Erlang in many different field, the lead in the life-jacket is becoming significantly less heavy. /Mike From matthias@REDACTED Fri Feb 16 18:31:39 2001 From: matthias@REDACTED (matthias@REDACTED) Date: Fri, 16 Feb 2001 18:31:39 +0100 (CET) Subject: Erlang Open Internet Platform In-Reply-To: <96jgv4$16r$1@news.du.uab.ericsson.se> References: <402DD461F109D411977E0008C791C312039F5D95@imp02mbx.one2one.co.uk> <96jgv4$16r$1@news.du.uab.ericsson.se> Message-ID: <14989.25595.974982.447806@corelatus.com> Mike Williams writes: > 2) It is hyped hugely by some powerful player. > > Java, Ada, C++ (SUN, DoD, AT&T) are examples of way 2. I think the hype around C++ came from the compiler vendors (Borland and Microsoft) who essentially gave away C++ compilers with their C compilers. Supposedly ("Design and Evolution of C++") AT&T allocated almost no resources. Maybe C++'s success relies more on people wanting to feel that they were engaged in a more "structured and worthy" form of programming without giving up any of the things they could do in C. Matthias From jamesh@REDACTED Fri Feb 16 21:11:36 2001 From: jamesh@REDACTED (James Hague) Date: Fri, 16 Feb 2001 14:11:36 -0600 Subject: Erlang Open Internet Platform Message-ID: > 1) It solves a number of useful problems in an easy and time > saving way > > 2) It is hyped hugely by some powerful player. > > Java, Ada, C++ (SUN, DoD, AT&T) are examples of way 2. I think C++ is a special case. Its success was a combination of C already being popular and there being much hype about OOP. There were a number of widely promoted languages with OOP features--most notably Borland's Object Pascal, circa 1989--but not too surprisingly something compatible with C took over. > In this light, the "telecoms" background of Erlang works like a > life-jacket made of lead. However we see that the number of hits > on the Erlang.org site is steadily increasing. As more and more people > find uses for Erlang in many different field, the lead in the > life-jacket is becoming significantly less heavy. I agree, even to the point where I think Erlang is a top notch choice for general purpose programming in many cases. The slogan should be "Twice the productivity, half the stress." Heck, I'd just take the latter of those :) The great increase in processor speed and memory capacity is helping as well. When I first ran across the functional language Hope in 1985, I remember thinking "This is cool, but you sure can't do much in 640K." Now I have no idea what to do with all the speed of a 300MHz Pentium II, and that's pretty bottom of the line as far as current consumer machines go. Makes me wonder how things look from the perspective of someone who was using Erlang back when Ericsson was loading up on the ~20MHz Sun workstations (which is what I had at EXU in 1993). James From davidg@REDACTED Fri Feb 16 23:23:55 2001 From: davidg@REDACTED (David Gould) Date: Fri, 16 Feb 2001 14:23:55 -0800 Subject: String data type In-Reply-To: <200102161137.MAA32615@trana.bluetail.com>; from Robert Virding on Fri, Feb 16, 2001 at 12:37:19PM +0100 References: <87u25wasue.fsf@western.ird.idealx.com> <200102161137.MAA32615@trana.bluetail.com> Message-ID: <20010216142355.A27761@dnai.com> On Fri, Feb 16, 2001 at 12:37:19PM +0100, Robert Virding wrote: > > The first question is of course what do you *mean* by a string > datatype? What type of operations do you intend to do on these > strings? > > Binaries provide efficient storage of bytes and with the new bit-syntax > you also get quite a good interface to access binaries. There are some > things to watch when building but otherwies it works well. However > there are not many libraries to do the same type of operations on > binary strings as for normal list strings. I want to have the normal libraries or similar to work with binary strings. That is, I want regexs (eg perlre), spit, join, getline, upcase, str, but do not want to pay the size and time penalties for making lists out of strings. I would really prefer to use Erlang for all those text munging, and report building and scripty things that perl does so very well, but when you need to rip apart hundreds of megabytes of text, the time and space penalties of the list representation are too much. On the topic of: "what else could Erlang have to be a better general purpose tool?", it would be nice to have a mode or an interpreter start file or whatever to make it possible to use Erlang from the shell as easily as perl or pythong scripts. That is, an interpreter behaviour somewhere in between the normal erl node and the SAE link everything yourself tool. That is, if I have a foo.erl source, I want to be able to put "#!/usr/local/bin/erlang" at the top, and then invoke it simply as "./foo.erl -opts somefiles" and have the language take care of compiling and loading the other modules etc as needed. Maybe this could be a -behavior(script) or something. -dg -- David Gould davidg@REDACTED 510 536 1443 If simplicity worked, the world would be overrun with insects. From cpressey@REDACTED Sat Feb 17 00:14:09 2001 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 16 Feb 2001 17:14:09 -0600 Subject: Erlang Open Internet Platform References: <402DD461F109D411977E0008C791C312039F5D99@imp02mbx.one2one.co.uk> Message-ID: <3A8DB441.5A341A20@catseye.mb.ca> Sean Hinde wrote: > Chris Wrote> > > OTP = Open Telecom Platform. Telecom = Telecommunications = > > communicating over a remote distance. In what way is the > > Internet not a > > form of telecommunications...? ;-) > Yes, but it seems that just about every Fred public wants to do "internet > programming" whereas "Telecoms programming" is something else entirely. Agreed, there is that perception. But I'd rather try to change the perception of what is "telecomm" than the perception of what is "Erlang/OTP". Also, I'm not certain I'd like every "Fred" using Erlang for everything! I don't mean that as an elitist remark, only that the pressure placed on Erlang to please everyone would be enormous. I'd rather see the right people using Erlang for the right things. > I certainly agree with comments that it is hard work to divine the power of > OTP from the standard docs. Worth it but hard work indeed. Also agreed. Up until now, I was under the impression that OTP was simply the name of the open-source implementation (compiler+runtime) of Erlang, but I guess there's a lot more to it than just that - its the definition of the entire environment, including applications? > Presentation as "Design Patterns" as in Ulf Ekstr?m's thesis may > make things clearer. Yes. That paper really clarified some things for me. Also, many programmers learn by experimentation. I think if the "barriers to entry" were lowered - e.g. if you didn't have to go in and "hack" source code, which is always distasteful - that might be enough of an initial push to get it going in a more accessible direction. > > Also, there is so much hype around "internet solutions" these days; I > > was attracted to Erlang partly because it seems to be able to > > avoid that > > stigma by being more general than just that. > That is very nice to hear. I hope this reflects a more general outlook.. It would be nice, but seems doubtful - I'm a bit of an outsider. :-) I get the impression that it's worse here in North America, but I see many programmers choose their language(s) because of their jobs, and many projects pick their language based on the cost to hire programmers for that language. I'm disappointed that this circular logic does not in the least consider the language's strengths and weaknesses. It assumes any language is good enough for any project, while in fact that is not the case, or we'd only have one language. _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From ak@REDACTED Sat Feb 17 07:44:16 2001 From: ak@REDACTED (Andi Kleen) Date: Sat, 17 Feb 2001 07:44:16 +0100 Subject: String data type In-Reply-To: <20010216142355.A27761@dnai.com>; from davidg@dnai.com on Fri, Feb 16, 2001 at 02:23:55PM -0800 References: <87u25wasue.fsf@western.ird.idealx.com> <200102161137.MAA32615@trana.bluetail.com> <20010216142355.A27761@dnai.com> Message-ID: <20010217074416.A6192@gruyere.muc.suse.de> On Fri, Feb 16, 2001 at 02:23:55PM -0800, David Gould wrote: > I want to have the normal libraries or similar to work with binary strings. > That is, I want regexs (eg perlre), spit, join, getline, upcase, str, but > do not want to pay the size and time penalties for making lists out of > strings. I would really prefer to use Erlang for all those text munging, > and report building and scripty things that perl does so very well, but > when you need to rip apart hundreds of megabytes of text, the time and > space penalties of the list representation are too much. Instead of ugly regexprs SNOBOL like pattern matching for text would be neat, if you want efficient text manipulation. It would lead Erlang a bit back to its Prolog heritance. -Andi From etxuwig@REDACTED Sat Feb 17 23:03:18 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Sat, 17 Feb 2001 23:03:18 +0100 (MET) Subject: Erlang Open Internet Platform In-Reply-To: Message-ID: On Fri, 16 Feb 2001, James Hague wrote: >When I first ran across the functional language Hope in 1985, I >remember thinking "This is cool, but you sure can't do much in >640K." Now I have no idea what to do with all the speed of a 300MHz >Pentium II, and that's pretty bottom of the line as far as current >consumer machines go. Makes me wonder how things look from the >perspective of someone who was using Erlang back when Ericsson was >loading up on the ~20MHz Sun workstations (which is what I had at >EXU in 1993). My first Erlang environment back in '92-93 was Erlang for MS-DOS (!) on a 20 MHz 386. I also played with a Mac port on my Mac IIx -- but that one crashed so much it wasn't useable. I was full of expectations when I came back to the US with Erlang compiled for the Alpha (we had 6 of them on loan from DEC for a while up in Alaska; they generated so much heat that we didn't need any other heating in the house -- and this was February.)... only to find that DEC had recalled the loaners. So I went out and bought a HP 7000 (36MHz) and bought ($1000) an Erlang license. This was the first time I could actually do something useful with it. This was '94, I think. I'm glad I stuck with it, though. (: /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 cpressey@REDACTED Sun Feb 18 05:23:21 2001 From: cpressey@REDACTED (Chris Pressey) Date: Sat, 17 Feb 2001 22:23:21 -0600 Subject: prelude to a spreadsheet Message-ID: <3A8F4E39.13C0BFC0@catseye.mb.ca> This module, sheet.erl, is currently a badly-written, immature prototype; and it's not even a spreadsheet; but it's a start, it shows that this sort of thing *is* very possible using only GS. http://www.catseye.mb.ca/erlang/sheet/ The basic interface so far is sheet:edit(ListOfListsOfStrings, ConfigList), which displays a "modal" (synchronous) dialogue box which allows the user to edit the list of lists of strings in a GS grid and entry box. The return value is either the altered list or the atom 'cancel'. The impressive test is sheet:test(2), which allowing inserting and deleting rows and demonstrates a derived column. There is no {see} configuration for the grid like there is for the list; the workaround (in sheet:scroll_sheet) is to set {row} twice, which seems to have the equivalent effect. It would be very nice if the grid could support justification of the text in each cell; in the meantime a fixed-width font, plus right-justifying text format functions, are used to simulate that effect. I hope this is eventually more useful to the average Erlang programmer than wumpus.erl, anyway :-) _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From cpressey@REDACTED Sun Feb 18 23:27:33 2001 From: cpressey@REDACTED (Chris Pressey) Date: Sun, 18 Feb 2001 16:27:33 -0600 Subject: Erlang: a European phenomenon? Message-ID: <3A904C55.223F3270@catseye.mb.ca> I was wondering to myself, who else in Canada uses Erlang? Well, the first name that popped into my mind was Ericsson, of course! But after about an hour scouring their employment opportunities ( http://www.ericsson.com/CA/career_opportunities/montreal/jobs.shtml ) I found not a single mention of Erlang! A search for Erlang on Ericsson's global site returns links mainly to ericsson.se with almost no mention of North America. It's not that I'm very surprised, it seems to be giving credit to my theory that companies (esp. in NA) will tend to use languages for which it is cheap to hire programmers... regardless of the language's strengths and weaknesses... a theory that I'd rather see disproven :-) but seems to be an unfortunate economic "truth" of our time. Please, someone tell me I'm not the only person on this continent using Erlang! :-) _chris -- Change rules. Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List http://www.catseye.mb.ca/list.html From tgahling@REDACTED Mon Feb 19 00:10:14 2001 From: tgahling@REDACTED (Tony Gahlinger) Date: Sun, 18 Feb 2001 18:10:14 -0500 Subject: Erlang: a European phenomenon? References: <3A904C55.223F3270@catseye.mb.ca> Message-ID: <3A905656.8B5742B9@ieee.org> Hmm .. try http://www.motivity.ca/ spearheaded by Vance Shipley--a quite regular contributor to this list--with the odd aiding and abetting on my part. We've been using Erlang/OTP as the focal development bed for our telecom products for the past three years. --Tony Chris Pressey wrote: > > I was wondering to myself, who else in Canada uses Erlang? > > Well, the first name that popped into my mind was Ericsson, of course! > But after about an hour scouring their employment opportunities ( > http://www.ericsson.com/CA/career_opportunities/montreal/jobs.shtml ) I > found not a single mention of Erlang! A search for Erlang on Ericsson's > global site returns links mainly to ericsson.se with almost no mention > of North America. > > It's not that I'm very surprised, it seems to be giving credit to my > theory that companies (esp. in NA) will tend to use languages for which > it is cheap to hire programmers... regardless of the language's > strengths and weaknesses... a theory that I'd rather see disproven :-) > but seems to be an unfortunate economic "truth" of our time. > > Please, someone tell me I'm not the only person on this continent using > Erlang! :-) > > _chris > > -- > Change rules. > Share and Enjoy on Cat's Eye Technologies' Electronic Mailing List > http://www.catseye.mb.ca/list.html -- ----------------------------------------------------------- Tony Gahlinger & Associates Inc. Telecommunication Consultants and Software Development 48 Combermere Crescent, Waterloo ON N2L 5B1 519-888-6267 Fax: 519-888-9127 ----------------------------------------------------------- From joe@REDACTED Mon Feb 19 09:26:11 2001 From: joe@REDACTED (Joe Armstrong) Date: Mon, 19 Feb 2001 09:26:11 +0100 (CET) Subject: Erlang: a European phenomenon? In-Reply-To: <3A904C55.223F3270@catseye.mb.ca> Message-ID: > I was wondering to myself, who else in Canada uses Erlang? Nortel :-) /Joe -- Joe Armstrong, Alteon WebSystems, tel: +46 8-545 550 00 S:t Eriksgatan 44, IV, fax: +46 8-654 70 71 SE-112 32 Stockholm, Sweden info: www.bluetail.com From radhia@REDACTED Mon Feb 19 12:05:16 2001 From: radhia@REDACTED (Radhia Cousot) Date: Mon, 19 Feb 2001 12:05:16 +0100 Subject: SAS'01 : Submission Deadline Extension Message-ID: <3A90FDEC.289E615@lix.polytechnique.fr> -------------- next part -------------- ========My apologies for duplicates of this announcement========= ================================================================= = = = Call For Papers = = = = 8th INTERNATIONAL STATIC ANALYSIS SYMPOSIUM = = = = = = La Sorbonne, Paris = = 16-18 July, 2001 = = = = http://www.ens.fr/sas01/ = = = ================================================================= = Submissions deadline extension: February 23, 2001. = ================================================================= 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 23, 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 mbj@REDACTED Mon Feb 19 16:27:51 2001 From: mbj@REDACTED (Martin Bjorklund) Date: Mon, 19 Feb 2001 16:27:51 +0100 Subject: defining behaviours (Re: Design Patterns for Erlang) In-Reply-To: Your message of "Thu, 15 Feb 2001 10:40:02 +0100 (MET)" References: Message-ID: <20010219162751M.mbj@bluetail.com> Ulf Wiger wrote: > I'm currently looking at how behaviours are defined. > Personally, I don't like the idea of poking into otp_internal.erl > in order to define a new behaviour. In practice, this means that > users of OTP can't define their own patterns. I wouldn't go that far - of course users can define new behaviours; you don't have to modify otp_internal.erl at all. The only function provided by otp_internal is that the compiler checks exported functions, and warns if a function required by the behaviour is missing. A behaviour is of course much more than this... This being said, I think what you propose (the behaviour 'behaviour' :) below should have been done a long time ago. (As many other things, it was a Qn'D hack which seemed fun at the time.) > I would like to propose the following: > > - The otp_internal:behaviours() function is simply scrapped. > If a module defines a compiler directive -behaviour(B), then > B should correspond to the name of the module implementing the > behaviour. > > - In each behaviour, export a function B:behaviour_info(Category), > for example like this: > > > -module(gen_server). > ... > -export([behaviour_info/1]). > > > behaviour_info(exports) -> > [{init, 1}, {handle_call, 3}, {handle_cast, 2}, {handle_info, 2}, > {terminate, 2}, {code_change, 3}]; > behaviour_info(_) -> > []. But I think it should be a bit more detailed, specifically we should make a distiction between mandatory and optional functions: -module(gen_server). ... -export([behaviour_info/1]). behaviour_info(mandatory_exports) -> [{init, 1}, {terminate, 2}]; behaviour_info(optional_exports) -> [{handle_call, 3}, {handle_cast, 2}, {handle_info, 2}, {code_change, 3}]; behaviour_info(_) -> []. > Furthermore, I'd like to introduce the following requirement: > > - A behaviour which wants a process must implement a function > B:init_it/6, with the following arguments: Comments below. > Why do this? > > Because I want to be able tell a supervisor to start a generic > server, or other behaviour, and have the supervisor take care of > actually starting the process. What do you mean - the supervisor starts the process already...? > Three immediate advantages come to > mind: > > - The supervisor can make sure that the process is started with > spawn_link(); Today, if a gen_server is started with e.g. > gen_server:start(), supervision will be ineffective (no link.) The supervisor could call link() explicitly to acheive this effect. We had endless discussions about this when we implemented this... It's not safe anyway, since the process could call unlink() when it's started. monitor is not a good idea either, since the child wants to be notified if the supervisor dies. We agreed that the supervision mechanism as it is today is for co-operating processes. > - The supervisor is able to execute in the started process before > handing over control to the behaviour. This way, the supervisor > can e.g. log information about _why_ the process is started > (initial start?, restart?, escalated restart?) -- something that > is not possible today. On the other hand, today the call-back process is able to execute in the supervisor before the process is started. This feature can be used, and is used, in many interesting ways... ;-) > A still open issue is whether behaviours which do _not_ want a > process should also be allowed? Actually, we have one already: > application. And gen_event. They should definitely be allowed! /martin From etxuwig@REDACTED Mon Feb 19 17:00:32 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 19 Feb 2001 17:00:32 +0100 (MET) Subject: defining behaviours (Re: Design Patterns for Erlang) In-Reply-To: <20010219162751M.mbj@bluetail.com> Message-ID: On Mon, 19 Feb 2001, Martin Bjorklund wrote: >Ulf Wiger wrote: > >> I'm currently looking at how behaviours are defined. >> Personally, I don't like the idea of poking into otp_internal.erl >> in order to define a new behaviour. In practice, this means that >> users of OTP can't define their own patterns. > >I wouldn't go that far - of course users can define new behaviours; >you don't have to modify otp_internal.erl at all. The only function >provided by otp_internal is that the compiler checks exported >functions, and warns if a function required by the behaviour is >missing. A behaviour is of course much more than this... Hmm, yes, I'll grant you that. What I meant was that when people define their own behaviours, they want to be able to enforce these checks as well... and others. There should perhaps be a good way to add your own functionality to the linter. >> behaviour_info(exports) -> >> [{init, 1}, {handle_call, 3}, {handle_cast, 2}, {handle_info, 2}, >> {terminate, 2}, {code_change, 3}]; >> behaviour_info(_) -> >> []. > >But I think it should be a bit more detailed, specifically we should >make a distiction between mandatory and optional functions: > > >-module(gen_server). >... >-export([behaviour_info/1]). > >behaviour_info(mandatory_exports) -> > [{init, 1}, {terminate, 2}]; >behaviour_info(optional_exports) -> > [{handle_call, 3}, {handle_cast, 2}, {handle_info, 2}, > {code_change, 3}]; >behaviour_info(_) -> > []. Good idea. >> Furthermore, I'd like to introduce the following requirement: >> >> - A behaviour which wants a process must implement a function >> B:init_it/6, with the following arguments: > >Comments below. > >> Why do this? >> >> Because I want to be able tell a supervisor to start a generic >> server, or other behaviour, and have the supervisor take care of >> actually starting the process. > >What do you mean - the supervisor starts the process already...? Erm, not exactly. The function that spawns the process does execute in the supervisor process, but the supervisor has no control over it: it simply calls an opaque function which (presumably) calls some version of spawn, and returns a pid. What I meant was that the supervisor should be given a specification and _specifically_ start the process. >> Three immediate advantages come to >> mind: >> >> - The supervisor can make sure that the process is started with >> spawn_link(); Today, if a gen_server is started with e.g. >> gen_server:start(), supervision will be ineffective (no link.) > >The supervisor could call link() explicitly to acheive this effect. >We had endless discussions about this when we implemented this... >It's not safe anyway, since the process could call unlink() when it's >started. Yes, but there's a distinct difference between e.g. calling gen_server:start() instead of gen_server:start_link() because you didn't know any better, and explicitly unlinking from the supervisor, which is really a form of sabotage. >monitor is not a good idea either, since the child wants to >be notified if the supervisor dies. We agreed that the supervision >mechanism as it is today is for co-operating processes. I'm thinking that the supervisor needs to use both: monitor in order to have _guaranteed_ supervision of the child, and link in order to facilitate cascading EXITs. If the child unlinks from the supervisor, it might mess up the cascading EXIT, but the supervisor must always be able to detect a crashed child. >> - The supervisor is able to execute in the started process before >> handing over control to the behaviour. This way, the supervisor >> can e.g. log information about _why_ the process is started >> (initial start?, restart?, escalated restart?) -- something that >> is not possible today. > >On the other hand, today the call-back process is able to execute in >the supervisor before the process is started. This feature can be >used, and is used, in many interesting ways... ;-) Yes, and I've been thinking that it would perhaps be better if the supervisor was simply given a spec, and we do away with the callback completely. However, I realise that your smiley refers to my sysSupervisor callback, which is most likely the most ambitious supervisor callback yet -- even inventing atoms at runtime. (: On second thought, we may want to keep the callback module. >> A still open issue is whether behaviours which do _not_ want a >> process should also be allowed? Actually, we have one already: >> application. > >And gen_event. They should definitely be allowed! Oh yes, I forgot about those. (: /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 Mon Feb 19 17:12:06 2001 From: mbj@REDACTED (Martin Bjorklund) Date: Mon, 19 Feb 2001 17:12:06 +0100 Subject: defining behaviours (Re: Design Patterns for Erlang) In-Reply-To: Your message of "Mon, 19 Feb 2001 16:27:51 +0100" <20010219162751M.mbj@bluetail.com> References: <20010219162751M.mbj@bluetail.com> Message-ID: <20010219171206E.mbj@bluetail.com> A somewhat related issue - the currently internal module 'gen' should be documented, as it's very helpful when implementing new behaviours (and also when implementing ordinary erlang processes). It provides e.g. a well-tested implementation of call(Process, Request [, Timeout]). /martin From per@REDACTED Mon Feb 19 17:22:16 2001 From: per@REDACTED (Per Bergqvist) Date: Mon, 19 Feb 2001 17:22:16 +0100 Subject: Memory leak in dist.c Message-ID: <3A914838.A412E079@cellpt.com> Hi all, Found a small but annoying bug in dist.c today. When monitoring remote processes all structures are not cleaned up. This patch seems to solve it. It would be nice if somebody with real indepth knowledge of beam could verify the patch. Rgds, Per Bergqvist -------------- next part -------------- 689a690 > del_link(lnkp); From davidg@REDACTED Mon Feb 19 23:53:29 2001 From: davidg@REDACTED (David Gould) Date: Mon, 19 Feb 2001 14:53:29 -0800 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: <3A8789B2.2C7AF20E@catseye.mb.ca>; from Chris Pressey on Mon, Feb 12, 2001 at 12:58:58AM -0600 References: <3A8789B2.2C7AF20E@catseye.mb.ca> Message-ID: <20010219145329.A22578@dnai.com> On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote: ... > Speaking of which, if comma roughly means "and" and semicolon roughly > means "or" then the following would make sense to me but is not > considered legal by the compiler: > > fib(1; 2) -> 1; fib(N) when N > 2 -> fib(N-1) + fib(N-2). > > That may be too risque as well. Partly what I'd like to see is a sort > of "Dangerous Erlang" which trades off some of the safety and > predictability for flexibility and expressivity. Is there any other > programming language out there which claims to be a descendant of > Erlang, or lists Erlang as one of its influences? (Barring anything > that claims it's a direct "subset" or "superset" or "extended subset" of > Erlang) Hmmm, I am thinking, "typeless Haskell" ;-) -dg -- David Gould davidg@REDACTED 510 536 1443 If simplicity worked, the world would be overrun with insects. From cpressey@REDACTED Tue Feb 20 01:29:19 2001 From: cpressey@REDACTED (Chris Pressey) Date: Mon, 19 Feb 2001 18:29:19 -0600 Subject: Various (and almost completely unrelated) questions and opinions References: <3A8789B2.2C7AF20E@catseye.mb.ca> <20010219145329.A22578@dnai.com> Message-ID: <3A91BA5F.952C681@catseye.mb.ca> David Gould wrote: > On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote: > > [...] Partly what I'd like to see is a sort > > of "Dangerous Erlang" which trades off some of the safety and > > predictability for flexibility and expressivity. [...] > Hmmm, I am thinking, "typeless Haskell" ;-) Well, not entirely typeless - for that I think you have to go back to the lambda calculus itself or "alternative" languages like Unlambda, where there is only one "type", the function. Erlang has a type system, it is just not strongly typed (but there are seperate static analysis tools to do that, too.) Also I like Erlang's eager evaluation much better than Haskell's lazy evaluation. It is easy enough to build a lazy evaluator in Erlang if you need one. I've heard it said that "the number of Haskell programmers worldwide could fit in my bathroom" - Erlang's takeup may not be explosively large, but I think more people are actually *using* it for something, than Haskell. IMO Haskell == sophisticated, Perl == expedient, Erlang == one of the best blends of sophistication & expediency since... well, since C! I've had some thoughts about overloading operators, btw. I think it's only of limited use unless you can have user-defined functions in guards. This is assuming that the semantics of any overloaded operator are expressed by a user-defined function, and that relational operators can be overloaded. As an example, I would like to write code like this, in some sort of idealized Erlang-like language, simply for readability and clarity: delivery_charge(Shipment) when Shipment.distance > 5km -> $5.00/km * (Shipment.distance - 5km); delivery_charge(Shipment) -> $2.00. Obviously, I could write code which does exactly the same thing in Erlang, but it would be relatively ugly and cumbersome. Instead of the ">" operator, I'd have to use a measurement:greater_than() function, which is a more awkward syntax, and can't be used in a guard either. The literal units of measurement would as well have to be expressed as fairly awkward-looking function invokations like measurement:new(5.00, [{'$',1},{km,-1}]). Overloading only solves one of these problems, the rest remain and must be worked around by other means. The result is that I think I will continue on the path of writing a little language around the measurement data type, since Erlang alone can't handle it very nicely. The good news is that this little language will be heavily influenced by Erlang and the compiler will probably be written in Erlang and translate to Erlang - sort of a sublanguage for modules which rely heavily on manipulation of values with units of measurement. _chris -- "Ten short days ago all I could look forward to was a dead-end job as a engineer. Now I have a promising future and make really big Zorkmids." Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/ Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html From cpressey@REDACTED Tue Feb 20 01:44:27 2001 From: cpressey@REDACTED (Chris Pressey) Date: Mon, 19 Feb 2001 18:44:27 -0600 Subject: Erlang: a European phenomenon? References: <3A904C55.223F3270@catseye.mb.ca> <3A905656.8B5742B9@ieee.org> Message-ID: <3A91BDEB.669A45B1@catseye.mb.ca> Tony Gahlinger wrote: > Hmm .. try > http://www.motivity.ca/ > spearheaded by Vance Shipley--a quite regular contributor to this > list--with the odd aiding and abetting on my part. We've been using > Erlang/OTP as the focal development bed for our telecom products for > the past three years. D'oh. A simple search for "Erlang Canada" on dogpile would have revealed Motivity. Thanks and sorry to bother you for it. For completeness' sake, I also found a Toronto company called Vengeance ( http://www.venge.net/ ) which advertises their ability to use Erlang as well. Does anyone know what happened to ETOS? The URL http://www.iro.umontreal.ca/~etos/ seems to have changed permissions and is no longer world-readable. _chris -- "Ten short days ago all I could look forward to was a dead-end job as a engineer. Now I have a promising future and make really big Zorkmids." Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/ Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html From davidg@REDACTED Tue Feb 20 04:51:28 2001 From: davidg@REDACTED (David Gould) Date: Mon, 19 Feb 2001 19:51:28 -0800 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: <3A91BA5F.952C681@catseye.mb.ca>; from Chris Pressey on Mon, Feb 19, 2001 at 06:29:19PM -0600 References: <3A8789B2.2C7AF20E@catseye.mb.ca> <20010219145329.A22578@dnai.com> <3A91BA5F.952C681@catseye.mb.ca> Message-ID: <20010219195128.D24064@dnai.com> On Mon, Feb 19, 2001 at 06:29:19PM -0600, Chris Pressey wrote: > David Gould wrote: > > On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote: > > > [...] Partly what I'd like to see is a sort > > > of "Dangerous Erlang" which trades off some of the safety and > > > predictability for flexibility and expressivity. [...] > > Hmmm, I am thinking, "typeless Haskell" ;-) > > Well, not entirely typeless - for that I think you have to go back to > the lambda calculus itself or "alternative" languages like Unlambda, > where there is only one "type", the function. Erlang has a type system, > it is just not strongly typed (but there are seperate static analysis > tools to do that, too.) Well, it was sort of a joke. It is just that since there is a constant flamewar on comp.lang.functional about the necessity (or is it morality) of strict typing, I decided to learn a little about haskell too. Without insight, it is pretty on the page. Which I find to be a very good first discriminator for languages. Ugly source text, ugly all the way down. Canonical example: C++. > Also I like Erlang's eager evaluation much better than Haskell's lazy > evaluation. It is easy enough to build a lazy evaluator in Erlang if > you need one. > > I've heard it said that "the number of Haskell programmers worldwide > could fit in my bathroom" - Erlang's takeup may not be explosively > large, but I think more people are actually *using* it for something, > than Haskell. Well yes. I do know of a few people doing things with ocaml though, so it might be as widely used. But from the little I have looked at it, it seems to not quite pass the ugly test. All the let in and in and in ... > IMO Haskell == sophisticated, Perl == expedient, Erlang == one of the > best blends of sophistication & expediency since... well, since C! Very good, I like the observation about the blend as applied to C. I used (back in the early 80s) to love C, but it gets worse as time goes by and really is not a good choice for most of the things people use it for. I agree, the blend of beauty and ruthless pragmatism in Erlang is rarely found. And you can even use the curly braces for something (the essential criteria for language success as far as I can tell from the recent historical evidence ;-)). More later, I have a wife yelling something about dinner now.... -dg -- David Gould davidg@REDACTED 510 536 1443 If simplicity worked, the world would be overrun with insects. From vladdu@REDACTED Tue Feb 20 09:52:36 2001 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Tue, 20 Feb 2001 09:52:36 +0100 Subject: Erlang as .so Message-ID: Hi all! I wonder if it's possible to use the Erlang VM as a shared library, to be included in another program. This for example would allow a nicer graphical interface. Can it be done? If yes, is it documented? It would be nice if it was a fully encapsulated library (? la SAE), but for now I'd settle for just sharing 'erl' My priority list is to first try it on Windows, and then check Linux. cheers, Vlad _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. From Sean.Hinde@REDACTED Tue Feb 20 12:05:20 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 20 Feb 2001 11:05:20 -0000 Subject: String data type Message-ID: <402DD461F109D411977E0008C791C312039F5DAD@imp02mbx.one2one.co.uk> > On the topic of: "what else could Erlang have to be a better > general purpose > tool?", it would be nice to have a mode or an interpreter > start file or > whatever to make it possible to use Erlang from the shell as > easily as perl > or pythong scripts. That is, an interpreter behaviour > somewhere in between > the normal erl node and the SAE link everything yourself > tool. That is, if I > have a foo.erl source, I want to be able to put > "#!/usr/local/bin/erlang" at > the top, and then invoke it simply as "./foo.erl -opts > somefiles" and have I stumbled across this link while following some other link somewhere. I hope that Dan doesn't mind.. and I've no idea of the status... http://www.ericsson.se/cslab/~dan/proj/escript/ - 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 Lon.Willett@REDACTED Tue Feb 20 12:23:45 2001 From: Lon.Willett@REDACTED (Lon Willett) Date: 20 Feb 2001 11:23:45 +0000 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: Chris Pressey's message of "Mon, 19 Feb 2001 18:29:19 -0600" References: <3A8789B2.2C7AF20E@catseye.mb.ca> <20010219145329.A22578@dnai.com> <3A91BA5F.952C681@catseye.mb.ca> Message-ID: Chris Pressey writes: [snip] > Also I like Erlang's eager evaluation much better than Haskell's lazy > evaluation. It is easy enough to build a lazy evaluator in Erlang if > you need one. [snip] I prefer the eager ("strict") evaluation too, as a default. But there are some nice things that can be done with lazy evaluation: streams as lists, some clever data structures, etc. And it is not so trivial to write a lazy evaluator; any reasonable implementation would require changes to the VM. I briefly (as in for a few moments; then reality set in and I moved on to more pressing matters) considered modifying the beam type system to support "promises", or whatever one wants to call the delayed- evaluation objects. It probably wouldn't be too hard, but there are some tricky issues as to what one should do with them when they are passed in a message, or passed to term_to_binary. If someone else has implemented this, then I'd be interested in the results. And while on the topic of useful language extensions: has anyone implemented weak-reference ets tables? (Actually, with weak-reference ets tables, one could write a lazy-evaluator that has almost reasonable performance, although I suspect that the memory usage characteristics would lead to a bit of thrashing). /Lon -- Lon Willett Security Architect, SSE Ltd. Fitzwilliam Court, Leeson Close Dublin 2, Ireland +353-1-216-2946 +353-87-8053539 (mobile) From rv@REDACTED Tue Feb 20 12:52:45 2001 From: rv@REDACTED (Robert Virding) Date: Tue, 20 Feb 2001 12:52:45 +0100 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: Your message of "20 Feb 2001 11:23:45 GMT." Message-ID: <200102201152.MAA07971@trana.bluetail.com> Lon Willett writes: >And while on the topic of useful language extensions: has anyone >implemented weak-reference ets tables? (Actually, with weak-reference >ets tables, one could write a lazy-evaluator that has almost >reasonable performance, although I suspect that the memory usage >characteristics would lead to a bit of thrashing). That would be very difficult as ets tables do NOT share their data with anything. Each table creates a local copy of all data inserted in it and on lookup data is copied back. Robert From Lon.Willett@REDACTED Tue Feb 20 14:21:45 2001 From: Lon.Willett@REDACTED (Lon Willett) Date: 20 Feb 2001 13:21:45 +0000 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: Robert Virding's message of "Tue, 20 Feb 2001 12:52:45 +0100" References: <200102201152.MAA07971@trana.bluetail.com> Message-ID: Robert Virding writes: > Lon Willett writes: > >And while on the topic of useful language extensions: has anyone > >implemented weak-reference ets tables? [snip] > > That would be very difficult as ets tables do NOT share their data with > anything. Each table creates a local copy of all data inserted in it > and on lookup data is copied back. Oops. I knew that. Some kind of weak reference would be handy though. (ets tables just jumped to mind because of familiarity with a few lisp/scheme implementations of weak-reference hash-tables). Hmmm. Maybe a per-process table: put_weak and get_weak? Oh well. It's not so important. Weak-references have always struck me as rather a kludge anyway (but a useful kludge, for a certain subset of problems). /Lon From olgeni@REDACTED Tue Feb 20 14:41:36 2001 From: olgeni@REDACTED (Jimmy Olgeni) Date: Tue, 20 Feb 2001 14:41:36 +0100 (CET) Subject: erlang patches after R7B-1? Message-ID: Hi, I was poking around the erlang site and noticed that the bug fixes page (http://www.erlang.org/faq/bugs_and_fixes.html) is still at R6B. Are there any post-R7B-1 patches? -- jimmy From paf@REDACTED Tue Feb 20 17:25:48 2001 From: paf@REDACTED (Paulo Ferreira) Date: Tue, 20 Feb 2001 16:25:48 +0000 Subject: Doubt about funs Message-ID: Well, here is my doubt: Taken fom the Erlang Extensions doc: "We can also refer a function defined in a different module with the following syntax: F = {Module,FunctionName} " In this case, how does Erlang gets the correct function, if in the module are several functions, with the same name but with different arity ? I know it gets the correct function, at least in the same module, because I tested it. Thanks Paulo Ferreira ------------------------------------------------ Paulo Ferreira paf@REDACTED From jamesh@REDACTED Tue Feb 20 18:04:49 2001 From: jamesh@REDACTED (James Hague) Date: Tue, 20 Feb 2001 11:04:49 -0600 Subject: Doubt about funs Message-ID: > Well, here is my doubt: > > Taken fom the Erlang Extensions doc: > > "We can also refer a function defined in a different module with > the following syntax: > > F = {Module,FunctionName} " > > > In this case, how does Erlang gets the correct function, if > in the module are several functions, with the same name > but with different arity ? Context, I would think: F(1,2) % arity 2 F(blah) % arity 1 From feeley@REDACTED Tue Feb 20 18:12:46 2001 From: feeley@REDACTED (Marc Feeley) Date: Tue, 20 Feb 2001 12:12:46 -0500 Subject: Erlang: a European phenomenon? In-Reply-To: <3A91BDEB.669A45B1@catseye.mb.ca> (message from Chris Pressey on Mon, 19 Feb 2001 18:44:27 -0600) References: <3A904C55.223F3270@catseye.mb.ca> <3A905656.8B5742B9@ieee.org> <3A91BDEB.669A45B1@catseye.mb.ca> Message-ID: <200102201712.f1KHCk618654@dino02.IRO.UMontreal.CA> > Does anyone know what happened to ETOS? The URL > http://www.iro.umontreal.ca/~etos/ seems to have changed permissions and > is no longer world-readable. The project is still ongoing. The bottleneck right now is the next release of the Gambit-C Scheme compiler which is taking much longer than expected. It includes some special support for the (new version of the) ETOS compiler, allowing faster threading and pattern matching. There will be a new release of ETOS shortly after the release of Gambit-C. The ETOS web page is now back online: http://www.iro.umontreal.ca/~etos Marc From Chandrashekhar.Mullaparthi@REDACTED Tue Feb 20 18:13:47 2001 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Tue, 20 Feb 2001 17:13:47 -0000 Subject: Doubt about funs Message-ID: <402DD461F109D411977E0008C791C31203919983@imp02mbx.one2one.co.uk> The correct function is selected by the number of arguments to the Fun. cheers, Chandru > -----Original Message----- > From: Paulo Ferreira [mailto:paf@REDACTED] > Sent: 20 February 2001 16:26 > To: erlang-questions@REDACTED > Subject: Doubt about funs > > > Well, here is my doubt: > > Taken fom the Erlang Extensions doc: > > "We can also refer a function defined in a different module with > the following syntax: > > F = {Module,FunctionName} " > > > In this case, how does Erlang gets the correct function, if > in the module are several functions, with the same name > but with different arity ? > > > I know it gets the correct function, at least in the same module, > because I tested it. > > > Thanks > > Paulo Ferreira > > > ------------------------------------------------ > Paulo Ferreira paf@REDACTED > > NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From cesarini@REDACTED Tue Feb 20 18:35:50 2001 From: cesarini@REDACTED (Francesco Cesarini) Date: Tue, 20 Feb 2001 17:35:50 +0000 Subject: Doubt about funs References: Message-ID: <3A92AAF6.B8BAB896@terminus.ericsson.se> In Funs of the type {Mod, Fun}, arity must not be known at compile time (As the function is exported in another module), and can thus be derived during run time when the fun is called. (As other people have mentioned, through the arity in the call, e.g. Fun(A,B)). Calling a non existing exported function would then result in a run time error. Funs of the type fun function/2 however need the arity specified as they are local calls. Checks for the existence of local function are done at compile time, there of, the arity must be stated. Regards, Francesco Paulo Ferreira wrote: > > Well, here is my doubt: > > Taken fom the Erlang Extensions doc: > > "We can also refer a function defined in a different module with > the following syntax: > > F = {Module,FunctionName} " > > In this case, how does Erlang gets the correct function, if > in the module are several functions, with the same name > but with different arity ? > > I know it gets the correct function, at least in the same module, > because I tested it. > > Thanks > > Paulo Ferreira > > ------------------------------------------------ > Paulo Ferreira paf@REDACTED -- Francesco Cesarini Erlang/OTP consultant Cellular: INT+44-7776 250381 ECN: 832-707192 http://welcome.to/cesarini.consulting From richardc@REDACTED Tue Feb 20 18:48:47 2001 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 20 Feb 2001 18:48:47 +0100 (MET) Subject: Doubt about funs In-Reply-To: <402DD461F109D411977E0008C791C31203919983@imp02mbx.one2one.co.uk> Message-ID: > "We can also refer a function defined in a different module with > the following syntax: > > F = {Module,FunctionName} " Yes, it is true that you can (still) use tuples {Module, FunctionName} in this manner, but it is a relic of early Erlang implementations and I strongly recommend that they are not used in new code. If you need to pass around a functional value to call a particular function in a particular module, the following is much better: F = fun (X1, ..., Xn) -> m:f(X1, ..., Xn) end Why? 1), it is apparent that `m' is the target of a call (so e.g. tools like `xref' can know about it, and you can easily grep for `m:' in your source code. In general, avoid passing around module names as data. (For the same reason, it is better to use spawn/1 and spawn/2 than the old spawn/3 and spawn/4, if possible. Avoid `apply/3'.) 2) The `fun ... end' value is a _real_ functional value, and has a well-defined arity. 3) It is more efficient: a static remote-call `m:f(...)' is a relatively fast jump in modern (post-JAM) Erlang implementations, and applications of fun-expressions are also quite efficient nowadays, while the {M, F} call is basically executed by calling `erlang:apply(M, F, ArgList)' which is much slower. /Richard Carlsson Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From kent@REDACTED Tue Feb 20 19:22:27 2001 From: kent@REDACTED (Kent Boortz) Date: 20 Feb 2001 19:22:27 +0100 Subject: erlang patches after R7B-1? In-Reply-To: Jimmy Olgeni's message of "Tue, 20 Feb 2001 14:41:36 +0100 (CET)" References: Message-ID: > I was poking around the erlang site and noticed that the bug fixes > page (http://www.erlang.org/faq/bugs_and_fixes.html) is still at R6B. > > Are there any post-R7B-1 patches? No. "http://www.erlang.org/download/otp_src_R7B-0to1.patch.gz" is the only patch for R7B. We will soon create R7B-2 and a new large patch "http://www.erlang.org/download/otp_src_R7B-1to2.patch.gz". kent From paf@REDACTED Tue Feb 20 19:32:38 2001 From: paf@REDACTED (Paulo Ferreira) Date: Tue, 20 Feb 2001 18:32:38 +0000 Subject: Doubt about funs In-Reply-To: References: <402DD461F109D411977E0008C791C31203919983@imp02mbx.one2one.co.uk> Message-ID: >Yes, it is true that you can (still) use tuples {Module, FunctionName} in >this manner, but it is a relic of early Erlang implementations and I >strongly recommend that they are not used in new code. If you need to pass >around a functional value to call a particular function in a particular >module, the following is much better: > > F = fun (X1, ..., Xn) -> m:f(X1, ..., Xn) end > >Why? > >1), it is apparent that `m' is the target of a call (so e.g. tools like >`xref' can know about it, and you can easily grep for `m:' in your source >code. In general, avoid passing around module names as data. (For the same >reason, it is better to use spawn/1 and spawn/2 than the old spawn/3 and >spawn/4, if possible. Avoid `apply/3'.) > >2) The `fun ... end' value is a _real_ functional value, and has a >well-defined arity. > >3) It is more efficient: a static remote-call `m:f(...)' is a relatively >fast jump in modern (post-JAM) Erlang implementations, and applications of >fun-expressions are also quite efficient nowadays, while the {M, F} call >is basically executed by calling `erlang:apply(M, F, ArgList)' which is >much slower. > > > /Richard Carlsson > > >Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) >E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ Thanks to all that replied, but this last answer should be on the FAQ, or at least on the documentation. So, here is another advantage of erlang: One doubt and in two hours time I have five correct answers !!! Greetings from Porto,Portugal Paulo Ferreira ------------------------------------------------ Paulo Ferreira paf@REDACTED From jamesh@REDACTED Tue Feb 20 21:55:00 2001 From: jamesh@REDACTED (James Hague) Date: Tue, 20 Feb 2001 14:55:00 -0600 Subject: Hardware support for overflow detection in BEAM? Message-ID: As best I can tell from the BEAM sources (there *is* a lot of code :) overflow for fixnums and the like is detected manually before, in the case of addition, adding the numbers together. Has anyone tried modifying this to just do the math, then check the overflow bit after the fact? Seems like this would be a win on the x86, though I can't say for sure about processors. James From cpressey@REDACTED Tue Feb 20 22:04:15 2001 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 20 Feb 2001 15:04:15 -0600 Subject: Various (and almost completely unrelated) questions and opinions References: <3A8789B2.2C7AF20E@catseye.mb.ca> <20010219145329.A22578@dnai.com> <3A91BA5F.952C681@catseye.mb.ca> Message-ID: <3A92DBCF.6D74FEE4@catseye.mb.ca> David Gould wrote: > On Mon, Feb 19, 2001 at 06:29:19PM -0600, Chris Pressey wrote: > > David Gould wrote: > > > On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote: > > > > [...] Partly what I'd like to see is a sort > > > > of "Dangerous Erlang" which trades off some of the safety and > > > > predictability for flexibility and expressivity. [...] > > > Hmmm, I am thinking, "typeless Haskell" ;-) > > Well, not entirely typeless - for that I think you have to go back to > > the lambda calculus itself or "alternative" languages like Unlambda, > > where there is only one "type", the function. [...] > Well, it was sort of a joke. It is just that since there is a constant > flamewar on comp.lang.functional about the necessity (or is it morality) > of strict typing, I decided to learn a little about haskell too. Ah, understood. Advocacy is a strange and terrible thing. Sure, static analysis is a good thing that saves time and energy. On the other hand, it's not impossible to write a program without it, and there are always other factors to consider. Erlang's philosophy of being fault *tolerant* doesn't strictly need static analysis. But it's always nice to have it on the side. All in all, I like ML better as a generic example of a functional programming language. It hasn't got all the fancy stuff Haskell has in it, so (for me) it was easier to understand. (Then again I'd say the same thing with respect to Pascal and C in imperative programming.) > Without insight, it is pretty on the page. Which I find to be a very > good first discriminator for languages. Ugly source text, ugly all the way > down. Canonical example: C++. It's a good rough judgement, but sometimes it lies too. Perl is ugly to look at and mostly (but not entirely) ugly underneath. Python is nice to look at but (as I understand, not being a big Python programmer) not entirely nice underneath. > > I've heard it said that "the number of Haskell programmers worldwide > > could fit in my bathroom" - Erlang's takeup may not be explosively > > large, but I think more people are actually *using* it for something, > > than Haskell. > Well yes. I do know of a few people doing things with ocaml though, so > it might be as widely used. But from the little I have looked at it, it > seems to not quite pass the ugly test. All the let in and in and in ... O.Caml was one of the original attempts to combine object-oriented and functional programming, and a pretty naive one in my opinion. A direct combination leads to a lot of redundant functionality, which can make building new code easier ("there's more than one way to do it") but also makes maintaining existing code harder. Just my opinion of course, I know some people who swear by O.Caml. > > IMO Haskell == sophisticated, Perl == expedient, Erlang == one of the > > best blends of sophistication & expediency since... well, since C! > Very good, I like the observation about the blend as applied to C. I used > (back in the early 80s) to love C, but it gets worse as time goes by and > really is not a good choice for most of the things people use it for. Me too. C is a "systems-construction" language, and as I was doing more stuff further and further away from "constructing a system", I started using Perl; mainly for the garbage collection and regexps. But my day job involves extremely expedient languages like Perl and Business BASIC and various scripting languages for various specialty software packages where control is utmost and abstraction is, well, nearly absent; so it's little wonder I'll cherish any beauty (like single-assignment) that shows up in an otherwise expedient language. > I agree, the blend of beauty and ruthless pragmatism in Erlang is rarely > found. Erlang, one of the few (only?) functional languages genuinely suited to a production environment? > And you can even use the curly braces for something (the essential criteria > for language success as far as I can tell from the recent historical > evidence ;-)). Absolutely :-) Lon Willett wrote: > Chris Pressey writes: > [snip] > > Also I like Erlang's eager evaluation much better than Haskell's lazy > > evaluation. It is easy enough to build a lazy evaluator in Erlang if > > you need one. > [snip] > I prefer the eager ("strict") evaluation too, as a default. But there > are some nice things that can be done with lazy evaluation: streams as > lists, some clever data structures, etc. Well, clever is clever. I dunno - I'd rather leave being clever, up to the programmer, I guess. > And it is not so trivial to > write a lazy evaluator; any reasonable implementation would require > changes to the VM. It all depends on what you want to evaluate. If you wanted to lazily evaluate arbitrary Erlang code (complete with send and receive?) then yes, you'd have to make some major changes. But I was thinking merely numerical expressions, like a "symbolic calculator", which would be far easier; in fact I think there's some example code for one in the extensions doc. In fact, if you consider erl_eval et al as part of the language, then there is your means of delayed (if not formally "lazy") evaluation right there. It all depends what you need out of lazy evaluation, and yes, while it makes possible some clever tricks, are there very many problems that really call for full lazy evaluation? It seems to me more real-world, production-environment problems actually call for eager evaluation - make sure everything is resolved as soon as possible. So I see Erlang's design decision as a fairly wise one. One of the main drives towards lazy evaluation (it seems to me) is the desire for if(e,t,f) to be just like any other function, yet for it to be short-circuiting, so that f isn't evaluated unless e is false. It strikes me that lambda functions for t and f could serve this purpose - but Erlang isn't even in a position where 'if' is supposed to be a function, so I can't see there being a lot of call for it here. > I briefly (as in for a few moments; then reality set in and I moved on > to more pressing matters) considered modifying the beam type system to > support "promises", or whatever one wants to call the delayed- > evaluation objects. I think in Erlang they should be called "funs" :-) _chris -- "Ten short days ago all I could look forward to was a dead-end job as a engineer. Now I have a promising future and make really big Zorkmids." Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/ Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html From mbj@REDACTED Tue Feb 20 22:49:23 2001 From: mbj@REDACTED (Martin Bjorklund) Date: Tue, 20 Feb 2001 22:49:23 +0100 Subject: Doubt about funs In-Reply-To: Your message of "Tue, 20 Feb 2001 18:48:47 +0100 (MET)" References: Message-ID: <20010220224923S.mbj@bluetail.com> Richard Carlsson wrote: > > > "We can also refer a function defined in a different module with > > the following syntax: > > > > F = {Module,FunctionName} " > > Yes, it is true that you can (still) use tuples {Module, FunctionName} in > this manner, but it is a relic of early Erlang implementations and I > strongly recommend that they are not used in new code. > If you need to pass > around a functional value to call a particular function in a particular > module, the following is much better: > > F = fun (X1, ..., Xn) -> m:f(X1, ..., Xn) end I strongly disagree. These two constructs behave very different! Using F in the former construct is an external apply, which means that the latest version of the code gets called. Using F in the latter, on the other hand, is a call to the function defined in the version of the module that was there when F was constructed. Thus, if a new version of the module (where the fun was defined) is loaded, and you try to use F, you'll using the old version. If yet another version of the module is loaded, F is invalid, and the process is killed. Thus, my recommendation, which is documented somewhere deep in the OTP docs, is to use funs for shortlived local tasks, and {M,F} whenever the function is kept for a longer time (e.g. as part of server's state). Using {M,F} guarantees that the function can be upgraded without killing all users of the fun. > 1), it is apparent that `m' is the target of a call (so e.g. tools like > `xref' can know about it, and you can easily grep for `m:' in your source > code. In general, avoid passing around module names as data. (For the same > reason, it is better to use spawn/1 and spawn/2 than the old spawn/3 and > spawn/4, if possible. Avoid `apply/3'.) No! Using spawn/1 or spawn/2 is even worse if you want to support code upgrade. This means that the process will have a reference to the fun on it's stack, which it never will get rid of. Thus, loading two more versions of the module kills the process. I don't understand why these functions were added in the first place. I don't think they add anything. > 2) The `fun ... end' value is a _real_ functional value, and has a > well-defined arity. > > 3) It is more efficient: a static remote-call `m:f(...)' is a relatively > fast jump in modern (post-JAM) Erlang implementations, and applications of > fun-expressions are also quite efficient nowadays, while the {M, F} call > is basically executed by calling `erlang:apply(M, F, ArgList)' which is > much slower. I agree. Use funs with care. /martin From happi@REDACTED Wed Feb 21 00:46:23 2001 From: happi@REDACTED (Erik Johansson) Date: Wed, 21 Feb 2001 00:46:23 +0100 Subject: Doubt about funs References: <20010220224923S.mbj@bluetail.com> Message-ID: <00c401c09b97$559b9340$c90b0a0a@student.uu.se> "Martin Bjorklund" wrote [...] > > F = fun (X1, ..., Xn) -> m:f(X1, ..., Xn) end > > I strongly disagree. These two constructs behave very different! > Using F in the former construct is an external apply, which means that > the latest version of the code gets called. Using F in the latter, on > the other hand, is a call to the function defined in the version of > the module that was there when F was constructed. Thus, if a new > version of the module (where the fun was defined) is loaded, and you > try to use F, you'll using the old version. If yet another version of > the module is loaded, F is invalid, and the process is killed. You have a point there, but your statement is not completely true. What you describe will happen in the current implementation if the function defining F is changed (or any funs are added or removed before the fun defining F). But if you do the code change carefully you can actually change code in the module defining F and F will upgrade to new code. The point is really that you should not hold on to funs over code change. But there is no reason to do so either. If the code defining the fun is changed then the code that applies the fun should get a new fun. You could run in to similar problems with F = {m,f} if you change the module m so that f does not exist, or the arity of f changes, or the implementation of f changes, then applying F is not a good idea. It might even be an argument for using a fun instead of a tuple in the current implementation: * If a process is holding on to a fun and the implementation of the fun is changed twice then that process is killed, and the supervisor can start up the process again in a correct way. * If a process is holding on to a mod-fun-tuple then the run-time system can't detect this and the process will keep on living and applying {m, f} even if the intention of the new code would be to apply {m, g}. (The semantics of funs and code-change is an interesting topic and any input is welcome. ;) [...] > > (For the same reason, it is better to use spawn/1 and spawn/2 than the old spawn/3 and > > spawn/4, if possible. Avoid `apply/3'.) > > No! Using spawn/1 or spawn/2 is even worse if you want to support > code upgrade. This means that the process will have a reference to > the fun on it's stack, which it never will get rid of. Thus, loading > two more versions of the module kills the process. No! That is not true. (Unless the fun is not tail-recursive, but that is not specific for funs. If you want to support code upgrade you will use tail-recursive functions as much as possible anyway.) spawn( fun () -> m:f(X1, ..., Xn) end) has the same effect as spawn(m, f, [X1, ..., Xn]) With the added benefit that you in the module m can write spawn( fun () -> f(X1, ..., Xn) end) without exporting f/n. [...] > Use funs with care. Yes that is certainly true. But as Richard wrote there are several advantages of using funs over a tuple, and I can see no real advantage of using the tuple approach. Correct behaviour for code change can just as easily be achieved with funs as with "apply tuple"; you just need to think about it in a new way. I hope you can see my point through my muddy presentation; it has been a long day. /Erik From jim@REDACTED Wed Feb 21 03:13:56 2001 From: jim@REDACTED (Jim Larson) Date: Tue, 20 Feb 2001 18:13:56 -0800 Subject: Doubt about funs In-Reply-To: Your message of "Tue, 20 Feb 2001 18:48:47 +0100." Message-ID: <200102210213.SAA27009@functor.Sendmail.COM> In message you write: > >> "We can also refer a function defined in a different module with >> the following syntax: >> >> F = {Module,FunctionName} " > >Yes, it is true that you can (still) use tuples {Module, FunctionName} in >this manner, but it is a relic of early Erlang implementations and I >strongly recommend that they are not used in new code. If you need to pass >around a functional value to call a particular function in a particular >module, the following is much better: > > F = fun (X1, ..., Xn) -> m:f(X1, ..., Xn) end > >Why? > >1), it is apparent that `m' is the target of a call (so e.g. tools like >`xref' can know about it, and you can easily grep for `m:' in your source >code. In general, avoid passing around module names as data. (For the same >reason, it is better to use spawn/1 and spawn/2 than the old spawn/3 and >spawn/4, if possible. Avoid `apply/3'.) Do you also advise against the use of callback interfaces? If so, how to you implement the desired dynamic dispatch? Pass funs to an initialization function? Jim From davidg@REDACTED Wed Feb 21 08:31:53 2001 From: davidg@REDACTED (David Gould) Date: Tue, 20 Feb 2001 23:31:53 -0800 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: <3A91BA5F.952C681@catseye.mb.ca>; from Chris Pressey on Mon, Feb 19, 2001 at 06:29:19PM -0600 References: <3A8789B2.2C7AF20E@catseye.mb.ca> <20010219145329.A22578@dnai.com> <3A91BA5F.952C681@catseye.mb.ca> Message-ID: <20010220233153.B5446@dnai.com> On Mon, Feb 19, 2001 at 06:29:19PM -0600, Chris Pressey wrote: ... > I've had some thoughts about overloading operators, btw. I think it's Have you looked at Oberon? I am somewhat persuaded by the Oberon rationale against overloaded operators. Oberon is roughly my idea of what a C level language with objects should have been. They claim extreme simplicity is a good thing. To back it up, the Oberon language specification is coherent and complete in something like 28 pages. See other simple languages, eg R5RS for contrast. Anyway, the Oberon argument is that code should be understandable by reading it. That is, what is being done and the cost of doing it should be apparent by looking at it. The problem with overloading is that "A + B" could mean anything, eg "blend these two 80MB images", and it is not obvious from the immediate source what the heck is going on or what it might cost. Not without finding the declarations of A and B and '+' and understanding how overloading selects implementations, all of which in the worst case (c++ again!) are stored in separate files in separate directory hierarchies. At least for the Oberon system designers, this appears to work, they have produced some pretty fantastic stuff that runs on ridiculously low resources. One of the things I like about Erlang is that it too has an emphasis on "textual transparancy" and simplicity. Except possibly in how I/O is really done... > only of limited use unless you can have user-defined functions in > guards. This is assuming that the semantics of any overloaded operator > are expressed by a user-defined function, and that relational operators > can be overloaded. I like the rationale for the restrictions on guards, that they are restricted to known time or constant time operations without side effects. It means a less flexibility, but if guards could be arbitrarily expensive, then people would start contorting code in other ways to avoid using guards or something. A net loss I think. -dg -- David Gould davidg@REDACTED 510 536 1443 If simplicity worked, the world would be overrun with insects. From mbj@REDACTED Wed Feb 21 09:52:58 2001 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 21 Feb 2001 09:52:58 +0100 Subject: Doubt about funs In-Reply-To: Your message of "Wed, 21 Feb 2001 00:46:23 +0100" <00c401c09b97$559b9340$c90b0a0a@student.uu.se> References: <00c401c09b97$559b9340$c90b0a0a@student.uu.se> Message-ID: <20010221095258C.mbj@bluetail.com> "Erik Johansson" wrote: > The point is really that you should not hold on to funs over code > change. That's what I tried to say. I objected to Richard's statement that a fun() is always prefered over {M,F} tuples. > But there is no reason to do so either. If the code defining the fun is > changed then the code that applies the fun should get a new fun. How do you propose this should be done in practise? You'd have to make sure that all processes (ets tables, files, ...) which holds a function gets notified when the new code is loaded. This is simply not feasible. > You could run in to similar problems with F = {m,f} if you change the module > m so that f does not exist, or the arity of f changes, or the implementation > of f changes, then applying F is not a good idea. Of course, but in that case the programmer made the choice to change or remove the function. With a fun, this happens whether the programmer wants it or not. > It might even be an argument for using a fun instead of a tuple in the > current implementation: > * If a process is holding on to a fun and the implementation of the fun is > changed twice then that process is killed, and the supervisor can start up > the process again in a correct way. Surely you can't be serious. Code change by crashing might be an interesting area of research ;-) > * If a process is holding on to a mod-fun-tuple then the run-time system > can't detect this and the process will keep on living and applying {m, f} > even if the intention of the new code would be to apply {m, g}. Again, this is under the control of the prgrammer with {M,F}. > > > (For the same reason, it is better to use spawn/1 and spawn/2 than the > old spawn/3 and > > > spawn/4, if possible. Avoid `apply/3'.) > > > > No! Using spawn/1 or spawn/2 is even worse if you want to support > > code upgrade. This means that the process will have a reference to > > the fun on it's stack, which it never will get rid of. Thus, loading > > two more versions of the module kills the process. > > No! That is not true. > (Unless the fun is not tail-recursive, but that is not specific for funs. > If you want to support code upgrade you will use tail-recursive functions > as much as possible anyway.) > > spawn( fun () -> m:f(X1, ..., Xn) end) ^^ you probably mean fun() -> f(...), otherwise you'd have to export f anyway! > has the same effect as > spawn(m, f, [X1, ..., Xn]) What you describe is not how it works today: ==================================== -module(t). -export([t/0]). t() -> spawn(fun() -> loop() end). loop() -> receive ok -> loop() end. ==================================== 1> c(t). {ok,t} 2> P = t:t(). <0.32.0> 3> process_info(P, current_function). {current_function,{t,loop,0}} 4> l(t). {module,t} 5> process_info(P, current_function). {current_function,{t,loop,0}} 6> l(t). {module,t} 7> process_info(P, current_function). undefined > > Use funs with care. > > Yes that is certainly true. > But as Richard wrote there are several advantages of using funs over a > tuple, and I can see no real advantage of using the tuple approach. > Correct behaviour for code change can just as easily be achieved with funs > as with "apply tuple"; you just need to think about it in a new way. I still disagree. A scheme in which code change is achieved by uncontrolled crashes is not really what we're looking for. If you can find a way to change code of funs in a real, distributed system, please let us know!! Just to make my point clear, I do like funs, and I use them all the time, but only for short-lived tasks like in a local lists:foreach etc. In code that e.g. registers callbacks to be invoked at a later time, I use the tuple syntax. /martin From richardc@REDACTED Wed Feb 21 09:58:13 2001 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 21 Feb 2001 09:58:13 +0100 (MET) Subject: Doubt about funs In-Reply-To: <200102210213.SAA27009@functor.Sendmail.COM> Message-ID: On Tue, 20 Feb 2001, Jim Larson wrote: > >1), it is apparent that `m' is the target of a call (so e.g. tools like > >`xref' can know about it, and you can easily grep for `m:' in your source > >code. In general, avoid passing around module names as data. (For the same > >reason, it is better to use spawn/1 and spawn/2 than the old spawn/3 and > >spawn/4, if possible. Avoid `apply/3'.) > > Do you also advise against the use of callback interfaces? If so, > how to you implement the desired dynamic dispatch? Pass funs to an > initialization function? No, sometimes a dynamic lookup is definitely what you want, but this can be more neatly expressed with the normal remote-call syntax: f(Mod) -> receive Pattern1 -> Mod:f(...); Pattern2 -> Mod:g(...); Pattern3 -> Mod:h(...); ... end Calling `apply/3' is not necessary unless you are writing something like an interpreter, where even the number of arguments in each call could vary. (Using Mod:f(...), where Mod is not a constant atom, makes it impossible for xref to know about the call, but at least you can grep for ":f(".) My main point was just against the use of pseudo-functional values `{M, F}' which do not have the same semantics as real functional values (with respect to arity and dynamic lookup), not against dynamic lookup in general. /Richard Carlsson Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From jakob@REDACTED Wed Feb 21 10:33:03 2001 From: jakob@REDACTED (Jakob Cederlund =?iso-8859-1?Q?på?= UAB) Date: Wed, 21 Feb 2001 10:33:03 +0100 Subject: Erlang as .so In-Reply-To: Message-ID: <5.0.2.1.0.20010221102649.00bc3450@mail> At 09:52 2001-02-20 +0100, you wrote: >Hi all! > >I wonder if it's possible to use the Erlang VM as a shared library, to be >included in another program. This for example would allow a nicer >graphical interface. > >Can it be done? If yes, is it documented? It would be nice if it was a >fully encapsulated library (? la SAE), but for now I'd settle for just >sharing 'erl' > >My priority list is to first try it on Windows, and then check Linux. > >cheers, Vlad >_________________________________________________________________________ >Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Well, on Windows you're in luck, because it's that way since R7; the emulator is contained in a dll, beam.dll, which is linked to erl.exe and werl.exe. It is feasible, but not easy, to link it to your own program. Check the source for werl.exe. Speaking of a better interface, I've been thinking of that for a long time. Werl is not much better than the command-line interface, and not all of us think that shell mode in emacs is the ultimate IDE. When I've finished some stuff I will look into it. /Jakob From kent@REDACTED Wed Feb 21 10:42:52 2001 From: kent@REDACTED (Kent Boortz) Date: 21 Feb 2001 10:42:52 +0100 Subject: Hardware support for overflow detection in BEAM? In-Reply-To: James Hague's message of "Tue, 20 Feb 2001 14:55:00 -0600" References: Message-ID: > As best I can tell from the BEAM sources (there *is* a lot of code :) > overflow for fixnums and the like is detected manually before, in the case > of addition, adding the numbers together. Has anyone tried modifying this > to just do the math, then check the overflow bit after the fact? Seems like > this would be a win on the x86, though I can't say for sure about > processors. We are looking into this at the moment, i.e. we investigate if we can put back the use of hardware support for arithmetic overflows. I removed it a couple of years ago simply because the hardware support for arithmetic overflows in Erlang didn't work correctly. At the time I blamed the operating system implementations to be incomplete/broken. On some machines the overflow test cases hang the whole machine, on others some overflows where caught and others not. I felt that the extra speed was not worth the danger of crashing an Erlang node. kent From siri.hansen@REDACTED Wed Feb 21 10:49:42 2001 From: siri.hansen@REDACTED (Siri Hansen) Date: Wed, 21 Feb 2001 09:49:42 +0000 Subject: Doubt about funs References: Message-ID: <3A938F36.493D920A@eei.ericsson.se> > Taken fom the Erlang Extensions doc: > > "We can also refer a function defined in a different module with > the following syntax: > > F = {Module,FunctionName} " > The documentation also says that you can use the test function/1 in a guard to check if a term is a fun. This test fails for the {Module,FunctionName} expression. Why? /siri From etxuwig@REDACTED Wed Feb 21 10:51:21 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 21 Feb 2001 10:51:21 +0100 (MET) Subject: Doubt about funs In-Reply-To: <20010221095258C.mbj@bluetail.com> Message-ID: I basically agree with Martin, but... On Wed, 21 Feb 2001, Martin Bjorklund wrote: >"Erik Johansson" wrote: >> has the same effect as >> spawn(m, f, [X1, ..., Xn]) > >What you describe is not how it works today: > >==================================== >-module(t). >-export([t/0]). > > >t() -> > spawn(fun() -> loop() end). > >loop() -> > receive > ok -> > loop() > end. >==================================== >1> c(t). >{ok,t} >2> P = t:t(). ><0.32.0> >3> process_info(P, current_function). >{current_function,{t,loop,0}} >4> l(t). >{module,t} >5> process_info(P, current_function). >{current_function,{t,loop,0}} >6> l(t). >{module,t} >7> process_info(P, current_function). >undefined Erm, what did you intent to demonstrate here? P crashes, but that doesn't really have anything to do with the fun. It's because t:loop() executes in the old module. If you change loop() like this: loop() -> receive ok -> t:loop() after 1000 -> t:loop() end. then P won't crash. Indeed, if you make a stack trace on P, you will see that there is no reference to the fun on the stack (if I read the stack trace correctly): 39> erlang:process_display(P, backtrace). program counter = 0x19a8f4 (t:loop/0 + 4) cp = 0xed830 () arity = 0 true The main gripe about long-lived funs is exactly that they sometimes surprise you during code change. Upgrades are hard enough as it is. This could perhaps be remedied -- it's certainly improved a lot already, compared to you only needed to recompile to break all references to a fun. /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 Feb 21 10:56:29 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 21 Feb 2001 10:56:29 +0100 (MET) Subject: Doubt about funs In-Reply-To: <3A938F36.493D920A@eei.ericsson.se> Message-ID: On Wed, 21 Feb 2001, Siri Hansen wrote: >> Taken fom the Erlang Extensions doc: >> >> "We can also refer a function defined in a different module with >> the following syntax: >> >> F = {Module,FunctionName} " >> > >The documentation also says that you can use the test function/1 in a >guard to check if a term is a fun. This test fails for the >{Module,FunctionName} expression. > >Why? Because Erlang has no way of telling if {M, F} is any ordinary tuple of two atoms, or a reference to a specific function. Erlang can, on the other hand tell the difference between a fun() and a tuple. In older implementations of funs, it couldn't do that, and you could create a 5-tuple that could pass for a fun(), until you tried calling it. /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 Feb 21 10:58:29 2001 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 21 Feb 2001 10:58:29 +0100 Subject: Doubt about funs In-Reply-To: Your message of "Wed, 21 Feb 2001 10:51:21 +0100 (MET)" References: Message-ID: <20010221105829Q.mbj@bluetail.com> Ulf Wiger wrote: > P crashes, but that doesn't really have anything to do with the > fun. It's because t:loop() executes in the old module. Yes, of course, you're right. Ok, so I agree you can use a fun to spawn a new function, if you don't want to export that function. I guess it's a matter of taste (and tradition). But the main point about code change is still valid though. /martin From etxuwig@REDACTED Wed Feb 21 11:37:05 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 21 Feb 2001 11:37:05 +0100 (MET) Subject: Doubt about funs In-Reply-To: <20010221095258C.mbj@bluetail.com> Message-ID: On Wed, 21 Feb 2001, Martin Bjorklund wrote: >"Erik Johansson" wrote: > >> But there is no reason to do so either. If the code defining the fun is >> changed then the code that applies the fun should get a new fun. > >How do you propose this should be done in practise? You'd have to >make sure that all processes (ets tables, files, ...) which holds a >function gets notified when the new code is loaded. This is simply >not feasible. Since funs are actually made into real functions by the compiler, they seem to have roughly the same properties as ordinary functions during code change. I've run some tests, and it does seem to be the case that as long as the fun is tail recursive (doesn't wait for a return value), then upgrading doesn't break the fun as long as the arity stays the same. This is the same as for ordinary functions. It then becomes an issue of interface management. In general, changing interfaces in an incompatible manner during system upgrade is asking for trouble -- especially if it's a callback function which is relatively frequently used. It doesn't really matter if it's a fun or a variable like Module or {Module, Function}; you still have to suspend all processes referencing the function and upgrade all of them at the same time. I will admit that my fear of funs in this context is based on previous experiences. Most of the past problems appear to have been fixed. Still, I would like to see a uniform method of specifying what _is_ actually part of an interface, in a way that you can easily spot what has changed. It would be nice if this method allowed for automated analysis. We (AXD 301) try to collect interface functions in a separate interface module. This doesn't cover exported records and funs, however. Regarding records, the .hrl file must be published in a special library subdirectory, and users of the .hrl are not allowed to include it directly from the application's inc/ directory. Thus, we can see what compile-time dependencies are exported from an application. This is non-OTP-standard, though (there doesn't seem to be an OTP standard that addresses the issue.) /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 Feb 21 11:44:32 2001 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 21 Feb 2001 11:44:32 +0100 Subject: Doubt about funs In-Reply-To: Your message of "Wed, 21 Feb 2001 11:37:05 +0100 (MET)" References: Message-ID: <20010221114432B.mbj@bluetail.com> Ulf Wiger wrote: > Since funs are actually made into real functions by the compiler, they > seem to have roughly the same properties as ordinary functions during > code change. I've run some tests, and it does seem to be the case that > as long as the fun is tail recursive (doesn't wait for a return > value), then upgrading doesn't break the fun as long as the arity > stays the same. This is the same as for ordinary functions. erik> What you describe will happen in the current implementation if erik> the function defining F is changed (or any funs are added or erik> removed before the fun defining F). So, it's still a problem. If this problem was solved, so that it worked as you described above, I'd be the first to start using funs for everything! /martin From etxuwig@REDACTED Wed Feb 21 11:54:45 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 21 Feb 2001 11:54:45 +0100 (MET) Subject: Doubt about funs In-Reply-To: <20010221114432B.mbj@bluetail.com> Message-ID: On Wed, 21 Feb 2001, Martin Bjorklund wrote: >Ulf Wiger wrote: > >> Since funs are actually made into real functions by the compiler, they >> seem to have roughly the same properties as ordinary functions during >> code change. I've run some tests, and it does seem to be the case that >> as long as the fun is tail recursive (doesn't wait for a return >> value), then upgrading doesn't break the fun as long as the arity >> stays the same. This is the same as for ordinary functions. > >erik> What you describe will happen in the current implementation if >erik> the function defining F is changed (or any funs are added or >erik> removed before the fun defining F). Yes, you're right. Adding a fun before a fun referenced by some process P, will cause P to crash when the old module is purged. Oops. /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 Erik.Johansson@REDACTED Wed Feb 21 11:57:36 2001 From: Erik.Johansson@REDACTED (Erik.Johansson) Date: Wed, 21 Feb 2001 11:57:36 +0100 Subject: Doubt about funs References: <00c401c09b97$559b9340$c90b0a0a@student.uu.se> <20010221095258C.mbj@bluetail.com> Message-ID: <028701c09bf5$1a4b5010$980cee82@it.uu.se> Paulo Ferreira wrote: > So, here is another advantage of erlang: One doubt and in two hours time > I have five correct answers !!! And then the obligatory debate starts ;) Ulf Wiger wrote: (cited out of context) > I will admit that my fear of funs in this context is based on > previous experiences. Most of the past problems appear to have been > fixed. >It then becomes an issue of interface management. Yes, this is my point; you can use a fun just as well as {M, F} but you would have to design things a bit differently from the beginning. My real concern is what the semantics for funs during code change should be. In the current system processes holding on to funs that changes twice get killed. Some say this is good because then you can be sure that old code is phased out. I would like to try a different behavior where existing funs holds on to the code as long as needed in stead. This could lead to an ever increasing amount of code if one is not careful, but isn't that better than having processes crash if you are not careful? Martin Bj?rklund wrote: > erik> What you describe will happen in the current implementation if > erik> the function defining F is changed (or any funs are added or > erik> removed before the fun defining F). > > So, it's still a problem. If this problem was solved, so that it > worked as you described above, I'd be the first to start using funs > for everything! Yes it is still a problem, but if you know about it and are careful with how you use funs, you can use them for everything. And please lobby for a nice semantic for funs and code change. To summarize my view: 1. For short lived tasks: always use a fun. 2. For spawing use a tail-recursive fun. 3. For long-lived (call-backs) either make a careful design or stick to {M., F} if you feel that it is easier. /Erik From etxuwig@REDACTED Wed Feb 21 12:16:48 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 21 Feb 2001 12:16:48 +0100 (MET) Subject: XML update Message-ID: StarOffice goes XML: -------------------- First of all, Sun's StarOffice has gone Open Source: http://www.sun.com/developers/openoffice/ Unfortunately, Sun has taken out important functionality when doing so, so OpenOffice is not (yet) a viable office environment. Too bad. Second, OpenOffice is planning to use XML as its primary document format, and make the format completely open: http://www.xml.com/pub/a/2001/02/07/openoffice.html?page=1 XMErl ----- I want to thank those who've helped me find bugs and made suggestions on how to fix/improve XMErl. I haven't spent time on it myself in a long while, but it seems to be improving anyway. Special thanks to Mickael Remond, who is working on the XPATH side, and to Johan Blom, who is experimenting with a verifier hook to XMErl; to Bijan Parsia for writing an entertaining article and pitching my work to those who know XML much, much better than I. (: Mattias L?ng sent some encouragement my way by devising a test in which xmerl beat the Java-based openxml.org parser by some 20% on performance. I don't know if it holds in general, but hey! In return, I'll pitch your product (http://www.corelatus.se/), which has an XML-based API. ;-) I will make an effort to include the changes you've sent me. All suggestions are much welcome. Open Source is a great way to work! My knowledge of XML is still very limited, but with your help, it seems like we can put together a pretty decent tool anyway. /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 Feb 21 12:52:38 2001 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 21 Feb 2001 12:52:38 +0100 Subject: Doubt about funs In-Reply-To: Your message of "Wed, 21 Feb 2001 11:57:36 +0100" <028701c09bf5$1a4b5010$980cee82@it.uu.se> References: <028701c09bf5$1a4b5010$980cee82@it.uu.se> Message-ID: <20010221125238B.mbj@bluetail.com> "Erik.Johansson" wrote: > My real concern is what the semantics for funs during code change > should be. In the current system processes holding on to funs that > changes twice get killed. Some say this is good because then you can > be sure that old code is phased out. I think that is good. > I would like to try a different behavior where existing funs holds > on to the code as long as needed in stead. This could lead to an > ever increasing amount of code if one is not careful, but isn't that > better than having processes crash if you are not careful? One problem with this is that you would have to come up with a way to explicitly tell all users of the fun that it's time to refresh. This is something you need, since the code might be updated because of bug fixes or new features, and you definately want to change all occurences of the old fun in the system. External calls takes care of that today. > And please lobby for a nice semantic for funs and code change. I agree, it's an important area. > To summarize my view: > 1. For short lived tasks: always use a fun. > 2. For spawing use a tail-recursive fun. > 3. For long-lived (call-backs) either make a careful design or > stick to {M., F} if you feel that it is easier. I agree with this as well. The only concern I have with "careful" design is that it might be difficult to do in real code. For example, how can I make sure that the function that defined the fun is not changed in a future version? Well, I could define a function with the only purpose of returning the fun. Then, how would I make sure that no funs are added/removed before this one? I could declare all funs in a section at the end of the module, and always add funs after the ones defined, and never remove stale funs. I'm not sure I like that approach though. /martin From jj@REDACTED Wed Feb 21 13:50:33 2001 From: jj@REDACTED (Joao Jr.) Date: Wed, 21 Feb 2001 09:50:33 -0300 Subject: problem to compiler ".erl" file to ".bean" file. Message-ID: <007b01c09c04$e1c41460$356429a4@dis.unb.br> Hi, I've problem when a try to compiler ".erl" file to ".bean" file. I execute the compiler, it compiler perfectly, but ".bean" file isn't create and it isn't return any error. Then a can't use my functions. What can I do, to solve this problem? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richardc@REDACTED Wed Feb 21 14:09:05 2001 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 21 Feb 2001 14:09:05 +0100 (MET) Subject: Doubt about funs In-Reply-To: <20010221114432B.mbj@bluetail.com> Message-ID: On Wed, 21 Feb 2001, Martin Bjorklund wrote: > Ulf Wiger wrote: > > > Since funs are actually made into real functions by the compiler, they > > seem to have roughly the same properties as ordinary functions during > > code change. I've run some tests, and it does seem to be the case that > > as long as the fun is tail recursive (doesn't wait for a return > > value), then upgrading doesn't break the fun as long as the arity > > stays the same. This is the same as for ordinary functions. > > erik> What you describe will happen in the current implementation if > erik> the function defining F is changed (or any funs are added or > erik> removed before the fun defining F). Never depend on funs "migrating" from old code to new, even if you did not add or remove funs from the code (i.e., even if the internal fun-indexing inside the module stays the same over the code change). The code executed by a fun should be exactly that in the version of the module used to create the fun-value. Coming Erlang implementations will assure this by using a module-checksum to identify the correct code for a fun, or crash the call if that version has been purged. (In the current implementation a fun could only survive at most one code change anyway, so it was not really much of a help. The new scheme is more consistent.) /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From Erik.Johansson@REDACTED Wed Feb 21 14:25:09 2001 From: Erik.Johansson@REDACTED (Erik.Johansson) Date: Wed, 21 Feb 2001 14:25:09 +0100 Subject: Doubt about funs References: <028701c09bf5$1a4b5010$980cee82@it.uu.se> <20010221125238B.mbj@bluetail.com> Message-ID: <031501c09c09$b7065c60$980cee82@it.uu.se> "Martin Bjorklund" wrote: > One problem with this is that you would have to come up with a way to > explicitly tell all users of the fun that it's time to refresh. This > is something you need, since the code might be updated because of bug > fixes or new features, and you definately want to change all > occurences of the old fun in the system. External calls takes care of > that today. Well external calls take care of that to a certain degree today, you might still need to explicitly handle changes to interfaces and to data representation. ... > I agree with this as well. The only concern I have with "careful" > design is that it might be difficult to do in real code. For example, > how can I make sure that the function that defined the fun is not > changed in a future version? What I meant with "careful design" was not to try to write funs that don't change but to design servers so that they explicitly can upgrade to a new fun when the code changes. You say that this is infeasible or difficult in real code but if you are aware of the problem from the outset I don't think it is harder than, for example, the problem of handling changes in the representation of data after code change. (I'm not saying that this is an easy problem. ;) Using a {M., F} instead of a fun don't solve the real problems with code change it just hides some of the deeper problems behind the simplicity of the remote call. /Erik From Lon.Willett@REDACTED Wed Feb 21 14:44:23 2001 From: Lon.Willett@REDACTED (Lon Willett) Date: 21 Feb 2001 13:44:23 +0000 Subject: Doubt about funs In-Reply-To: Richard Carlsson's message of "Tue, 20 Feb 2001 18:48:47 +0100 (MET)" References: Message-ID: So has anyone considered implementing a syntax like "fun Mod:Fun/Arity"? It seems like an obvious thing to do. And even a naive implementation which just replaced the expression with "{M,F}" (losing the arity) would at least provide a nice consistent way to express the intent. A good implementation would produce some dynamic function object that was efficient, contained the arity, and was robust across code change. /Lon -- Lon Willett Security Architect, SSE Ltd. Fitzwilliam Court, Leeson Close Dublin 2, Ireland +353-1-216-2946 +353-87-8053539 (mobile) From Chandrashekhar.Mullaparthi@REDACTED Wed Feb 21 15:22:54 2001 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Wed, 21 Feb 2001 14:22:54 -0000 Subject: Doubt about funs Message-ID: <402DD461F109D411977E0008C791C3120391998F@imp02mbx.one2one.co.uk> IMHO, adding the arity in the fun specification will not add any more value. On the contrary, it'll be a bit of a pain when we want to write code like: somefunc(Fun) -> receive Pattern1 -> Fun(a,b); Pattern2 -> Fun(a,b,c) end. cheers, Chandru > -----Original Message----- > From: Lon Willett [mailto:Lon.Willett@REDACTED] > Sent: 21 February 2001 13:44 > To: erlang-questions@REDACTED > Cc: Paulo Ferreira > Subject: Re: Doubt about funs > > > So has anyone considered implementing a syntax like "fun > Mod:Fun/Arity"? > > It seems like an obvious thing to do. And even a naive implementation > which just replaced the expression with "{M,F}" (losing the arity) > would at least provide a nice consistent way to express the intent. A > good implementation would produce some dynamic function object that > was efficient, contained the arity, and was robust across code change. > > /Lon > -- > Lon Willett > Security Architect, SSE Ltd. > Fitzwilliam Court, Leeson Close > Dublin 2, Ireland > +353-1-216-2946 > +353-87-8053539 (mobile) > 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 vances@REDACTED Wed Feb 21 16:57:12 2001 From: vances@REDACTED (Vance Shipley) Date: Wed, 21 Feb 2001 10:57:12 -0500 Subject: Erlang as .so In-Reply-To: <5.0.2.1.0.20010221102649.00bc3450@mail> Message-ID: > Werl is not much better than the command-line interface, and not It would at least be nice if cut & paste worked properly. Currently it works just a little bit better than the DOS shell. What I'd really like is for it to work as XWindows (cut with left, paste with middle). > all of us think that shell mode in emacs is the ultimate IDE. When > I've finished some stuff I will look into it. > > /Jakob I've been tempted for some time to rewrite edlin.erl for vi mode. -Vance From jamesh@REDACTED Wed Feb 21 17:40:42 2001 From: jamesh@REDACTED (James Hague) Date: Wed, 21 Feb 2001 10:40:42 -0600 Subject: Various (and almost completely unrelated) questions and opini ons Message-ID: > Have you looked at Oberon? I am somewhat persuaded by the > Oberon rationale > against overloaded operators. Oberon is roughly my idea of > what a C level > language with objects should have been. They claim extreme > simplicity is > a good thing. To back it up, the Oberon language > specification is coherent > and complete in something like 28 pages. See other simple > languages, eg > R5RS for contrast. Overloaded operators don't make sense in a functional language, IMO. Actually, I'd argue that they don't make sense in C++. If you consider matrix multiplication, the old style C way was like this: matmul(result, a, b). The pain isn't from having to type "matmul" instead of "*", it's from having to keep track of temporary variables to hold intermediate results. This could be rewritten to use returned structures instead: result = matmul(a, b). That takes care of most of the problem. In functional languages the "structure return" style is the norm, so I don't see a need for overloaded operators. In fact, I'd be just fine with having to type add(X,Y) everywhere instead of A+Y, as long as there were versions of add that supported different numbers of parameters. Maybe I'm just weird :) James From spearce@REDACTED Wed Feb 21 18:34:13 2001 From: spearce@REDACTED (Shawn Pearce) Date: Wed, 21 Feb 2001 12:34:13 -0500 Subject: Translating from pid to node name Message-ID: <20010221123413.Y12184@spearce.org> I have a server process which is going to get the pid of another process, most likely from another node (erts node). How can I translate that pid to the name of the node that its coming from? Specifically I want to advoid having to send the process a message to request its node name. :-) -- Shawn. ``If this had been a real life, you would have received instructions on where to go and what to do.'' From Sean.Hinde@REDACTED Wed Feb 21 19:15:26 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Wed, 21 Feb 2001 18:15:26 -0000 Subject: Translating from pid to node name Message-ID: <402DD461F109D411977E0008C791C312039F5DB8@imp02mbx.one2one.co.uk> > I have a server process which is going to get the pid of another > process, most likely from another node (erts node). How can I > translate that pid to the name of the node that its coming from? You can just use node(Pid). The docs for the erlang module are large but very useful :) - 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 rv@REDACTED Wed Feb 21 19:55:38 2001 From: rv@REDACTED (Robert Virding) Date: Wed, 21 Feb 2001 19:55:38 +0100 Subject: Doubt about funs In-Reply-To: Your message of "21 Feb 2001 13:44:23 GMT." Message-ID: <200102211855.TAA12255@trana.bluetail.com> Lon Willett writes: >So has anyone considered implementing a syntax like "fun Mod:Fun/Arity"? > >It seems like an obvious thing to do. And even a naive implementation >which just replaced the expression with "{M,F}" (losing the arity) >would at least provide a nice consistent way to express the intent. A >good implementation would produce some dynamic function object that >was efficient, contained the arity, and was robust across code change. This was considered but there did not seem to be any point seeing it can easily be had with "fun (A, ...) -> m:f(A, ...) end". This, by the way, will handle module updates of module m as it is just a normal call. Some other significant benefits with a fun which cannot be handles by {M,F} are: 1. The fun "function", the one automatically created, doesn't have to be exported and allows you to keep tighter control of your interface. 2. A fun is a closure over the variable bindings when it was created so it "imports" free variables. This is a big one. For example: incrementer(X) -> fun (Y) -> Y+X end. and calling incrementer(15) returns a function which increments a vlue by 15. 2. Using spawn/1/2 and funs allow you create processes without exporting "internal" functions. Plus the closure (but be careful to keep track of when things are done!). Ulf Wiger writes: >On Wed, 21 Feb 2001, Martin Bjorklund wrote: > >>Ulf Wiger wrote: >> >>> Since funs are actually made into real functions by the compiler, they >>> seem to have roughly the same properties as ordinary functions during >>> code change. I've run some tests, and it does seem to be the case that >>> as long as the fun is tail recursive (doesn't wait for a return >>> value), then upgrading doesn't break the fun as long as the arity >>> stays the same. This is the same as for ordinary functions. >> >>erik> What you describe will happen in the current implementation if >>erik> the function defining F is changed (or any funs are added or >>erik> removed before the fun defining F). > >Yes, you're right. Adding a fun before a fun referenced by some >process P, will cause P to crash when the old module is purged. There is a little misconception about the implementation here. Yes, a normal Erlang function is created for a fun with a funny name which actually gives some indication of where the fun is defined, at least in which function. The fun "object" contains a (indirect) reference to this *name*. It also contains the module name and a unique module id. This means that: 1. The module name and id mean that you can call funs which are defined in the old version of code, not just in the new version. A fun is therefore usable over one module update. 2. There are no problems when updating a module about moving things, add/removing funs etc. A fun contains an identifier to which version of a module it was defined in, it won't just test the new version. 3. Seeing funs reference a module and do not contain the code they run they don't "live forever" like other data, or rather are "usable forever". When the module has been pruged out you can no longer call the fun. But they are safe during their lifetime. Getting back to the {M,F} versus fun question. They actually *mean* two different things even though the syntax for using them is the same. As long as you are aware of this then there are no real problems. I personally never use {M,F} and only use funs for temporary things, like for higher-order functions. I have had no problems with module versions, but then again my funs are short lived. Robert From bparsia@REDACTED Wed Feb 21 20:43:03 2001 From: bparsia@REDACTED (Bijan Parsia) Date: Wed, 21 Feb 2001 14:43:03 -0500 (EST) Subject: Inets, CGI, Python, and Windows, oh my! Message-ID: Or "Oh damn!" ;) Anyone have any tips on running python cgi scripts under Inets under Windows (gag) 98? AFAICT, it's not going to work out of the box no matter how I diddle the settings. mod_cgi:is_executable/1 seems incapable of recognizing *.py files as executables because, well, they *aren't* to Windows, or rather, to *dos* (yuck!). (Note that os:find_executable(python) works, so the python executable is in my PATH variable.) Even if it would find the interpereter, it's not clear that it will get any results or even execute the script. os:cmd("python tester.py"). doesn't work. It doesn't execute the script (though sometimes it *does* crash windows). os:cmd("python -c \"import tester; tester.test()"). *does* work and even gets the results. Oh the pain. Any hints like suffering souls care to share? Cheers, Bijan Parsia. From matthias@REDACTED Wed Feb 21 21:00:03 2001 From: matthias@REDACTED (matthias@REDACTED) Date: Wed, 21 Feb 2001 21:00:03 +0100 (CET) Subject: stand-alone Erlang for windows Message-ID: <14996.7747.320402.722336@corelatus.com> Hi, I use linux and haven't developed software on windows since 1994. Now I've got a lovely application which uses stand-alone Erlang and I'd like to give it to someone with a windows box. What do I need to do? Do I need to compile the SAE stuff under windows, or is it included in the download for windows? If it isn't, can someone give me the necessary binaries? Matthias From cpressey@REDACTED Wed Feb 21 20:59:11 2001 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 21 Feb 2001 13:59:11 -0600 Subject: Doubt about funs References: <00c401c09b97$559b9340$c90b0a0a@student.uu.se> <20010221095258C.mbj@bluetail.com> <028701c09bf5$1a4b5010$980cee82@it.uu.se> Message-ID: <3A941E0F.63699F96@catseye.mb.ca> "Erik.Johansson" wrote: > Paulo Ferreira wrote: > > So, here is another advantage of erlang: One doubt and in two hours time > > I have five correct answers !!! > And then the obligatory debate starts ;) Can a lowly newbie like myself get in on this action? :-) > To summarize my view: > 1. For short lived tasks: always use a fun. > 2. For spawing use a tail-recursive fun. > 3. For long-lived (call-backs) either make a careful design or stick to {M., F} if you feel that it is easier. Earlier, Martin Bjorklund wrote: > Just to make my point clear, I do like funs, and I use them all the > time, but only for short-lived tasks like in a local lists:foreach > etc. In code that e.g. registers callbacks to be invoked at a later > time, I use the tuple syntax. To me, "short-lived" has little to do with it... As I understand it - fun objects were introduced into Erlang so that functions passed to and returned from other functions could be anonymous (and so they could "lift" closure variables, which obviously cannot be done inside named functions). So when I go to write a function I generally ask myself - is it a rendez-vous point - does it deserve a name? If it's going to be referred to elsewhere, it will need one. If not, it's local and should probably be a fun. Here's the interesting question, though. How would one go about making a tail-recursive (anonymous) fun anyway? It can't call itself, because it doesn't have a name :-) _chris -- "Ten short days ago all I could look forward to was a dead-end job as a engineer. Now I have a promising future and make really big Zorkmids." Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/ Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html From tshab@REDACTED Wed Feb 21 21:54:20 2001 From: tshab@REDACTED (Ted Shab) Date: Wed, 21 Feb 2001 12:54:20 -0800 (PST) Subject: Inets, CGI, Python, and Windows, oh my! In-Reply-To: Message-ID: <20010221205420.71178.qmail@web10010.mail.yahoo.com> This may help: http://support.microsoft.com/support/kb/articles/Q164/6/74.ASP?LN=EN-US&SD=gn&FR=0&qry=bat&rnk=2&src=DHCS_MSPSS_gn_SRCH&SPR=IIS HOWTO: Use a CMD or BAT File as a CGI Script SUMMARY Internet Information Server 1.0 (IIS) can use .cmd or .bat files as CGI scripts. In IIS 2.0 and 3.0, this capability has been removed by default. MORE INFORMATION You can enable the use of .cmd and .bat files with IIS by adding a script mapping to the registry. WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. For information about how to edit the registry, view the "Changing Keys And Values" online Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" online Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. Start Registry Editor (Regedt32.exe) and locate the following registry subkey in the HKEY_LOCAL_MACHINE subtree: \SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\Script Map On the Edit menu, click Add Value. Enter the following for .cmd files: Value Name: .CMD Data Type: REG_SZ String: "\Winnt\system32\cmd.exe /c %s %s" (Leave off the quotation marks) For .BAT files, repeat this process and substitute .BAT for .CMD in the value name. Sample Script Use any text editor to create the following script and save it as myscript.cmd. @echo off echo Content-Type: text/plain echo. echo Hello World!! echo. echo. The above test script can be placed in the IIS server \scripts directory. You can run this script from the following URL, for example: http://servername/scripts/myscript.cmd --- Bijan Parsia wrote: > Or "Oh damn!" ;) > > Anyone have any tips on running python cgi scripts > under Inets under > Windows (gag) 98? > > AFAICT, it's not going to work out of the box no > matter how I diddle the > settings. mod_cgi:is_executable/1 seems incapable of > recognizing *.py > files as executables because, well, they *aren't* to > Windows, or rather, > to *dos* (yuck!). > > (Note that os:find_executable(python) works, so the > python executable is > in my PATH variable.) > > Even if it would find the interpereter, it's not > clear that it will get > any results or even execute the script. > > os:cmd("python tester.py"). > > doesn't work. It doesn't execute the script (though > sometimes it *does* > crash windows). > > os:cmd("python -c \"import tester; tester.test()"). > > *does* work and even gets the results. > > Oh the pain. > > Any hints like suffering souls care to share? > > Cheers, > Bijan Parsia. > __________________________________________________ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/ From jouni.ryno@REDACTED Wed Feb 21 21:57:26 2001 From: jouni.ryno@REDACTED (Jouni Ryno) Date: Wed, 21 Feb 2001 22:57:26 +0200 Subject: Erlang, C, IC and asyncronous servers/clients Message-ID: The current IC-system seems to generated code only for cases, were communication is initiated from only one side. I would need to port some older code, which used IG in more asynchronous way (yes, I know, it was not completely safe). In detail I have Erlang side C side raw telemetry -> data processing, packet detection when packet found from raw telemetry <- packet_type_X <- packet_type_Y <- up to N packets C-process receives binary chunks from Erlang, whenever it finds a valid, complete packet, it sends it to Erlang-process for further distribution. The catch is, there's n packets to generate, so simple function return values is not adequate. At least the IC examples for C-server and -client don't allow this kind of two-way message sending. So to put it simply, is there a way to do it ? (and yes, the I could the processing in Erlang, but we also have to give out source code for colleagues to analyze data later. Erlang is used in real time situation ) Jouni Ryn? mailto://Jouni.Ryno@REDACTED/ http://www.geo.fmi.fi/~ryno/ Finnish Meteorological Institute http://www.fmi.fi/ Geophysical Research http://www.geo.fmi.fi/ P.O.BOX 503 Tel (+358)-9-19294656 FIN-00101 Helsinki GSM (+358)-50-5302903 Finland FAX (+358)-9-19294603 "It's just zeros and ones, it cannot be hard" From cpressey@REDACTED Wed Feb 21 22:29:10 2001 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 21 Feb 2001 15:29:10 -0600 Subject: Various (and almost completely unrelated) questions and opinions References: Message-ID: <3A943326.A0C26FF3@catseye.mb.ca> David Gould wrote: > Have you looked at Oberon? Only briefly. I used to use Pascal a lot and Modula-2 some, but eventually got kind of sick of Wirth languages. > Anyway, the Oberon argument is that code should be understandable by > reading it. That is, what is being done and the cost of doing it should > be apparent by looking at it. The problem with overloading is that "A + B" > could mean anything, eg "blend these two 80MB images", and it is not obvious > from the immediate source what the heck is going on or what it might cost. Well, yes. That's a valid argument for cost-conscious programming. Of course, it also happens to be an argument against polymorphism, inheritance, and any other feature that makes it hard to "judge the cost by the syntax." I mean, you can already say add(X,Y) when number(X), number(Y) -> X + Y; add(X,Y) when element(1, X) == image -> LiC(X,Y). which means it's already possible to write Erlang code which is hard to judge the cost of by looking at the application. > > only of limited use unless you can have user-defined functions in > > guards. This is assuming that the semantics of any overloaded operator > > are expressed by a user-defined function, and that relational operators > > can be overloaded. > I like the rationale for the restrictions on guards, that they are > restricted to known time or constant time operations without side > effects. What is worse to me is the unorthogonality - that I can't say integer(X) or tuple(X) outside of a guard and mean the same thing. James Hague wrote: > Overloaded operators don't make sense in a functional language, IMO. > Actually, I'd argue that they don't make sense in C++. If you consider > matrix multiplication, the old style C way was like this: matmul(result, a, > b). The pain isn't from having to type "matmul" instead of "*", it's from > having to keep track of temporary variables to hold intermediate results. Well, actually, for me, the pain is having those parentheses - a nesting level. I work with rather long numerical expressions. And to me it is much easier to read a * b * c * d * e * f * g. than matmul(a, matmul(b, matmul(c, matmul(d, matmul(e, matmul(f, g)))))). "Gobs and gobs of nested brackets" is not one of elements of the LISP heritage in Erlang that I particularly like! :-) But this all points to the fact that what I am thinking of is in fact a different language than Erlang, and I shan't complain about these characteristics of Erlang in the future. No overloading, guards are a form of type constraint, and so forth, for the sake of predictability and ease of cost judgement. _chris -- "Ten short days ago all I could look forward to was a dead-end job as a engineer. Now I have a promising future and make really big Zorkmids." Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/ Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html From jamesh@REDACTED Wed Feb 21 22:43:02 2001 From: jamesh@REDACTED (James Hague) Date: Wed, 21 Feb 2001 15:43:02 -0600 Subject: Various (and almost completely unrelated) questions and opini ons Message-ID: Chris Pressey wrote > > Well, actually, for me, the pain is having those parentheses > - a nesting > level. I work with rather long numerical expressions. And > to me it is > much easier to read > > a * b * c * d * e * f * g. > > than > > matmul(a, matmul(b, matmul(c, matmul(d, matmul(e, matmul(f, g)))))). Of course in Lisp you'd just say: (matmul a b c d e f g) which is even shorter than the infix version :) James From mbj@REDACTED Wed Feb 21 23:23:06 2001 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 21 Feb 2001 23:23:06 +0100 Subject: Doubt about funs In-Reply-To: Your message of "Wed, 21 Feb 2001 13:59:11 -0600" <3A941E0F.63699F96@catseye.mb.ca> References: <3A941E0F.63699F96@catseye.mb.ca> Message-ID: <20010221232306R.mbj@bluetail.com> Chris Pressey wrote: > Here's the interesting question, though. How would one go about making > a tail-recursive (anonymous) fun anyway? It can't call itself, because > it doesn't have a name :-) You'd have to do something along these lines: g() -> F = fun(G) -> io:format("looping forever\n"), G(G) end, F(F). /martin From davidg@REDACTED Wed Feb 21 23:23:09 2001 From: davidg@REDACTED (David Gould) Date: Wed, 21 Feb 2001 14:23:09 -0800 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: <3A943326.A0C26FF3@catseye.mb.ca>; from Chris Pressey on Wed, Feb 21, 2001 at 03:29:10PM -0600 References: <3A943326.A0C26FF3@catseye.mb.ca> Message-ID: <20010221142309.A9650@dnai.com> On Wed, Feb 21, 2001 at 03:29:10PM -0600, Chris Pressey wrote: > David Gould wrote: > > Have you looked at Oberon? > > Only briefly. I used to use Pascal a lot and Modula-2 some, but > eventually got kind of sick of Wirth languages. This happens, but Oberon is I think the nicest of all the Wirth efforts. > Well, yes. That's a valid argument for cost-conscious programming. Of > course, it also happens to be an argument against polymorphism, > inheritance, and any other feature that makes it hard to "judge the cost > by the syntax." > > I mean, you can already say > > add(X,Y) when number(X), number(Y) -> X + Y; > add(X,Y) when element(1, X) == image -> LiC(X,Y). > > which means it's already possible to write Erlang code which is hard to > judge the cost of by looking at the application. Sure, but by that standard, any function call is obscure at the limit. What I meant, I think, is that viewing the source text and searching in the source text gives the reader at least a fighting chance to find what is going on. In the Erlang example you give, the definition is explicit, the rule to select which definition is explicit, and text searching will find the definition. In the countercase (why is it always C++?), overloading something like "+" combined with some overuse of inheritance and a macro or two makes it almost impossible to tell what "+" gets resolved to without stepping it in a debugger or reading the entire program and libraries. > What is worse to me is the unorthogonality - that I can't say integer(X) > or tuple(X) outside of a guard and mean the same thing. Ok, I think I agree. If it looks like a function, it should be a function. This is my main problem with python, some code things are functions and some are subroutines that do not return a value. > But this all points to the fact that what I am thinking of is in fact a > different language than Erlang, and I shan't complain about these > characteristics of Erlang in the future. No overloading, guards are a > form of type constraint, and so forth, for the sake of predictability > and ease of cost judgement. Please do not fall out of love so fast... and I certainly do not speak for the Erlang designers, so maybe overloading is coming soon. -dg -- David Gould davidg@REDACTED 510 536 1443 If simplicity worked, the world would be overrun with insects. From etxuwig@REDACTED Wed Feb 21 23:43:07 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 21 Feb 2001 23:43:07 +0100 (MET) Subject: Various (and almost completely unrelated) questions and opini ons In-Reply-To: Message-ID: On Wed, 21 Feb 2001, James Hague wrote: >Chris Pressey wrote >> to me it is much easier to read >> >> a * b * c * d * e * f * g. >> >> than >> >> matmul(a, matmul(b, matmul(c, matmul(d, matmul(e, matmul(f, g)))))). > >Of course in Lisp you'd just say: > >(matmul a b c d e f g) > >which is even shorter than the infix version :) Ok, so matmul([V|Values]) -> lists:foldl(fun(X,Prod) -> matmul(Prod, X) end, V, Values). ... matmul([a,b,c,d,e,f,g]). (: /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 cpressey@REDACTED Thu Feb 22 08:41:59 2001 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 22 Feb 2001 01:41:59 -0600 Subject: Various (and almost completely unrelated) questions and opinions References: <3A943326.A0C26FF3@catseye.mb.ca> <20010221142309.A9650@dnai.com> Message-ID: <3A94C2C7.8C604142@catseye.mb.ca> David Gould wrote: > On Wed, Feb 21, 2001 at 03:29:10PM -0600, Chris Pressey wrote: > > [...] it's already possible to write Erlang code which is hard to > > judge the cost of by looking at the application. > Sure, but by that standard, any function call is obscure at the limit. OK. I suppose my point is that this sort of feature can always be abused. If you disallow it by not offering the feature, you stop it from being abused, but you also prevent the possible good uses of it. I don't think it's really worth the tradeoff, in Erlang. > > What is worse to me is the unorthogonality - that I can't say integer(X) > > or tuple(X) outside of a guard and mean the same thing. > Ok, I think I agree. If it looks like a function, it should be a function. (Speaking of conformity, almost every other language I've ever seen uses ">=" for "greater than or equal to". Not Erlang... :-) > Please do not fall out of love so fast... and I certainly do not speak for > the Erlang designers, so maybe overloading is coming soon. Well, I originally thought about overloading because I thought that maybe with it, I could use Erlang to solve some problems it wasn't originally designed for, by having it work on a customized primitive data type. But that just isn't the case. And on general principles, I'm no fan of overloading either, because it does rely on a lot of far-reaching context. So I am inclined to agree with the application of an Oberon-like philosophy to overloading in Erlang. Keep it predictable; disallow operator overloading. Polymorphism (such as it is with this LISP-like type system) is probably a better idea than overloading for a functional language. The "==" operator is a good example of good built-in polymorphism. My desired language differs from Erlang in several ways. It's more of a number-crunching language where cost-consciousness isn't a priority but clarity is. What I'm going to do instead of using Erlang (and should have thought about doing from the start) is to *steal* the best ideas from Erlang for my own use. :-) I'll still write the compiler in Erlang though, and probably have it compile to Erlang as well. It's probably a little too much to do with a parse transformation - and I might want to have destination formats other than Erlang someday - all the more reason for it to be it's own language. _chris -- "Ten short days ago all I could look forward to was a dead-end job as a engineer. Now I have a promising future and make really big Zorkmids." Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/ Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html From raimo@REDACTED Thu Feb 22 09:08:49 2001 From: raimo@REDACTED (Raimo Niskanen) Date: Thu, 22 Feb 2001 09:08:49 +0100 Subject: problem to compiler ".erl" file to ".bean" file. References: <007b01c09c04$e1c41460$356429a4@dis.unb.br> Message-ID: <3A94C911.293EF22@erix.ericsson.se> > "Joao Jr." wrote: > > Hi, > > I've problem when a try to compiler ".erl" file to ".bean" file. > > I execute the compiler, it compiler perfectly, but ".bean" file isn't > create and it isn't return any error. > > Then a can't use my functions. > > What can I do, to solve this problem? > > thanks. > > Please be more specific. Which command do you give, what is the printout, which version of Erlang are you running, and on what operating system. And by the way, the result files are ".beam" files, not ".bean" files. Normally, the command "erlc foo.erl" produces no printout, but the result file "foo.beam", when successful. / Raimo Niskanen, Ericsson UAB, Erlang/OTP From voudheus@REDACTED Thu Feb 22 10:11:32 2001 From: voudheus@REDACTED (Karel Van Oudheusden) Date: Thu, 22 Feb 2001 10:11:32 +0100 Subject: Ericsson and Active Networks? Message-ID: <3A94D7C4.C18B032F@imec.be> Hello, I have been studying the Erlang language for some time now and am personally doing research in the area of Active Networks (http://www.sds.lcs.mit.edu/activeware/). If I am not mistaken, the hype around Active Networks actually started somewhere in the USA when they discovered that Ericsson had a programming language and run-time system (Erlang) with the very important property of "hot swappable code". Could people who are doing research in this field please give me a sign? What are the motivations, from Ericsson's point of view, on why these Active Networks are interesting in an industrial setting? (I know most of the academic reasons, but are they realistic?) To be precise, what I mean with Active Networks is a future Internet containing many mobile entities that both act as "routers" for certain connections or act as "end users" for others (or both simultaneously). But perhaps other, more realistic definitions of Active Networks are preferable. I am also referring to the research area of Pico Nodes (http://bwrc.eecs.berkeley.edu/). I am working here at IMEC and I would like to know if somebody of Ericsson is willing to participate in a video-conferencing session with one of my bosses regarding this issue (Ericsson and IMEC are already working together on certain issues). Perhaps this is an akward way of stating my (our) interest, but our research has, until now, not addresses this issue of Active Networks. Thank you for your cooperation, Karel. From thomasl@REDACTED Thu Feb 22 10:58:57 2001 From: thomasl@REDACTED (Thomas Lindgren) Date: Thu, 22 Feb 2001 10:58:57 +0100 Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: <20010221142309.A9650@dnai.com> (message from David Gould on Wed, 21 Feb 2001 14:23:09 -0800) References: <3A943326.A0C26FF3@catseye.mb.ca> <20010221142309.A9650@dnai.com> Message-ID: <200102220958.KAA00955@lammgam.bluetail.com> David Gould: > In the countercase (why is it always C++?), overloading something > like "+" combined with some overuse of inheritance and a macro or > two makes it almost impossible to tell what "+" gets resolved to > without stepping it in a debugger or reading the entire program and > libraries. So, what can one say about the Erlang construct "F(X1,X2,X3)"? A casual reader can not in general see what F is supposed to do. I think the use of higher-order functions suffers from the same defect as overloading or objects (esp. with before- and after-methods and suchlike), namely that it is hard to follow what actually will happen in the general case. (The benefits may outweigh this disadvantage, but that's beside the point.) Well-known idioms (foldl, forall) can be managed, but it's easy to get lost in a maze of anonymous functions and function-valued parameters. Conclusion: use carefully. Apply can occasionally be even worse. I _have_ heard one correspondent on this list defend the use of sending "some term" across the network, constructing an atom from it and doing an apply on the result. But not in public :-) (The idea of doing apply on dynamically constructed atoms has been independently rediscovered at least once. In the module lib/asn1/src/asn1rt.erl in R7B0, we find the following code: encode(ber,Module,Type,Term) -> Call = list_to_atom(lists:concat(['enc_',Type])), case catch apply(Module,Call,[Term,[]]) of ... end; ... ) Thomas -- Thomas Lindgren thomas+junk@REDACTED Alteon WebSystems From shrogers@REDACTED Thu Feb 22 10:35:32 2001 From: shrogers@REDACTED (Steven H. Rogers) Date: Thu, 22 Feb 2001 03:35:32 -0600 Subject: Various (and almost completely unrelated) questions and opinions References: <3A943326.A0C26FF3@catseye.mb.ca> <20010221142309.A9650@dnai.com> <3A94C2C7.8C604142@catseye.mb.ca> Message-ID: <3A94DD63.F8A1FFED@ionet.net> Chris Pressey wrote: > > ... > My desired language differs from Erlang in several ways. It's more of a > number-crunching language where cost-consciousness isn't a priority but > clarity is. What I'm going to do instead of using Erlang (and should > have thought about doing from the start) is to *steal* the best ideas > from Erlang for my own use. :-) > > ,,. You might want to look at A+ (http://www.aplusdev.org), an APL derivative that Morgan Stanley Dean Witter released as open source last month. It has a functional flavor and is good for number crunching. It uses the APL character set which, while concise and elegant, makes setting up a development environment a bit of a hassle if you're not a *nix font guru. In addition to the source, binaries are available for Irix, Linux, and Solaris. Regards, Steve -- TANSTAAFL From richardc@REDACTED Thu Feb 22 11:51:58 2001 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 22 Feb 2001 11:51:58 +0100 (MET) Subject: Various (and almost completely unrelated) questions and opinions In-Reply-To: <3A943326.A0C26FF3@catseye.mb.ca> Message-ID: On Wed, 21 Feb 2001, Chris Pressey wrote: > What is worse to me is the unorthogonality - that I can't say > integer(X) or tuple(X) outside of a guard and mean the same thing. As of the coming R8 release, all the old guard tests `atom', `float', etc., will have the better synonyms `is_atom', `is_float', and so on. These can also be called outside of guards as normal boolean functions (they are bifs, belonging to module `erlang'). /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From Jouni.Ryno@REDACTED Thu Feb 22 12:11:31 2001 From: Jouni.Ryno@REDACTED (Jouni.Ryno@REDACTED) Date: Thu, 22 Feb 2001 13:11:31 +0200 Subject: Erlang, C, IC and asyncronous servers/clients In-Reply-To: Message from "Jouni Ryno" of "Wed, 21 Feb 2001 22:57:26 +0200." Message-ID: Oh, from the IC-4.0.5 User's Guide, 6.3 "All functions found in the code are exported. The user is free to define his own client if there is a need for this. The basic client generated is a synchronous client, but an asynchronous client can be implemented by proper use of exported functions." Is there an example of the "proper use" ? Or does it belong to "can be done, but nobody does" -section :-) Jouni Ryn? mailto://Jouni.Ryno@REDACTED/ http://www.geo.fmi.fi/~ryno/ Finnish Meteorological Institute http://www.fmi.fi/ Geophysical Research http://www.geo.fmi.fi/ P.O.BOX 503 Tel (+358)-9-19294656 FIN-00101 Helsinki GSM (+358)-50-5302903 Finland FAX (+358)-9-19294603 "It's just zeros and ones, it cannot be hard" From nick@REDACTED Thu Feb 22 12:53:30 2001 From: nick@REDACTED (Niclas Eklund) Date: Thu, 22 Feb 2001 12:53:30 +0100 (MET) Subject: Erlang, C, IC and asyncronous servers/clients In-Reply-To: Message-ID: Hello! Can't you define the function to be oneway and add a new function which send the N packets back to the Erlang side? If not, you must search for all complete packets and return them in a sequence. The last option is to use the C-interface directly, i.e., not via IC. /Nick On Wed, 21 Feb 2001, Jouni Ryno wrote: > The current IC-system seems to generated code only for cases, were > communication is initiated from only one side. I would need to port > some older code, which used IG in more asynchronous way (yes, I know, > it was not completely safe). > > In detail I have > Erlang side C side > raw telemetry -> data processing, packet detection > when packet found from raw telemetry > <- packet_type_X > <- packet_type_Y > <- up to N packets > > C-process receives binary chunks from Erlang, whenever it finds a > valid, complete packet, it sends it to Erlang-process for further > distribution. The catch is, there's n packets to generate, so simple > function return values is not adequate. > > At least the IC examples for C-server and -client don't allow this kind > of two-way message sending. > > So to put it simply, is there a way to do it ? > > (and yes, the I could the processing in Erlang, but we also have to > give out source code for colleagues to analyze data later. Erlang is > used in real time situation ) From Jouni.Ryno@REDACTED Thu Feb 22 12:11:31 2001 From: Jouni.Ryno@REDACTED (Jouni.Ryno@REDACTED) Date: Thu, 22 Feb 2001 13:11:31 +0200 Subject: Erlang, C, IC and asyncronous servers/clients In-Reply-To: Message from "Jouni Ryno" of "Wed, 21 Feb 2001 22:57:26 +0200." Message-ID: Oh, from the IC-4.0.5 User's Guide, 6.3 "All functions found in the code are exported. The user is free to define his own client if there is a need for this. The basic client generated is a synchronous client, but an asynchronous client can be implemented by proper use of exported functions." Is there an example of the "proper use" ? Or does it belong to "can be done, but nobody does" -section :-) Jouni Ryn? mailto://Jouni.Ryno@REDACTED/ http://www.geo.fmi.fi/~ryno/ Finnish Meteorological Institute http://www.fmi.fi/ Geophysical Research http://www.geo.fmi.fi/ P.O.BOX 503 Tel (+358)-9-19294656 FIN-00101 Helsinki GSM (+358)-50-5302903 Finland FAX (+358)-9-19294603 "It's just zeros and ones, it cannot be hard" From Jouni.Ryno@REDACTED Thu Feb 22 13:23:49 2001 From: Jouni.Ryno@REDACTED (Jouni.Ryno@REDACTED) Date: Thu, 22 Feb 2001 14:23:49 +0200 Subject: Erlang, C, IC and asyncronous servers/clients In-Reply-To: Message from Niclas Eklund of "Thu, 22 Feb 2001 12:53:30 +0100." Message-ID: > > Hello! > > Can't you define the function to be oneway and add a new function which > send the N packets back to the Erlang side? The problem is, that I would anyway have to initiate the transfer from the data-sending-side. That's why I'm searching for asynchronous c-server. > If not, you must search for > all complete packets and return them in a sequence. Hmm, yes, in effect putting packets inside packet. It just don't look correct :-) >The last option is to > use the C-interface directly, i.e., not via IC. > Ugly :-) But anyway, I just have to make it work this week, so I might even try to make it work with old IG. If I remember correctly, someone was still keeping it alive ... But thanks anyway. Jouni Ryn? mailto://Jouni.Ryno@REDACTED/ http://www.geo.fmi.fi/~ryno/ Finnish Meteorological Institute http://www.fmi.fi/ Geophysical Research http://www.geo.fmi.fi/ P.O.BOX 503 Tel (+358)-9-19294656 FIN-00101 Helsinki GSM (+358)-50-5302903 Finland FAX (+358)-9-19294603 "It's just zeros and ones, it cannot be hard" From richardc@REDACTED Thu Feb 22 13:35:43 2001 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 22 Feb 2001 13:35:43 +0100 (MET) Subject: Doubt about funs In-Reply-To: Message-ID: On 21 Feb 2001, Lon Willett wrote: > So has anyone considered implementing a syntax like "fun Mod:Fun/Arity"? > > It seems like an obvious thing to do. And even a naive implementation > which just replaced the expression with "{M,F}" (losing the arity) > would at least provide a nice consistent way to express the intent. A > good implementation would produce some dynamic function object that > was efficient, contained the arity, and was robust across code change. It has been vaguely discussed (in the work on creating a Standard Erlang specification), but then restricted to built-in functions only (since these are known not to change), like `fun erlang:length/1'. It never caught on, though, and I don't think it was a very useful idea. After some more pondering about the problem of funs and code change, I think that the main issue is the use of the `F(...)' syntax. A simple rule should suffice here: if the callback value could be rather old, so that its target module might have been replaced once or more since the value was passed, then *do not use `F(...)' for the callback*. If we write code for a server or similar long-lived process, allowing clients to send us callbacks (in some form), then there are two possible situations: In the first case, we apply the callback as soon as we handle the message in which it was passed. In this case, we can allow the client to pass a fun which we apply using `F(...)', because we can assume that there hae been no code change between its creation and its application. (It is of course possible that the fun is already "stale" when sent to us, but this is not really different from being sent a fun which is broken in some other way.) In the second case, we ourselves are storing the callback for later use. We thus know that when we eventually apply it, the callback module could have been replaced any number of times since we were passed the value. In this case, we should probably not use `F(...)' (even when it would be tempting). We should instead decide on a format for the callbacks, such as `{hook, Module, FunctionName, Arity}', match out the components, and call `Module:FunctionName(...)'. In this way, we are *sure* that we do not crash the program by replacing client code (as long as the code remains functionally compatible), because we avoid applying any given fun-values that could have become stale *while we were storing them*. Thus, I say: never use F = {M,N} when you are going to call F with F(...) - and vice versa, if you *want* a dynamic call, do it by matching out and calling M:F(...). For a function that takes a callback as argument, either document that it should be a fun, *or* a tuple representing a function name in some way, but do not allow both. The details of how a dynamic call-back hook should look (e.g., should it include arity and/or "user data"?) are probably best left for the programmer to decide for his particular application. (Maybe for OTP to standardize.) There might even be reason to include a syntax for it in the language, but I don't have any really good suggestions right now. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://www.csd.uu.se/~richardc/ From tobbe@REDACTED Thu Feb 22 13:58:32 2001 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: 22 Feb 2001 13:58:32 +0100 Subject: Erlang, C, IC and asyncronous servers/clients In-Reply-To: "Jouni.Ryno@fmi.fi"'s message of "Thu, 22 Feb 2001 14:23:49 +0200" References: Message-ID: > But anyway, I just have to make it work this week, so I might even try > to make it work with old IG. If I remember correctly, someone was still > keeping it alive ... Yes, you'll find it here: http://www.bluetail.com/~tobbe/ig/doc.new/ Cheers /Tobbe From etxuwig@REDACTED Thu Feb 22 15:57:03 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 22 Feb 2001 15:57:03 +0100 (MET) Subject: process WORM dictionary Message-ID: Hi! Here's a thought. The much-berated process dictionary is very useful for certain purposes, but in many cases, you'd want to use it in a way that you put() an object into it once and then get() it many times. The practice of using the process dictionary to continuously update a set of "global variables" is rightfully discouraged (except this leads people to create an ets table and use it for the same purpose, which is no better -- actually worse in some ways.) Here's an example of reasonable use of the process dictionary, from proc_lib.erl: init_p(Parent,Ancestors,M,F,A) -> put('$ancestors',[Parent|Ancestors]), put('$initial_call',{M,F,A}), Result = (catch apply(M,F,A)), exit_p(Result,M,F,A). What I'm thinking is that there is no reason why it would be even possible for a process to replace these values, by e.g. calling put('$ancestors', NewValue). This is a form of structural information that shouldn't be considered part of the process' metadata. So, wouldn't it be better if there was a write-once dictionary for the process? I realize that there is an ambition to save bytes in the process struct, but perhaps it could be implemented as a "sticky bit" in the existing process dictionary? Any attempt then to overwrite or erase a write-once object would generate a runtime error. /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 Feb 23 14:12:47 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 23 Feb 2001 14:12:47 +0100 (MET) Subject: supervisor:restart_child/2 Message-ID: Here's a question I know you've all been losing sleep over: When I call supervisor:terminate_child(ThisSuper, ThatChild), supervisor:restart_child(ThisSuper, ThatChild). Then the supervisor doesn't count this towards the restart frequency. That is, I can do this forever, and the supervisor will never escalate. Is this by accident, or is it deliberate? If deliberate, what is the reasoning behind it? /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 Sean.Hinde@REDACTED Fri Feb 23 14:32:44 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Fri, 23 Feb 2001 13:32:44 -0000 Subject: supervisor:restart_child/2 Message-ID: <402DD461F109D411977E0008C791C312039F5DC9@imp02mbx.one2one.co.uk> Ulf> > When I call > > supervisor:terminate_child(ThisSuper, ThatChild), > supervisor:restart_child(ThisSuper, ThatChild). > > Then the supervisor doesn't count this towards the restart > frequency. That is, I can do this forever, and the supervisor will > never escalate. > Seems reasonable to me. Presumably the assumption is that as you are explicitly calling these functions you are in control of things therefore it is not a fault condition. Is 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 etxuwig@REDACTED Fri Feb 23 14:58:16 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 23 Feb 2001 14:58:16 +0100 (MET) Subject: supervisor:restart_child/2 In-Reply-To: <402DD461F109D411977E0008C791C312039F5DC9@imp02mbx.one2one.co.uk> Message-ID: On Fri, 23 Feb 2001, Sean Hinde wrote: >Ulf> > >> When I call >> >> supervisor:terminate_child(ThisSuper, ThatChild), >> supervisor:restart_child(ThisSuper, ThatChild). >> >> Then the supervisor doesn't count this towards the restart >> frequency. That is, I can do this forever, and the supervisor will >> never escalate. > >Seems reasonable to me. Presumably the assumption is that as you are >explicitly calling these functions you are in control of things >therefore it is not a fault condition. Is it? Well, I'm not sure... (: The reason I even care is that I have re-written supervisor so that it is able to tell the child how many times it has restarted, and by extension, whether it is starting for the first time, or whether it is, for example, an escalated restart. In this context, what does it mean when someone explicitly terminates a child and restarts it? Shouldn't I update the count of how many times it's restarted? And if I do, shouldn't I terminate the supervisor if the restart intensity is exceeded? One alternative is to pretend as if nothing has happened. This will, of course, not fool the child -- it will know that _something_ happened... Another alternative is to reset the restart count. This might have surprising effects. My guess is that if you're going to explicitly terminate and restart a child, you're probably only going to do it once in a fortnight or so, so it most likely won't matter. So, I made restart_child/2 also update the restart count. This means that it can also trigger an escalated restart. My hacked supervisor.erl and the hacked behaviour modules seem to work just fine. I can't post them, as the archive is too large, but if anyone wants to check them out, let me know. BTW, I've also rewritten the supervisor to use monitor instead of links (actually, it uses both), so now a child can't mess up the supervision by explicitly unlinking. /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 lennart.ohman@REDACTED Fri Feb 23 16:21:31 2001 From: lennart.ohman@REDACTED (=?iso-8859-1?Q?Lennart__=D6hman?=) Date: Fri, 23 Feb 2001 16:21:31 +0100 Subject: supervisor:restart_child/2 Message-ID: Hi everyone! There are several reasons to this: 1) If the supervisor would count your explicit manipulations, do you want it to immediately restart a terminated child? Most often not. Therefore this management must be done outside the restart intensity. 2) Restarts are only done (and restart intensity exhausted) by *illegal* terminations. Each child has a permanence (temporary, transient or permanent) defining when it terminates illegally. If explicit terminations done through the API shall be counted, the semantics of illegal terminations must be extended to cover different types of API initiated terminations. /Lennart Ohman >Ulf> > >> When I call >> >> supervisor:terminate_child(ThisSuper, ThatChild), >> supervisor:restart_child(ThisSuper, ThatChild). >> >> Then the supervisor doesn't count this towards the restart >> frequency. That is, I can do this forever, and the supervisor will >> never escalate. > From etxuwig@REDACTED Fri Feb 23 17:01:05 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 23 Feb 2001 17:01:05 +0100 (MET) Subject: supervisor:restart_child/2 In-Reply-To: Message-ID: On Fri, 23 Feb 2001, Lennart ?hman wrote: >Hi everyone! > >There are several reasons to this: >1) If the supervisor would count your explicit manipulations, >do you want it to immediately restart a terminated child? Most >often not. Therefore this management must be done outside the >restart intensity. Well, I'm not sure I agree with that interpretation. Obviously, it's not desireable that a terminate_child/2 would cause the child to immediately restart. That doesn't automatically mean that an ordered restart shouldn't be counted towards the restart frequency. However, a call to terminate_child/2 causes the child to die with reason = shutdown. Even though it's not really stated in the manual, this should count as a normal exit. According to the manual then, the child will not be restarted. However, if a supervisor escalates, or a supervisor with one_for_all or rest_for_one supervision detects a child crash, other children may be terminated with reason = shutdown, and then immediately restarted. Thus, the child cannot make an assumption that.... actually, with the current supervisor, the child can never make _any_ assumptions, because it has no way of finding out why it is being started. Regardless, the manual should be interpreted as implying that explicit terminate_child()/restart_child() operations do not count as non-normal exits. Thus, the implied semantics (by omission, if nothing else) of these functions are that they cannot trigger an escalated restart. I have no problem with this behaviour. However, it could be stated explicitly in the manual. /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 Pascal.Brisset@REDACTED Sat Feb 24 08:09:16 2001 From: Pascal.Brisset@REDACTED (Pascal Brisset) Date: Sat, 24 Feb 2001 08:09:16 +0100 Subject: supervisor:restart_child/2 (throttling) In-Reply-To: References: <402DD461F109D411977E0008C791C312039F5DC9@imp02mbx.one2one.co.uk> Message-ID: <14999.24092.852125.505696@pcg.localdomain> Ulf Wiger writes: > The reason I even care is that I have re-written supervisor so that > it is able to tell the child how many times it has restarted, and > by extension, whether it is starting for the first time, or whether > it is, for example, an escalated restart. I would support some extensions to supervisor.erl too. Suppose a supervised server tries to acquire some resource when it starts, and crashes or terminates if it can't. If the resource is unavailable, we don't really want the child to be shut down with reached_max_restart_intensity. The child can avoid this by waiting for a fixed time on startup or before crashing, but then the availability of the server would be less than optimal (if the child has been running correctly for some time, we should try to restart it immediately, and begin to delay the restarts only if it keeps crashing). Letting the child know that it is having restart problems would definitely helps. It would be even better if the supervisor itself could be configured to throttle the child down, i.e. regulate its restart frequency with some kind of exponential back-off. -- Pascal --- supervisor.erl Thu Dec 14 09:25:59 2000 +++ rsupervisor.erl Sun Jan 21 20:51:28 2001 @@ -445,9 +462,11 @@ {ok, NState} -> restart(NState#state.strategy, Child, NState); {terminate, NState} -> - report_error(shutdown, reached_max_restart_intensity, + report_error(regulate, restart_delayed, Child, State#state.name), - {shutdown, remove_child(Child, NState)} + %% We should use a smarter delay here, and sleep asynchronously. + receive after State#state.period * 1000 -> ok end, + restart(Child, State) end. From Sean.Hinde@REDACTED Sun Feb 25 22:43:30 2001 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Sun, 25 Feb 2001 21:43:30 -0000 Subject: supervisor:restart_child/2 (throttling) Message-ID: <402DD461F109D411977E0008C791C312039F5DD1@imp02mbx.one2one.co.uk> > Suppose a supervised server tries to acquire some resource when it > starts, and crashes or terminates if it can't. If the resource is > unavailable, we don't really want the child to be shut down with > reached_max_restart_intensity. The child can avoid this by waiting > for a fixed time on startup or before crashing, but then the > availability of the server would be less than optimal (if the child > has been running correctly for some time, we should try to restart it > immediately, and begin to delay the restarts only if it keeps > crashing). I'd definitely support this. I find I re-write this sort of functionality quite often and it would be nice to have it formalised into the supervisor behaviour. e.g. my erpc thing posted recently uses timers to retry a tcp/ip connection every few seconds. It would have been very nice to just use supervisor. This would go hand in hand with having an 'infinity' retries option as discussed last year some time on the list. -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 etxuwig@REDACTED Mon Feb 26 10:54:39 2001 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 26 Feb 2001 10:54:39 +0100 (MET) Subject: supervisor:restart_child/2 (throttling) In-Reply-To: <402DD461F109D411977E0008C791C312039F5DD1@imp02mbx.one2one.co.uk> Message-ID: On Sun, 25 Feb 2001, Sean Hinde wrote: >> Suppose a supervised server tries to acquire some resource when it >> starts, and crashes or terminates if it can't. If the resource is >> unavailable, we don't really want the child to be shut down with >> reached_max_restart_intensity. The child can avoid this by waiting >> for a fixed time on startup or before crashing, but then the >> availability of the server would be less than optimal (if the child >> has been running correctly for some time, we should try to restart it >> immediately, and begin to delay the restarts only if it keeps >> crashing). > >I'd definitely support this. I find I re-write this sort of functionality >quite often and it would be nice to have it formalised into the supervisor >behaviour. e.g. my erpc thing posted recently uses timers to retry a tcp/ip >connection every few seconds. It would have been very nice to just use >supervisor. > >This would go hand in hand with having an 'infinity' retries option >as discussed last year some time on the list. OK, issues with the above: 1) It's not acceptable to block the supervisor while delaying a restart. It would have to be done by ordering a timer. 2) If the child crashes and is gone for some time, messages to that child will go into the bit bucket, instead of being buffered while the child is waiting for the resource. 3) A possibility would be to have the supervisor execute a delay in the init function of the process, but then it would first have to send an ack to the supervisor so that it's not blocked unnecessarily (in general, you don't want to block the supervisor for very long) 4) If you _don't_ block the supervisor, then it will proceed to start any children that come after this child. This might be a desired behaviour, but then again it might not. Of course making it an option in the supervisor doesn't preclude either behaviour. /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 kramer@REDACTED Mon Feb 26 22:30:49 2001 From: kramer@REDACTED (Reto Kramer) Date: Mon, 26 Feb 2001 13:30:49 -0800 Subject: Q regarding multicast and n-way connection in a cluster Message-ID: I am relatively new to really getting into Erlang as opposed to just reading every available article about it ;-). So far I used to be involved with building clustered (business) solutions that have employed a technique that seems not to be exactly in line with the Erlang way of architecting such systems. I'd appreciate if someone could illustrate for me how an Erlang architect would build a "clustered stateful service". Let's assume that each client has a little bit of state (some kB) and that there could be many thousand concurrent clients hitting the cluster. Because of the large workload that the large number of clients generates, the cluster might have to get rather large (e.g. 10 to 50 machines). Also we do not want to pass the state back and forth between the client and the server but only pass a session identifier (e.g. as part of a http cookie). For cluster membership I am used to use heartbeats over IP multicast, where each cluster member uses the same multicast address to publish the heartbeat information. Heartbeats can carry all sorts of data (e.g. a servers current load, etc.). Also each server packs its "views" of who else is in the cluster into the heartbeat that is seen by everybody else. This avoids the need for a centralized "member registry". Q1: how could I elegantly access the socket layer to send/listen on a multicast address? It seemed to me that a cluster of n Erlang nodes will "implicitly" n-way interconnect if I have to use message sends from each server to each other server to maintain the cluster membership protocol. While this seems feasible for smaller clusters, I would get nervous about scalability if the cluster contains maybe 100s of machines (I would "waist" those socket resources for something that I could use 1 multicast socket for). Q2: where can I find information as to how the various Erlang constructs (e.g. process links across nodes) translate to "OS resource usage". I am specifically interested in whether inter node communication is multiplexed through a single socket per node-pair (or is there a socket per process or even per send)? Q3: are "process links across nodes" implemented by detecting the breaking of a TCP connection or is there a heartbeat/timeout involved for the point2point connection as well? Thanks for you help and pointer to "implementation level documentation"! cheers, - Reto -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 2768 bytes Desc: not available URL: From mickael.remond@REDACTED Mon Feb 26 22:34:48 2001 From: mickael.remond@REDACTED (Mickael Remond) Date: 26 Feb 2001 22:34:48 +0100 Subject: A French site dedicated to Erlang advocacy and tutorials Message-ID: <87g0h1w2kn.fsf@louxor.home> Hello, I just would like to let you know that I am now running a French site dedicated to Erlang advocacy and promotion: http://www.erlang-fr.org/ The main intention of this site is to promote Erlang language in France by translating documents and articles (such as Bijan Parsia's article on XML), by supporting Erlang developpers in France, by hosting Erlang projects and so on. We are hoping to do our best to make Erlang more widely known in France and to contribute spreading the Erlang passion. One of our goal is to write articles and tutorials that will make Erlang more attractive and more accesible for beginners. The first article is about XML document publication with Erlang and the Sablotron binding. It will be available by the end of the week in French and I hope that I will be able to translate it during the next week end. So, the site is essentially in French, but are also commited to produce valuable content for the English speaking Erlang community. I hope that you will like our work. Stay tuned ! -- Micka?l R?mond From davidg@REDACTED Mon Feb 26 23:35:09 2001 From: davidg@REDACTED (David Gould) Date: Mon, 26 Feb 2001 14:35:09 -0800 Subject: CGI module for Erlang? Message-ID: <20010226143509.C19261@dnai.com> I really like the wikie, and want to run one of my own, but my ISP does not let me run servers. But, I can run CGIs, so I am thinking I could adapt the wikie code to run as a CGI with StandAlone Erlang and run a wikie that way. Which poses the question, has anyone done a CGI module for Erlang? Is anyone interested in one? Any ideas about what it should look like? -dg -- David Gould davidg@REDACTED 510 536 1443 If simplicity worked, the world would be overrun with insects. From Chandrashekhar.Mullaparthi@REDACTED Tue Feb 27 11:43:18 2001 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Tue, 27 Feb 2001 10:43:18 -0000 Subject: Q regarding multicast and n-way connection in a cluster Message-ID: <402DD461F109D411977E0008C791C312039199A8@imp02mbx.one2one.co.uk> Right now I dont think Erlang has explicit support for receiving on a multicast address. Sending to a multicast address is no problem though. But you can use either ports or a linked in driver which implements that for you. You can "configure" a node so that it doesn't automatically connect to all nodes it sees. See the parameter dist_auto_connect in the kernel manual. I could be wrong, but I think inter-node communications are multiplexed through a single-socket-per-node pair. There is a heartbeat between connected erlang nodes. Check the net_ticktime parameter in the kernel manual. When a process dies - all processes linked to it get the message {'EXIT', Pid, Reason} regardless of which nodes these processes reside on. If this is because of a broken TCP connection - the message will be {'EXIT', Pid, noconnection}. You can use node(Pid) to determine from which node this message originated. hth Chandru > -----Original Message----- > From: Reto Kramer [mailto:kramer@REDACTED] > Sent: 26 February 2001 21:31 > To: erlang-questions@REDACTED > Subject: Q regarding multicast and n-way connection in a cluster > > I am relatively new to really getting into Erlang as opposed to just > reading every available article about it ;-). > > So far I used to be involved with building clustered (business) solutions > that have employed a technique that seems not to be exactly in line with > the Erlang way of architecting such systems. > > I'd appreciate if someone could illustrate for me how an Erlang architect > would build a "clustered stateful service". Let's assume that each > client has a little bit of state (some kB) and that there could be many > thousand concurrent clients hitting the cluster. Because of the large > workload that the large number of clients generates, the cluster might > have to get rather large (e.g. 10 to 50 machines). Also we do not want to > pass the state back and forth between the client and the server but only > pass a session identifier (e.g. as part of a http cookie). > > For cluster membership I am used to use heartbeats over IP multicast, > where each cluster member uses the same multicast address to publish the > heartbeat information. Heartbeats can carry all sorts of data (e.g. a > servers current load, etc.). Also each server packs its "views" of who > else is in the cluster into the heartbeat that is seen by everybody else. > This avoids the need for a centralized "member registry". > > Q1: how could I elegantly access the socket layer to send/listen on a > multicast address? > > It seemed to me that a cluster of n Erlang nodes will "implicitly" n-way > interconnect if I have to use message sends from each server to each other > server to maintain the cluster membership protocol. While this seems > feasible for smaller clusters, I would get nervous about scalability if > the cluster contains maybe 100s of machines (I would "waist" those socket > resources for something that I could use 1 multicast socket for). > > Q2: where can I find information as to how the various Erlang constructs > (e.g. process links across nodes) translate to "OS resource usage". I am > specifically interested in whether inter node communication is multiplexed > through a single socket per node-pair (or is there a socket per process or > even per send)? > > Q3: are "process links across nodes" implemented by detecting the breaking > of a TCP connection or is there a heartbeat/timeout involved for the > point2point connection as well? > > Thanks for you help and pointer to "implementation level documentation"! > > cheers, > - Reto > > > > 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 kenneth@REDACTED Tue Feb 27 15:30:03 2001 From: kenneth@REDACTED (Kenneth Lundin) Date: Tue, 27 Feb 2001 15:30:03 +0100 Subject: Erlang, C, IC and asyncronous servers/clients References: Message-ID: <3A9BB9EB.159DF864@erix.ericsson.se> Hi, I think there is an easy solution where you define 2 interfaces, one for each direction and use the same transportation channel for both. /Kenneth Jouni Ryno wrote: > > The current IC-system seems to generated code only for cases, were > communication is initiated from only one side. I would need to port > some older code, which used IG in more asynchronous way (yes, I know, > it was not completely safe). > > In detail I have > Erlang side C side > raw telemetry -> data processing, packet detection > when packet found from raw telemetry > <- packet_type_X > <- packet_type_Y > <- up to N packets > > C-process receives binary chunks from Erlang, whenever it finds a > valid, complete packet, it sends it to Erlang-process for further > distribution. The catch is, there's n packets to generate, so simple > function return values is not adequate. > > At least the IC examples for C-server and -client don't allow this kind > of two-way message sending. > > So to put it simply, is there a way to do it ? > > (and yes, the I could the processing in Erlang, but we also have to > give out source code for colleagues to analyze data later. Erlang is > used in real time situation ) > > Jouni Ryn? mailto://Jouni.Ryno@REDACTED/ > http://www.geo.fmi.fi/~ryno/ > Finnish Meteorological Institute http://www.fmi.fi/ > Geophysical Research http://www.geo.fmi.fi/ > P.O.BOX 503 Tel (+358)-9-19294656 > FIN-00101 Helsinki GSM (+358)-50-5302903 > Finland FAX (+358)-9-19294603 > > "It's just zeros and ones, it cannot be hard" -- Kenneth Lundin Ericsson Utvecklings AB kenneth@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 57 25 125 25 ?lvsj? From bauerd@REDACTED Tue Feb 27 23:52:50 2001 From: bauerd@REDACTED (David W. Bauer Jr.) Date: Tue, 27 Feb 2001 17:52:50 -0500 (EST) Subject: INETS Question In-Reply-To: <3A9BB9EB.159DF864@erix.ericsson.se> Message-ID: I am trying to POST a form to INETS and was curiosu to know what Inets would do with large amounts of content. Can I always rely upon getting data in one large chunk from the server into my module? Specifically, here is my fun: fun(Env, Input) -> Input = httpd:parse_query(Input). This should return to me the following according to the documentation: ServerRet = [{Key,Value}] When I make this POST: POST /exchange/erl/api/exml HTTP/1.0\r Accept: */*\r User-Agent: Mozilla\r Content-Length: 5\r \r dave LF I get Key = "dave\n", Value = []. But what if the content where very large? Thanks, David ~~~ ~~ ~~~~ _o URL: http://www.david-bauer.com ~~~ ~~~~ ~~ _'|<,_ ~~~~ ~~~ ~~~~ (*)/ (*) From vladdu@REDACTED Wed Feb 28 21:27:26 2001 From: vladdu@REDACTED (Vlad Dumitrescu) Date: Wed, 28 Feb 2001 21:27:26 +0100 Subject: Erlang OS Message-ID: Hi all! I was reading again through the Erlang book, and got to the OS chapter. And I started wondering... what if there was an ErlangOS? What would it take to implement it? Of course, for efficiency there would be a lot of C stuff anyway, but I think it might be an interesting thing to look into. Maybe a special driver might allow to run any POSIX compliant program within an Erlang environment and (maybe) make it look like a regular Erlang process.... Just some random thoughts... but maybe someone thinks it might make a fun master thesis :-) regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry@REDACTED Wed Feb 28 22:08:51 2001 From: thierry@REDACTED (Thierry Mallard) Date: Wed, 28 Feb 2001 22:08:51 +0100 Subject: Erlang OS In-Reply-To: <200102282105.f1SL4iG13719@sarajevo.idealx.com>; from MAILER-DAEMON@sarajevo.idealx.com on Wed, Feb 28, 2001 at 10:05:00PM +0100 References: <200102282105.f1SL4iG13719@sarajevo.idealx.com> Message-ID: <20010228220851.B8074@IDEALX.com> On Wed, Feb 28, 2001 at 09:27:26PM +0100, Vlad Dumitrescu wrote: > Hi all! > > I was reading again through the Erlang book, and got to the OS chapter. And > I started wondering... what if there was an ErlangOS? Since a few weeks now, I was considering something like this too. I think one first step could be to build, on top of a classical GNU/Linux distribution, specific services that would replace existing one. Namely, I'm thinking about inetd. This service, as you probably know, is responsible for the launch of TCP services corresponding to specific ports, and with some security checks. For example, when someone connects to port 80, inetd launches a httpd process after having checked the rights of the client. Ok, that's not the best example, since Apache is most oftently used as standalone ;-)... but you get the point. So now I wondered if we could replace inetd by an Erlang written one. But this one would launch Erlang processes instead of binary programs. Some typical services do have prototypes, like Inets for httpd if i'm not mistaken. One specific feature of this Erlang version could be distribution of the processes, with load balancing, but that has to be more deeply considered. In fact i was thinking of reusing Eddie as a base for this Erlang INetd. Mickael Remond and I did start to write a IRC bot in Erlang (manderlbot.sourceforge.net). We were aiming to write a minimal IRC server within this project too, first as a proxy, but then of course as a real IRC server. This could be a second INetD services ;-) The only point that makes me hesitate is performance. But i'm still not familiar enough with this domain to speak of it. Ok i'll stop here my dream for the moment. I have begun to write an article for the new-born erlang-fr.org website, with english translation simultaneously, but i've still work to do on it. So i'd better get back to it... Best regards to you all :-) -- Thierry Mallard | GnuPG key on wwwkeys.pgp.net | key 0xA3D021CB | http://thierry.mallard.com | From spearce@REDACTED Wed Feb 28 22:30:07 2001 From: spearce@REDACTED (Shawn Pearce) Date: Wed, 28 Feb 2001 16:30:07 -0500 Subject: Protocol Mixup in JInterface from R7B-0 Message-ID: <20010228163007.V12184@spearce.org> Ok, I realize that between release of the OTP distribution that there may be some issues with protocol changes that may make them not able to communicate with each other, but one would think that R7B-0's JInterface could speak to R7B-0's ERTS. But.... In OtpOutputStream.java at line 421 and 424 the method write_long uses writeBE to send the long value. (As a smallBig on the wire, whatever that is.) This causes the following behavior to show up. I'm sending the value 0x08000000. (Bit 27 is the only bit set.) Erlang to Java -> Erlang: 134217728 Java: 134217728 Java to Erlang -> Java: 134217728 Erlang: 8 Clearly this is wrong. I ran a whole set of test cases with various values in the upper 5 bits of the Java field and every time what I saw in Erlang was the value bit shifted right 24 bits. I changed the calls at lines 421 and 424 to writeLE and rebuilt my entire erlang installation. Now I see the proper behavior: Java to Erlang -> Java: 134217728 Erlang: 134217728 Better: Java: 983394991 Erlang: 983394991 Has this error been fixed in subsequent releases?? This is our 3rd patch to JInterface (the others are the famous acceptor null pointer fix and the patches I posted earlier with the hash functions implemented for the OtpErlang objects which were missing them). Patch file is attached for those interested. -- Shawn. ``If this had been a real life, you would have received instructions on where to go and what to do.'' -------------- next part -------------- *** otp_src_R7B-0.orig/lib/jinterface/java_src/com/ericsson/otp/erlang/OtpOutputStream.java Tue Aug 22 08:02:25 2000 --- otp_src_R7B-0/lib/jinterface/java_src/com/ericsson/otp/erlang/OtpOutputStream.java Wed Feb 28 16:06:58 2001 *************** *** 415,429 **** this.write1(OtpExternal.smallBigTag); this.write1(4); // length if (l < 0) { this.write1(1); // sign ! this.write4BE(-l); // value } else { this.write1(0); // sign ! this.write4BE(l); //value } } } /** --- 415,429 ---- this.write1(OtpExternal.smallBigTag); this.write1(4); // length if (l < 0) { this.write1(1); // sign ! this.write4LE(-l); // value } else { this.write1(0); // sign ! this.write4LE(l); //value } } } /**