From jay@REDACTED Wed Oct 1 08:31:41 2003 From: jay@REDACTED (Jay Nelson) Date: Tue, 30 Sep 2003 23:31:41 -0700 Subject: One Million Processes Message-ID: <4.2.2.20030930232719.00d2c870@duomark.com> Vance Shipley wrote: > I'm soliciting suggestions on an application to create. I am building a similar thing using an OpenBSD firewall running pf to load balance across multiple nodes. The application is a game server and it will create a process for each move, chat sent, ad or other transaction. The whole game will be distributed so that each new request or interaction can occur on any of the backend machines. Another application is to have a realtime quote feed that handles each stock or commodity symbol as a separate process. Losing one symbol should not affect any of the other quotes maintained or the analytics computed on the quotes. jay From joachim.durchholz@REDACTED Wed Oct 1 08:41:36 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Wed, 01 Oct 2003 08:41:36 +0200 Subject: new syntax - a provocation In-Reply-To: References: <200309260019.h8Q0JCtF280244@atlas.otago.ac.nz> <3F78A4F9.6090203@web.de> Message-ID: <3F7A7720.2040807@web.de> Luke Gorrie wrote: [On moving processes across nodes] > The tricky part seems to be moving the identity. Is there a simple way > to do this that would be generally useful? Basically, the processes need an identity that's independent of the node they are running on. One could do this statistically (generate a random 128-bit string for each process and assume that a collision is less probable than any combination of hardware failures that would produce a collision as well). Or the current id could include the node id and a serial number, but indicating nothing more than "place of birth"; the message handling code would keep a table that indicated which process id lives on what node. This is a bit complicated because such a table would have to be updated lazily (to avoid O(N*M) overhead for N nodes and M processes, which is generally O(N^2); making it lazy reduces the overhead to O(C log C), where C is the number of connections actually made). > If not, I'm more inclined > to just write some code to kill the process on one node and start the > new one on the other by hand. The interesting part is how to tell all the clients of the original process where the new process lives. Other than that, I think restarting the process in the new location is probably easier. Another issue would be long-running processes. Stuff that doesn't fit the Erlang model of "each server processes no more than a small chunk of work with every message". Say, a day-long weather forecast that may have to move to another server to avoid imminent shutdown, or similar stuff. Another perspective: In Erlang, the programmer is urged to divide the task into small subtasks. The approach of migrating the entire process state allows programmers to keep the large monolithic tasks, opening up another niche of design space. In other words: I don't think that this is very useful for Erlang in its current state, and it's not likely that this will ever change, but it's an interesting and useful idea in other contexts. Just my 2c. Regards, Jo From rvg@REDACTED Wed Oct 1 08:54:24 2003 From: rvg@REDACTED (Rudolph van Graan) Date: Wed, 1 Oct 2003 08:54:24 +0200 Subject: One Million Processes In-Reply-To: <20030930190312.GR70644@frogman.motivity.ca> Message-ID: <1797027E-F3DC-11D7-B613-000A956D87EE@ifoni.com> Hi Vance, One idea I have toying with for a while has been a highway ["road"] simulator. The concept is to model each car on the road as a separate process which interacts with the few cars around it according to set rules. For example: 1. If the car in front breaks, you must break 2. The driver has a reaction time 3. Cars can change lanes etc etc The goal is to determine how specific incidents influence the general flow [an accident or someone driving slow in the fast lane] etc. I am sure one can model this mathematically, but I wanted to have something that is based on a real model and that can be used to understand why gridlocks occur and what triggers them. I've noticed several patterns in traffic flow and would like to test these ideas. One of these is the concept of a memory effect. An accident, even after being cleared up, causes a slowdown in the general area where it occurred for hours at a time, even if there is no actual cause left. I think erlang is a good tool for the job, as it will allow you to model each car independently and it suits the massive concurrency model quite well. Ideas? Rgds, Rudolph On Tuesday, Sep 30, 2003, at 21:03 Africa/Johannesburg, Vance Shipley wrote: > > I would like to put together an application for the > sole purpose of achieving one million processes doing > something productive. With current limits on the number > of processes which a node can support this will require > several nodes. > > I am building a platform to host a number of Sun CP1500 > Sparc boards in a single chassis. I'll have at least a > half a dozen available. These will all be independent, > diskless clients. I would like to also keep the distributed > system it comprises up and running continuosly. Forever. > > I'm soliciting suggestions on an application to create. > The goal is to demonstrate massive concurrency. One thing > I played around with this year was implementing the digraph > module with every vertice as a process. It becomes a living > database. Another obvious choice is the game of life. I'd > prefer something a little more impressive though. > > If anyone has any other interesting things they could do with > an Erlang/OTP cluster I can make it available. > > -Vance From joachim.durchholz@REDACTED Wed Oct 1 09:00:23 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Wed, 01 Oct 2003 09:00:23 +0200 Subject: One Million Processes In-Reply-To: <20030930190312.GR70644@frogman.motivity.ca> References: <20030930190312.GR70644@frogman.motivity.ca> Message-ID: <3F7A7B87.5030003@web.de> Vance Shipley wrote: > I would like to put together an application for the sole purpose of > achieving one million processes doing something productive. Anything client-server with many clients will do. Say, internet shops, or internet games. Or distributed processing ? la Seti@REDACTED Actually Seti@REDACTED would be a good demonstration of Erlang's capabilities, as it had to deal with several code upgrades during its lifetime. Unfortunately, it might also demonstrate lack of capabilities. Seti@REDACTED suffered from code manipulation, which was handled by an ad-hoc solution (everything was computed twice, the results compared, and all suspicious work redone). It did handle gracefully cases with temporary Internet connections (it would just wait until one was available); I'm not sure how well Erlang's message system could cope with that, but I don't think it's built for this scenario. > I would like to also keep the distributed system it comprises up and > running continuosly. Forever. Well, in this scenario, it's just the server(s) that run(s) continuously. But it could be an interesting demonstration to display Erlang's failover capabilities. > With current limits on the number of processes which a node can > support this will require several nodes. The client/server scenario has very little process counts per node, so this is not a problem. However, current limits on the node count may affect the system similarly. (More precisely: every node needs at least one atom, and the atom table is limited in size and not garbage collected.) This doesn't exactly fit your description, partly because it's not quite the right idea, partly due to implementation restrictions. Regards, Jo From vlad_dumitrescu@REDACTED Wed Oct 1 10:14:05 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 1 Oct 2003 10:14:05 +0200 Subject: Improving Web Services Message-ID: I read a small note in a paper the other day, and it was so funny... Quoting from memory: It seems that some people are not very pleased with performance of Web Services, and Sun (I think) has a research team that works on replacing XML with a binary format for the data. "This will improve performance" says one spokesperson. Now, really - how long has it been since the first voices were raised against XMLs extreme verbosity for this kind of use? My guess is that those who promoted XML thought that "hey, we do it this way first, then we have something to improve and we'll have jobs a couple of more years!" /Vlad From joe@REDACTED Wed Oct 1 12:22:55 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 1 Oct 2003 12:22:55 +0200 (CEST) Subject: One Million Processes In-Reply-To: <20030930190312.GR70644@frogman.motivity.ca> Message-ID: > If anyone has any other interesting things they could do with > an Erlang/OTP cluster I can make it available. > - a massive IRC/chat/instant messaging application - a chord simulation (peer-to-peer hash lookup) /Joe > -Vance > From jay@REDACTED Wed Oct 1 15:20:48 2003 From: jay@REDACTED (Jay Nelson) Date: Wed, 01 Oct 2003 06:20:48 -0700 Subject: One Million Processes Message-ID: <4.2.2.20031001061732.00d1eb10@duomark.com> A document summarizer that utilizes search engine results to get a list of documents. It then retrieves all the documents and analyzes each one in a separate process. This could be augmented by allowing peers to join the process space temporarily to distribute the bandwidth requirements. The user would not have to deal with 404s and could see the relevant summary (as well as skipping documents where the content has changed since they were indexed). jay From thomas.arts@REDACTED Wed Oct 1 16:03:08 2003 From: thomas.arts@REDACTED (Thomas Arts) Date: Wed, 1 Oct 2003 16:03:08 +0200 Subject: ASN.1 specification and protocol stack Message-ID: <00bf01c38824$be3dfec0$a22d1081@ituniv398> Could anyone point me to a relatively small ASN.1 specification of a protocol together with the accompanying protocol stack? We are looking into testing tools and would like to have a case study to see how well the testing performs. Thanks Thomas --- Dr Thomas Arts Program Manager Software Engineering and Management IT-university in Gothenburg Box 8718, 402 75 Gothenburg, Sweden http://www.ituniv.se/ Tel +46 31 772 6031 Fax +46 31 772 4899 From garry@REDACTED Wed Oct 1 17:03:30 2003 From: garry@REDACTED (Garry Hodgson) Date: Wed, 1 Oct 2003 11:03:30 -0400 (EDT) Subject: One Million Processes In-Reply-To: <20030930190312.GR70644@frogman.motivity.ca> References: <20030930190312.GR70644@frogman.motivity.ca> Message-ID: <2003100111041065020643@k2.sage.att.com> Vance Shipley wrote: > I'm soliciting suggestions on an application to create. > The goal is to demonstrate massive concurrency. you could make each process simulate a monkey hitting the keys on a typewriter. then have other processes analyzing the results, so they can notify you when they've completed the works of shakespeare. sorry, i couldn't resist. ---- Garry Hodgson, Technology Consultant, AT&T Labs Be happy for this moment. This moment is your life. From garry@REDACTED Wed Oct 1 22:24:58 2003 From: garry@REDACTED (Garry Hodgson) Date: Wed, 1 Oct 2003 16:24:58 -0400 (EDT) Subject: One Million Processes In-Reply-To: <20030930190312.GR70644@frogman.motivity.ca> References: <20030930190312.GR70644@frogman.motivity.ca> Message-ID: <2003100116251065039932@k2.sage.att.com> Vance Shipley wrote: > > I would like to put together an application for the > sole purpose of achieving one million processes doing > something productive. oh...productive, he says. > If anyone has any other interesting things they could do with > an Erlang/OTP cluster I can make it available. what if one were, say, in the business of running a large IP network? and you wanted to be able to generate a reasonably up to date picture of what it looked like, and how that changed over time. could you build something that would fan out over ip or domain or some other intersting space and determine relationships, or watch for changes, or explore it in other ways that would contribute to the overall picture "back home"? now, that wouild be cool. ---- Garry Hodgson, Technology Consultant, AT&T Labs Be happy for this moment. This moment is your life. From ok@REDACTED Thu Oct 2 05:27:55 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 2 Oct 2003 15:27:55 +1200 (NZST) Subject: Improving Web Services Message-ID: <200310020327.h923RtWt143611@atlas.otago.ac.nz> "Vlad Dumitrescu" wrote: It seems that some people are not very pleased with performance of Web Services, and Sun (I think) has a research team that works on replacing XML with a binary format for the data. "This will improve performance" says one spokesperson. Now, really - how long has it been since the first voices were raised against XMLs extreme verbosity for this kind of use? Since XML was first described. (For at least a year I thought XML-RPC was a joke cooked up by a student; I couldn't believe that anybody might intend something like that seriously.) I'm also having a bit of trouble believing a proposal for an XML encoding of the ODMG Object Interchange Format; you can compress that by about a factor of 2 while still staying in XML. There's a reason why WAP uses a compression scheme for sending WML pages. In fairness to XML, it compresses quite nicely. XMill works quite well. From joe@REDACTED Thu Oct 2 17:02:56 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 2 Oct 2003 17:02:56 +0200 (CEST) Subject: Announce: Client server tutorial Message-ID: I have written a client-server tutorial, its at: http://www.sics.se/~joe/tutorials/client_server/client_server.html Properties Client in Erlang Server in C Sockets Parallel server (ie I fork of one process per session) /Joe From peter@REDACTED Thu Oct 2 18:08:14 2003 From: peter@REDACTED (Peter Lund) Date: Thu, 2 Oct 2003 17:08:14 +0100 (BST) Subject: io:format works poorly with Red Hat 9 Message-ID: <53220.149.254.120.136.1065110894.squirrel@www.lundata.se> Hi, I am experience problems when running the latest Erlang/OTP on the latest Redhat. When running in stand alone mode starting with: ../bin/run_erl -daemon /tmp/myApp ... and then connecting with: ../bin/to_erl /tmp/myApp I run a function that results in many io:format/2 printouts (between 50 and 500 lines are printed). Sometimes it works ok, but sometimes the to_erl is disconnected from the erlang node, in the middle of the printout, just as if I had pressed ctrl-d. The longer the printout is the higher the probability seems to be that it fails. Chandru told me that he had seen the same problem before on an older combination of Redhat and Erlang/OTP. So the below table is the failing observations we have made. Linux Kernel Erlang/OTP 2.4.20-8 R9C-0 (Redhat9) 2.4.7-10 R8B-0 Does anyone know why this is happening? Redhat seems to me too important for us to ignore... Peter Lund From vances@REDACTED Thu Oct 2 23:27:41 2003 From: vances@REDACTED (Vance Shipley) Date: Thu, 2 Oct 2003 17:27:41 -0400 Subject: io:format works poorly with Red Hat 9 In-Reply-To: <53220.149.254.120.136.1065110894.squirrel@www.lundata.se> References: <53220.149.254.120.136.1065110894.squirrel@www.lundata.se> Message-ID: <20031002212741.GM78960@frogman.motivity.ca> Peter, This has always been this way on all platforms I have used. I use to_erl daily and I know, I'm quite used to it. I have always assumed that "the pipe filled up". I'm sure there is a solution but it never bothered me enough to look into it. -Vance On Thu, Oct 02, 2003 at 05:08:14PM +0100, Peter Lund wrote: } } Sometimes it works ok, but sometimes the to_erl is disconnected from } the erlang node, in the middle of the printout, just as if I had } pressed ctrl-d. The longer the printout is the higher the probability } seems to be that it fails. From jonathan@REDACTED Fri Oct 3 00:03:12 2003 From: jonathan@REDACTED (jonathan@REDACTED) Date: Thu, 02 Oct 2003 23:03:12 +0100 Subject: Announce: Client server tutorial In-Reply-To: Message-ID: <3F7CAEB0.8100.2F84D5@localhost> On 2 Oct 2003 at 17:02, Joe Armstrong wrote: Am I missing something? Wouldn't it have made more sense to the server in Erlang and client in C? Or are things done this to demonstrate some particular techniques that you wanted to show? - Jonathan Coupe > > I have written a client-server tutorial, its at: > > http://www.sics.se/~joe/tutorials/client_server/client_server.html > > Properties > Client in Erlang > Server in C > Sockets > Parallel server (ie I fork of one process per session) > > /Joe > > > > > > From ok@REDACTED Fri Oct 3 04:32:18 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 3 Oct 2003 14:32:18 +1200 (NZST) Subject: Opaque types Message-ID: <200310030232.h932WINo153322@atlas.otago.ac.nz> Pattern matching for abstract data types is precisely what my "Abstract Patterns" paper was about. Abstract patterns are almost the same as the "views" that have been proposed for Haskell, but "abstract pattern" is a rather clearer name. From ok@REDACTED Fri Oct 3 05:02:19 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 3 Oct 2003 15:02:19 +1200 (NZST) Subject: new syntax - a provocation Message-ID: <200310030302.h9332Jmt073866@atlas.otago.ac.nz> I wrote: It's interesting to consider the question: "what would an Erlang implementation have to be like for us to be able to take a running process and move it to another processor?" (IBM's AIX was able to do this on their mainframes, I believe. I think Kali Scheme can do it. I should also have mentioned the University of Washington "Emerald" system/language. Luke Gorrie asked: And also the question: why would you want to? Seriously. Surely the answer is obvious? To reduce *total* communication costs. Suppose you have two processes X and Y, and two machines A and B. Process X is running on A and Y is running on B. Now process X discovers that it is going to communicate *lots* with Y for a while. So X moves over the machine B, has a nice long chat with Y, and then moves back to A. Depending on exactly what the situation is, it may be possible for X to spawn a process Z on B, send it some background information, wait for Z to chat with Y, and then read Z's suicide note. It's nice to have a single language mechanism (move process to node) instead of relying on a different ad hoc solution for each of many programs. Erlang shouldn't have any extra problem with moving code over; if you are going to do spawn(M, F, [E1,...,En], Node) then you had _better_ be perfectly sure what Node thinks M means anyway. However, I wasn't suggesting that Erlang *SHOULD* be made to suppose between-node process migration, only that it's worth *thinking* about what it would take to do that. From tony@REDACTED Fri Oct 3 09:15:48 2003 From: tony@REDACTED (Tony Rogvall) Date: 03 Oct 2003 09:15:48 +0200 Subject: new syntax - a provocation In-Reply-To: <200310030302.h9332Jmt073866@atlas.otago.ac.nz> References: <200310030302.h9332Jmt073866@atlas.otago.ac.nz> Message-ID: <1065165347.1804.32.camel@bit.hemma.se> On Fri, 2003-10-03 at 05:02, Richard A. O'Keefe wrote: > I wrote: > It's interesting to consider the question: "what would an Erlang > implementation have to be like for us to be able to take a running > process and move it to another processor?" (IBM's AIX was able to > do this on their mainframes, I believe. I think Kali Scheme can do it. > > I should also have mentioned the University of Washington "Emerald" > system/language. > > Luke Gorrie asked: > > And also the question: why would you want to? Seriously. > > Surely the answer is obvious? To reduce *total* communication costs. > Suppose you have two processes X and Y, and two machines A and B. > Process X is running on A and Y is running on B. > Hi! The reason why "we" never did implement moving of processes was that it is not a "easy" in the general case. Just implementing the "move" is nearly trivial. Dump the stack/heap code and send it away, not the issue I think. 1. Normally when you want to move the process it is to late. system has crashed. 2. You may want to move before the crash, but then you want to move the resources with you i.e keep links / ports (files/sockets/drivers). Otherwise you need to restart all the resources on the new location. 3. Suppose 1 and 2 does not apply, we still want the process and keep the old identity. This means that some pid translation table must be implemented, notifications are sent to the systems connected to the system that hold the moved process. If the process own some resources that we not want to move, then some proxy must be installed in place of the process moved to keep the resources running. etc etc etc. (It have not even started think about supervisor trees :-) Why not just have a gen_server, then you pass the state in a spawn call and let the application handle the problems with accessing/moving external resources. PROBLEM SOLVED. -- Tony Rogvall -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 307 bytes Desc: This is a digitally signed message part URL: From erlang@REDACTED Fri Oct 3 10:04:59 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 03 Oct 2003 09:04:59 +0100 Subject: Announce: Client server tutorial In-Reply-To: <3F7CAEB0.8100.2F84D5@localhost> References: <3F7CAEB0.8100.2F84D5@localhost> Message-ID: <3F7D2DAB.5020500@manderp.freeserve.co.uk> Hi Jonathan, hi Joe, I think the tutorial is spot on in cases where the C server may be, for example a UDP packet generator, or some code interfacing with Linux iptables to build a media gateway. I've implemented such things, and I'll probably be taking notes and applying the principles in the tutorial while I re-engineer these components. Comparing what I've done with Joe's usually terse and precise implementation will be very instructive. Thanks Joe. I owe you even more beers! I'm not sure I will ever visit Sweden, and I don't know if you'll ever visit London, but rest assured you'll never go thirsty on my account! Pete. jonathan@REDACTED wrote: > On 2 Oct 2003 at 17:02, Joe Armstrong wrote: > > Am I missing something? Wouldn't it have made more sense to the > server in Erlang and client in C? Or are things done this to > demonstrate some particular techniques that you wanted to show? > > - Jonathan Coupe > > >>I have written a client-server tutorial, its at: >> >> http://www.sics.se/~joe/tutorials/client_server/client_server.html >> >> Properties >> Client in Erlang >> Server in C >> Sockets >> Parallel server (ie I fork of one process per session) >> >> /Joe >> >> >> >> >> >> > > > > > From joachim.durchholz@REDACTED Fri Oct 3 11:06:38 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Fri, 03 Oct 2003 11:06:38 +0200 Subject: Opaque types In-Reply-To: <200310030232.h932WINo153322@atlas.otago.ac.nz> References: <200310030232.h932WINo153322@atlas.otago.ac.nz> Message-ID: <3F7D3C1E.8080900@web.de> Richard A. O'Keefe wrote: > Pattern matching for abstract data types is precisely what my > "Abstract Patterns" paper was about. Abstract patterns are almost > the same as the "views" that have been proposed for Haskell, but > "abstract pattern" is a rather clearer name. The first thing a programmer will think about when confronted with this term is the Abstract Factory Pattern, a wildly unrelated concept. Personally, I'd name the entire concept "user-defined pattern matching" or something similar, and use terms like "view" or "abstract data type pattern" only when describing concrete mechanisms. Regards, Jo From sean.hinde@REDACTED Fri Oct 3 13:57:30 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Fri, 3 Oct 2003 12:57:30 +0100 Subject: Edoc thoughts Message-ID: Fellow Documentation Generators, We have a new found requirement to generate a goodly thud of internal documentation for each of our new systems. Hence I have developed a great enthusiasm for tools which can deliver said volume for minimum effort. First efforts using edoc are quite promising, but have generated a couple of small troubles within: 1. I would like to do something like: @spec read_customer(Msisdn::string(), Operator::atom()) -> {ok, Number::string(), Services::services()} | not_likely But edoc doesn't seem to like the notation Number::string() in a result. I am forced to have one or the other - Number or string(). Is there some strong reason for this and is it easy to change? 2. It would be nice to have a global @type area, as well as local @types which appear together with the @spec for the function. 3. This last could probably be an exercise for the reader (or writer?) but an edoc:directory(string()) or even edoc:application(Otp_app::atom()) mechanism to do all files and generate an overview page would be the icing on the cake for this excellent time saver. Richard C or anyone else? Thanks, Sean From richardc@REDACTED Fri Oct 3 14:49:51 2003 From: richardc@REDACTED (Richard Carlsson) Date: Fri, 3 Oct 2003 14:49:51 +0200 (MET DST) Subject: Edoc thoughts In-Reply-To: References: Message-ID: Hello, Sean. I'd like to start by saying that I've been working on a new release of edoc, with major internal restructuring and many improvements, and I hope to release it in a not too distant future. (I know I've been saying this for a while now...) On Fri, 3 Oct 2003, Sean Hinde wrote: > First efforts using edoc are quite promising, but have generated a > couple of small troubles within: > > 1. I would like to do something like: > > @spec read_customer(Msisdn::string(), Operator::atom()) -> > {ok, Number::string(), Services::services()} | not_likely > > But edoc doesn't seem to like the notation Number::string() in a > result. I am forced to have one or the other - Number or string(). Is > there some strong reason for this and is it easy to change? It's part of the design. The right-hand side (following the '->') already _is_ a type expression, and allowing "local type constraints" such as 'Number::string()' in your example would make it possible to actually come up with an inconsistent declaration, where you also claim that the _type_variable_ 'Number' also stands for e.g. 'integer()'. To clarify this: - The things to the left of the '::' are the _parameter_names_, which you use for talking about the parameters (instead of having to say "the second parameter", you can just say "Operator"). - The things to the right of the '::', and the thing that follows the '->' are _types_. In addition, you can list further local definitions. Your example can be written: % @spec read_customer(Msisdn::string(), Operator::atom()) -> % {ok, Number, Services} | not_likely % Number = string() % Services = services() (which actually makes it easier to see the format of the returned values). You could also lift out all types, like this: % @spec read_customer(Msisdn::Msisdn, Operator::Operator) -> % {ok, Number, Services} | not_likely % Msisdn = string() % Operator = atom() % Number = string() % Services = services() (note the difference between the lhs parameter name Msisdn, and the rhs type variable Msisdn). However, since this is a common idiom, we allow the following as short-hand: % @spec read_customer(Msisdn, Operator) -> % {ok, Number, Services} | not_likely % Msisdn = string() % Operator = atom() % Number = string() % Services = services() meaning that the parameter called Msisdn has type Msisdn, and the parameter called Operator has type Operator. (The same name is simply being used in two distinct name spaces, but it is practical to let the context decide which one you mean.) Whether or not to use '::' to specify directly for a parameter what type it has, or to put it in a separate definition, is just a question of which version becomes more readable. When parameters are few, the '::' works fine, but with many parameters it can get messy. > 2. It would be nice to have a global @type area, as well as local > @types which appear together with the @spec for the function. Semi-local types, just used in one or a few related functions, can be defined using the above notation, as in: % @spec foo(Input::thingy()) -> thingy() % thingy() = string() | atom() ... % @spec bar(X::thingy()) -> {ok, thingy()} | error and they will be listed where they are defined. The type name is still global for the module, though. (This only works for alias types. Really abstract types have to be defined using the @type tag.) If the type is only used in a single function (but in several places), it is better to just use a type variable (these are local for the function), instead of the "datatype()" named-type notation, as in: % @spec foo(Input::Thing) -> Thing % Thing = string() | atom() > 3. This last could probably be an exercise for the reader (or writer?) > but an edoc:directory(string()) or even > edoc:application(Otp_app::atom()) mechanism to do all files and > generate an overview page would be the icing on the cake for this > excellent time saver. I'm working on it. :-) /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From crav@REDACTED Fri Oct 3 11:01:24 2003 From: crav@REDACTED (=?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=) Date: Fri, 3 Oct 2003 10:01:24 +0100 Subject: ConnHandle Message-ID: <001801c3898c$ec2d62d0$6600a8c0@carlos> IT'S NECESSARY TO CREATE A NEW ConnHandle FOR EACH TRANSACCTION?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.hinde@REDACTED Fri Oct 3 14:57:53 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Fri, 3 Oct 2003 13:57:53 +0100 Subject: Edoc thoughts In-Reply-To: Message-ID: <339CCCF0-F5A1-11D7-91E6-000A95927CCE@mac.com> On Friday, October 3, 2003, at 01:49 pm, Richard Carlsson wrote: > > Hello, Sean. I'd like to start by saying that I've been working on a > new release of edoc, with major internal restructuring and many > improvements, and I hope to release it in a not too distant future. > (I know I've been saying this for a while now...) This is great news. Need a beta tester? > - The things to the right of the '::', and the thing that follows the > '->' are _types_. In addition, you can list further local definitions. > Your example can be written: > > % @spec read_customer(Msisdn::string(), Operator::atom()) -> > % {ok, Number, Services} | not_likely > % Number = string() > % Services = services() Yes, this was actually in the documentation.. The additional explanation is most welcome though. >> 3. This last could probably be an exercise for the reader (or writer?) >> but an edoc:directory(string()) or even >> edoc:application(Otp_app::atom()) mechanism to do all files and >> generate an overview page would be the icing on the cake for this >> excellent time saver. > > I'm working on it. :-) Splendid, can't wait! Cheers, Sean From joe@REDACTED Fri Oct 3 16:35:40 2003 From: joe@REDACTED (Joe Armstrong) Date: Fri, 3 Oct 2003 16:35:40 +0200 (CEST) Subject: Announce: Client server tutorial In-Reply-To: <3F7CAEB0.8100.2F84D5@localhost> Message-ID: On Thu, 2 Oct 2003 jonathan@REDACTED wrote: > On 2 Oct 2003 at 17:02, Joe Armstrong wrote: > > Am I missing something? Wouldn't it have made more sense to the > server in Erlang and client in C? Or are things done this to > demonstrate some particular techniques that you wanted to show? Writing a Server in Erlang and client in C borders on the trivial (apart from the fact that *nothing* in C is trivial :-) I find I *often* have to write servers in C since it's difficult to get Erlang to do really low-level things ... /Joe > > - Jonathan Coupe > > > > > I have written a client-server tutorial, its at: > > > > http://www.sics.se/~joe/tutorials/client_server/client_server.html > > > > Properties > > Client in Erlang > > Server in C > > Sockets > > Parallel server (ie I fork of one process per session) > > > > /Joe > > > > > > > > > > > > > > From joe@REDACTED Fri Oct 3 16:52:39 2003 From: joe@REDACTED (Joe Armstrong) Date: Fri, 3 Oct 2003 16:52:39 +0200 (CEST) Subject: Announce: Client server tutorial In-Reply-To: <3F7D2DAB.5020500@manderp.freeserve.co.uk> Message-ID: Why I wrote this was because I wanted a low level IP interface, and needed a simple way of writing a bridge between a high level protocol (like TCP) and a much lower level where I can send and receive IP packets directly - and that you can't do in Erlang :-( /Joe On Fri, 3 Oct 2003, Peter-Henry Mander wrote: > Hi Jonathan, hi Joe, > > I think the tutorial is spot on in cases where the C server may be, for > example a UDP packet generator, or some code interfacing with Linux > iptables to build a media gateway. I've implemented such things, and > I'll probably be taking notes and applying the principles in the > tutorial while I re-engineer these components. Comparing what I've done > with Joe's usually terse and precise implementation will be very > instructive. > > Thanks Joe. I owe you even more beers! I'm not sure I will ever visit > Sweden, and I don't know if you'll ever visit London, but rest assured > you'll never go thirsty on my account! > > Pete. > > jonathan@REDACTED wrote: > > On 2 Oct 2003 at 17:02, Joe Armstrong wrote: > > > > Am I missing something? Wouldn't it have made more sense to the > > server in Erlang and client in C? Or are things done this to > > demonstrate some particular techniques that you wanted to show? > > > > - Jonathan Coupe > > > > > >>I have written a client-server tutorial, its at: > >> > >> http://www.sics.se/~joe/tutorials/client_server/client_server.html > >> > >> Properties > >> Client in Erlang > >> Server in C > >> Sockets > >> Parallel server (ie I fork of one process per session) > >> > >> /Joe > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > From vances@REDACTED Fri Oct 3 17:13:31 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 3 Oct 2003 11:13:31 -0400 Subject: Announce: Client server tutorial In-Reply-To: References: <3F7CAEB0.8100.2F84D5@localhost> Message-ID: <20031003151331.GT78960@frogman.motivity.ca> I've written some cnodes lately which act like gen_servers. They understand the protocol so you can do: Reply = gen_server:call({cnode_name, 'cnode_name@REDACTED'}, Request) Why? Just 'cause it amused me at the time. -Vance From mlogan@REDACTED Fri Oct 3 20:27:34 2003 From: mlogan@REDACTED (Martin J. Logan) Date: 03 Oct 2003 13:27:34 -0500 Subject: ConnHandle In-Reply-To: <001801c3898c$ec2d62d0$6600a8c0@carlos> References: <001801c3898c$ec2d62d0$6600a8c0@carlos> Message-ID: <1065205653.30026.140.camel@dhcp-lom-194-186.futuresource.com> Eh??? Connection handle for what transaction?? On Fri, 2003-10-03 at 04:01, Carlos Rodr?guez Alcal? Villagra wrote: > IT'S NECESSARY TO CREATE A NEW ConnHandle FOR EACH TRANSACCTION?? From mwilligs@REDACTED Fri Oct 3 21:45:46 2003 From: mwilligs@REDACTED (Miguel Willigs) Date: Fri, 3 Oct 2003 16:45:46 -0300 (PYST) Subject: megaco_test_mg and megaco_test_mgc Message-ID: <3955.65.198.40.11.1065210346.squirrel@unimail.uninet.com.py> Hi there. I found two examples files in the erlang instalation: megaco_test_mg.erl and megaco_test_mgc.erl. My question is: How do I run these examples? Is there any documentation about these examples? Thanks in advance From vances@REDACTED Sat Oct 4 02:37:20 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 3 Oct 2003 20:37:20 -0400 Subject: gen_server:cast/2 vs ! Message-ID: <20031004003720.GV78960@frogman.motivity.ca> Today I am wondering why I would make an interface to a process with gen_server behaviour use gen_server:cast/2 to send it's asynchronous messages. Why not just ! AsynchMessage? Is it so wrong to have a gen_server process use handle_info for lots of things? The gen_servers and gen_fsms which communicate with my cnodes pretty much have to unless I put a proxy in. What will I gain from the cast function? -Vance From sean.hinde@REDACTED Sat Oct 4 03:24:56 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Sat, 4 Oct 2003 02:24:56 +0100 Subject: gen_server:cast/2 vs ! In-Reply-To: <20031004003720.GV78960@frogman.motivity.ca> Message-ID: <9040BEBB-F609-11D7-91E6-000A95927CCE@mac.com> On Saturday, October 4, 2003, at 01:37 am, Vance Shipley wrote: > > Today I am wondering why I would make an interface to a process > with gen_server behaviour use gen_server:cast/2 to send it's > asynchronous messages. Why not just ! AsynchMessage? > > Is it so wrong to have a gen_server process use handle_info for > lots of things? The gen_servers and gen_fsms which communicate > with my cnodes pretty much have to unless I put a proxy in. > > What will I gain from the cast function? I like to use the convention that cast messages to this process are only sent using the API of this gen_server module: -module(my_server). -export([send_async_req/2). send_async_req(Pid, Req) -> gen_server:cast(Pid, Req). This has some major maintenance benefits: 1. It separates out API related traffic from other messages - I know where to look in the callbacks, I know that this set of messages must have arrived via the API, and I know that handle_info is dealing with a different kind of message (timers, port data etc) 2. It makes it extremely easy to track back months later to where the messages are coming from by simply grepping for the places the API is called. These maintenance advantages to me are a pretty overwhelming reason to avoid bypassing the gen_server abstraction with ! Sean From vances@REDACTED Sat Oct 4 07:36:17 2003 From: vances@REDACTED (Vance Shipley) Date: Sat, 4 Oct 2003 01:36:17 -0400 Subject: gen_server:cast/2 vs ! In-Reply-To: <9040BEBB-F609-11D7-91E6-000A95927CCE@mac.com> References: <20031004003720.GV78960@frogman.motivity.ca> <9040BEBB-F609-11D7-91E6-000A95927CCE@mac.com> Message-ID: <20031004053617.GX78960@frogman.motivity.ca> On Sat, Oct 04, 2003 at 02:24:56AM +0100, Sean Hinde wrote: } } I like to use the convention that cast messages to this process are } only sent using the API of this gen_server module: I'm wondering about more functional differences. Beyond the code maintenance aspects how will it behave differently. } -module(my_server). } -export([send_async_req/2). } } send_async_req(Pid, Req) -> } gen_server:cast(Pid, Req). How would it behave differently if you coded it as: -module(my_server). -export([send_async_req/2). send_async_req(Pid, Req) -> Pid ! Req. I'm thinking about things like SASL. There are two schools of thought with APIs. One has the underlying messages hidden behind function calls as in your example. The other makes the messages the API. In my current project I'm implementing some OSI layers in Erlang. I want to keep them independent of each other so you can reuse them and rearrange them. To do this I'm providing the "service primitives" as Erlang messages: {'N', 'UDATA', request, {CalledPartyAddress, CallingPartyAddress, QualityOfServiceParameterSet, UserData}} This has the major benefit of being already documented. If you're reading the specification you will understand what the above is and how the parameters are encoded. The API which is used between OSI layer services is a message passing one so it suits my purposes to maintain them as such rather than having a unitdata_request/4 function. Now I'm asking myself if I should have users of a service send service primitives directly or with a cast. gen_server:cast(Pid, {'N', 'UDATA', request, {CalledPartyAddress, CallingPartyAddress, QualityOfServiceParameterSet, UserData}) That's not quite as clear as: Pid ! {'N', 'UDATA', request, {CalledPartyAddress, CallingPartyAddress, QualityOfServiceParameterSet, UserData} But I can live with it if it's for a purpose. -Vance From fritchie@REDACTED Sat Oct 4 08:40:59 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Sat, 04 Oct 2003 01:40:59 -0500 Subject: essential Erlang In-Reply-To: Message of "Wed, 24 Sep 2003 20:41:09 +0200." Message-ID: <200310040640.h946exTk002239@snookles.snookles.com> >>>>> "vd" == Vlad Dumitrescu writes: vd> That's a problem for me too. I hear EDTK is a good tool, but it vd> doesn't work on Windows. I haven't tried it on Windows. Silly me. Sorry. As far as I know, there isn't a reason why EDTK couldn't be used by Windows BEAM, aside from replacing the UNIX-specific parts and replacing them with Windows equivalents. After all, the same port<->driver interface is the same. I just don't have the time to do it and the hardware & OS licenses to check that it works. Most of the driver code, both on the Erlang side and on the BEAM/C side, is boilerplate. In fact, it was so much so that I tried implementing the code generators using an XML template processor. And it worked. And it was easy to write. And it didn't suck horribly like XSLT, which could've been a similar option for implementing EDTK ... except for the fact that XSLT is IMHO an abomination. If you wanted to extract the boilerplate from EDTK and use it to create your own one-off driver or an entirely new driver generator, it's only a matter of time & typing. (And caffiene and other critical resources :-) Any Windows-specific things could probably be figured out by looking at the Windows flavor of existing drivers. Wishing he had more time to continue EDTK development.... -Scott http://www.snookles.com/erlang/edtk/ From valentin@REDACTED Sat Oct 4 10:01:09 2003 From: valentin@REDACTED (Valentin) Date: Sat, 4 Oct 2003 10:01:09 +0200 Subject: gen_server:cast/2 vs ! References: <20031004003720.GV78960@frogman.motivity.ca><9040BEBB-F609-11D7-91E6-000A95927CCE@mac.com> <20031004053617.GX78960@frogman.motivity.ca> Message-ID: <002701c38a4d$ad9ba740$01010d0a@moneymaker> > > How would it behave differently if you coded it as: > > -module(my_server). > -export([send_async_req/2). > > send_async_req(Pid, Req) -> > Pid ! Req. > How about this: The server side, construct like handle_cast( {some_pattern, A, B, C}, State ) -> ...... would handle both client requests: cast( ServerRef, Request ) as well as abcast( ServerName, Request ) This worked for me nicely in quite a few occasions. V. From bmk@REDACTED Sat Oct 4 11:57:26 2003 From: bmk@REDACTED (Micael Karlberg) Date: Sat, 4 Oct 2003 11:57:26 +0200 Subject: megaco_test_mg and megaco_test_mgc In-Reply-To: <3955.65.198.40.11.1065210346.squirrel@unimail.uninet.com.py> Message-ID: <289F3F07-F651-11D7-8FF9-003065F4233A@mac.com> Hi, They are not examples. They are part of the megaco test suite. No doc. Take a look in the Makefile in the test directory. /BMK On Friday, October 3, 2003, at 09:45 PM, Miguel Willigs wrote: > Hi there. > > I found two examples files in the erlang instalation: > megaco_test_mg.erl > and megaco_test_mgc.erl. > My question is: How do I run these examples? Is there any documentation > about these examples? > > Thanks in advance > From vances@REDACTED Sat Oct 4 16:02:29 2003 From: vances@REDACTED (Vance Shipley) Date: Sat, 4 Oct 2003 10:02:29 -0400 Subject: gen_server:cast/2 vs ! In-Reply-To: <002701c38a4d$ad9ba740$01010d0a@moneymaker> References: <20031004053617.GX78960@frogman.motivity.ca> <002701c38a4d$ad9ba740$01010d0a@moneymaker> Message-ID: <20031004140229.GA78960@frogman.motivity.ca> The cast call says it always returns ok. This is different from bang behaviour: 1> gen_server:cast(self(), foo). ok 2> self() ! foo. foo 3> gen_server:cast(pid(0,999,0), foo). ok 4> pid(0,999,0) ! foo. foo 5> gen_server:cast(bogus, foo). ok 6> bogus ! foo. =ERROR REPORT==== 4-Oct-2003::09:40:56 === Error in process <0.33.0> on node 'mapper@REDACTED' with exit value: {badarg,[{erl_eval,eval_op,3},{erl_eval,expr,5},{shell,eval_loop,2}]} ** exited: {badarg,[{erl_eval,eval_op,3}, {erl_eval,expr,5}, {shell,eval_loop,2}]} ** The latter may well be the preferable behaviour, if the registered process doesn't exist fail and let supervision restore sanity. On the other hand if you would otherwise wrap the send in a catch the cast behaviour is more desirable. -Vance From klacke@REDACTED Sat Oct 4 21:36:21 2003 From: klacke@REDACTED (Klacke) Date: Sat, 4 Oct 2003 21:36:21 +0200 Subject: yaws 1.31 Message-ID: <20031004193621.GA24817@bluetail.com> yaws 1.31 released. (http://yaws.hyber.org) This is minor bugfix release Even more redir bugs fuxed by Johan Bevemyr Runs on old erlangs (R7) (klacke) Compiles and runs nicely under win32 cygwin using native win32 erlang (klacke) Cosmetic fixes, docs update and return 403 on bad GETs by Leon Smith /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From ok@REDACTED Mon Oct 6 04:07:36 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 6 Oct 2003 15:07:36 +1300 (NZDT) Subject: new syntax - a provocation Message-ID: <200310060207.h9627a35156356@atlas.otago.ac.nz> Tony Rogvall wrote: > The reason why "we" never did implement moving of processes was that > it is not a "easy" in the general case. I don't know who "we" is in this context, and I didn't ask that question anyway. I know _that_ it isn't easy, and _why_ it isn't easy. What I suggested was _thinking_about_what_it_would_take_. No more and no less. Just _thinking_ about what it _would_ take. Not doing it. > Just implementing the "move" is nearly trivial. Dump the > stack/heap code and send it away, not the issue I think. When you are running code that has been compiled to native code it is _not_ at all trivial. In Erlang/OTP a process may point to shared objects that do not live in its heap; that means simply copying the process won't do. &c. > 1. Normally when you want to move the process it is to late. > system has crashed. The reason I gave for moving a process has NOTHING to do with crashing. It is a matter of reducing network costs, no more and no less. In fact, The Emerald system, which I cited as a good example of a system that does process migration, assumes a reliable network. One node goes down and everything goes down. There are plenty of reasons for process migration (load balancing, reducing transmission costs, access to localised resources) which have absolutely nothing whatsoever to do with crashing in any way. > 2. You may want to move before the crash, but then you want to > move the resources with you i.e keep links / ports > (files/sockets/drivers). Otherwise you need to restart all the > resources on the new location. Again, he seems to be under the impression that process migration has something to do with crashing. It doesn't. Process migration is not about crashing, ok? > 3. Suppose 1 and 2 does not apply, we still want the process and keep > the old identity. This means that some pid translation table must be > implemented, notifications are sent to the systems connected to the > system that hold the moved process. You might want to keep the old identity. Then again, you might not. It all depends. Having the same registration might do. > If the process own some resources > that we not want to move, then some proxy must be installed in place of > the process moved to keep the resources running. etc etc etc. Yes. And the systems which have implemented process migration *DO* that. > Why not just have a gen_server, then you pass the state > in a spawn call and let the application handle the problems with > accessing/moving external resources. PROBLEM SOLVED. PROBLEM NOT EVEN CLOSE TO ADDRESSED, LET ALONE SOLVED. The problem is *not* to burden the application with all that stuff. Evading a questino is not answering it! It seems that I must stress again that I am _not_ recommending that Erlang should turn into a clone of Emerald or KaliScheme or AIX, only that the question "what would it take for Erlang to support something like that" is one worth thinking about, because it leads to some interesting questions and design ideas. From matthias@REDACTED Mon Oct 6 11:34:45 2003 From: matthias@REDACTED (Matthias Lang) Date: Mon, 6 Oct 2003 11:34:45 +0200 Subject: Application under VxWorks - looking for suggestions In-Reply-To: <1064568375.1975.26.camel@xam> References: <1064568375.1975.26.camel@xam> Message-ID: <16257.14133.148126.270398@antilipe.corelatus.se> Massimo Cesaro writes: > I'm starting to cross compile Erlang for VxWorks, and I looking for tips > and hints to speed from people on the list who maybe already did > that. Last March, I was going through my HTTP logs and noticed someone who'd stumbled upon our site with this search string: "help I run VxWorks get me out of here" ;-) > I'm looking for creating a stripped down version of Erlang and OTP > (there are a lot of goodies in OTP that I don't need) in order to > minimize RAM requirements, are you trying to minimise RAM or FLASH requirements? Stripping unused modules won't save any RAM unless you're loading modules you then don't use (why?), but it will save a lot flash. We (corelatus) run Erlang on embedded hardware with no swap space. Our older systems "only" have 32Mbyte of RAM. The typical total RAM consumption of the Erlang VM running a fairly simple control application is 8Mbyte, with an OS-enforced maximum of 14Mbyte. In other words: it's quite possible to run in 16Mbyte, but having more DRAM will let you be lazier. > Given that I will only use a small subset of stdlib, is it > safe to strip down the modules I don't need? Module calls can be arbitrarily obfuscated in Erlang, e.g. you could have code like this: apply(list_to_atom(lists:reverse("gnirts")), chr, ["hello", $e]) there's no tool in the world that can untangle that. So there is no absolute safety. You can get relative safety by using the XREF tool which comes with Erlang. To make our embedded system, I wrote a script which stripped the Erlang system. The result is about 1.2Mbyte of library .beams. I didn't use SAE at all, partly because SAE was in its infancy when I did the shrinking work and partly because we have enough flash so that we don't have to worry about space that much. Matthias From luke@REDACTED Mon Oct 6 14:25:48 2003 From: luke@REDACTED (Luke Gorrie) Date: 06 Oct 2003 14:25:48 +0200 Subject: Announce: Client server tutorial In-Reply-To: References: Message-ID: Joe Armstrong writes: > Why I wrote this was because I wanted a low level IP interface, and > needed a simple way of writing a bridge between a high level protocol > (like TCP) and a much lower level where I can send and receive IP > packets directly - and that you can't do in Erlang :-( In the Jungerl there is a 'tuntap' application. It's a linked-in driver for creating virtual Linux network devices which you implement in Erlang, either at IP-level ('tun') or ethernet-level ('tap'). It works great - we've used it extensively at work. Cheers, Luke From mwilligs@REDACTED Mon Oct 6 21:07:06 2003 From: mwilligs@REDACTED (Miguel Willigs) Date: Mon, 6 Oct 2003 16:07:06 -0300 (PYST) Subject: megaco_test_mg and megaco_test_mgc In-Reply-To: <289F3F07-F651-11D7-8FF9-003065F4233A@mac.com> References: <3955.65.198.40.11.1065210346.squirrel@unimail.uninet.com.py> <289F3F07-F651-11D7-8FF9-003065F4233A@mac.com> Message-ID: <32833.65.198.40.11.1065467226.squirrel@unimail.uninet.com.py> Thank you for the answer, I have one more question: What are the parametters in the megaco_test_mgc:start() function? > Hi, > > They are not examples. They are part of the megaco test suite. > No doc. Take a look in the Makefile in the test directory. > > /BMK > > On Friday, October 3, 2003, at 09:45 PM, Miguel Willigs wrote: > >> Hi there. >> >> I found two examples files in the erlang instalation: >> megaco_test_mg.erl >> and megaco_test_mgc.erl. >> My question is: How do I run these examples? Is there any documentation >> about these examples? >> >> Thanks in advance >> > From massimo.cesaro@REDACTED Tue Oct 7 10:51:29 2003 From: massimo.cesaro@REDACTED (Massimo Cesaro) Date: 07 Oct 2003 10:51:29 +0200 Subject: Application under VxWorks - looking for suggestions In-Reply-To: <16257.14133.148126.270398@antilipe.corelatus.se> References: <1064568375.1975.26.camel@xam> <16257.14133.148126.270398@antilipe.corelatus.se> Message-ID: <1065516691.1437.54.camel@xam> On Mon, 2003-10-06 at 11:34, Matthias Lang wrote: > Massimo Cesaro writes: > > > I'm starting to cross compile Erlang for VxWorks, and I looking for tips > > and hints to speed from people on the list who maybe already did > > that. > > Last March, I was going through my HTTP logs and noticed someone who'd > stumbled upon our site with this search string: > > "help I run VxWorks get me out of here" > > ;-) Ugh! Unfortunately I cannot choose on this... > > > I'm looking for creating a stripped down version of Erlang and OTP > > (there are a lot of goodies in OTP that I don't need) in order to > > minimize RAM requirements, > > are you trying to minimise RAM or FLASH requirements? Stripping > unused modules won't save any RAM unless you're loading modules you > then don't use (why?), but it will save a lot flash. Currently I have 4 MB of Flash and 8 MB of RAM. I understand that I'll have the luxury of 16 MB of RAM, but won't hold my breath waiting for it. > > We (corelatus) run Erlang on embedded hardware with no swap space. Our > older systems "only" have 32Mbyte of RAM. The typical total RAM > consumption of the Erlang VM running a fairly simple control > application is 8Mbyte, with an OS-enforced maximum of 14Mbyte. Can you elaborate on the concept of "fairly simple control application"? My idea was to run just the Megaco stack with a pretty simple gateway application. > > In other words: it's quite possible to run in 16Mbyte, but having more > DRAM will let you be lazier. > > > Given that I will only use a small subset of stdlib, is it > > safe to strip down the modules I don't need? > > Module calls can be arbitrarily obfuscated in Erlang, e.g. you could > have code like this: > > apply(list_to_atom(lists:reverse("gnirts")), chr, ["hello", $e]) > > there's no tool in the world that can untangle that. So there is no > absolute safety. You can get relative safety by using the XREF tool > which comes with Erlang. Yes, that's what planned to do. > > To make our embedded system, I wrote a script which stripped the > Erlang system. The result is about 1.2Mbyte of library .beams. I > didn't use SAE at all, partly because SAE was in its infancy when I > did the shrinking work and partly because we have enough flash so that > we don't have to worry about space that much. I think that with 4 MB of flash we have some margins as well. I considered using SAE because it's documented and I'hoping will save time. > > Matthias Thank you for the tips! Massimo From matthias@REDACTED Tue Oct 7 11:58:17 2003 From: matthias@REDACTED (Matthias Lang) Date: Tue, 7 Oct 2003 11:58:17 +0200 Subject: Application under VxWorks - looking for suggestions In-Reply-To: <1065516691.1437.54.camel@xam> References: <1064568375.1975.26.camel@xam> <16257.14133.148126.270398@antilipe.corelatus.se> <1065516691.1437.54.camel@xam> Message-ID: <16258.36409.985964.460489@antilipe.corelatus.se> matthias> The typical total RAM consumption of the Erlang VM running a matthias> fairly simple control application is 8Mbyte, > Can you elaborate on the concept of "fairly simple control > application"? The API spec on our website (http://www.corelatus.com/gth/api/) should give you a pretty good idea of what it does. An 8M Erlang + Linux swapless system is too tight, you'd spend all your time struggling with memory use. Erlang + VxWorks may be better. There are some Ericsson groups with Erlang-on-VxWorks experience, maybe someone can comment. Otherwise, you have to experiment. Matthias From massimo.cesaro@REDACTED Tue Oct 7 13:17:01 2003 From: massimo.cesaro@REDACTED (Massimo Cesaro) Date: 07 Oct 2003 13:17:01 +0200 Subject: Date range and match specification syntax Message-ID: <1065525422.1462.66.camel@xam> Hello, I'm trying to select-ing from a mnesia table all the records inside a date range. I see that Dates are {Year, Month, Day} tuples, hence this Query = [ {'$1', [{'>=', StartDate, {element, 3, '$1'}}, {'=<', EndDate, {element, 3, '$1'}}], ['$_']}], mnesia:dirty_select(cdr, Query). will fail with a badarg because the >= operator cannot be applied on tuples (well, I think this is the resons why the shell complains). My second approach is using date_to_gregorian_days: Query = [ {'$1', [{'>=', calendar:date_to_gregorian_days(StartDate), calendar:date_to_gregorian_days({element, 3, '$1'})}], ['$_']}], mnesia:dirty_select(cdr, Query). but this fails with ** exited: {function_clause,[{calendar, date_to_gregorian_days, [element,3,'$1']}, {otr_cdr,get,2}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** Maybe I'm using a wrong approach; any suggestion on how to solve this apparently simple problem ? Massimo From dgud@REDACTED Tue Oct 7 15:04:40 2003 From: dgud@REDACTED (Dan Gudmundsson) Date: Tue, 7 Oct 2003 15:04:40 +0200 Subject: Date range and match specification syntax In-Reply-To: <1065525422.1462.66.camel@xam> References: <1065525422.1462.66.camel@xam> Message-ID: <16258.47592.813535.85538@rian.du.uab.ericsson.se> Hi Massimo Cesaro writes: > Hello, > I'm trying to select-ing from a mnesia table all the records inside a > date range. I see that Dates are {Year, Month, Day} tuples, hence this > Query = [ > {'$1', > [{'>=', StartDate, {element, 3, '$1'}}, {'=<', EndDate, > {element, 3, '$1'}}], > ['$_']}], > mnesia:dirty_select(cdr, Query). > > will fail with a badarg because the >= operator cannot be applied on > tuples (well, I think this is the resons why the shell complains). I think you need declare the variables as const {const, StartDate} and {const, EndDate} > My second approach is using date_to_gregorian_days: > Query = [ > {'$1', > [{'>=', calendar:date_to_gregorian_days(StartDate), > calendar:date_to_gregorian_days({element, 3, '$1'})}], > ['$_']}], > mnesia:dirty_select(cdr, Query). You can't do function calls inside the select expression, they are compiled and interpreted in it's own little machine.. > Maybe I'm using a wrong approach; any suggestion on how to solve this > apparently simple problem ? > > Massimo > Try to use Query = ets:fun2ms(fun(X) -> ... end) instead, slightly simpler to use :-) It generates queries which can be used with mnesia.. Also ets:test_ms/2 can help you with the debugging. /Dan "Answering without thinking or testing" -- Dan Gudmundsson Project: Mnesia, Erlang/OTP From massimo.cesaro@REDACTED Tue Oct 7 15:30:52 2003 From: massimo.cesaro@REDACTED (Massimo Cesaro) Date: 07 Oct 2003 15:30:52 +0200 Subject: Date range and match specification syntax In-Reply-To: <16258.47592.813535.85538@rian.du.uab.ericsson.se> References: <1065525422.1462.66.camel@xam> <16258.47592.813535.85538@rian.du.uab.ericsson.se> Message-ID: <1065533453.1437.74.camel@xam> Hi Dan, > > Hi > > Massimo Cesaro writes: > > Hello, > > I'm trying to select-ing from a mnesia table all the records inside a > > date range. I see that Dates are {Year, Month, Day} tuples, hence this > > Query = [ > > {'$1', > > [{'>=', StartDate, {element, 3, '$1'}}, {'=<', EndDate, > > {element, 3, '$1'}}], > > ['$_']}], > > mnesia:dirty_select(cdr, Query). > > > > will fail with a badarg because the >= operator cannot be applied on > > tuples (well, I think this is the resons why the shell complains). > > I think you need declare the variables as const > {const, StartDate} and {const, EndDate} Yes!! That was the problem. After your suggestion I doubled checked with the shell and I found that my assumption about tuples comparison was plain wrong. This way the test works: Query = [ {'$1', [{'>=', {const, StartDate}, {element, 1, '$1'}}], ['$_']}], > > > My second approach is using date_to_gregorian_days: > > Query = [ > > {'$1', > > [{'>=', calendar:date_to_gregorian_days(StartDate), > > calendar:date_to_gregorian_days({element, 3, '$1'})}], > > ['$_']}], > > mnesia:dirty_select(cdr, Query). > > You can't do function calls inside the select expression, they > are compiled and interpreted in it's own little machine.. > > > Maybe I'm using a wrong approach; any suggestion on how to solve this > > apparently simple problem ? > > > > Massimo > > > > Try to use Query = ets:fun2ms(fun(X) -> ... end) instead, > slightly simpler to use :-) You kidding, don't you ?! :-) Seriously, I'd like to see a short tutorial or more examples about it. > It generates queries which can be used with mnesia.. > > Also ets:test_ms/2 can help you with the debugging. > > /Dan "Answering without thinking or testing" > -- > Dan Gudmundsson Project: Mnesia, Erlang/OTP > Thank you for the support!!! Massimo From ulf.wiger@REDACTED Tue Oct 7 16:51:45 2003 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Tue, 7 Oct 2003 16:51:45 +0200 Subject: Date range and match specification syntax Message-ID: <76E5F712842F5F49A35738622BAA0F4F9EA761@ESEALNT442.al.sw.ericsson.se> On October 7, 2003, Massimo Cesaro wrote: >> Try to use Query = ets:fun2ms(fun(X) -> ... end) instead, >> slightly simpler to use :-) >You kidding, don't you ?! :-) >Seriously, I'd like to see a short tutorial or more examples about it. Here's a short tutorial using ets, and trying to mimic your problem (the ms_transform manual is daunting, I agree): Your match spec would look pretty much like this: fun({_,_,D}) when StartDate =< D, D =< EndDate -> object() end 1> ets:new(cdr,[set,public,named_table,{keypos,2}]). cdr 2> [ets:insert(cdr,{cdr,D,{2003,12,D}}) || D <- lists:seq(1,31)]. [true, true|...] 3> ets:tab2list(cdr). [{cdr,28,{2003,12,28}}, {cdr,27,{2003,12,27}}, {cdr,1,{2003,12,1}}, {cdr,14,{2003,12|...}}, {cdr,5,{2003|...}}, {cdr,16,{...}}, {cdr,7|...}, {cdr|...}, {...}|...] 4> StartDate = {2003,12,3}. {2003,12,3} 5> EndDate = {2003,12,17}. {2003,12,17} 6> P = ets:fun2ms(fun({_,_,D}) when StartDate =< D, D =< EndDate -> object() end). [{{'_','_','$1'}, [{'=<',{const,{2003,12,3}},'$1'},{'=<','$1',{const,{2003,12,17}}}], ['$_']}] 7> catch ets:select(cdr,P). [{cdr,10,{2003,12,10}}, {cdr,13,{2003,12,13}}, {cdr,15,{2003,12,15}}, {cdr,11,{2003,12,11}}, {cdr,3,{2003,12,3}}, {cdr,8,{2003,12,8}}, {cdr,12,{2003,12,12}}, {cdr,4,{2003,12,4}}, {cdr,14,{2003,12,14}}, {cdr,5,{2003,12,5}}, {cdr,16,{2003,12,16}}, {cdr,7,{2003,12,7}}, {cdr,6,{2003,12,6}}, {cdr,9,{2003,12,9}}, {cdr,17,{2003,12,17}}] 8> From massimo.cesaro@REDACTED Tue Oct 7 17:17:33 2003 From: massimo.cesaro@REDACTED (Massimo Cesaro) Date: 07 Oct 2003 17:17:33 +0200 Subject: Date range and match specification syntax In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F9EA761@ESEALNT442.al.sw.ericsson.se> References: <76E5F712842F5F49A35738622BAA0F4F9EA761@ESEALNT442.al.sw.ericsson.se> Message-ID: <1065539854.1437.94.camel@xam> On Tue, 2003-10-07 at 16:51, Ulf Wiger (AL/EAB) wrote: Hello Ulf, > > On October 7, 2003, Massimo Cesaro wrote: > >> Try to use Query = ets:fun2ms(fun(X) -> ... end) instead, > >> slightly simpler to use :-) > >You kidding, don't you ?! :-) > >Seriously, I'd like to see a short tutorial or more examples about it. > > > Here's a short tutorial using ets, and trying to mimic your > problem (the ms_transform manual is daunting, I agree): > > Your match spec would look pretty much like this: > > fun({_,_,D}) when StartDate =< D, D =< EndDate -> > object() > end > I see... > > 1> ets:new(cdr,[set,public,named_table,{keypos,2}]). > cdr > 2> [ets:insert(cdr,{cdr,D,{2003,12,D}}) || D <- lists:seq(1,31)]. > [true, > true|...] > 3> ets:tab2list(cdr). > [{cdr,28,{2003,12,28}}, > {cdr,27,{2003,12,27}}, > {cdr,1,{2003,12,1}}, > {cdr,14,{2003,12|...}}, > {cdr,5,{2003|...}}, > {cdr,16,{...}}, > {cdr,7|...}, > {cdr|...}, > {...}|...] > 4> StartDate = {2003,12,3}. > {2003,12,3} > 5> EndDate = {2003,12,17}. > {2003,12,17} > 6> P = ets:fun2ms(fun({_,_,D}) when StartDate =< D, D =< EndDate -> object() end). > [{{'_','_','$1'}, > [{'=<',{const,{2003,12,3}},'$1'},{'=<','$1',{const,{2003,12,17}}}], > ['$_']}] > 7> catch ets:select(cdr,P). > [{cdr,10,{2003,12,10}}, > {cdr,13,{2003,12,13}}, > {cdr,15,{2003,12,15}}, > {cdr,11,{2003,12,11}}, > {cdr,3,{2003,12,3}}, > {cdr,8,{2003,12,8}}, > {cdr,12,{2003,12,12}}, > {cdr,4,{2003,12,4}}, > {cdr,14,{2003,12,14}}, > {cdr,5,{2003,12,5}}, > {cdr,16,{2003,12,16}}, > {cdr,7,{2003,12,7}}, > {cdr,6,{2003,12,6}}, > {cdr,9,{2003,12,9}}, > {cdr,17,{2003,12,17}}] > 8> Well, I'm amazed, really. You managed to get in 1 line of Erlang a result that in other languages would require a lot more code. Thanks for the information. I hope I can get rid of my 10+ years of C/C++ development and start thinking in Erlang by myself... Cheers, Massimo From mwilligs@REDACTED Tue Oct 7 19:26:42 2003 From: mwilligs@REDACTED (Miguel Willigs) Date: Tue, 7 Oct 2003 14:26:42 -0300 (PYST) Subject: megaco_test_mg and megaco_test_mgc In-Reply-To: <249F349C-F833-11D7-8EA6-003065F4233A@mac.com> References: <32795.65.198.40.11.1065466514.squirrel@unimail.uninet.com.py> <249F349C-F833-11D7-8EA6-003065F4233A@mac.com> Message-ID: <32882.65.198.40.11.1065547602.squirrel@unimail.uninet.com.py> Hi I use the next command line to start the megaco_test_mgc aplication: megaco_test_mgc:start(mgc1,{deviceName,"controller6666qq"},{text,tcp},silence). Is there something wrong in this command? Thank again > Hi, > > The start function: > > start(Node, Mid, ET, Verbosity) > > Node - Is a node name. In the test programs we start slave nodes and > run the > MG/MGC in those. > Mid - Is the Mid of the MGC > ET - What encoding type's the MGC shall support > basically a list of {encoding_type(),transport_protocol()} > where > encoding_type() = text | binary > transport_protocol() = tcp | udp > Verbosity - Debugging: silence | info | debug > silence - no debug printouts > info - some debug printouts > debug - lots of debug printouts > > /BMK > > On Monday, October 6, 2003, at 08:55 PM, Miguel Willigs wrote: > >> Thank you for the answer, I have one more question: What are the >> parametters in the megaco_test_mgc:start() function? >> >> >>> Hi, >>> >>> They are not examples. They are part of the megaco test suite. >>> No doc. Take a look in the Makefile in the test directory. >>> >>> /BMK >>> >>> On Friday, October 3, 2003, at 09:45 PM, Miguel Willigs wrote: >>> >>>> Hi there. >>>> >>>> I found two examples files in the erlang instalation: >>>> megaco_test_mg.erl >>>> and megaco_test_mgc.erl. >>>> My question is: How do I run these examples? Is there any >>>> documentation >>>> about these examples? >>>> >>>> Thanks in advance >>>> >>> >> > From bmk@REDACTED Tue Oct 7 21:38:01 2003 From: bmk@REDACTED (Micael Karlberg) Date: Tue, 7 Oct 2003 21:38:01 +0200 Subject: megaco_test_mg and megaco_test_mgc In-Reply-To: <32882.65.198.40.11.1065547602.squirrel@unimail.uninet.com.py> Message-ID: Hi, On Tuesday, October 7, 2003, at 07:26 PM, Miguel Willigs wrote: > Hi > I use the next command line to start the megaco_test_mgc aplication: > megaco_test_mgc:start(mgc1,{deviceName,"controller6666qq"},{text,tcp},s > ilence). > Is there something wrong in this command? ET should be a list. And if you intend to run it on the same node, then you can make it: megaco_test_mgc:start(node(),{deviceName,"controller6666qq"},[{text,tcp} ],silence). > > Thank again /BMK > >> Hi, >> >> The start function: >> >> start(Node, Mid, ET, Verbosity) >> >> Node - Is a node name. In the test programs we start slave nodes and >> run the >> MG/MGC in those. >> Mid - Is the Mid of the MGC >> ET - What encoding type's the MGC shall support >> basically a list of {encoding_type(),transport_protocol()} >> where >> encoding_type() = text | binary >> transport_protocol() = tcp | udp >> Verbosity - Debugging: silence | info | debug >> silence - no debug printouts >> info - some debug printouts >> debug - lots of debug printouts >> >> /BMK >> >> On Monday, October 6, 2003, at 08:55 PM, Miguel Willigs wrote: >> >>> Thank you for the answer, I have one more question: What are the >>> parametters in the megaco_test_mgc:start() function? >>> >>> >>>> Hi, >>>> >>>> They are not examples. They are part of the megaco test suite. >>>> No doc. Take a look in the Makefile in the test directory. >>>> >>>> /BMK >>>> >>>> On Friday, October 3, 2003, at 09:45 PM, Miguel Willigs wrote: >>>> >>>>> Hi there. >>>>> >>>>> I found two examples files in the erlang instalation: >>>>> megaco_test_mg.erl >>>>> and megaco_test_mgc.erl. >>>>> My question is: How do I run these examples? Is there any >>>>> documentation >>>>> about these examples? >>>>> >>>>> Thanks in advance >>>>> >>>> >>> >> > From tony@REDACTED Wed Oct 8 10:33:30 2003 From: tony@REDACTED (Tony Rogvall) Date: Wed, 8 Oct 2003 10:33:30 +0200 Subject: Date range and match specification syntax In-Reply-To: <16258.47592.813535.85538@rian.du.uab.ericsson.se> Message-ID: <18512A1C-F96A-11D7-A4FC-000A95EB4F88@rogvall.com> On Tuesday, Oct 7, 2003, at 15:04 Europe/Stockholm, Dan Gudmundsson wrote: > > Hi > > > Try to use Query = ets:fun2ms(fun(X) -> ... end) instead, > slightly simpler to use :-) HATS OFF!!! ets:fun2ms is a marvel, lot of thanks to whom ever wrote that function, step forward and reveal your self .... ;-) /Tony From erlang@REDACTED Wed Oct 8 19:44:22 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Wed, 8 Oct 2003 14:44:22 -0300 Subject: Console ouput Message-ID: <00d501c38dc3$d14ed710$1e00a8c0@design> If process P executes group_leader(GP, self(), all console ouput will be sent to process GP? If not, how can I send all console ouput of a process to another process. Thanks, Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From lennart.ohman@REDACTED Wed Oct 8 20:07:56 2003 From: lennart.ohman@REDACTED (=?ISO-8859-1?Q?Lennart_=D6hman?=) Date: Wed, 08 Oct 2003 20:07:56 +0200 Subject: Console ouput In-Reply-To: <00d501c38dc3$d14ed710$1e00a8c0@design> References: <00d501c38dc3$d14ed710$1e00a8c0@design> Message-ID: <3F84527C.2080705@st.se> Read the code of io.erl in stdlib and you will understand. request(standard_io, Request) -> request(group_leader(), Request); request(Pid, Request) when pid(Pid) -> Mref = erlang:monitor(process,Pid), Pid ! {io_request,self(),Pid,io_request(Request)}, wait_io_mon_reply(Pid,Mref); request(Name, Request) when atom(Name) -> case whereis(Name) of undefined -> {error, arguments}; Pid -> request(Pid, Request) end. Group leader is actully one of the few things which are inherited in Erlang - from parent to spawned process. In the IO context the group leader is simply used to identify who handles standard_io for that process. You see that in the code above. For instance calling io:format/2 causes a io_request message to be sent to the process acting as its group-leader. If you wish to send io to another particular process, just simply use IO functions with a descriptor argument. By studying the io code (as above) you see what messages to expect in the receiving process. /Lennart Inswitch Solutions - Erlang Evaluation wrote: > > > If process P executes group_leader(GP, self(), all console ouput will be > sent to process GP? > If not, how can I send all console ouput of a process to another process. > > > Thanks, > Eduardo Figoli > INSwitch Solutions > > -- ------------------------------------------------------------- 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 svg@REDACTED Wed Oct 8 19:50:17 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Wed, 08 Oct 2003 23:50:17 +0600 (YEKST) Subject: Console ouput In-Reply-To: <00d501c38dc3$d14ed710$1e00a8c0@design> References: <00d501c38dc3$d14ed710$1e00a8c0@design> Message-ID: <20031008.235017.41654825.svg@surnet.ru> Good day, erlang> If process P executes group_leader(GP, self(), all console ouput will be sent to process GP? erlang> If not, how can I send all console ouput of a process to another process. Yes, it's so. `io' functions use process_info(self(), group_leader) to find process which implements input-output protocol and send messages to it. In this way you can start service on remote node with rpc, change its group leader and receive it's output locally. Best Regards, Vladimir Sekissov From mwilligs@REDACTED Wed Oct 8 21:53:35 2003 From: mwilligs@REDACTED (Miguel Willigs) Date: Wed, 8 Oct 2003 16:53:35 -0300 (PYST) Subject: megaco_test_mg and megaco_test_mgc] Message-ID: <33160.65.198.40.11.1065642815.squirrel@unimail.uninet.com.py> Hi again This is my last question about this issue (I hope), how can I install erlang in order to be able to execute megaco_test_mgc and megaco_test_mg?. The point is, I understand prety well (I think) about megaco_test_mg and megaco_test_mgc by looking the source code, but I can't execute those codes. Thanks > Hi, > > On Tuesday, October 7, 2003, at 07:26 PM, Miguel Willigs wrote: > >> Hi >> I use the next command line to start the megaco_test_mgc aplication: megaco_test_mgc:start(mgc1,{deviceName,"controller6666qq"},{text,tcp},s ilence). >> Is there something wrong in this command? > > ET should be a list. And if you intend to run it on the same node, then you > can make it: > > megaco_test_mgc:start(node(),{deviceName,"controller6666qq"},[{text,tcp} ],silence). > >> >> Thank again > > /BMK > >> >>> Hi, >>> >>> The start function: >>> >>> start(Node, Mid, ET, Verbosity) >>> >>> Node - Is a node name. In the test programs we start slave nodes and run the >>> MG/MGC in those. >>> Mid - Is the Mid of the MGC >>> ET - What encoding type's the MGC shall support >>> basically a list of {encoding_type(),transport_protocol()} >>> where >>> encoding_type() = text | binary >>> transport_protocol() = tcp | udp >>> Verbosity - Debugging: silence | info | debug >>> silence - no debug printouts >>> info - some debug printouts >>> debug - lots of debug printouts >>> >>> /BMK >>> >>> On Monday, October 6, 2003, at 08:55 PM, Miguel Willigs wrote: >>> >>>> Thank you for the answer, I have one more question: What are the parametters in the megaco_test_mgc:start() function? >>>> >>>> >>>>> Hi, >>>>> >>>>> They are not examples. They are part of the megaco test suite. No doc. Take a look in the Makefile in the test directory. >>>>> >>>>> /BMK >>>>> >>>>> On Friday, October 3, 2003, at 09:45 PM, Miguel Willigs wrote: >>>>> >>>>>> Hi there. >>>>>> >>>>>> I found two examples files in the erlang instalation: >>>>>> megaco_test_mg.erl >>>>>> and megaco_test_mgc.erl. >>>>>> My question is: How do I run these examples? Is there any >>>>>> documentation >>>>>> about these examples? >>>>>> >>>>>> Thanks in advance >>>>>> >>>>> >>>> >>> >> > From jmncoelho@REDACTED Wed Oct 8 14:40:22 2003 From: jmncoelho@REDACTED (Jorge Manuel Neves Coelho) Date: Wed, 8 Oct 2003 13:40:22 +0100 Subject: Xmerl and DTDs Message-ID: <00bf01c38d99$57380e30$09583ad5@asusthlon> Hi! I'm using xmerl to process xml documents. I would like to validate these documents against a dtd, does any one know if it's possible to parse a DTD using xmerl? Or does anyone know another parser that is able to do this? Thank you, Jorge -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrik.linder@REDACTED Thu Oct 9 10:42:38 2003 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Thu, 9 Oct 2003 10:42:38 +0200 Subject: Xmerl and DTDs In-Reply-To: <00bf01c38d99$57380e30$09583ad5@asusthlon> Message-ID: Hello Jorge Yes it can be done. We are currently using xmerl for this purpose (version 0.17). The default behaviour of xmerl_scan is to read each DTD and put it into its 'rules' ets table. We use the 'event' callback feature to add the actual DTD validation. Good Luck /Fredrik -----Original Message----- From: owner-erlang-questions@REDACTED [mailto:owner-erlang-questions@REDACTED]On Behalf Of Jorge Manuel Neves Coelho Sent: den 8 oktober 2003 14:40 To: erlang-questions@REDACTED Subject: Xmerl and DTDs Hi! I'm using xmerl to process xml documents. I would like to validate these documents against a dtd, does any one know if it's possible to parse a DTD using xmerl? Or does anyone know another parser that is able to do this? Thank you, Jorge -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.karlsson@REDACTED Thu Oct 9 11:26:25 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Thu, 9 Oct 2003 11:26:25 +0200 Subject: Xmerl and DTDs In-Reply-To: <00bf01c38d99$57380e30$09583ad5@asusthlon>; from jmncoelho@oninetspeed.pt on Wed, Oct 08, 2003 at 14:40:22 +0200 References: <00bf01c38d99$57380e30$09583ad5@asusthlon> Message-ID: <20031009092625.GA861@aspen2.lk.sll.se> Bom Dia Jorge, I think it is to be included in the next version of xmerl. You can check out a prilimary version from CVS at the project site: http://sowap.sourceforge.net/developer.html >From changes.txt for xmerl 0.19: . On Added xmerl_validate.erl for XML validation . /Mikael 2003.10.08 14:40, Jorge Manuel Neves Coelho wrote: > Hi! > > I'm using xmerl to process xml documents. I would like to validate > these documents against a dtd, does any one know if it's possible to > parse a DTD using xmerl? Or does anyone know another parser that > is able to do this? > > Thank you, > Jorge > From ulf.wiger@REDACTED Thu Oct 9 11:29:45 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 09 Oct 2003 11:29:45 +0200 Subject: Xmerl and DTDs In-Reply-To: <00bf01c38d99$57380e30$09583ad5@asusthlon> References: <00bf01c38d99$57380e30$09583ad5@asusthlon> Message-ID: On Wed, 8 Oct 2003 13:40:22 +0100, Jorge Manuel Neves Coelho wrote: > Hi! > > I'm using xmerl to process xml documents. I would like to validate > these documents against a dtd, does any one know if it's possible to > parse a DTD using xmerl? Or does anyone know another parser that > is able to do this? > > Thank you, > Jorge Fredrik has answered about xmerl and validation. I haven't tried it myself, but Joe Armstrong's xml_lt, http://www.erlang.org/user.html#xml_lt-2.0, should also be able to validate, probably a bit more solidly than xmerl... A worthwhile effort might be to align the two on the Erlang side, so that you can easily use both for different purposes. /Uffe -- Ulf Wiger From tobbe@REDACTED Thu Oct 9 13:27:30 2003 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Thu, 09 Oct 2003 13:27:30 +0200 Subject: Date range and match specification syntax In-Reply-To: <76E5F712842F5F49A35738622BAA0F4F9EA761@ESEALNT442.al.sw.ericsson.se> References: <76E5F712842F5F49A35738622BAA0F4F9EA761@ESEALNT442.al.sw.ericsson.se> Message-ID: <3F854622.70708@bluetail.com> Nice, but how do I express 'or', as in: 1 > ets:fun2ms(fun({_,_,D}) when StartDate =< D; D =< EndDate -> object() end). Error: fun with semicolon (;) in guard cannot be translated into match_spec {error,transform_error} ? /Tobbe Ulf Wiger (AL/EAB) wrote: >On October 7, 2003, Massimo Cesaro wrote: > > >>>Try to use Query = ets:fun2ms(fun(X) -> ... end) instead, >>>slightly simpler to use :-) >>> >>> >>You kidding, don't you ?! :-) >>Seriously, I'd like to see a short tutorial or more examples about it. >> >> > > >Here's a short tutorial using ets, and trying to mimic your >problem (the ms_transform manual is daunting, I agree): > >Your match spec would look pretty much like this: > >fun({_,_,D}) when StartDate =< D, D =< EndDate -> > object() >end > > >1> ets:new(cdr,[set,public,named_table,{keypos,2}]). >cdr >2> [ets:insert(cdr,{cdr,D,{2003,12,D}}) || D <- lists:seq(1,31)]. >[true, > true|...] >3> ets:tab2list(cdr). >[{cdr,28,{2003,12,28}}, > {cdr,27,{2003,12,27}}, > {cdr,1,{2003,12,1}}, > {cdr,14,{2003,12|...}}, > {cdr,5,{2003|...}}, > {cdr,16,{...}}, > {cdr,7|...}, > {cdr|...}, > {...}|...] >4> StartDate = {2003,12,3}. >{2003,12,3} >5> EndDate = {2003,12,17}. >{2003,12,17} >6> P = ets:fun2ms(fun({_,_,D}) when StartDate =< D, D =< EndDate -> object() end). >[{{'_','_','$1'}, > [{'=<',{const,{2003,12,3}},'$1'},{'=<','$1',{const,{2003,12,17}}}], > ['$_']}] >7> catch ets:select(cdr,P). >[{cdr,10,{2003,12,10}}, > {cdr,13,{2003,12,13}}, > {cdr,15,{2003,12,15}}, > {cdr,11,{2003,12,11}}, > {cdr,3,{2003,12,3}}, > {cdr,8,{2003,12,8}}, > {cdr,12,{2003,12,12}}, > {cdr,4,{2003,12,4}}, > {cdr,14,{2003,12,14}}, > {cdr,5,{2003,12,5}}, > {cdr,16,{2003,12,16}}, > {cdr,7,{2003,12,7}}, > {cdr,6,{2003,12,6}}, > {cdr,9,{2003,12,9}}, > {cdr,17,{2003,12,17}}] >8> > > From vlad_dumitrescu@REDACTED Thu Oct 9 14:15:42 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 9 Oct 2003 14:15:42 +0200 Subject: Esdl from Emacs Message-ID: Hi, When I try to start any esdl program from an Emacs Erlang buffer, sdl hangs: Command:36:SDL_SetVideoModeFunc: I am on Windows and use the latest of all involved tools. Is there a reason for this to not work, or is it a bug? It's awkward to have to use a separate erlang node... Thanks in advance. Regards, Vlad From vlad_dumitrescu@REDACTED Thu Oct 9 15:30:12 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 9 Oct 2003 15:30:12 +0200 Subject: Esdl & sdl_ttf Message-ID: Hello again, Is anyone doing, or did anyone do, anything about interfacing to sdl_ttf or FreeType? regards, Vlad From ulf.wiger@REDACTED Thu Oct 9 17:10:31 2003 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Thu, 9 Oct 2003 17:10:31 +0200 Subject: Date range and match specification syntax Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5402568@ESEALNT442.al.sw.ericsson.se> fun({_,_,D}) when StartDate =< D -> object(); ({_,_,D}) when D =< EndDate -> object() end. (: /Uffe -----Original Message----- From: Torbjorn Tornkvist [mailto:tobbe@REDACTED] Sent: den 9 oktober 2003 13:28 To: Ulf Wiger (AL/EAB) Cc: Erlang mailing list Subject: Re: Date range and match specification syntax Nice, but how do I express 'or', as in: 1 > ets:fun2ms(fun({_,_,D}) when StartDate =< D; D =< EndDate -> object() end). Error: fun with semicolon (;) in guard cannot be translated into match_spec {error,transform_error} ? /Tobbe Ulf Wiger (AL/EAB) wrote: >On October 7, 2003, Massimo Cesaro wrote: > > >>>Try to use Query = ets:fun2ms(fun(X) -> ... end) instead, >>>slightly simpler to use :-) >>> >>> >>You kidding, don't you ?! :-) >>Seriously, I'd like to see a short tutorial or more examples about it. >> >> > > >Here's a short tutorial using ets, and trying to mimic your >problem (the ms_transform manual is daunting, I agree): > >Your match spec would look pretty much like this: > >fun({_,_,D}) when StartDate =< D, D =< EndDate -> > object() >end > > >1> ets:new(cdr,[set,public,named_table,{keypos,2}]). >cdr >2> [ets:insert(cdr,{cdr,D,{2003,12,D}}) || D <- lists:seq(1,31)]. >[true, > true|...] >3> ets:tab2list(cdr). >[{cdr,28,{2003,12,28}}, > {cdr,27,{2003,12,27}}, > {cdr,1,{2003,12,1}}, > {cdr,14,{2003,12|...}}, > {cdr,5,{2003|...}}, > {cdr,16,{...}}, > {cdr,7|...}, > {cdr|...}, > {...}|...] >4> StartDate = {2003,12,3}. >{2003,12,3} >5> EndDate = {2003,12,17}. >{2003,12,17} >6> P = ets:fun2ms(fun({_,_,D}) when StartDate =< D, D =< EndDate -> object() end). >[{{'_','_','$1'}, > [{'=<',{const,{2003,12,3}},'$1'},{'=<','$1',{const,{2003,12,17}}}], > ['$_']}] >7> catch ets:select(cdr,P). >[{cdr,10,{2003,12,10}}, > {cdr,13,{2003,12,13}}, > {cdr,15,{2003,12,15}}, > {cdr,11,{2003,12,11}}, > {cdr,3,{2003,12,3}}, > {cdr,8,{2003,12,8}}, > {cdr,12,{2003,12,12}}, > {cdr,4,{2003,12,4}}, > {cdr,14,{2003,12,14}}, > {cdr,5,{2003,12,5}}, > {cdr,16,{2003,12,16}}, > {cdr,7,{2003,12,7}}, > {cdr,6,{2003,12,6}}, > {cdr,9,{2003,12,9}}, > {cdr,17,{2003,12,17}}] >8> > > From vlad_dumitrescu@REDACTED Thu Oct 9 20:36:52 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 9 Oct 2003 20:36:52 +0200 Subject: Compiling ESDL (Windows) Message-ID: Hi, I followed all instructions to compile ESDL, but I get a very strange behaviour: $ ./mingw_build.sh -f Makefile.win32 cd src make -f Makefile.win32 make[1]: Entering directory `/cygdrive/c/program/erl/lib/esdl-0.93.0909' cd src make -f Makefile.win32 make[2]: Entering directory `/cygdrive/c/program/erl/lib/esdl-0.93.0909' cd src .............. i.e. for some reason "cd" doesn't work. ./configure-cygwin-mingw.sh works fine. Anyone has a clue about what is going on? Thanks in advance. Regards, Vlad From sean.hinde@REDACTED Fri Oct 10 00:21:32 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Thu, 9 Oct 2003 23:21:32 +0100 Subject: Date range and match specification syntax In-Reply-To: <18512A1C-F96A-11D7-A4FC-000A95EB4F88@rogvall.com> Message-ID: On Wednesday, October 8, 2003, at 09:33 am, Tony Rogvall wrote: > > On Tuesday, Oct 7, 2003, at 15:04 Europe/Stockholm, Dan Gudmundsson > wrote: > >> >> Hi >> >> >> Try to use Query = ets:fun2ms(fun(X) -> ... end) instead, >> slightly simpler to use :-) > > HATS OFF!!! > > ets:fun2ms is a marvel, lot of thanks to whom ever wrote that function, > step forward and reveal your self .... ;-) Well, I guess I can possibly lay claim to the first hack along those lines: http://www.erlang.org/ml-archive/erlang-questions/200110/msg00175.html I do know that there is nothing of mine in the final version (even inspiration) because the real author claims that he never reads the mailing list. I guess this also means that he will remain anonymous ;) Sean From serge@REDACTED Fri Oct 10 03:55:43 2003 From: serge@REDACTED (Serge Aleynikov) Date: Thu, 09 Oct 2003 21:55:43 -0400 Subject: default floating point printing format Message-ID: <3F86119F.9080505@hq.idt.net> Hi all! Does anybody know if there is a way to specify a default format mask for outputing floating point numbers in a nested Erlang term. I.e., given: Term = [[(2/3), (5/7)], {1.2345, (13/15)}]. I'd like to do: io:format("~p", [Term]) such that all floating point numbers were printed like: "~.3f" Thanks. Serge From jmncoelho@REDACTED Thu Oct 9 20:14:04 2003 From: jmncoelho@REDACTED (Jorge Manuel Neves Coelho) Date: Thu, 9 Oct 2003 19:14:04 +0100 Subject: Xmerl and DTDs again... Message-ID: <003a01c38e91$1f687f50$0100a8c0@asusthlon> Thank you all for your fast answers. But I'm still having problems. I'm not sure I understand how to use xmerl to parse DTDs. If I use an internal or external DTD in an xml file, xmerl_scan reports an error while parsing it. How can I do it? Thank you, Jorge -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo@REDACTED Fri Oct 10 09:05:17 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Fri, 10 Oct 2003 09:05:17 +0200 Subject: Date range and match specification syntax References: <37FB7AA6F5F9814FB634A7BF4C35A6F5402568@ESEALNT442.al.sw.ericsson.se> Message-ID: Try also ets:fun2ms(fun({_,_,D}) when (StartDate =< D) or (D =< EndDate) -> object() end) Ulf Wiger AL/EAB wrote: > fun({_,_,D}) when StartDate =< D -> object(); > ({_,_,D}) when D =< EndDate -> object() > end. > > (: > > /Uffe > > -----Original Message----- > From: Torbjorn Tornkvist [mailto:tobbe@REDACTED] > Sent: den 9 oktober 2003 13:28 > To: Ulf Wiger (AL/EAB) > Cc: Erlang mailing list > Subject: Re: Date range and match specification syntax > > > Nice, but how do I express 'or', as in: > > 1 > ets:fun2ms(fun({_,_,D}) when StartDate =< D; D =< EndDate -> > object() end). > Error: fun with semicolon (;) in guard cannot be translated into match_spec > {error,transform_error} > > ? /Tobbe > > Ulf Wiger (AL/EAB) wrote: > > >>On October 7, 2003, Massimo Cesaro wrote: >> >> >> >>>>Try to use Query = ets:fun2ms(fun(X) -> ... end) instead, >>>>slightly simpler to use :-) >>>> >>>> >>> >>>You kidding, don't you ?! :-) >>>Seriously, I'd like to see a short tutorial or more examples about it. >>> >>> >> >> >>Here's a short tutorial using ets, and trying to mimic your >>problem (the ms_transform manual is daunting, I agree): >> >>Your match spec would look pretty much like this: >> >>fun({_,_,D}) when StartDate =< D, D =< EndDate -> >> object() >>end >> >> >>1> ets:new(cdr,[set,public,named_table,{keypos,2}]). >>cdr >>2> [ets:insert(cdr,{cdr,D,{2003,12,D}}) || D <- lists:seq(1,31)]. >>[true, >>true|...] >>3> ets:tab2list(cdr). >>[{cdr,28,{2003,12,28}}, >>{cdr,27,{2003,12,27}}, >>{cdr,1,{2003,12,1}}, >>{cdr,14,{2003,12|...}}, >>{cdr,5,{2003|...}}, >>{cdr,16,{...}}, >>{cdr,7|...}, >>{cdr|...}, >>{...}|...] >>4> StartDate = {2003,12,3}. >>{2003,12,3} >>5> EndDate = {2003,12,17}. >>{2003,12,17} >>6> P = ets:fun2ms(fun({_,_,D}) when StartDate =< D, D =< EndDate -> object() end). >>[{{'_','_','$1'}, >> [{'=<',{const,{2003,12,3}},'$1'},{'=<','$1',{const,{2003,12,17}}}], >> ['$_']}] >>7> catch ets:select(cdr,P). >>[{cdr,10,{2003,12,10}}, >>{cdr,13,{2003,12,13}}, >>{cdr,15,{2003,12,15}}, >>{cdr,11,{2003,12,11}}, >>{cdr,3,{2003,12,3}}, >>{cdr,8,{2003,12,8}}, >>{cdr,12,{2003,12,12}}, >>{cdr,4,{2003,12,4}}, >>{cdr,14,{2003,12,14}}, >>{cdr,5,{2003,12,5}}, >>{cdr,16,{2003,12,16}}, >>{cdr,7,{2003,12,7}}, >>{cdr,6,{2003,12,6}}, >>{cdr,9,{2003,12,9}}, >>{cdr,17,{2003,12,17}}] >>8> >> >> > > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From dgud@REDACTED Fri Oct 10 09:21:06 2003 From: dgud@REDACTED (Dan Gudmundsson) Date: Fri, 10 Oct 2003 09:21:06 +0200 Subject: Compiling ESDL (Windows) In-Reply-To: References: Message-ID: <16262.24034.148185.40391@rian.du.uab.ericsson.se> I believe that you should just do $ ./mingw_build.sh the Makefile.win32 are for the microsoft tools. I havn't actually tested it (either), I don't use windows, but Patrik does and he's the one who rewrote it. /Dan Vlad Dumitrescu writes: > Hi, > > I followed all instructions to compile ESDL, but I get a very strange > behaviour: > > $ ./mingw_build.sh -f Makefile.win32 > cd src > make -f Makefile.win32 > make[1]: Entering directory `/cygdrive/c/program/erl/lib/esdl-0.93.0909' > cd src > make -f Makefile.win32 > make[2]: Entering directory `/cygdrive/c/program/erl/lib/esdl-0.93.0909' > cd src > .............. > > i.e. for some reason "cd" doesn't work. ./configure-cygwin-mingw.sh works > fine. > > Anyone has a clue about what is going on? > Thanks in advance. Regards, > Vlad -- Dan Gudmundsson Project: Mnesia, Erlang/OTP Ericsson Utvecklings AB Phone: +46 8 727 5762 UAB/F/P Mobile: +46 70 519 9469 S-125 25 Stockholm Visit addr: Armborstv 1 From vlad_dumitrescu@REDACTED Fri Oct 10 10:22:27 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 10 Oct 2003 10:22:27 +0200 Subject: Compiling ESDL (Windows) References: <16262.24034.148185.40391@rian.du.uab.ericsson.se> Message-ID: From: "Dan Gudmundsson" > > I believe that you should just do > $ ./mingw_build.sh > > the Makefile.win32 are for the microsoft tools. > > I havn't actually tested it (either), I don't use windows, but > Patrik does and he's the one who rewrote it. the problem was that there I had no "Makefile" other then the obsolete "Makefile.win32". For some reason it didn't got copied. Now I get this: vladum@REDACTED /cygdrive/c/Program/erl/lib/esdl $ ./mingw_build.sh make: *** No rule to make target `testsprite.beam', needed by `target'. Stop. That's why I prefer IDEs :-) regards, Vlad From vlad_dumitrescu@REDACTED Fri Oct 10 10:24:28 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 10 Oct 2003 10:24:28 +0200 Subject: Compiling ESDL (Windows) References: <16262.24034.148185.40391@rian.du.uab.ericsson.se> Message-ID: Erm, disregard the latest post, it seems that my zip utility mixes things up and it was the wrong Makefile... It seems to be working now. /Vlad From kostis@REDACTED Fri Oct 10 15:57:14 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Fri, 10 Oct 2003 15:57:14 +0200 (MEST) Subject: Binary pattern syntax anomaly Message-ID: <200310101357.h9ADvELi018544@harpo.it.uu.se> Is there any particularly good reason why the following piece of Erlang code works correctly B = <<2,42>>, <<1, B/binary>> = <<1, <<2,42>>/binary>>. while the following (semantically equivalent) code <<1, <<2,42>>/binary>> = <<1, <<2,42>>/binary>>. gets rejected as an illegal pattern? Isn't this a bug, or at least a totally unnecessary restriction in the syntax of binary patterns? Kostis. From jeremy@REDACTED Fri Oct 10 06:03:41 2003 From: jeremy@REDACTED (Jeremy Hylton) Date: Fri, 10 Oct 2003 00:03:41 -0400 Subject: CFP: LL3; Submission deadline Oct. 17 Message-ID: <200310100405.h9A45TT89844@hades.cslab.ericsson.net> Call for Presentations Lightweight Languages Workshop (LL3) http://ll3.ai.mit.edu/ November 8, 2003 Cambridge, Ma., USA The Lightweight Languages Workshop series focuses on programming languages, tools, and processes that are usable and useful. Lightweight languages have been an effective vehicle for introducing new features to mainstream programmers. We encourage presentations on topics of interest to the community of lightweight language users and designers. We prefer topics that will interest a broad audience. We do not require the presentation of novel research ideas. We are looking for abstracts of talks to be given at the workshop. Send abstracts to ll3-submit@REDACTED See the full call for proposals for suggested topics. Deadlines --------- Submissions: Oct. 17, 2003 Notification: Oct. 24, 2003 Program Committee ----------------- Ken Anderson, BBN (co-chair) Jeremy Hylton, Python Software Foundation (co-chair) Geoffrey Knauth, BAE Systems Shriram Krishnamurthi, Brown University Erik Meijer, Microsoft WebData Dan Sugalski, Perl Foundation Greg Sullivan, MIT CSAIL For more information, email ll3@REDACTED From david.wallin@REDACTED Fri Oct 10 17:19:26 2003 From: david.wallin@REDACTED (david wallin) Date: Fri, 10 Oct 2003 16:19:26 +0100 Subject: BUG: in io:fread/3: doesn't return eof Message-ID: <22B4311D-FB35-11D7-891E-000393536F4E@ul.ie> Subject says it all really. With release R9C-0 io:fread/3 doesn't return 'eof' but an error. The following function worked fine with R9B-1 but now I get an '{error, Error}' instead of 'eof'. get_best_fitness(Io) -> case io:fread(Io, 'adhoc> ', "~d~f~f~d~f") of {ok, [Generation, BestFitness, AvgFitness, ValidSol, Entropy]} -> {Generation, BestFitness} ; {error, Error} -> io:format("~p.get_best_fitness: unexpected format '~p'\n", [?MODULE, Error]), error ; eof -> eof end. cheers, --david. From erlang@REDACTED Fri Oct 10 18:58:04 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Fri, 10 Oct 2003 13:58:04 -0300 Subject: Evaluate string in Erlang Message-ID: <110501c38f52$0d8ab430$1e00a8c0@design> I have the A="erlang:nodes().". Does anyone know how can I evaluate A string variable in Erlang? Once more thanks to all, Eduardo Figoli -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.hinde@REDACTED Fri Oct 10 19:50:52 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Fri, 10 Oct 2003 18:50:52 +0100 Subject: Evaluate string in Erlang In-Reply-To: <110501c38f52$0d8ab430$1e00a8c0@design> Message-ID: <4A24F8AB-FB4A-11D7-8668-000A95927CCE@mac.com> On Friday, October 10, 2003, at 05:58 pm, Inswitch Solutions - Erlang Evaluation wrote: > "erlang:nodes()." One way is: 1> {ok, A, _} = erl_scan:string("erlang:nodes()."). 2> {ok, B} = erl_parse:parse_exprs(A). 3> erl_eval:exprs(B, []). Sean From bjarne@REDACTED Sat Oct 11 10:17:54 2003 From: bjarne@REDACTED (=?iso-8859-1?Q?Bjarne_D=E4cker?=) Date: Sat, 11 Oct 2003 10:17:54 +0200 Subject: Erlang/OTP User Conference 2003 - call for papers Message-ID: <002401c38fd0$2c2caa00$e10b69d4@segeltorp> Hello Planning for this year's Erlang/OTP User Conference is under way. Please see the call-for-papers at http://www.erlang.se/euc/03/ Presentations, papers, demos are welcome, both on applications and on technology. Bjarne D?cker -------------- next part -------------- An HTML attachment was scrubbed... URL: From taj.khattra@REDACTED Sun Oct 12 07:12:27 2003 From: taj.khattra@REDACTED (Taj Khattra) Date: Sat, 11 Oct 2003 22:12:27 -0700 Subject: eddie technical reports In-Reply-To: <20030914221109.1376.qmail@infidel.telus.net> References: <20030914221109.1376.qmail@infidel.telus.net> Message-ID: <20031012051227.GA1762@localhost.localdomain> On Sun, Sep 14, 2003 at 10:11:09PM -0000, Taj Khattra wrote: > the eddie technical reports links at > > http://eddie.sourceforge.net/techrep.html > > are dead - is anybody aware of some other place where > i could find them ? (already googled for them, but no > luck) > sorry to follow up my own message, but i finally found them collecting dust on an old hard drive. i've put them at http://pobox.com/~taj.khattra/Load_Balancing.ps.gz http://pobox.com/~taj.khattra/Admission_Control.ps.gz in case anyone else is interested. -taj From apomares@REDACTED Sun Oct 12 15:04:17 2003 From: apomares@REDACTED (Alejandro Pomares) Date: Sun, 12 Oct 2003 15:04:17 +0200 Subject: =?ISO-8859-1?Q?Baja_de_su_lista_de_distribuci=F3n?= Message-ID: <966B56EE-FCB4-11D7-88B5-000A95A0BD80@obelix.umh.es> Estimado Sr. Solicito la BAJA de su lista de distribuci?n. Gracias Alejandro Pomares From raimo@REDACTED Mon Oct 13 09:23:30 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Mon, 13 Oct 2003 09:23:30 +0200 Subject: BUG: in io:fread/3: doesn't return eof References: <22B4311D-FB35-11D7-891E-000393536F4E@ul.ie> Message-ID: Erlang (BEAM) emulator version 5.3 [hipe] [threads:0] Eshell V5.3 (abort with ^G) 1> io:fread('adhoc> ', "~d~f~f~d~f"). adhoc> 1 2.0 3.0 4 5.0 {ok,[1,2.00000,3.00000,4,5.00000]} 2> Works fine. Please give more info about from where you read input and how you expect the end of file in the input to appear. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB david wallin wrote: > Subject says it all really. With release R9C-0 io:fread/3 doesn't return > 'eof' but an error. > > The following function worked fine with R9B-1 but now I get an '{error, > Error}' instead of 'eof'. > > get_best_fitness(Io) -> > > case io:fread(Io, 'adhoc> ', "~d~f~f~d~f") of > > {ok, [Generation, BestFitness, AvgFitness, ValidSol, Entropy]} -> > {Generation, BestFitness} ; > > {error, Error} -> > io:format("~p.get_best_fitness: unexpected format '~p'\n", > [?MODULE, Error]), > error ; > > eof -> eof > > end. > > > > cheers, > > --david. > From sean.hinde@REDACTED Mon Oct 13 12:22:21 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 13 Oct 2003 11:22:21 +0100 Subject: Erlang is getting too big Message-ID: <219ABE6A-FD67-11D7-8668-000A95927CCE@mac.com> Hi, An observation from the trenches. There are huge problems out in the real world getting companies (or even other departments) to adopt Erlang. One of the arguments in favour of Erlang has been that it is a "small" language so the overhead of learning it and, vastly more important, supporting the applications written in it is small. This is no longer the case, and from what I see on the mailing list and in conferences there is a strong push towards adding more obfuscation to an already large and (for C++ types) confusing language. Please let us stop this profligate adding of new features otherwise we will kill the takeup of Erlang stone dead. Sean From lennart.ohman@REDACTED Mon Oct 13 12:56:17 2003 From: lennart.ohman@REDACTED (=?ISO-8859-1?Q?Lennart_=D6hman?=) Date: Mon, 13 Oct 2003 12:56:17 +0200 Subject: Erlang is getting too big In-Reply-To: <219ABE6A-FD67-11D7-8668-000A95927CCE@mac.com> References: <219ABE6A-FD67-11D7-8668-000A95927CCE@mac.com> Message-ID: <3F8A84D1.7090805@st.se> I agree with the previous "speaker". /Lennart Sean Hinde wrote: > Hi, > > An observation from the trenches. > > There are huge problems out in the real world getting companies (or even > other departments) to adopt Erlang. One of the arguments in favour of > Erlang has been that it is a "small" language so the overhead of > learning it and, vastly more important, supporting the applications > written in it is small. > > This is no longer the case, and from what I see on the mailing list and > in conferences there is a strong push towards adding more obfuscation to > an already large and (for C++ types) confusing language. > > Please let us stop this profligate adding of new features otherwise we > will kill the takeup of Erlang stone dead. > > Sean > -- ------------------------------------------------------------- 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 vlad_dumitrescu@REDACTED Mon Oct 13 12:56:28 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Oct 2003 12:56:28 +0200 Subject: Erlang is getting too big References: <219ABE6A-FD67-11D7-8668-000A95927CCE@mac.com> Message-ID: > There are huge problems out in the real world getting companies (or > even other departments) to adopt Erlang. One of the arguments in favour > of Erlang has been that it is a "small" language so the overhead of > learning it and, vastly more important, supporting the applications > written in it is small. > > This is no longer the case, and from what I see on the mailing list and > in conferences there is a strong push towards adding more obfuscation > to an already large and (for C++ types) confusing language. > > Please let us stop this profligate adding of new features otherwise we > will kill the takeup of Erlang stone dead. As I feel hit by that ;-) I am compelled to answer. My goal would be to make Erlang _better_, which in some cases might mean "'bigger', but 'easier'" or "'bigger', but 'faster to develop in'". It's not "add features just for the fun of it". I am very much aware about the situation Erlang is in, being both commercial and open-sourced, and I am certain that it's very difficult to keep the balance. Well, not really - I suppose if there's a real conflict, the paying customers will always win. Discussing about enhancements can't hurt, I think, just because the OTP team is (and needs to be!) quite conservative when it comes to new stuff. On the other hand, saying "let's stop any development of the language, it's good enough as it is" is in my humble opinion at least as bad as bloating Erlang just for the sake of it. If Erlang will gain terrain in the commercial area, then it will become harder and harder to change anything, because there will be many more paying customers. If we see something that can be improved, the proper timing to do it is as soon as possible. Maybe the experimental stuff should be moved to a parallel development branch, as it was already proposed before? It doesn't feel good about saying that... Just some 2 cents rambling :-) /Vlad From sean.hinde@REDACTED Mon Oct 13 13:33:24 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 13 Oct 2003 12:33:24 +0100 Subject: Erlang is getting too big In-Reply-To: Message-ID: <0E74CFEC-FD71-11D7-8668-000A95927CCE@mac.com> > > My goal would be to make Erlang _better_, which in some cases might > mean > "'bigger', but 'easier'" or "'bigger', but 'faster to develop in'". > It's not > "add features just for the fun of it". > > I am very much aware about the situation Erlang is in, being both > commercial and > open-sourced, and I am certain that it's very difficult to keep the > balance. > Well, not really - I suppose if there's a real conflict, the paying > customers > will always win. Discussing about enhancements can't hurt, I think, > just because > the OTP team is (and needs to be!) quite conservative when it comes to > new > stuff. > > On the other hand, saying "let's stop any development of the language, > it's good > enough as it is" is in my humble opinion at least as bad as bloating > Erlang just > for the sake of it. Perhaps I should clarify slightly more than I did. I am not arguing for not changing anything. The bit syntax is something so awesome to behold and simplifies so much that is core to the Erlang problem domain that I totally approve of the decision to add that. My concern is of adding new features which are a bit tweaky, language researchy which do not contribute to the singular vision of Erlang, which to me is all about building massive systems which are maintainable by non "CS genius" people who can be trained in the language in a week. Sean From mike@REDACTED Mon Oct 13 13:34:34 2003 From: mike@REDACTED (Mike Williams) Date: 13 Oct 2003 11:34:34 GMT Subject: Erlang is getting too big References: <219ABE6A-FD67-11D7-8668-000A95927CCE@mac.com> Message-ID: Sean, Thanks, I have been shouting this for anout the last four years. At this stage of Erlang's development, it is far better to live with what we have got "warts and all". It is easy to add things, it is impossible to take things away. Continuously adding things to the language will just land us with a monster which nobody will addopt. /mike In article <219ABE6A-FD67-11D7-8668-000A95927CCE@REDACTED>, sean.hinde@REDACTED (Sean Hinde) writes: |> Hi, |> |> An observation from the trenches. |> |> There are huge problems out in the real world getting companies (or |> even other departments) to adopt Erlang. One of the arguments in favour |> of Erlang has been that it is a "small" language so the overhead of |> learning it and, vastly more important, supporting the applications |> written in it is small. |> |> This is no longer the case, and from what I see on the mailing list and |> in conferences there is a strong push towards adding more obfuscation |> to an already large and (for C++ types) confusing language. |> |> Please let us stop this profligate adding of new features otherwise we |> will kill the takeup of Erlang stone dead. |> |> Sean |> From vlad_dumitrescu@REDACTED Mon Oct 13 13:42:58 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 13 Oct 2003 13:42:58 +0200 Subject: Erlang is getting too big References: <0E74CFEC-FD71-11D7-8668-000A95927CCE@mac.com> Message-ID: From: "Sean Hinde" > My concern is of adding new features which are a bit tweaky, language > researchy which do not contribute to the singular vision of Erlang, > which to me is all about building massive systems which are > maintainable by non "CS genius" people who can be trained in the > language in a week. Ah! Then there we agree. There is one minor point that I'd like to make: discussing about new features (even tweaky ones) might prove useful anyway. Maybe someone comes up with a simple way of using an until that point tweaky feature, making it extremely useful. If I'm not confusing issues, the bit syntax also had some tweaky ancestors. [side note] In my own experience with trying to introduce Erlang to new "markets", the problem was about not being able to strip down easily the parts that are not needed (like in my case for example ASN, Corba). It can surely be done (Wings proves it by distributing a slim Erlang system), but as far as I know it's a manual job. [/] regards, Vlad From david.wallin@REDACTED Mon Oct 13 14:11:57 2003 From: david.wallin@REDACTED (david wallin) Date: Mon, 13 Oct 2003 13:11:57 +0100 Subject: BUG: in io:fread/3: doesn't return eof In-Reply-To: Message-ID: <7150A476-FD76-11D7-891E-000393536F4E@ul.ie> On Monday, October 13, 2003, at 08:23 AM, Raimo Niskanen wrote: > Erlang (BEAM) emulator version 5.3 [hipe] [threads:0] > > Eshell V5.3 (abort with ^G) > 1> io:fread('adhoc> ', "~d~f~f~d~f"). > adhoc> 1 2.0 3.0 4 5.0 > {ok,[1,2.00000,3.00000,4,5.00000]} > 2> > I have a file with alot of entries like that, and the function below is supposed to be called until all of them are read, i.e, it should return the eof from io:fread/3. The behaviour of 'io:fread/3' has clearly changed between R9B-1 and R9C-0. --david. > Works fine. Please give more info about from where you read input and > how you expect the end of file in the input to appear. > > -- > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > > david wallin wrote: >> Subject says it all really. With release R9C-0 io:fread/3 doesn't >> return 'eof' but an error. >> The following function worked fine with R9B-1 but now I get an >> '{error, Error}' instead of 'eof'. >> get_best_fitness(Io) -> >> case io:fread(Io, 'adhoc> ', "~d~f~f~d~f") of >> {ok, [Generation, BestFitness, AvgFitness, ValidSol, Entropy]} -> >> {Generation, BestFitness} ; >> {error, Error} -> >> io:format("~p.get_best_fitness: unexpected format '~p'\n", >> [?MODULE, Error]), >> error ; >> eof -> eof >> end. >> cheers, >> --david. From joe@REDACTED Mon Oct 13 14:38:36 2003 From: joe@REDACTED (Joe Armstrong) Date: Mon, 13 Oct 2003 14:38:36 +0200 (CEST) Subject: Erlang is getting too big In-Reply-To: <219ABE6A-FD67-11D7-8668-000A95927CCE@mac.com> Message-ID: > Hi, > > An observation from the trenches. > > There are huge problems out in the real world getting companies (or > even other departments) to adopt Erlang. One of the arguments in favour > of Erlang has been that it is a "small" language so the overhead of > learning it and, vastly more important, supporting the applications > written in it is small. On Mon, 13 Oct 2003, Sean Hinde wrote: Yes > This is no longer the case, and from what I see on the mailing list and > in conferences there is a strong push towards adding more obfuscation > to an already large and (for C++ types) confusing language. I think there is a lot of talk here but not much action :-) Sure there is a lot of talk about things that would be nice, but this does not mean to say that the language is growing in an incontrollable manner - I have ofter argued that "If we add something" we should "take something out" and I think this is still and always the case. IMHO Erlang is perceived as being large because the distribution keeps growing in size - this is because the language and the applications are not distributed separately - so it becomes very difficult to distinguished exactly "what is Erlang". I would very much like to see the distribution split as follows: 1) "The language" + the *minimal set of libraries necessary to compile and run a simple application. 2) A set of applications - o - Now 1) is (roughly) the compiler, the run-time system + *half* of the modules in stdlib and kernel. This is not large. My earlier stand-alone Erlang sytems achieved 1) in less than 1.44 MBytes. 2) Is potentially huge - o - The Erlang OTP system is actually three things - The language - OTP - A number of applications But the boundaries are not clearly visible. I think it would greatly improve things if we could release the basic language stuff, OTP and the applications separately - so that the" distinctions become clearer. /Joe From cyberlync@REDACTED Mon Oct 13 15:15:22 2003 From: cyberlync@REDACTED (Eric Merritt) Date: Mon, 13 Oct 2003 06:15:22 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: Message-ID: <20031013131522.1030.qmail@web40812.mail.yahoo.com> --- Mike Williams wrote: > Sean, > > Thanks, I have been shouting this for anout the last > four years. > At this stage of Erlang's development, it is far > better to live > with what we have got "warts and all". It is easy to > add things, > it is impossible to take things away. Continuously > adding things to > the language will just land us with a monster which > nobody will > addopt. Why is it impossible to take something away? If you give ample warning, say depricating a feature two or three releases before it goes away, and provide a very clear migration path to new features it should not be a problem to remove features. If a client doesn't want to modify his source he always has the option of not upgrading past the point where a depricated feature is removed. __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From jamesh@REDACTED Mon Oct 13 15:30:49 2003 From: jamesh@REDACTED (James Hague) Date: Mon, 13 Oct 2003 08:30:49 -0500 Subject: Garbage collection of binaries Message-ID: If I write a tail recursive function that loads a large file as a binary--say, 10MB--on each iteration, then the emulator quickly runs out of memory and dies. This is apparently because binaries are only garbage collected when the regular garbage collector runs, and with large binaries it's easy to run out of memory before then. It's easy to get this to happen in a real application. One hacky solution is to call erlang:garbage_collect all over the place, but...yuck. Is this being addressed in the run-time system at some point? Any other workarounds? From sean.hinde@REDACTED Mon Oct 13 15:46:24 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 13 Oct 2003 14:46:24 +0100 Subject: Erlang is getting too big In-Reply-To: Message-ID: On Monday, October 13, 2003, at 01:38 pm, Joe Armstrong wrote: >> Hi, >> >> An observation from the trenches. >> >> There are huge problems out in the real world getting companies (or >> even other departments) to adopt Erlang. One of the arguments in >> favour >> of Erlang has been that it is a "small" language so the overhead of >> learning it and, vastly more important, supporting the applications >> written in it is small. > > > On Mon, 13 Oct 2003, Sean Hinde wrote: > > Yes > >> This is no longer the case, and from what I see on the mailing list >> and >> in conferences there is a strong push towards adding more obfuscation >> to an already large and (for C++ types) confusing language. > > I think there is a lot of talk here but not much action :-) I think there is and has been quite a bit of action since the bit syntax. Duplicate guards, much new syntactic sugar for record operations #rec{_ = xx}, Java style module naming, soon to be more syntactic sugar for guards, Parameterised modules.. Some of these new features have led to head scratching and questions to me from folks here learning Erlang in the last few weeks. I think we *are* in severe danger of making the core language "too big". We haven't "taken anything out of the language" to add any of these things, and none of them add new capabilities to the language. All of them must be understood by anyone learning Erlang, and already they cannot all be taught in a week. The questions coming to me are from people who have been on their Erlang course and simply didn't have time to cover all of the language syntax. Sean From bjarne@REDACTED Mon Oct 13 15:51:15 2003 From: bjarne@REDACTED (=?iso-8859-1?Q?Bjarne_D=E4cker?=) Date: Mon, 13 Oct 2003 15:51:15 +0200 Subject: Erlang is getting too big References: Message-ID: <002b01c39191$12eccc60$cf2469d4@segeltorp> What an excellent discussion topic for the after beer session at the coming Erlang/OTP User Conference ! http://www.erlang.se/euc/03/ CU Bjarne ----- Original Message ----- From: "Joe Armstrong" To: "Sean Hinde" Cc: "Erlang Questions" Sent: Monday, October 13, 2003 2:38 PM Subject: Re: Erlang is getting too big > > Hi, > > > > An observation from the trenches. > > > > There are huge problems out in the real world getting companies (or > > even other departments) to adopt Erlang. One of the arguments in favour > > of Erlang has been that it is a "small" language so the overhead of > > learning it and, vastly more important, supporting the applications > > written in it is small. > > > On Mon, 13 Oct 2003, Sean Hinde wrote: > > Yes > > > This is no longer the case, and from what I see on the mailing list and > > in conferences there is a strong push towards adding more obfuscation > > to an already large and (for C++ types) confusing language. > > I think there is a lot of talk here but not much action :-) > > Sure there is a lot of talk about things that would be nice, but > this does not mean to say that the language is growing in an > incontrollable manner - I have ofter argued that "If we add something" > we should "take something out" and I think this is still and always > the case. > > IMHO Erlang is perceived as being large because the distribution > keeps growing in size - this is because the language and the > applications are not distributed separately - so it becomes very > difficult to distinguished exactly "what is Erlang". > > I would very much like to see the distribution split as follows: > > 1) "The language" + the *minimal set of libraries necessary to > compile and run a simple application. > > 2) A set of applications > > - o - > > Now 1) is (roughly) the compiler, the run-time system + *half* of > the modules in stdlib and kernel. This is not large. My earlier > stand-alone Erlang sytems achieved 1) in less than 1.44 MBytes. > > 2) Is potentially huge > > - o - > > The Erlang OTP system is actually three things > > - The language > - OTP > - A number of applications > > But the boundaries are not clearly visible. > > I think it would greatly improve things if we could release the > basic language stuff, OTP and the applications separately - so that the" > distinctions become clearer. > > > /Joe > > > > From chris.danx@REDACTED Mon Oct 13 18:31:14 2003 From: chris.danx@REDACTED (chris.danx) Date: Mon, 13 Oct 2003 17:31:14 +0100 Subject: Silly Qn': Process exits at spawn Message-ID: <3F8AD352.7050409@ntlworld.com> Hi, What's wrong with this module? I've not played with erlang in ages and even then only for a few days. The problem seems to be that the registered process exists at spawn or very quickly but I don't understand why. Can someone please tell me what is wrong? -module(neural). -export([create_registry/0, stop_registry/0, registry_loop/1, add_neuron/1, registered_neurons/0]). create_registry () -> Pid = spawn (neural, registry_loop, []), register (neural_registry, Pid). stop_registry () -> neural_registry ! stop. add_neuron (Name) -> neural_registry ! {self(), add, Name}. registered_neurons () -> neural_registry ! {self(), reg_neurons}, receive {Registry, Vals} -> Vals end. registry_loop(Val) -> receive {From, add, Name} -> registry_loop (lists:append (Val, Name)); stop -> true; Other -> registry_loop (Val) end. Thanks, Chris From peter@REDACTED Mon Oct 13 18:59:48 2003 From: peter@REDACTED (Peter Lund) Date: Mon, 13 Oct 2003 17:59:48 +0100 (BST) Subject: Silly Qn': Process exits at spawn In-Reply-To: <3F8AD352.7050409@ntlworld.com> References: <3F8AD352.7050409@ntlworld.com> Message-ID: <17002.149.254.120.136.1066064388.squirrel@www.lundata.se> You spawn trying to call neural:registry_loop/0 (without params), but you have only defined a .../1 that takes one param. That explains the crash... > Hi, > > What's wrong with this module? I've not played with erlang in ages and > even then only for a few days. The problem seems to be that the > registered process exists at spawn or very quickly but I don't > understand why. Can someone please tell me what is wrong? > > > -module(neural). > -export([create_registry/0, > stop_registry/0, > registry_loop/1, > add_neuron/1, > registered_neurons/0]). > > create_registry () -> > Pid = spawn (neural, registry_loop, []), > register (neural_registry, Pid). > > > stop_registry () -> > neural_registry ! stop. > > > add_neuron (Name) -> > neural_registry ! {self(), add, Name}. > > > registered_neurons () -> > neural_registry ! {self(), reg_neurons}, > receive > {Registry, Vals} -> > Vals > end. > > registry_loop(Val) -> > receive > {From, add, Name} -> > registry_loop (lists:append (Val, Name)); > stop -> > true; > Other -> > registry_loop (Val) > end. > > > Thanks, > Chris From sean.hinde@REDACTED Mon Oct 13 18:56:23 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 13 Oct 2003 17:56:23 +0100 Subject: Silly Qn': Process exits at spawn In-Reply-To: <3F8AD352.7050409@ntlworld.com> Message-ID: <2D1AF7F8-FD9E-11D7-8668-000A95927CCE@mac.com> You are starting your process with a none existing registry_loop/0. If you have sasl running, and use proc_lib:spawn, rather than spawn you get nice error messsages. Sean On Monday, October 13, 2003, at 05:31 pm, chris.danx wrote: > Hi, > > What's wrong with this module? I've not played with erlang in ages > and even then only for a few days. The problem seems to be that the > registered process exists at spawn or very quickly but I don't > understand why. Can someone please tell me what is wrong? > > > -module(neural). > -export([create_registry/0, > stop_registry/0, > registry_loop/1, > add_neuron/1, > registered_neurons/0]). > > create_registry () -> > Pid = spawn (neural, registry_loop, []), > register (neural_registry, Pid). > > > stop_registry () -> > neural_registry ! stop. > > > add_neuron (Name) -> > neural_registry ! {self(), add, Name}. > > > registered_neurons () -> > neural_registry ! {self(), reg_neurons}, > receive > {Registry, Vals} -> > Vals > end. > > registry_loop(Val) -> > receive > {From, add, Name} -> > registry_loop (lists:append (Val, Name)); > stop -> > true; > Other -> > registry_loop (Val) > end. > > > Thanks, > Chris > From mickael.remond@REDACTED Mon Oct 13 19:04:27 2003 From: mickael.remond@REDACTED (Mickael Remond) Date: Mon, 13 Oct 2003 19:04:27 +0200 Subject: Silly Qn': Process exits at spawn In-Reply-To: <3F8AD352.7050409@ntlworld.com> References: <3F8AD352.7050409@ntlworld.com> Message-ID: <20031013170427.GD5203@cgey.com> * chris.danx [2003-10-13 17:31:14 +0100]: > Hi, > > What's wrong with this module? I've not played with erlang in ages and > even then only for a few days. The problem seems to be that the > registered process exists at spawn or very quickly but I don't > understand why. Can someone please tell me what is wrong? > > > -module(neural). > -export([create_registry/0, > stop_registry/0, > registry_loop/1, > add_neuron/1, > registered_neurons/0]). > > create_registry () -> > Pid = spawn (neural, registry_loop, []), => Your calling registry_loop/0 here which does not exist. > register (neural_registry, Pid). > > > stop_registry () -> > neural_registry ! stop. > > > add_neuron (Name) -> > neural_registry ! {self(), add, Name}. > > > registered_neurons () -> > neural_registry ! {self(), reg_neurons}, > receive > {Registry, Vals} -> > Vals > end. > > registry_loop(Val) -> > receive > {From, add, Name} -> > registry_loop (lists:append (Val, Name)); > stop -> > true; > Other -> > registry_loop (Val) > end. > > > Thanks, Your are welcome, -- Micka?l R?mond http://www.erlang-projects.org/ From svg@REDACTED Mon Oct 13 18:44:33 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Mon, 13 Oct 2003 22:44:33 +0600 (YEKST) Subject: Silly Qn': Process exits at spawn In-Reply-To: <3F8AD352.7050409@ntlworld.com> References: <3F8AD352.7050409@ntlworld.com> Message-ID: <20031013.224433.71109063.svg@surnet.ru> Good day, You have yet another error at lists:append/2 in registry_loop/1. This code would work only if add_neuron (Name) -> neural_registry ! {self(), add, [Name]}. rewrite as ... registry_loop ([Name|Val]); ... and do lists:reverse(Val) in registered_neurons/0 or ... registry_loop (lists:append(Val,[Name])); ... lists:append(List1, List2) is also equivalent for List1 ++ List2 Best Regards, Vladimir Sekissov chris.danx> -module(neural). chris.danx> -export([create_registry/0, chris.danx> stop_registry/0, chris.danx> registry_loop/1, chris.danx> add_neuron/1, chris.danx> registered_neurons/0]). chris.danx> chris.danx> create_registry () -> chris.danx> Pid = spawn (neural, registry_loop, []), chris.danx> register (neural_registry, Pid). chris.danx> chris.danx> chris.danx> stop_registry () -> chris.danx> neural_registry ! stop. chris.danx> chris.danx> chris.danx> add_neuron (Name) -> chris.danx> neural_registry ! {self(), add, Name}. chris.danx> chris.danx> chris.danx> registered_neurons () -> chris.danx> neural_registry ! {self(), reg_neurons}, chris.danx> receive chris.danx> {Registry, Vals} -> chris.danx> Vals chris.danx> end. chris.danx> chris.danx> registry_loop(Val) -> chris.danx> receive chris.danx> {From, add, Name} -> chris.danx> registry_loop (lists:append (Val, Name)); chris.danx> stop -> chris.danx> true; chris.danx> Other -> chris.danx> registry_loop (Val) chris.danx> end. chris.danx> chris.danx> chris.danx> Thanks, chris.danx> Chris chris.danx> From cyberlync@REDACTED Mon Oct 13 19:53:01 2003 From: cyberlync@REDACTED (Eric Merritt) Date: Mon, 13 Oct 2003 10:53:01 -0700 (PDT) Subject: Spatial Indexes in mnesia Message-ID: <20031013175301.19296.qmail@web40809.mail.yahoo.com> Just out of curiosity doesn mnesia support spatial indexes on data. The docs don't make any mention of it, but I thought it was worth asking in any case. Back in 2001 there was a bit of discussion on the list about it but there doesn't seem to be any solutions. In either case, its simple enough to use postgre or mysql but it would be nice to use mnesia ;) __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From vances@REDACTED Mon Oct 13 20:22:13 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 13 Oct 2003 14:22:13 -0400 Subject: Erlang is getting too big In-Reply-To: References: <219ABE6A-FD67-11D7-8668-000A95927CCE@mac.com> Message-ID: <20031013182213.GH91573@frogman.motivity.ca> On Mon, Oct 13, 2003 at 02:38:36PM +0200, Joe Armstrong wrote: } } I think it would greatly improve things if we could release the } basic language stuff, OTP and the applications separately - so that the" } distinctions become clearer. I could't agree more. The fact that if one were to want to take Erlang for a test drive that they would find themselves building things with Java, CORBA, SNMP, etc. is exactly what Sean is warning about. I think it is important to understand what OTP is (and isn't). This is difficult for people new to the environment as it is because there are no clear lines. Having an erlang:spawn and a proc_lib:spawn is just confusing when you're just trying to learn the language. A core language distribution would make things much clearer. As to the addition of new features I wouldn't want to think that we were going to stagnate. What of try/cond which have been on the way for a long time? I'd like to see them added. -Vance From sean.hinde@REDACTED Mon Oct 13 20:49:55 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 13 Oct 2003 19:49:55 +0100 Subject: Erlang is getting too big In-Reply-To: <20031013182213.GH91573@frogman.motivity.ca> Message-ID: <098CEDD8-FDAE-11D7-8668-000A95927CCE@mac.com> On Monday, October 13, 2003, at 07:22 pm, Vance Shipley wrote: > On Mon, Oct 13, 2003 at 02:38:36PM +0200, Joe Armstrong wrote: > } > } I think it would greatly improve things if we could release the > } basic language stuff, OTP and the applications separately - so that > the" > } distinctions become clearer. > > > I could't agree more. The fact that if one were to want to take Erlang > for a test drive that they would find themselves building things with > Java, CORBA, SNMP, etc. is exactly what Sean is warning about. Err, actually it isn't. This is what Joe is worrying about. I am more concerned about there being so much syntax - wayyy before getting as far as libraries. > > I think it is important to understand what OTP is (and isn't). This is > difficult for people new to the environment as it is because there are > no clear lines. Having an erlang:spawn and a proc_lib:spawn is just > confusing when you're just trying to learn the language. A core > language distribution would make things much clearer. But then what would distinguish it from the other 500 languages out there? This needs a book, or a lightweight way into OTP, not discarding it. > > As to the addition of new features I wouldn't want to think that we > were going to stagnate. What of try/cond which have been on the way > for a long time? I'd like to see them added. To join begin ... end, which I've never figured out the point of? What was that about Perl - a hundred different ways to achieve the same thing? If try/cond is a true revolution in clarity and "so obvious it must be correct" programming, and can replace a couple of other structures then yes, but otherwise no. I don't want to see Erlang stagnate at all. I just think we are loading it down so much it is starting to sink under its own weight. Sean From david.wallin@REDACTED Mon Oct 13 21:22:34 2003 From: david.wallin@REDACTED (David Wallin) Date: Mon, 13 Oct 2003 20:22:34 +0100 Subject: problem with gethostbyname/1 Message-ID: <7a2b12ab84904dab6702e6ef43415cb7@wintermute> Hi all, This is under Gentoo Linux (2.4.20) Pentium 4, could someone give me a clue as to why this happens: Eshell V5.3 (abort with ^G) 1> inet:gethostbyname("wintermute"). {error,nxdomain} 2> inet_res:gethostbyname("wintermute"). {ok,{hostent,"wintermute.csis.ul.ie",[],inet,4,[{136,201,24,71}]}} 3> halt(). cheers, --david. From robert.virding@REDACTED Mon Oct 13 21:26:56 2003 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 13 Oct 2003 21:26:56 +0200 Subject: Erlang is getting too big References: <20031013131522.1030.qmail@web40812.mail.yahoo.com> Message-ID: <007701c391bf$f74ff7a0$2100a8c0@virding.org> ----- Original Message ----- From: "Eric Merritt" To: Sent: Monday, October 13, 2003 3:15 PM Subject: Re: Erlang is getting too big > Why is it impossible to take something away? If you > give ample warning, say depricating a feature two or > three releases before it goes away, and provide a very > clear migration path to new features it should not be > a problem to remove features. If a client doesn't want > to modify his source he always has the option of not > upgrading past the point where a depricated feature is > removed. Have you ever tried to remove, or change, anything in a distribution. I think not. It is in principle impossible to make a backwards incompatible change, no matter how sesnible and approved. I know I have tried for many years when I was working with it. That is one reason why the language keeps growing, you can add improvements but can't remove the old stuff. We were very restrictive in adding new stuff but some things slipped through and got a user base before they could be cleaned up. It's a bit like the urban legend about Make. Robert From chris.danx@REDACTED Mon Oct 13 21:35:14 2003 From: chris.danx@REDACTED (chris.danx) Date: Mon, 13 Oct 2003 20:35:14 +0100 Subject: Silly Qn': Process exits at spawn In-Reply-To: <3F8AD352.7050409@ntlworld.com> References: <3F8AD352.7050409@ntlworld.com> Message-ID: <3F8AFE72.4020801@ntlworld.com> Thanks folks, it runs now! Can anyone help with another problem? I've probably done something stupid again. The following code is supposed to query the server if a neuron with the given name exists and if it does, return false. If the neuron doesn't exist, it creates a new neuron one (a process) and returns. The problem I'm having is finding where abouts the hang occurs. Does anyone have any tips for debugging Erlang? I think it fails to receive the {Reg, Exists} message in create neuron, but I could be wrong. %% create a neuron % create_neuron (Name, State, OutputFunc) -> neural_registry ! {self(), exists, Name}, receive {Reg, Exists} -> if Exists == true -> false; true -> {X, Pid} = neurons:create_neuron(Name, State, OutputFunc), add_neuron_to_reg ({X, Pid}) end end. %% add neuron to registry % add_neuron_to_reg ({Name, Pid}) -> neural_registry ! {self(), add, {Name, Pid}}, receive {Reg, Succ} -> Succ end. registry_loop(Val) -> receive % add neuron to list % {From, add, {Name, Pid}} -> P = [{Name, Pid}] ++ Val, From ! {self(), true}, registry_loop (P); % % {From, remove, Name} -> {X, P} = get_neuron_and_remaining (Val, Name, []), if X == nil -> From ! {self(), false}; true -> From ! {self(), true} end, registry_loop (X); % retrieve registered neurons % {From, reg_neurons} -> From ! {self(), Val}, registry_loop (Val); % return true if neuron exists, false otherwise % {From, exists, Name} -> From ! {self(), false}, registry_loop (Val); % stop registry. % stop -> true; % just loop. % Other -> registry_loop (Val) end. Cheers, Chris From vances@REDACTED Mon Oct 13 21:34:26 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 13 Oct 2003 15:34:26 -0400 Subject: Erlang is getting too big In-Reply-To: <098CEDD8-FDAE-11D7-8668-000A95927CCE@mac.com> References: <20031013182213.GH91573@frogman.motivity.ca> <098CEDD8-FDAE-11D7-8668-000A95927CCE@mac.com> Message-ID: <20031013193426.GO3765@frogman.motivity.ca> On Mon, Oct 13, 2003 at 07:49:55PM +0100, Sean Hinde wrote: } } On Monday, October 13, 2003, at 07:22 pm, Vance Shipley wrote: } > } >I could't agree more. The fact that if one were to want to take Erlang } >for a test drive that they would find themselves building things with } >Java, CORBA, SNMP, etc. is exactly what Sean is warning about. } } Err, actually it isn't. This is what Joe is worrying about. I am more } concerned about there being so much syntax - wayyy before getting as } far as libraries. OK, however I believe it has the same effect. } But then what would distinguish it from the other 500 languages out } there? This needs a book, or a lightweight way into OTP, not discarding } it. I certainly have no interest in discarding OTP! It is OTP which drew me to Erlang in the first place. By having an Erlang without an OTP I believe it makes it much clearer what OTP is. } To join begin ... end, which I've never figured out the point of? I've used begin before in this sort of way: init() -> case catch begin case foo:init() of ok -> ok; _ -> throw(foo) end, case bar:init() of ok -> ok; _ -> throw(bar) end, end of ok -> ok; Error -> io:fwrite("module ~w failed to initialize~n", [Module]) end. That's not really a good example of the "Erlang way" of error handling however it demonstrates the use of 'begin'. Good examples are the best way of demonstrating the application of these things. I think the following is a good one. For a long time I couldn't figure out what 'if' brought to the table. It seemed totally redundant with 'case'. Over the years I have used 'if' more and more. A few days ago I wrote the following and was very happy with the clear expressiveness it achieved: if not ConnectionOriented and not SequenceControl -> Class = 0; not ConnectionOriented and SequenceControl -> Class = 1; ConnectionOriented and not SequenceControl -> Class = 2; ConnectionOriented and SequenceControl -> Class = 3 end, Yes, it could have been written using case: case ConnectionOriented of false -> case SequenceControl of false -> Class = 0; true -> Class = 1 end; true -> case SequenceControl of false -> Class = 2; true -> Class = 3 end end, I think you'll agree the former is much clearer. -Vance From sean.hinde@REDACTED Mon Oct 13 21:46:27 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 13 Oct 2003 20:46:27 +0100 Subject: problem with gethostbyname/1 In-Reply-To: <7a2b12ab84904dab6702e6ef43415cb7@wintermute> Message-ID: On Monday, October 13, 2003, at 08:22 pm, David Wallin wrote: > Hi all, > > This is under Gentoo Linux (2.4.20) Pentium 4, could someone give me a > clue as to why this happens: > > Eshell V5.3 (abort with ^G) > 1> inet:gethostbyname("wintermute"). > {error,nxdomain} > 2> inet_res:gethostbyname("wintermute"). > {ok,{hostent,"wintermute.csis.ul.ie",[],inet,4,[{136,201,24,71}]}} > 3> halt(). > Erlang has a ton of different ways to do name lookup, though the whole mechanism for choosing which one(s) are used appear to be undocumented, and it involves digging around in all sorts of UNIX files in /etc and elsewhere. You can find out which methods are being used with 1> inet_db:res_option(lookup). [native,file] (example from my mac) And force a setting by creating a .inetrc file in your home directory containing: {lookup, ["native", "file"]}. Options appear to be: "bind", "dns", "hosts", "files", "file", "yp", "nis", "nisplus", "native" Some mechanisms appear to use internal dns code, others spawn external port programs. It is a bit of a minefield but there may be enough clues to sort it out. My sympathies! Sean From vances@REDACTED Mon Oct 13 22:19:09 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 13 Oct 2003 16:19:09 -0400 Subject: Application directory heirachy Message-ID: <20031013201909.GA36063@frogman.motivity.ca> The Design Principles document describes the directory structure of an application quite differently than what is found in the distribution: The application directory have the following sub-directories: src ebin priv include src Contains the Erlang source code. If source code is written in several different languages, a sub-directory with the name e_src can be created below the src directory to store the Erlang source code. In the R9C-0 distribution we find a different practice. The src directories for Erlang files are always "src" while other languages are at the same level with names like c_src and java_src: asn1/c_src asn1/src ic/c_src ic/java_src ic/src orber/c_src orber/java_src orber/src Did this change at some point? I seem to remember e_src directories however maybe they were just mine created with the above guidlines. -Vance [ This would be an OTP question as opposed to an Erlang one. I have ] [ long advocated a seperate list for OTP questions which I believe ] [ would help with the distinction. This is apparently not a popular ] [ view however. ] From david.wallin@REDACTED Mon Oct 13 22:27:25 2003 From: david.wallin@REDACTED (david wallin) Date: Mon, 13 Oct 2003 21:27:25 +0100 Subject: problem with gethostbyname/1 In-Reply-To: Message-ID: Sean, This is on my Linux box (before): Eshell V5.3 (abort with ^G) 1> inet_db:res_option(lookup). [] I added '{lookup, ["file","dns"]}.' to the '.inetrc' file, and now gethostbyname/1 works like a charm. Even net_adm:ping/1 works, which is nice :-) thanks a million, --david. On Monday, October 13, 2003, at 08:46 PM, Sean Hinde wrote: > > On Monday, October 13, 2003, at 08:22 pm, David Wallin wrote: > >> Hi all, >> >> This is under Gentoo Linux (2.4.20) Pentium 4, could someone give me >> a clue as to why this happens: >> >> Eshell V5.3 (abort with ^G) >> 1> inet:gethostbyname("wintermute"). >> {error,nxdomain} >> 2> inet_res:gethostbyname("wintermute"). >> {ok,{hostent,"wintermute.csis.ul.ie",[],inet,4,[{136,201,24,71}]}} >> 3> halt(). >> > > Erlang has a ton of different ways to do name lookup, though the whole > mechanism for choosing which one(s) are used appear to be > undocumented, and it involves digging around in all sorts of UNIX > files in /etc and elsewhere. You can find out which methods are being > used with > > 1> inet_db:res_option(lookup). > [native,file] > > (example from my mac) > > And force a setting by creating a .inetrc file in your home directory > containing: > > {lookup, ["native", "file"]}. > > Options appear to be: > > "bind", "dns", "hosts", "files", "file", "yp", "nis", "nisplus", > "native" > > Some mechanisms appear to use internal dns code, others spawn external > port programs. It is a bit of a minefield but there may be enough > clues to sort it out. > > My sympathies! > > Sean From sean.hinde@REDACTED Mon Oct 13 22:30:20 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 13 Oct 2003 21:30:20 +0100 Subject: Erlang is getting too big In-Reply-To: <200310131956.h9DJuZlU003344@harpo.it.uu.se> Message-ID: <10ABBB9A-FDBC-11D7-8668-000A95927CCE@mac.com> On Monday, October 13, 2003, at 08:56 pm, Kostis Sagonas wrote: > On Mon, 13 Oct 2003, Sean Hinde wrote: >> >> I think there is and has been quite a bit of action since the bit >> syntax. Duplicate guards, much new syntactic sugar for record >> operations #rec{_ = xx}, Java style module naming, soon to be more >> syntactic sugar for guards, Parameterised modules.. Some of these new >> features have led to head scratching and questions to me from folks >> here learning Erlang in the last few weeks. I think we *are* in severe >> danger of making the core language "too big". >> >> We haven't "taken anything out of the language" to add any of these >> things, and none of them add new capabilities to the language. All of >> them must be understood by anyone learning Erlang, and already they >> cannot all be taught in a week. > > Although I sympathise with Sean's concerns to some extent, I am having > trouble sharing all his worries. Erlang is a small language and I fail > to see why some of the "recently added features" are needed to be > taught > in a course that introduces the language to developers, or scare away > people. I don't think the language is actually that small anymore.. One reason for the training issue is that these people are more and more likely to find their first job is maintaining code from others. If there are basic syntax features which can't be fitted in the course it leads to a sense of "well, what else was left out?", and "will I ever figure out the whole thing?". This is the feedback I am getting from our newcomers. > > Some examples to illustrate my point: > > 1. "Duplicate guards": There is absolutely no need to teach the old > guards. Simply introduce the new is_* ones! > > 2. "Java style module naming" > Is this so difficult a concept to grasp? > If one thinks the answer is NO, then what's the problem? > If the answer is YES, then is there really needed for this > concept to be mentioned to somebody who wants to find out > what Erlang is all about? Maintenance again, and an increasing danger of making code less readable. > > 3. "Parameterized modules" > This extension is not even available anywhere yet... it is > already being taught in courses? No, but it is a proposal which looks like it could well be on its way. I could list more examples, but my point is that the accumulation of features is the problem rather than any individual new feature. Erlang is really only just getting started in the outside world and its size is causing problems already. > PS. On Friday, I sent a mail about something I want added to the bit > syntax, but it is still unanswered ;-) I have come across this as well, and I agree with your suggestion. Sean From dvanhorn@REDACTED Mon Oct 13 21:35:50 2003 From: dvanhorn@REDACTED (David Van Horn) Date: Mon, 13 Oct 2003 14:35:50 -0500 Subject: Relation to Pi Calculus Message-ID: <3F8AFE96.6050703@cs.uvm.edu> I've heard that Erlang is essentially an implementation of the untyped pi calculus. Is this a fair characterization? Which variant of the pi calculus most closely resembles Erlang (eg, asynchronous pi, distributed pi, seal, join, etc.)? Could someone provide examples of Erlang primitives that closely rememble the pi calculus primitives: input, output, and restriction? Does a formal semantics of core Erlang exist, and if so where? Thanks in advance. -d From kostis@REDACTED Mon Oct 13 21:56:35 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 13 Oct 2003 21:56:35 +0200 (MEST) Subject: Erlang is getting too big In-Reply-To: Mail from 'Sean Hinde ' dated: Mon, 13 Oct 2003 14:46:24 +0100 Message-ID: <200310131956.h9DJuZlU003344@harpo.it.uu.se> On Mon, 13 Oct 2003, Sean Hinde wrote: > > I think there is and has been quite a bit of action since the bit > syntax. Duplicate guards, much new syntactic sugar for record > operations #rec{_ = xx}, Java style module naming, soon to be more > syntactic sugar for guards, Parameterised modules.. Some of these new > features have led to head scratching and questions to me from folks > here learning Erlang in the last few weeks. I think we *are* in severe > danger of making the core language "too big". > > We haven't "taken anything out of the language" to add any of these > things, and none of them add new capabilities to the language. All of > them must be understood by anyone learning Erlang, and already they > cannot all be taught in a week. Although I sympathise with Sean's concerns to some extent, I am having trouble sharing all his worries. Erlang is a small language and I fail to see why some of the "recently added features" are needed to be taught in a course that introduces the language to developers, or scare away people. Some examples to illustrate my point: 1. "Duplicate guards": There is absolutely no need to teach the old guards. Simply introduce the new is_* ones! [In fact, this is exaclty the point where the OTP team could have been more agressive in issuing *warnings* about using old guards, so that applications would be forced to upgrade sooner... but I guess they want to be spared the hassle from the (paying) user community. This way, things could even possibly be removed from the language, and there would not even be a need to mention the existence of the old ones.] 2. "Java style module naming" Is this so difficult a concept to grasp? If one thinks the answer is NO, then what's the problem? If the answer is YES, then is there really needed for this concept to be mentioned to somebody who wants to find out what Erlang is all about? 3. "Parameterized modules" This extension is not even available anywhere yet... it is already being taught in courses? Is there something I am missing? Cheers, Kostis PS. On Friday, I sent a mail about something I want added to the bit syntax, but it is still unanswered ;-) From svg@REDACTED Mon Oct 13 22:03:12 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Tue, 14 Oct 2003 02:03:12 +0600 (YEKST) Subject: Erlang is getting too big In-Reply-To: <20031013193426.GO3765@frogman.motivity.ca> References: <20031013182213.GH91573@frogman.motivity.ca> <098CEDD8-FDAE-11D7-8668-000A95927CCE@mac.com> <20031013193426.GO3765@frogman.motivity.ca> Message-ID: <20031014.020312.74729045.svg@surnet.ru> vances> if vances> not ConnectionOriented and not SequenceControl -> Class = 0; vances> not ConnectionOriented and SequenceControl -> Class = 1; vances> ConnectionOriented and not SequenceControl -> Class = 2; vances> ConnectionOriented and SequenceControl -> Class = 3 vances> end, How about :) Class = case {ConnectionOriented, SequenceControl} of {false, false} -> 0; {false, true} -> 1; {true, false} -> 2; {true, true} -> 4 end, Best Regards, Vladimir Sekissov From francesco@REDACTED Tue Oct 14 00:15:24 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Mon, 13 Oct 2003 23:15:24 +0100 Subject: Erlang is getting too big References: <10ABBB9A-FDBC-11D7-8668-000A95927CCE@mac.com> Message-ID: <3F8B23FC.30803@erlang-consulting.com> Finally the subject comes to light. And sadly enough, 90% of Erlang users are not able to defend themselves... Why? Because they are not on the mailing list. When they first study Erlang, they struggle to understand recursion. Pattern matching is some form of black magic they do not trust, let alone concurrency. LCs? Let's not even go there. In the good old days, they would attend three courses over a 6 months period and have all the time on this planet to learn (Ironically, when the language was compact). Today, if they are lucky, they might get a 5 day course, OTP included. I work with these people on a daily basis. They support and maintain Erlang programs, possibly write them as well. Most enjoy their job, but will not go pondering day and night over problems and potential solutions like most of us do. At 5pm they clock off, and until they log on the following morning, Erlang does not even cross their mind. It was for these people Erlang was originally developed and kept simple. It was for this reason OTP was developed (Some parts were successful, others weren't). Now when there are organizations supporting 20+ erlang products or systems consisting of millions of lines of code, these issues become very relevant. These people must have the chance of going into the code, understanding what is going on, and finding the bugs because development can not jump in and act as heroes all the time. After all, that is where 70% of the cost of the software cycle is. And to reduce this cost, one has to stop increasing the complexity of the language. Only well thought and necessary additions should be included... Things that will simplify the code, not make it more complex. Things such as List (In)Comprehensions are powerful if you know what you are doing. Parameterised modules as well if you are a hacker. But alas, they do not fit in the jungle of large scale software design for which Erlang was intended. Concepts such as packages should have integrated in OTP, as OTP is there to solve these problems. A bit more throughout should have gone into adding records, extra guards, macros and include files. And a lot more thought should be put in before adding parametersed modules and the new type syntax are included. Francesco -- http://www.erlang-consulting.com From ok@REDACTED Tue Oct 14 01:57:58 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 14 Oct 2003 12:57:58 +1300 (NZDT) Subject: Erlang is getting too big Message-ID: <200310132357.h9DNvwE4238123@atlas.otago.ac.nz> Kostis Sagonas wrote: 1. "Duplicate guards": There is absolutely no need to teach the old guards. Simply introduce the new is_* ones! Is there something I am missing? Er, yes. A textbook. Myself, I don't see the new is_* guards as a significant improvement on the old ones, and in the admittedly modest amount of Erlang code I write, I stick with what's described in the Erlang book. Perhaps it is time for a new edition of the Erlang book. From luke@REDACTED Tue Oct 14 04:42:29 2003 From: luke@REDACTED (Luke Gorrie) Date: 14 Oct 2003 04:42:29 +0200 Subject: Erlang is getting too big In-Reply-To: <3F8B23FC.30803@erlang-consulting.com> References: <10ABBB9A-FDBC-11D7-8668-000A95927CCE@mac.com> <3F8B23FC.30803@erlang-consulting.com> Message-ID: Francesco Cesarini writes: > Things such as List (In)Comprehensions are powerful if you know what > you are doing. Out of curiosity, what is it you don't like about list comprehensions? Just one more thing to learn, or do you think they're particularly confusing in practice even if you've read how they work? They definitely are one more thing to learn. But assuming you've read the basics, I think list comprehensions with only one generator are really easy to understand - just a straight-forward combination of map and filter. Initially I found multiple generators difficult to understand, until I was shown that it's the same thing as nested loops. So: [{X,Y} || X <- list1(), Y <- list2(), test(X, Y)] is like, in pseudo-code: results = empty() for X in list1() for Y in list2() if test(X, Y) then results.add({X, Y}) return results with one extra nested loop for each generator. That makes it pretty understandable for me, even though I rarely find a use for multiple generators in practice. Cheers, Luke From francesco@REDACTED Tue Oct 14 08:24:53 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 14 Oct 2003 07:24:53 +0100 Subject: Erlang is getting too big References: <10ABBB9A-FDBC-11D7-8668-000A95927CCE@mac.com> <3F8B23FC.30803@erlang-consulting.com> Message-ID: <3F8B96B5.4000504@erlang-consulting.com> > > >>Things such as List (In)Comprehensions are powerful if you know what >>you are doing. >> >> > >Out of curiosity, what is it you don't like about list comprehensions? >Just one more thing to learn, or do you think they're particularly >confusing in practice even if you've read how they work? > I *love* list comprehensions. Back in 95, I spent sleepless nights trying to solve the 8 queens problem. If I have a bright class, I will be the first so show them pivot sort. The same applies to funs and higher order functions. However, less than 5% of programmers end up using LCs, if not less. People who are struggling to come to term with the rest of the language don't, as it is yet another thing to take in. Something they can solve with recursion. Interesting enough, two of the last three major projects (50+ people) I worked in, list comprehensions were banned to avoid a minority of the people using a majority of the language (There were also efficiency problems at the time which have now been solved). If you really have to add something new to the language, add Dynamic Records Joe has privately talked to people about. They are brilliant and a perfect semantical fit to Erlang. Francesco -- http://www.erlang-consulting.com From thomasl_erlang@REDACTED Tue Oct 14 08:47:43 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 13 Oct 2003 23:47:43 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: <200310131956.h9DJuZlU003344@harpo.it.uu.se> Message-ID: <20031014064743.90773.qmail@web41901.mail.yahoo.com> --- Kostis Sagonas wrote: > 1. "Duplicate guards": There is absolutely no > need to teach the old > guards. Simply introduce the new is_* ones! Why introduce the is_* guards in the first place? I don't see the point. Here's another part that could stand cleaning up: - guard syntax 1: "," and ";" - guard syntax 2: "and", "or" (are they there anymore?) - expression syntax 1: "and", "or" - expression syntax 2: "andalso", "orelse" All of them working somewhat differently. My modest proposal: - drop is_* guards (unless there is a pressing reason to keep them?) - get rid of strict and/or in expressions and move andalso/orelse to "and"/"or". This just seems to be a bug cast in stone. - write guards as arbitrarily nested (G1,G2) and (G1;G2) and drop the and/or-syntax in guards. All of these get rid of unnecessary complexity of Erlang. > 2. "Java style module naming" > Is this so difficult a concept to grasp? Given the semantic problems of Erlang packages, I'm afraid it is :-) Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From raimo@REDACTED Tue Oct 14 09:10:40 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Tue, 14 Oct 2003 09:10:40 +0200 Subject: problem with gethostbyname/1 References: , Message-ID: Hi, could you please try {lookup,["native","file"]} also. The "native" resolver uses the built-in (native) resolver in the OS. This is what generally works best, especially in comparision to non-erlang applications. The "file" option is just a fallback, the "native" resolver also most probably uses the /etc/host file at some point, which is what the "file" option does. If the "native" resolver does not work fine, you probably have a misconfigured Linux box. The fact that Erlang before your change had an empty lookup option also suggests that something in your network configuration may be weird. The default Erlang behaviour is to mimic the native resolver, but internally, since before R9B (I think) the native resolver had performance problems. Not anymore. If you keep using the "dns" option, be warned that you are using an internal DNS client that may not behave as the rest of the applications on the Linux box (that uses the native resolver). I have never come across a Gentoo Linux box before. Could you dump the following files as well as the output from os:type() and send to me? /etc/hosts /etc/resolv.conf /etc/host.conf /etc/nsswitch.conf /etc/irs.conf If you know of some other /etc file that Gentoo Linux uses for network configuration that is not among the above, throw it in too. Sorry about the lack of documentation, but this part of the system is just a mess that we have wanted to rewrite for a long time, but dare not since it might break for some paying customer. Therefore we have not come around to documenting it either. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB david wallin wrote: > Sean, > > This is on my Linux box (before): > > Eshell V5.3 (abort with ^G) > 1> inet_db:res_option(lookup). > [] > > I added '{lookup, ["file","dns"]}.' to the '.inetrc' file, and now > gethostbyname/1 works like a charm. Even net_adm:ping/1 works, which is > nice :-) > > thanks a million, > > --david. > > > > On Monday, October 13, 2003, at 08:46 PM, Sean Hinde wrote: > >> >> On Monday, October 13, 2003, at 08:22 pm, David Wallin wrote: >> >>> Hi all, >>> >>> This is under Gentoo Linux (2.4.20) Pentium 4, could someone give me >>> a clue as to why this happens: >>> >>> Eshell V5.3 (abort with ^G) >>> 1> inet:gethostbyname("wintermute"). >>> {error,nxdomain} >>> 2> inet_res:gethostbyname("wintermute"). >>> {ok,{hostent,"wintermute.csis.ul.ie",[],inet,4,[{136,201,24,71}]}} >>> 3> halt(). >>> >> >> Erlang has a ton of different ways to do name lookup, though the whole >> mechanism for choosing which one(s) are used appear to be >> undocumented, and it involves digging around in all sorts of UNIX >> files in /etc and elsewhere. You can find out which methods are being >> used with >> >> 1> inet_db:res_option(lookup). >> [native,file] >> >> (example from my mac) >> >> And force a setting by creating a .inetrc file in your home directory >> containing: >> >> {lookup, ["native", "file"]}. >> >> Options appear to be: >> >> "bind", "dns", "hosts", "files", "file", "yp", "nis", "nisplus", "native" >> >> Some mechanisms appear to use internal dns code, others spawn external >> port programs. It is a bit of a minefield but there may be enough >> clues to sort it out. >> >> My sympathies! >> >> Sean > > From vlad_dumitrescu@REDACTED Tue Oct 14 09:11:24 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 14 Oct 2003 09:11:24 +0200 Subject: Erlang is getting too big References: <20031014064743.90773.qmail@web41901.mail.yahoo.com> Message-ID: From: "Thomas Lindgren" > - get rid of strict and/or in expressions and move > andalso/orelse to "and"/"or". This just seems to be a > bug cast in stone. > > - write guards as arbitrarily nested (G1,G2) and > (G1;G2) and drop the and/or-syntax in guards. > > All of these get rid of unnecessary complexity of > Erlang. Maybe "get rid of" is too much, considering backwards compatibility, but these could at least be *strongly* recommended in the Style Guidelines and at the courses? BTW, where did the style guildelines go? They are only present on the website - shouldn't they be part of the docs? regards, Vlad From thomasl_erlang@REDACTED Tue Oct 14 09:11:40 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 14 Oct 2003 00:11:40 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: <007701c391bf$f74ff7a0$2100a8c0@virding.org> Message-ID: <20031014071140.59435.qmail@web41902.mail.yahoo.com> --- Robert Virding wrote: > Have you ever tried to remove, or change, anything > in a distribution. > I think not. It is in principle impossible to make a > backwards > incompatible change, no matter how sesnible and > approved. I know > I have tried for many years when I was working with > it. That is one > reason why the language keeps growing, you can add > improvements > but can't remove the old stuff. Summary: how about doing structured language releases? Intro: I think you are being too pessimistic. The more recent releases of OTP are capable of warning about using obsolete stuff, which is what is needed. They also break existing code (cond :-). My experience is that new Erlang releases are not introduced into products willy-nilly anyway, but after a period of testing and perhaps porting. *Modest* changes to the source, including not relying on bugs or obsolete stuff, might be acceptable in this process. Changes to the language still need to be sensible to be accepted, of course. And your (deleted) point about new features escaping the lab too soon is well taken. Case in point: records = tuples. The point: There is an ad hoc way to indicate which "version" of Erlang you want when you compile today. I think it would be a good idea to formalize this into structured language releases (one every few years), explicit notes of obsolete, non-portable or ephemeral features, etc. And, importantly, add a linter to detect non-compliant usage. Experimental additions could be done separately from mainline OTP, then be added to the language spec when accepted. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From thomasl_erlang@REDACTED Tue Oct 14 09:19:48 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 14 Oct 2003 00:19:48 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: Message-ID: <20031014071948.67552.qmail@web41905.mail.yahoo.com> --- Luke Gorrie wrote: > Francesco Cesarini > writes: > > > Things such as List (In)Comprehensions are > powerful if you know what > > you are doing. > > Out of curiosity, what is it you don't like about > list comprehensions? > Just one more thing to learn, or do you think > they're particularly > confusing in practice even if you've read how they > work? List comprehensions are very handy if one learns to use them. When they can be used, they are normally clearer than the corresponding map/filter or explicit function too. (There are some exceptions, e.g., when the expression part gets messy.) Often I use them for simple things, such as: NewMod = {Mod, Exp, [ annotate_form(Form) || Form <- Forms ], Misc} One of the good additions to Erlang, IMHO. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From vlad_dumitrescu@REDACTED Tue Oct 14 09:24:57 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 14 Oct 2003 09:24:57 +0200 Subject: Erlang is getting too big References: <10ABBB9A-FDBC-11D7-8668-000A95927CCE@mac.com> <3F8B23FC.30803@erlang-consulting.com> Message-ID: From: "Francesco Cesarini" > Finally the subject comes to light. And sadly enough, 90% of Erlang > users are not able to defend themselves... Why? Because they are not on > the mailing list. Very good points, and also from almost first-hand source (as you are teaching Erlang to many of the users you mention). > In the good old days, they would attend three courses over a 6 months > period and have all the time on this planet to learn (Ironically, when > the language was compact). Today, if they are lucky, they might get a 5 > day course, OTP included. Maybe it's just me, but I feel that there should be a much looser connection between the evolution of the language and the financial situation of the companies that are using it. However simple and compact a language might be, one can't expect 5 days of training to create experts. This is again the same issue: Erlang/OTP is a commercial system, which also has been released as open-source. Not the other way around. This means the commercial interests go before the others. This is completely understandable, and possibly one of the main reasons why Erlang is so good. > It was for these people Erlang was originally > developed and kept simple. It was for this reason OTP was developed > (Some parts were successful, others weren't). Absolutely true. On the other hand, I (and a few more, I guess) use it nowadays only in my spare time, so I can afford a more liberal approach. *** Is there a way to keep the balance, so that everybody is happy? I think Joe's (et al.) proposal of more clearly separating kernel Erlang from OTP would be one good way to go in that direction. Not only at the code level, but also above that. Unless of course, Erlang is seen as a necessary evil that is used to distribute OTP ;-) I'm babbling a little, but hopefully it's making some sense. * Keep Erlang easy to learn for total beginners? Yes, but then dumping the whole OTP on them at once might be a contradiction in terms. * Take away the "telecom" mark from Erlang and step into other areas? Yes, and again having to handle the whole OTP is somewhat working against that. * Leave open the chance to improve Erlang? Yes, the new stuff might be provided as a library, not as kernel language. best regards, Vlad From magnus@REDACTED Tue Oct 14 09:24:06 2003 From: magnus@REDACTED (=?ISO-8859-1?Q?Magnus_Fr=F6berg?=) Date: Tue, 14 Oct 2003 09:24:06 +0200 Subject: problem with gethostbyname/1 In-Reply-To: References: , Message-ID: <3F8BA496.3010300@bluetail.com> Raimo Niskanen wrote: > > I have never come across a Gentoo Linux box before. Could you dump the > following files as well as the output from os:type() and send to me? Hi we have done a fix to inet_config.erl for our Gentoo users. It seems like Gentoo does not have the /etc/host.conf file so we added usage of /etc/nsswitch.conf as well for 'linux' while configuring the inet_db. The diff below is against the R9C-0 version of inet_config.erl: Index: lib/kernel/src/inet_config.erl =================================================================== RCS file: /home/share/erlang/cvsroot/otp/lib/kernel/src/inet_config.erl,v retrieving revision 1.1.1.5 retrieving revision 1.7 diff -u -r1.1.1.5 -r1.7 --- lib/kernel/src/inet_config.erl 2 Sep 2003 13:34:18 -0000 1.1.1.5 +++ lib/kernel/src/inet_config.erl 3 Sep 2003 13:53:57 -0000 1.7 @@ -82,8 +82,13 @@ 'bsd/os' -> load_resolv(filename:join(Etc,"irs.conf"), host_conf_bsdos); linux -> - load_resolv(filename:join(Etc,"host.conf"),host_conf_linux), - + case load_resolv(filename:join(Etc,"host.conf"),host_conf_li nux) of + ok -> + ok; + _Other -> + load_resolv(filename:join(Etc,"nsswitch.conf"), nssw itch_conf) + end, + % It may be the case that the domain name was not set % because the hostname was short. But we can now look it % up and get the long name and the domain name from it. /Magnus -- Magnus Fr?berg Tel: +46 (0)8 545 55 026 Alteon WebSystems AB Email: magnus@REDACTED S:t Eriksgatan 44 SE-112 34 Stockholm, SWEDEN From thomasl_erlang@REDACTED Tue Oct 14 09:33:53 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 14 Oct 2003 00:33:53 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: <098CEDD8-FDAE-11D7-8668-000A95927CCE@mac.com> Message-ID: <20031014073353.3672.qmail@web41901.mail.yahoo.com> --- Sean Hinde wrote: > To join begin ... end, which I've never figured out > the point of? It's useful when you need to insert a sequence of expressions in places where just a single expression is expected. (This actually turns up every now and then.) Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From joe@REDACTED Tue Oct 14 10:01:42 2003 From: joe@REDACTED (Joe Armstrong) Date: Tue, 14 Oct 2003 10:01:42 +0200 (CEST) Subject: Erlang is getting too big (Long and a lot of shouting :-) In-Reply-To: <20031014064743.90773.qmail@web41901.mail.yahoo.com> Message-ID: Is Erlang big? Should it grow? Before we all get to overexcited about this I'd like to get my own 5 cents in ... When discussing language design/properties all things are not equally important - we are talking as if they were. For many years I have thought about what makes a language successful. Here are two good answers: 1) - Somebody makes money by using language X 2) - X is superbly good at solving some particular problem that no other language can solve adequately The guy who say 1) also said (paraphrased) " I became interested in Erlang because I discovered that people were prepared to invest their own $ in it". For point 2) - sure you can write anything in any language (Turing equivalence) - but this does not mean it is equally difficult. I guess if Erlang is 10 to 100 times better than language X for a particular application then it has some chance of succeeding in that particular niche. So to succeed 1) and 2) have to satisfied << note I haven't mentioned deep guards :-) or parameterised modules >> Simplicity (though I love it) is not on my list - whatever else Java/C++/Perl have it's certainly not simplicity ... Cobra and the XML morass are certainly not simple ... and programming things like the windows API are so complicated that entire tool-making industries have emerged to try and hide bits of the complexity. Entire armies of consultant *love* complexity - Complexity = Job opportunities Back to the argument. IMNSHO Erlang is good at concurrency. It should be is was DESIGNED TO BE GOOD AT CONCURRENCY (The guy four doors down the corridor wonders why I am pounding the keyboard so hard :-) I think (I KNOW) that language changes that are aimed at improving the concurrency are essential. The world will not stand still - what we have done with processes in Erlang will one day be done in Java/C# (whatever). So what should we do? I have said this before: - Improve the *isolation* between processes This I consider the single most important change to the language. I consider ISOLATION (you're banging the keyboard again) to be the single most important property that a language has. What is ISOLATION? Two processes are isolated if one process cannot bugger up another process. This is "pretty easy to achieve" on different machines. Suppose I run one process in Sweden and the second process runs on Richard O'Keefe's machine in new Zealand - suppose I write in Erlang and he writes in smalltalk - then I hope errors in my program would not crash his program. The *difficult* bit is doing it on the same machine in the same language. What is it that buggers up software projects - bugs in one program propagate to other programs. -- Yikes Gadzookes bother and blast - my incomparably beautiful fault-free well tested program crashed because I linked it together with a program that contained an error. The only way that I know of to stop errors propagating is to use processes (ie virtual machines) - PROCESSES ARE USED TO STOP THE PROPAGATION OF ERRORS. Erlang was designed for large software projects. The principle reason why large software projects fail is because the software never works. The main reason why software doesn't work is that errors propagate between modules - bad code buggers up good code. Unless you can stop the propagation of errors you will never be able to write any decent software. For this reason I do not care about syntactic sugar. Where should we be going? ========================= * improve concurrency I'd like to see more processes with better isolation - * GC of everything atom tables, code * First Order Code First order code with GC would be *wonderful* - even better than structs (which is just sugar) * Agent extensions SECURITY (sorry I'm shouting again) * Interoperability This is the "wrapper" stuff I keep yacking on about - integration of UBF contracts with the language. We should not add things which makes programming a little bit more convenient (which is after all what a lot of the language changes do) - we should add thing so we can easily write applications that nobody else can write. Erlang is good at one thing - making large reliable systems. That is what it was designed to do - so YES to all changes aimed at making it easier to build reliable system software - NO to everything else. /Joe PS - any pleeeeese add the version number of the language to files. -module(foo). -version(5.0). <--------------- the language version Then If we do change the language the compiler can figure out what went wrong!!!!! From Bengt.Kleberg@REDACTED Tue Oct 14 10:07:19 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Tue, 14 Oct 2003 10:07:19 +0200 Subject: Erlang is getting too big In-Reply-To: <20031014064743.90773.qmail@web41901.mail.yahoo.com> References: <20031014064743.90773.qmail@web41901.mail.yahoo.com> Message-ID: <3F8BAEB7.50405@ericsson.com> Thomas Lindgren wrote: ...deleted > Here's another part that could stand cleaning up: > > - guard syntax 1: "," and ";" > - guard syntax 2: "and", "or" > (are they there anymore?) > - expression syntax 1: "and", "or" > - expression syntax 2: "andalso", "orelse" > > All of them working somewhat differently. > oops. what is the difference between ',' and 'and'? and ';' and 'or'? i have been using them to mean the same thing. eiffel has 'andalso' and 'orelse'. the only :-) people that finds 'and' and 'or' strange are the ones that has a c background. > My modest proposal: > > - drop is_* guards (unless there is a pressing reason > to keep them?) > there is no static typing. therefore it helps (me) to be able to recognise the return value of a function from its name. one way of doing this is to teach users (by using the concept in guards) to call functions that return booleans is_*. moreover, there is a guard float() and a bif float(). the bif returns a float, not a boolean. this (imho) is confusing bengt. From DANIESC.SCHUTTE@REDACTED Tue Oct 14 10:09:42 2003 From: DANIESC.SCHUTTE@REDACTED (DANIESC SCHUTTE) Date: Tue, 14 Oct 2003 10:09:42 +0200 Subject: Erlang is getting too big Message-ID: >>> "Vlad Dumitrescu" 10/14/03 09:24AM >>> *** Is there a way to keep the balance, so that everybody is happy? I think Joe's (et al.) proposal of more clearly separating kernel Erlang from OTP would be one good way to go in that direction. Not only at the code level, but also above that. Unless of course, Erlang is seen as a necessary evil that is used to distribute OTP ;-) I'm babbling a little, but hopefully it's making some sense. * Keep Erlang easy to learn for total beginners? Yes, but then dumping the whole OTP on them at once might be a contradiction in terms. * Take away the "telecom" mark from Erlang and step into other areas? Yes, and again having to handle the whole OTP is somewhat working against that. * Leave open the chance to improve Erlang? Yes, the new stuff might be provided as a library, not as kernel language. ?- Just my 2 cents The biggest problem that I found with "beginner Erlang" programmers was the fact that this is a "functional" language rather than an OO language - and the paradigm shift from other mainstream languages (Pascal / C / C++ / VB :) ) are the stumbling blocks - but once made - it works. My personal suggestion and something I would personally like to contribute towards, is possibly even more tutorials or "how to's" on the OTP stuff - this would solve a lot of the unknows for some programmers. The Telecom mark has never actually bothered us :) erlang is a tool - and utilizing it in other sectors is part of the "creativity" and "lateral thinking ability" of developers and software engineers - why ignore where it origionated. Personally - we use only the "applications" that we need - and as we grow - we find the additional applications provide us with more and more functionality. The fact that Erlang is growing shows me one thing - IT'S ALIVE AND KICKING. Systems that are used evolve and improve. The maintenance might be difficult but I think that the Erlang development team has shown great competency in that respect. It might just be a perceptiob problem. As long as the system is maintainable - I don't see a problem with additional applications / add-ons. The biggest problem might be users saying "so much to learn so little time" - to them I advise - take it an application at a time. Regards Daniel ##################################################################################### The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy all copies. ##################################################################################### From Bengt.Kleberg@REDACTED Tue Oct 14 10:42:07 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Tue, 14 Oct 2003 10:42:07 +0200 Subject: Silly Qn': Process exits at spawn In-Reply-To: <3F8AFE72.4020801@ntlworld.com> References: <3F8AD352.7050409@ntlworld.com> <3F8AFE72.4020801@ntlworld.com> Message-ID: <3F8BB6DF.2050100@ericsson.com> chris.danx wrote: > Thanks folks, it runs now! > > Can anyone help with another problem? I've probably done something > stupid again. The following code is supposed to query the server if a > neuron with the given name exists and if it does, return false. If the > neuron doesn't exist, it creates a new neuron one (a process) and > returns. The problem I'm having is finding where abouts the hang > occurs. Does anyone have any tips for debugging Erlang? see the manual page for module ''dbg''. > I think it fails to receive the {Reg, Exists} message in create neuron, > but I could be wrong. > > > %% create a neuron > % > create_neuron (Name, State, OutputFunc) -> > neural_registry ! {self(), exists, Name}, > receive > {Reg, Exists} -> if Exists == true -> > false; > true -> > {X, Pid} = neurons:create_neuron(Name, State, OutputFunc), > add_neuron_to_reg ({X, Pid}) > end > end. for the sake of simplicity i think you could re-write this as: create_neuron(Name, State, Output) -> neural_registry ! {self(), exists, Name}, receive {_From, true} -> false; {_From, false} -> {X, Pid} = neurons:create_neuron(Name, State, Output), add_neuron_to_reg({X, Pid}) end end. bengt From raimo@REDACTED Tue Oct 14 11:17:28 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Tue, 14 Oct 2003 11:17:28 +0200 Subject: BUG: in io:fread/3: doesn't return eof References: , <7150A476-FD76-11D7-891E-000393536F4E@ul.ie> Message-ID: I do not doubt that you have discovered that the behaviour has changed between R9B-1 and R9C-0, I just wanted your help to pinpoint the bug. Something like: ------------------- This shows the bug: Erlang (BEAM) emulator version 5.3 [hipe] [threads:0] Eshell V5.3 (abort with ^G) 1> file:write_file("kasta.txt","1 2.0 3.0 4 5.0\n"). ok 2> {ok,Io} = file:open("kasta.txt", [read]). {ok,<0.32.0>} 3> io:fread(Io, 'adhoc> ', "~d~f~f~d~f"). {ok,[1,2.00000,3.00000,4,5.00000]} 4> io:fread(Io, 'adhoc> ', "~d~f~f~d~f"). {error,{fread,format}} compared to R9B-1 that returns 'eof' from command 4> ------------------- I cracked it anyway, but if I had a small example like above I might have cracked it yesterday. Here is a "diff -c" that fixes the bug: *** lib/stdlib/src/io_lib_fread.erl@@/OTP_R9C Mon Jul 7 13:59:36 2003 --- lib/stdlib/src/io_lib_fread.erl Tue Oct 14 08:45:12 2003 *************** *** 53,59 **** {more,RestFormat,N,Inputs} -> case More of eof -> ! {done,fread_error(format),eof}; _ -> %% Don't forget to count the newline. {more,{More,RestFormat,N+1,Inputs}} --- 53,59 ---- {more,RestFormat,N,Inputs} -> case More of eof -> ! {done,eof,eof}; _ -> %% Don't forget to count the newline. {more,{More,RestFormat,N+1,Inputs}} It will be fixed in R9C-1. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB david wallin wrote: > > On Monday, October 13, 2003, at 08:23 AM, Raimo Niskanen wrote: > >> Erlang (BEAM) emulator version 5.3 [hipe] [threads:0] >> >> Eshell V5.3 (abort with ^G) >> 1> io:fread('adhoc> ', "~d~f~f~d~f"). >> adhoc> 1 2.0 3.0 4 5.0 >> {ok,[1,2.00000,3.00000,4,5.00000]} >> 2> >> > > I have a file with alot of entries like that, and the function below is > supposed to be called until all of them are read, i.e, it should return > the eof from io:fread/3. The behaviour of 'io:fread/3' has clearly > changed between R9B-1 and R9C-0. > > --david. > > >> Works fine. Please give more info about from where you read input and >> how you expect the end of file in the input to appear. >> >> -- >> / Raimo Niskanen, Erlang/OTP, Ericsson AB >> >> >> david wallin wrote: >> >>> Subject says it all really. With release R9C-0 io:fread/3 doesn't >>> return 'eof' but an error. >>> The following function worked fine with R9B-1 but now I get an >>> '{error, Error}' instead of 'eof'. >>> get_best_fitness(Io) -> >>> case io:fread(Io, 'adhoc> ', "~d~f~f~d~f") of >>> {ok, [Generation, BestFitness, AvgFitness, ValidSol, Entropy]} -> >>> {Generation, BestFitness} ; >>> {error, Error} -> >>> io:format("~p.get_best_fitness: unexpected format '~p'\n", >>> [?MODULE, Error]), >>> error ; >>> eof -> eof >>> end. >>> cheers, >>> --david. > > From mike@REDACTED Tue Oct 14 11:25:18 2003 From: mike@REDACTED (Mike Williams) Date: 14 Oct 2003 09:25:18 GMT Subject: Erlang is getting too big (Joe over-simplifies things) References: <20031014064743.90773.qmail@web41901.mail.yahoo.com>, Message-ID: In article , joe@REDACTED (Joe Armstrong) writes: |> |> The principle reason why large software projects fail is because the |> software never works. |> |> The main reason why software doesn't work is that errors propagate between |> modules - bad code buggers up good code. Vast over simplification! There are many reasons why SW projects fail. Perhaps the most common one is that the project solves the wrong problem (i.e. the spec was wrong). Another reason is that the SW is never "designed", it just "happens" resulting in a system with no well though out modularisation, no policies for error recovery, no thought behind concurrency etc etc. I've seen them all (and so have you Joe :-). What I think you mean, Joe, is: The main reason why software systems are unstable (crash often) is that errors propagate between modules. The main cause is languages with unsafe pointers (C, C++) and explict memory allocation / de-allocation. There are two ways to solve this. 1) Don't use languages with unsafe pointers 2) Use an OS with sufficienty fine MMU protection that a pointer error in one thread can't clobber another thread. Erlang is approach #1. What Erlang does not solve (and, for obvious reasons no other language does either) is the propagation of errors between parts of the system by sending erroneous data in messages or function calls. What Erlang helps with is the "let it crash and some other process clean up the mess" philosophy of error handling encapsulated in Erlang and OTP. /mike From anders.fluur@REDACTED Tue Oct 14 10:43:30 2003 From: anders.fluur@REDACTED (Anders Fluur (LN/EAB)) Date: Tue, 14 Oct 2003 10:43:30 +0200 Subject: =?iso-8859-1?Q?Varf=F6r_kan_jag_inte_inte_anropa_A_--_B_--_C_=3F?= Message-ID: <9505F6390AA7D311A2D500508B951BEF12136F2C@esealnt427> Hej, Varf?r kan jag inte inte anropa A -- B -- C, n?r A ++ B ++ C fungerar? ( erlang)82> A = [1,2]. [1,2] ( erlang)83> B=[3,4]. [3,4] ( erlang)84> C=[5,6]. [5,6] ( erlang)85> [1,2,3,4,5,6]--A--B--C. [3,4,5,6] ( erlang)86> A++B++C. [1,2,3,4,5,6] Mvh Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.wallin@REDACTED Tue Oct 14 12:12:12 2003 From: david.wallin@REDACTED (david wallin) Date: Tue, 14 Oct 2003 11:12:12 +0100 Subject: BUG: in io:fread/3: doesn't return eof In-Reply-To: Message-ID: Raimo, Thanks. I'll try to be more helpful in the future. cheers, --david. On Tuesday, October 14, 2003, at 10:17 AM, Raimo Niskanen wrote: > I do not doubt that you have discovered that the behaviour has changed > between R9B-1 and R9C-0, I just wanted your help to pinpoint the bug. > Something like: > > ------------------- > This shows the bug: > Erlang (BEAM) emulator version 5.3 [hipe] [threads:0] > > Eshell V5.3 (abort with ^G) > 1> file:write_file("kasta.txt","1 2.0 3.0 4 5.0\n"). > ok > 2> {ok,Io} = file:open("kasta.txt", [read]). > {ok,<0.32.0>} > 3> io:fread(Io, 'adhoc> ', "~d~f~f~d~f"). > {ok,[1,2.00000,3.00000,4,5.00000]} > 4> io:fread(Io, 'adhoc> ', "~d~f~f~d~f"). > {error,{fread,format}} > > compared to R9B-1 that returns 'eof' from command 4> > ------------------- > > > > I cracked it anyway, but if I had a small example like above I might > have cracked it yesterday. > > Here is a "diff -c" that fixes the bug: > > *** lib/stdlib/src/io_lib_fread.erl@@/OTP_R9C Mon Jul 7 13:59:36 > 2003 > --- lib/stdlib/src/io_lib_fread.erl Tue Oct 14 08:45:12 2003 > *************** > *** 53,59 **** > {more,RestFormat,N,Inputs} -> > case More of > eof -> > ! {done,fread_error(format),eof}; > _ -> > %% Don't forget to count the newline. > {more,{More,RestFormat,N+1,Inputs}} > --- 53,59 ---- > {more,RestFormat,N,Inputs} -> > case More of > eof -> > ! {done,eof,eof}; > _ -> > %% Don't forget to count the newline. > {more,{More,RestFormat,N+1,Inputs}} > > It will be fixed in R9C-1. > > -- > / Raimo Niskanen, Erlang/OTP, Ericsson AB > > From lennart.ohman@REDACTED Tue Oct 14 12:21:07 2003 From: lennart.ohman@REDACTED (=?ISO-8859-1?Q?Lennart_=D6hman?=) Date: Tue, 14 Oct 2003 12:21:07 +0200 Subject: =?ISO-8859-1?Q?Varf=F6r_kan_jag_inte_inte_anropa_?= =?ISO-8859-1?Q?A_--_B_--_C_=3F?= In-Reply-To: <9505F6390AA7D311A2D500508B951BEF12136F2C@esealnt427> References: <9505F6390AA7D311A2D500508B951BEF12136F2C@esealnt427> Message-ID: <3F8BCE13.90902@st.se> Hi, the -- operator works with two arguments. I think you shall concider what you did as: [1,2,3,4,5,6] -- (A -- (B -- C)). If you try ((([1,2,3,4,5,6] -- A) -- B) -- C). I beleive you will accomplish what you intended. Best Regards, Lennart Anders Fluur (LN/EAB) wrote: > Hej, > Varf?r kan jag inte inte anropa A -- B -- C, n?r A ++ B ++ C fungerar? > > (erlang)82 > A = [1,2]. > [1,2] > (erlang)83 > B=[3,4]. > [3,4] > (erlang)84 > C=[5,6]. > [5,6] > (erlang)85 > [1,2,3,4,5,6]--A--B--C. > [3,4,5,6] > (erlang)86 > A++B++C. > [1,2,3,4,5,6] > > Mvh > Anders > ------------------------------------------------------------- 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 raimo@REDACTED Tue Oct 14 12:26:20 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Tue, 14 Oct 2003 12:26:20 +0200 Subject: problem with gethostbyname/1 References: , , <3F8BA496.3010300@bluetail.com> Message-ID: The fix looks fine, we will include it in R9C-1. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB Magnus Fr?berg wrote: > Raimo Niskanen wrote: > >> >> I have never come across a Gentoo Linux box before. Could you dump the >> following files as well as the output from os:type() and send to me? > > > Hi > > we have done a fix to inet_config.erl for our Gentoo users. > It seems like Gentoo does not have the /etc/host.conf file so > we added usage of /etc/nsswitch.conf as well for 'linux' while > configuring the inet_db. > > The diff below is against the R9C-0 version of inet_config.erl: > > Index: lib/kernel/src/inet_config.erl > =================================================================== > RCS file: /home/share/erlang/cvsroot/otp/lib/kernel/src/inet_config.erl,v > retrieving revision 1.1.1.5 > retrieving revision 1.7 > diff -u -r1.1.1.5 -r1.7 > --- lib/kernel/src/inet_config.erl 2 Sep 2003 13:34:18 -0000 > 1.1.1.5 > +++ lib/kernel/src/inet_config.erl 3 Sep 2003 13:53:57 -0000 1.7 > @@ -82,8 +82,13 @@ > 'bsd/os' -> > load_resolv(filename:join(Etc,"irs.conf"), > host_conf_bsdos); > linux -> > - > load_resolv(filename:join(Etc,"host.conf"),host_conf_linux), > - > + case > load_resolv(filename:join(Etc,"host.conf"),host_conf_li > nux) of > + ok -> > + ok; > + _Other -> > + > load_resolv(filename:join(Etc,"nsswitch.conf"), nssw > itch_conf) > + end, > + > % It may be the case that the domain name was not set > % because the hostname was short. But we can now > look it > % up and get the long name and the domain name from it. > > > /Magnus > From raimo@REDACTED Tue Oct 14 12:29:24 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Tue, 14 Oct 2003 12:29:24 +0200 Subject: BUG: in io:fread/3: doesn't return eof References: , Message-ID: Ok, sorry if I sounded a bit sore. WARNING! I just tried to fread a file that did not contain a full set of fields on the last line, and my patch caused this error behaviour to change. I will be back with a better patch! -- / Raimo Niskanen, Erlang/OTP, Ericsson AB david wallin wrote: > > Raimo, > > Thanks. I'll try to be more helpful in the future. > > > cheers, > > --david. > > On Tuesday, October 14, 2003, at 10:17 AM, Raimo Niskanen wrote: > >> I do not doubt that you have discovered that the behaviour has changed >> between R9B-1 and R9C-0, I just wanted your help to pinpoint the bug. >> Something like: >> >> ------------------- >> This shows the bug: >> Erlang (BEAM) emulator version 5.3 [hipe] [threads:0] >> >> Eshell V5.3 (abort with ^G) >> 1> file:write_file("kasta.txt","1 2.0 3.0 4 5.0\n"). >> ok >> 2> {ok,Io} = file:open("kasta.txt", [read]). >> {ok,<0.32.0>} >> 3> io:fread(Io, 'adhoc> ', "~d~f~f~d~f"). >> {ok,[1,2.00000,3.00000,4,5.00000]} >> 4> io:fread(Io, 'adhoc> ', "~d~f~f~d~f"). >> {error,{fread,format}} >> >> compared to R9B-1 that returns 'eof' from command 4> >> ------------------- >> >> >> >> I cracked it anyway, but if I had a small example like above I might >> have cracked it yesterday. >> >> Here is a "diff -c" that fixes the bug: >> >> *** lib/stdlib/src/io_lib_fread.erl@@/OTP_R9C Mon Jul 7 13:59:36 2003 >> --- lib/stdlib/src/io_lib_fread.erl Tue Oct 14 08:45:12 2003 >> *************** >> *** 53,59 **** >> {more,RestFormat,N,Inputs} -> >> case More of >> eof -> >> ! {done,fread_error(format),eof}; >> _ -> >> %% Don't forget to count the newline. >> {more,{More,RestFormat,N+1,Inputs}} >> --- 53,59 ---- >> {more,RestFormat,N,Inputs} -> >> case More of >> eof -> >> ! {done,eof,eof}; >> _ -> >> %% Don't forget to count the newline. >> {more,{More,RestFormat,N+1,Inputs}} >> >> It will be fixed in R9C-1. >> >> -- >> / Raimo Niskanen, Erlang/OTP, Ericsson AB >> >> > From richardc@REDACTED Tue Oct 14 12:31:30 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 14 Oct 2003 12:31:30 +0200 (MET DST) Subject: Erlang is getting too big In-Reply-To: <3F8BAEB7.50405@ericsson.com> References: <20031014064743.90773.qmail@web41901.mail.yahoo.com> <3F8BAEB7.50405@ericsson.com> Message-ID: On Tue, 14 Oct 2003, Bengt Kleberg wrote: > Thomas Lindgren wrote: > ...deleted > > Here's another part that could stand cleaning up: > > > > - guard syntax 1: "," and ";" > > - guard syntax 2: "and", "or" > > (are they there anymore?) > > - expression syntax 1: "and", "or" > > - expression syntax 2: "andalso", "orelse" > > > > All of them working somewhat differently. > > oops. what is the difference between ',' and 'and'? and ';' and 'or'? i > have been using them to mean the same thing. > > eiffel has 'andalso' and 'orelse'. the only :-) people that finds 'and' > and 'or' strange are the ones that has a c background. Perhaps the most complicated part of the Erlang language are the clause guards. They are a mess, although we've tried to clear up a few things. 1. Guards are comma-separated sequences (conjunctions) of "tests", i.e., the commas mean logical "and". (So far so good.) 2. Later, it was added that you could have alternative lists of tests, if you separated them with semicolon as in "t01, t02, t03; t11, t12, t13; t21, t22, t23 ->" (a disjunction of conjunctions.) So, the semicolons mean logical "or" in this context. (This addition was probably one of the less motivated ones. I've never used it myself.) 3. A "test" is either a comparison "X == Y", "X > Y" etc, or a call to a built-in test function like "integer(X)" or "float(Y)". (I.e., it is not just any boolean expression.) 4. Guard tests have a separate name space! "integer(X)" above is not defined outside guards, so you can't write: Bool = (f(X) and integer(Y)) in normal Erlang code - unless you define "integer/1" yourself. (But you can't override the tests used in guards.) The test "float(X)" overrides the built-in typecast function of the same name. You _can_ write the following: Bool = (f(X) and float(Y)) but you might be surprised when "float(Y)" does not return a boolean. 5 The subexpressions of guard tests are "guard expressions", which are a limited subset of normal expressions. Basically: variables, constants, operators and calls to a subset of the "automatically recognized" BIFs are allowed, but nothing else. 6. Guard tests are implicitly "wrapped in a catch", so that if a subexpression crashes (the tests themselves can't crash), they quietly evaluate to "true" instead. (Thankfully, the number of programmers crazy enough to actually make use of this "feature" is very small. I have not seen it used in OTP and I would like to have it removed from the language.) 7. The boolean operators "and" and "or" (and "not" and "xor") have been in Erlang quite a while, but were defined to be strict, i.e., always evaluate both arguments. Furthermore, they could originally not be used anywhere in a guard(!). 8. When "and" and "or" were eventually allowed in guards, they actually got the same semantics (within guards) as "," and ";" respectively, since guards cannot have side effects (and thus it does not matter if you use strict evaluation or not, space/time aside). But there is no point in using and/or instead of comma and semicolon unless you like longer lines. Stick to the normal separators. It's just in subexpressions that you might use and/or/not/xor once in a blue moon. 9. 'andalso' and 'orelse' (the non-strict versions of 'and' and 'or' can be useful for avoiding deep nesting of case switches`, and can make the code much more concise. For example: case f(X) of true -> true; false -> case g(X) of false -> case h(X) of true -> true; fasle -> false end; true -> false end end is equivalent to f(X) orelse (not g(X) andalso h(X)) Now, how long did it take for you to verify that the first version really implements the second one? What happens if you misspell 'true' or 'false' somewhere? (Personally, I'd have preferred 'and' and 'or' to be defined as non-strict to begin with.) And now, for 10,000 dollars*: What does the following do, if X is a floating-point number? if float(X), (float(X) == true) -> true; true -> false end What we've tried to do in the last years is to make the differences between normal expressions and guards smaller. It's not easy, as I hope you can see from the above. It was in order to clear up the confusion with the guard test namespace that we added the "is_..." versions of the type tests. These have the same definition everywhere, and you can even call "erlang:is_integer(X)" if you need to. I think they are a good thing. It is much easier to say to a beginner "Oh, 'integer(X)' is old-style - avoid that and use 'is_integer(X)' instead." instead of trying to explain why he can't write 'integer(X)' in other places than guard tests. A new book would certainly be in order, if anyone could find a publisher. /Richard * Altairian dollars. Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From Erik.Stenman@REDACTED Tue Oct 14 12:38:48 2003 From: Erik.Stenman@REDACTED (Erik Stenman) Date: Tue, 14 Oct 2003 12:38:48 +0200 Subject: =?iso-8859-1?Q?RE:_Varf=F6r_kan_jag_inte_inte_anropa_A_--_B_--_C_=3F?= In-Reply-To: <3F8BCE13.90902@st.se> Message-ID: <009001c3923f$59b07f80$2d9ab280@lamppc36> Interesting '--' is apparently evaluated right to left: 1> [1,2,3,4,5,6]--[1,2,3,4]--[4]. [4,5,6] Using parentheses gives you the expected result: 12> (([1,2,3,4,5,6]--[1,2])--[3,4])--[5,6]. [] But the "spec" says: Operators with the same priority are evaluated left to right. See: http://www.erlang.org/doc/r9c/doc/reference_manual/part_frame.html 6.23 Operator Precedence Operator precedence in falling priority: : # Unary + - bnot not / * div rem band and + - bor bxor bsl bsr or xor ++ -- == /= =< < >= > =:= =/= andalso orelse = ! catch When evaluating an expression, the operator with the highest priority is evaluated first. Operators with the same priority are evaluated left to right. Example: 6 + 5 * 4 - 3 / 2 evaluates to 6 + 20 - 1.5 evaluates to 26 - 1.5 evaluates to 24.5 Looking at erl_parse.yrl one can see that list_op ('--' and '++') are right associated. So either the documentation or the implementation is wrong. Changing line 105 from: expr_300 -> expr_400 list_op expr_300 : mkop('$1', '$2', '$3'). expr_300 -> expr_400 : '$1'. to: expr_300 -> expr_300 list_op expr_400 : mkop('$1', '$2', '$3'). expr_300 -> expr_400 : '$1'. Will give you a left associated parser: Eshell V5.3 (abort with ^G) 1> [1,2,3,4,5,6]--[1,2]--[3,4]--[5,6]. [] /Erik > Lennart ?hman wrote > > Hi, the -- operator works with two arguments. I think you > shall concider what you did as: > > [1,2,3,4,5,6] -- (A -- (B -- C)). > > If you try > > ((([1,2,3,4,5,6] -- A) -- B) -- C). > > I beleive you will accomplish what you intended. > > Best Regards, > Lennart > > > Anders Fluur (LN/EAB) wrote: > > Hej, > > Varf?r kan jag inte inte anropa A -- B -- C, n?r A ++ B ++ > C fungerar? > > > > (erlang)82 > A = [1,2]. [1,2] > > (erlang)83 > B=[3,4]. > > [3,4] > > (erlang)84 > C=[5,6]. > > [5,6] > > (erlang)85 > > [1,2,3,4,5,6]--A--B--C. > > [3,4,5,6] > > (erlang)86 > A++B++C. > > [1,2,3,4,5,6] > > > > Mvh > > Anders > > > > > ------------------------------------------------------------- > 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 thomasl_erlang@REDACTED Tue Oct 14 13:13:55 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 14 Oct 2003 04:13:55 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: <3F8BAEB7.50405@ericsson.com> Message-ID: <20031014111355.75296.qmail@web41904.mail.yahoo.com> --- Bengt Kleberg wrote: > Thomas Lindgren wrote: > ...deleted > > Here's another part that could stand cleaning up: > > > > - guard syntax 1: "," and ";" > > - guard syntax 2: "and", "or" > > (are they there anymore?) > > - expression syntax 1: "and", "or" > > - expression syntax 2: "andalso", "orelse" > > > > All of them working somewhat differently. > > oops. what is the difference between ',' and 'and'? > and ';' and 'or'? i > have been using them to mean the same thing. As I recall, ";" can't be nested inside a guard, while 'or' can. ";" appeared before guard expressions were generalized, and the implementation at the time seemed to require this restriction ... but once generalized guards were worked out, it puzzles me why a new set of operators was introduced rather than generalizing the old ones. > eiffel has 'andalso' and 'orelse'. the only :-) > people that finds 'and' > and 'or' strange are the ones that has a c > background. My main objections are the added noise from long names, the limited usefulness of strict and/or, and the fact that the obvious names are used for the unobvious version. And in C you use && anyway :-) (The &-operator corresponds to 'band' not horrid 'and'.) > > My modest proposal: > > > > - drop is_* guards (unless there is a pressing > reason > > to keep them?) > > there is no static typing. therefore it helps (me) > to be able to > recognise the return value of a function from its > name. one way of doing > this is to teach users (by using the concept in > guards) to call > functions that return booleans is_*. > > moreover, there is a guard float() and a bif > float(). the bif returns a > float, not a boolean. > this (imho) is confusing If that is a big problem, why not introduce a new float-making function, rather than a collection of extra type tests? Seems simpler all-around. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From raimo@REDACTED Tue Oct 14 13:22:19 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Tue, 14 Oct 2003 13:22:19 +0200 Subject: BUG: in io:fread/3: doesn't return eof References: , <7150A476-FD76-11D7-891E-000393536F4E@ul.ie>, Message-ID: WARNING! The previous patch was incorrect. When the last line of the data file did not contain a complete set of fields, it misbehaved. This is a better patch (diff -c): *** lib/stdlib/src/io_lib_fread.erl@@/OTP_R9C Mon Jul 7 13:59:36 2003 --- lib/stdlib/src/io_lib_fread.erl Tue Oct 14 12:50:41 2003 *************** *** 53,59 **** {more,RestFormat,N,Inputs} -> case More of eof -> ! {done,fread_error(format),eof}; _ -> %% Don't forget to count the newline. {more,{More,RestFormat,N+1,Inputs}} --- 53,59 ---- {more,RestFormat,N,Inputs} -> case More of eof -> ! fread(RestFormat,eof,N,Inputs,eof); _ -> %% Don't forget to count the newline. {more,{More,RestFormat,N+1,Inputs}} -- / Raimo Niskanen, Erlang/OTP, Ericsson AB Raimo Niskanen wrote: > I do not doubt that you have discovered that the behaviour has changed > between R9B-1 and R9C-0, I just wanted your help to pinpoint the bug. > Something like: > > ------------------- > This shows the bug: > Erlang (BEAM) emulator version 5.3 [hipe] [threads:0] > > Eshell V5.3 (abort with ^G) > 1> file:write_file("kasta.txt","1 2.0 3.0 4 5.0\n"). > ok > 2> {ok,Io} = file:open("kasta.txt", [read]). > {ok,<0.32.0>} > 3> io:fread(Io, 'adhoc> ', "~d~f~f~d~f"). > {ok,[1,2.00000,3.00000,4,5.00000]} > 4> io:fread(Io, 'adhoc> ', "~d~f~f~d~f"). > {error,{fread,format}} > > compared to R9B-1 that returns 'eof' from command 4> > ------------------- > > > > I cracked it anyway, but if I had a small example like above I might > have cracked it yesterday. > > Here is a "diff -c" that fixes the bug: > > *** lib/stdlib/src/io_lib_fread.erl@@/OTP_R9C Mon Jul 7 13:59:36 2003 > --- lib/stdlib/src/io_lib_fread.erl Tue Oct 14 08:45:12 2003 > *************** > *** 53,59 **** > {more,RestFormat,N,Inputs} -> > case More of > eof -> > ! {done,fread_error(format),eof}; > _ -> > %% Don't forget to count the newline. > {more,{More,RestFormat,N+1,Inputs}} > --- 53,59 ---- > {more,RestFormat,N,Inputs} -> > case More of > eof -> > ! {done,eof,eof}; > _ -> > %% Don't forget to count the newline. > {more,{More,RestFormat,N+1,Inputs}} > > It will be fixed in R9C-1. > From thomasl_erlang@REDACTED Tue Oct 14 13:42:38 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 14 Oct 2003 04:42:38 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: Message-ID: <20031014114238.48475.qmail@web41902.mail.yahoo.com> A question on #6 below: shouldn't it be that the guard _fails_ if a subexpression crashes? Anyway, a couple of short comments: 1. Do we WANT to unify guards and expressions? Personally, I think it might be good, but not if the solution is messier than what it replaces. It's not a "must have" for me. 2. Assuming that we do: Another approach to unifying guards with expressions would be to introduce the appropriate type tests as BIFs. Apart from float/1, this seems straightforward? For float/1 used in expressions, change the BIF to a type test and write a lint-like program to detect (and maybe rewrite) all occurrences in existing source code. (The linker could also direct calls to float/1 in "old BEAM code" to the float-making BIF, and calls in "new code" to the float-testing BIF.) That way, it seems to me we would avoid having an extra set of tests identical in all but name. Well, unless I've overlooked something crucial. (Please don't say 'backwards compatibility' :-) Best, Thomas --- Richard Carlsson wrote: > > On Tue, 14 Oct 2003, Bengt Kleberg wrote: > > > Thomas Lindgren wrote: > > ...deleted > > > Here's another part that could stand cleaning > up: > > > > > > - guard syntax 1: "," and ";" > > > - guard syntax 2: "and", "or" > > > (are they there anymore?) > > > - expression syntax 1: "and", "or" > > > - expression syntax 2: "andalso", "orelse" > > > > > > All of them working somewhat differently. > > > > oops. what is the difference between ',' and > 'and'? and ';' and 'or'? i > > have been using them to mean the same thing. > > > > eiffel has 'andalso' and 'orelse'. the only :-) > people that finds 'and' > > and 'or' strange are the ones that has a c > background. > > Perhaps the most complicated part of the Erlang > language are the clause > guards. They are a mess, although we've tried to > clear up a few things. > > 1. Guards are comma-separated sequences > (conjunctions) of "tests", > i.e., the commas mean logical "and". (So far so > good.) > > 2. Later, it was added that you could have > alternative lists > of tests, if you separated them with > semicolon as in > "t01, t02, t03; t11, t12, t13; t21, t22, t23 > ->" > (a disjunction of conjunctions.) So, the > semicolons mean > logical "or" in this context. (This addition was > probably > one of the less motivated ones. I've never used > it myself.) > > 3. A "test" is either a comparison "X == Y", "X > > Y" etc, or > a call to a built-in test function like > "integer(X)" or > "float(Y)". (I.e., it is not just any boolean > expression.) > > 4. Guard tests have a separate name space! > "integer(X)" above > is not defined outside guards, so you can't > write: > > Bool = (f(X) and integer(Y)) > > in normal Erlang code - unless you define > "integer/1" > yourself. (But you can't override the tests used > in guards.) > The test "float(X)" overrides the built-in > typecast function > of the same name. You _can_ write the following: > > Bool = (f(X) and float(Y)) > > but you might be surprised when "float(Y)" does > not return a > boolean. > > 5 The subexpressions of guard tests are "guard > expressions", > which are a limited subset of normal > expressions. Basically: > variables, constants, operators and calls to a > subset of the > "automatically recognized" BIFs are allowed, but > nothing else. > > 6. Guard tests are implicitly "wrapped in a catch", > so that if > a subexpression crashes (the tests themselves > can't crash), > they quietly evaluate to "true" instead. > (Thankfully, the > number of programmers crazy enough to actually > make use of > this "feature" is very small. I have not seen it > used in OTP > and I would like to have it removed from the > language.) > > 7. The boolean operators "and" and "or" (and "not" > and "xor") > have been in Erlang quite a while, but were > defined to be > strict, i.e., always evaluate both arguments. > Furthermore, > they could originally not be used anywhere in a > guard(!). > > 8. When "and" and "or" were eventually allowed in > guards, they > actually got the same semantics (within guards) > as "," and > ";" respectively, since guards cannot > have side effects > (and thus it does not matter if you use strict > evaluation or > not, space/time aside). But there is no point in > using and/or > instead of comma and semicolon unless you like > longer lines. > Stick to the normal separators. It's just in > subexpressions > that you might use and/or/not/xor once in a blue > moon. > > 9. 'andalso' and 'orelse' (the non-strict versions > of 'and' and > 'or' can be useful for avoiding deep nesting of > case > switches`, and can make the code much more > concise. For > example: > > case f(X) of > true -> true; > false -> > case g(X) of > false -> > case h(X) of > true -> true; > fasle -> false > end; > true -> false > end > end > > is equivalent to > > f(X) orelse (not g(X) andalso h(X)) > > Now, how long did it take for you to verify that > the > first version really implements the second one? > What > happens if you misspell 'true' or 'false' > somewhere? > (Personally, I'd have preferred 'and' and 'or' > to be > defined as non-strict to begin with.) > > And now, for 10,000 dollars*: > > What does the following do, if X is a > floating-point number? > > if float(X), (float(X) == true) -> true; > true -> false > end > > What we've tried to do in the last years is to make > the differences > between normal expressions and guards smaller. It's > not easy, as I hope > you can see from the above. It was in order to clear > up the confusion > with the guard test namespace that we added the > "is_..." versions of the > type tests. These have the same definition > everywhere, and you can even > call "erlang:is_integer(X)" if you need to. I think > they are a good > thing. It is much easier to say to a beginner "Oh, > 'integer(X)' is > old-style - avoid that and use 'is_integer(X)' > instead." instead of > trying to explain why he can't write 'integer(X)' in > other places than > guard tests. > > A new book would certainly be in order, if anyone > could find a > publisher. > > /Richard > > > * Altairian dollars. > > > > Richard Carlsson (richardc@REDACTED) (This space > intentionally left blank.) > === message truncated === __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From Bengt.Kleberg@REDACTED Tue Oct 14 13:51:06 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Tue, 14 Oct 2003 13:51:06 +0200 Subject: Erlang is getting too big In-Reply-To: <20031014111355.75296.qmail@web41904.mail.yahoo.com> References: <20031014111355.75296.qmail@web41904.mail.yahoo.com> Message-ID: <3F8BE32A.3010500@ericsson.com> Thomas Lindgren wrote: > --- Bengt Kleberg wrote: > ...deleted >> >>oops. what is the difference between ',' and 'and'? >>and ';' and 'or'? i >>have been using them to mean the same thing. > > > As I recall, ";" can't be nested inside a guard, while > 'or' can. > thank you. ...deleted > > >>eiffel has 'andalso' and 'orelse'. the only :-) >>people that finds 'and' >>and 'or' strange are the ones that has a c >>background. > > > My main objections are the added noise from long > names, the limited usefulness of strict and/or, and > the fact that the obvious names are used for the > unobvious version. imho the only people that think it is ''unobvious'' that and/or evaluate all their ''arguments'' are the ones that has a c background. ...deleted >>>My modest proposal: >>> >>>- drop is_* guards (unless there is a pressing >> >>reason >> >>>to keep them?) >> >>there is no static typing. therefore it helps (me) >>to be able to >>recognise the return value of a function from its >>name. one way of doing >>this is to teach users (by using the concept in >>guards) to call >>functions that return booleans is_*. >> >>moreover, there is a guard float() and a bif >>float(). the bif returns a >>float, not a boolean. >>this (imho) is confusing > > > If that is a big problem, why not introduce a new > float-making function, rather than a collection of > extra type tests? Seems simpler all-around. i find it a good thing (tm) that boolean-return-value-functions are recognisable from their name. bengt From thomasl_erlang@REDACTED Tue Oct 14 13:56:38 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 14 Oct 2003 04:56:38 -0700 (PDT) Subject: Erlang is getting too big (Long and a lot of shouting :-) In-Reply-To: Message-ID: <20031014115638.32050.qmail@web41903.mail.yahoo.com> --- Joe Armstrong wrote: > Where should we be going? > ========================= > > * improve concurrency > > I'd like to see more processes with better > isolation - What is missing? > * GC of everything, atom tables, code An implementation thing, rather than a language thing, I'd say. But I agree. > * First Order Code > > First order code with GC would be *wonderful* - > even better than > structs (which is just sugar) It might be a good idea. Some way of slicing, dicing and gluing together modules with code change would make _my_ life easier at least :-) Also, it would help in making fun:s survive loading a new module version. > * Agent extensions What would those be? And why are they interesting? > SECURITY (sorry I'm shouting again) Only a problem if we can't trust our surroundings? (The last two suggest new application areas, I guess?) > We should not add things which makes programming > a little bit more > convenient (which is after all what a lot of the > language changes do) - > we should add thing so we can easily write > applications that nobody else can write. Hear, hear. I fully agree. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From richardc@REDACTED Tue Oct 14 14:00:07 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 14 Oct 2003 14:00:07 +0200 (MET DST) Subject: Relation to Pi Calculus In-Reply-To: <3F8AFE96.6050703@cs.uvm.edu> References: <3F8AFE96.6050703@cs.uvm.edu> Message-ID: On Mon, 13 Oct 2003, David Van Horn wrote: > I've heard that Erlang is essentially an implementation of the untyped > pi calculus. Is this a fair characterization? To say that it is "essentially an implementation of untyped pi calculus" is not very accurate. Erlang is a lot larger than just send/receive/inparallel. Also, in pi calculus *everything* is done by separate processes, while in Erlang, a single process does its internal work by means of executing a functional program. Furthermore, in Erlang you cannot create separate channels - there is only one channel per process (multiple writers allowed, but only the owner process can read from it) which is identified with the process Id. Separate channels must be simulated by tagging the messages. > Which variant of the pi calculus most closely resembles Erlang (eg, > asynchronous pi, distributed pi, seal, join, etc.)? Could someone > provide examples of Erlang primitives that closely rememble the pi > calculus primitives: input, output, and restriction? Process communication in Erlang is asynchronous. The primitives are 'ReceiverPid ! Message', 'receive M -> ... end' and 'spawn(...)'. '!' is the asynchronous send operator. The function 'spawn(...)' takes a description of the code to be executed, and creates a new process for performing that code in parallel, while returning the new process Id to the parent process. The receive statement can have several clauses, with pattern matching on the format of the message, and can leave messages in the incoming queue if they do not match any of the current patterns. There can also be a time-out clause which triggers after a certain number of milliseconds. For more details, see "Concurrent Programming in Erlang", in PDF here: http://www.erlang.org/doc.html > Does a formal semantics of core Erlang exist, and if so where? No formal semantics yet - the only definition is in natural language: http://www.csd.uu.se/projects/hipe/cerl/ /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From richardc@REDACTED Tue Oct 14 14:12:14 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 14 Oct 2003 14:12:14 +0200 (MET DST) Subject: Erlang is getting too big In-Reply-To: <20031014114238.48475.qmail@web41902.mail.yahoo.com> References: <20031014114238.48475.qmail@web41902.mail.yahoo.com> Message-ID: On Tue, 14 Oct 2003, Thomas Lindgren wrote: > A question on #6 below: shouldn't it be that the guard > _fails_ if a subexpression crashes? D'oh! (I need more coffee.) Yes, of course: if a subexpression crashes, it quietly evaluates to *false*, thus failing the test. (And may I repeat: Please don't use this for anything!) > Anyway, a couple of short comments: > > 1. Do we WANT to unify guards and expressions? > Personally, I think it might be good, but not if the > solution is messier than what it replaces. It's not a > "must have" for me. The point, I think, is to try to get nearer to the principle of least surprise. The way guards were originally defined, there were lots of surprises in store, once you went beyond the simple "f(X) when integer(X) -> ..." ones. > 2. Assuming that we do: > > Another approach to unifying guards with expressions > would be to introduce the appropriate type tests as > BIFs. Apart from float/1, this seems straightforward? Well, the "is_..." forms are BIFs, but I assume you mean to keep the names integer(X) etc. and also introduce them as BIFs. But since auto-recognized BIFs override local definitions (sic!), this would probably break a lot of existing code. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From fred@REDACTED Tue Oct 14 15:21:34 2003 From: fred@REDACTED (=?ISO-8859-1?Q?Lars-=C5ke_Fredlund?=) Date: Tue, 14 Oct 2003 15:21:34 +0200 Subject: Relation to Pi Calculus Message-ID: <3F8BF85E.4010006@sics.se> On Mon, 13 Oct 2003, David Van Horn wrote: > Does a > formal semantics of core Erlang exist, and if so where? There are a number of formal semantics for parts of Erlang. Frank Huch for instance did work on abstract interpretation for Erlang and has a formal semantics (he was previously at Aachen, check google to find papers). Here at SICS we were working with theorem proving for Erlang and developed an (operational semantics based) formal semantics (see for instance http://www.sics.se/fdt/publications/lfthesis.pdf) I also like Barklund and Virdings thorough semantics description in natural language (see http://www.erlang.org/download/erl_spec47.ps.gz). === Lars-?ke Fredlund Email: fred@REDACTED Swedish Institute of Computer Science Box 1263 Phone: +46 8 633 1545 164 29 Kista, Sweden Fax: +46 8 751 7230 From thomasl_erlang@REDACTED Tue Oct 14 16:25:51 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 14 Oct 2003 07:25:51 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: Message-ID: <20031014142551.30724.qmail@web41902.mail.yahoo.com> --- Richard Carlsson wrote: > > 2. Assuming that we do: > > > > Another approach to unifying guards with > expressions > > would be to introduce the appropriate type tests > as > > BIFs. Apart from float/1, this seems > straightforward? > > Well, the "is_..." forms are BIFs, but I assume you > mean to keep the names integer(X) etc. and also > introduce them as BIFs. Yes. > But since auto-recognized BIFs override local > definitions (sic!), > this would probably break a lot of existing code. If you mean BIFs that do not need the erlang: prefix, then the override nowadays goes in the other direction. (And correctly so, IMO.) -module(test). -compile(export_all). abs(X) when X > 0 -> X; abs(X) -> -X. 1> c(test). ... Warning: defining BIF abs/1 Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From dgud@REDACTED Tue Oct 14 16:40:21 2003 From: dgud@REDACTED (Dan Gudmundsson) Date: Tue, 14 Oct 2003 16:40:21 +0200 Subject: Erlang is getting too big In-Reply-To: <20031014142551.30724.qmail@web41902.mail.yahoo.com> References: <20031014142551.30724.qmail@web41902.mail.yahoo.com> Message-ID: <16268.2773.757389.493460@rian.du.uab.ericsson.se> Thomas Lindgren writes: > > But since auto-recognized BIFs override local > > definitions (sic!), > > this would probably break a lot of existing code. > > If you mean BIFs that do not need the erlang: prefix, > then the override nowadays goes in the other > direction. (And correctly so, IMO.) > Hmm... -module(junk). -compile(export_all). x(Y) -> abs(Y). abs(X) -> sune. 3> c(junk). ./junk.erl:7: Warning: defining BIF abs/1 {ok,junk} 4> junk:x(8). 8 5> junk:x(-8). 8 6> junk:abs(8). From richardc@REDACTED Tue Oct 14 16:41:34 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 14 Oct 2003 16:41:34 +0200 (MET DST) Subject: Erlang is getting too big In-Reply-To: <20031014142551.30724.qmail@web41902.mail.yahoo.com> References: <20031014142551.30724.qmail@web41902.mail.yahoo.com> Message-ID: On Tue, 14 Oct 2003, Thomas Lindgren wrote: > > But since auto-recognized BIFs override local > > definitions (sic!), > > this would probably break a lot of existing code. > > If you mean BIFs that do not need the erlang: prefix, > then the override nowadays goes in the other > direction. (And correctly so, IMO.) > > -module(test). > -compile(export_all). > > abs(X) when X > 0 -> > X; > abs(X) -> > -X. > > 1> c(test). > ... Warning: defining BIF abs/1 Ah, but that warning only tells you that you have defined a function called abs/1, which is also the name of an auto-recognized BIF. And if you call it from the outside, as in "test:abs(-1)", your function is called, as you expect. But if you try to use it for a local call, you get into trouble, because it is overridden by the BIF: -module(test). -export([myabs/1, abs/1]). myabs(X) -> abs(X). abs(X) when X > 0 -> {abs, X}; abs(X) -> {abs, -X}. 1> c(test). ./test.erl:7: Warning: defining BIF abs/1 {ok,test} 2> test:abs(1). {abs,1} 3> test:myabs(1). 1 4> (And no, the ordering of the functions above does not matter.) Is this sufficiently confusing? /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From c_dhanasekar@REDACTED Tue Oct 14 12:52:23 2003 From: c_dhanasekar@REDACTED (dhanasekaran chenniappan) Date: 14 Oct 2003 10:52:23 -0000 Subject: Erlang Deployment package Message-ID: <20031014105223.1638.qmail@mailweb33.rediffmail.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- Hi, Can any one send me the details about creating deployment package for ERLANG beam on windows 2000 OS. Is it need to install the entire ERLANG environment in the system for run the application. regards dhanas From jesperw@REDACTED Tue Oct 14 16:59:44 2003 From: jesperw@REDACTED (Jesper Wilhelmsson) Date: Tue, 14 Oct 2003 16:59:44 +0200 (MEST) Subject: Garbage collection of binaries In-Reply-To: References: Message-ID: On Mon, 13 Oct 2003, James Hague wrote: > If I write a tail recursive function that loads a large file as a > binary--say, 10MB--on each iteration, then the emulator quickly runs out of > memory and dies. This is apparently because binaries are only garbage > collected when the regular garbage collector runs, and with large binaries > it's easy to run out of memory before then. It's easy to get this to happen > in a real application. > > One hacky solution is to call erlang:garbage_collect all over the place, > but...yuck. Is this being addressed in the run-time system at some point? > Any other workarounds? Binaries are referenced counted and are removed when their conter reach zero. This can happen in the garbage collector as you say, but it can also happen when the process owning it dies. So, I guess a workaround could be to let a new process handle the binary in each iteration, and let it die afterwards. I would of course be possible (and a bit more efficient) to add a BIF that removes the binary explicitly, but from what I have seen in this list, introducing new functionality (and in particular one that destructively removes things from memory) is not that popular right now ;-) __ ___( |_______________________ _______________________________________________ | | ,---. ,--.,--.,--. ( ( | || _ || o ) o ) p ) ) ) "Beware of bugs in the above code; | || (_) || r'| r'| -?--.( ( I have only proved it correct, not tried it." o,--' | `---' |_| |_| `-----' ) ) -- Donald Knuth _`----'______________________( (_______________________________________________ Jesper Wilhelmsson, jesperw@REDACTED +46 (0)18 471 1046 Computing Science Department, Uppsala University, Sweden +46 (0)733 207 207 ------------------------------------------------------------------------------- From sean.hinde@REDACTED Tue Oct 14 19:12:23 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Tue, 14 Oct 2003 18:12:23 +0100 Subject: Garbage collection of binaries In-Reply-To: Message-ID: <93C30A90-FE69-11D7-8668-000A95927CCE@mac.com> On Tuesday, October 14, 2003, at 03:59 pm, Jesper Wilhelmsson wrote: > On Mon, 13 Oct 2003, James Hague wrote: > >> If I write a tail recursive function that loads a large file as a >> binary--say, 10MB--on each iteration, then the emulator quickly runs >> out of >> memory and dies. This is apparently because binaries are only garbage >> collected when the regular garbage collector runs, and with large >> binaries >> it's easy to run out of memory before then. It's easy to get this to >> happen >> in a real application. >> >> One hacky solution is to call erlang:garbage_collect all over the >> place, >> but...yuck. Is this being addressed in the run-time system at some >> point? >> Any other workarounds? > > Binaries are referenced counted and are removed when their conter reach > zero. This can happen in the garbage collector as you say, but it can > also > happen when the process owning it dies. > So, I guess a workaround could be to let a new process handle the > binary > in each iteration, and let it die afterwards. > > I would of course be possible (and a bit more efficient) to add a BIF > that > removes the binary explicitly, but from what I have seen in this list, > introducing new functionality (and in particular one that destructively > removes things from memory) is not that popular right now ;-) > Is there not some mechanism which could be introduced to specifically check for processes growing in this way - I don't know, perhaps every time a very large binary is assigned on the heap check to see if it might be a good time do do a "survival" GC? Maybe a running total could be kept of binaries assigned over a certain size? It would seem to have relatively little overhead compared to the actual operation of making a very large binary, and it would protect against this case quite a bit of the time. Sean From lennart.ohman@REDACTED Tue Oct 14 19:17:12 2003 From: lennart.ohman@REDACTED (=?ISO-8859-1?Q?Lennart_=D6hman?=) Date: Tue, 14 Oct 2003 19:17:12 +0200 Subject: Erlang Deployment package In-Reply-To: <20031014105223.1638.qmail@mailweb33.rediffmail.com> References: <20031014105223.1638.qmail@mailweb33.rediffmail.com> Message-ID: <3F8C2F98.6080908@st.se> Hi, you need the a complete erlang-machine to run Erlang, also in runtime. What you might not need are all the libraries of Erlang code (or applications) The only reason for removing them would be to save space, either on the installation target or during the distribution (the target is downloading over a modem-line for instance). Having a lot of files in a deployment is error prone too, and makes trouble- shooting much harder. For that purpose I recommend you to look at Joe's stand alone Erlang. I have no experience from it, but it seems like something you want to check-out. http://www.sics.se/~joe/sae.html Best Regards, Lennart dhanasekaran chenniappan wrote: > Hi, > Can any one send me the details about creating deployment package for ERLANG beam on windows 2000 OS. Is it need to install the entire ERLANG environment in the system for run the application. > > regards > dhanas -- ------------------------------------------------------------- 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 thomasl_erlang@REDACTED Tue Oct 14 21:12:16 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 14 Oct 2003 12:12:16 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: Message-ID: <20031014191216.29490.qmail@web41906.mail.yahoo.com> --- Richard Carlsson wrote: > > > On Tue, 14 Oct 2003, Thomas Lindgren wrote: > > > > But since auto-recognized BIFs override local > > > definitions (sic!), > > > this would probably break a lot of existing > code. > > > > If you mean BIFs that do not need the erlang: > prefix, > > then the override nowadays goes in the other > > direction. (And correctly so, IMO.) > > > > -module(test). > > -compile(export_all). > > > > abs(X) when X > 0 -> > > X; > > abs(X) -> > > -X. > > > > 1> c(test). > > ... Warning: defining BIF abs/1 > > Ah, but that warning only tells you that you have > defined > a function called abs/1, which is also the name of > an > auto-recognized BIF. > > And if you call it from the outside, as in > "test:abs(-1)", > your function is called, as you expect. > > But if you try to use it for a local call, you get > into > trouble, because it is overridden by the BIF: As the saying goes, I stand corrected. (Thanks also to Dan G for pointing this out.) So, um, well, *shouldn't* a local call really go to the local version too? I think it should. Again, I would suggest sailing through the transition period with a linter. E.g., emit warnings or even errors when finding a call which is ambiguous in this respect. (The linter probably should do that anyway.) Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From bjarne@REDACTED Tue Oct 14 23:03:47 2003 From: bjarne@REDACTED (=?iso-8859-1?Q?Bjarne_D=E4cker?=) Date: Tue, 14 Oct 2003 23:03:47 +0200 Subject: Erlang is getting too big References: <20031013131522.1030.qmail@web40812.mail.yahoo.com> <007701c391bf$f74ff7a0$2100a8c0@virding.org> Message-ID: <00d901c39299$54470d20$700f69d4@segeltorp> > > If a client doesn't want > > to modify his source he always has the option of not > > upgrading past the point where a depricated feature is > > removed. Not quite true. Perhaps later versions are much faster so he likes to use them. Bjarne From cyberlync@REDACTED Wed Oct 15 00:45:07 2003 From: cyberlync@REDACTED (Eric Merritt) Date: Tue, 14 Oct 2003 15:45:07 -0700 (PDT) Subject: Erlang is getting too big In-Reply-To: <00d901c39299$54470d20$700f69d4@segeltorp> Message-ID: <20031014224507.75622.qmail@web40804.mail.yahoo.com> --- Bjarne_D?cker wrote: > > > If a client doesn't want > > > to modify his source he always has the option of > not > > > upgrading past the point where a depricated > feature is > > > removed. > > Not quite true. Perhaps later > versions are much faster so > he likes to use them. Then he should be worth it for him to spend the time and money it takes to do the upgrade ;) > > Bjarne > > __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From ok@REDACTED Wed Oct 15 00:48:50 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 15 Oct 2003 11:48:50 +1300 (NZDT) Subject: Erlang is getting too big Message-ID: <200310142248.h9EMmoIW279522@atlas.otago.ac.nz> Francesco Cesarini wrote: However, less than 5% of programmers end up using LCs, if not less. People who are struggling to come to term with the rest of the language don't, as it is yet another thing to take in. Something they can solve with recursion. The reason that I like higher order functions and comprehensions is that they let me *avoid* recursion. Not that I don't like recursion; I do. But years ago in Prolog I just got *sick* of writing yet another list traversal; life is too short to keep writing the same code over and over and over again. I was originally opposed to the addition of anonymous functions to Erlang (not that anyone asked my opinion) on the grounds that it made the language more complicated, they weren't really needed, and it wasn't clear to me what was supposed to happen when you reloaded a module that defined such things and one or more of them was already in use. I was wrong. Higher order functions and list comprehensions can shorten your code a *lot*, and clear brief code using well-known names for tarversal patterns can be easier to read and maintain than stuff using basic language features. Imagine trying to use Java without `for' and 'while' statements... From bernardp@REDACTED Tue Oct 14 22:12:04 2003 From: bernardp@REDACTED (Pierpaolo BERNARDI) Date: Tue, 14 Oct 2003 22:12:04 +0200 Subject: Varför kan jag inte inte anropa A -- B -- C ? References: <009001c3923f$59b07f80$2d9ab280@lamppc36> Message-ID: <01fb01c392a8$b5132e40$27f06850@c1p4e3> From: "Erik Stenman" > But the "spec" says: Operators with the same priority are evaluated left to > right. ... > Looking at erl_parse.yrl one can see that list_op ('--' and '++') are right > associated. > So either the documentation or the implementation is wrong. > Changing line 105 from: > expr_300 -> expr_400 list_op expr_300 : > mkop('$1', '$2', '$3'). > expr_300 -> expr_400 : '$1'. > to: > expr_300 -> expr_300 list_op expr_400 : > mkop('$1', '$2', '$3'). > expr_300 -> expr_400 : '$1'. > Will give you a left associated parser: > Eshell V5.3 (abort with ^G) > 1> [1,2,3,4,5,6]--[1,2]--[3,4]--[5,6]. > [] But ++ needs to be right associative for efficiency reasons; -- is more intuitive if left associative, like -. It seems the best course would be to separate ++ from --. Second best is to leave like it is now, as ++ is probably more used than --. BTW, in a quick scan of code written by me, I found some functions that would go from linear to quadratic running time, if the associativity of ++ were to be changed. Am I the only one that hadn't read the spec this carefully? Cheers P. From ok@REDACTED Wed Oct 15 03:34:51 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 15 Oct 2003 14:34:51 +1300 (NZDT) Subject: Erlang is getting too big Message-ID: <200310150134.h9F1Yp5S230190@atlas.otago.ac.nz> Richard Carlsson wrote: [that if you define a local function with the same name = (symbol/arity) as a pervasive built-in, then you get a warning that says you've redefined it, and you can call it from the outside, but on the inside you get the built-in]. It seems to me that this is clearly a bug. The warning is useful, but a direct call to a function with a visible local definition should _always_ find that local definition, or what are scope rules for? From richardc@REDACTED Wed Oct 15 10:12:46 2003 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 15 Oct 2003 10:12:46 +0200 (MET DST) Subject: Erlang is getting too big In-Reply-To: <200310150134.h9F1Yp5S230190@atlas.otago.ac.nz> References: <200310150134.h9F1Yp5S230190@atlas.otago.ac.nz> Message-ID: On Wed, 15 Oct 2003, Richard A. O'Keefe wrote: > Richard Carlsson wrote: > [that if you define a local function with the same name > = (symbol/arity) as a pervasive built-in, then you get a > warning that says you've redefined it, and you can call > it from the outside, but on the inside you get the built-in]. > > It seems to me that this is clearly a bug. The warning is useful, but > a direct call to a function with a visible local definition should > _always_ find that local definition, or what are scope rules for? In Erlang, it seems that the main use of scope rules is to make interesting exceptions from them. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From mickael.remond@REDACTED Wed Oct 15 16:13:07 2003 From: mickael.remond@REDACTED (Mickael Remond) Date: Wed, 15 Oct 2003 16:13:07 +0200 Subject: Erlang Deployment package In-Reply-To: <3F8C2F98.6080908@st.se> References: <20031014105223.1638.qmail@mailweb33.rediffmail.com> <3F8C2F98.6080908@st.se> Message-ID: <20031015141306.GA23005@cgey.com> > For that purpose I recommend you to look at Joe's stand alone > Erlang. I have no experience from it, but it seems like something > you want to check-out. > > http://www.sics.se/~joe/sae.html By the way, what is the status of this tool. It was included in last year version of Erlang/OTP, but seems to have been removed from Erlang/OTP R9C-0. Last year, the only remaining problem was with Windows executable generation (it was nearly working). I do not know if the code is know properly working. Cheers -- Micka?l R?mond http://www.erlang-projects.org/ From kenneth@REDACTED Wed Oct 15 16:37:28 2003 From: kenneth@REDACTED (Kenneth Lundin) Date: Wed, 15 Oct 2003 16:37:28 +0200 Subject: Erlang is getting too big References: <200310131956.h9DJuZlU003344@harpo.it.uu.se> Message-ID: <3F8D5BA8.4060603@erix.ericsson.se> Well I just have to comment on this. I don't think there are that many new features in the syntax the past 4 years. The single most important news is in my opinion the Bit-syntax. Some of the other features referred to by Sean and others are not at all part of the language yet (but some are distributed as experimental). - The Java style module naming is still distributed as experimental it is not supported and should not in my opinion be mentioned for beginners. It might be a good idea to make it official but we have not decided to do that yet. - There is ONE syntactic sugar construct regarding records #rec{_ = xx} added. - The new suggested syntactic sugar for type guards "f(I/integer) <-> f(I) when integer(I) is not added to the language yet and we have not decided that it will. - There are some additions regarding guards and guard BIFs. But where are the rest of the new features cluttering the language? Do you think this is a lot of new things over a 4 year period? Do you consider the functions in the kernel and stdlib to be part of the language? Well I think that is a different discussion. I think the record syntax and semantics is something to regret. It is an important feature to have structured datatypes with names on them but not the way records are implemented. In summary I agree that we should be careful with language extensions and I think that we really are. /Kenneth (from the OTP team at Ericsson) Kostis Sagonas wrote: > On Mon, 13 Oct 2003, Sean Hinde wrote: > > > > I think there is and has been quite a bit of action since the bit > > syntax. Duplicate guards, much new syntactic sugar for record > > operations #rec{_ = xx}, Java style module naming, soon to be more > > syntactic sugar for guards, Parameterised modules.. Some of these new > > features have led to head scratching and questions to me from folks > > here learning Erlang in the last few weeks. I think we *are* in severe > > danger of making the core language "too big". > > > > We haven't "taken anything out of the language" to add any of these > > things, and none of them add new capabilities to the language. All of > > them must be understood by anyone learning Erlang, and already they > > cannot all be taught in a week. > > Although I sympathise with Sean's concerns to some extent, I am having > trouble sharing all his worries. Erlang is a small language and I fail > to see why some of the "recently added features" are needed to be taught > in a course that introduces the language to developers, or scare away > people. > > Some examples to illustrate my point: > > 1. "Duplicate guards": There is absolutely no need to teach the old > guards. Simply introduce the new is_* ones! > > [In fact, this is exaclty the point where the OTP team could have > been more agressive in issuing *warnings* about using old guards, > so that applications would be forced to upgrade sooner... but I > guess they want to be spared the hassle from the (paying) user > community. This way, things could even possibly be removed from > the language, and there would not even be a need to mention > the existence of the old ones.] > > 2. "Java style module naming" > Is this so difficult a concept to grasp? > If one thinks the answer is NO, then what's the problem? > If the answer is YES, then is there really needed for this > concept to be mentioned to somebody who wants to find out > what Erlang is all about? > > 3. "Parameterized modules" > This extension is not even available anywhere yet... it is > already being taught in courses? > > Is there something I am missing? > > Cheers, > Kostis > > PS. On Friday, I sent a mail about something I want added to the bit > syntax, but it is still unanswered ;-) > -- Kenneth Lundin Ericsson AB kenneth@REDACTED ?T2/UAB/UKH/K BOX 1505 +46 8 727 57 25 125 25 ?lvsj? From cpressey@REDACTED Wed Oct 15 19:42:24 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 15 Oct 2003 10:42:24 -0700 Subject: One Million Processes In-Reply-To: <20030930190312.GR70644@frogman.motivity.ca> References: <20030930190312.GR70644@frogman.motivity.ca> Message-ID: <20031015104224.5c3b28e2.cpressey@catseye.mine.nu> On Tue, 30 Sep 2003 15:03:12 -0400 Vance Shipley wrote: > I'm soliciting suggestions on an application to create. > The goal is to demonstrate massive concurrency. One thing > I played around with this year was implementing the digraph > module with every vertice as a process. It becomes a living > database. Another obvious choice is the game of life. I'd > prefer something a little more impressive though. How about an evolution simulation? Each process behaves per its "DNA", seeks food (other processes!), reproduces with occasional mutations, etc. It would be interesting to see if the processes could evolve in communication (for cooperation, for instance.) At any rate, it would give a fresh vividness to terms like 'kill' and 'spawn' :) -Chris From vances@REDACTED Wed Oct 15 22:29:11 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 15 Oct 2003 16:29:11 -0400 Subject: One Million Processes In-Reply-To: <20031015104224.5c3b28e2.cpressey@catseye.mine.nu> References: <20030930190312.GR70644@frogman.motivity.ca> <20031015104224.5c3b28e2.cpressey@catseye.mine.nu> Message-ID: <20031015202911.GC6191@frogman.motivity.ca> Chris, This is the sort of thing I've been thinking about, it's the game of life however the children grow, go to school, get jobs and support they're parents. Unlike the basic game of life there is no grid so the concept of how these processes discover each other to interact is what I haven't thought through. It does lend itself well to infinite uptime. -Vance On Wed, Oct 15, 2003 at 10:42:24AM -0700, Chris Pressey wrote: } } How about an evolution simulation? Each process behaves per its "DNA", } seeks food (other processes!), reproduces with occasional mutations, } etc. It would be interesting to see if the processes could evolve in } communication (for cooperation, for instance.) } } At any rate, it would give a fresh vividness to terms like 'kill' and } 'spawn' :) } } -Chris From cyberlync@REDACTED Wed Oct 15 23:47:17 2003 From: cyberlync@REDACTED (Eric Merritt) Date: Wed, 15 Oct 2003 14:47:17 -0700 (PDT) Subject: One Million Processes In-Reply-To: <20031015202911.GC6191@frogman.motivity.ca> Message-ID: <20031015214717.47862.qmail@web40810.mail.yahoo.com> > This is the sort of thing I've been thinking about, > it's the > game of life however the children grow, go to > school, get jobs > and support they're parents. This is similar to what I have been thinking about for a long time. My idea is more game oriented, but with a real ecosystem (well as real as can be easily simulated ;) > Unlike the basic game of life there is no grid so > the concept > of how these processes discover each other to > interact is what > I haven't thought through. I havn't found a way around this either. I am guessing you could present a single process that stores the location of other processes in some kind of rtree, but I am not sure how efficient that would be in erlang. > It does lend itself well to infinite uptime. > Not to mention that process make constructing a simulation like this really really easy. __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From Chandrashekhar.Mullaparthi@REDACTED Thu Oct 16 12:30:23 2003 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Thu, 16 Oct 2003 11:30:23 +0100 Subject: One Million Processes Message-ID: > -----Original Message----- > From: Vance Shipley [mailto:vances@REDACTED] > > > Chris, > > This is the sort of thing I've been thinking about, it's the > game of life however the children grow, go to school, get jobs > and support they're parents. > > Unlike the basic game of life there is no grid so the concept > of how these processes discover each other to interact is what > I haven't thought through. > > It does lend itself well to infinite uptime. > > -Vance Vance, As you spawn these processes, you could make them aware of their "neighbours" - a few processes spawned before and after. Each process can have a "socialising" algorithm to introduce it's "neighbours" to other processes. They can randomly decide whether they "like" the new process or not. You can do all sorts of stuff with this - only limited by your imagination :-) cheers Chandru NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From olivier@REDACTED Thu Oct 16 14:13:47 2003 From: olivier@REDACTED (Olivier) Date: Thu, 16 Oct 2003 14:13:47 +0200 Subject: gethostbyname/1 on Freebsd Message-ID: <3F8E8B7B.2000207@dolphian.com> hi all, i'm having problems with gethostbyname/1 on FreeBSD: 1> inet:gethostbyname("localhost"). {ok,{hostent,"localhost",["naboo.dolphian.priv","naboo"],inet,4,[{127,0,0,1}]}} 2> inet:gethostbyname("naboo"). {ok,{hostent,"localhost",["naboo.dolphian.priv","naboo"],inet,4,[{127,0,0,1}]}} 3> inet:gethostbyname("haruki"). {error,nxdomain} /etc/resolv.conf is ok: search dolphian.priv nameserver 192.168.100.1 $ host haruki haruki.dolphian.priv has address 192.168.100.239 same configuration on a linux box works as expected: 1> inet:gethostbyname("penelope"). {ok,{hostent,"penelope.dolphian.priv",[],inet,4,[{192,168,100,173}]}} any idea ? erlang is: Erlang (BEAM) emulator version 5.3 (installed from the ports) thanks in advance, -- olivier From jesperw@REDACTED Thu Oct 16 13:49:15 2003 From: jesperw@REDACTED (Jesper Wilhelmsson) Date: Thu, 16 Oct 2003 13:49:15 +0200 (MEST) Subject: Garbage collection of binaries In-Reply-To: <93C30A90-FE69-11D7-8668-000A95927CCE@mac.com> References: <93C30A90-FE69-11D7-8668-000A95927CCE@mac.com> Message-ID: On Tue, 14 Oct 2003, Sean Hinde wrote: > > Is there not some mechanism which could be introduced to specifically > check for processes growing in this way - I don't know, perhaps every > time a very large binary is assigned on the heap check to see if it > might be a good time do do a "survival" GC? Maybe a running total could > be kept of binaries assigned over a certain size? It would seem to have > relatively little overhead compared to the actual operation of making a > very large binary, and it would protect against this case quite a bit > of the time. > > Sean To do an off-heap collection (to reclaim objects that is not allocated in the heap, ie binaries), and find all references to these objects (or to see that there are no references), you have to look through all memory that can contain these references. That is, all heaps and all stacks. This would be expensive, but maybe not SO expensive compared to creating a large binary. In the private heap architecture, it would be possible to mark all processes that have had a reference to a binary and only scan those processes. This is not possible in a shared heap architecture though. If this is needed in an application or not, is verry much depended on the application. Perhaps it is better if the programmer who knows if it is needed or not, calls garbage_collect() in concerned processes before creating a large binary, the cost would be the same if it was done under the surface anyway. The difference in this case is, that the programmer probably knows that it is only these three processes that have touched the large binaries and needs collections. The system would only know that there are twenty processes that have binaries - they all need collection. .joppe __ ___( |_______________________ _______________________________________________ | | ,---. ,--.,--.,--. ( ( | || _ || o ) o ) p ) ) ) "Beware of bugs in the above code; | || (_) || r'| r'| -?--.( ( I have only proved it correct, not tried it." o,--' | `---' |_| |_| `-----' ) ) -- Donald Knuth _`----'______________________( (_______________________________________________ Jesper Wilhelmsson, jesperw@REDACTED +46 (0)18 471 1046 Computing Science Department, Uppsala University, Sweden +46 (0)733 207 207 ------------------------------------------------------------------------------- From raimo@REDACTED Thu Oct 16 17:15:18 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Thu, 16 Oct 2003 17:15:18 +0200 Subject: gethostbyname/1 on Freebsd References: <3F8E8B7B.2000207@dolphian.com> Message-ID: How is /etc/host.conf and|or /etc/nsswitch.conf? Try inet_db:set_lookup([file,native]). And then inet:gethostbyname("haruki"). If that works and you can not fix it with your /etc/host.conf and such files, create a file .inetrc in your home directory containing: {lookup,["file","native"]}. You may skip the "file" options above. Just "native" should work fine. This trick will force Erlang to use the operating system (native) name resolver and not try to interprete all the very operating system dependent weird files. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB Olivier wrote: > > hi all, > > i'm having problems with gethostbyname/1 on FreeBSD: > > 1> inet:gethostbyname("localhost"). > {ok,{hostent,"localhost",["naboo.dolphian.priv","naboo"],inet,4,[{127,0,0,1}]}} > > 2> inet:gethostbyname("naboo"). > {ok,{hostent,"localhost",["naboo.dolphian.priv","naboo"],inet,4,[{127,0,0,1}]}} > > 3> inet:gethostbyname("haruki"). > {error,nxdomain} > > /etc/resolv.conf is ok: > search dolphian.priv > nameserver 192.168.100.1 > > $ host haruki > haruki.dolphian.priv has address 192.168.100.239 > > same configuration on a linux box works as expected: > > 1> inet:gethostbyname("penelope"). > {ok,{hostent,"penelope.dolphian.priv",[],inet,4,[{192,168,100,173}]}} > > any idea ? erlang is: > > Erlang (BEAM) emulator version 5.3 (installed from the ports) > > thanks in advance, > > -- > olivier > From joachim.durchholz@REDACTED Thu Oct 16 19:30:02 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Thu, 16 Oct 2003 19:30:02 +0200 Subject: Erlang is getting too big In-Reply-To: <20031013131522.1030.qmail@web40812.mail.yahoo.com> References: <20031013131522.1030.qmail@web40812.mail.yahoo.com> Message-ID: <3F8ED59A.9090203@web.de> Eric Merritt wrote: > Why is it impossible to take something away? If you > give ample warning, say depricating a feature two or > three releases before it goes away, and provide a very > clear migration path to new features it should not be > a problem to remove features. You also need a way to convert existing code that uses deprecated features. The conversion must not take more than O(1), O(log LOC) just might be OK, O (LOC) would be out of the question. And it's d*mned f*cking hard to offer such a migration part. It almost invariably means some automatic conversion tools, and getting such one-shot conversion tools written, tested and debugged is one of those things that tend to sort-of work. (I have worked in a company where such things were done, though I haven't worked directly with them - but I got told the war stories, and the above is what the stories agreed on.) Regards, Jo From joachim.durchholz@REDACTED Thu Oct 16 19:39:36 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Thu, 16 Oct 2003 19:39:36 +0200 Subject: Erlang is getting too big (Long and a lot of shouting :-) In-Reply-To: References: Message-ID: <3F8ED7D8.7030805@web.de> Joe Armstrong wrote: > [snip] YES!!! [Hammering my keyboard in unison with you *ggg*] Regards, Jo From mwilligs@REDACTED Thu Oct 16 20:58:18 2003 From: mwilligs@REDACTED (Miguel Willigs) Date: Thu, 16 Oct 2003 15:58:18 -0300 (PYST) Subject: megaco_test_mg and megaco_test_mgc Message-ID: <33057.65.198.40.11.1066330698.squirrel@unimail.uninet.com.py> Hi there I have a problem triyng to run these test files. I wrote the commands as follow: In the MGC side: erl -sname mgc (mgc@REDACTED)1>megaco_test_mgc:start(node(),[{deviceName,"ctrl"}],[{text,tcp}],debug). and in the MG side: erl -sname mg (mg@REDACTED)1> megaco_test_mg:start(node(), {deviceName,"mg"}, text, tcp, debug). No problem in this point, but when I am triyng to run megaco_test_mg:service_change/1 in the mg side, I get the following error message: <0.37.0>:MG: loop(initiated) -> received request to perform service change DBG: <0.37.0>:MG: loop(initiated) -> service change result: {error, {bad_megaco_conn_handle, {error, {megaco_tcp_connect, {gen_tcp_connect, econnrefused}}}}} Could somebody tell me what's wrong? thanks in advance, From mwilligs@REDACTED Thu Oct 16 21:10:42 2003 From: mwilligs@REDACTED (Miguel Willigs) Date: Thu, 16 Oct 2003 16:10:42 -0300 (PYST) Subject: megaco_test_mg and megaco_test_mgc Message-ID: <33075.65.198.40.11.1066331442.squirrel@unimail.uninet.com.py> Hi there I have a problem triyng to run these test files. I wrote the commands as follow: In the MGC side: erl -sname mgc (mgc@REDACTED)1>megaco_test_mgc:start(node(),[{deviceName,"ctrl"}],[{text,tcp}],debug). and in the MG side: erl -sname mg (mg@REDACTED)1> megaco_test_mg:start(node(), {deviceName,"mg"}, text, tcp, debug). No problem in this point, but when I am triyng to run megaco_test_mg:service_change/1 in the mg side, I get the following error message: <0.37.0>:MG: loop(initiated) -> received request to perform service change DBG: <0.37.0>:MG: loop(initiated) -> service change result: {error, {bad_megaco_conn_handle, {error, {megaco_tcp_connect, {gen_tcp_connect, econnrefused}}}}} But the most common message error is in the MGC side, is the following: *** [2003:10:16 19:18:45 4444] DBG: <0.37.0> MGC *** loop -> received megaco request from <0.74.0>: {handle_trans_request,{megaco_conn_handle, [{deviceName,"ctrl"}], {deviceName,"mg"}}, 1, [{'ActionRequest', 0, asn1_NOVALUE, asn1_NOVALUE, [{'CommandRequest', {serviceChangeReq, {'ServiceChangeRequest', [{megaco_term_id,false,["root"]}], {'ServiceChangeParm', restart, asn1_NOVALUE, asn1_NOVALUE, asn1_NOVALUE, ["901"], asn1_NOVALUE, asn1_NOVALUE, asn1_NOVALUE, asn1_NOVALUE}}}, asn1_NOVALUE, asn1_NOVALUE}]}]} *** [2003:10:16 19:18:45 4451] DBG: <0.37.0> MGC *** loop -> send request reply: {delay_reply,0, {discard_ack,[{'ActionReply', 0, asn1_NOVALUE, asn1_NOVALUE, [{serviceChangeReply, {'ServiceChangeReply', [{megaco_term_id,false,["root"]}], {serviceChangeResParms, {'ServiceChangeResParm', [{deviceName,"ctrl"}], asn1_NOVALUE, asn1_NOVALUE, asn1_NOVALUE, asn1_NOVALUE}}}}]}]}} *** [2003:10:16 19:18:45 4454] DBG: <0.37.0> MGC *** loop -> await request (mgc@REDACTED)2> =ERROR REPORT==== 16-Oct-2003::16:18:45 === encode trans reply body failed: {megaco_pretty_text_encoder,encode_message,[[],{'MegacoMessage',asn1_NOVALUE,{'Message',1,[{deviceName,[99,116,114,108]}],{transactions,[{transactionReply,{'TransactionReply',1,asn1_NOVALUE,{actionReplies,[{'ActionReply',0,asn1_NOVALUE,asn1_NOVALUE,[{serviceChangeReply,{'ServiceChangeReply',[{megaco_term_id,false,[[114,111,111,116]]}],{serviceChangeResParms,{'ServiceChangeResParm',[{deviceName,[99,116,114,108]}],asn1_NOVALUE,asn1_NOVALUE,asn1_NOVALUE,asn1_NOVALUE}}}}]}]}}}]}}}],{error,{function_clause,[{megaco_pretty_text_encoder,enc_MId,[[{deviceName,[99,116,114,108]}],[]]},{megaco_pretty_text_encoder,enc_Message,2},{megaco_pretty_text_encoder,enc_MegacoMessage,2},{megaco_pretty_text_encoder,encode_message,2},{megaco_messenger_misc,encode_body,3},{megaco_messenger,send_reply,3},{megaco_messenger,handle_request_callback,3},{megaco_messenger,handle_requests,2}|more]}}} Could somebody tell me what's wrong? thanks in advance, From robert.virding@REDACTED Thu Oct 16 23:06:34 2003 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 16 Oct 2003 23:06:34 +0200 Subject: Enhanced type guard syntax] References: <3F697CCB.6000603@erix.ericsson.se> Message-ID: <00ac01c39429$63369f80$2100a8c0@virding.org> Unfortunately I missed this discussion when it came out but I will give my opinion now. I don't really know what others have said so I may just be repeating someone elses opinion. My first instinctive gut reaction was "Definitely not". It breaks one of my/our basic principles which I hope we wrote down somewhere. If we didn'r we definitely should have. That is that you can use the same pattern on both sides for constructing and destructing a term. And that can always do it. This should work with all terms including binaries. This new idea breaks this principle. I can't write: A = 1, B = 2, {A/integer,B/integer} = {A/integer,B/integer}, Well, I can of course, but the meaning of /integer is different on each side of =. Which is a Bad Thing! As I have said before that as I get older I value consistency more. Just to be very clear here, it is not that there is a = here which is important, but this was just a way to get patterns and terms together concisely. My second more thought through reaction is still "Defintely not". Now I will have torea what others have written. Robert ----- Original Message ----- From: "Kenneth Lundin" To: Sent: Thursday, September 18, 2003 11:37 AM Subject: Enhanced type guard syntax] > > Below follows a suggestion regarding enhanced syntax for > writing type guards in function clauses and in other match expressions. > > I post this to see if you in the Erlang community have some (positive > or negative) opinions regarding this and I hope I get a lot of feedback. > > > > > Enhanced type guard syntax > --------------------------------------- > > The situation to day is that it is quite cumbersome to write type guards > for a function and that it > is unfair that some type constraints can be expressed directly in the > argument list (list, tuple,Binary) > while other type constraints must be expressed in the guard > (integer,atom,float,pid,port,fun) where the argument names have to be > repeated again. > The idea is originally from Mats Cronqvist AXD. > > Examples as it is today: > ------------------------ > > % The constraint that A and B must be integers > % must be expressed in the guard notation with the arguments repeated > % > foo(A, B) when integer(A), integer(B) -> > A * B. > > % The constraint that it must be a list (with at least one element) > % can be expressed directly in the argumentlist > % > bar([H|T]) -> > H. > > > > Proposed solution > ------------------ > > Examples with new suggested syntax: > ----------------------------------- > > % The type constraint expressed directly in the argument list > % Shorter to write > % Exactly the same semantics as the foo example above > % The compiler has potential of handling these type constraints more > efficiently than today > % and this syntax makes the different type of guards more visible > % > foo(A/integer, B/integer) -> > A * B. > > > {X/float, Y/float} = graph:coordinates(), > > The rationale behind this suggestion is that we already have the > Variable/type syntax in the matchexpressions for binaries (example: > <> = <<2,"AB","CD">>) > It is unfair that some types can be matched without guard syntax while > others can't. > It will result in a more compact and intuitive way of writing that will > encourage writing type constraints which will catch errors as early and > efficient as possible. The allowed type specifiers should be all the > type test BIFs named is_XXX/1 but without the "is_" prefix. > > Alternative syntax > ------------------- > > Of course some other special character can be used to distinguish the > type constraint from other tokens and one idea could be to make this as > an extension to the '_' (don't care) notation which then indicates don't > care the value but it should be of a certain type. > > foo(A = $integer, B = $integer) -> > A*B. > > foo(A = _$integer, B = _$integer) -> > > Advantages with this solution could be that it does only introduce the > new variants of typed don't care. > > > /Regards Kenneth Lundin Product Manager of Erlang/OTP > > > From robert.virding@REDACTED Thu Oct 16 23:41:37 2003 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 16 Oct 2003 23:41:37 +0200 Subject: =?iso-8859-1?Q?Re:_Varf=F6r_kan_jag_inte_inte_anropa_A_--_B_--_C_=3F?= References: <009001c3923f$59b07f80$2d9ab280@lamppc36> <01fb01c392a8$b5132e40$27f06850@c1p4e3> Message-ID: <01cc01c3942e$477bad80$2100a8c0@virding.org> Unfortunately you are all missing something, -- is a big joke. After I had added the ++ syntax, it is just syntactic sugar really, I just had to add -- as a joke. I was also planning to add ** and // but I couldn't really come up with good list meanings so I dropped it. That is why there is no really thought out semantics for --. The operator associativity had to be the same as ++ though. Sometimes I still get the feeling we should have done the same as Smalltalk. Robert ----- Original Message ----- From: "Pierpaolo BERNARDI" To: Sent: Tuesday, October 14, 2003 10:12 PM Subject: Re: Varf?r kan jag inte inte anropa A -- B -- C ? > From: "Erik Stenman" > > > But the "spec" says: Operators with the same priority are evaluated left > to > > right. > ... > > Looking at erl_parse.yrl one can see that list_op ('--' and '++') are > right > > associated. > > So either the documentation or the implementation is wrong. > > Changing line 105 from: > > expr_300 -> expr_400 list_op expr_300 : > > mkop('$1', '$2', '$3'). > > expr_300 -> expr_400 : '$1'. > > to: > > expr_300 -> expr_300 list_op expr_400 : > > mkop('$1', '$2', '$3'). > > expr_300 -> expr_400 : '$1'. > > Will give you a left associated parser: > > Eshell V5.3 (abort with ^G) > > 1> [1,2,3,4,5,6]--[1,2]--[3,4]--[5,6]. > > [] > > But ++ needs to be right associative for efficiency reasons; > -- is more intuitive if left associative, like -. > > It seems the best course would be to separate ++ from --. > Second best is to leave like it is now, as ++ is probably > more used than --. > > BTW, in a quick scan of code written by me, I found some functions > that would go from linear to quadratic running time, if the > associativity of ++ were to be changed. > Am I the only one that hadn't read the spec this carefully? > > Cheers > P. > > From garry@REDACTED Fri Oct 17 04:44:50 2003 From: garry@REDACTED (Garry Hodgson) Date: Thu, 16 Oct 2003 22:44:50 -0400 (EDT) Subject: One Million Processes In-Reply-To: <20031015202911.GC6191@frogman.motivity.ca> References: <20031015202911.GC6191@frogman.motivity.ca> Message-ID: <2003101622441066358682@k2.sage.att.com> Vance Shipley wrote: > This is the sort of thing I've been thinking about, it's the > game of life however the children grow, go to school, get jobs > and support they're parents. > > Unlike the basic game of life there is no grid so the concept > of how these processes discover each other to interact is what > I haven't thought through. > > It does lend itself well to infinite uptime. or at least until they develop nuclear weapons and blow up your cluster. ---- Garry Hodgson, Technology Consultant, AT&T Labs Be happy for this moment. This moment is your life. From francesco@REDACTED Fri Oct 17 08:41:05 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Fri, 17 Oct 2003 07:41:05 +0100 Subject: heart anyone? Message-ID: <3F8F8F01.9020800@erlang-consulting.com> Dear Erlangers, before I head off to reinvent the wheel, I was wondering if any one has implemented their own version of heart. What we are looking for is a behaviour similar to the supervisor one, where you can allow a maximum of X local restarts of the beam emulator in Y seconds. Possibly after X restarts, the OS is rebooted, erlang started up again, and if it crashes, the whole system just stops. Needless to say cyclic restarts have been a problem.. Any other thoughts on heart are welcome. Past problems, praises, horror stories, et all. Thanks, Francesco -- http://www.erlang-consulting.com From hakan@REDACTED Fri Oct 17 09:26:07 2003 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 17 Oct 2003 09:26:07 +0200 (MEST) Subject: megaco_test_mg and megaco_test_mgc In-Reply-To: <33075.65.198.40.11.1066331442.squirrel@unimail.uninet.com.py> Message-ID: On Thu, 16 Oct 2003, Miguel Willigs wrote: Miguel> No problem in this point, but when I am triyng to run Miguel> megaco_test_mg:service_change/1 in the mg side, I get the following error Miguel> message: Miguel> Miguel> <0.37.0>:MG: loop(initiated) -> received request to perform service change Miguel> DBG: <0.37.0>:MG: loop(initiated) -> service change result: {error, Miguel> {bad_megaco_conn_handle, Miguel> {error, Miguel> {megaco_tcp_connect, Miguel> {gen_tcp_connect, Miguel> econnrefused}}}}} This means that gen_tcp:connect fails with a 'econnrefused' error code. No one is listening on the remote address. Either the MGC is not started or it is listening on the wrong port. Miguel> But the most common message error is in the MGC side, is the following: The key information in the error printout is: {error,{function_clause,[{megaco_pretty_text_encoder,enc_MId,[[{deviceName,[99,116,114,108]}],[]]} By reading the source code for enc_MId/2 in megaco_text_gen.hrl or by checking the ASN.1 spec for the MID's definition it becomes clear that the error is in the serviceChangeMgcId field in the 'ServiceChangeResParm' record. It should be {deviceName,"ctrl"} and not [{deviceName,"ctrl"}]. /H?kan --- H?kan Mattsson Ericsson High Availability Software, DBMS Internals http://www.erlang.org/~hakan/ From micael.karlberg@REDACTED Fri Oct 17 09:44:01 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Fri, 17 Oct 2003 09:44:01 +0200 Subject: megaco_test_mg and megaco_test_mgc In-Reply-To: <33057.65.198.40.11.1066330698.squirrel@unimail.uninet.com.py> References: <33057.65.198.40.11.1066330698.squirrel@unimail.uninet.com.py> Message-ID: <16271.40385.716187.831012@gargle.gargle.HOWL> Hi, Miguel Willigs writes: > Hi there > > I have a problem triyng to run these test files. > I wrote the commands as follow: > In the MGC side: > > erl -sname mgc > (mgc@REDACTED)1>megaco_test_mgc:start(node(),[{deviceName,"ctrl"}],[{text,tcp}],debug). The Mid should (in this case) be: {deviceName,"ctrl"} This causes the MGC to crash when attempting to encode the service change reply. > > and in the MG side: > > erl -sname mg > (mg@REDACTED)1> megaco_test_mg:start(node(), {deviceName,"mg"}, text, tcp, > debug). > > No problem in this point, but when I am triyng to run > megaco_test_mg:service_change/1 in the mg side, I get the following error > message: > > <0.37.0>:MG: loop(initiated) -> received request to perform service change > DBG: <0.37.0>:MG: loop(initiated) -> service change result: {error, > {bad_megaco_conn_handle, > {error, > {megaco_tcp_connect, > {gen_tcp_connect, > econnrefused}}}}} H?kan has already relied to this. > > Could somebody tell me what's wrong? > > thanks in advance, Regards, /BMK From micael.karlberg@REDACTED Fri Oct 17 09:57:52 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Fri, 17 Oct 2003 09:57:52 +0200 Subject: megaco_test_mg and megaco_test_mgc In-Reply-To: <16271.40385.716187.831012@gargle.gargle.HOWL> References: <33057.65.198.40.11.1066330698.squirrel@unimail.uninet.com.py> <16271.40385.716187.831012@gargle.gargle.HOWL> Message-ID: <16271.41216.709110.711605@gargle.gargle.HOWL> Micael Karlberg writes: > Hi, > <--- snip ---> > > H?kan has already relied to this. ------ My spelling checker (Niclas Eklund) tells me, that I missed a 'p' in replied... /BMK From svenolof@REDACTED Fri Oct 17 09:51:17 2003 From: svenolof@REDACTED (Sven-Olof Nystr|m) Date: Fri, 17 Oct 2003 09:51:17 +0200 Subject: =?iso-8859-1?Q?Re:_Varf=F6r_kan_jag_inte_inte_anropa_A_--_B_--_C_=3F?= In-Reply-To: <01cc01c3942e$477bad80$2100a8c0@virding.org> References: <009001c3923f$59b07f80$2d9ab280@lamppc36> <01fb01c392a8$b5132e40$27f06850@c1p4e3> <01cc01c3942e$477bad80$2100a8c0@virding.org> Message-ID: <16271.40821.581238.973636@mirach.it.uu.se> Robert Virding writes: > Unfortunately you are all missing something, -- is a big joke. After > I had added the ++ syntax, it is just syntactic sugar really, I just had > to add -- as a joke. I was also planning to add ** and // but I > couldn't really come up with good list meanings so I dropped it. > That is why there is no really thought out semantics for --. > > The operator associativity had to be the same as ++ though. Sometimes > I still get the feeling we should have done the same as Smalltalk. > Of course, this means that the minusminus operator is now part of the language and must be supported in the future. It is also difficult to understand your motivation for making the ++ operator right-associative. What prevents a compiler from implementing (X ++ Y) ++ Z as "first concatenate Y and Z, then concatenate X with the result"? Sven-Olof From joachim.durchholz@REDACTED Fri Oct 17 11:07:50 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Fri, 17 Oct 2003 11:07:50 +0200 Subject: Garbage collection of binaries In-Reply-To: References: Message-ID: <3F8FB166.9050304@web.de> James Hague wrote: > One hacky solution is to call erlang:garbage_collect all over the place, > but...yuck. Destruct the last known reference to the binary, then call garbage_collect. That's not too yucky: the code that's responsible for the binary is also responsible for the clean-up. I'm somewhat surprised that GC doesn't kick in. It should. The binary is taking up lots of memory. > Any other workarounds? I'd recommend Sean's solution. Processes are cheap after all. Regards, Jo From joachim.durchholz@REDACTED Fri Oct 17 11:14:58 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Fri, 17 Oct 2003 11:14:58 +0200 Subject: Garbage collection of binaries In-Reply-To: <93C30A90-FE69-11D7-8668-000A95927CCE@mac.com> References: <93C30A90-FE69-11D7-8668-000A95927CCE@mac.com> Message-ID: <3F8FB312.7050500@web.de> Sean Hinde wrote: > Is there not some mechanism which could be introduced to specifically > check for processes growing in this way - I don't know, perhaps every > time a very large binary is assigned on the heap check to see if it > might be a good time do do a "survival" GC? Maybe a running total could > be kept of binaries assigned over a certain size? Yuck - that's all things that GC is already supposed to do. One thing that I have seen happen is that GC didn't take the binaries into account when deciding whether it should collect or not. In other words, the decision was made based on heap use, not based on total memory footprint. In that case, it's quite easy to fill up the entire swap space without the GC ever kicking in. Personally, I think that binaries should not be reference counted, they should be managed by an Erlang object that keeps the information on the true size of the binary. YMMV :-) Regards, Jo From joachim.durchholz@REDACTED Fri Oct 17 11:17:49 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Fri, 17 Oct 2003 11:17:49 +0200 Subject: Garbage collection of binaries In-Reply-To: References: Message-ID: <3F8FB3BD.1080107@web.de> Jesper Wilhelmsson wrote: > Binaries are referenced counted and are removed when their conter reach > zero. This gives me another approach: when you're done with a binary, zero out all references to it. The binary will go away immediately. (This might be impossible if the reference is created as an intermediate result. It might also interfere with tail recursion. Using reference counts in a functional language doesn't strike me as a particularly good solution in this light...) Regards, Jo From joachim.durchholz@REDACTED Fri Oct 17 12:11:14 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Fri, 17 Oct 2003 12:11:14 +0200 Subject: Spatial Indexes in mnesia In-Reply-To: <20031013175301.19296.qmail@web40809.mail.yahoo.com> References: <20031013175301.19296.qmail@web40809.mail.yahoo.com> Message-ID: <3F8FC042.5090600@web.de> You can fake spatial indexes via "bit interleaving". Assuming four-bit X, Y, and Z coordinates XXXX, YYYY, and ZZZZ, construct a bit vector XYZXYZXYZXYZ. When traversing the records in the order imposed by that index, you'll retrieve them in the order that you'd visit them if they were stored in an octree. For example, if you have the interleaved coordinates 00101xxxxxxx (where the "x" indicate don't-care bits), this will give the XYZ coordinates (00xx,01xx,1xxx), which is exactly the area that a specific octree node covers. To actually find those records within the space indicated by the query, the following algorithm is in order: * The algorithm takes two parameters, one of them an interleaved coordinate with don't cares TV (the "test vector"), and a set of test vectors IN, containing ranges that are known to be entirely within the area described by the query. * If the coordinate range indicated by TV contains no records, return IN. * If the range indicated by TV is entirely within the space described by the query, return IN + {TV}. * If the range indicated by TV is entirely outside the space described by the query, return IN. * Otherwise, create two new test vectors from TV: one by replacing the first don't-care bit of TV with a 0, and one by replacing it with 1, giving the new test vectors TV0 and TV1. Return ALG (TV0, ALG (TV1, IN)) where ALG is this algorithm. This will give a set of ranges that contain the records within the space indicated by the query, ready for retrieving them from mnesia. This is a useful framework. For one, set operations are easy to do on this representation. Intersection and union of range lists are nearly trivial, set difference requires a bit of thinking and care but is rather straightforward as well. Another question might be how to set up a view. The algorithm doesn't return a Mnesia view, it returns lists of coordinate ranges. To convert them to a view without doing extensive changes to Mnesia, you'd have to construct a temporary table with the (primary keys of) the records that are selected by the spatial query. I'm not sure how attractive efficiency-wise that would be, but it might save your neck if you need to postprocess the result set with further queries. A general note: the above algorithm leaves open how the intersection test between coordinate ranges and geometric figures can be done. In the most general case, the intersection-testing code would be passed in as a function or as a fun. However, such testing can be tricky for complicated geometric queries. It might be better to write a test function for simple queries ("inside a rectangular range", "inside an ellipsoid", "to the right of a plane" etc.), run the algorithm for each simple query that's in the complex query, and then do set operations. Note that for this to work, you need every simple query in two forms: one for the inside and one for the outside. It might save a few lines of code and a few hours of testing to make three-valued functions that return "inside", "outside", or "intersects", and adapt the base algorithm accordingly. Hope this all is useful to somebody. Regards, Jo From bjorn@REDACTED Fri Oct 17 12:19:03 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 17 Oct 2003 12:19:03 +0200 Subject: Binary pattern syntax anomaly In-Reply-To: <200310101357.h9ADvELi018544@harpo.it.uu.se> References: <200310101357.h9ADvELi018544@harpo.it.uu.se> Message-ID: We rejected nested binary patterns to keep the implementation simple. We discussed the possibibility to have the compiler automatically flatten nested patterns, but we decided not to do it because the semantics could be different if patterns were not aligned on byte boundaries. (Your example pattern could be flattened without changing the semantics.) /Bjorn P.S. I have not had any free time for reading erlang-questions the last couple of weeks. Therefore the late answer. Kostis Sagonas writes: > Is there any particularly good reason why the following piece of > Erlang code works correctly > > B = <<2,42>>, > <<1, B/binary>> = <<1, <<2,42>>/binary>>. > > while the following (semantically equivalent) code > > <<1, <<2,42>>/binary>> = <<1, <<2,42>>/binary>>. > > gets rejected as an illegal pattern? > > Isn't this a bug, or at least a totally unnecessary restriction > in the syntax of binary patterns? > > Kostis. > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From robert.virding@REDACTED Fri Oct 17 13:47:52 2003 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 17 Oct 2003 13:47:52 +0200 Subject: =?iso-8859-1?Q?Re:_Re:_Varf=F6r_kan_jag_inte_inte_anropa_A_--_B_--_C_=3F?= References: <009001c3923f$59b07f80$2d9ab280@lamppc36><01fb01c392a8$b5132e40$27f06850@c1p4e3><01cc01c3942e$477bad80$2100a8c0@virding.org> <16271.40821.581238.973636@mirach.it.uu.se> Message-ID: <003f01c394a4$7f4d0fd0$8500000a@Clarke> ----- Original Message ----- From: "Sven-Olof Nystr|m" To: "Robert Virding" Cc: "Pierpaolo BERNARDI" ; Sent: Friday, October 17, 2003 9:51 AM Subject: Re: Re: Varf?r kan jag inte inte anropa A -- B -- C ? > Robert Virding writes: > > Unfortunately you are all missing something, -- is a big joke. After > > I had added the ++ syntax, it is just syntactic sugar really, I just had > > to add -- as a joke. I was also planning to add ** and // but I > > couldn't really come up with good list meanings so I dropped it. > > That is why there is no really thought out semantics for --. > > > > The operator associativity had to be the same as ++ though. Sometimes > > I still get the feeling we should have done the same as Smalltalk. > > > > Of course, this means that the minusminus operator is now part of the > language and must be supported in the future. Yes, I know. Wonderful isn't it? > It is also difficult to understand your motivation for making the ++ > operator right-associative. What prevents a compiler from implementing > (X ++ Y) ++ Z as "first concatenate Y and Z, then concatenate X with > the result"? Just to make the associativity relate to how you would like it to work. If the terms are expressions it makes it a little clearer what is happening. At least I think so. Robert From anders.fluur@REDACTED Fri Oct 17 12:07:13 2003 From: anders.fluur@REDACTED (Anders Fluur (LN/EAB)) Date: Fri, 17 Oct 2003 12:07:13 +0200 Subject: Syntax of .inetrc? Message-ID: <9505F6390AA7D311A2D500508B951BEF12136F3B@esealnt427> In a previous posting there was a reference to .inetrc Where is this file documented? I'm developing an application, which is to be run on a machine where we do not have root access. Is it possible to configure .inetrc so that host lookup uses an arbitrary file like /home/nils/hosts ? Best Regards, Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo@REDACTED Fri Oct 17 15:27:28 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Fri, 17 Oct 2003 15:27:28 +0200 Subject: Syntax of .inetrc? References: <9505F6390AA7D311A2D500508B951BEF12136F3B@esealnt427> Message-ID: It is NOT documented, but frequently used. It is designed exactly for your purpose - not having root access but reluctant sysadmins. For your problem there are two tricks: 1) Set an environmet variable ERL_INET_ETC_DIR to an alternate /etc directory e.g /home/nils. Then Erlang will read /etc/hosts, /etc/resolv.conf, and (/etc/host.conf or /etc/nsswitc.conf) from that directory. 3) Use an .inetrc like: {lookup,["file","native"]}. {host,{127,0,0,1}, ["localhost","hostalias"]}. That's right. You can specify hosts in the .inetrc file. It is however only read at startup of the node. Or use a combination. Write the /home/nils/hosts file and set {lookup,["file","native"]} in .inetrc and that hosts file will also be read once at startup and preceed the native lookup. The .inetrc syntax is normal Erlang term syntax. Note the dot at the end of every line. Example lines are, besides the above: {domain,"Domainname"}. {nameserver,{127,0,0,1}}. {nameserver,{127,0,0,1},Port}. {alt_nameserver,{127,0,0,1}}. {alt_nameserver,{127,0,0,1},Port}. {search,["Domain1","Domain2",...]}. There are more. Read the source starting at $ERL_TOP/lib/kernel/src/inet_db.erl:add_rc_list_int/1 Inspect the result of your experiments with inet_db:get_rc/0, or ets:i(inet_db) and ets:i(inet_hosts) if that does not give enough. Oh, and the .inetrc file can be put in several locations: 1) the user's home directory. 2) the erlang installation root (with the {erts-VSN lib man ...} dirs) 3) in a directory specified by the Erlang kernel configuration variable inetrc_dir. And that can be specified when you build your own boot script or on the command line with "-kernel inetrc_dir /path/to/dir". Have fun. WARNING. This is a mess and we would really like to straighten it up some day, so details may change. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB Anders Fluur LN/EAB wrote: > In a previous posting there was a reference to .inetrc > Where is this file documented? > > I'm developing an application, which is to be run on a machine where we > do not have root access. > Is it possible to configure .inetrc so that host lookup uses > an arbitrary file like /home/nils/hosts ? > > Best Regards, > Anders > From chris.danx@REDACTED Fri Oct 17 21:10:59 2003 From: chris.danx@REDACTED (chris.danx) Date: Fri, 17 Oct 2003 20:10:59 +0100 Subject: Databases? Message-ID: <3F903EC3.30101@ntlworld.com> Hi, I've been thinking about writing a server to deliver multimedia content to clients and am looking for a language to program the server in. I figure since I know a little bit of erlang, I'd give a more complex problem (like this) a go. I need to connect to a db, pull out the results of some query and throw it out to the client in XML (preferably in a UTF-8 encoding). The client may select one of the items, or search again. If they select an item, the server sends the client the file. Can anyone provide any links for working with XML and Databases in Erlang? Admittedly, I haven't looked very much but am going to search thoroughly when time permits. Also are there any good examples of servers written in Erlang? I was going to have a look at Yaws later, is that a good example of something substantial? Cheers, Chris From hal@REDACTED Fri Oct 17 22:11:22 2003 From: hal@REDACTED (Hal Snyder) Date: Fri, 17 Oct 2003 15:11:22 -0500 Subject: Spatial Indexes in mnesia In-Reply-To: <3F8FC042.5090600@web.de> (Joachim Durchholz's message of "Fri, 17 Oct 2003 12:11:14 +0200") References: <20031013175301.19296.qmail@web40809.mail.yahoo.com> <3F8FC042.5090600@web.de> Message-ID: <87r81bzkt1.fsf@ghidra.vail> Joachim Durchholz writes: > You can fake spatial indexes via "bit interleaving". Assuming > four-bit X, Y, and Z coordinates XXXX, YYYY, and ZZZZ, construct a > bit vector XYZXYZXYZXYZ. When traversing the records in the order > imposed by that index, you'll retrieve them in the order that you'd > visit them if they were stored in an octree. For example, if you > have the interleaved coordinates 00101xxxxxxx (where the "x" > indicate don't-care bits), this will give the XYZ coordinates > (00xx,01xx,1xxx), which is exactly the area that a specific octree > node covers. ... > Hope this all is useful to somebody. FYI - We have used the above approach in two dimensions for sorting inputs prior to batch-loading of an rtree-indexed table (PostgreSQL). It was for a telephony app in which a person calls in, platform gets long/lat based on ANI, then it looks in 2-d indexed database to find nearest service provider. IIRC the ordering is what you would get doing a traversal of the space with a Hilbert curve of sufficiently high order. This was all before we saw the (Erlang) light. From jesperw@REDACTED Fri Oct 17 16:53:23 2003 From: jesperw@REDACTED (Jesper Wilhelmsson) Date: Fri, 17 Oct 2003 16:53:23 +0200 (MEST) Subject: Garbage collection of binaries In-Reply-To: <3F8FB3BD.1080107@web.de> References: <3F8FB3BD.1080107@web.de> Message-ID: On Fri, 17 Oct 2003, Joachim Durchholz wrote: > Jesper Wilhelmsson wrote: > > Binaries are referenced counted and are removed when their conter reach > > zero. > > This gives me another approach: when you're done with a binary, zero out > all references to it. The binary will go away immediately. Well.. The only place where the reference count is decremented is in the GC and when a process dies. To manually decrement the reference count and promise the system to never use the address again is not a verry functional way of doing things. .joppe > > (This might be impossible if the reference is created as an intermediate > result. It might also interfere with tail recursion. Using reference > counts in a functional language doesn't strike me as a particularly good > solution in this light...) > > Regards, > Jo > __ ___( |_______________________ _______________________________________________ | | ,---. ,--.,--.,--. ( ( | || _ || o ) o ) p ) ) ) "Beware of bugs in the above code; | || (_) || r'| r'| -?--.( ( I have only proved it correct, not tried it." o,--' | `---' |_| |_| `-----' ) ) -- Donald Knuth _`----'______________________( (_______________________________________________ Jesper Wilhelmsson, jesperw@REDACTED +46 (0)18 471 1046 Computing Science Department, Uppsala University, Sweden +46 (0)733 207 207 ------------------------------------------------------------------------------- From spearce@REDACTED Sat Oct 18 03:14:09 2003 From: spearce@REDACTED (Shawn Pearce) Date: Fri, 17 Oct 2003 21:14:09 -0400 Subject: Garbage collection of binaries In-Reply-To: References: <3F8FB3BD.1080107@web.de> Message-ID: <20031018011409.GA16171@spearce.org> Perhaps add a total 'large binary' size to the process structure. This large_bin_siz field would store the total size of all referenced binaries (where total is the total memory footprint, not just the subsection referenced). During each GC the large_bin_siz field would be zeroed and resummed while all references are being copied. References which are not copied would have the binary's refcnt decremented as occurs today. Creating a new binary reference would automatically increment large_bin_siz within the process structure, unless the new binary reference is being formed from subsection of an existing binary reference. When allocating a new large binary in the global heap, the large binary allocator examines current free memory and determines if binary collection might need to occur to prevent heap expansion. If so, it scans the active process list and examines the large_bin_siz fields, requesting GC from each process which has a sufficiently large value. After GC'ing all of those processes, enough large binary memory should have been free'd. If not, the heap expands or a global GC occurs. Which gets selected might be based on how successful a global GC has been in the past few allocations to get the necessary memory. Some apps will need a heavy period of heap expansion, then just local GCs, while some may need just global GCs, etc. I'm not up on the internals of beam lately, so I don't know what effect this might have on forcing a process to wait for others to GC, or if the process trying to allocate the large binary is also itself requested to GC. Just a thought. IMHO, this is one of Erlang's larger warts. Its soooo easy to run a node out of memory with binaries. Almost to the point that it removes much of the reason to use Erlang. :-) Jesper Wilhelmsson wrote: > On Fri, 17 Oct 2003, Joachim Durchholz wrote: > > > Jesper Wilhelmsson wrote: > > > Binaries are referenced counted and are removed when their conter reach > > > zero. > > > > This gives me another approach: when you're done with a binary, zero out > > all references to it. The binary will go away immediately. > > Well.. The only place where the reference count is decremented is in the > GC and when a process dies. > To manually decrement the reference count and promise the system to never > use the address again is not a verry functional way of doing things. > .joppe > > > > > (This might be impossible if the reference is created as an intermediate > > result. It might also interfere with tail recursion. Using reference > > counts in a functional language doesn't strike me as a particularly good > > solution in this light...) > > > > Regards, > > Jo -- Shawn. There are no data that cannot be plotted on a straight line if the axis are chosen correctly. From olgeni@REDACTED Sat Oct 18 13:43:30 2003 From: olgeni@REDACTED (Jimmy Olgeni) Date: Sat, 18 Oct 2003 13:43:30 +0200 (CEST) Subject: gethostbyname/1 on Freebsd In-Reply-To: <3F8E8B7B.2000207@dolphian.com> References: <3F8E8B7B.2000207@dolphian.com> Message-ID: <20031018134235.C87577@olgeni.olgeni> On Thu, 16 Oct 2003, Olivier wrote: > i'm having problems with gethostbyname/1 on FreeBSD: I noticed that it may happen in -CURRENT if you have no nsswitch.conf file in /etc/ - is that so? -- jimmy From robert.virding@REDACTED Sat Oct 18 23:10:28 2003 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 18 Oct 2003 23:10:28 +0200 Subject: soure->source Xformer References: Message-ID: <000d01c395bc$41b3d280$2100a8c0@virding.org> ----- Original Message ----- From: "Richard Carlsson" To: "Joe Armstrong" Cc: Sent: Tuesday, September 23, 2003 3:16 PM Subject: Re: soure->source Xformer > > On Tue, 23 Sep 2003, Joe Armstrong wrote: > > > > sys_pre_expand already *does* expand away records and list > > > comprehensions (do "c(foo, ['E'])." and look at the "foo.E" file). > > > > Sorry - I'd forgotten aabout the records - but the expansion of list > > comprehensions is missing ... > > You're right; sorry - list comprehensions are dealt with in the > 'v3_core' module. (And it is messy because it is expanding and > translating at the same time. It is a much nicer approach to put every > nontrivial transformation in a separate pass, even if it means that you > traverse stuff more than once.) Sorry for being very late in commenting again. :-) There are two reasons that list comprehensions are dealt with in this pass: 1. The syntactic construct exists in erlang but not in Core and I don't really want to add it to core as it is not needed there. 2. Core contains local functions but not Erlang. These make it easy to expand lc:s as most of the real work is is handling the funs. Robert From robert.virding@REDACTED Sat Oct 18 23:40:52 2003 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 18 Oct 2003 23:40:52 +0200 Subject: new syntax - a provocation References: <200309250638.h8P6chgT046325@atlas.otago.ac.nz> Message-ID: <009001c395c0$81d22c00$2100a8c0@virding.org> ----- Original Message ----- From: "Richard A. O'Keefe" To: Sent: Thursday, September 25, 2003 8:38 AM Subject: Re: new syntax - a provocation > Joe Armstrong discussed two ways of implementing > atoms without a (permanent) atom table. > > I don't understand what Mod and Index are. > > The question is "what do we want a global atom table _for_?" > > Mainly, so that atom equal/not-equal testing can be O(1). > Now, suppose an atom is a tagged pointer to a > [hash,size,data] > block. You only compare the data if the hash and size are the same. > Most Erlang atoms are fairly short, so while this would be slower than > whatever it is now, it wouldn't get _that_ much slower. > The hash value would be used for indexing in clause/case selection. This probably the best solution if you don't want an atom table. It is simple and it works. Joes other suggestions are much more complex and difficult to get right. Robert From robert.virding@REDACTED Sat Oct 18 23:53:28 2003 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 18 Oct 2003 23:53:28 +0200 Subject: new syntax - a provocation References: Message-ID: <009401c395c2$437a7a00$2100a8c0@virding.org> ----- Original Message ----- From: "Joe Armstrong" To: "Richard A. O'Keefe" Cc: Sent: Thursday, September 25, 2003 11:12 AM Subject: Re: new syntax - a provocation > Yes - I spent about 10 years thinking about "how to garb the atom > table" just to realise that I'd been thinking about the wrong problem. > > The problem statement should have been "How to design a system that > does not need an atom table". > > Garbing atom tables is *difficult* - a redesign that does not need an > atom table is much easier - I came up with two or three schemes for this > after a couple of days thought. No, garbing atom tables is *easy*. I mean it. Sorry you have the wrong problem statement. It should be "How do I design a system that has a simple but efficient implementation of atoms?". It is not inherently difficult to garbage atom tables! The reason that it is difficult to collect atoms in the BEAM/JAM is because of the per process heaps. If you use a single heap implementation (with an truly incremental collector) then collecting the atom table is trivial. I KNOW because I have done it. What this means is that designing the heap structure, object formats within the heap and the gc algorithm are intertwined and you cannot separate them. So choosing easier per process heaps makes gc atoms more difficult or slower while a more complex single heap makes it easy. This also means that some objects will be implemented completely differently, or at least should be. Robert P.S. Sorry for answering so long after but I haven't had much time lately to follow the list and this issue interests me. P.P.S. Do all of you realise what a truly crappy system Windows is? I have to work in it. :-) From robert.virding@REDACTED Sat Oct 18 23:55:05 2003 From: robert.virding@REDACTED (Robert Virding) Date: Sat, 18 Oct 2003 23:55:05 +0200 Subject: new syntax - a provocation References: <200309252351.h8PNpaP5407732@atlas.otago.ac.nz> Message-ID: <00a401c395c2$7d331680$2100a8c0@virding.org> ---- Original Message ----- From: "Richard A. O'Keefe" To: Sent: Friday, September 26, 2003 1:51 AM Subject: Re: new syntax - a provocation > Perhaps I should also point to the "logix" implementation > of Flat Concurrent Prolog. I never actually looked inside, but > my understanding was that atoms were implemented basically as free- > floating strings, with the added wrinkle that if two atoms were > compared and found to be equal, references to one were changed to > be references to the other. (Just _which_ references and just _how_ > they were found escape my memory. I thought I had a copy of logix > on an old file system, but it was a shell script pointing to an > installation in Melbourne.) The implementation of Strand (another flat concurrent logic language) did the same. Robert From joachim.durchholz@REDACTED Sun Oct 19 01:33:44 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Sun, 19 Oct 2003 01:33:44 +0200 Subject: Garbage collection of binaries In-Reply-To: References: <3F8FB3BD.1080107@web.de> Message-ID: <3F91CDD8.2090507@web.de> Jesper Wilhelmsson wrote: > Joachim Durchholz wrote: >> Jesper Wilhelmsson wrote: >> >>> Binaries are referenced counted and are removed when their conter >>> reach zero. >> >> This gives me another approach: when you're done with a binary, >> zero out all references to it. The binary will go away immediately. > > Well.. The only place where the reference count is decremented is in > the GC and when a process dies. Hmm... If binaries are reference counted, this sounds as if the following scheme is in effect: +----------+ +----------------+ +--------+ | Erlang | --> | administrative | --> | binary | | variable | | data | | data | +----------+ +----------------+ +--------+ where "administrative data" contains the reference count, and maybe additional internal data ("administrative data" and "binary data" might actually be a single block of data). I see two ways of getting rid of the leftmost reference: 1. If the variable is mutable, assign something else to it. 2. If it is immutable, make sure it's a local variable so that it will die as soon as it goes out of scope. None of these solutions is very satisfactory, but I don't see any other ways of solving the problem from within the application. Solving it in the GC would be better, of course, but not everybody can easily do that :-) > To manually decrement the reference count and promise the system to > never use the address again is not a verry functional way of doing > things. Such an approach would not work well with any garbage-collected system, functional or not. Of course, it's not what I suggest. Regards, Jo From joachim.durchholz@REDACTED Sun Oct 19 01:45:20 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Sun, 19 Oct 2003 01:45:20 +0200 Subject: Garbage collection of binaries In-Reply-To: <20031018011409.GA16171@spearce.org> References: <3F8FB3BD.1080107@web.de> <20031018011409.GA16171@spearce.org> Message-ID: <3F91D090.7090700@web.de> Shawn Pearce wrote: > Perhaps add a total 'large binary' size to the process structure. > > [...] Keeping the total size of all binaries up-to-date should be easier if the total is updated when the binary is allocated or deallocated. This also keeps the complications of detecting block types etc. out of the GC loop and moves them to the code that creates and destroys blocks - which is much better modularity. An even more modular approach would be to make the binaries normal citizens of garbage collected memory. This would also simplify the emulator code, I'd think :-) Regards, Jo From joachim.durchholz@REDACTED Sun Oct 19 01:59:23 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Sun, 19 Oct 2003 01:59:23 +0200 Subject: new syntax - a provocation In-Reply-To: <009401c395c2$437a7a00$2100a8c0@virding.org> References: <009401c395c2$437a7a00$2100a8c0@virding.org> Message-ID: <3F91D3DB.2060908@web.de> Robert Virding wrote: > It is not inherently difficult to garbage atom tables! The reason that it is > difficult to collect atoms in the BEAM/JAM is because of the per process > heaps. If you use a single heap implementation (with an truly incremental > collector) then collecting the atom table is trivial. I KNOW because I > have done it. Making an incremental collector right isn't a trivial task: 1. Write it. There's quite some code involved. 2. Make it right. Not too easy either. 3. Make it fast. This can take up an arbitrary amount of time (the Boehm collector took several years to get to its current-day speed). 4. Find all the pathological allocation patterns that cause it to degenerate into polynomial or exponential behaviour. (This happened to the ISE Eiffel run-time - near-verbatim quote from the technical lead: "it's galling to do one's very best to make the best ever garbage collector conceivable, just to be proven wrong by a pathological case.") Erlang uses a stop-the-world collector, and it can get away with that because it uses that collector on a per-process basis. (I'm wondering when a process GC is triggered though... if GC is triggered by out-of-memory, this would trigger GC in all processes... so how does Erlang avoid this? Regards, Jo From david.wallin@REDACTED Sun Oct 19 19:36:49 2003 From: david.wallin@REDACTED (david wallin) Date: Sun, 19 Oct 2003 18:36:49 +0100 Subject: file:read_file/1 - bug or feature? Message-ID: On a Linux system , I tried the following: file:read_file("/proc//loadavg"). and got '{ok, <<>>}' as a reply. Is this a bug or a feature? cheers, --david. From olgeni@REDACTED Sun Oct 19 22:55:15 2003 From: olgeni@REDACTED (Jimmy Olgeni) Date: Sun, 19 Oct 2003 22:55:15 +0200 (CEST) Subject: file:read_file/1 - bug or feature? In-Reply-To: References: Message-ID: <20031019224703.B99677@olgeni.olgeni> On Sun, 19 Oct 2003, david wallin wrote: > file:read_file("/proc//loadavg"). > and got '{ok, <<>>}' as a reply. Is the file length equal to 0? Maybe that's confusing the file library. I get the same on FreeBSD: 3> file:read_file ("/proc/0/cmdline"). {ok,<<>>} But it should be "swapper". Does "invoke_read_file" in "efile_drv.c" do things with the file size? :) -- jimmy From ok@REDACTED Mon Oct 20 01:13:03 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 20 Oct 2003 12:13:03 +1300 (NZDT) Subject: =?iso-8859-1?Q?Re:_Re:_Varf=F6r_kan_jag_inte_inte_anropa_A_--_B_--_C_=3F?= Message-ID: <200310192313.h9JND3W5344102@atlas.otago.ac.nz> The question has been asked, "why is X++Y++Z read as X++(Y++Z)?" >From the Haskell standard Prelude: infixr 5 ++ >From SML: infix5 :: @ (* :: is infix cons, @ is the same as Erlang ++ *) While "append" is associative, "cons" is not; the only fixity for infix cons which makes any sense at all is 'infixr'; the semantics of append being so intimately related to the semantics of cons, and the 'infixr' fixity for append naturally leading to the efficient evaluation order without any subterfuge, it makes sense for "append" to be infixr as well. Indeed, it would be quite perverse for a functional programming language with Lisp-style lists to make infix append left associative. Simplicity is all very well, but sanity must take first place. From matthias@REDACTED Mon Oct 20 08:20:55 2003 From: matthias@REDACTED (Matthias Lang) Date: Mon, 20 Oct 2003 08:20:55 +0200 Subject: file:read_file/1 - bug or feature? In-Reply-To: <20031019224703.B99677@olgeni.olgeni> References: <20031019224703.B99677@olgeni.olgeni> Message-ID: <16275.32455.613249.453687@antilipe.corelatus.se> > On Sun, 19 Oct 2003, david wallin wrote: > > > file:read_file("/proc//loadavg"). > > and got '{ok, <<>>}' as a reply. Try os:cmd("cat /proc/loadavg"). Jimmy's earlier mail was right on the money about the size. Given that the length of that file (according to fstat) is zero, the null result isn't altogether unreasonable. If you trace the emulator (e.g. with strace or strut): open("loadavg", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 read(3, "", 0) = 0 close(3) = 0 you see what's happening. Here's what it looks like for a real file: open("books", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0664, st_size=114, ...}) = 0 read(3, "The Anatomy of a High-Performanc"..., 114) = 114 close(3) = 0 write(0, "{ok,<<84,104,101,32,65,110,97,11"..., 111) = 111 People run into trouble every so often by assuming more unix-isms in the 'file' module/ERTS than they actually have. E.g. you can't open devices such as serial ports. It'd might help if the 'file' module documentation had a warning about 'no funny file-like things' and I should probably add a question to the FAQ about it too. Matthias From raimo@REDACTED Mon Oct 20 09:13:26 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Mon, 20 Oct 2003 09:13:26 +0200 Subject: gethostbyname/1 on Freebsd References: <3F8E8B7B.2000207@dolphian.com>, <20031018134235.C87577@olgeni.olgeni> Message-ID: Sorry if I am slow, but it is monday morning: what is -CURRENT? Anyway. It is a bad design now that Erlang (inet_config) assumes which files should be present based only on os:type(). I you do not have the files "normal" (how it looked some years ago) to your OS, Erlang's own name resolver may miss the mark by miles in any OTP release. This is the main reason we want to rewrite the lot (of the resolving stuff). Jimmy Olgeni wrote: > On Thu, 16 Oct 2003, Olivier wrote: > > >> i'm having problems with gethostbyname/1 on FreeBSD: > > > I noticed that it may happen in -CURRENT if you have no nsswitch.conf > file in /etc/ - is that so? > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From raimo@REDACTED Mon Oct 20 09:16:57 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Mon, 20 Oct 2003 09:16:57 +0200 Subject: file:read_file/1 - bug or feature? References: <20031019224703.B99677@olgeni.olgeni>, <20031019224703.B99677@olgeni.olgeni>, <16275.32455.613249.453687@antilipe.corelatus.se> Message-ID: The reason the file driver does this is that it is about to return a binary, and want to know how large binary to allocate to read the file straight into. It is an optimization. It is correct that the file driver (and therefore the file module) is only intended for regular files. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB Matthias Lang wrote: > > On Sun, 19 Oct 2003, david wallin wrote: > > > > > file:read_file("/proc//loadavg"). > > > and got '{ok, <<>>}' as a reply. > > Try > > os:cmd("cat /proc/loadavg"). > > Jimmy's earlier mail was right on the money about the size. > > Given that the length of that file (according to fstat) is zero, the > null result isn't altogether unreasonable. If you trace the emulator > (e.g. with strace or strut): > > open("loadavg", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 > read(3, "", 0) = 0 > close(3) = 0 > > you see what's happening. Here's what it looks like for a real file: > > open("books", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0664, st_size=114, ...}) = 0 > read(3, "The Anatomy of a High-Performanc"..., 114) = 114 > close(3) = 0 > write(0, "{ok,<<84,104,101,32,65,110,97,11"..., 111) = 111 > > People run into trouble every so often by assuming more unix-isms in > the 'file' module/ERTS than they actually have. E.g. you can't open > devices such as serial ports. It'd might help if the 'file' module > documentation had a warning about 'no funny file-like things' and I > should probably add a question to the FAQ about it too. > > Matthias From steve@REDACTED Sat Oct 18 03:53:48 2003 From: steve@REDACTED (Steven H. Rogers) Date: Fri, 17 Oct 2003 19:53:48 -0600 Subject: R9C-0 Toolbar Menus and Red Hat 9 In-Reply-To: <20031018011409.GA16171@spearce.org> References: <3F8FB3BD.1080107@web.de> <20031018011409.GA16171@spearce.org> Message-ID: <3F909D2C.7030007@shrogers.com> Toolbar Menu items don't work on my RH9 system (TK 9.3.5-88). Is there a simple solution? Steve -- Steven H. Rogers, Ph.D., steve@REDACTED Weblog: http://shrogers.com/zope/portal/Members/steve/blog "That language is an instrument of human reason, and not merely a medium for the expression of thought, is a truth generally admitted."- George Boole From thomasl_erlang@REDACTED Mon Oct 20 11:47:18 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 20 Oct 2003 02:47:18 -0700 (PDT) Subject: Garbage collection of binaries In-Reply-To: <3F91D090.7090700@web.de> Message-ID: <20031020094718.87588.qmail@web41903.mail.yahoo.com> --- Joachim Durchholz wrote: > An even more modular approach would be to make the > binaries normal > citizens of garbage collected memory. This would > also simplify the > emulator code, I'd think :-) Storing binaries globally means message passing needs not copy binaries. That was the reason I heard, at least. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From Erik.Stenman@REDACTED Mon Oct 20 12:12:03 2003 From: Erik.Stenman@REDACTED (Erik Stenman) Date: Mon, 20 Oct 2003 12:12:03 +0200 Subject: Garbage collection of binaries In-Reply-To: <20031020094718.87588.qmail@web41903.mail.yahoo.com> Message-ID: <004201c396f2$9be2a600$7d1efea9@lamppc36> > Thomas Lindgren Wrote > --- Joachim Durchholz wrote: > > An even more modular approach would be to make the > > binaries normal > > citizens of garbage collected memory. This would > > also simplify the > > emulator code, I'd think :-) > > Storing binaries globally means message passing needs > not copy binaries. That was the reason I heard, at > least. Binaries would be copyied not onlyby message passing, but by the garbage collector itself. ERTS currently uses a generational *copying* GC, hence storing the binaries directly on the heap without rewriting the GC would mean that the binary would be copied at each major GC. /Erik From joachim.durchholz@REDACTED Mon Oct 20 13:46:25 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Mon, 20 Oct 2003 13:46:25 +0200 Subject: Garbage collection of binaries In-Reply-To: <004201c396f2$9be2a600$7d1efea9@lamppc36> References: <004201c396f2$9be2a600$7d1efea9@lamppc36> Message-ID: <3F93CB11.1070309@web.de> Erik Stenman wrote: > ERTS currently uses a generational *copying* GC, Ah, I overlooked that. > hence storing the binaries directly on the heap without rewriting the > GC would mean that the binary would be copied at each major GC. Hmm... good reasons, but that's the wrong place to address the problem, I think. Copying collectors are designed for minimizing fragmentation. In other words, the memory area that stores binaries will be fragmented. Particularly if the binaries come and go quite often, and have slightly different sizes (which I'd expect for large data like binaries). In other words: the distinction whether to copy some data or not should be based on the size of that data, not on its status as a binary. And if copying indeed is a problem (it shouldn't be, but theory and practice differ more in practice than theory would admit *g*), the solution should be in the GC mechanism. Not in a tacked-on reference counting mechanism that doesn't even interoperate well, and that might expand the footprint beyond reasons. Actually, this is the kind of behaviour that can break systems, and from the reports on this list, I conclude that this has already happened. Not the kind of behaviour that I would have expected from a safety-minded language like Erlang :-(( I'm frustrated. From the outside, you always get promises. From the inside, things are not so rosy. *sigh* still questing for a rock-solid, really reliable language... ... and all of this is a "wonderful" example that getting garbage collection right is *hard*. Don't try this at home and all. Regards, Jo From sean.hinde@REDACTED Mon Oct 20 13:54:41 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 20 Oct 2003 12:54:41 +0100 Subject: Garbage collection of binaries In-Reply-To: <004201c396f2$9be2a600$7d1efea9@lamppc36> Message-ID: <30889A4C-02F4-11D8-97E9-000A95927CCE@mac.com> On Monday, October 20, 2003, at 11:12 am, Erik Stenman wrote: > >> Thomas Lindgren Wrote >> --- Joachim Durchholz wrote: >>> An even more modular approach would be to make the >>> binaries normal >>> citizens of garbage collected memory. This would >>> also simplify the >>> emulator code, I'd think :-) >> >> Storing binaries globally means message passing needs >> not copy binaries. That was the reason I heard, at >> least. > > Binaries would be copyied not onlyby message passing, > but by the garbage collector itself. > ERTS currently uses a generational *copying* GC, hence > storing the binaries directly on the heap without > rewriting the GC would mean that the binary would be > copied at each major GC. > > /Erik > > This is great, and non copying of binaries is a fantastic feature which moves Erlang into the realms of carrying traffic as well as control, but we still need a solution to the problem that a process will merrily use up all 4G of beam memory space without doing a garbage collection.. I think that a solution in which a process keeps track of its own large binary allocations and kicks of a GC if this gets too big will be a good step. It will not cover all cases where tracking reference counts across all processes might lead to a different answer, but it would cover the common case of a single process processing a large amount of binary data and would provide good protection in the other cases. Sean From bjorn@REDACTED Mon Oct 20 14:02:08 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 20 Oct 2003 14:02:08 +0200 Subject: Garbage collection of binaries In-Reply-To: References: <3F8FB3BD.1080107@web.de> Message-ID: Garbage collections of binaries is a tricky issue. To clarify how binaries are removed: It is done by a combination of garbage collection and reference counters. Binaries are represented in each process as small objects on the heap. Those objects are also part of a linked list (one list per process). After each garbage collection, the linked list is scanned to which objects were not moved (thus, no longer referenced). For each unreferenced object, the reference count in the binary itself is decreased. As a consequence of the above, if a binary is referenced from the old generation heap, it cannot be removed until a new major collection (a.k.a. fullsweep collection) is done. How often a major collection occurs depends on the application. If a process is known to have large binaries but small amounts of live heap data, the process can be started using the spawn_opt/4, passing in the '{fullsweep_after,0}' option. (See the documentation for spawn_opt/4 for further details.) That will make every GC a major collection (fullsweep), cleaning away any binaries that are no longer referenced. Note that a major collection copies all data that is is still alive; if you have large amounts of live data on the heap doing a major collection every time will typically be slower than the default generational GC (which only does a major collection when there is no more place on the old generation heap). BTW, when a process aquires a new binary, it gets "penalty points" so that it will be garbage collected sooner. But a binary that has survived one GC will not generate further "penalty points". /Bjorn Jesper Wilhelmsson writes: > On Fri, 17 Oct 2003, Joachim Durchholz wrote: > > > Jesper Wilhelmsson wrote: > > > Binaries are referenced counted and are removed when their conter reach > > > zero. > > > > This gives me another approach: when you're done with a binary, zero out > > all references to it. The binary will go away immediately. > > Well.. The only place where the reference count is decremented is in the > GC and when a process dies. > To manually decrement the reference count and promise the system to never > use the address again is not a verry functional way of doing things. > .joppe > > > > > (This might be impossible if the reference is created as an intermediate > > result. It might also interfere with tail recursion. Using reference > > counts in a functional language doesn't strike me as a particularly good > > solution in this light...) > > > > Regards, > > Jo > > > > __ > ___( |_______________________ _______________________________________________ > | | ,---. ,--.,--.,--. ( ( > | || _ || o ) o ) p ) ) ) "Beware of bugs in the above code; > | || (_) || r'| r'| -?--.( ( I have only proved it correct, not tried it." > o,--' | `---' |_| |_| `-----' ) ) -- Donald Knuth > _`----'______________________( (_______________________________________________ > Jesper Wilhelmsson, jesperw@REDACTED +46 (0)18 471 1046 > Computing Science Department, Uppsala University, Sweden +46 (0)733 207 207 > ------------------------------------------------------------------------------- > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From alexey@REDACTED Mon Oct 20 15:07:37 2003 From: alexey@REDACTED (Alexey Shchepin) Date: Mon, 20 Oct 2003 16:07:37 +0300 Subject: Bug in ei_encode_string_len Message-ID: <87ekx86orq.fsf@office.sevcom.net> Hi! It seems ei_encode_string_len incorrectly encode string with length greater than 0xffff. It not append ERL_NIL_EXT in the end of list. This results in badarg error when this binary processed with binary_to_term. Below is a patch that should fix this (not tested). --- encode_string.c.orig Mon Oct 20 13:20:45 2003 +++ encode_string.c Mon Oct 20 13:23:52 2003 @@ -42,7 +42,7 @@ s += len; } else { - if (!buf) s += 5 + (2*len); + if (!buf) s += 6 + (2*len); else { /* strings longer than 65535 are encoded as lists */ put8(s,ERL_LIST_EXT); @@ -52,6 +52,8 @@ put8(s,ERL_SMALL_INTEGER_EXT); put8(s,p[i]); } + + put8(s,ERL_NIL_EXT); } } From michael@REDACTED Mon Oct 20 19:30:14 2003 From: michael@REDACTED (Michael Hobbs) Date: Mon, 20 Oct 2003 12:30:14 -0500 (CDT) Subject: Slightly OT: static typing In-Reply-To: <20031020094718.87588.qmail@web41903.mail.yahoo.com> References: <3F91D090.7090700@web.de> <20031020094718.87588.qmail@web41903.mail.yahoo.com> Message-ID: <2405.66.41.245.83.1066671014.squirrel@mail.hobbshouse.org> Has anyone else read "Objects Have Failed" by Richard P. Gabriel? http://www.dreamsongs.com/NewFiles/ObjectsHaveFailed.pdf Regardless of your bias toward or against OOP[1], I found the sections on static typing to be somewhat relevant to the current design of Erlang and its possible future directions. One choice quote: What the static types are trying to do is to make sure that a program cannot fail at runtime. Yet, for living systems to be created, they must be able to sustain a failure and repair itself. This is part of a doomed attempt to eliminate errors and write perfect systems. Opinions? - Michael Hobbs [1] My own personal bias toward OOP is that it is a fine paradigm, but is significantly overused, especially inheritance. I prefer spatial locality of code and tend to shy away from systems that allow too much action-at-a-distance. From vlad_dumitrescu@REDACTED Tue Oct 21 08:20:58 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 21 Oct 2003 08:20:58 +0200 Subject: Slightly OT: static typing References: <3F91D090.7090700@web.de> <20031020094718.87588.qmail@web41903.mail.yahoo.com> <2405.66.41.245.83.1066671014.squirrel@mail.hobbshouse.org> Message-ID: From: "Michael Hobbs" > Has anyone else read "Objects Have Failed" by Richard P. Gabriel? Hi, I read it, and loved it. My interpretation of the part about static typing is that it condemns any practice that relies on static typing alone. For a language like Erlang, there is already a lot being done to ensure runtime safety - adding static typing would only be a bonus. We can do without, and Erlang won't become C or Pascal just by adding typing. But that's only my opinion. Regards, Vlad From fredrik.linder@REDACTED Tue Oct 21 08:48:51 2003 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Tue, 21 Oct 2003 08:48:51 +0200 Subject: One Million Processes In-Reply-To: Message-ID: > > This is the sort of thing I've been thinking about, it's the > > game of life however the children grow, go to school, get jobs > > and support they're parents. > > > > Unlike the basic game of life there is no grid so the concept > > of how these processes discover each other to interact is what > > I haven't thought through. > > > > It does lend itself well to infinite uptime. > > As you spawn these processes, you could make them aware of their > "neighbours" - a few processes spawned before and after. Each process can > have a "socialising" algorithm to introduce it's "neighbours" to other > processes. They can randomly decide whether they "like" the new process or > not. You can do all sorts of stuff with this - only limited by your > imagination :-) Another cool app would be to build a 'true' peer-to-peer DC network, where one can easily search for files on ALL connected machines via a neighbours' neighbour search. And one could build groups of users, just like todays icq/msn/aol/... with chatting, file sharing, diraries, events... Cheers /Fredrik From thomasl_erlang@REDACTED Tue Oct 21 09:42:05 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 21 Oct 2003 00:42:05 -0700 (PDT) Subject: peer-to-peerlang (was RE: One Million Processes) In-Reply-To: Message-ID: <20031021074205.97343.qmail@web41906.mail.yahoo.com> --- Fredrik Linder wrote: > Another cool app would be to build a 'true' > peer-to-peer DC network, where > one can easily search for files on ALL connected > machines via a neighbours' > neighbour search. And one could build groups of > users, just like todays > icq/msn/aol/... with chatting, file sharing, > diraries, events... Peer-to-peer would be an interesting new field for Erlang as well, technically speaking. How about a language (-version) with lots of support for, um, whatever the p2p-people need when they write their algorithms? Much of that could likely be written in Erlang. My guess is that Erlang already has a lot of what one wants (e.g., distribution, transparency), but not quite (e.g., some measure of security/untrustedness, millions of nodes in distribution, ...). Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From vlad_dumitrescu@REDACTED Tue Oct 21 10:28:16 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 21 Oct 2003 10:28:16 +0200 Subject: peer-to-peerlang (was RE: One Million Processes) References: <20031021074205.97343.qmail@web41906.mail.yahoo.com> Message-ID: From: "Thomas Lindgren" > Peer-to-peer would be an interesting new field for > Erlang as well, technically speaking. How about a > language (-version) with lots of support for, um, > whatever the p2p-people need when they write their > algorithms? Are language extensions really needed for this? IMHO library support will suffice... > Much of that could likely be written in Erlang. My > guess is that Erlang already has a lot of what one > wants (e.g., distribution, transparency), but not > quite (e.g., some measure of security/untrustedness, > millions of nodes in distribution, ...). The question is whether the standard distribution mechanism *should* be used in such a setting at all. I also think the idea of automagically having the nodes talk to each other is attractive, using normal socket connections resolves a lot of problems. For instance, security can be handled in a library, not by hacking the runtime. regards, Vlad From bjorn@REDACTED Tue Oct 21 11:05:09 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 21 Oct 2003 11:05:09 +0200 Subject: peer-to-peerlang (was RE: One Million Processes) In-Reply-To: References: <20031021074205.97343.qmail@web41906.mail.yahoo.com> Message-ID: "Vlad Dumitrescu" writes: > > The question is whether the standard distribution mechanism *should* be used in > such a setting at all. I also think the idea of automagically having the nodes > talk to each other is attractive, using normal socket connections resolves a lot > of problems. For instance, security can be handled in a library, not by hacking > the runtime. > I think it is clear that the distribution should NOT be used, for several reasons. Security: Anyone that is able to connect (has the cookie) can do any kind of damage to any other connected Erlang node. (Through spawn/4 or one of the rpc:call functions.) Scalability: The distribution was not designed to allow that many nodes connected to each other. Distribution is good for communication between a small number of hosts that that mutually trust each other. Even without distribution, using standard sockets, you still get most of the advantages of Erlang. For instance, you can still send Erlang terms by using the term_to_binary/1 and binary_to_term/1 BIFs. /Bjorn > regards, > Vlad > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From ulf.wiger@REDACTED Tue Oct 21 11:47:17 2003 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Tue, 21 Oct 2003 11:47:17 +0200 Subject: surprising result with hipe compilation Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5402576@ESEALNT442.al.sw.ericsson.se> I experimented a bit with a recursive-descent parser, and thought I'd check whether compiling to native code could speed things up: First, clocking the parse operation without hipe compilation: 41> timer:tc(contract_parser1,read_and_parse,["file_plugin.con"]). {5860, {ok,[{name,"file_server"}, {vsn,"ubf1.0"}, {types,[{info,{constant,info},[]}, {description,{constant,description},[]}, {services,{constant,services},[]}, {contract,{constant,contract},[]}, {file,{prim,string},[]}, {ls,{constant,ls},[]}, {files,{tuple,[{constant,files},{list,{prim,file}}]},[]}, {getFile,{tuple,[{constant,get},{prim,file}]},[]}, {noSuchFile,{constant,noSuchFile},[]}]}, {transition,{start,[{input,{prim,ls},[{output,{prim,files},start}]}, {input,{prim,getFile}, [{output,{prim,binary},start}, {output,{prim,noSuchFile},stop}]}]}}, {anystate,[{{prim,info},{prim,string}}, {{prim,description},{prim,string}}, {{prim,contract},{prim,term}}]}]}} This was ~2ms slower than the yecc-generated parse module. (To be expected. It's supposed to be slower.) Now, compiling the parse module with hipe: 42> c(contract,[native]). {module,contract} ... 45> timer:tc(contract_parser1,read_and_parse,["file_plugin.con"]). {16958, {ok,[{name,"file_server"}, {vsn,"ubf1.0"}, {types,[{info,{constant,info},[]}, {description,{constant,description},[]}, {services,{constant,services},[]}, {contract,{constant,contract},[]}, {file,{prim,string},[]}, {ls,{constant,ls},[]}, {files,{tuple,[{constant,files},{list,{prim,file}}]},[]}, {getFile,{tuple,[{constant,get},{prim,file}]},[]}, {noSuchFile,{constant,noSuchFile},[]}]}, {transition,{start,[{input,{prim,ls},[{output,{prim,files},start}]}, {input,{prim,getFile}, [{output,{prim,binary},start}, {output,{prim,noSuchFile},stop}]}]}}, {anystate,[{{prim,info},{prim,string}}, {{prim,description},{prim,string}}, {{prim,contract},{prim,term}}]}]}} Oops! Slight slow-down. Perhaps all those transitions between threaded and native...? Hipe-compile the module calling the parser: 52> c(contract_parser1,[native]). {ok,contract_parser1} 53> timer:tc(contract_parser1,read_and_parse,["file_plugin.con"]). {75, {'EXIT',{undef,[{contract_parser1,read_and_parse,["file_plugin.con"]}, {timer,tc,3}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]}}} Oops again! This looks like a bug, or am I missing something? The source is available upon request. /Uffe From raimo@REDACTED Tue Oct 21 12:10:13 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Tue, 21 Oct 2003 12:10:13 +0200 Subject: Support glitch Message-ID: Hi, we have had our first glitch in our internal support system. Two support sequences are lost. We may be able to retrieve them from backups, but if the authors of the support mails could repost them, they will get faster respons. Both sequences we think contained only one question - no replies yet. The sequences are: 8236 - We think it was Francesco Cesarini who asked about heart. 8243 - We think it was some Anders ... at Ericsson (ERV) who asked about documentation of .inetrc. Thank you. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From joachim.durchholz@REDACTED Tue Oct 21 14:08:25 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Tue, 21 Oct 2003 14:08:25 +0200 Subject: Slightly OT: static typing In-Reply-To: <2405.66.41.245.83.1066671014.squirrel@mail.hobbshouse.org> References: <3F91D090.7090700@web.de> <20031020094718.87588.qmail@web41903.mail.yahoo.com> <2405.66.41.245.83.1066671014.squirrel@mail.hobbshouse.org> Message-ID: <3F9521B9.7040604@web.de> Michael Hobbs wrote: > Has anyone else read "Objects Have Failed" by Richard P. Gabriel? > http://www.dreamsongs.com/NewFiles/ObjectsHaveFailed.pdf Just did. I was not impressed. A lot of valid observations, and a lot of wrong conclusion. IMNSHO and YMMV :-) Regards, Jo From ulf.wiger@REDACTED Tue Oct 21 17:07:04 2003 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Tue, 21 Oct 2003 17:07:04 +0200 Subject: surprising result with hipe compilation Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5402578@ESEALNT442.al.sw.ericsson.se> Ulf Wiger (AL/EAB) wrote: > 52> c(contract_parser1,[native]). > {ok,contract_parser1} > 53> timer:tc(contract_parser1,read_and_parse,["file_plugin.con"]). > {75, > {'EXIT',{undef,[{contract_parser1,read_and_parse,["file_plugin.con"]}, > {timer,tc,3}, > {erl_eval,expr,3}, > {erl_eval,exprs,4}, > {shell,eval_loop,2}]}}} > > > Oops again! This looks like a bug, or am I missing something? I was missing something: the 'export_all' option. :( It didn't help much, though. If anything, It got even slower with both modules native. Something in this code does not seem to get along with hipe. /Uffe From thomasl_erlang@REDACTED Tue Oct 21 19:54:18 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 21 Oct 2003 10:54:18 -0700 (PDT) Subject: peer-to-peerlang (was RE: One Million Processes) In-Reply-To: Message-ID: <20031021175418.45898.qmail@web41906.mail.yahoo.com> --- Vlad Dumitrescu wrote: > From: "Thomas Lindgren" > > Peer-to-peer would be an interesting new field for > > Erlang as well, technically speaking. How about a > > language (-version) with lots of support for, um, > > whatever the p2p-people need when they write their > > algorithms? > > Are language extensions really needed for this? IMHO > library support will > suffice... > > > Much of that could likely be written in Erlang. My > > guess is that Erlang already has a lot of what one > > wants (e.g., distribution, transparency), but not > > quite (e.g., some measure of > security/untrustedness, > > millions of nodes in distribution, ...). > > The question is whether the standard distribution > mechanism *should* be used in > such a setting at all. I also think the idea of > automagically having the nodes > talk to each other is attractive, using normal > socket connections resolves a lot > of problems. For instance, security can be handled > in a library, not by hacking > the runtime. Yeah, I was thinking mainly of a hacked OTP distribution (or a nearly-separate distribution even), possibly with some security extensions to the runtime to avoid unnecessary exploits. Though it could be interesting to consider more sweeping changes. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From thomasl_erlang@REDACTED Tue Oct 21 20:02:58 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 21 Oct 2003 11:02:58 -0700 (PDT) Subject: peer-to-peerlang (was RE: One Million Processes) In-Reply-To: Message-ID: <20031021180258.9234.qmail@web41904.mail.yahoo.com> --- Bjorn Gustavsson wrote: > "Vlad Dumitrescu" > writes: > I think it is clear that the distribution should NOT > be used, > for several reasons. > > Security: Anyone that is able to connect (has the > cookie) can do > any kind of damage to any other connected Erlang > node. (Through > spawn/4 or one of the rpc:call functions.) > > Scalability: The distribution was not designed to > allow that many > nodes connected to each other. > > Distribution is good for communication between a > small number of > hosts that that mutually trust each other. Indeed. BUT the replacement mechanism (unreliable distribution, if you will) should be about as convenient as today, if not more so. Perhaps something like: - automatic scalable, unreliable distribution handling millions of nodes that may join or leave at any time - transparent message passing among the nodes - some sort of directory (or directories) for the whole thing - some way to manage code - again, security/trust issues and "whatever more is needed". Target audience: p2p developers. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From sean.hinde@REDACTED Tue Oct 21 20:25:02 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Tue, 21 Oct 2003 19:25:02 +0100 Subject: Try/Cond Message-ID: Hi, I have heard and read much about the possible arrival of try/cond to the language. Can anyone shed any light on how it would be intended to work? Thanks, Sean From richardc@REDACTED Tue Oct 21 20:43:50 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 21 Oct 2003 20:43:50 +0200 Subject: Try/Cond References: Message-ID: <006301c39803$454ffe20$bfdcd1d9@gnit> ----- Original Message ----- From: "Sean Hinde" To: "Erlang Questions" Sent: Tuesday, October 21, 2003 8:25 PM Subject: Try/Cond > I have heard and read much about the possible arrival of try/cond to > the language. Can anyone shed any light on how it would be intended to > work? Basically, like "if" but with any boolean expressions instead of just guards. (I once tried to suggest that the if-expression should be generalized, instead of adding a keyword like "cond", but that sort of change scared too many people.) The current status is that it turned out that Erlang's scoping rules made it harder than we had expected to implement "cond" correctly (i.e., it's not just a trivial expansion into a nested case statement), so it was postponed until someone with a lot of spare time could have another look at it. /Richard From richardc@REDACTED Tue Oct 21 20:46:19 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 21 Oct 2003 20:46:19 +0200 Subject: Try/Cond References: Message-ID: <006901c39803$9dfb93e0$bfdcd1d9@gnit> Oh, and you also mentioned "try". We're still discussing the fine points about the semantics and syntax. I seriously hope it will be part of R10 next year. /Richard ----- Original Message ----- From: "Sean Hinde" To: "Erlang Questions" Sent: Tuesday, October 21, 2003 8:25 PM Subject: Try/Cond > Hi, > > I have heard and read much about the possible arrival of try/cond to > the language. Can anyone shed any light on how it would be intended to > work? > > Thanks, > Sean > > > From luke@REDACTED Tue Oct 21 20:49:44 2003 From: luke@REDACTED (Luke Gorrie) Date: 21 Oct 2003 20:49:44 +0200 Subject: Try/Cond In-Reply-To: <006301c39803$454ffe20$bfdcd1d9@gnit> References: <006301c39803$454ffe20$bfdcd1d9@gnit> Message-ID: "Richard Carlsson" writes: > The current status is that it turned out that Erlang's scoping rules > made it harder than we had expected to implement "cond" correctly > (i.e., it's not just a trivial expansion into a nested case > statement), so it was postponed until someone with a lot of spare time > could have another look at it. Just add `let' too. -Luke (ducking) From sean.hinde@REDACTED Tue Oct 21 20:50:37 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Tue, 21 Oct 2003 19:50:37 +0100 Subject: Try/Cond In-Reply-To: <006901c39803$9dfb93e0$bfdcd1d9@gnit> Message-ID: <75A1E4DC-03F7-11D8-97E9-000A95927CCE@mac.com> On Tuesday, October 21, 2003, at 07:46 pm, Richard Carlsson wrote: > > Oh, and you also mentioned "try". We're still discussing the > fine points about the semantics and syntax. I seriously hope > it will be part of R10 next year. > So try is like (guessing): try func1(xx), f2(yy) catch {'EXIT', Reason} -> {error, oops}; ok -> ok end. ? Sean From luke@REDACTED Tue Oct 21 20:56:40 2003 From: luke@REDACTED (Luke Gorrie) Date: 21 Oct 2003 20:56:40 +0200 Subject: Try/Cond In-Reply-To: References: <006301c39803$454ffe20$bfdcd1d9@gnit> Message-ID: Luke Gorrie writes: > "Richard Carlsson" writes: > > > The current status is that it turned out that Erlang's scoping rules > > made it harder than we had expected to implement "cond" correctly > > (i.e., it's not just a trivial expansion into a nested case > > statement), so it was postponed until someone with a lot of spare time > > could have another look at it. > > Just add `let' too. Hmm, but Core Erlang already has `let'. Is the problem that you can't express cond in Core Erlang, or that you have to do something hard with it before it gets to Core? Or something else? -Luke From richardc@REDACTED Tue Oct 21 21:05:07 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 21 Oct 2003 21:05:07 +0200 Subject: Try/Cond References: <75A1E4DC-03F7-11D8-97E9-000A95927CCE@mac.com> Message-ID: <008e01c39806$3e2fc690$bfdcd1d9@gnit> ----- Original Message ----- From: "Sean Hinde" To: "Richard Carlsson" Cc: "Erlang Questions" Sent: Tuesday, October 21, 2003 8:50 PM Subject: Re: Try/Cond > So try is like (guessing): > > try > func1(xx), > f2(yy) > catch > {'EXIT', Reason} -> > {error, oops}; > ok -> > ok > end. > > ? The main points are 1) being able to definitely separate exceptions from return values, and 2) being able to catch only those exceptions one is interested in, letting everything else fall through. Something like: try f(X) catch {throw, file_not_found} -> ... end also, we want to be able to directly switch on the result in the successful case. Something like this: try scan(FD) of foo -> ...; bar -> ... catch {throw, eof} -> ... end /Richard From sean.hinde@REDACTED Tue Oct 21 21:15:38 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Tue, 21 Oct 2003 20:15:38 +0100 Subject: Try/Cond In-Reply-To: <008e01c39806$3e2fc690$bfdcd1d9@gnit> Message-ID: On Tuesday, October 21, 2003, at 08:05 pm, Richard Carlsson wrote: > > ----- Original Message ----- > From: "Sean Hinde" > To: "Richard Carlsson" > Cc: "Erlang Questions" > Sent: Tuesday, October 21, 2003 8:50 PM > Subject: Re: Try/Cond > > >> So try is like (guessing): >> >> try >> func1(xx), >> f2(yy) >> catch >> {'EXIT', Reason} -> >> {error, oops}; >> ok -> >> ok >> end. >> >> ? > > The main points are 1) being able to definitely separate exceptions > from return values, and 2) being able to catch only those exceptions > one is interested in, letting everything else fall through. Something > like: > > try > f(X) > catch > {throw, file_not_found} -> > ... > end > > also, we want to be able to directly switch on the result in the > successful case. Something like this: > > try scan(FD) of > foo -> ...; > bar -> ... > catch > {throw, eof} -> > ... > end So this is the same as: case catch scan(Fd) of foo -> ...; bar -> ...; {throw, eof} -> ....; Else -> exit(Else) end. or am I missing something more subtle? Sean From richardc@REDACTED Tue Oct 21 21:33:22 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 21 Oct 2003 21:33:22 +0200 Subject: Try/Cond References: Message-ID: <009a01c3980a$30df47a0$bfdcd1d9@gnit> ----- Original Message ----- From: "Sean Hinde" To: "Richard Carlsson" Cc: "Erlang Questions" Sent: Tuesday, October 21, 2003 9:15 PM Subject: Re: Try/Cond > So this is the same as: > > case catch scan(Fd) of > foo -> ...; > bar -> ...; > {throw, eof} -> > ....; > Else -> exit(Else) > end. > > or am I missing something more subtle? Yes, with this "simulated try", you can't be sure that the term {throw, eof} was not just a value returned from the expression in the "catch", and more importantly, when you call "exit(Else)", you exchange the caught exception for a completely new one - often with different properties. For example, catching a "badmatch" error and re-throwing it with "exit" would change the exception so that it is not logged. Another possible mistake is catching a term originally thrown with "throw(X)" and re-throwing it using "exit(X)". To put it short: Erlang exceptions carry more information than most people think, and the old "catch" just wasn't constructed with this in mind - it destroys most distinctions. (One could say that it presents a very simple model to the user, by lying about the details.) /Richard From richardc@REDACTED Tue Oct 21 21:38:58 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 21 Oct 2003 21:38:58 +0200 Subject: Try/Cond References: <006301c39803$454ffe20$bfdcd1d9@gnit> Message-ID: <00a401c3980a$f89bc980$bfdcd1d9@gnit> ----- Original Message ----- From: "Luke Gorrie" To: "Richard Carlsson" Cc: "Sean Hinde" ; Sent: Tuesday, October 21, 2003 8:56 PM Subject: Re: Try/Cond > Luke Gorrie writes: > > > "Richard Carlsson" writes: > > > > > The current status is that it turned out that Erlang's scoping rules > > > made it harder than we had expected to implement "cond" correctly > > > (i.e., it's not just a trivial expansion into a nested case > > > statement), so it was postponed until someone with a lot of spare time > > > could have another look at it. > > > > Just add `let' too. > > Hmm, but Core Erlang already has `let'. Is the problem that you can't > express cond in Core Erlang, or that you have to do something hard > with it before it gets to Core? Or something else? Representing a cond in Core Erlang is no problem, but there are several things done with the code before the Core stage, and it would have been nice if "cond" could be expanded into "case" expressions very early (so that e.g. the debugger does not have to know anything about it). But it was not as simple as that. /Richard From luke@REDACTED Tue Oct 21 21:44:35 2003 From: luke@REDACTED (Luke Gorrie) Date: 21 Oct 2003 21:44:35 +0200 Subject: Try/Cond In-Reply-To: <00a401c3980a$f89bc980$bfdcd1d9@gnit> References: <006301c39803$454ffe20$bfdcd1d9@gnit> <00a401c3980a$f89bc980$bfdcd1d9@gnit> Message-ID: "Richard Carlsson" writes: > Representing a cond in Core Erlang is no problem, but there are several > things done with the code before the Core stage, and it would have been > nice if "cond" could be expanded into "case" expressions very early > (so that e.g. the debugger does not have to know anything about it). But > it was not as simple as that. Feel free to dump the details. Maybe someone will think of the solution in the shower :-) My first thought was that the trouble would be getting stuck with unwanted variable bindings from clauses that failed, for want of `let'. But variable renaming / alpha-conversion should take care of that. So now I'm most curious as to what the trouble is :-) But maybe that just punts the problem until you need to export the binding for a variable "out" of the cond for some later code. But then you could make the assignment to that variable as soon as the cond clause is selected. But maybe....... -Luke (curious!) From ok@REDACTED Wed Oct 22 06:20:19 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 22 Oct 2003 17:20:19 +1300 (NZDT) Subject: Slightly OT: static typing Message-ID: <200310220420.h9M4KJX9406293@atlas.otago.ac.nz> Michael Hobbs wrote: > Has anyone else read "Objects Have Failed" by Richard P. Gabriel? > http://www.dreamsongs.com/NewFiles/ObjectsHaveFailed.pdf Yes, last night. I'm with him part of the way. The kinds of abstractions you just can't do in Java are quite frustrating. However, it is rather odd to see someone whinging about how reuse has failed when the amount of reuse actually happening these days is *unbelievable* from the perspective of, say, 30 years ago. For example, I write my lecture notes using SGML. I actually do this using my own text editor, because I'm comfortable with it, but when I use Emacs, I get an SGML mode that is appropriate for my specific DTD, and I didn't have to write any of that code. I have a choice of three free SGML parsers with pretty much compatible output, none of which I wrote. To get slides, I have a back end which uses LaTeX (which I didn't write) to produce Postscript (one of these days I'll try pdflatex, which again I didn't write) which I can view on-screen with gv (which I didn't write). I also have a back end which turns a whole paper's worth of slides into an HTML 4.01 web (complete with links to a glossary); I wrote the back end, but there are lots of free HTML viewers that can be used. I tested the conversion with Amaya, which is free source code that I didn't write. I have a spelling checker which is a couple of lines of shell code calling a SGML parser, an awk script which isn't _that_ big, and 'spell', which I didn't write. I wrote the back ends and I devised the DTD. All of my code together comes to less than 2k of source, including comments and blank lines; dear knows how much code they call on. Or look at how much reusable code there is in Erlang. Or take the statistics package R. The reference manual for the built in functions is about 2000 printed pages, and that doesn't include all the statistical, data mining, and bioinformatics code that's available over the web, documented to much the same standard. I can do _amazing_ things in a few lines of R, that would take me a __long__ time to hack up in C. And R talks nicely to Java and Python and Perl and quite a few data bases and ... If anyone wants to do any statistical processing or data visualisation on data gathered as part of the operation of an Erlang system, R is just what the doctor ordered (and it's free...) I look at the stuff some of our 4th-year students do in graphics; they accomplish stuff I don't even begin to understand in at most a couple of thousand lines of code. They aren't unimaginably good programmers, they are using enormous libraries that already do most of what they want. I guess when it arrives packaged in a library (like Erlang/OTP or R or OpenGL &c) people stop thinking of it as "reuse", but it is, and it's the big success story of our time. From francesco@REDACTED Wed Oct 22 08:39:04 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Wed, 22 Oct 2003 07:39:04 +0100 Subject: Try/Cond References: <009a01c3980a$30df47a0$bfdcd1d9@gnit> Message-ID: <3F962608.7000905@erlang-consulting.com> Yes, I agree that there are flaws in the semantics of catch and throw. But in my 8 years of working with Erlang, only once did I see a problem with them: X = (catch foo(Y)), ets:insert(bar, {Y, X}). All the other times, we solved the problem with the simple design rule: Do not use catch and throw. With the introduction of OTP in 1996, I have never seen anyone use exit in their code. The few catches and throws I came across were easily rewritten into a more purely functional style. Yes, it would have been nice with better separated semantics for exit, catch and throw from the start, but I do not see the need to resolve this issue now, considering that it is not causing problems. The issue will not be resolved anyhow, as catch, throw and exit will still remain in the language in the same format they exist in today. (Or is the plan to remove some other feature when introducing try and cond?) Regards, Francesco -- http://www.erlang-consulting.com Richard Carlsson wrote: >----- Original Message ----- >From: "Sean Hinde" >To: "Richard Carlsson" >Cc: "Erlang Questions" >Sent: Tuesday, October 21, 2003 9:15 PM >Subject: Re: Try/Cond > > > > >>So this is the same as: >> >>case catch scan(Fd) of >>foo -> ...; >>bar -> ...; >>{throw, eof} -> >>....; >>Else -> exit(Else) >>end. >> >>or am I missing something more subtle? >> >> > >Yes, with this "simulated try", you can't be sure that the >term {throw, eof} was not just a value returned from the >expression in the "catch", and more importantly, when you >call "exit(Else)", you exchange the caught exception for >a completely new one - often with different properties. > >For example, catching a "badmatch" error and re-throwing >it with "exit" would change the exception so that it is not >logged. Another possible mistake is catching a term originally >thrown with "throw(X)" and re-throwing it using "exit(X)". > >To put it short: Erlang exceptions carry more information >than most people think, and the old "catch" just wasn't >constructed with this in mind - it destroys most distinctions. >(One could say that it presents a very simple model to >the user, by lying about the details.) > > /Richard > > > > > From thomasl_erlang@REDACTED Wed Oct 22 09:52:47 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 22 Oct 2003 00:52:47 -0700 (PDT) Subject: Try/Cond In-Reply-To: <009a01c3980a$30df47a0$bfdcd1d9@gnit> Message-ID: <20031022075247.43497.qmail@web41903.mail.yahoo.com> --- Richard Carlsson wrote: > To put it short: Erlang exceptions carry more > information > than most people think, and the old "catch" just > wasn't > constructed with this in mind - it destroys most > distinctions. > (One could say that it presents a very simple model > to the user, by lying about the details.) (This suggests a pretty dark corner in Erlang's semantics.) My main gripe with exceptions is that they don't provide enough information. At least to the programmer. When I get a 'badarg', I'd also like to know where it occurred and what caused it, for instance. Something like 'smart_exceptions' in jungerl provides a stopgap solution, but a VM solution would be far more satisfying. Here is a way that 'try' could add a bit more value: - exceptions are "objects" that provide lots of info on why and where they occurred (module, function, line, reason, involved terms, etc etc) - 'catch' strips this info and presents just the reason - 'try' provides the entire exception object AND some way to interrogate it (e.g., suitable match notation, up to and including "all_properties"). - Note that if one can't match the exception per se, just its properties, then there is no need to make exception objects a new type either. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From peter@REDACTED Wed Oct 22 10:42:11 2003 From: peter@REDACTED (Peter Lund) Date: Wed, 22 Oct 2003 09:42:11 +0100 (BST) Subject: Try/Cond In-Reply-To: <3F962608.7000905@erlang-consulting.com> References: <3F962608.7000905@erlang-consulting.com> Message-ID: <31973.149.254.120.136.1066812131.squirrel@www.lundata.se> I think catch/throw are useful when parsing. I find catch very useful when parsing binaries or strings. This enables me to write the parser in a very offensive manner and then catch possible deviations from the correct format with a catch. If I find a problem deep inside the parse algorithm it is also very convinient to just throw and then let the catch-statement catch it, instead of attempting to return fault information back through the entire function call chain. That would really be a hazzle... /Peter > Yes, I agree that there are flaws in the semantics of catch and throw. > But in my 8 years of working with Erlang, only once did I see a problem > with them: > > X = (catch foo(Y)), > ets:insert(bar, {Y, X}). > > All the other times, we solved the problem with the simple design rule: > > Do not use catch and throw. > > With the introduction of OTP in 1996, I have never seen anyone use exit > in their code. The few catches and throws I came across were easily > rewritten into a more purely functional style. > > Yes, it would have been nice with better separated semantics for exit, > catch and throw from the start, but I do not see the need to resolve > this issue now, considering that it is not causing problems. The issue > will not be resolved anyhow, as catch, throw and exit will still remain > in the language in the same format they exist in today. (Or is the > plan to remove some other feature when introducing try and cond?) > > Regards, > Francesco > -- > http://www.erlang-consulting.com > > Richard Carlsson wrote: > >>----- Original Message ----- >>From: "Sean Hinde" >>To: "Richard Carlsson" >>Cc: "Erlang Questions" >>Sent: Tuesday, October 21, 2003 9:15 PM >>Subject: Re: Try/Cond >> >> >> >> >>>So this is the same as: >>> >>>case catch scan(Fd) of >>>foo -> ...; >>>bar -> ...; >>>{throw, eof} -> >>>....; >>>Else -> exit(Else) >>>end. >>> >>>or am I missing something more subtle? >>> >>> >> >>Yes, with this "simulated try", you can't be sure that the >>term {throw, eof} was not just a value returned from the >>expression in the "catch", and more importantly, when you >>call "exit(Else)", you exchange the caught exception for >>a completely new one - often with different properties. >> >>For example, catching a "badmatch" error and re-throwing >>it with "exit" would change the exception so that it is not >>logged. Another possible mistake is catching a term originally >>thrown with "throw(X)" and re-throwing it using "exit(X)". >> >>To put it short: Erlang exceptions carry more information >>than most people think, and the old "catch" just wasn't >>constructed with this in mind - it destroys most distinctions. >>(One could say that it presents a very simple model to >>the user, by lying about the details.) >> >> /Richard >> >> >> >> From fredrik.linder@REDACTED Wed Oct 22 10:33:05 2003 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Wed, 22 Oct 2003 10:33:05 +0200 Subject: Try/Cond In-Reply-To: <006901c39803$9dfb93e0$bfdcd1d9@gnit> Message-ID: Hi folks, I'd like to add my NSHO. I seriously hope we'll never see any 'try'-statement introduced into Erlang. With that said, I too would like a deterministic way of separating 'normal control flow' from 'exceptional control flow'. But Erlang already has that construct, so why add a new one? Wasn't there a discussion about that just days ago? Instead of 'try' could the current 'catch' semantics be extended to add the desired functionality, WITHOUT affecting already existing code! So why, really *why*, add a new keyword. One of the things that make Erlang soo good is that there (usually) are only one way of doing something. With a new 'try'-statement and the old 'catch'-statement (that won't go away) there will be two... I fully support the work of separating normal control flow from its 'exceptional' counterpart, but would like to (as many others) keep Erlang 'small. Very Best /Fredrik > -----Original Message----- > From: owner-erlang-questions@REDACTED > [mailto:owner-erlang-questions@REDACTED]On Behalf Of Richard Carlsson > Sent: den 21 oktober 2003 20:46 > To: Sean Hinde; Erlang Questions > Subject: Re: Try/Cond > > > > Oh, and you also mentioned "try". We're still discussing the > fine points about the semantics and syntax. I seriously hope > it will be part of R10 next year. > > /Richard > > ----- Original Message ----- > From: "Sean Hinde" > To: "Erlang Questions" > Sent: Tuesday, October 21, 2003 8:25 PM > Subject: Try/Cond > > > > Hi, > > > > I have heard and read much about the possible arrival of try/cond to > > the language. Can anyone shed any light on how it would be intended to > > work? > > > > Thanks, > > Sean > > > > > > > From fredrik.linder@REDACTED Wed Oct 22 10:39:42 2003 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Wed, 22 Oct 2003 10:39:42 +0200 Subject: peer-to-peerlang (was RE: One Million Processes) In-Reply-To: <20031021180258.9234.qmail@web41904.mail.yahoo.com> Message-ID: > -----Original Message----- > From: owner-erlang-questions@REDACTED > [mailto:owner-erlang-questions@REDACTED]On Behalf Of Thomas Lindgren > --- Bjorn Gustavsson wrote: > > "Vlad Dumitrescu" > > writes: > > I think it is clear that the distribution should NOT > > be used, > > for several reasons. > > > > Security: Anyone that is able to connect (has the > > cookie) can do > > any kind of damage to any other connected Erlang > > node. (Through > > spawn/4 or one of the rpc:call functions.) > > > > Scalability: The distribution was not designed to > > allow that many > > nodes connected to each other. > > > > Distribution is good for communication between a > > small number of > > hosts that that mutually trust each other. > > Indeed. BUT the replacement mechanism (unreliable > distribution, if you will) should be about as > convenient as today, if not more so. Perhaps something > like: > > - automatic scalable, unreliable distribution handling > millions of nodes that may join or leave at any time > > - transparent message passing among the nodes > > - some sort of directory (or directories) for the > whole thing > > - some way to manage code > > - again, security/trust issues > > and "whatever more is needed". Target audience: p2p > developers. I do not think that a new, more secure, distribution mechanism should REPLACE the existing mechansim. It is more like they should co-exist. Consider; my several erlang nodes large cluster (p2p-node) trust each other, while I'd like one or a few of them to connect to another p2p-node. Internally within my cluster I'd like to have the normal distribution, but between p2p-nodes I'd like the more secure one. So there are actually some nodes that needs them both... /Fredrik From mikpe@REDACTED Wed Oct 22 11:37:10 2003 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 22 Oct 2003 11:37:10 +0200 Subject: surprising result with hipe compilation In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F5402578@ESEALNT442.al.sw.ericsson.se> References: <37FB7AA6F5F9814FB634A7BF4C35A6F5402578@ESEALNT442.al.sw.ericsson.se> Message-ID: <16278.20422.925021.78743@alkaid.it.uu.se> Ulf Wiger (AL/EAB) writes: > > Ulf Wiger (AL/EAB) wrote: > > > 52> c(contract_parser1,[native]). > > {ok,contract_parser1} > > 53> timer:tc(contract_parser1,read_and_parse,["file_plugin.con"]). > > {75, > > {'EXIT',{undef,[{contract_parser1,read_and_parse,["file_plugin.con"]}, > > {timer,tc,3}, > > {erl_eval,expr,3}, > > {erl_eval,exprs,4}, > > {shell,eval_loop,2}]}}} > > > > > > Oops again! This looks like a bug, or am I missing something? > > I was missing something: the 'export_all' option. :( > It didn't help much, though. If anything, It got even slower with > both modules native. Something in this code does not seem to > get along with hipe. A self-contained test case would be required if we are to track this down. /Mikael From peter@REDACTED Wed Oct 22 12:13:03 2003 From: peter@REDACTED (Peter Lund) Date: Wed, 22 Oct 2003 11:13:03 +0100 (BST) Subject: Try/Cond In-Reply-To: <006901c39803$9dfb93e0$bfdcd1d9@gnit> References: <006901c39803$9dfb93e0$bfdcd1d9@gnit> Message-ID: <64772.149.254.120.136.1066817583.squirrel@www.lundata.se> Who are we and why am I not included in this "discussion"? Anything that ever should make it into the language should be "discussed" and presented openly first. Decisions should not be made behind closed doors by some anonomous group of people but by the erlang *community* instead... > Oh, and you also mentioned "try". We're still discussing the > fine points about the semantics and syntax. I seriously hope > it will be part of R10 next year. > > /Richard > > ----- Original Message ----- > From: "Sean Hinde" > To: "Erlang Questions" > Sent: Tuesday, October 21, 2003 8:25 PM > Subject: Try/Cond > > >> Hi, >> >> I have heard and read much about the possible arrival of try/cond to >> the language. Can anyone shed any light on how it would be intended to >> work? >> >> Thanks, >> Sean >> >> >> From joe@REDACTED Wed Oct 22 13:04:43 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 22 Oct 2003 13:04:43 +0200 (CEST) Subject: Try/Cond In-Reply-To: <3F962608.7000905@erlang-consulting.com> Message-ID: On Wed, 22 Oct 2003, Francesco Cesarini wrote: > Yes, I agree that there are flaws in the semantics of catch and throw. > But in my 8 years of working with Erlang, only once did I see a problem > with them: > > X = (catch foo(Y)), > ets:insert(bar, {Y, X}). > > All the other times, we solved the problem with the simple design rule: > > Do not use catch and throw. > What - you're nuts > With the introduction of OTP in 1996, I have never seen anyone use exit > in their code. The few catches and throws I came across were easily > rewritten into a more purely functional style. My code has loads of exits. The golden rule is "let it crash" - quite often code will crash with a less-than-helpful (TM) diagnostic. Here I always write exit(<>) The more I program the more I use exit - as soon as I don't know what to do I instinctively write exit(...) - this is a reflex reaction. There is no way of getting a non-local return from a function if you do not use catch and throw. Pleeeese teach you students the correct way to use catch/throw/exit - this will lead to much cleaner code than if they try religiously to avoid their use. /Joe > Yes, it would have been nice with better separated semantics for exit, > catch and throw from the start, but I do not see the need to resolve > this issue now, considering that it is not causing problems. The issue > will not be resolved anyhow, as catch, throw and exit will still remain > in the language in the same format they exist in today. (Or is the plan > to remove some other feature when introducing try and cond?) > > Regards, > Francesco > -- > http://www.erlang-consulting.com > > Richard Carlsson wrote: > > >----- Original Message ----- > >From: "Sean Hinde" > >To: "Richard Carlsson" > >Cc: "Erlang Questions" > >Sent: Tuesday, October 21, 2003 9:15 PM > >Subject: Re: Try/Cond > > > > > > > > > >>So this is the same as: > >> > >>case catch scan(Fd) of > >>foo -> ...; > >>bar -> ...; > >>{throw, eof} -> > >>....; > >>Else -> exit(Else) > >>end. > >> > >>or am I missing something more subtle? > >> > >> > > > >Yes, with this "simulated try", you can't be sure that the > >term {throw, eof} was not just a value returned from the > >expression in the "catch", and more importantly, when you > >call "exit(Else)", you exchange the caught exception for > >a completely new one - often with different properties. > > > >For example, catching a "badmatch" error and re-throwing > >it with "exit" would change the exception so that it is not > >logged. Another possible mistake is catching a term originally > >thrown with "throw(X)" and re-throwing it using "exit(X)". > > > >To put it short: Erlang exceptions carry more information > >than most people think, and the old "catch" just wasn't > >constructed with this in mind - it destroys most distinctions. > >(One could say that it presents a very simple model to > >the user, by lying about the details.) > > > > /Richard > > > > > > > > > > > > From joe@REDACTED Wed Oct 22 13:26:30 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 22 Oct 2003 13:26:30 +0200 (CEST) Subject: Language change proposal Message-ID: Hi everybody - I'd like to propose the following language change: (It's *very* easy to implement) I want all Erlang modules to be tagged with a "language version" Like this ... ------------------------------------------------------------------------ Suppose the next version of Erlang is 5.3 then: 1) All modules *must* start -module(XXXX). -vsn("5.3"). 2) Any module *without* a version is assumed to be "5.2" 3) If there is no version the compiler should complain like hell with a warning that cannot be turned off that an explicit language version is not present. 4) There should be files called "depreciated_5.3.{erl,txt}" that tell the user what language language features and library routine have been depreciated in version 5.3 The text file should describe the depreciated features. The Erlang file can be used by the compiler to provide warnings about depreciated features. Then - somewhat later - when we change to version 5.4 The same rules apply - with one exception - warnings issued about depreciated constructs in 5.3 now become hard errors - and there is no way to turn off this behaviour. ------------------------------------------------------------------------- Versions should be numbered X.Y.Z Bumping X is done for syntax changes to Erlang, or changes in the semantics if BIFs etc. (serious things). Bumping Y is done for depreciated library functions bug fixes in libraries Bumping Z is done for cosmetic reasons -------------------------------------------------------------------------- ******* * Why * ******* We need enforceable mechanisms to *remove* things from the Erlang libraries and from the language. Erlang is getting bigger and things are not being removed. As regards customers who crave backwards compatibility tell them that if they want to use the new stuff they will have to change their code. The version that they used in their products should always be supported into the future - but the cost of doing so should increase as you bump the version numbers. This is *exactly* what the chip manufacturers do - have you ever tried to buy "old" memory chips - they cost a fortune !!!! IMHO their should be no language changes until it can be realistically demonstrated that we can remove things from the language. /Joe From luke@REDACTED Wed Oct 22 13:27:00 2003 From: luke@REDACTED (Luke Gorrie) Date: 22 Oct 2003 13:27:00 +0200 Subject: Try/Cond In-Reply-To: References: Message-ID: Joe Armstrong writes: > There is no way of getting a non-local return from a function if you > do not use catch and throw. And there is no way to do non-local return from a function without buggering up the backtrace of genuine errors in Erlang today, for the reasons Richard gave. That's why I personally avoid try/catch whenever possible - it discards lots of good debug information for no good reason. That's why I think try/catch would be a Good Thing. If we need to remove something in exchange, how about we remove the 'catch'-related programming rules. Instead of 'catch is dangerous because foo bar baz, only use it if you're a guru", you could say "go ahead and use try/catch if you think it will make your program simpler". But then we probably need a new set of programming rules for using try/catch with higher-order functions, like a 'throw {?MODULE, ...}' convention, since you don't know what other catch patterns will be on the stack when your fun is called -- not to mention if your fun is sent to another process to be executed and doesn't have your 'catch' at all. "Don't use 'throw' in a fun" ? That's life, eh? :-) -Luke From richardc@REDACTED Wed Oct 22 13:28:51 2003 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 22 Oct 2003 13:28:51 +0200 Subject: Try/Cond References: <006901c39803$9dfb93e0$bfdcd1d9@gnit> <64772.149.254.120.136.1066817583.squirrel@www.lundata.se> Message-ID: <004901c3988f$ab3a8430$bfdcd1d9@gnit> ----- Original Message ----- From: "Peter Lund" To: Cc: Sent: Wednesday, October 22, 2003 12:13 PM Subject: Re: Try/Cond > Who are we and why am I not included in this "discussion"? "We" in this case are the Erlang/OTP people (mainly Bj?rn G., Patrik N. and Kenneth L.), and the HiPE group (which includes myself) - in short, those involved with implementing and supporting every aspect of the language, both old and new. > Anything that ever should make it into the language should > be "discussed" and presented openly first. Decisions should > not be made behind closed doors by some anonomous group of > people but by the erlang *community* instead... The addition of "try"-expressions was suggested already in the draft Standard Erlang Specification by Jonas Barklund and Robert Virding around 1997, which you can find here: http://www.bluetail.com/~rv/Erlang-spec/index.shtml (however note that the page is not being updated anymore, and that the de facto Erlang language has by now partly evolved away from some parts of the draft standard document). Since then, "try"-expressions have been a recurring topic on the erlang-questions list. I really don't think you can claim that this is something that has been going on behind closed doors, unless that closed door is your own. On the other hand, there are lots of small things that have been done with the language by the Erlang/OTP folks in the last 5 years since the draft standard, which have simply been presented in the "highlights" of each new release, without ever being discussed on the erlang-questions list, for better or for worse. You have to realise that although being Open Source, there is in fact only one full implementation of Erlang, and it is maintained and developed by OTP. /Richard From nick@REDACTED Wed Oct 22 13:44:39 2003 From: nick@REDACTED (Niclas Eklund) Date: Wed, 22 Oct 2003 13:44:39 +0200 (MEST) Subject: Language change proposal In-Reply-To: Message-ID: Hello! Xref supplies a very flexible solution. See ('-deprecated(...)'): http://www.erlang.org/doc/r9c/lib/tools-2.3/doc/html/xref.html /Nick > Hi everybody - I'd like to propose the following language change: > > (It's *very* easy to implement) > > I want all Erlang modules to be tagged with a "language version" > > Like this ... > > ------------------------------------------------------------------------ > > Suppose the next version of Erlang is 5.3 then: > > 1) All modules *must* start > > -module(XXXX). > -vsn("5.3"). > > 2) Any module *without* a version is assumed to be "5.2" > > 3) If there is no version the compiler should complain like hell > with a warning that cannot be turned off that an explicit language > version is not present. > > 4) There should be files called "depreciated_5.3.{erl,txt}" > that tell the user what language language features and library > routine have been depreciated in version 5.3 > > The text file should describe the depreciated features. > > The Erlang file can be used by the compiler to provide warnings about > depreciated features. > > > Then - somewhat later - when we change to version 5.4 > > The same rules apply - with one exception - warnings issued about > depreciated constructs in 5.3 now become hard errors - and there is no > way to turn off this behaviour. > > ------------------------------------------------------------------------- > > Versions should be numbered X.Y.Z > > Bumping X is done for syntax changes to Erlang, or changes in the > semantics if BIFs etc. (serious things). > > Bumping Y is done for depreciated library functions bug fixes in libraries > > Bumping Z is done for cosmetic reasons > > -------------------------------------------------------------------------- > > ******* > * Why * > ******* > > We need enforceable mechanisms to *remove* things from the Erlang > libraries and from the language. > > Erlang is getting bigger and things are not being removed. > > As regards customers who crave backwards compatibility tell them that > if they want to use the new stuff they will have to change their code. > > The version that they used in their products should always be > supported into the future - but the cost of doing so should increase > as you bump the version numbers. > > This is *exactly* what the chip manufacturers do - have you ever > tried to buy "old" memory chips - they cost a fortune !!!! > > IMHO their should be no language changes until it can be > realistically demonstrated that we can remove things from the > language. > > /Joe From fredrik.linder@REDACTED Wed Oct 22 14:05:05 2003 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Wed, 22 Oct 2003 14:05:05 +0200 Subject: Language change proposal In-Reply-To: Message-ID: This sounds like an excellent proposal! /Fredrik > -----Original Message----- > From: owner-erlang-questions@REDACTED > [mailto:owner-erlang-questions@REDACTED]On Behalf Of Joe Armstrong > Sent: den 22 oktober 2003 13:27 > To: erlang-questions@REDACTED > Subject: Language change proposal > > > > Hi everybody - I'd like to propose the following language change: > > (It's *very* easy to implement) > > I want all Erlang modules to be tagged with a "language version" > > Like this ... > > ------------------------------------------------------------------------ > > Suppose the next version of Erlang is 5.3 then: > > 1) All modules *must* start > > -module(XXXX). > -vsn("5.3"). > > 2) Any module *without* a version is assumed to be "5.2" > > 3) If there is no version the compiler should complain like hell > with a warning that cannot be turned off that an explicit > language > version is not present. > > 4) There should be files called "depreciated_5.3.{erl,txt}" > that tell the user what language language features and library > routine have been depreciated in version 5.3 > > The text file should describe the depreciated features. > > The Erlang file can be used by the compiler to provide > warnings about > depreciated features. > > > Then - somewhat later - when we change to version 5.4 > > The same rules apply - with one exception - warnings issued about > depreciated constructs in 5.3 now become hard errors - and there is no > way to turn off this behaviour. > > ------------------------------------------------------------------------- > > Versions should be numbered X.Y.Z > > Bumping X is done for syntax changes to Erlang, or changes in the > semantics if BIFs etc. (serious things). > > Bumping Y is done for depreciated library functions bug fixes > in libraries > > Bumping Z is done for cosmetic reasons > > -------------------------------------------------------------------------- > > ******* > * Why * > ******* > > We need enforceable mechanisms to *remove* things from the Erlang > libraries and from the language. > > Erlang is getting bigger and things are not being removed. > > As regards customers who crave backwards compatibility tell them that > if they want to use the new stuff they will have to change their code. > > The version that they used in their products should always be > supported into the future - but the cost of doing so should increase > as you bump the version numbers. > > This is *exactly* what the chip manufacturers do - have you ever > tried to buy "old" memory chips - they cost a fortune !!!! > > IMHO their should be no language changes until it can be > realistically demonstrated that we can remove things from the > language. > > /Joe > > > From D.WILLIAMS@REDACTED Wed Oct 22 14:26:54 2003 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Wed, 22 Oct 2003 14:26:54 +0200 Subject: Language change proposal Message-ID: From: Joe Armstrong > > I want all Erlang modules to be tagged with a "language version" > I wholeheartedly share the concern for managing language and library evolutions. Doing this properly would be another major strength of Erlang over many other environments. As to the details, I would prefer that whatever mechanism is used to deprecate libraries (modules, functions) be designed to serve the same purpose for external libraries (not only those provided as part of the Erlang/OTP distribution) and application development in general. Also, I am not very keen on having to add a vsn attribute to every module I develop. I would prefer these issues to be manageable in one place for an entire build tree (i.e. in an (E)makefile). I would therefore (respectfully) suggest an alternative scheme: 1) The compiler would by default assume the latest version of the language is being used. When a language feature becomes deprecated, the compiler rejects code using this feature unless a specific compiler directive has been used to allow it. 2) Functions would be deprecated by adding an obsolete attribute that would list obsolete functions in the same format as export/import: -module(my_module). -export([a/1,b/2,c/3]). -obsolete([b/2]). This could be used (by the Erlang development team) for core libraries, as well as (by the rest of us) for our own libraries, frameworks and applications... Regards, Dominic Williams. From vlad_dumitrescu@REDACTED Wed Oct 22 14:29:29 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 22 Oct 2003 14:29:29 +0200 Subject: essential Erlang References: <3F71A4FC.9080806@web.de> Message-ID: Replying to an older post: ----- Original Message ----- From: "Joachim Durchholz" > > I'd find it more interesting if there were a way of making Erlang > interface better with C programs. I've been interfacing Windows with a > non-C language, and it's been a pain even though it was a direct-call > interface - I'm wondering how much worse it will be to write a driver > program for Erlang... (semiautomatically generating drivers from C > include files would help a lot) I've been trying that, and my experience is that converting the headres is just the simpler part (tedious and boring, but simpler). The problem for me was how to handle memory allocation of objects needed on both sides. Maybe it's not that difficult, but I couldn't make it work. So I returned to writing a port program that did the interfacing. Maybe this is the way to go, so that non-system drivers don't crash the runtime: from C headers generate code (C and Erlang) that will provide 80% of a port program. I think the old IG application, no longer supported, could be seen as a starting point. [http://www.bluetail.com/~tobbe/ig/] regards, Vlad ps: sorry, IC doesn't appeal to me :-) Converting C headers to IDL is just as tedious and boring. From lennart.ohman@REDACTED Wed Oct 22 14:37:37 2003 From: lennart.ohman@REDACTED (=?ISO-8859-1?Q?Lennart_=D6hman?=) Date: Wed, 22 Oct 2003 14:37:37 +0200 Subject: Language change proposal In-Reply-To: References: Message-ID: <3F967A11.8060604@st.se> Not a bad idea. But I suggest another attribute since "vsn" is already in use by OTP release handler. -erts_vsn("5.3") /Lennart Fredrik Linder wrote: > This sounds like an excellent proposal! > > /Fredrik > > >>-----Original Message----- >>From: owner-erlang-questions@REDACTED >>[mailto:owner-erlang-questions@REDACTED]On Behalf Of Joe Armstrong >>Sent: den 22 oktober 2003 13:27 >>To: erlang-questions@REDACTED >>Subject: Language change proposal >> >> >> >>Hi everybody - I'd like to propose the following language change: >> >>(It's *very* easy to implement) >> >>I want all Erlang modules to be tagged with a "language version" >> >>Like this ... >> >>------------------------------------------------------------------------ >> >> Suppose the next version of Erlang is 5.3 then: >> >> 1) All modules *must* start >> >> -module(XXXX). >> -vsn("5.3"). >> >> 2) Any module *without* a version is assumed to be "5.2" >> >> 3) If there is no version the compiler should complain like hell >> with a warning that cannot be turned off that an explicit >>language >> version is not present. >> >> 4) There should be files called "depreciated_5.3.{erl,txt}" >> that tell the user what language language features and library >> routine have been depreciated in version 5.3 >> >> The text file should describe the depreciated features. >> >> The Erlang file can be used by the compiler to provide >>warnings about >> depreciated features. >> >> >> Then - somewhat later - when we change to version 5.4 >> >> The same rules apply - with one exception - warnings issued about >>depreciated constructs in 5.3 now become hard errors - and there is no >>way to turn off this behaviour. >> >>------------------------------------------------------------------------- >> >> Versions should be numbered X.Y.Z >> >> Bumping X is done for syntax changes to Erlang, or changes in the >>semantics if BIFs etc. (serious things). >> >> Bumping Y is done for depreciated library functions bug fixes >>in libraries >> >> Bumping Z is done for cosmetic reasons >> >>-------------------------------------------------------------------------- >> >> ******* >> * Why * >> ******* >> >> We need enforceable mechanisms to *remove* things from the Erlang >>libraries and from the language. >> >> Erlang is getting bigger and things are not being removed. >> >> As regards customers who crave backwards compatibility tell them that >>if they want to use the new stuff they will have to change their code. >> >> The version that they used in their products should always be >>supported into the future - but the cost of doing so should increase >>as you bump the version numbers. >> >> This is *exactly* what the chip manufacturers do - have you ever >>tried to buy "old" memory chips - they cost a fortune !!!! >> >> IMHO their should be no language changes until it can be >>realistically demonstrated that we can remove things from the >>language. >> >> /Joe >> >> >> > > -- ------------------------------------------------------------- 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 luke@REDACTED Wed Oct 22 15:21:35 2003 From: luke@REDACTED (Luke Gorrie) Date: 22 Oct 2003 15:21:35 +0200 Subject: SNMP MIB-2 tables in Erlang? Message-ID: Ahoy, We're adding support for some standard SNMP MIBs to our Linux boxes: interfaces, IP statistics, routing table, etc. I'm thinking about doing it with the Erlang SNMP agent instead of using an existing implementation, in the name of having better customization hooks. Has anyone already done something similar? If so please give me a yell. Cheers, Luke From joe@REDACTED Wed Oct 22 16:02:17 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 22 Oct 2003 16:02:17 +0200 (CEST) Subject: Language change proposal In-Reply-To: Message-ID: On Wed, 22 Oct 2003, WILLIAMS Dominic wrote: > From: Joe Armstrong > > > > I want all Erlang modules to be tagged with a "language version" > > > > I wholeheartedly share the concern for managing language and library > evolutions. Doing this properly would be another major strength of > Erlang over many other environments. This is *not* a proposal for library management/evolution only a *minimal* way of getting rid of stuff from the language. <> > As to the details, I would prefer that whatever mechanism is used to > deprecate libraries (modules, functions) be designed to serve the same > purpose for external libraries (not only those provided as part of the > Erlang/OTP distribution) and application development in general. > > Also, I am not very keen on having to add a vsn attribute to every > module I develop. I would prefer these issues to be manageable in one > place for an entire build tree (i.e. in an (E)makefile). > The problem is that then the code will get detached from the makefile and the version information will be lost. > I would therefore (respectfully) suggest an alternative scheme: > > 1) The compiler would by default assume the latest version of the > language is being used. When a language feature becomes deprecated, > the compiler rejects code using this feature unless a specific > compiler directive has been used to allow it. This doesn't work - suppose we *don't* do as I have suggested - the following *will* happen. - A new version of the language turns up - with the 'try' statement. - I write a program using 'try' and use the latest compiler - I post my program to the net - I get mail saying that my program is ****ed up because it won't go through some old version of the compiler that was released before version numbering was introduced. This has already happened to me on several occasions - I have sent people program that use binaries - only to find that they are using a "pre-binaries" Erlang. > > 2) Functions would be deprecated by adding an obsolete attribute that > would list obsolete functions in the same format as export/import: > > -module(my_module). > -export([a/1,b/2,c/3]). > -obsolete([b/2]). > Ummm ... why not - A while back I made a little system for patching modules. Example: Suppose we have mod.erl -module(mod). -export [p/7, j/3, a/2, b/4, x/9]). and mod.1.patch -module(mod1). %% my new module name -inherit(mod). %% based on -remove([a/2, b/4]). %% These calls in mod1 will not be available -add([c/2]). %% c/2 is added to mod1 -replace([p/7,j/3]). %% p/7 and j/3 are in mod1 but are being redefined c(_, _) -> ... p(...) Then both mod and mod1 can co-exist, old programs can use mod and new ones can use mod1 This can be implemented with some very simple munging mod1.erl looks like -module(mod2). -export([p/7, j/3, x/9, c/2]). %% set up the old calls p(....) -> mod:p(....) use the old definitions of p/7 ... x(...) -> mod:x(...) %% and add the new code c(..., ...) -> ... Then you could issue a series of files mod.erl mod.1.patch mod.2.patch etc. This is how programs used to done when I started off in the 'good 'ol days - when the "program" weighed about 15 Kg and was 4 trays of punched cards. The "patch" was only a few hundred cards and didn't need a fork lift truck to get it to the computer center :-) > This could be used (by the Erlang development team) for core > libraries, as well as (by the rest of us) for our own libraries, > frameworks and applications... > > Regards, > > Dominic Williams. > /Joe From ulf.wiger@REDACTED Wed Oct 22 16:26:08 2003 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Wed, 22 Oct 2003 16:26:08 +0200 Subject: surprising result with hipe compilation Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5402579@ESEALNT442.al.sw.ericsson.se> Yes, of course. I am fixing some unrelated bugs and hope to be able to reproduce the problem once I'm done. Then I'll send you the code. /Uffe -----Original Message----- From: Mikael Pettersson [mailto:mikpe@REDACTED] Sent: den 22 oktober 2003 11:37 To: Ulf Wiger (AL/EAB) Cc: 'erlang-questions@REDACTED' Subject: RE: surprising result with hipe compilation Ulf Wiger (AL/EAB) writes: > > Ulf Wiger (AL/EAB) wrote: > > > 52> c(contract_parser1,[native]). > > {ok,contract_parser1} > > 53> timer:tc(contract_parser1,read_and_parse,["file_plugin.con"]). > > {75, > > {'EXIT',{undef,[{contract_parser1,read_and_parse,["file_plugin.con"]}, > > {timer,tc,3}, > > {erl_eval,expr,3}, > > {erl_eval,exprs,4}, > > {shell,eval_loop,2}]}}} > > > > > > Oops again! This looks like a bug, or am I missing something? > > I was missing something: the 'export_all' option. :( > It didn't help much, though. If anything, It got even slower with > both modules native. Something in this code does not seem to > get along with hipe. A self-contained test case would be required if we are to track this down. /Mikael From david.wallin@REDACTED Wed Oct 22 16:44:18 2003 From: david.wallin@REDACTED (David Wallin) Date: Wed, 22 Oct 2003 15:44:18 +0100 Subject: BUG in HiPE Message-ID: <6ee5b60e12fb1073fedf5a9acfb952ca@wintermute> Source file attached, here's what happens: 5> c(hipe_bugs,[native]). {ok,hipe_bugs} 6> hipe_bugs:bug1(). =ERROR REPORT==== 22-Oct-2003::15:38:31 === Error in process <0.24.0> with exit value: {{badmatch,false},[{hipe_bugs,bug1,0}]} ** exited: {{badmatch,false},[{hipe_bugs,bug1,0}]} ** 7> c(hipe_bugs). {ok,hipe_bugs} 8> hipe_bugs:bug1(). "2003-10-22 14:38:50 [build 1]." 9> cheers, --david. -------------- next part -------------- A non-text attachment was scrubbed... Name: hipe_bugs.erl Type: application/octet-stream Size: 711 bytes Desc: not available URL: From joachim.durchholz@REDACTED Wed Oct 22 16:41:23 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Wed, 22 Oct 2003 16:41:23 +0200 Subject: Slightly OT: static typing In-Reply-To: <200310220420.h9M4KJX9406293@atlas.otago.ac.nz> References: <200310220420.h9M4KJX9406293@atlas.otago.ac.nz> Message-ID: <3F969713.8070903@web.de> Richard A. O'Keefe wrote: > Michael Hobbs wrote: >> Has anyone else read "Objects Have Failed" by Richard P. Gabriel? >> http://www.dreamsongs.com/NewFiles/ObjectsHaveFailed.pdf > > [...] it is rather odd to see someone whinging about how reuse > has failed when the amount of reuse actually happening these days is > *unbelievable* from the perspective of, say, 30 years ago. > > [Lots of valid examples of code reuse snipped] Right, but this reuse isn't happening in an OO fashion... so, reuse has failed /for OO/ (which is, after all, his point), and has worked for the standard "structured programming" approach. Regards, Jo From mikpe@REDACTED Wed Oct 22 17:29:19 2003 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 22 Oct 2003 17:29:19 +0200 Subject: BUG in HiPE In-Reply-To: <6ee5b60e12fb1073fedf5a9acfb952ca@wintermute> References: <6ee5b60e12fb1073fedf5a9acfb952ca@wintermute> Message-ID: <16278.41551.356848.364312@alkaid.it.uu.se> David Wallin writes: > > Source file attached, here's what happens: > > 5> c(hipe_bugs,[native]). > {ok,hipe_bugs} > 6> hipe_bugs:bug1(). > > =ERROR REPORT==== 22-Oct-2003::15:38:31 === > Error in process <0.24.0> with exit value: > {{badmatch,false},[{hipe_bugs,bug1,0}]} > > ** exited: {{badmatch,false},[{hipe_bugs,bug1,0}]} ** > 7> c(hipe_bugs). > {ok,hipe_bugs} > 8> hipe_bugs:bug1(). > "2003-10-22 14:38:50 [build 1]." > 9> Confirmed. The problem is that module_info() returns [] when the module is native-compiled, which breaks your keysearch/3 call. We'll look into this. Thanks for the report. /Mikael From cpressey@REDACTED Wed Oct 22 18:29:25 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 22 Oct 2003 09:29:25 -0700 Subject: Language change proposal In-Reply-To: References: Message-ID: <20031022092925.6115a375.cpressey@catseye.mine.nu> On Wed, 22 Oct 2003 13:26:30 +0200 (CEST) Joe Armstrong wrote: > > Hi everybody - I'd like to propose the following language change: > > (It's *very* easy to implement) > > I want all Erlang modules to be tagged with a "language version" > > Like this ... > > --------------------------------------------------------------------- > --- > > Suppose the next version of Erlang is 5.3 then: > > 1) All modules *must* start > > -module(XXXX). > -vsn("5.3"). It's a good idea, but wouldn't it be easier to write code that works on different versions if it was done with macros, e.g. -ifdef(?ERLANG_5_3). % some code that uses bleeding-edge features here -else. -ifdef(?ERLANG_5_2). % some code that uses 5.2-isms here -else. % some code that is dangerously language-version-unspecific here -endif. -endif. I think this would be the way to go if you wanted to write code that takes advantage of new features while still being able to compile and run on older installations. Even slicker would be if there was a single ?ERLANG_VERSION predefined macro, and a way to check its value with conditional compilation. Nothing earthshatteringly new, of course (are we finally catching up to cpp? :) -Chris From david.wallin@REDACTED Wed Oct 22 19:08:38 2003 From: david.wallin@REDACTED (David Wallin) Date: Wed, 22 Oct 2003 18:08:38 +0100 Subject: Another HiPE bug? Message-ID: <13707b3b1b7e004a58ed714f43945650@wintermute> Attached the source code, the function 'make_odd/1' should work like this: A binary consisting of an even number of ones is taken as argument. A randomly picked bit is flipped and the new binary returned. As shown below, this is not the case (the input in this case is <<2#00000011>>). I also tried with other inputs and the result was always <<192>> when compiled with HiPE. Eshell V5.3 (abort with ^G) 1> c(hipe_bugs). {ok,hipe_bugs} 2> hipe_bugs:bug2(). <<131>> 3> hipe_bugs:bug2(). <<19>> 4> hipe_bugs:bug2(). <<7>> 5> hipe_bugs:bug2(). <<2>> 6> hipe_bugs:bug2(). <<11>> 7> c(hipe_bugs,[native]). {ok,hipe_bugs} 8> hipe_bugs:bug2(). <<192>> 9> hipe_bugs:bug2(). <<192>> 10> hipe_bugs:bug2(). <<192>> 11> hipe_bugs:bug2(). <<192>> toodlepip, --david. -------------- next part -------------- A non-text attachment was scrubbed... Name: hipe_bugs.erl Type: application/octet-stream Size: 1006 bytes Desc: not available URL: From thomasl_erlang@REDACTED Wed Oct 22 21:20:03 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 22 Oct 2003 12:20:03 -0700 (PDT) Subject: Language change proposal In-Reply-To: Message-ID: <20031022192003.84239.qmail@web41906.mail.yahoo.com> --- Joe Armstrong wrote: > > Hi everybody - I'd like to propose the following > language change: > > (It's *very* easy to implement) > > I want all Erlang modules to be tagged with a > "language version" > > Like this ... > > ------------------------------------------------------------------------ > > Suppose the next version of Erlang is 5.3 then: > > 1) All modules *must* start > > -module(XXXX). > -vsn("5.3"). > > 2) Any module *without* a version is assumed > to be "5.2" Since -vsn is already in use, as Lennart noted, how about introducing -module(XXXX, ERL_VSN). with a release-dependent macro ?LATEST for convenience, e.g., -module(lists, ?LATEST). The advantage: if all future Erlang versions agree to begin all modules with a -module(..., ...) attribute, then the system can select the parser and tokenizer to be used at that point. Having a floating -vsn attribute is less convenient, or so it seems to me. Also, I think it would be a good thing to have a language release, ie, a definition of what things mean, associated with each language version. Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From thomasl_erlang@REDACTED Wed Oct 22 21:22:05 2003 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 22 Oct 2003 12:22:05 -0700 (PDT) Subject: Try/Cond In-Reply-To: <004901c3988f$ab3a8430$bfdcd1d9@gnit> Message-ID: <20031022192205.94784.qmail@web41905.mail.yahoo.com> --- Richard Carlsson wrote: > ----- Original Message ----- > From: "Peter Lund" > To: > Cc: > Sent: Wednesday, October 22, 2003 12:13 PM > Subject: Re: Try/Cond > > > > Who are we and why am I not included in this > "discussion"? > > "We" in this case are the Erlang/OTP people (mainly > Bj?rn G., > Patrik N. and Kenneth L.), and the HiPE group (which > includes > myself) - in short, those involved with implementing > and supporting > every aspect of the language, both old and new. By the way, is there a current description of 'cond' anywhere? Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com From richardc@REDACTED Wed Oct 22 21:49:39 2003 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 22 Oct 2003 21:49:39 +0200 Subject: Fw: Try/Cond Message-ID: <00e801c398d5$a69d5290$bfdcd1d9@gnit> ----- Original Message ----- From: "Thomas Lindgren" To: Sent: Wednesday, October 22, 2003 9:22 PM Subject: Re: Try/Cond > By the way, is there a current description of 'cond' > anywhere? > > Best, > Thomas As far as I know, the only detailed description is the one in the Standard Erlang Specification draft. The concept is simple enough, but it's not clear that it's worth the implementation effort, at least the way things looked last time I thought about it. /Richard From joachim.durchholz@REDACTED Thu Oct 23 01:03:23 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Thu, 23 Oct 2003 01:03:23 +0200 Subject: Language change proposal In-Reply-To: <20031022092925.6115a375.cpressey@catseye.mine.nu> References: <20031022092925.6115a375.cpressey@catseye.mine.nu> Message-ID: <3F970CBB.2050205@web.de> Chris Pressey wrote: > It's a good idea, but wouldn't it be easier to write code that works on > different versions if it was done with macros, e.g. > > -ifdef(?ERLANG_5_3). > % some code that uses bleeding-edge features here > -else. > -ifdef(?ERLANG_5_2). > % some code that uses 5.2-isms here > -else. > % some code that is dangerously language-version-unspecific here > -endif. > -endif. Most definitely *no*. I have maintained C code that went like this; it was a nightmare. The reason was that it offered too many opportunities for "clever writing" like this: if (normal condition) { ... #ifdef VERSION = xxx ... } else { ... #else ... } else { ... #endif ... } You can't even properly do indentation... However, there's one thing that /could/ be done: add an erlang_version predicate that's guaranteed to be evaluated at compile time. Also, add some rules about compile-time evaluation for expressions "known to be constant" (these can be very simplicistic, look at the rules for Turbo Pascal, for example). With that, you can write stuff like (excuse the non-Erlang syntax here, I've still not gotten around to making my ankles wet...) if erlang_version = "5_3" % some code that uses bleeding-edge features here else if erlang_version = "5_2" % some code that uses 5.2-isms here else some code that is dangerously language-version-unspecific here endif endif Regards, Jo From hal@REDACTED Thu Oct 23 01:49:01 2003 From: hal@REDACTED (Hal Snyder) Date: Wed, 22 Oct 2003 18:49:01 -0500 Subject: SNMP MIB-2 tables in Erlang? In-Reply-To: (Luke Gorrie's message of "22 Oct 2003 15:21:35 +0200") References: Message-ID: <874qy0bzpu.fsf@ghidra.vail> Luke Gorrie writes: > We're adding support for some standard SNMP MIBs to our Linux boxes: > interfaces, IP statistics, routing table, etc. > > I'm thinking about doing it with the Erlang SNMP agent instead of > using an existing implementation, in the name of having better > customization hooks. Has anyone already done something similar? If so > please give me a yell. We put stats into mnesia tables for distribution + SNMP monitoring. Here's a cookbook from our last go-round with it, including sample MIB. Hope it helps. Making a Mnesia Table SNMP Accessible http://www.drxyzzy.org/mnesia-snmp/index.html From spearce@REDACTED Thu Oct 23 02:19:41 2003 From: spearce@REDACTED (Shawn Pearce) Date: Wed, 22 Oct 2003 20:19:41 -0400 Subject: Language change proposal In-Reply-To: <3F970CBB.2050205@web.de> References: <20031022092925.6115a375.cpressey@catseye.mine.nu> <3F970CBB.2050205@web.de> Message-ID: <20031023001941.GA19180@spearce.org> Although a very slick idea, I think it would lead to much confusion about why code was eliminated from the if statement. Reading that code one might reasonably expect to be able to compile it with version 5_3 and have it run the first group on 5_3, but the same module binary would use different code on 5_2. Too confusing. If an application really MUST split into different code based on different language versions, use different 'inner' modules. Define functions in those modules which implement the given required feature X on each language version, or have feature X throw/exit an error if the platform cannot perform it. Each 'inner' module can get compiled with the proper version(s) of language, runtime, 3rd party libs, etc. The more generic code which doesn't care about versions can be compiled with the most current, and get warnings/deprecation errors as necessary. I liked the -module(mod, "5.3"). syntax, as it offers a nice way to determine the "format" of the file before any other attributes might be set. This might help an attribute linter, etc. It would also be nice to be able to do: -module(mod). and: erlc -assume_version 5.3 *.erl to compile across an entire project without needing to set the version in every header. But really I think that putting the version number in all new files, and having the compiler assume 5.2 for those that don't have a version number is reasonable. How hard is it really to put the version number of the langauge / runtime you are targeting into the header of a module when you write that module? It certainly makes it clear what might be the required version to make the silly thing work properly. It might also be nice to define other dependencies such as: -require(stdlib, "5.3"). to indicate that this module would need a version of stdlib that understand the calls available in version 5.3 of stdlib. If version 6.8 of stdlib is loaded, but it understands the 5.3 calls, then all is good. If however the currently loaded version of stdlib (6.8) does not understand 5.3 calls then the code server should refuse to load this module. (It might have loaded it, checked M:module_info/1, then unloaded it when discovering this problem.) This would let a developer concisely code his expectations about the versions of things he/she is using within their code, and make that available to the OTP release handler, as well as linters, etc. Joachim Durchholz wrote: > However, there's one thing that /could/ be done: add an erlang_version > predicate that's guaranteed to be evaluated at compile time. Also, add > some rules about compile-time evaluation for expressions "known to be > constant" (these can be very simplicistic, look at the rules for Turbo > Pascal, for example). > > With that, you can write stuff like (excuse the non-Erlang syntax here, > I've still not gotten around to making my ankles wet...) > > if erlang_version = "5_3" > % some code that uses bleeding-edge features here > else > if erlang_version = "5_2" > % some code that uses 5.2-isms here > else > some code that is dangerously language-version-unspecific here > endif > endif > > Regards, > Jo > -- Shawn. From cpressey@REDACTED Thu Oct 23 03:01:15 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 22 Oct 2003 18:01:15 -0700 Subject: Language change proposal In-Reply-To: <3F970CBB.2050205@web.de> References: <20031022092925.6115a375.cpressey@catseye.mine.nu> <3F970CBB.2050205@web.de> Message-ID: <20031022180115.7b4218f6.cpressey@catseye.mine.nu> On Thu, 23 Oct 2003 01:03:23 +0200 Joachim Durchholz wrote: > Chris Pressey wrote: > > It's a good idea, but wouldn't it be easier to write code that works > > on different versions if it was done with macros, e.g. > > [...] > > Most definitely *no*. > I have maintained C code that went like this; it was a nightmare. The > reason was that it offered too many opportunities for "clever writing" > like this: > > if (normal condition) { > ... > #ifdef VERSION = xxx > ... > } else { > ... > #else > ... > } else { > ... > #endif > ... > } Well, you don't have to worry about that, since you can't write that kind of code in Erlang. -ifdef() and friends cannot appear inside a function definition. -Chris From hal@REDACTED Thu Oct 23 06:29:49 2003 From: hal@REDACTED (Hal Snyder) Date: Wed, 22 Oct 2003 23:29:49 -0500 Subject: building erl interface libs only Message-ID: <87ekx4r2yq.fsf@ghidra.vail> Maybe there is an easier way to do it, but I didn't see the desired option in otp_build... In case anyone wants to build only the C interface libraries for Erlang/OTP, I put the incantations (and the patch we're using) at http://www.drxyzzy.org/ei-only/ei-only.html From vlad_dumitrescu@REDACTED Thu Oct 23 08:37:32 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 23 Oct 2003 08:37:32 +0200 Subject: Language change proposal References: <20031022092925.6115a375.cpressey@catseye.mine.nu> <3F970CBB.2050205@web.de> <20031023001941.GA19180@spearce.org> Message-ID: From: "Shawn Pearce" > If an application really MUST split into different code based on > different language versions, use different 'inner' modules. > Define functions in those modules which implement the given required > feature X on each language version, or have feature X throw/exit an error if > the platform cannot perform it. I think this might be nicest, but it is a matter of taste. > It might also be nice to define other dependencies such as: > > -require(stdlib, "5.3"). > > to indicate that this module would need a version of stdlib that understand > the calls available in version 5.3 of stdlib. Mmm, wouldn't there be confusions with the stdlib application's version? After all, as user of stdlib, I don't care what it's using inside, just what interfaces it has. So in this case i'd expect to check stdlib's version - but if things are going to be added and deprecated and removed, after 3-4 passes it might become quite difficult to find out which versions will work and which ones don't. regards, Vlad From francesco@REDACTED Thu Oct 23 09:00:17 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Thu, 23 Oct 2003 08:00:17 +0100 Subject: Try/Cond References: Message-ID: <3F977C80.6050706@erlang-consulting.com> > > > What - you're nuts > It is pretty well known ;-) >>With the introduction of OTP in 1996, I have never seen anyone use exit >>in their code. The few catches and throws I came across were easily >>rewritten into a more purely functional style. >> >> > > My code has loads of exits. > In other threads, it was pretty much agreed that, even if pretty, your code differed from the norm. :-p It would be a consultant's dream to have 40 programmers, each terminating their behaviors with different reasons, starting to make strange checks and handling error cases that will never occur. > The golden rule is "let it crash" - quite often code will crash >with a less-than-helpful (TM) diagnostic. Here I always write > > exit(<>) > Of course, let it crash. But instead of exits, I prefer to just handle positive cases. If you know an element will be in a list, {value, Element} = lists:keysearch/3 should suffice. Others, depending on their background, would have code handling lots of estranged weird cases that should never occur, for the sake of 'Just in case the data is corrupted'. Data shouldn't be, so don't worry about it. (The best examples are from a project where the bonus was based on the number of bugs in the code, and people interpreted a bug as having their process crash, even if it was not their fault). > There is no way of getting a non-local return from a function if you >do not use catch and throw. > Of course, as was mentioned yesterday, the main usage is when handling unreliable input in deeply nested functions, e.g. parsing. Other than that, it makes the code very hard to understand and debug. That, because the errors occur when they are used as a replacement to gotos, used across modules, and not with extreme care. > Pleeeese teach you students the correct way to use catch/throw/exit - >this will lead to much cleaner code than if they try religiously to avoid their use. > I do (After all, you were the one who brain washed me into writing pretty understandable code :-p). Based on design guidelines, experience, and their individual ability to grasp what I am explaining, this will have to vary the depth in which we cover the subjects. Got to go! The men in the green shirts are knocking on the door. Regards, Francesco -- http://www.erlang-consulting.com From peter@REDACTED Thu Oct 23 11:26:07 2003 From: peter@REDACTED (Peter Lund) Date: Thu, 23 Oct 2003 10:26:07 +0100 (BST) Subject: Try/Cond Message-ID: <7513.149.254.120.136.1066901167.squirrel@www.lundata.se> Richard wrote: > On the other hand, there are lots of small things that have > been done with the language by the Erlang/OTP folks in the > last 5 years since the draft standard, which have simply been > presented in the "highlights" of each new release, without ever > being discussed on the erlang-questions list, for better or for > worse. You have to realise that although being Open Source, > there is in fact only one full implementation of Erlang, and it > is maintained and developed by OTP. I agree that the OTP team needs to at the end make their "own" deci- sions about what to include and not to include, since they actually have to put together new releases of Erlang/OTP. But it is preferable that also they at an early stage present their ideas for changes to everyone. If we acheive some good degree of consensus before changing the language, the risk is reduced that erlang splits up into different distributions and different dialects at some later stage... /Peter From mbj@REDACTED Thu Oct 23 12:14:13 2003 From: mbj@REDACTED (Martin Bjorklund) Date: Thu, 23 Oct 2003 12:14:13 +0200 (CEST) Subject: heart anyone? In-Reply-To: <3F8F8F01.9020800@erlang-consulting.com> References: <3F8F8F01.9020800@erlang-consulting.com> Message-ID: <20031023.121413.10549720.mbj@bluetail.com> Francesco Cesarini wrote: > > > Dear Erlangers, > > before I head off to reinvent the wheel, I was wondering if any one has > implemented their own version of heart. What we are looking for is a > behaviour similar to the supervisor one, where you can allow a maximum > of X local restarts of the beam emulator in Y seconds. Possibly after X > restarts, the OS is rebooted, erlang started up again, and if it > crashes, the whole system just stops. Needless to say cyclic restarts > have been a problem.. > > Any other thoughts on heart are welcome. Past problems, praises, horror > stories, et all. Yes, we do this, but there's no need to hack heart. Instead we do what we have to do in the HEART_COMMAND, i.e. the command that heart calls when the node goes down. This command is a shell script which first checks if we've rebooted too many times, and if so gives up. Otherwise erlang is started. It shouldn't be difficult to also do a OS reboot here. Here's the interesting part of that script: # # Execute this function to make # sure that we don't get into a reboot cycle. If we # reboot more than 6 times, each time less than 20 # minutes since the last reboot, we give up, and # don't try to reboot again. # Use this function only if heart is used and we're # rebooting on the permenanent release. # In case of a safe restart (i.e. not in the reboot # interval) remove the reboot file used by isdstart. # check_reboot() { Restarts=0; Timestamp=`timestamp`; Month=`month`; ExternalRebootFile=$dir/reboot.isd if [ -w $RebootFile ]; then LastTimestamp=`awk '{print $1}' $RebootFile`; LastMonth=`awk '{print $2}' $RebootFile`; Restarts=`awk '{print $3}' $RebootFile`; Diff=`expr $Timestamp - $LastTimestamp`; if [ "$Month" = "$LastMonth" ]; then if [ $Diff -lt $Timespan ]; then # We rebooted too early if [ $Restarts -ge $MaxRestarts ]; then # We rebooted too early too many times - give up echo "`date`: Too many reboots - giving up" >> $LogFile; # Keep RebootFile as we otherwise removes ExternalRebootFile # the next time started. echo "$Timestamp $Month 0" > $RebootFile; exit 0; fi Restarts=`expr $Restarts + 1`; else Restarts=0; fi else Restarts=0; fi fi if [ $Restarts = 0 -a -w $ExternalRebootFile ]; then # We rebooted outside the reboot interval rm $ExternalRebootFile; fi echo "$Timestamp $Month $Restarts" > $RebootFile; exit 1; } timestamp() { D=`date '+%d'`; H=`date '+%H'`; M=`date '+%M'`; expr $D \* 1440 + $H \* 60 + $M } month() { date '+%y%m' } /martin From kostis@REDACTED Wed Oct 22 23:55:51 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 22 Oct 2003 23:55:51 +0200 (MEST) Subject: Another HiPE bug? In-Reply-To: Mail from 'David Wallin ' dated: Wed, 22 Oct 2003 18:08:38 +0100 Message-ID: <200310222155.h9MLtpgf029097@harpo.it.uu.se> David Wallin wrote: > > A binary consisting of an even number of ones is taken as argument. A > randomly picked bit is flipped and the new binary returned. As shown > below, this is not the case (the input in this case is > <<2#00000011>>). I also tried with other inputs and the result was > always <<192>> when compiled with HiPE. > We confirm this bug. It is related to the construction of binaries with variable-sized segments. A minimal example that shows the problem is: construct(S) -> <<42:S>>. In BEAM the call construct(8) returns <<42>> as it should. In native code, it returns <<192>>. Apparently, this only affects the first segment of the binary... Thanks for this report. We'll look into this. Kostis Sagonas. PS. Your previous bug report is actually a problem in the loader and requires help from the OTP team to be fixed... It is due to the magic that the BEAM loader performs to create the code for module_info/* when loading a .beam file. A simple way to get around it, is to change the line that reads: Info = module_info(), to be: Info = apply(?MODULE, module_info, []), Amazing how easily you can fool the BEAM compiler, isn't it? From ulf.wiger@REDACTED Thu Oct 23 13:41:37 2003 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Thu, 23 Oct 2003 13:41:37 +0200 Subject: Try/Cond Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F540257D@ESEALNT442.al.sw.ericsson.se> From: Francesco Cesarini [mailto:francesco@REDACTED] >> There is no way of getting a non-local return from a function if you >>do not use catch and throw. >> >Of course, as was mentioned yesterday, the main usage is when handling >unreliable input in deeply nested functions, e.g. parsing. Other than >that, it makes the code very hard to understand and debug. That, because >the errors occur when they are used as a replacement to gotos, used >across modules, and not with extreme care. Personally, I practically never use catch and throw (well, I may use catch every once in a while, but only related to exits, not throw. Non-local return *is* possible without throw. I've mentioned before a side project of mine, where I generate a recursive- descent parser from a yecc grammar. There, I use a backtracking fun to break out of a path as soon as I find that it doesn't match. Example (simplified): try_rule([Rule|Rs], Tokens, MatchF, BackF, Result, S) -> NewMatchF = fun(X, Ts1, S1) -> %% so far so good, continue try_rule(Rs, Ts1, Match, Back, set_var(X,Result), S1) end, (S#state.module):Pattern(Tokens, NewMatchF, BackF, Result, S); try_rule([], Tokens, MatchF, BackF, Result, S) -> %% no more rules to test -- we have a match. MatchF(Result, Tokens, S). match_rules([], Tokens, BackF, Result, S) -> %% no branches matched -- backtrack. Back(); ... match_rules([{RulePrefix, Branches}|Rules], Tokens, BackF, Result, S)... -> NewBackF = fun() -> %% wrong track -- try the next rule match_rule(Rules, Tokens, BackF, Result, S) end, NewMatchF = fun(X, Ts1, S1) -> %% a match -- continue down this path. NewResult = set_var(X, Result), match_rules(Branches, Ts1, NewBackF, NewResult, S1) end, (S#state.module):RulePrefix(Tokens, NewMatchF, NewBackF, S). This has the (big) advantage of avoiding deep recursion in the emulator. Logically, we're still doing the same thing, but this is more efficient (except, it would seem, in Hipe, for unknown reasons). Basically, for each step, you define two closures (or reuse the ones that were passed to you): one to call when we know that we have a match, and one to call when we know that we're on the wrong track. One could of course argue that it's less intuitive than catch/throw. /Uffe From Chandrashekhar.Mullaparthi@REDACTED Thu Oct 23 14:21:35 2003 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Thu, 23 Oct 2003 13:21:35 +0100 Subject: Language change proposal Message-ID: Hi, > -----Original Message----- > From: Joe Armstrong [mailto:joe@REDACTED] > Sent: 22 October 2003 12:27 > To: erlang-questions@REDACTED > Subject: Language change proposal > > > > Hi everybody - I'd like to propose the following language change: > > (It's *very* easy to implement) > > I want all Erlang modules to be tagged with a "language version" > > Like this ... > > -------------------------------------------------------------- > ---------- > > Suppose the next version of Erlang is 5.3 then: > > 1) All modules *must* start > > -module(XXXX). > -vsn("5.3"). I don't know how useful this will be. Isn't it enough if we extend the syntax of the .app file to specify this. After all, the smallest component which is *shipped* is an application. {application, Application, [{description, Description}, {vsn, Vsn}, {id, Id}, {modules, [Module1, .., ModuleN]}, {maxT, MaxT}, {registered, [Name1, .., NameN]}, {applications, [Appl1, .., ApplN]}, {included_applications, [Appl1, .., ApplN]}, {env, [{Par1, Val1}, .., {ParN, ValN}]}, {mod, {Module, StartArgs}}, {start_phases, [{Phase1, PhaseArgs1}, .., {PhaseN, PhaseArgsN}]}]}. We can include an extra tag here which specifies the version of ERTS required. This should be optional. As in {erts_vsn, ErtsVsn} where ErtsVsn = {minimum, "5.3"} | {only, "5.3"} ?? The .rel file already requires that the version of ERTS be specified and is strictly enforced when a system is being built. In another email, you wrote: > I also *hate* stuff that is hidden away in version control software - > I much prefer explicit versioning in the code where I can read it - > Stuff which is hidden in CVS/clearcase etc. often prevents a module > from having a life of it's own outside the versioning tool ... I can't comment about clear case, but in CVS, if the version in the module is specified as -vsn('$Id: $ '). When the code is checked in, the $Id: $ is translated to -vsn('$Id: dl_parse.erl,v 1.10 2003/06/19 10:58:32 chandru Exp $ '). which is visible in dl_parse:module_info(). 5> dl_parse:module_info(). [{exports,[{is_vcard,1}, {parse_vcard,1}, {parse_command,1}, {many_to_rest,1}, {module_info,0}, {module_info,1}]}, {imports,[]}, {attributes,[{author,[chandru@REDACTED]}, {vsn,['$Id: dl_parse.erl,v 1.10 2003/06/19 10:58:32 chandru Exp $ ']}]}, {compile,[{options,[v3]},{version,"4.1"},{time,{2003,10,23,11,54,5}}]}] cheers Chandru NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From joe@REDACTED Thu Oct 23 16:53:12 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 23 Oct 2003 16:53:12 +0200 (CEST) Subject: Try/Cond In-Reply-To: <3F977C80.6050706@erlang-consulting.com> Message-ID: On Thu, 23 Oct 2003, Francesco Cesarini wrote: > > > > > > What - you're nuts > > > It is pretty well known ;-) It was a complement :-) > > >>With the introduction of OTP in 1996, I have never seen anyone use exit > >>in their code. The few catches and throws I came across were easily > >>rewritten into a more purely functional style. > >> ... cut ... On mature refelection there might be a case for being restrictive with catches and throws but never with exits - let's suppose you write last to compute the last element of a list. You might write it like this: last([_|T]) -> last(T); last([H]) -> H. This version works because you "know" that 1) It's dingo dongo stupid to ask for the last element of an empty list 2) last([]) will fail with a pattern matching error and 3) any process that asks for the last element of an empty list is wayo damaged beyond control and should be killed But all of this is *implicit* knowledge. When you read code like this my brain automatically wonders -- wonder why there is no base case for the recursion - I wonder if the programmer forgot it (actually a type system will go though the same kind of reasoning as well, so it's not a bad idea to be explicit). If you write it like this: last([_|T]) -> last(T); last([H]) -> H; last([]) -> exit(emptyListsDoNotHaveLastElementYourProgramIsNuts). The you will at least know that the programmer had thought about it. You could do this with an appropriate comment instead last([_|T]) -> last(T); last([H]) -> H. %% YIKYDHTTM > > Got to go! The men in the green shirts are knocking on the door. > There you go - /Joe From ulf.wiger@REDACTED Thu Oct 23 17:06:27 2003 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Thu, 23 Oct 2003 17:06:27 +0200 Subject: Try/Cond Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5402581@ESEALNT442.al.sw.ericsson.se> -----Original Message----- From: Joe Armstrong [mailto:joe@REDACTED] > You might write it like this: > > last([_|T]) -> last(T); > last([H]) -> H. > > This version works because [...] Errm... actually, it doesn't work, Joe. ;-) /Uffe From joachim.durchholz@REDACTED Fri Oct 24 02:03:46 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Fri, 24 Oct 2003 02:03:46 +0200 Subject: Try/Cond In-Reply-To: References: Message-ID: <3F986C62.3010807@web.de> Joe Armstrong wrote: > > When you read code like this my brain automatically wonders -- > wonder why there is no base case for the recursion - I wonder if the programmer > forgot it (actually a type system will go though the same kind of > reasoning as well, so it's not a bad idea to be explicit). > > If you write it like this: > > > last([_|T]) -> last(T); > last([H]) -> H; > last([]) -> exit(emptyListsDoNotHaveLastElementYourProgramIsNuts). > > The you will at least know that the programmer had thought about it. Besides, Haskell does it that way, too, so it can't be entirely nuts to have an idiom like this :-) Regards, Jo From spearce@REDACTED Fri Oct 24 02:01:25 2003 From: spearce@REDACTED (Shawn Pearce) Date: Thu, 23 Oct 2003 20:01:25 -0400 Subject: Language change proposal In-Reply-To: References: <20031022092925.6115a375.cpressey@catseye.mine.nu> <3F970CBB.2050205@web.de> <20031023001941.GA19180@spearce.org> Message-ID: <20031024000125.GA19935@spearce.org> Vlad Dumitrescu wrote: > > It might also be nice to define other dependencies such as: > > > > -require(stdlib, "5.3"). > > > > to indicate that this module would need a version of stdlib that understand > > the calls available in version 5.3 of stdlib. > > Mmm, wouldn't there be confusions with the stdlib application's version? After > all, as user of stdlib, I don't care what it's using inside, just what > interfaces it has. So in this case i'd expect to check stdlib's version - but if > things are going to be added and deprecated and removed, after 3-4 passes it > might become quite difficult to find out which versions will work and which ones > don't. I think what I was trying to point out was the version number concept being tossed about is used to specify what _interface_ version this module requires to compile and run properly. If we were to state that a module required ERTS 5.3, and the language support that was available in 5.3, surely we would also expect the stdlib module to have all functions which were documented in the 5.3 release manuals. Now fast foward 3 years, a function has been removed from stdlib. stdlib in ERTS 8.3 no longer fully implements the interface which was available in 5.3. The code server should refuse to load my module which depends on stdlib 5.3 as my module might not work properly. However, who makes the decision that stdlib no longer supports the 5.3 interface is up to stdlib's developers, not me or my module. stdlib should be queried by the code server to see if it can handle interface 5.3, which is associated with the module by the 'require' attribute. I think this might get coded as something like this: -module(stdlib, "8.3"). % Needs 8.3 ERTS. module_interface_version(Major, Minor) -> if Major >= 8 and Minor <= 3 -> ok; % Version 7.6 introduced kill_foo, a bad idea now gone. % All other 7.x is ok. Major = 7 and Minor = 6 -> {not_supported, [kill_foo]}; Major = 7 -> ok; % Version 6.8 introduced kill_pid, replaced by exit_pid in 6.9. % All other 6.x is still supported. Major = 6 and Minor = 8 -> {not_supported, [kill_pid]}; Major = 6 -> ok; % We're amazingly still compatible with 5.0 and 5.1. Major = 5 and Minor =< 1 -> ok; % No other interface version is supported. true -> not_supported; end. This is better, IMHO, to putting the required VSN in the app release file as the API required is used in this module. The compiler, code loader or linter can check to see who is using the deprecated (or flat out removed) API and lead the developer in the right direction. When a module is modified to be brought current, its VSN can be updated at the same time its API usage sites are updated and tested. Now if there is a good linter that can determine what is deprecated/removed (or not available in an older version), and do this by reading the VSN from the app release file, maybe that's an acceptable way to go. -- Shawn. From ok@REDACTED Fri Oct 24 03:19:58 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 24 Oct 2003 14:19:58 +1300 (NZDT) Subject: Slightly OT: static typing Message-ID: <200310240119.h9O1JwsD312086@atlas.otago.ac.nz> Michael Hobbs asked about R.P.Gabriel's "Objects Have Failed". I pointed out that reuse is actually very successful. Joachim Durchholz replied: Right, but this reuse isn't happening in an OO fashion... so, reuse has failed /for OO/ (which is, after all, his point), and has worked for the standard "structured programming" approach. Reuse is working *in* OO languages; it's not clear to me that it makes any practical sense to say that it "has failed /for OO/" when it is blatantly working well *in* OO. It is very clear to me that reuse in R (one of my examples) *DOES* depend on R's OO features. While I personally loathe and detest Java (but less than half as much as I loathe and detest C++) it would not have been possible to build up the large library available for Java if the designers hadn't done _something_ right. The better (Smalltalk, Eiffel, CLOS, Dylan) and even the marginally tolerable (Java) OO languages are at least workable structured programming languages. And while unit testing and "refactoring" are things that people have been doing for 50 years, I don't believe that it is an accident that SUnit and the Refactoring Browser were invented in and for Smalltalk. (The SUnit idea has been applied to a bunch of other languages, but most if not all of them OO to a greater or lesser degree.) Such tools definitely make it easier to produce code that has been reused (RB) and is worth reusing (SUnit). This does actually bring us back to Erlang. Some of the things that the better OO languages rely on which has these good results are actually Lispy things. Smalltalk is really _very_ like Lisp in many ways. So is Erlang. It's quite possible that the SUnit and RB ideas could be adapted to Erlang in interesing ways. From ok@REDACTED Fri Oct 24 04:42:49 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 24 Oct 2003 15:42:49 +1300 (NZDT) Subject: Language change proposal Message-ID: <200310240242.h9O2gngS431493@atlas.otago.ac.nz> Chris Pressey suggested: It's a good idea, but wouldn't it be easier to write code that works on different versions if it was done with macros, e.g. -ifdef(?ERLANG_5_3). [snip] -endif. I think this would be the way to go if you wanted to write code that takes advantage of new features while still being able to compile and run on older installations. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH! Someone please tell me this was a late April Fools' joke? If would be nice if people finally understood why the Ada requirements explicitly required that there *NOT* be a preprocessor or conditional compilation facility... From ok@REDACTED Fri Oct 24 05:26:42 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 24 Oct 2003 16:26:42 +1300 (NZDT) Subject: Language change proposal Message-ID: <200310240326.h9O3Qges432539@atlas.otago.ac.nz> -module(stdlib, "8.3"). % Needs 8.3 ERTS. I hate this syntax, because it is so obviously declaring the version of THIS module, not the version of Erlang. Any method of declaring the version of the Erlang language that is required should ideally have *erlang* in the name so that it is obvious what it is the version *of*. For example, -erlang([8,3,10]). % Erlang 8.3J or later -module(thingy, [10,2,27]). % This is thingy version 10.2.27 ... Like an XML declaration, this should go first. A revised Erlang language might not even use -module for declaring modules; some day we might see -erlang([10,1]). module StdLib ( foo/1, bar/2 ) where ... (with apologies to Haskell). From ulf.wiger@REDACTED Fri Oct 24 09:52:36 2003 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 24 Oct 2003 09:52:36 +0200 Subject: Try/Cond In-Reply-To: <3F986C62.3010807@web.de> References: <3F986C62.3010807@web.de> Message-ID: On Fri, 24 Oct 2003 02:03:46 +0200, Joachim Durchholz wrote: > Joe Armstrong wrote: >> >> When you read code like this my brain automatically wonders -- >> wonder why there is no base case for the recursion - I wonder if the >> programmer >> forgot it (actually a type system will go though the same kind of >> reasoning as well, so it's not a bad idea to be explicit). >> >> If you write it like this: >> >> >> last([_|T]) -> last(T); >> last([H]) -> H; >> last([]) -> exit(emptyListsDoNotHaveLastElementYourProgramIsNuts). >> >> The you will at least know that the programmer had thought about it. > > Besides, Haskell does it that way, too, so it can't be entirely nuts to > have an idiom like this :-) Personally, I prefer the (working) version: last([]) -> H; last([_|T]) -> last(T). And if it's not obvious from the overall programming style in the module that I'm describing the correct cases only and relying on the standard error, I would prefer to insert a comment: %% This function will crash if called with anything but a non-empty list last([]) -> H; last([_|T]) -> last(T). In my experience, from working in a huge software system, the standard crash reports are usually good enough, and custom exit reasons usually only serve to confuse the audience. There is a lot to be said about consistency in large projects... (: -- Ulf Wiger From mbj@REDACTED Fri Oct 24 10:02:27 2003 From: mbj@REDACTED (Martin Bjorklund) Date: Fri, 24 Oct 2003 10:02:27 +0200 (CEST) Subject: Try/Cond In-Reply-To: References: <3F986C62.3010807@web.de> Message-ID: <20031024.100227.98650398.mbj@bluetail.com> Ulf Wiger wrote: > Personally, I prefer the (working) version: ^^^^^^^^^ > > last([]) -> H; > last([_|T]) -> last(T). hehe :) /martin From vances@REDACTED Fri Oct 24 15:29:06 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 24 Oct 2003 09:29:06 -0400 Subject: Try/Cond In-Reply-To: References: <3F986C62.3010807@web.de> Message-ID: <20031024132906.GA11958@frogman.motivity.ca> last(List) -> B = list_to_binary(List), S = size(B) - 8, <<_:S, Last:8>> = B, Last. :) From luke@REDACTED Fri Oct 24 15:52:29 2003 From: luke@REDACTED (Luke Gorrie) Date: 24 Oct 2003 15:52:29 +0200 Subject: Try/Cond In-Reply-To: <20031024132906.GA11958@frogman.motivity.ca> References: <3F986C62.3010807@web.de> <20031024132906.GA11958@frogman.motivity.ca> Message-ID: Vance Shipley writes: > last(List) -> > B = list_to_binary(List), > S = size(B) - 8, > <<_:S, Last:8>> = B, > Last. or of course last(L) -> (foldl(fun(X, _) -> fun() -> X end end, [], L))(). -Luke From Bengt.Kleberg@REDACTED Fri Oct 24 11:07:38 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Fri, 24 Oct 2003 11:07:38 +0200 Subject: Language change proposal In-Reply-To: <20031022092925.6115a375.cpressey@catseye.mine.nu> References: <20031022092925.6115a375.cpressey@catseye.mine.nu> Message-ID: <3F98EBDA.9000300@ericsson.com> Chris Pressey wrote: ...deleted > It's a good idea, but wouldn't it be easier to write code that works on > different versions if it was done with macros, e.g. > > -ifdef(?ERLANG_5_3). > % some code that uses bleeding-edge features here > -else. > -ifdef(?ERLANG_5_2). > % some code that uses 5.2-isms here > -else. > % some code that is dangerously language-version-unspecific here > -endif. > -endif. > please do not allow this into erlang. i have maintained (somebody elses) c code which used #ifdef, and i promised myself never to do that again. bengt From wolfoxbr@REDACTED Fri Oct 24 15:54:57 2003 From: wolfoxbr@REDACTED (Roberto Amorim) Date: Fri, 24 Oct 2003 11:54:57 -0200 Subject: Try/Cond References: <3F986C62.3010807@web.de> <20031024.100227.98650398.mbj@bluetail.com> Message-ID: > > Personally, I prefer the (working) version: > ^^^^^^^^^ > > > > last([]) -> H; > > last([_|T]) -> last(T). I like this one: last([H|T]) -> case T of [] -> H; _ -> last(T) end; last([]) -> 'whatever you want'. Regards, Roberto From Bengt.Kleberg@REDACTED Fri Oct 24 11:04:38 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Fri, 24 Oct 2003 11:04:38 +0200 Subject: Language change proposal In-Reply-To: References: Message-ID: <3F98EB26.3060108@ericsson.com> Joe Armstrong wrote: ...deleted > - A new version of the language turns up - with the 'try' statement. > - I write a program using 'try' and use the latest compiler > - I post my program to the net > - I get mail saying that my program is ****ed up because it > won't go through some old version of the compiler that was released > before version numbering was introduced. > > This has already happened to me on several occasions - I have sent people > program that use binaries - only to find that they are using a > "pre-binaries" Erlang. ...deleted would it not be true to say that you have written atleast one program that have the opposite problem? using www_tools-1.0.tgz i had to update the tcp code to R7. i would also like to thank you for this module since it made it possible to do what i wanted to do. bengt From Bengt.Kleberg@REDACTED Fri Oct 24 10:59:06 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Fri, 24 Oct 2003 10:59:06 +0200 Subject: Language change proposal In-Reply-To: References: Message-ID: <3F98E9DA.3050408@ericsson.com> WILLIAMS Dominic wrote: ...deleted > 2) Functions would be deprecated by adding an obsolete attribute that > would list obsolete functions in the same format as export/import: > > -module(my_module). > -export([a/1,b/2,c/3]). > -obsolete([b/2]). > the eiffel keyword ''obsolete'' has an argument that explains what alternatives there are, instead of the obsolete feature. perhaps somehting like this (yes, i know this makes it impossible to obsolete a whole slew of functions in one go. but see my second example for an alternative): -module(my_module). -export([a/1,b/2,c/3]). -obsolete(b/2, "use c/2 instead"). moreover, eiffel can obsolete a whole class. which could be quite handy: -module(my_module). -obsolete("use my_other_module instead"). bengt From cpressey@REDACTED Fri Oct 24 18:53:21 2003 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 24 Oct 2003 09:53:21 -0700 Subject: Language change proposal In-Reply-To: <200310240242.h9O2gngS431493@atlas.otago.ac.nz> References: <200310240242.h9O2gngS431493@atlas.otago.ac.nz> Message-ID: <20031024095321.104f5294.cpressey@catseye.mine.nu> On Fri, 24 Oct 2003 15:42:49 +1300 (NZDT) "Richard A. O'Keefe" wrote: > Chris Pressey suggested: > It's a good idea, but wouldn't it be easier to write code that > works on different versions if it was done with macros, e.g. > > -ifdef(?ERLANG_5_3). > [snip] > -endif. > > I think this would be the way to go if you wanted to write code > that takes advantage of new features while still being able to > compile and run on older installations. > > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH! Gee Richard A. O'Keefe, you sound a bit stressed. Maybe you should make yourself a nice hot cup of peppermint tea and re-read my "suggestion" (as you call it) paying closer attention to how I used the word "if". > Someone please tell me this was a late April Fools' joke? Let me put it this way: if it's easy to tell when I'm being serious and when I'm not, I'm not doing my job. I AM a Bishop, after all. > If would be nice if people finally understood why the Ada requirements > explicitly required that there *NOT* be a preprocessor or conditional > compilation facility... Yes, it would be nice. I think I've done my part by understanding it fairly well. However, I'm also not very optimistic about seeing invariant expressions in Erlang any time soon. Ah, but the rivers of the Erlang support list are choked with the bodies of keyboard-pounding language designers, are they not? Guardians of Truth and Beauty, each and every one of us, who do not seem to realize that Erlang is not a project in pursuit of perfect language purity. It is, in fact, an exercise in return-on-investment (right, Mr. Ericsson?) And defining a new predefined macro is just about as small an investment there is. Take it one small step further and add -assert() to -ifdef() and friends, and I for one have a hard time explaining the difference between -requires_erlang('5.3'). and -assert(?ERLANG_VERSION, '5.3'). in terms that the average non-language-designing Erlang programmer would appreciate or care about. So it would seem to me that this small investment gets a comparable return. Perhaps even a greater one, when you consider the same -assert() mechanism can be used for any other macro already in use, predefined (like ?MACHINE) or otherwise. So there you have a plausible case for using macros. Of course, if you think that just because I can make that case means that that's the way I truly feel, you're a bigger sucker than I thought. -Chris From cpressey@REDACTED Fri Oct 24 18:55:27 2003 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 24 Oct 2003 09:55:27 -0700 Subject: Language change proposal In-Reply-To: <3F98EBDA.9000300@ericsson.com> References: <20031022092925.6115a375.cpressey@catseye.mine.nu> <3F98EBDA.9000300@ericsson.com> Message-ID: <20031024095527.1eddfc7f.cpressey@catseye.mine.nu> On Fri, 24 Oct 2003 11:07:38 +0200 Bengt Kleberg wrote: > Chris Pressey wrote: > ...deleted > > It's a good idea, but wouldn't it be easier to write code that works on > > different versions if it was done with macros, e.g. > > > > -ifdef(?ERLANG_5_3). > > % some code that uses bleeding-edge features here > > -else. > > -ifdef(?ERLANG_5_2). > > % some code that uses 5.2-isms here > > -else. > > % some code that is dangerously language-version-unspecific here > > -endif. > > -endif. > > > > please do not allow this into erlang. It's too late - it's already there! THE HORROR THE HORROR > i have maintained (somebody elses) c code which used #ifdef, and i > promised myself never to do that again. OOC, were you using a syntax-colouring editor at the time? -Chris From luke@REDACTED Fri Oct 24 19:07:46 2003 From: luke@REDACTED (Luke Gorrie) Date: 24 Oct 2003 19:07:46 +0200 Subject: Language change proposal In-Reply-To: <3F98EBDA.9000300@ericsson.com> References: <20031022092925.6115a375.cpressey@catseye.mine.nu> <3F98EBDA.9000300@ericsson.com> Message-ID: Bengt Kleberg writes: > i have maintained (somebody elses) c code which used #ifdef, and i > promised myself never to do that again. They have this in Common Lisp too. The other week I was trying to understand a single function that was 170 lines long and contained no fewer than 43 ifdef-style conditionals. "Not very nice." By the way, I've found a really fun new way of inspecting programs: http://groups.google.com/groups?q=teleport.el&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=lhoexds818.fsf%40dodo.bluetail.com&rnum=1 (Joe, I think you might like it :-)) Cheers, Luke (who'd be remiss not to mention Emacs `hide-ifdef' mode, for when you need to read heavily ifdef'ified C) From enewhuis@REDACTED Fri Oct 24 20:55:52 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 24 Oct 2003 13:55:52 -0500 Subject: Constant Time ETS Ordered Set Get Largest-Keyed Member ? Message-ID: <3F9975B8.5020702@futuresource.com> O Great ETS Masters, Is there a "constant time" ETS ordered set get largest-keyed member function, technique, or trick? I want to retreive the last member of the ordered set, the one with the largest valued key, often enough to justify building a separate ETS index table. My code would be simpler, however, of course, if I could avoid the extra ETS table. In C++, with a heavy dose of the Standard C++ Library containers, I'd probably do this with the "reverse end" member of a map<>. Sincerely, Eric Newhuis From sean.hinde@REDACTED Fri Oct 24 21:42:21 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Fri, 24 Oct 2003 20:42:21 +0100 Subject: Constant Time ETS Ordered Set Get Largest-Keyed Member ? In-Reply-To: <3F9975B8.5020702@futuresource.com> Message-ID: <2F61141A-065A-11D8-8A54-000A95927CCE@mac.com> On Friday, October 24, 2003, at 07:55 pm, Eric Newhuis wrote: > O Great ETS Masters, > > Is there a "constant time" ETS ordered set get largest-keyed member > function, technique, or trick? > > I want to retreive the last member of the ordered set, the one with > the largest valued key, often enough to justify building a separate > ETS index table. My code would be simpler, however, of course, if I > could avoid the extra ETS table. > > In C++, with a heavy dose of the Standard C++ Library containers, I'd > probably do this with the "reverse end" member of a map<>. > > Sincerely, > Eric Newhuis > > > Maybe I'm missing something, but ets:last/1 finds the entry with the largest key in an ordered set table. I'm not sure how I'd use an index table to do this though so I might be barking up the wrong tree. Sean From svg@REDACTED Fri Oct 24 21:35:54 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Sat, 25 Oct 2003 01:35:54 +0600 (YEKST) Subject: Constant Time ETS Ordered Set Get Largest-Keyed Member ? In-Reply-To: <3F9975B8.5020702@futuresource.com> References: <3F9975B8.5020702@futuresource.com> Message-ID: <20031025.013554.74751179.svg@surnet.ru> Good day, What about ets:lookup(Tab, ets:last(Key)) or (catch ets:foldr(fun (Last, _) -> throw(Last) end, [], Tab)) Best Regards, Vladimir Sekissov enewhuis> O Great ETS Masters, enewhuis> enewhuis> Is there a "constant time" ETS ordered set get largest-keyed member enewhuis> function, technique, or trick? enewhuis> enewhuis> I want to retreive the last member of the ordered set, the one with the enewhuis> largest valued key, often enough to justify building a separate ETS enewhuis> index table. My code would be simpler, however, of course, if I could enewhuis> avoid the extra ETS table. enewhuis> enewhuis> In C++, with a heavy dose of the Standard C++ Library containers, I'd enewhuis> probably do this with the "reverse end" member of a map<>. enewhuis> enewhuis> Sincerely, enewhuis> Eric Newhuis enewhuis> enewhuis> From jerome@REDACTED Fri Oct 24 22:15:47 2003 From: jerome@REDACTED (=?ISO-8859-1?Q?J=E9r=F4me_Desquilbet?=) Date: Fri, 24 Oct 2003 22:15:47 +0200 Subject: Erlang on Mac OS 10.3 In-Reply-To: <20031024095321.104f5294.cpressey@catseye.mine.nu> References: <200310240242.h9O2gngS431493@atlas.otago.ac.nz> <20031024095321.104f5294.cpressey@catseye.mine.nu> Message-ID: Has anybody tried to compile the Erlang package on Panther already? On my side, make fails with: ld: Undefined symbols: _z_errmsg TIA for any help, J?r?me. From sean.hinde@REDACTED Fri Oct 24 22:39:49 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Fri, 24 Oct 2003 21:39:49 +0100 Subject: Erlang on Mac OS 10.3 In-Reply-To: Message-ID: <364C33A8-0662-11D8-8A54-000A95927CCE@mac.com> On Friday, October 24, 2003, at 09:15 pm, J?r?me Desquilbet wrote: > Has anybody tried to compile the Erlang package on Panther already? > On my side, make fails with: > > ld: Undefined symbols: > _z_errmsg > > TIA for any help, > J?r?me. > I have heard (ehem!) that the emulator compiled under 10.2 works under some Panther like early release. It looks like the included zlib might have failed to compile - can you perhaps post the rest of the compile log? Sean From jerome@REDACTED Fri Oct 24 22:51:47 2003 From: jerome@REDACTED (=?ISO-8859-1?Q?J=E9r=F4me_Desquilbet?=) Date: Fri, 24 Oct 2003 22:51:47 +0200 Subject: Erlang on Mac OS 10.3 In-Reply-To: <364C33A8-0662-11D8-8A54-000A95927CCE@mac.com> References: <364C33A8-0662-11D8-8A54-000A95927CCE@mac.com> Message-ID: Le 24 oct. 03, ? 22:39, Sean Hinde a ?crit : > > On Friday, October 24, 2003, at 09:15 pm, J?r?me Desquilbet wrote: > >> Has anybody tried to compile the Erlang package on Panther already? >> On my side, make fails with: >> >> ld: Undefined symbols: >> _z_errmsg >> >> TIA for any help, >> J?r?me. >> > > I have heard (ehem!) that the emulator compiled under 10.2 works under > some Panther like early release. > > It looks like the included zlib might have failed to compile - can you > perhaps post the rest of the compile log? > > Sean Here it is (sorry for the large message). This is the result of make run after the same failure: -- J?r?me. --------8<----------------------------- $ make cd erts/emulator && ERL_TOP=/Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0 make generate depend make -f powerpc-apple-darwin7.0.0/Makefile generate make[2]: Nothing to be done for `generate'. make -f powerpc-apple-darwin7.0.0/Makefile depend gcc -MM -MG -g -O2 -I/Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/powerpc- apple-darwin7.0.0 -no-cpp-precomp -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DHIPE_ARCHITECTURE=noarch -Ibeam -Isys/unix -Isys/common -Ipowerpc-apple-darwin7.0.0 -Ipowerpc-apple-darwin7.0.0/opt -Izlib -Ihipe -Idrivers/common \ beam/*.c drivers/common/*.c drivers/unix/*.c \ sys/unix/*.c sys/common/*.c hipe/*.c | \ sed 's|^\([^:]*:\)|$(OBJDIR)/\1|g;s|powerpc-apple-darwin7.0.0/opt/ |$(TARGET_TYPE_DIR)/|g' > powerpc-apple-darwin7.0.0/depend.mk gcc -MM -MG -DENABLE_ELIB_MALLOC -DELIB_ALLOC_IS_CLIB -DELIB_HEAP_SBRK -g -O2 -I/Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/powerpc- apple-darwin7.0.0 -no-cpp-precomp -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -DHIPE_ARCHITECTURE=noarch -Ibeam -Isys/unix -Isys/common -Ipowerpc-apple-darwin7.0.0 -Ipowerpc-apple-darwin7.0.0/opt -Izlib -Ihipe -Idrivers/common \ beam/elib_malloc.c beam/elib_memmove.c beam/erl_bif_info.c beam/utils.c beam/erl_alloc.c | sed 's|^\([^:]*\).o[ ]*:|$(OBJDIR)/\1.elib.o:|g;s|powerpc-apple-darwin7.0.0/opt/ |$(TARGET_TYPE_DIR)/|g' >> powerpc-apple-darwin7.0.0/depend.mk cd erts && ERL_TOP=/Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0 make NO_START_SCRIPTS=true ( cd emulator && make shared ) make -f powerpc-apple-darwin7.0.0/Makefile TYPE=shared make -f powerpc-apple-darwin7.0.0/Makefile TYPE=shared make[5]: Nothing to be done for `all'. gcc -o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/bin/powerpc- apple-darwin7.0.0/beam.shared \ /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_main.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/preload.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_pbifs.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/benchmark.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_alloc.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_mtrace.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_alloc_util.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_goodfit_alloc.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bestfit_alloc.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_afit_alloc.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_instrument.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_init.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_atom_table.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bif_table.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bif_info.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bif_op.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bif_os.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bif_lists.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bif_trace.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bif_wrap.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_trace.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/copy.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/utils.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/bif.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/io.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_debug.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_md5.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_message.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_process.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_process_dict.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_arith.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/time.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_time_sup.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/external.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/dist.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/binary.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_db.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_db_util.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_db_hash.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_db_tree.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/fix_alloc.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/big.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/hash.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/index.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/atom.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/module.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/export.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/register.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/break.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_async.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/sys_threads.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/ggc.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_gc.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_posix_str.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bits.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_math.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_vector.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_term.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_fun.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_bif_port.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_node_tables.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_process_dump.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/beam_emu.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/beam_opcodes.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/beam_load.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/beam_bif_load.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/beam_debug.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/beam_bp.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/beam_catches.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/sys.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/driver_tab.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/unix_efile.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/gzio.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/elib_malloc.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/elib_memmove.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/erl_mseg.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/unix_ddll_drv.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/sys_float.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/efile_drv.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/ddll_drv.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/inet_drv.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/zlib_drv.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/ram_file_drv.o /Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/ obj.shared.beam/powerpc-apple-darwin7.0.0/ttsl_drv.o -lncurses -lresolv -ldl -lm -L/Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/erts/obj/ powerpc-apple-darwin7.0.0 -lz ld: Undefined symbols: _z_errmsg make[3]: *** [/Volumes/Home/jerome/Developpement/erlang/otp_src_R9C-0/bin/powerpc- apple-darwin7.0.0/beam.shared] Error 1 make[2]: *** [shared] Error 2 make[1]: *** [shared] Error 2 make: *** [emulator] Error 2 --------8<----------------------------- From joachim.durchholz@REDACTED Sat Oct 25 00:27:38 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Sat, 25 Oct 2003 00:27:38 +0200 Subject: Language change proposal In-Reply-To: <3F98E9DA.3050408@ericsson.com> References: <3F98E9DA.3050408@ericsson.com> Message-ID: <3F99A75A.8000400@web.de> Bengt Kleberg wrote: > WILLIAMS Dominic wrote: > ...deleted > >> 2) Functions would be deprecated by adding an obsolete attribute that >> would list obsolete functions in the same format as export/import: >> >> -module(my_module). >> -export([a/1,b/2,c/3]). >> -obsolete([b/2]). > > the eiffel keyword ''obsolete'' has an argument that explains what > alternatives there are, instead of the obsolete feature. perhaps > somehting like this (yes, i know this makes it impossible to obsolete a > whole slew of functions in one go. but see my second example for an > alternative): > > -module(my_module). > -export([a/1,b/2,c/3]). > -obsolete(b/2, "use c/2 instead"). > > moreover, eiffel can obsolete a whole class. which could be quite handy: > > -module(my_module). > -obsolete("use my_other_module instead"). I have been programming in Eiffel for several years, so some experience reports may be in order. 1. In Eiffel, the "obsolete" keyword has no semantic effect whatsoever. However, the Eiffel compiler will emit a warning whenever it sees a call to an obsolete feature. (One thing that could have been improved: if an obsolete routine called another obsolete routine, that call would also be flagged with a warning. Presumably, such calls should /not/ be marked... but that's really a minor nit to pick.) An important point is that the remark given with the "obsolete keyword" is given as part of the warning message. The programmer will see the warning and can decide immediately whether anything should be done about the issue, without having to go into the source code of the obsolete function. 2. For library designers, "obsolete" is a godsend. It will deflect most bug reports, change requests, and other communication from application programmers even before it hits the support line. If a programmer ever has a problem with an obsolete routine, he will prefer upgrading to the "approved" routines to any support calls. (Of course, some people will call anyway. But the support load reduces substantially.) 3. For application programmers, "obsolete" is a godsend as well. The remark on the "obsolete" keywords usually gives enough information that he knows what to do, without bothering to call support (and wait until a solution is available). 4. A warning to library developers: don't expect to ever get rid of a function marked obsolete anyway. There will be software that has been running untouched for a decade, and that will continue for decades to come. Functions marked obsolete are still there to stay, just like Fortran ;-) If you want to really phase out some function, use a mechanism that goes beyond "obsolete", or add an option that turns the warning into something more severe. Or make the standard obsolescence warnings be emitted as "remark" and turn it into a "warning" when phasing out the function is imminent for the next release. Or whatever - in any case, provide for a distinction between mild obsolescence reminders and stern warnings that a function Won't Be Available Anymore. Regards, Jo From Bengt.Kleberg@REDACTED Fri Oct 24 11:13:43 2003 From: Bengt.Kleberg@REDACTED (Bengt Kleberg) Date: Fri, 24 Oct 2003 11:13:43 +0200 Subject: Language change proposal In-Reply-To: References: <20031022092925.6115a375.cpressey@catseye.mine.nu> <3F970CBB.2050205@web.de> <20031023001941.GA19180@spearce.org> Message-ID: <3F98ED47.9030002@ericsson.com> Vlad Dumitrescu wrote: > From: "Shawn Pearce" > ...deleted >>It might also be nice to define other dependencies such as: >> >>-require(stdlib, "5.3"). >> >>to indicate that this module would need a version of stdlib that understand >>the calls available in version 5.3 of stdlib. > > > Mmm, wouldn't there be confusions with the stdlib application's version? After > all, as user of stdlib, I don't care what it's using inside, just what > interfaces it has. So in this case i'd expect to check stdlib's version - but if i do not think anybody would expect ''require'' to check anything _but_ the interface to a module. the implementation is surely uninteresting for this purpose? note that, imho, the first argument to ''require'' should be the smallest part that is distributed. currently erlang is a monolith (but i hope this changes rsn :-), so only -require(erlang, "R9A"). would make sense. when we get seperate pieces of erlang, it would make sense to use ''stdlib'', or something (''core''?). bengt From kostis@REDACTED Sun Oct 26 13:39:46 2003 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 26 Oct 2003 13:39:46 +0100 (MET) Subject: BUG in HiPE Message-ID: <200310261239.h9QCdk5J017351@harpo.it.uu.se> On Wed, 22 Oct 2003, David Wallin reported two HiPE bugs. These bugs have now been fixed and, if needed, patches can be sent to interested users of HiPE. The fixes will be available in the next release of Erlang/OTP R9C. We sincerely thank David for reporting them. Best, Kostis Sagonas (for the HiPE team). From jeremy@REDACTED Sun Oct 26 06:04:07 2003 From: jeremy@REDACTED (Jeremy Hylton) Date: Sun, 26 Oct 2003 01:04:07 -0400 Subject: LL3, Nov. 8, 2003, Call for participation Message-ID: <200310260507.h9Q56x412657@hades.cslab.ericsson.net> Call for Participation Lightweight Languages Workshop 2003 (LL3) ========================================= Saturday, November 8, 2003 MIT, Room 34-101, Cambridge, Mass. http://ll3.ai.mit.edu/ LL3 will be an intense, exciting, one-day forum bringing together the best programming language implementors and researchers, from both academia and industry, to exchange ideas and information, to challenge one another, and to learn from one another. If you plan to attend, please register as soon as possible. There is no cost to attend, but we need to know how much food to order. The workshop will also be broadcast live on the Internet. We are grateful to Microsoft Research for sponsoring the workshop and Internet broadcast. Program ======= Session I: 10:00-11:00 ---------------------- ACME: Toward a LL Testing Framework for Large Distributed Systems Dana Moore and Bill Wright Interactive Web Programming using WASH/CGI Matthias Neubauer Session II: 11:30-12:30 ----------------------- XS: Lisp on Lego MindStorms Taiichi Yuasa Posters and demos -- details will be posted on the web site Session III: 2:00-3:30 ---------------------- Bluespec, Language Support for Next-Generation Hardware Design Rishiyur S. Nikhil The Virtual Machine of Lua Luiz Henrique de Figueiredo Embedding an interpreted language using higher-order functions and types Norman Ramsey Session IV: 4:00-5:00 --------------------- Functional Reactive Programming in Scheme Gregory Cooper Boundaries Dan Sugalski Program Committee ================= Ken Anderson, BBN (co-chair) Jeremy Hylton, Python Software Foundation (co-chair) Geoffrey Knauth, BAE Systems Shriram Krishnamurthi, Brown University Erik Meijer, Microsoft WebData Dan Sugalski, Perl Foundation Greg Sullivan, MIT CSAIL From sean.hinde@REDACTED Sun Oct 26 20:54:47 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Sun, 26 Oct 2003 19:54:47 +0000 Subject: [ANN] enscript mode for Erlang Message-ID: <40E27C5F-07EE-11D8-8A54-000A95927CCE@mac.com> Hi all, Announcing an erlang syntax highlighting mode for enscript (used by viewcvs as well as being useful in its own right for generating colourised html, rtf, and ps output) INSTALLATION Save the rules at the bottom of this mail in a new file (erlang.st) in the hl directory of your enscript installation (e.g /usr/local/share/enscript/hl/erlang.st). You might also wish to add the following line to the namerules section of enscript.st /\.(e|h)rl$/ erlang; USAGE enscript --color --language=html -Eerlang -o out.html in.erl KNOWN BUGS Keywords, guards and bifs will sometimes be highlighted even when used as normal atoms - regexp lookaheads don't seem to work, so I can't figure out how to check for an opening ( without consuming it, which then messes up variable name highlighting. Any suggestions for a solution to this and other feedback welcome. It has only been tested against enscript 1.6.3, and requires at least 1.6.2. It seems to mostly work on my code at least.. I will wait to see what other bugs come out before submitting to the enscript maintainer. Enjoy! Sean -------------- save from below in erlang.st ---------------- /** * Name: erlang * Description: Erlang programming language. * Author: Sean Hinde */ /* Erlang atom: ([a-z][a-zA-Z0-9_]*|\'[^\n]*\') */ state erlang extends HighlightEntry { /* Comments */ /%/ { comment_face (true); language_print ($0); call (eat_one_line); comment_face (false); } /* String constants. */ /\"/ { string_face (true); language_print ($0); call (c_string); string_face (false); } /* Special -record(rec_name, {}). pre-processor case */ /(-record)(\([ \t]*)([a-z][a-zA-Z0-9_]*|\'[^\n]*\')/ { reference_face (true); language_print ($1); reference_face (false); language_print ($2); type_face (true); language_print ($3); type_face (false); } /* Special -define(Alter, "Hello"). pre-processor case */ /(-define)(\([ \t]*)([a-z][a-zA-Z0-9_]*|\'[^\n]*\'|[A-Z_][a-zA-Z0-9_]*)/ { reference_face (true); language_print ($1); reference_face (false); language_print ($2); builtin_face (true); language_print ($3); builtin_face (false); } /* Pre-processor lines. */ /^-([a-z][a-zA-Z0-9_]*)/ { reference_face (true); language_print ($0); reference_face (false); } /* Defines */ /(\?)([a-z][a-zA-Z0-9_]*|\'[^\n]*\'|[A-Z_][a-zA-Z0-9_]*)/ { language_print ($1); builtin_face (true); language_print ($2); builtin_face (false); } /* Records */ /(#)([a-z][a-zA-Z0-9_]*|\'[^\n]*\')/ { language_print ($1); type_face (true); language_print ($2); type_face (false); } /* Keywords. '(after begin case try catch end fun if of receive when) Regexp taken from emacs Erlang mode R9C */ /\b(a(fter|ndalso)|begin|c(atch|ase)\ |end|fun|if|o(f|relse)|receive|try|when\ |query)\b/ { keyword_face (true); language_print ($0); keyword_face (false); } /* Guards. Regexp taken from emacs Erlang mode R9C */ /\b((is_)*(atom|function|binary|constant|float\ |integer|list|number|p(id|ort)\ |re(ference|cord)|tuple))\b/ { builtin_face (true); language_print ($0); builtin_face (false); } /* Built in functions */ /\b(a(bs|live|pply|tom_to_list)\ |binary_to_(list|term)\ |concat_binary|d(ate|isconnect_node)\ |e(lement|rase|xit)\ |float(|_to_list)\ |g(arbage_collect|et(|_keys)|roup_leader)\ |h(alt|d)\ |i(nte(ger_to_list|rnal_bif)|s_alive)\ |l(ength|i(nk|st_to_(atom|binary|float|integer\ |pid|tuple)))\ |make_ref|no(de(|_(link|unlink)|s)|talive)\ |open_port\ |p(id_to_list|rocess(_(flag|info)|es)|ut)\ |r(egister(|ed)|ound)\ |s(e(lf|telement)|ize\ |p(awn(|_link)|lit_binary)|tatistics)\ |t(erm_to_binary|hrow|ime|l\ |r(ace|unc)|uple_to_list)\ |un(link|register)|whereis)\b/ { keyword_face (true); language_print ($0); keyword_face (false); } /* * Function definitions. */ /^([a-z][a-zA-Z0-9_]*|'[^\n]*')/ { function_name_face (true); language_print ($1); function_name_face (false); language_print ($2); } /* Atom like strings */ /('[^\n]*')/ { string_face (true); language_print ($0); string_face (false); } /* Characters */ /(\$.)/ { string_face (true); language_print ($0); string_face (false); } /* Variable Names */ /* /([\{\(\,\[ \t]+)([A-Z_][a-zA-Z0-9_]*)/ { */ /([^a-z0-9_\"])([A-Z_][a-zA-Z0-9_]*)/ { language_print ($1); variable_name_face (true); language_print ($2); variable_name_face (false); } } /* Local variables: mode: erlang End: */ From robert.virding@REDACTED Mon Oct 27 12:53:36 2003 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 27 Oct 2003 12:53:36 +0100 Subject: Language change proposal References: <200310240242.h9O2gngS431493@atlas.otago.ac.nz> <20031024095321.104f5294.cpressey@catseye.mine.nu> Message-ID: <030001c39c80$f48f8820$2100a8c0@virding.org> ----- Original Message ----- From: "Chris Pressey" To: "Richard A. O'Keefe" Cc: "Erlang-Questions" Sent: Friday, October 24, 2003 5:53 PM Subject: Re: Language change proposal > Ah, but the rivers of the Erlang support list are choked with the bodies > of keyboard-pounding language designers, are they not? Guardians of > Truth and Beauty, each and every one of us, who do not seem to realize > that Erlang is not a project in pursuit of perfect language purity. It > is, in fact, an exercise in return-on-investment (right, Mr. Ericsson?) > > And defining a new predefined macro is just about as small an investment > there is. > > Take it one small step further and add -assert() to -ifdef() and > friends, and I for one have a hard time explaining the difference > between > > -requires_erlang('5.3'). > > and > > -assert(?ERLANG_VERSION, '5.3'). > > in terms that the average non-language-designing Erlang programmer would > appreciate or care about. So it would seem to me that this small > investment gets a comparable return. Perhaps even a greater one, when > you consider the same -assert() mechanism can be used for any other > macro already in use, predefined (like ?MACHINE) or otherwise. > > So there you have a plausible case for using macros. Being the original "Guardian of Truth and Beauty" I think you have missed the point, at least how I see it. If you want Erlang to be a good return-on-investment over a long term then you have to be very strict about what you allow in the language. Otherwise it will become full of little "features" that, separately, are all innocent but put together result in a complete mess, which is difficult to understand and maintain. And macros are definitely in this this category. Mind you this coming from the person who actually added macros to the language! :-) To my defence I must say that I didn't want them myself and never really saw the benefit. They made me do it. Being in a playful mood I gave them much more than they originally asked for, for example arguments, and there is only one thing I really missed and that is allowing macros of the same name with different number of arguments. If you are going down you might as well do it properly. But I still say the preprocessor should never have been added. Richard where is the Ada reasoning about a preprocessor described? If I had been able to come up with Richard O'Keefe's Abstract Data Types this would have been a much better solution. In contrast to Joe though I don't see size in itself to be the main problem. The main things to worry about are to be extremely clear about the basic concepts in your language and keeping to them, and in being consistent. If two different things look similar then they should behave similarily, and vice a versa. That was one of my main critisms about the type checking in patterns, it broke the model of being able to put terms together and pull them apart by the same construct. I think that if you ARE clear and consistent then there is no basic problem in adding new features. Of course it is another question whether you NEED the new features. Implementing the union of everyones requests is a bad idea. This is one of the problems I see with ETS tables. They don't fit into the basic Erlang model of how data is organised. Data is local to processes while ETS tables are outside. It is my view (and here I do agree with Joe :-) that everything should look like a process, i.e. you communicate with messages and you can link to it. This is why you need guardians so that it will be clear and consistent. As I have said before one of our, the original implementors, main faults was not actually explaining and writing down our basic concepts. To us they were so clear they need no explanantion. Of course sometimes we weren't in agreement as to the concepts. :-) Robert P.S. I also implemented records. :-) Not my idea either. A struct like term would have been much better but there were reasons for not doing that, which I again think were wrong. From robert.virding@REDACTED Mon Oct 27 12:54:32 2003 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 27 Oct 2003 12:54:32 +0100 Subject: Try/Cond References: <006301c39803$454ffe20$bfdcd1d9@gnit> Message-ID: <030101c39c81$163e4600$2100a8c0@virding.org> ----- Original Message ----- From: "Luke Gorrie" To: "Richard Carlsson" Cc: "Sean Hinde" ; Sent: Tuesday, October 21, 2003 7:49 PM Subject: Re: Try/Cond > "Richard Carlsson" writes: > > > The current status is that it turned out that Erlang's scoping rules > > made it harder than we had expected to implement "cond" correctly > > (i.e., it's not just a trivial expansion into a nested case > > statement), so it was postponed until someone with a lot of spare time > > could have another look at it. > > Just add `let' too. I wish we had and I wish we would. It would remove an aweful lot of scoping problems, not just in cond. Robert From sean.hinde@REDACTED Mon Oct 27 02:12:41 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 27 Oct 2003 01:12:41 +0000 Subject: Erlang is getting too big In-Reply-To: <3F8D5BA8.4060603@erix.ericsson.se> Message-ID: On Wednesday, October 15, 2003, at 03:37 pm, Kenneth Lundin wrote: > Well I just have to comment on this. > I don't think there are that many new features in the syntax the past > 4 years. Not many, but certainly a few. I have calmed down a bit since firing off the original e-mail - life here has been interesting recently! I must also say that the more recently officially added additions have been pretty nice and well thought out, in contrast it seems with some of the earlier stuff ;-) It is very clear that Erlang is foremost an industrial language and it is of course as much in your interests as ours to ensure that the language remains consistent, easy to learn and understand, and easy to write error free code in. > > The single most important news is in my opinion the Bit-syntax. > > Some of the other features referred to by Sean and others are not at > all part of the language yet (but some are distributed as > experimental). It was not really my intent to comment on these examples specifically, it was to re-iterate the point that Erlang is the accumulation of all this stuff, both old and new, and that it seems to me that Erlang is now pretty much complete, warts and all. One of the problems with the experimental stuff is that once in there it very quickly becomes impossible to remove - we are already seeing nice open source libraries being written which make heavy use of the packages notation. > > - The Java style module naming is still distributed as experimental it > is not supported and should not in my opinion be mentioned for > beginners. It might be a good idea to make it official but we have not > decided to do that yet. The problem with the "don't mention to beginners" approach is that increasingly the first job will be to maintain someone else code, which by Murphys law means that this code will use exactly the set of features which weren't mentioned in the beginners course. It would be very interesting to do the study of the cost benefit of any new language feature. > > - There is ONE syntactic sugar construct regarding records #rec{_ = > xx} added. True, though I also had in mind the #rec{} = Var 'as' notation which is of course of wider scope than records, but is often used with them. > > - The new suggested syntactic sugar for type guards "f(I/integer) <-> > f(I) when integer(I) is not added to the language yet and we have not > decided that it will. > > - There are some additions regarding guards and guard BIFs. > > But where are the rest of the new features cluttering the language? > Do you think this is a lot of new things over a 4 year period? Not a lot no, but the accumulation of these plus many of the things being discussed would make for quite a lot. > I think the record syntax and semantics is something to regret. It is > an important feature to have structured datatypes with names on them > but not the way records are implemented. Indeed, though the more recent efforts to help tidy the implementation and improve runtime checking and efficiency are noticed and appreciated. > In summary I agree that we should be careful with language extensions > and I think that we really are. Good, good, I just wanted to make sure amidst the clamour for more and more features that sense is prevailing. It might be seen by some as a little dull spending time on making the implementation better and better and faster and more fault tolerant etc, and not adding whizzy new stuff, but it is these aspects which are really the most appreciated by us at least. Finally my mail was in part prompted by our experience for the first time of actually training our own Erlang programmers rather than stealing them from Ericsson :-). I hope that the feedback was of some value at least, and that you take hope from the fact that this means we should be buying some more licences soon.. Best Regards, Sean From gunilla@REDACTED Mon Oct 27 11:23:11 2003 From: gunilla@REDACTED (Gunilla Arendt) Date: Mon, 27 Oct 2003 11:23:11 +0100 Subject: Application directory heirachy References: <20031013201909.GA36063@frogman.motivity.ca> Message-ID: <3F9CF20F.66632CAA@erix.ericsson.se> I think the directory structure 'src/e_src' really never has been used within OTP. It's Design Principles which is out-of-date in this case. Regards, Gunilla Vance Shipley wrote: > > The Design Principles document describes the directory > structure of an application quite differently than what > is found in the distribution: > > The application directory have the following > sub-directories: > > src > ebin > priv > include > > src > Contains the Erlang source code. If source code is > written in several different languages, a sub-directory > with the name e_src can be created below the src > directory to store the Erlang source code. > > In the R9C-0 distribution we find a different practice. The > src directories for Erlang files are always "src" while other > languages are at the same level with names like c_src and > java_src: > > asn1/c_src > asn1/src > > ic/c_src > ic/java_src > ic/src > > orber/c_src > orber/java_src > orber/src > > Did this change at some point? I seem to remember e_src directories > however maybe they were just mine created with the above guidlines. > > -Vance > > [ This would be an OTP question as opposed to an Erlang one. I have ] > [ long advocated a seperate list for OTP questions which I believe ] > [ would help with the distinction. This is apparently not a popular ] > [ view however. ] -- _____Gunilla Arendt______________________________________________ EAB/UKH/KD Erlang/OTP Product Development Gunilla.Arendt@REDACTED +46-8-7275730 ecn 851 5730 From Domonkos.Asztalos@REDACTED Mon Oct 27 14:29:06 2003 From: Domonkos.Asztalos@REDACTED (Asztalos Domonkos) Date: Mon, 27 Oct 2003 14:29:06 +0100 Subject: ASN.1 specification and protocol stack References: <00bf01c38824$be3dfec0$a22d1081@ituniv398> Message-ID: <3F9D1DA2.7B818CF8@eth.ericsson.se> Hi Thomas, one of my collegues suggestion is: "I suppose to look at the ITU-T ASN.1 database (http://www.itu.int/ITU-T/asn1/database/index.html) and I'm sure there you can find suitable modules that fit your needs." BR, Domi Thomas Arts wrote: > Could anyone point me to a relatively small ASN.1 specification > of a protocol together with the accompanying protocol stack? > > We are looking into testing tools and would like to have a case > study to see how well the testing performs. > > Thanks > Thomas > > --- > Dr Thomas Arts > Program Manager > Software Engineering and Management > IT-university in Gothenburg > Box 8718, 402 75 Gothenburg, Sweden > http://www.ituniv.se/ > > Tel +46 31 772 6031 > Fax +46 31 772 4899 From sean.hinde@REDACTED Mon Oct 27 15:25:43 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 27 Oct 2003 14:25:43 +0000 Subject: Try/Cond In-Reply-To: <030101c39c81$163e4600$2100a8c0@virding.org> Message-ID: <727710DC-0889-11D8-8A54-000A95927CCE@mac.com> On Monday, October 27, 2003, at 11:54 am, Robert Virding wrote: > > ----- Original Message ----- > From: "Luke Gorrie" > To: "Richard Carlsson" > Cc: "Sean Hinde" ; > Sent: Tuesday, October 21, 2003 7:49 PM > Subject: Re: Try/Cond > > >> "Richard Carlsson" writes: >> >>> The current status is that it turned out that Erlang's scoping rules >>> made it harder than we had expected to implement "cond" correctly >>> (i.e., it's not just a trivial expansion into a nested case >>> statement), so it was postponed until someone with a lot of spare >>> time >>> could have another look at it. >> >> Just add `let' too. > > I wish we had and I wish we would. It would remove an aweful lot of > scoping problems, not just in cond. > > Robert This is quite an interesting case. The current situation from the dumb user perspective is that sometimes the compiler warns you that a variable is "unsafe", even though it seems illogical that its binding could escape from where the compiler is telling you it has. Never mind, just make up some new variable names and life goes on. Introducing let into the language would force the requirement for an explicit understanding of what underlies these occasional error messages and the need to specifically code for it with new syntax onto anyone wishing to use the language or maintain applications written in it. I'd vote for a couple of extra compiler messages and the slight inconvenience the inelegant scoping causes if it means not adding let. Sean From mwilligs@REDACTED Mon Oct 27 16:21:57 2003 From: mwilligs@REDACTED (mwilligs@REDACTED) Date: Mon, 27 Oct 2003 12:21:57 -0300 (PYST) Subject: streamMode variable Message-ID: <33426.65.198.40.11.1067268117.squirrel@unimail.uninet.com.py> In the file megaco_message_v1.hlr the structure LocalControlDescriptor have the streamMode variable. Witch are the posible values of streamMode? In the RFC 3015 page 91 is defined as follow: StreamMode ::= ENUMERATED { sendOnly(0), recvOnly(1), sendRecv(2), ... } The point is: Is it right to write it this way in erlang?: LCD1=#'LocalControlDescriptor'{streamMode=2} or shall I write it in this way?: LCD1=#'LocalControlDescriptor'{streamMode=recvOnly} Because, appareantly neither of this ways is correct. thanks in advance From erlang@REDACTED Mon Oct 27 16:56:20 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Mon, 27 Oct 2003 15:56:20 +0000 Subject: revised SciTE syntax lexer Message-ID: <20031027155620.75829751.erlang@manderp.freeserve.co.uk> Hi SciTE+Erlang users, I've updated the SciTE Erlang syntax highlighter with a few bug fixes. The most significant fixes are:- folding the fun() -> ... end notation and _not_ folding the fun funct_name/arity notation. parsing radix numbers correctly (with radix error highlighting too :-) I've cleaned the lexer code too, so the number of intermediary/unresolved states in erlang.properties file is reduced. If anyone (Chris Pressey? James Hague?) in here would like to test-drive the fix, please let me know. If there's no objection to me posting the .tar.bz2 file on the mailing list, I will do so. Pete. From micael.karlberg@REDACTED Mon Oct 27 18:03:03 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Mon, 27 Oct 2003 18:03:03 +0100 Subject: streamMode variable In-Reply-To: <33426.65.198.40.11.1067268117.squirrel@unimail.uninet.com.py> References: <33426.65.198.40.11.1067268117.squirrel@unimail.uninet.com.py> Message-ID: <16285.20423.881923.960766@gargle.gargle.HOWL> Hi, LCD1=#'LocalControlDescriptor'{streamMode = recvOnly} is the correct. What kind of problems did you encounter? /BMK mwilligs@REDACTED writes: > In the file megaco_message_v1.hlr the structure LocalControlDescriptor > have the streamMode variable. > > Witch are the posible values of streamMode? > In the RFC 3015 page 91 is defined as follow: > StreamMode ::= ENUMERATED > { > sendOnly(0), > recvOnly(1), > sendRecv(2), > ... > } > The point is: Is it right to write it this way in erlang?: > LCD1=#'LocalControlDescriptor'{streamMode=2} > or shall I write it in this way?: > LCD1=#'LocalControlDescriptor'{streamMode=recvOnly} > > Because, appareantly neither of this ways is correct. > > thanks in advance -- Micael Karlberg Ericsson AB, ?lvsj? Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@REDACTED Fax: +46 8 727 5775 From michael@REDACTED Mon Oct 27 20:13:46 2003 From: michael@REDACTED (Michael Hobbs) Date: Mon, 27 Oct 2003 13:13:46 -0600 (CST) Subject: Erlang module for SWIG? In-Reply-To: References: <3F8D5BA8.4060603@erix.ericsson.se> Message-ID: <2573.66.41.245.83.1067282026.squirrel@mail.hobbshouse.org> Has anyone ever attempted to create an Erlang module for SWIG? (http://www.swig.org) If so, I'm curious about what sort of roadblocks are in the way of doing a proper implementation. Specifically, I'm trying to create an Erlang interface to wxWindows. (http://www.wxwindows.org) After having made a couple of different stabs at it, I'm considering using SWIG to help automate the process a little more. However, if there are serious problems with SWIGing Erlang, I may just persevere down my current path instead. Thanks, - Michael Hobbs From mwilligs@REDACTED Mon Oct 27 20:46:46 2003 From: mwilligs@REDACTED (mwilligs@REDACTED) Date: Mon, 27 Oct 2003 16:46:46 -0300 (PYST) Subject: streamMode variable In-Reply-To: <16285.20423.881923.960766@gargle.gargle.HOWL> References: <33426.65.198.40.11.1067268117.squirrel@unimail.uninet.com.py> <16285.20423.881923.960766@gargle.gargle.HOWL> Message-ID: <33806.65.198.40.11.1067284006.squirrel@unimail.uninet.com.py> Hi Thaks for the answer. my problem is the following: I wana make an 'add' command: Context=$ { Add=A4444 { Media { LocalControl{Mode = SendRecv} } } } And this is my code: where CH={megaco_conn_handle,{deviceName,"ctrl"},{deviceName,"mg"}} %%%% addcommand(Pid,CH)-> LCD1=#'LocalControlDescriptor'{streamMode=recvOnly}, SP1=#'StreamParms'{localControlDescriptor=LCD1}, MEDIA1=#'MediaDescriptor'{streams=SP1}, ADD1=#'AmmRequest'{terminationID=[#megaco_term_id{id=?A4444}] , descriptors=MEDIA1}, CR1=#'CommandRequest'{command={addReq, ADD1}}, AR=#'ActionRequest'{contextId=?megaco_choose, commandRequests=[CR1]}, megaco:cast(CH, [AR], []). %%%%%% what's wrong in this code?? How can I make a test to find errors in my megaco packets? Thanks again > Hi, > > LCD1=#'LocalControlDescriptor'{streamMode = recvOnly} is the correct. > What kind of problems did you encounter? > > /BMK > > > mwilligs@REDACTED writes: > > In the file megaco_message_v1.hlr the structure LocalControlDescriptor > > have the streamMode variable. > > > > Witch are the posible values of streamMode? > > In the RFC 3015 page 91 is defined as follow: > > StreamMode ::= ENUMERATED > > { > > sendOnly(0), > > recvOnly(1), > > sendRecv(2), > > ... > > } > > The point is: Is it right to write it this way in erlang?: > > LCD1=#'LocalControlDescriptor'{streamMode=2} > > or shall I write it in this way?: > > LCD1=#'LocalControlDescriptor'{streamMode=recvOnly} > > > > Because, appareantly neither of this ways is correct. > > > > thanks in advance > > -- > Micael Karlberg Ericsson AB, ?lvsj? Sweden > Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > ECN: 851 5668 Mail: micael.karlberg@REDACTED > Fax: +46 8 727 5775 > From C.Reinke@REDACTED Mon Oct 27 20:51:33 2003 From: C.Reinke@REDACTED (C.Reinke) Date: Mon, 27 Oct 2003 19:51:33 +0000 Subject: Erlang module for SWIG? In-Reply-To: Message from "Michael Hobbs" of "Mon, 27 Oct 2003 13:13:46 CST." <2573.66.41.245.83.1067282026.squirrel@mail.hobbshouse.org> Message-ID: while SWIG has its own interest, perhaps you might find the route useful that Daan Leijen has chosen for creating the Haskell binding to wxWindows: http://wxhaskell.sourceforge.net/ "Since the core interface is generated automatically from the wxEiffel binding, about 75% of the wxWindows functionality is already supported, excluding the more "exotic" widgets like dockable windows and the openGL canvas. .." http://wxhaskell.sourceforge.net/development.html "... wxcore [documentation]. The Haskell binding to the core wxWindows library. This is just like programming the wxWindows library directly, you can see some examples in the cvs. All the method definitions and marshaling code is generated automatically -- about 500 classes with 2500 methods and 1000 constant definitions. wxcore uses the following two sub-projects: wxc. A C project that puts a C wrapper around the C++ interface to wxWindows. This makes it much easier to access the wxWindows library from Haskell. The C wrapper consists of the C sources of the Eiffel ewxw library for wxWindows. We also added a few files to make the project suitable for Haskell, but we made no changes to the original Eiffel sources. This way, we are able to automatically update the sources from their cvs server. A big thank-you to the people that worked on the Eiffel library! wxdirect. A Haskell program that reads the C header files of the wxWindows C library and automatically generates Haskell marshaling code and class definitions." Erlang and Haskell FFIs differ, and I don't know the details of this, but perhaps you find useful info there.. Cheers, Claus > Has anyone ever attempted to create an Erlang module for SWIG? > (http://www.swig.org) If so, I'm curious about what sort of roadblocks are > in the way of doing a proper implementation. > > Specifically, I'm trying to create an Erlang interface to wxWindows. > (http://www.wxwindows.org) After having made a couple of different stabs > at it, I'm considering using SWIG to help automate the process a little > more. However, if there are serious problems with SWIGing Erlang, I may > just persevere down my current path instead. > > Thanks, > - Michael Hobbs > > > From mwilligs@REDACTED Mon Oct 27 21:50:03 2003 From: mwilligs@REDACTED (mwilligs@REDACTED) Date: Mon, 27 Oct 2003 17:50:03 -0300 (PYST) Subject: Communication between Erlang and Unix proceses Message-ID: <2919.65.198.40.11.1067287803.squirrel@unimail.uninet.com.py> Hi there, I have been trying the communication between Unix proceses and Erlang processes through the usage of the open_port function. But, I have been having some problems to receive the messages from the Unix process. I can?t discriminate when I received a message and when no message is received. Please, take a look at the source files: con2.c and con1.erl The erlang process receives 11 messages ?Hello? through the port, and then I tried to close the port, but it did not work. How should I do that? And, if you take a look at the programs con3.c and con2.erl, you will see that I tried to receive messages that were suppose to be written from the Unix Console through fgets(buf, 1000, stderr) call. But, instead of that I am not being able to write the message and the Erlang process reads garbage from the port. How can I discriminate when a real message is received? Thanks again, Miguel Willigs Files attached: =============== -module(con1). -export([read/0]). %write (Path, Data) -> %Port = open_port({spawn, Path}, [{packet, 2}]), %Port ! {self(), {command, Data}}. read () -> Port = open_port({spawn, "/home/ljara/erlang/con2"}, [{packet, 2}]), recibir(). recibir() -> receive {Port, Data} -> io:format('erlang received from port:~p~n', [Data]), recibir(), receive {Port, "close"} -> Port ! {self(), close} end end. ***************************************************************************************************************************************************** /*********************************************************************/ /* con2.c - Programa que recibe mensajes desde un programa Erlang */ /* Fecha: 24/10/23 */ /* Autor: IYDDEPTO */ /*********************************************************************/ #include #include /****************************************/ typedef unsigned char byte; //Funciones void put_int16(int i, byte *s); /****************************************/ int main() { int len, flag=0, i=0; byte buf[1000]; char ini_message[50]; strcpy(ini_message, "com2 in C Starting \n"); strcpy(buf, "Hello"); fprintf(stderr, ini_message); while (flag!=1 && i<10) { //gets(buf); // fgets(buf, 1000, stderr); //Si ya no se quiere enviar mensajes if(strcmp(buf, "fin")==0) { flag=1; //Se cierra el puerto fprintf(stderr, "I have touched the flag\n"); } if((write_cmd(buf, strlen(buf)))<0) { perror("Message Sending Failed"); exit(1); } i++; fprintf(stderr, "Valor de i:%d\n", i); } if((write_cmd("close", strlen("close")))<0) { perror("Message Sending Failed"); exit(1); } fprintf(stderr, "C Program finished\n"); return(0); } /***************************************************/ /* Pack the 2 bytes length (MSB first) and send it */ int write_cmd(byte *buf, int len) { byte str[2]; put_int16(len, str); if (write_exact(str, 2) != 2) return(-1); return write_exact(buf, len); } /***************************************************/ int write_exact(byte *buf, int len) { int i, wrote = 0; i = write(1, buf+wrote, len-wrote); return (i); } /***************************************************/ void put_int16(int i, byte *s) { *s = (i >> 8) & 0xff; s[1] = i & 0xff; } ****************************************************************************************************************************************************** -module(con2). -export([read/0]). %write (Path, Data) -> %Port = open_port({spawn, Path}, [{packet, 2}]), %Port ! {self(), {command, Data}}. read () -> Port = open_port({spawn, "/home/ljara/erlang/con3"}, [{packet, 2}]), recibir(). recibir() -> receive {Port, Data} -> io:format('erlang received from port:~p~n', [Data]), recibir(), receive {Port, "close"} -> Port ! {self(), close} end end. ****************************************************************************************************************************************************** /*********************************************************************/ /* con3.c - Programa que recibe mensajes desde un programa Erlang */ /* Fecha: 24/10/23 */ /* Autor: IYDDEPTO */ /*********************************************************************/ #include #include /****************************************/ typedef unsigned char byte; //Funciones void put_int16(int i, byte *s); /****************************************/ int main() { int len, flag=0, i=0; byte buf[1000]; char ini_message[50]; strcpy(ini_message, "com2 in C Starting \n"); //strcpy(buf, "Hello"); fprintf(stderr, ini_message); while (flag!=1 && i<10) { //gets(buf); fgets(buf, 1000, stderr); //Si ya no se quiere enviar mensajes if(strcmp(buf, "fin")==0) { flag=1; //Se cierra el puerto fprintf(stderr, "I have touched the flag\n"); } if((write_cmd(buf, strlen(buf)))<0) { perror("Message Sending Failed"); exit(1); } i++; fprintf(stderr, "Valor de i:%d\n", i); } if((write_cmd("close", strlen("close")))<0) { perror("Message Sending Failed"); exit(1); } fprintf(stderr, "C Program finished\n"); return(0); } /***************************************************/ /* Pack the 2 bytes length (MSB first) and send it */ int write_cmd(byte *buf, int len) { byte str[2]; put_int16(len, str); if (write_exact(str, 2) != 2) return(-1); return write_exact(buf, len); } /***************************************************/ int write_exact(byte *buf, int len) { int i, wrote = 0; i = write(1, buf+wrote, len-wrote); return (i); } /***************************************************/ void put_int16(int i, byte *s) { *s = (i >> 8) & 0xff; s[1] = i & 0xff; } From luke@REDACTED Tue Oct 28 04:46:49 2003 From: luke@REDACTED (Luke Gorrie) Date: 28 Oct 2003 04:46:49 +0100 Subject: SNMP MIB-2 tables in Erlang? In-Reply-To: <874qy0bzpu.fsf@ghidra.vail> References: <874qy0bzpu.fsf@ghidra.vail> Message-ID: Hal Snyder writes: > We put stats into mnesia tables for distribution + SNMP monitoring. > Here's a cookbook from our last go-round with it, including sample > MIB. Hope it helps. > > Making a Mnesia Table SNMP Accessible > http://www.drxyzzy.org/mnesia-snmp/index.html Nice, thanks! -Luke From raimo@REDACTED Tue Oct 28 08:21:01 2003 From: raimo@REDACTED (Raimo Niskanen) Date: Tue, 28 Oct 2003 08:21:01 +0100 Subject: Communication between Erlang and Unix proceses References: <2919.65.198.40.11.1067287803.squirrel@unimail.uninet.com.py> Message-ID: Hi. To close a port; Port ! {self(),close}, receive {Port,closed} -> ok end, Not the other way around, and note that you receive the atom 'closed', not the string "close". Or have a look at erlang:port_close(Port). If the port program closes the port you will receive {'EXIT',Port,Reason} unless you use the flag 'eof' to open_port/2, in which case you will receive {Port,eof} and then will have to close the port yourself. About the fgets(): I think the problem is that you try to fgets() from stderr, which is an input stream for the port program. Who knows what gets messed up then. Erlang uses file descriptors 0 and 1 (stdin and stdout) to communicate with the port program, so the port program's file descriptors 0 and 1 are connected to the Erlang port. Basta. You can also use the flag 'stderr_to_stdout' to open_port/2 to duplicate the port program's stdout to stderr, so also the stderr output comes to the Erlang port. Not that I think you want it... You can also use the flag nouse_stdio to make erlang use file descriptors 3 and 4 instead of 0 and 1, and then fix your port program to do the same and so get access to stdin and stdout from the port program. Exactly how it is done I do not know (yet). Have a look at http://www.erlang.org/download/erlang-book-part1.pdf section "9.4 Ports" (page 134), and the erlang man page for 'erlang', functions open_port/2 and port_close/1. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB mwilligs@REDACTED wrote: > Hi there, > > I have been trying the communication between Unix proceses > and Erlang processes through the usage of the open_port > function. But, I have been having some problems to receive > the messages from the Unix process. > I can?t discriminate when I received a message and when no message is > received. Please, take a look at the source files: con2.c and con1.erl > The erlang process receives 11 messages ?Hello? through the port, and then > I tried to close the port, but it did not work. How should I do that? > > And, if you take a look at the programs con3.c and con2.erl, you will see > that I tried to receive messages that were suppose to be written from the > Unix Console through fgets(buf, 1000, stderr) call. But, instead of that I > am not being able to write the message and the Erlang process reads > garbage from the port. > How can I discriminate when a real message is received? > > Thanks again, > Miguel Willigs > > > Files attached: > =============== > > > -module(con1). > -export([read/0]). > > > %write (Path, Data) -> > %Port = open_port({spawn, Path}, [{packet, 2}]), > %Port ! {self(), {command, Data}}. > > read () -> > Port = open_port({spawn, "/home/ljara/erlang/con2"}, [{packet, 2}]), > recibir(). > > recibir() -> > > receive > {Port, Data} -> > io:format('erlang received from port:~p~n', [Data]), > recibir(), > > receive > {Port, "close"} -> > Port ! {self(), close} > > end > end. > > > ***************************************************************************************************************************************************** > > > /*********************************************************************/ > /* con2.c - Programa que recibe mensajes desde un programa Erlang */ > /* Fecha: 24/10/23 */ > /* Autor: IYDDEPTO */ > /*********************************************************************/ > > #include > #include > > > /****************************************/ > > typedef unsigned char byte; > > //Funciones > void put_int16(int i, byte *s); > > > /****************************************/ > > int main() > { > int len, flag=0, i=0; > > byte buf[1000]; > > char ini_message[50]; > > strcpy(ini_message, "com2 in C Starting \n"); > > strcpy(buf, "Hello"); > > fprintf(stderr, ini_message); > > while (flag!=1 && i<10) > { > //gets(buf); > // fgets(buf, 1000, stderr); > > //Si ya no se quiere enviar mensajes > if(strcmp(buf, "fin")==0) > { > flag=1; > //Se cierra el puerto > fprintf(stderr, "I have touched the flag\n"); > } > > if((write_cmd(buf, strlen(buf)))<0) > { > perror("Message Sending Failed"); > exit(1); > } > i++; > fprintf(stderr, "Valor de i:%d\n", i); > } > > if((write_cmd("close", strlen("close")))<0) > { > perror("Message Sending Failed"); > exit(1); > } > > fprintf(stderr, "C Program finished\n"); > return(0); > } > > /***************************************************/ > > /* Pack the 2 bytes length (MSB first) and send it */ > int write_cmd(byte *buf, int len) > { > byte str[2]; > > put_int16(len, str); > > if (write_exact(str, 2) != 2) > return(-1); > > return write_exact(buf, len); > > } > > /***************************************************/ > > int write_exact(byte *buf, int len) > { > int i, wrote = 0; > > i = write(1, buf+wrote, len-wrote); > return (i); > > > } > > /***************************************************/ > > void put_int16(int i, byte *s) > { > *s = (i >> 8) & 0xff; > s[1] = i & 0xff; > } > > > ****************************************************************************************************************************************************** > > -module(con2). > -export([read/0]). > > > %write (Path, Data) -> > %Port = open_port({spawn, Path}, [{packet, 2}]), > %Port ! {self(), {command, Data}}. > > read () -> > Port = open_port({spawn, "/home/ljara/erlang/con3"}, [{packet, 2}]), > recibir(). > > recibir() -> > > receive > {Port, Data} -> > io:format('erlang received from port:~p~n', [Data]), > recibir(), > > receive > {Port, "close"} -> > Port ! {self(), close} > > end > end. > > > ****************************************************************************************************************************************************** > > /*********************************************************************/ > /* con3.c - Programa que recibe mensajes desde un programa Erlang */ > /* Fecha: 24/10/23 */ > /* Autor: IYDDEPTO */ > /*********************************************************************/ > > #include > #include > > > /****************************************/ > > typedef unsigned char byte; > > //Funciones > void put_int16(int i, byte *s); > > > /****************************************/ > > int main() > { > int len, flag=0, i=0; > > byte buf[1000]; > > char ini_message[50]; > > strcpy(ini_message, "com2 in C Starting \n"); > > //strcpy(buf, "Hello"); > > fprintf(stderr, ini_message); > > while (flag!=1 && i<10) > { > //gets(buf); > fgets(buf, 1000, stderr); > > //Si ya no se quiere enviar mensajes > if(strcmp(buf, "fin")==0) > { > flag=1; > //Se cierra el puerto > fprintf(stderr, "I have touched the flag\n"); > } > > if((write_cmd(buf, strlen(buf)))<0) > { > perror("Message Sending Failed"); > exit(1); > } > i++; > fprintf(stderr, "Valor de i:%d\n", i); > } > > if((write_cmd("close", strlen("close")))<0) > { > perror("Message Sending Failed"); > exit(1); > } > > fprintf(stderr, "C Program finished\n"); > return(0); > } > > /***************************************************/ > > /* Pack the 2 bytes length (MSB first) and send it */ > int write_cmd(byte *buf, int len) > { > byte str[2]; > > put_int16(len, str); > > if (write_exact(str, 2) != 2) > return(-1); > > return write_exact(buf, len); > > } > > /***************************************************/ > > int write_exact(byte *buf, int len) > { > int i, wrote = 0; > > i = write(1, buf+wrote, len-wrote); > return (i); > > > } > > /***************************************************/ > > void put_int16(int i, byte *s) > { > *s = (i >> 8) & 0xff; > s[1] = i & 0xff; > } > > > > From vlad_dumitrescu@REDACTED Tue Oct 28 10:42:59 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 28 Oct 2003 10:42:59 +0100 Subject: Erlang module for SWIG? References: Message-ID: From: "C.Reinke" > while SWIG has its own interest, perhaps you might find the route > useful that Daan Leijen has chosen for creating the Haskell binding > to wxWindows: > > http://wxhaskell.sourceforge.net/ Very interesting! If I was to give this a shot, this is what I would do, FWIIW: create a wxWindows standalone application that exposes all wxWindows functionality via a message inteface and uses TCP to communicate with the extenal client(s). Since the whole API is huge, this would need to make use of automatisation on a large scale, both for the C/C++ side and for the Erlang one. Also, I think that it would be good to try to make the interface as high-level as possible, to minimize the amount of traffic. Since there will have to be conversion of data between Erlang and C anyway, I don't think that using a socket connection would be much slower than a port program or a driver. Just my 1 ?re. Regards, Vlad From david.wallin@REDACTED Tue Oct 28 12:28:49 2003 From: david.wallin@REDACTED (david wallin) Date: Tue, 28 Oct 2003 11:28:49 +0000 Subject: BUG in HiPE In-Reply-To: <200310261239.h9QCdk5J017351@harpo.it.uu.se> Message-ID: Thank you for fixing this so swiftly. I would be interested in such patches, unless R9C-1 is just around the corner. cheers, --david. On Sunday, October 26, 2003, at 12:39 PM, Kostis Sagonas wrote: > On Wed, 22 Oct 2003, David Wallin reported two HiPE bugs. > > These bugs have now been fixed and, if needed, patches can be sent > to interested users of HiPE. The fixes will be available in the > next release of Erlang/OTP R9C. > > We sincerely thank David for reporting them. > > Best, > Kostis Sagonas (for the HiPE team). From micael.karlberg@REDACTED Tue Oct 28 14:20:30 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Tue, 28 Oct 2003 14:20:30 +0100 Subject: streamMode variable In-Reply-To: <33806.65.198.40.11.1067284006.squirrel@unimail.uninet.com.py> References: <33426.65.198.40.11.1067268117.squirrel@unimail.uninet.com.py> <16285.20423.881923.960766@gargle.gargle.HOWL> <33806.65.198.40.11.1067284006.squirrel@unimail.uninet.com.py> Message-ID: <16286.27934.339131.852959@gargle.gargle.HOWL> Hi, There is a number of errors. 'streams' in 'MediaDescriptor' and 'descriptors' in 'AmmRequest'. Below is a corrected addcommand function: addcommand(Pid, CH) -> LCD1 = #'LocalControlDescriptor'{streamMode=recvOnly}, SP1 = #'StreamParms'{localControlDescriptor=LCD1}, MEDIA1 = #'MediaDescriptor'{streams={oneStream, SP1}}, ADD1 = #'AmmRequest'{terminationID=[#megaco_term_id{id=?A4444}] , descriptors=[{mediaDescriptor, MEDIA1}]}, CR1 = #'CommandRequest'{command={addReq, ADD1}}, AR = #'ActionRequest'{contextId=?megaco_choose, commandRequests=[CR1]}, megaco:call(CH, [AR], []). I will add a test function in the megaco module so that it's possible to test the message ([AR]) input to the call/cast functions (offline). /BMK mwilligs@REDACTED writes: > Hi > Thaks for the answer. > my problem is the following: > > I wana make an 'add' command: > > Context=$ > { > Add=A4444 > { > Media > { > LocalControl{Mode = SendRecv} > } > } > } > > And this is my code: > > where > CH={megaco_conn_handle,{deviceName,"ctrl"},{deviceName,"mg"}} > > %%%% > addcommand(Pid,CH)-> > > LCD1=#'LocalControlDescriptor'{streamMode=recvOnly}, > SP1=#'StreamParms'{localControlDescriptor=LCD1}, > MEDIA1=#'MediaDescriptor'{streams=SP1}, > ADD1=#'AmmRequest'{terminationID=[#megaco_term_id{id=?A4444}] , > descriptors=MEDIA1}, > CR1=#'CommandRequest'{command={addReq, ADD1}}, > AR=#'ActionRequest'{contextId=?megaco_choose, commandRequests=[CR1]}, > megaco:cast(CH, [AR], []). > %%%%%% > > > > what's wrong in this code?? > > How can I make a test to find errors in my megaco packets? > > Thanks again > > > Hi, > > > > LCD1=#'LocalControlDescriptor'{streamMode = recvOnly} is the correct. > > What kind of problems did you encounter? > > > > /BMK > > > > > > mwilligs@REDACTED writes: > > > In the file megaco_message_v1.hlr the structure LocalControlDescriptor > > > have the streamMode variable. > > > > > > Witch are the posible values of streamMode? > > > In the RFC 3015 page 91 is defined as follow: > > > StreamMode ::= ENUMERATED > > > { > > > sendOnly(0), > > > recvOnly(1), > > > sendRecv(2), > > > ... > > > } > > > The point is: Is it right to write it this way in erlang?: > > > LCD1=#'LocalControlDescriptor'{streamMode=2} > > > or shall I write it in this way?: > > > LCD1=#'LocalControlDescriptor'{streamMode=recvOnly} > > > > > > Because, appareantly neither of this ways is correct. > > > > > > thanks in advance > > > > -- > > Micael Karlberg Ericsson AB, ?lvsj? Sweden > > Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > > ECN: 851 5668 Mail: micael.karlberg@REDACTED > > Fax: +46 8 727 5775 > > -- Micael Karlberg Ericsson AB, ?lvsj? Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@REDACTED Fax: +46 8 727 5775 From enewhuis@REDACTED Tue Oct 28 20:24:45 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Tue, 28 Oct 2003 13:24:45 -0600 Subject: Latest Erlang on Mac OS X Panther Message-ID: <635DCA08-097C-11D8-B73C-000A95D9A520@futuresource.com> I wish to run the latest OTP on Mac running OS X Panther. Can anyone offer any latest guidance? I've seen the postings for former releases, mined them for important bits, and so far have not been able to compile R9C-0 from source without running into this error: gcc -o /Users/enewhuis/Foundry/otp_releases/otp_src_R9C-0/bin/powerpc-apple- darwin7.0.0/beam.shared ... ... ld: Undefined symbols: _z_errmsg I am willing to invest time to get this working on the Mac but I would like to avoid redundant work if someone else already has the answer. Sincerely, Eric Newhuis From bjorn@REDACTED Wed Oct 29 07:30:01 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 29 Oct 2003 07:30:01 +0100 Subject: Latest Erlang on Mac OS X Panther In-Reply-To: Eric Newhuis's message of "Tue, 28 Oct 2003 13:24:45 -0600" References: <635DCA08-097C-11D8-B73C-000A95D9A520@futuresource.com> Message-ID: Is that linking problem only for the Shared Heap emulator? In that case, a simply workaround would be to comment out the building of the Shared Heap emulator from the Makefile, as it is not critical for building the rest of OTP. We (OTP) will look into this problem, but as Mac OS X is not one of our commercial platforms it may take some time. For the time being, we let our only Mac continue to run Jaguar. However, as soon as I get Panther on my Mac at home (est. mid November), I'll look into this problem. /Bjorn Eric Newhuis writes: > I wish to run the latest OTP on Mac running OS X Panther. > > Can anyone offer any latest guidance? I've seen the postings for > former releases, mined them for important bits, and so far have not > been able to compile R9C-0 from source without running into this error: > > gcc -o > /Users/enewhuis/Foundry/otp_releases/otp_src_R9C-0/bin/powerpc-apple- > darwin7.0.0/beam.shared ... > ... > ld: Undefined symbols: > _z_errmsg > > I am willing to invest time to get this working on the Mac but I would > like to avoid redundant work if someone else already has the answer. > > Sincerely, > Eric Newhuis > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From bjarne@REDACTED Wed Oct 29 12:33:15 2003 From: bjarne@REDACTED (=?iso-8859-1?Q?Bjarne_D=E4cker?=) Date: Wed, 29 Oct 2003 12:33:15 +0100 Subject: Welcome to EUC'2003 !!! Message-ID: <001d01c39e10$71ae0080$f42469d4@segeltorp> Hello All Erlang users, developers, friends, hangers-on etc. are invited to this year's Erlang/OTP User Conference. Please see the invitation at http://www.erlang.se/euc/03/ and the exciting conference programme at http://www.erlang.se/euc/03/Programme.html To register for the EUC'2003 just send an e-mail to euc@REDACTED Welcome Bjarne (on behalf of the Erlang/OTP team) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Oct 30 02:19:18 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 30 Oct 2003 14:19:18 +1300 (NZDT) Subject: Language change proposal Message-ID: <200310300119.h9U1JIPT471120@atlas.otago.ac.nz> "Robert Virding" wrote: But I still say the preprocessor should never have been added. Richard where is the Ada reasoning about a preprocessor described? If I had been able to come up with Richard O'Keefe's Abstract Data Types this would have been a much better solution. The requirement was stated in Steelman 2C. (http://www.adahome.com/History/Steelman/steelman.htm#2) 2C. Syntactic Extensions. The user shall not be able to modify the source language syntax. In particular, the user shall not be able to introduce new precedence rules or to define new syntactic forms. Basically, they didn't want an extensible language (like Algol 68 or CGOL, which let you introduce new operators, or like Pop with its templates which I actually found very nice to use). If we are going to talk about return on investment, that's precisely what this is all about. They wanted to make sure that there were no unnecessary barriers to building tools that could analyse Ada source code, and that every maintainer would be reading the same language. I find the fact that I can't build an Erlang analysis tool without having to emulate all that preprocessor fertiliser incredibly sad; put the preprocessor and records together, and you've roughly doubled the size of a simple tool. Yes, I know it's easy if you do it in Erlang using the appropriate existing module. But that simply emphasises how hard it is to do it any _other_ way. >From http://www.faqs.org/faqs/computer-lang/Ada/programming/part3/ question 8.7: .7: Does Ada have macros? No, neither Ada 83 nor Ada 95 do. There was a Steelman requirement that the language developed NOT have a macro capability. This was a well thought-out requirement. What you see in a piece of Ada code is what you get (within a debugger for example). This does not hold true for macro languages. General text-substitution macros like those in the C preprocessor are thought to be too unsafe. For example, a macro can refer to a variable X and depending where the macro is expanded X may or may not be visible. Ada programs are supposed to be readable and in many cases C macros are the main culprits in producing unreadable C programs. Compile time macro facilities tend to be dreadfully over- and misused, resulting in horrible maintenance problems. Furthermore, there is a tendency to use macros to patch up glaring omissions in the language. For example, C has no named constants, a very bad omission, but #define is used to patch over this gap. In C, three "legitimate" uses of macros are for defining compile-time constants, types, and inline functions. Ada has all three of these facilities, without macros. If one wants macros to handle conditional compilation, the better way to achieve the equivalent is in most instances to isolate the system dependent parts and then put them in separate units with multiple system-specific implementations. Because Erlang has pattern matching, inline functions are not quite good enough to handle compile-time constants. That's what Abstract Patterns were invented for. Cross-module inlining would be made possible by the -import_early directive I once described. This is why you need guardians so that it will be clear and consistent. As I have said before one of our, the original implementors, main faults was not actually explaining and writing down our basic concepts. To us they were so clear they need no explanantion. Of course sometimes we weren't in agreement as to the concepts. :-) It's surely not too late to write them down now. From ok@REDACTED Fri Oct 31 05:01:37 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 31 Oct 2003 17:01:37 +1300 (NZDT) Subject: www.erlang.{org,se} Message-ID: <200310310401.h9V41bI2011787@atlas.otago.ac.nz> For a couple of days now I have been trying to visit those sites. It doesn't seem to matter whether I use Netscape, Opera, or Amaya, they can't find those sites, yet on two machines where I've tried I can get to all sorts of places. Nor does erlang.org (no leading "www.") work. What happened? From ok@REDACTED Wed Oct 29 23:35:46 2003 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 30 Oct 2003 11:35:46 +1300 (NZDT) Subject: Language change proposal Message-ID: <200310292235.h9TMZkhv457381@atlas.otago.ac.nz> Chris Pressey persists: Ah, but the rivers of the Erlang support list are choked with the bodies of keyboard-pounding language designers, are they not? Guardians of Truth and Beauty, each and every one of us, who do not seem to realize that Erlang is not a project in pursuit of perfect language purity. It is, in fact, an exercise in return-on-investment (right, Mr. Ericsson?) False dichotomy. And defining a new predefined macro is just about as small an investment there is. Predefined macros aren't *investments*, they are *penalties*. Take it one small step further and add -assert() to -ifdef() and friends, and I for one have a hard time explaining the difference between -requires_erlang('5.3'). and -assert(?ERLANG_VERSION, '5.3'). in terms that the average non-language-designing Erlang programmer would appreciate or care about. It is incredibly simple. -assert (which does not and should not exist; we should be looking for ways to excise the preprocessor cancer, not pumping it full of growth hormones) can appear too late. You *CAN'T* check Erlang version using a feature whose very removal is one of the things you want to protect against. Oddly enough, when it comes to reading an Erlang source file, an Erlang processor has the same two problems that an XML processor has when reading an XML document. (1) What character set encoding was used? One of the long term goals for Erlang is that it should support Unicode; many existing Erlang users already combine Erlang and XML (hence xmerl, amongst others), and XML requires Unicoode. If you are going to process XML in Erlang, it is helpful if you can represent XML identifiers as Erlang atoms, and at a minimum you need to be able to hold Unicode characters in strings. I'd be happy with ISO Latin 1 as the default encoding, but I suppose Windows programmers wouldn't be, and in today's Europe, it could be useful to be able to mention the Euro, so 8859-15 might be a good choice; need I go on? (2) Which version of the language specification is to be used? There is no reason to expect that every future version of Erlang will _have_ a preprocessor. The "erlang declaration" still needs to be usable, so it _can't_ use a preprocessor kluge. We come up with the fairly obvious result that something like -erlang(Encoding, Version). is needed, where "-erlang(" must literally be the first 8 characters of the source file, the Encoding written as an unquoted Erlang atom follows with no spaces, and then the language version. This also has the nice effect of making it easy to tell the UNIX 'file' command how to recognise Erlang source files. By the way, whatever you call "assert", it's not a macro. If Chris Pressey _doesn't_ want to see the same kind of preprocessor mess that makes maintaining other people's C code a challenge, he should not have wasted our time suggesting it. From ulf.wiger@REDACTED Thu Oct 30 17:06:31 2003 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Thu, 30 Oct 2003 17:06:31 +0100 Subject: surprising result with hipe compilation Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5402595@ESEALNT442.al.sw.ericsson.se> From: Mikael Pettersson [mailto:mikpe@REDACTED] >To summarise: You compile to native code and save it in files, >and then benchmark it with timer:tc as the first thing you >do in a fresh system. This gives much worse results (longer >time taken) than if the code was only in BEAM. Yes, obviously, but this is not what I did. I called timer:tc(...) several times and picked the fastest one. >If one repeats the timer:tc call, the runtime for both BEAM and >native code is reduced to normal levels, and native code is >consistently (for your code) faster than BEAM. This is not what happens on my machine (a 400 MHz Ultra 10): [etxuwig@REDACTED]: erlc +native *.erl [etxuwig@REDACTED]: which erl /OTP/LXA_11930_R9C_3/bin/erl [etxuwig@REDACTED]: erl -boot start_clean -pa . Erlang (BEAM) emulator version 5.3 [hipe] [threads:0] Eshell V5.3 (abort with ^G) 1> timer:tc(test,run,[]). {334894, {ok,[{name,"file_server"}, {vsn,"ubf1.0"}, {types,[{info,{constant,info},[]}, {description,{constant,description},[]}, {services,{constant,services},[]}, {contract,{constant,contract},[]}, {file,{prim,string},[]}, {ls,{constant,ls},[]}, {files,{tuple,[{constant,files},{list,{prim,file}}]},[]}, {getFile,{tuple,[{constant,get},{prim,file}]},[]}, {noSuchFile,{constant,noSuchFile},[]}]}, {transition,{start,[{input,{prim,ls},[{output,{prim,files},start}]}, {input,{prim,getFile}, [{output,{prim,binary},start}, {output,{prim,noSuchFile},stop}]}]}}, {anystate,[{{prim,info},{prim,string}}, {{prim,description},{prim,string}}, {{prim,contract},{prim,term}}]}]}} 2> element(1,timer:tc(test,run,[])). 10511 3> element(1,timer:tc(test,run,[])). 27083 4> element(1,timer:tc(test,run,[])). 11149 5> element(1,timer:tc(test,run,[])). 10846 6> element(1,timer:tc(test,run,[])). 11326 7> element(1,timer:tc(test,run,[])). 10887 8> element(1,timer:tc(test,run,[])). 10573 9> BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution a [etxuwig@REDACTED]: erlc -W *.erl [etxuwig@REDACTED]: erl -boot start_clean -pa . Erlang (BEAM) emulator version 5.3 [hipe] [threads:0] Eshell V5.3 (abort with ^G) 1> timer:tc(test,run,[]). {36540, {ok,[{name,"file_server"}, {vsn,"ubf1.0"}, {types,[{info,{constant,info},[]}, {description,{constant,description},[]}, {services,{constant,services},[]}, {contract,{constant,contract},[]}, {file,{prim,string},[]}, {ls,{constant,ls},[]}, {files,{tuple,[{constant,files},{list,{prim,file}}]},[]}, {getFile,{tuple,[{constant,get},{prim,file}]},[]}, {noSuchFile,{constant,noSuchFile},[]}]}, {transition,{start,[{input,{prim,ls},[{output,{prim,files},start}]}, {input,{prim,getFile}, [{output,{prim,binary},start}, {output,{prim,noSuchFile},stop}]}]}}, {anystate,[{{prim,info},{prim,string}}, {{prim,description},{prim,string}}, {{prim,contract},{prim,term}}]}]}} 2> element(1,timer:tc(test,run,[])). 6054 3> element(1,timer:tc(test,run,[])). 6451 4> element(1,timer:tc(test,run,[])). 5938 5> element(1,timer:tc(test,run,[])). 6226 6> element(1,timer:tc(test,run,[])). 6407 7> BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded (v)ersion (k)ill (D)b-tables (d)istribution a When compiled with hipe, the code runs significantly slower. Dynamic loading of modules is indeed much (10x) slower when compiled to native code. I tried running a call trace to find out which other modules were used in the test. It was just prim_file.erl and io_lib.erl, but compiling those two as well (esp. prim_file.erl) made the test run slightly slower still when compiled with hipe. /Uffe From mwilligs@REDACTED Wed Oct 29 22:01:45 2003 From: mwilligs@REDACTED (mwilligs@REDACTED) Date: Wed, 29 Oct 2003 18:01:45 -0300 (PYST) Subject: Doubs building the ADD package Message-ID: <33008.65.198.40.11.1067461305.squirrel@unimail.uninet.com.py> I wanna do this ... Local { v=0 c=in IP4 $ m=audio $ RTP/AVP 4 } ... what wrong in de line "PropGrps1=cre_PropertyParm(v,"0")" because in this line the error jump cre_PropertyParm(Name,Value)-> #'PropertyParm'{name=Name,value=Value}. ... PropGrps3=cre_PropertyParm(m,"audio $ RTP/AVP"), PropGrps2=cre_PropertyParm(c,"IN IP4 $"), PropGrps1=cre_PropertyParm(v,"0"), LRD1 = cre_LocalRemoteDescriptor([PropGrps1]),%%%here fail, I proved with 0 insteaded of "0" % %for introducing more propgrps it's like this : % LRD1 = cre_LocalRemoteDescriptor([PropGrps1,PropGrps2,PropGrps3]),%%%here fail %LRD1 = cre_LocalRemoteDescriptor([]),%that work %that work LCD1 = cre_LocalControlDescriptor(sendRecv), SP3 = cre_StreamParms({remoteDescriptor, LRD1}), SP2 = cre_StreamParms({localDescriptor, LRD1}), SP1 = cre_StreamParms({localControlDescriptor, LCD1}), MEDIA1 = cre_MediaDescriptor(oneStream,SP3), ADD1 = cre_Ammrequest(?A4444, mediaDescriptor, MEDIA1), CR1 = cre_commandReq({addReq, ADD1}), AR = cre_actionReq(?megaco_choose, [CR1]). ... From mikpe@REDACTED Thu Oct 30 15:06:05 2003 From: mikpe@REDACTED (Mikael Pettersson) Date: Thu, 30 Oct 2003 15:06:05 +0100 Subject: surprising result with hipe compilation In-Reply-To: <37FB7AA6F5F9814FB634A7BF4C35A6F540257A@ESEALNT442.al.sw.ericsson.se> References: <37FB7AA6F5F9814FB634A7BF4C35A6F540257A@ESEALNT442.al.sw.ericsson.se> Message-ID: <16289.6861.905174.110440@alkaid.it.uu.se> Ulf Wiger (AL/EAB) writes: > > H?r ?r lite kod som kan ?terskapa problemet: > > Jag har klippt in en provk?rning, med och utan hipe-kompilering. > Jag klockade genom att k?ra testfunktionen m?nga g?nger och > j?mf?ra b?sta tiden f?r resp. (hipe: 13.8 ms, icke-hipe: 6.1 ms) > > N?gra moduler var inte nativekompilerade: io, lists och eventuella > hj?lpmoduler till dem. > > /Uffe > > [etxuwig@REDACTED]: erlc -W +native *.erl > [etxuwig@REDACTED]: erl -boot start_clean > Erlang (BEAM) emulator version 5.2.3.1 [hipe] [threads:0] > > Eshell V5.2.3.1 (abort with ^G) > ... > 2> timer:tc(test,run,[]). To summarise: You compile to native code and save it in files, and then benchmark it with timer:tc as the first thing you do in a fresh system. This gives much worse results (longer time taken) than if the code was only in BEAM. I also tested compiling your code into a live system and that did not show this performance degradation. At first I suspected a loader bug which might cause excessive switches between BEAM and native code, but that turned out to not be the case at all. The problem is that when you invoke Erlang code in a fresh system, the system internally traps the first time a not-yet-loaded module is accessed. The module is located and loaded, internal tables are updated, and then the access is continued. In your case, timer:tc includes the time needed to trap-and-load your modules. You're seeing larger values for native code than BEAM code simply because loading native code is a heavyweight operation. If one repeats the timer:tc call, the runtime for both BEAM and native code is reduced to normal levels, and native code is consistently (for your code) faster than BEAM. Workarounds: explicitly load the necessary modules before calling timer:tc, or even better, run it once to load the code and prime the caches, and then again "for real". /Mikael From nicolas.niclausse@REDACTED Wed Oct 29 15:54:57 2003 From: nicolas.niclausse@REDACTED (Nicolas Niclausse) Date: Wed, 29 Oct 2003 15:54:57 +0100 Subject: limitations of SSL In-Reply-To: <3F98EBDA.9000300@ericsson.com> (Bengt Kleberg's message of "Fri, 24 Oct 2003 11:07:38 +0200") References: <20031022092925.6115a375.cpressey@catseye.mine.nu> <3F98EBDA.9000300@ericsson.com> Message-ID: <7bsmlcccvy.fsf_-_@schultze.ird.idealx.com> Hello, The SSL Release Notes state that ?Erlang SSL applicaton does not support session ?, and hence you can't reuse SSL id accross connections; Is it planned for the next release of Erlang ? I tried to handle more than 1024 concurrent connections with Yaws; it works well with HTTP (i raised my system's limit with 'ulimit -n 2048'), but don't with HTTPS (on a Linux system with erlang R9C). Is it possible to raise this limit with HTTPS (SSL) ? -- Nicolas NICLAUSSE IDEALX S.A.S. T?l:01 44 42 00 00 http://IDEALX.com/ From Jouni.Ryno@REDACTED Thu Oct 30 19:58:28 2003 From: Jouni.Ryno@REDACTED (Jouni Ryno) Date: Thu, 30 Oct 2003 20:58:28 +0200 Subject: Makefile, make_script and local Message-ID: <1067540308.1744.31.camel@catmind.ryno> Hi Is there any hmm. elegant way to make a boot script in a Makefile, when it should get (at least) the local-parameter i.e. I'm looking for something like $ erl -run systools make_sript my_app local It somehow feels ugly to make a wrapper program for just 1> systools:make_script("my_app", [local])... Hmm. an erl-parameter option, which would be handled with string to term would be nice ... regards Jouni -- Jouni Ryno Finnish Meteorological Institute From joachim.durchholz@REDACTED Fri Oct 31 11:38:46 2003 From: joachim.durchholz@REDACTED (Joachim Durchholz) Date: Fri, 31 Oct 2003 11:38:46 +0100 Subject: Language change proposal In-Reply-To: <200310292235.h9TMZkhv457381@atlas.otago.ac.nz> References: <200310292235.h9TMZkhv457381@atlas.otago.ac.nz> Message-ID: <3FA23BB6.7020301@web.de> Richard A. O'Keefe wrote: > One of the long term goals for Erlang is that it should support Unicode; This is something that I'd advise against. True, it would be nice to be able to write your source code using native-language identifiers witout having to worry about ASCII representation. However, there are two problems here: 1) If somebody gives me software to maintain, I might hit a, say, Chinese glyph somewhere. I'd have to download the proper font just to be able to look at the sources. I have programmed in Java, which also uses Unicode. I tend to avoid the German special characters ??????? even if I program in German; I use their transcriptions AE OE UE ae oe ue ss instead. 2) There are many glyphs that look the same. For example, that "a" letter might actually have an entirely different encoding since it's from the Russian alphabet. Unicode also has issues with letter case. For one, there is no good mapping of lowercase and uppercase letters (and cannot be: for example, the German ? has no uppercase equivalent, it transliterates to SS or SZ depending on personal whim). Additionally, Unicode has /three/ lettercase categories: lower, upper, and title case. (The latter information is gleaned from the Haskell language report, I don't know anything further about Unicode.) (There's also a portability issue: there are still EBCDIC machines around that don't support Unicode. I don't think this is relevant for Erlang though *g*) My personal idea about Unicode is that it is massively overengineered for simple tasks like representing source code. With one exception: it would be very nice if the language allowed Unicode within string literals. That's more a question of how to integrate binary data into source code well. > many existing Erlang users already combine Erlang and XML (hence xmerl, > amongst others), and XML requires Unicoode. If you are going to process > XML in Erlang, it is helpful if you can represent XML identifiers as > Erlang atoms, and at a minimum you need to be able to hold Unicode > characters in strings. > I'd be happy with ISO Latin 1 as the default encoding, but I suppose > Windows programmers wouldn't be, and in today's Europe, it could be > useful to be able to mention the Euro, so 8859-15 might be a good > choice; need I go on? What are the advantages of keeping some XML data as atoms? I would have thought that, ultimately, they are just strings, and all techniques that apply to atoms should apply to strings as well. About ISO Latin and Windows: That's one of the reasons why I don't use umlauts in my source code, except when it comes to literal strings. And I'm painfully aware that having umlauts in strings makes my sources nonportable; the better solution is to have some internationalization support. Regards, Jo From gunilla@REDACTED Fri Oct 31 12:55:57 2003 From: gunilla@REDACTED (Gunilla Arendt) Date: Fri, 31 Oct 2003 12:55:57 +0100 Subject: Makefile, make_script and local References: <1067540308.1744.31.camel@catmind.ryno> Message-ID: <3FA24DCD.89B28373@erix.ericsson.se> Hi, You can use erlc: % erlc -I myapp-1/ebin myrel.rel See man page for erlc for more information. / Gunilla Jouni Ryno wrote: > > Hi > > Is there any hmm. elegant way to make a boot script in a Makefile, when > it should get (at least) the local-parameter > i.e. I'm looking for something like > $ erl -run systools make_sript my_app local > It somehow feels ugly to make a wrapper program for just > 1> systools:make_script("my_app", [local])... > > Hmm. an erl-parameter option, which would be handled with string to term > would be nice ... > > regards > Jouni > -- > Jouni Ryno > Finnish Meteorological Institute -- _____Gunilla Arendt______________________________________________ EAB/UKH/KD Erlang/OTP Product Development Gunilla.Arendt@REDACTED +46-8-7275730 ecn 851 5730 From gunilla@REDACTED Fri Oct 31 13:04:10 2003 From: gunilla@REDACTED (Gunilla Arendt) Date: Fri, 31 Oct 2003 13:04:10 +0100 Subject: Makefile, make_script and local References: <1067540308.1744.31.camel@catmind.ryno> Message-ID: <3FA24FBA.5FD7D399@erix.ericsson.se> Whoops! Sorry about my previous reply, I should try to read emails more carefully in the future. erlc is of course of no help to you, either, as it can't be used to send the 'local' option to systools:make_script. / Gunilla again Jouni Ryno wrote: > > Hi > > Is there any hmm. elegant way to make a boot script in a Makefile, when > it should get (at least) the local-parameter > i.e. I'm looking for something like > $ erl -run systools make_sript my_app local > It somehow feels ugly to make a wrapper program for just > 1> systools:make_script("my_app", [local])... > > Hmm. an erl-parameter option, which would be handled with string to term > would be nice ... > > regards > Jouni > -- > Jouni Ryno > Finnish Meteorological Institute -- _____Gunilla Arendt______________________________________________ EAB/UKH/KD Erlang/OTP Product Development Gunilla.Arendt@REDACTED +46-8-7275730 ecn 851 5730 From bjorn@REDACTED Fri Oct 31 13:34:19 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 31 Oct 2003 13:34:19 +0100 Subject: Makefile, make_script and local In-Reply-To: <3FA24FBA.5FD7D399@erix.ericsson.se> References: <1067540308.1744.31.camel@catmind.ryno> <3FA24FBA.5FD7D399@erix.ericsson.se> Message-ID: The way to pass arbitrary options via erlc is to prefix them with '+'. That is, the following should probably work: % erlc +native -I myapp-1/ebin myrel.rel /Bjorn Gunilla Arendt writes: > Whoops! > > Sorry about my previous reply, I should try to read emails more > carefully in the future. erlc is of course of no help to you, > either, as it can't be used to send the 'local' option to > systools:make_script. > > / Gunilla again > > > Jouni Ryno wrote: > > > > Hi > > > > Is there any hmm. elegant way to make a boot script in a Makefile, when > > it should get (at least) the local-parameter > > i.e. I'm looking for something like > > $ erl -run systools make_sript my_app local > > It somehow feels ugly to make a wrapper program for just > > 1> systools:make_script("my_app", [local])... > > > > Hmm. an erl-parameter option, which would be handled with string to term > > would be nice ... > > > > regards > > Jouni > > -- > > Jouni Ryno > > Finnish Meteorological Institute > > -- > _____Gunilla Arendt______________________________________________ > EAB/UKH/KD Erlang/OTP Product Development > Gunilla.Arendt@REDACTED +46-8-7275730 ecn 851 5730 > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From Jouni.Ryno@REDACTED Fri Oct 31 14:05:24 2003 From: Jouni.Ryno@REDACTED (Jouni =?ISO-8859-1?Q?Ryn=F6?=) Date: Fri, 31 Oct 2003 15:05:24 +0200 Subject: Makefile, make_script and local In-Reply-To: References: <1067540308.1744.31.camel@catmind.ryno> <3FA24FBA.5FD7D399@erix.ericsson.se> Message-ID: <1067605523.7376.26.camel@adic.fmi.fi> so it does: $ erlc +local +exref -I ebin/ -o ebin/ ebin/db_app.rel On Fri, 2003-10-31 at 14:34, Bjorn Gustavsson wrote: > The way to pass arbitrary options via erlc is to prefix them with '+'. > That is, the following should probably work: > > % erlc +native -I myapp-1/ebin myrel.rel > > /Bjorn > > Gunilla Arendt writes: > > > Whoops! > > > > Sorry about my previous reply, I should try to read emails more > > carefully in the future. erlc is of course of no help to you, > > either, as it can't be used to send the 'local' option to > > systools:make_script. > > > > / Gunilla again > > > > > > Jouni Ryno wrote: > > > > > > Hi > > > > > > Is there any hmm. elegant way to make a boot script in a Makefile, when > > > it should get (at least) the local-parameter > > > i.e. I'm looking for something like > > > $ erl -run systools make_sript my_app local > > > It somehow feels ugly to make a wrapper program for just > > > 1> systools:make_script("my_app", [local])... > > > > > > Hmm. an erl-parameter option, which would be handled with string to term > > > would be nice ... > > > > > > regards > > > Jouni > > > -- > > > Jouni Ryno > > > Finnish Meteorological Institute > > > > -- > > _____Gunilla Arendt______________________________________________ > > EAB/UKH/KD Erlang/OTP Product Development > > Gunilla.Arendt@REDACTED +46-8-7275730 ecn 851 5730 > > -- Jouni Ryn? mailto://Jouni.Ryno@REDACTED/ http://www.geo.fmi.fi/~ryno/ Finnish Meteorological Institute http://www.fmi.fi/ Geophysical Research http://www.geo.fmi.fi/ P.O.BOX 503 Tel (+358)-9-19294656 FIN-00101 Helsinki FAX (+358)-9-19294603 Finland priv-GSM (+358)-50-5302903 "It's just zeros and ones, it cannot be hard" From erlang@REDACTED Fri Oct 31 14:55:50 2003 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 31 Oct 2003 13:55:50 +0000 Subject: www.erlang.{org,se} In-Reply-To: <200310310401.h9V41bI2011787@atlas.otago.ac.nz> References: <200310310401.h9V41bI2011787@atlas.otago.ac.nz> Message-ID: <20031031135550.100d8daa.erlang@manderp.freeserve.co.uk> You're not the only one. It seems fine right now. Did solar flares hit Ericsson? Pete. On Fri, 31 Oct 2003 17:01:37 +1300 (NZDT) "Richard A. O'Keefe" wrote: > For a couple of days now I have been trying to visit those sites. > It doesn't seem to matter whether I use Netscape, Opera, or Amaya, > they can't find those sites, yet on two machines where I've tried > I can get to all sorts of places. Nor does erlang.org (no leading > "www.") work. What happened? > -- "The Tao of Programming flows far away and returns on the wind of morning." From micael.karlberg@REDACTED Fri Oct 31 15:09:19 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Fri, 31 Oct 2003 15:09:19 +0100 Subject: Doubs building the ADD package In-Reply-To: <33008.65.198.40.11.1067461305.squirrel@unimail.uninet.com.py> References: <33008.65.198.40.11.1067461305.squirrel@unimail.uninet.com.py> Message-ID: <16290.27919.788430.424478@gargle.gargle.HOWL> Hi, There is two problems: 1) The LocalRemoteDescriptor.propGrps is not a list of PropertyParm. It's actually a list of PropertyGroup, which is a list of PropertyParm. In our case it means, you should write e.g. [[PropGrps1]] (I am gessing that your cre_LocalRemoteDescriptor function does not wrap this). 2) In the PropertyParm record, the name part is a string, e.g. "v", and the value part is a list of length 1 of a string, e.g. ["0"]. So, using your function this would mean: cre_PropertyParm("v", ["0"]) Suggestion for cre_PropertyParm: cre_PropertyParm(Name, Value) when list(Name), list(Value) -> #'PropertyParm'{name = Name, value = [Value]}. Regards, /BMK mwilligs@REDACTED writes: > I wanna do this > > ... > Local { > v=0 > c=in IP4 $ > m=audio $ RTP/AVP 4 > } > ... > what wrong in de line "PropGrps1=cre_PropertyParm(v,"0")" because in this > line the error jump > > cre_PropertyParm(Name,Value)-> > #'PropertyParm'{name=Name,value=Value}. > > > > ... > PropGrps3=cre_PropertyParm(m,"audio $ RTP/AVP"), > PropGrps2=cre_PropertyParm(c,"IN IP4 $"), > PropGrps1=cre_PropertyParm(v,"0"), > LRD1 = cre_LocalRemoteDescriptor([PropGrps1]),%%%here fail, I proved with > 0 insteaded of "0" > % > %for introducing more propgrps it's like this : > % LRD1 = > cre_LocalRemoteDescriptor([PropGrps1,PropGrps2,PropGrps3]),%%%here fail > > %LRD1 = cre_LocalRemoteDescriptor([]),%that work > > %that work > LCD1 = cre_LocalControlDescriptor(sendRecv), > SP3 = cre_StreamParms({remoteDescriptor, LRD1}), > SP2 = cre_StreamParms({localDescriptor, LRD1}), > SP1 = cre_StreamParms({localControlDescriptor, LCD1}), > MEDIA1 = cre_MediaDescriptor(oneStream,SP3), > ADD1 = cre_Ammrequest(?A4444, mediaDescriptor, MEDIA1), > CR1 = cre_commandReq({addReq, ADD1}), > AR = cre_actionReq(?megaco_choose, [CR1]). > ... -- Micael Karlberg Ericsson AB, ?lvsj? Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@REDACTED Fax: +46 8 727 5775 From enewhuis@REDACTED Fri Oct 31 15:10:07 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 31 Oct 2003 08:10:07 -0600 Subject: Latest Erlang on Mac OS X Panther In-Reply-To: References: <635DCA08-097C-11D8-B73C-000A95D9A520@futuresource.com> Message-ID: Just to keep this thread alive I will say that no, this doesn't seem to be the only problem. I've not had time to investigate further mostly due to my indulgence in attempting to get distel working on my Panther Mac on R9B-0. I do remember that there were some problems copying files during the make. And I do remember seeing another target complain about undefined z_errmsg. Perhaps if I knew what z_errmsg is I could take the next step. I suppose I shall have to look at the erts source. I have no problem using the pre-built R9B-0 Mac OS/X release on Panther. I've been using it for a week now without any problems. However I have not tried anything that invokes the GUI. > Is that linking problem only for the Shared Heap emulator? > > In that case, a simply workaround would be to comment out > the building of the Shared Heap emulator from the Makefile, > as it is not critical for building the rest of OTP. From micael.karlberg@REDACTED Fri Oct 31 15:33:01 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Fri, 31 Oct 2003 15:33:01 +0100 Subject: Latest Erlang on Mac OS X Panther In-Reply-To: References: <635DCA08-097C-11D8-B73C-000A95D9A520@futuresource.com> Message-ID: <16290.29341.193298.788647@gargle.gargle.HOWL> A google indicate that it's defined in zlib (zlib/zutil.h). /BMK Eric Newhuis writes: > Just to keep this thread alive I will say that no, this doesn't seem to > be the only problem. I've not had time to investigate further mostly > due to my indulgence in attempting to get distel working on my Panther > Mac on R9B-0. > > I do remember that there were some problems copying files during the > make. And I do remember seeing another target complain about undefined > z_errmsg. Perhaps if I knew what z_errmsg is I could take the next > step. I suppose I shall have to look at the erts source. > > I have no problem using the pre-built R9B-0 Mac OS/X release on > Panther. I've been using it for a week now without any problems. > However I have not tried anything that invokes the GUI. > > > > Is that linking problem only for the Shared Heap emulator? > > > > In that case, a simply workaround would be to comment out > > the building of the Shared Heap emulator from the Makefile, > > as it is not critical for building the rest of OTP. -- Micael Karlberg Ericsson AB, ?lvsj? Sweden Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development ECN: 851 5668 Mail: micael.karlberg@REDACTED Fax: +46 8 727 5775 From cyberlync@REDACTED Fri Oct 31 15:46:36 2003 From: cyberlync@REDACTED (Eric Merritt) Date: Fri, 31 Oct 2003 06:46:36 -0800 (PST) Subject: Language change proposal In-Reply-To: <3FA23BB6.7020301@web.de> Message-ID: <20031031144636.3271.qmail@web40803.mail.yahoo.com> > (There's also a portability issue: there are still > EBCDIC machines > around that don't support Unicode. I don't think > this is relevant for > Erlang though *g*) EBCDIC is far, far from dead. Its usually only used on big iron like a 390 but its still used in the midrange realm on the as400s too. I wouldn't mind seeing erlang for 400s or 390s. Then you have some of the most reliable code running on some of the most reliable hardware on the planet. And no, this hardware is not old. Both of these platforms still see quite allot of use. IBM still releases upgrades and creates new versions. In fact, right now, the as/400 is probably the best general midrange server product available. I would say the same about the 390 on the high end. In any case, allot of systems still use EBCDIC. > My personal idea about Unicode is that it is > massively overengineered > for simple tasks like representing source code. > With one exception: it would be very nice if the > language allowed > Unicode within string literals. That's more a > question of how to > integrate binary data into source code well. I tend to agree. Why introduce complexity where none is needed. ASCII is probably the simplist solution that works, why switch it for something much more complex. __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ From enewhuis@REDACTED Fri Oct 31 15:52:09 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 31 Oct 2003 08:52:09 -0600 Subject: Latest Erlang on Mac OS X Panther In-Reply-To: <16290.29341.193298.788647@gargle.gargle.HOWL> References: <635DCA08-097C-11D8-B73C-000A95D9A520@futuresource.com> <16290.29341.193298.788647@gargle.gargle.HOWL> Message-ID: Yes I suppose I shall have to investigate using -Dlocal as a compiler option. There is a note in that header file pertaining to compilers not finding static variables. -Dlocal ? What a wonderful macro name. I'm sure nobody would ever use a C variable named local for anything but this purpose. > A google indicate that it's defined in zlib (zlib/zutil.h). > From bjarne@REDACTED Fri Oct 31 16:10:30 2003 From: bjarne@REDACTED (=?iso-8859-1?Q?Bjarne_D=E4cker?=) Date: Fri, 31 Oct 2003 16:10:30 +0100 Subject: www.erlang.{org,se} References: <200310310401.h9V41bI2011787@atlas.otago.ac.nz> Message-ID: <00d901c39fc2$f91e7320$5b0969d4@segeltorp> Hello, There was some change in the connection between Ericsson and Telia but it has been rectified now thanks to the efforts of a couple of competent hackers. This means that you once again can view the interesting programme of the coming Erlang/OTP User Conference http://www.erlang.se/euc/03/Programme.html To register for the EUC'2003 just send an e-mail to euc@REDACTED Welcome Bjarne ----- Original Message ----- From: "Richard A. O'Keefe" To: Sent: Friday, October 31, 2003 5:01 AM Subject: www.erlang.{org,se} > For a couple of days now I have been trying to visit those sites. > It doesn't seem to matter whether I use Netscape, Opera, or Amaya, > they can't find those sites, yet on two machines where I've tried > I can get to all sorts of places. Nor does erlang.org (no leading > "www.") work. What happened? From sean.hinde@REDACTED Fri Oct 31 16:23:57 2003 From: sean.hinde@REDACTED (Sean Hinde) Date: Fri, 31 Oct 2003 15:23:57 +0000 Subject: Latest Erlang on Mac OS X Panther In-Reply-To: <16290.29341.193298.788647@gargle.gargle.HOWL> Message-ID: <3EBBFCF0-0BB6-11D8-A2CF-000A95927CCE@mac.com> It appears to be failing to find the already compiled zlib included in the erts directory structure. This seems to suggest some weird error which causes zlib to be compiled in a way which the linker can't use, or some weird new compiler stufff in the final linking stage. Very odd. Sean On Friday, October 31, 2003, at 02:33 pm, Micael Karlberg wrote: > A google indicate that it's defined in zlib (zlib/zutil.h). > > /BMK > > Eric Newhuis writes: >> Just to keep this thread alive I will say that no, this doesn't seem >> to >> be the only problem. I've not had time to investigate further mostly >> due to my indulgence in attempting to get distel working on my Panther >> Mac on R9B-0. >> >> I do remember that there were some problems copying files during the >> make. And I do remember seeing another target complain about >> undefined >> z_errmsg. Perhaps if I knew what z_errmsg is I could take the next >> step. I suppose I shall have to look at the erts source. >> >> I have no problem using the pre-built R9B-0 Mac OS/X release on >> Panther. I've been using it for a week now without any problems. >> However I have not tried anything that invokes the GUI. >> >> >>> Is that linking problem only for the Shared Heap emulator? >>> >>> In that case, a simply workaround would be to comment out >>> the building of the Shared Heap emulator from the Makefile, >>> as it is not critical for building the rest of OTP. > > -- > Micael Karlberg Ericsson AB, ?lvsj? Sweden > Tel: +46 8 727 5668 EAB/UHK/KD - OTP Product Development > ECN: 851 5668 Mail: micael.karlberg@REDACTED > Fax: +46 8 727 5775 From jeinhorn@REDACTED Fri Oct 31 16:38:48 2003 From: jeinhorn@REDACTED (Jeff Einhorn) Date: 31 Oct 2003 09:38:48 -0600 Subject: Makefile, make_script and local In-Reply-To: <1067605523.7376.26.camel@adic.fmi.fi> References: <1067540308.1744.31.camel@catmind.ryno> <3FA24FBA.5FD7D399@erix.ericsson.se> <1067605523.7376.26.camel@adic.fmi.fi> Message-ID: <1067614727.2171.114.camel@dhcp-lom-195-14.futuresource.com> I have a similar question. This works for me: systools:make_script("test_rel", [{path, ["../../lib/*/ebin/"]}]). But can I do the same thing with erlc? Been trying stuff like the following, which does not work. erlc -W +local '+{path,["../../lib/*/ebin/"]}' test_rel.rel I can't seem to get the wildcard * with the -I option, so that route hasn't work for me either. thanks for your time, -jeff On Fri, 2003-10-31 at 07:05, Jouni Ryn? wrote: > so it does: > > $ erlc +local +exref -I ebin/ -o ebin/ ebin/db_app.rel > > > > On Fri, 2003-10-31 at 14:34, Bjorn Gustavsson wrote: > > The way to pass arbitrary options via erlc is to prefix them with '+'. > > That is, the following should probably work: > > > > % erlc +native -I myapp-1/ebin myrel.rel > > > > /Bjorn > > > > Gunilla Arendt writes: > > > > > Whoops! > > > > > > Sorry about my previous reply, I should try to read emails more > > > carefully in the future. erlc is of course of no help to you, > > > either, as it can't be used to send the 'local' option to > > > systools:make_script. > > > > > > / Gunilla again > > > > > > > > > Jouni Ryno wrote: > > > > > > > > Hi > > > > > > > > Is there any hmm. elegant way to make a boot script in a Makefile, when > > > > it should get (at least) the local-parameter > > > > i.e. I'm looking for something like > > > > $ erl -run systools make_sript my_app local > > > > It somehow feels ugly to make a wrapper program for just > > > > 1> systools:make_script("my_app", [local])... > > > > > > > > Hmm. an erl-parameter option, which would be handled with string to term > > > > would be nice ... > > > > > > > > regards > > > > Jouni > > > > -- > > > > Jouni Ryno > > > > Finnish Meteorological Institute > > > > > > -- > > > _____Gunilla Arendt______________________________________________ > > > EAB/UKH/KD Erlang/OTP Product Development > > > Gunilla.Arendt@REDACTED +46-8-7275730 ecn 851 5730 > > > -- Jeffrey M. Einhorn Platform Systems Design and Integration Manager FutureSource, LLC jeinhorn@REDACTED http://www.futuresource.com From enewhuis@REDACTED Fri Oct 31 16:40:47 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 31 Oct 2003 09:40:47 -0600 Subject: Latest Erlang on Mac OS X Panther In-Reply-To: <3EBBFCF0-0BB6-11D8-A2CF-000A95927CCE@mac.com> References: <3EBBFCF0-0BB6-11D8-A2CF-000A95927CCE@mac.com> Message-ID: <98CCA072-0BB8-11D8-B19F-000A95D9A520@futuresource.com> Could it be the Mac's cutting-edge gcc 3.3 ? > It appears to be failing to find the already compiled zlib included in > the erts directory structure. This seems to suggest some weird error > which causes zlib to be compiled in a way which the linker can't use, > or some weird new compiler stufff in the final linking stage. > > Very odd. From jeinhorn@REDACTED Fri Oct 31 18:14:52 2003 From: jeinhorn@REDACTED (Jeff Einhorn) Date: 31 Oct 2003 11:14:52 -0600 Subject: Makefile, make_script and local Message-ID: <1067620492.2171.122.camel@dhcp-lom-195-14.futuresource.com> Opps...it looks like: erlc -W -I "../../lib/*/ebin/" test_rel.rel does work with wildcards. thanks for your time, -jeff -- Jeffrey M. Einhorn Platform Systems Design and Integration Manager FutureSource, LLC jeinhorn@REDACTED http://www.futuresource.com From cpressey@REDACTED Fri Oct 31 21:23:12 2003 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 31 Oct 2003 12:23:12 -0800 Subject: Language change proposal In-Reply-To: <030001c39c80$f48f8820$2100a8c0@virding.org> References: <200310240242.h9O2gngS431493@atlas.otago.ac.nz> <20031024095321.104f5294.cpressey@catseye.mine.nu> <030001c39c80$f48f8820$2100a8c0@virding.org> Message-ID: <20031031122312.1f7596fa.cpressey@catseye.mine.nu> On Mon, 27 Oct 2003 12:53:36 +0100 "Robert Virding" wrote: > ----- Original Message ----- > From: "Chris Pressey" > > [...] > > So there you have a plausible case for using macros. > > Being the original "Guardian of Truth and Beauty" I think you have > missed the point, at least how I see it. If you want Erlang to be a > good return-on-investment over a long term then you have to be very > strict about what you allow in the language. Otherwise it will become > full of little "features" that, separately, are all innocent but put > together result in a complete mess, which is difficult to understand > and maintain. No doubt in most sane peoples' minds that this is how companies (/language projects/companies that oversee language projects) *should* operate - take the long view. The question is - do they? Indeed, given how management tends to operate, can they? And, of course the burning question is - will Ericsson? I don't just like Erlang because it's a beautiful language. I like it because it's a battle-tested production language that happens to be about two to three times more beautiful than the "national leading brand", even counting the warts. Given a choice between a wart-free Erlang and a bug-free Erlang, I'll take the bug-free one. Of course, that's a bit of false dilemma, but it speaks to where we concentrate our efforts - the more people concerned with how to make/keep Erlang small/beautiful/expressive/ orthogonal/cutting-edge, the fewer people submitting bug reports/fixes which will improve Erlang in the day-to-day humdrum of development. Yes, getting rid of the warts would be great - but will it ever become the corporate priority? I'm hoping yes, but guessing no. I'm concerned specifically that Joe's suggestion will be seen as complicating matters unnecessarily for paying customers. Which may or may not be the case, depending on the magnitude of the changes from one version to the next. But it does seem reasonable to not want to force your customers to fix things that, from their point of view (expediency), ain't broke. At least, not without offering them an alternative, like a bugfix branch of the last "unversioned" Erlang/OTP. Joe's suggestion is also interesting in that it's something you can, for the most part, already do dynamically: erts_version() -> {ok, L} = file:list_dir(code:root_dir()), lists:foldl(fun ("erts-" ++ V, A) -> case list_to_float(V) of R when R > A -> R; _ -> A end; (_, A) -> A end, 0.0, L). start() -> case of erts_version() of V when V < 5.3 -> erlang:fault({requires_erts, 5.3}); V -> continue() end. But I dasn't expound on this hack, lest my trolling further waste the reader's precious time - time that could be used for putting the finishing touches on your Hallowe'en costume, or submitting patches to make erlang:open_port/2 work correctly under Windows! :) -Chris