From bjarne@REDACTED Wed Jan 1 23:33:15 2003 From: bjarne@REDACTED (Bjarne Däcker) Date: Wed, 01 Jan 2003 23:33:15 +0100 Subject: Word origins (mnensia and mnemosyne) References: <001b01c2b019$1dcf96d0$86d0b33e@dld2000> Message-ID: <3E136CAB.B9D2132C@erix.ericsson.se> Hi > I'm curious about the origins of the words mnensia and > mnemosyne. A search in web dictionaries gives no answers, > so I assume the words are concocted by the creators of the > mnensia and mnemosyne applications -- but on what basis? Claes Wikstr?m (known as "Klacke")called the prototype DBMS "Amnesia" but he said that he had forgotten why! When it was turned into a product management didn't think it proper to use such a name so we just removed the initial "a-" which we believe is a negation in old Greek. Then Hans Nilsson selected the name Mnemosyne which we think is some Greek god. It also happens to be the name of some species of butterflies. Happy New Year Bjarne From kenneth@REDACTED Wed Jan 1 13:11:15 2003 From: kenneth@REDACTED (Kenneth Lundin) Date: Wed, 01 Jan 2003 13:11:15 +0100 Subject: ASN.1 compiler References: <006901c2aea3$89fb1130$1e00a8c0@design> Message-ID: <3E12DAE3.47C86884@erix.ericsson.se> > Eduardo Figoli wrote: > > > Where can I get an ASN.1 compiler for Windows ? > > Thanks, > Eduardo Figoli > Well you have an ASN.1 compiler in the Erlang/OTP package and it works on all platforms where you can run Erlang. Of course it does only support encode/decode from Erlang. If you really need an ASN.1 compiler for C/C++ on Windows you can try with a commercial one from OSS Nokalva, there might also be other compilers maybe also free ones. You can try looking at http://asn1.elibel.tm.fr which is a very good information source regarding ASN.1 Regards Kenneth -- From sureshsaragadam@REDACTED Thu Jan 2 06:40:30 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Thu, 2 Jan 2003 05:40:30 +0000 (GMT) Subject: Happy New Year and continued Erlang Hacking In-Reply-To: Message-ID: <20030102054030.6681.qmail@web8204.mail.in.yahoo.com> Hi Ulf, It is very nice to be here, one among the erlang programmers, it has been just few months i am working with erlnag but i can relise the impotence of OTP and its power in depth, Wish u a happy new year s suresh ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From matthias@REDACTED Thu Jan 2 08:06:43 2003 From: matthias@REDACTED (Matthias Lang) Date: Thu, 2 Jan 2003 08:06:43 +0100 Subject: Missing bookmarks in Erlang book (pdf-version) In-Reply-To: <00a301c2b10d$313986a0$add0b33e@dld2000> References: <00a301c2b10d$313986a0$add0b33e@dld2000> Message-ID: <15891.58627.430834.472522@antilipe.corelatus.se> Daniel Dudley writes: > While on the subject of this book, I'm wondering whether > anyone is working on a new version, Not to my knowledge. Joe was thinking about a new book a year or two ago, AFAIK an overwhelming lack of interest from O'Reilly killed it. Maurice Castro seems to have revised his book last year: http://www.serc.rmit.edu.au/~maurice/erlbk/ There was also talk of a "collaborative, on-line book" at one stage. Matthias From Marc.Vanwoerkom@REDACTED Thu Jan 2 09:43:52 2003 From: Marc.Vanwoerkom@REDACTED (Marc Ernst Eddy van Woerkom) Date: Thu, 2 Jan 2003 09:43:52 +0100 (MET) Subject: Missing bookmarks in Erlang book (pdf-version) In-Reply-To: <15891.58627.430834.472522@antilipe.corelatus.se> (message from Matthias Lang on Thu, 2 Jan 2003 08:06:43 +0100) Message-ID: <200301020843.h028hqI26773@bonsai.fernuni-hagen.de> > Not to my knowledge. Joe was thinking about a new book a year or two > ago, AFAIK an overwhelming lack of interest from O'Reilly killed it. Interesting that he tried O'Reilly who is publishing real world programmers titles and not a more scientific publisher like Addison Wesley. Regarding adding bookmarks: The PDF file of the first part tells that it was created with dvipsk, thus the text was created with LaTeX or TeX originally. Adding the PDF bookmarks would be possible for example by running the sources through PDFLaTeX or PDFTeX, with not too much adaptions. Regards, Marc From hans@REDACTED Thu Jan 2 12:06:25 2003 From: hans@REDACTED (Hans Nilsson) Date: Thu, 2 Jan 2003 12:06:25 +0100 (CET) Subject: Word origins (mnensia and mnemosyne) In-Reply-To: <20021230183623.A24257@bluetail.com> Message-ID: About Mnemosyne: it is from a search on the net for the word "amnesia". The search machine happend to be such one that also lists "near misses" so it suggested a couple of articles about something called "mnemosyne". One of the articles was about greece mythology. Mnemosyne was the mother of the Muses. She was also considered some kind of goddess of the memory (suitable for a DBMS called amnesia, isn't it?). Mnemosyne was also some kind of goddess of the speech (perfect for a query language). That's the reason. /Hans On Mon, 30 Dec 2002, Klacke wrote: > On Mon, Dec 30, 2002 at 04:35:43PM +0100, Daniel Dudley wrote: > > I'm curious about the origins of the words mnensia and > > mnemosyne. A search in web dictionaries gives no answers, > > so I assume the words are concocted by the creators of the > > mnensia and mnemosyne applications -- but on what basis? > > > > > I initially nicked the db to Amnesia. In those days, Mnesia was > a ram only db. The idea was that when the power is shut down, the > db forgets everything, amnesia. > > Once the OTP kit was getting ready for prime time, a couple > of serious suits came into my little research cubicle, closed > the door and said - Klacke, we must do something about this > non-proffesional-sounding name of the OTP database. > > I dropped the A. > > > /klacke > From daniel.dudley@REDACTED Thu Jan 2 18:50:14 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Thu, 2 Jan 2003 18:50:14 +0100 Subject: Record selectors Message-ID: <009f01c2b287$67808440$18d1b33e@dld2000> I'm curious as to why it is necessary to specify the record name when selecting a record instance bound to a variable, i.e., Variable#RecordName.Field. Using an example from the Erlang Extensions document, but following good programming practice by using a meaningful variable name, we have: > Person = #person{name = "Joe", [0,8,2,3,4,3,1,2]}. {person, "Joe", [0,8,2,3,4,3,1,2], undefined} > Person#person.name. "Joe" Since the Person variable is bound to an instance of person records, it seems to me that it should be possible to use syntax like one of the following examples to retrieve field data (and avoid duplicity and unnecessary keyboard typing in the code): 1) > Person#.name 2) > Person#name 3) > Person.name I venture to suggest that any of these examples are far more readable than and just as understandable as the original, prescribed syntax. Would I be correct in assuming that the compiler is too "dumb" to recognize the Person <-> person-record binding with one of the suggested alternative syntax? But hey, maybe I'm just missing something -- it wouldn't be the first time! ;-) Daniel From daniel.dudley@REDACTED Thu Jan 2 20:09:45 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Thu, 2 Jan 2003 20:09:45 +0100 Subject: Missing bookmarks in Erlang book (pdf-version) References: <00a301c2b10d$313986a0$add0b33e@dld2000> <15891.58627.430834.472522@antilipe.corelatus.se> Message-ID: <00d601c2b292$83621dd0$18d1b33e@dld2000> Matthias Lang writes: > Daniel Dudley writes: > > > While on the subject of this book, I'm wondering whether > > anyone is working on a new version, > > Not to my knowledge. Joe was thinking about a new book a year > or two ago, AFAIK an overwhelming lack of interest from > O'Reilly killed it. > Maurice Castro seems to have revised his book last year: > > http://www.serc.rmit.edu.au/~maurice/erlbk/ > > There was also talk of a "collaborative, on-line book" at one > stage. Yes, such an online book is what I am suggesting. IMO, this should be primarily a PDF document, which is suitable for both online viewing and printing. It is easier to "get the big picture" with printed documentation, while online viewing may be preferable for quick reference purposes. (It is both stressful and potentially damaging to one's eyesight to read pages upon pages online.) If there's anyone in the Erlang community who would like to collaborate on new, updated documentation, please let me know (possibly but not necessarily via this mailing list). How would Erlang feel about releasing the copyright on their documentation? This would include "Concurrent Programming In Erlang" -- there's too much well-written stuff there to let it go to waste! Daniel From daniel.dudley@REDACTED Thu Jan 2 20:18:36 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Thu, 2 Jan 2003 20:18:36 +0100 Subject: Missing bookmarks in Erlang book (pdf-version) References: <200301020843.h028hqI26773@bonsai.fernuni-hagen.de> Message-ID: <00da01c2b293$bfc12cc0$18d1b33e@dld2000> Marc Ernst Eddy van Woerkom wrote: > > Not to my knowledge. Joe was thinking about a new book > > a year or two ago, AFAIK an overwhelming lack of interest > > from O'Reilly killed it. > > Interesting that he tried O'Reilly who is publishing real > world programmers titles and not a more scientific publisher > like Addison Wesley. > > Regarding adding bookmarks: > The PDF file of the first part tells that it was created with > dvipsk, thus the text was created with LaTeX or TeX originally. > Adding the PDF bookmarks would be possible for example by > running the sources through PDFLaTeX or PDFTeX, with not too > much adaptions. Fine, if can I get hold of the original sources. Otherwise, I'm quite content to reestablish the links in the PDF document myself, given an errata list. Any offers? Daniel From jamesh@REDACTED Thu Jan 2 20:36:04 2003 From: jamesh@REDACTED (James Hague) Date: Thu, 2 Jan 2003 13:36:04 -0600 Subject: erl_ddll vs. stdio drivers Message-ID: I've been using erl_ddll to hook to external code--via a Windows DLL--but lately I've been wondering why I'm doing this instead of using pipes. The traditional advantage of the former is "much faster communication" but there are some big advantages to the latter: 1. Simpler interface (no need to handle the various callbacks from the runtime system, no need to fill in a structure with callback pointers--some of which are no longer valid--and pass it back to the runtime). 2. Can't accidentally take down the entire emulator. 3. "Driver" can be a standard executable, which is nice because not all languages can generate DLLs. Even if you're not a language addict, it's nice to be able to whip up a quickie driver in Perl or Python. 4. "Driver" can be used with other languages, not just Erlang, or even tested without having to be linked to from Erlang. >From a purist's point of view using pipes is cleaner. So here's my question: How significant is the speed difference between the two methods under Windows? "Twice as fast" makes no difference if we're talking microseconds, but I suspect that because a pipe involves several task switches the minimum time for a call and response is going to be 20 milliseconds or so. Has anyone done any timings? Happy new year! James From kent@REDACTED Thu Jan 2 21:13:07 2003 From: kent@REDACTED (Kent Boortz) Date: 02 Jan 2003 21:13:07 +0100 Subject: erl_ddll vs. stdio drivers In-Reply-To: References: Message-ID: James Hague writes: > >From a purist's point of view using pipes is cleaner. So here's my > question: How significant is the speed difference between the two methods > under Windows? "Twice as fast" makes no difference if we're talking > microseconds, but I suspect that because a pipe involves several task > switches the minimum time for a call and response is going to be 20 > milliseconds or so. Has anyone done any timings? If you know the number of reads and writes and how large they are you can write some test programs to test the performance and decide from that if the speed is ok for your application. Some comparising between pipes on Linux, Windows XP and Windows 2000 is done on the article http://www-106.ibm.com/developerworks/linux/library/l-rt4/?open&t=grl,l=252,p=pipes There is an issue with terminating the external port program on Windows. If the external port program is killed from another process (the erlang node) the Windows OS will not release some resources. This was partly why the ODBC port program was rewritten to use two threads so that the external port program can terminate itself when erlang closes the pipe even if the port program was hanging in an ODBC call, kent From kent@REDACTED Thu Jan 2 21:34:27 2003 From: kent@REDACTED (Kent Boortz) Date: 02 Jan 2003 21:34:27 +0100 Subject: Missing bookmarks in Erlang book (pdf-version) In-Reply-To: <200301020843.h028hqI26773@bonsai.fernuni-hagen.de> References: <200301020843.h028hqI26773@bonsai.fernuni-hagen.de> Message-ID: Marc Ernst Eddy van Woerkom writes: > Regarding adding bookmarks: > The PDF file of the first part tells that it was created with dvipsk, > thus the text was created with LaTeX or TeX originally. > Adding the PDF bookmarks would be possible for example by running > the sources through PDFLaTeX or PDFTeX, with not too much > adaptions. Depends what you mean by "not to much adaptions" ;-) I have tried several ways of converting the LaTeX sources to PDF and there is always something that doesn't work correctly. I think I'm responsible for the mess with the PDF versions of the book. I converted the PostScript file that was distributed earlier to PDF to make it more easy to use for those that want to read and print the document on Microsoft and Apple operating systems. The original is LaTeX following an old standard. At least at that time the bitmap fonts used did not display well in AcrobatReader so I somehow (lost my notes) regenerated the PDF document from LaTeX using vector PostScript fonts. It may be in this process the references got lost. The truth is I haven't found someone that know TeX, LaTeX, PostScript, PDF, vector fonts with TeX, image inclusion, different LaTeX style packages, the HyperRef package, the best way to convert LaTeX to PDF, what to change from "old" LaTeX to the new standard etc that can help me out. I have never written a document in TeX or LaTeX and for me doing the conversion is a trial and error process. If I get some parts right others fail. For example I just made a new try using "pdflatex" and after converting all the included images to PDF, changing the use of \epsffile to \includegraphics, changed some other package inclusions (I really don't know what I'm doing) I manage to get the references back but some images get cut of with a few pixels. I also get lots of warnings while running pdflatex. I had hyperlinks working in one version but now they are gone and I don't know why. But the hyperlinks looked ugly in AcrobatReader so maybe hyperlinks shouldn't be in the PDF book anyway, I don't know how useful clickable hyperlinks are for the readers of the PDF book. I don't think we can release the LaTeX source of the book for legal reasons but if someone on this list is an expert on this and can help out I think we can arrange a way for you to get the LaTeX source to correct the LaTeX code and find the best way to generate PDF from it using an Unix distribution of LaTeX like TeTeX. We have Acrobat distiller so generating PostScript that contains vector fonts and optionally pdfmarks is also ok, kent From jamesh@REDACTED Thu Jan 2 23:24:59 2003 From: jamesh@REDACTED (James Hague) Date: Thu, 2 Jan 2003 16:24:59 -0600 Subject: erl_ddll vs. stdio drivers Message-ID: > Some comparising between pipes on Linux, Windows XP and Windows 2000 > is done on the article > > > Wow, that's horrible! Thanks for the pointer. From fritchie@REDACTED Fri Jan 3 02:00:14 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 02 Jan 2003 19:00:14 -0600 Subject: erl_ddll vs. stdio drivers In-Reply-To: Message of "Thu, 02 Jan 2003 13:36:04 CST." Message-ID: <200301030100.h0310EA8001954@bb.snookles.com> >>>>> "jh" == James Hague writes: jh> From a purist's point of view using pipes is cleaner. So here's my jh> question: How significant is the speed difference between the two jh> methods under Windows? "Twice as fast" makes no difference if jh> we're talking microseconds, but I suspect that because a pipe jh> involves several task switches the minimum time for a call and jh> response is going to be 20 milliseconds or so. Has anyone done jh> any timings? I once did this for Linux, FreeBSD, and Solaris x86 on the same hardware, but I can't find the data. So I cooked up a very small test for FreeBSD, since that's the machine I've got handy right this instant. The call in and out has a minimal amount of data going in each direction (er, about 5 bytes in and 6? bytes out ... with an extra 2 or 3? bytes in each direction for the pipe driver). This was done on a Pentium III laptop at 500MHz running FreeBSD 4.7-RELEASE. "linked-in" style (via shared lib): 9.7 microseconds/call (103500 calls/second) "pipe" style : 192 microseconds/call (5190 calls/second) Watching the stats from "vmstat" while the "pipe" style driver was running, I see anywhere from 53-97K system calls per second and 8.2-15.0K context switches per second. For both driver styles, there was 0% idle time. -Scott From valentin@REDACTED Fri Jan 3 07:58:22 2003 From: valentin@REDACTED (Valentin) Date: Fri, 3 Jan 2003 08:58:22 +0200 Subject: Happy New Year and continued Erlang Hacking References: Message-ID: <007e01c2b2f5$950a7f60$eaea1ec4@moneymaker> > The other day, I checked the erlang.org statistics, and > could observe that Erlang/OTP R9B has been downloaded nearly > 10,000 times already. November 2002 seems to have been the > most active month ever. Wish you all good health and happiness for you and your families... I've noticed only few e-mails with 'co.za' extension, and would like to find out how many of us (us meaning Fellow Erlangers, as Ulf nicely put it) live and makes living in South Africa. The major problem with ERLANG as I see it can be summarized in one sentence: As much as I can live with the risk of being run-over by a truck tomorrow, I cannot expect the same level of tolerance from my customers. I tend to think that what is important to me, might be important to others as well, so how about getting together and figuring out ways and means for cooperation and growth. You never know, we might just build up a critical mass required for a success of ERLANG down here. Valentin Micic Principal Consultant Pharos Consulting (Pty) Ltd. South Africa. cell: +27 83 212 9180 From cpressey@REDACTED Fri Jan 3 12:15:26 2003 From: cpressey@REDACTED (Chris Pressey) Date: Fri, 3 Jan 2003 05:15:26 -0600 Subject: Record selectors In-Reply-To: <009f01c2b287$67808440$18d1b33e@dld2000> References: <009f01c2b287$67808440$18d1b33e@dld2000> Message-ID: <20030103051526.115c4004.cpressey@catseye.mb.ca> On Thu, 2 Jan 2003 18:50:14 +0100 "Daniel Dudley" wrote: > I'm curious as to why it is necessary to specify the record > name when selecting a record instance bound to a variable, > i.e., Variable#RecordName.Field. Because Erlang is a dynamically-typed language. In a dynamically-typed language, values have types, but variables do not. > Using an example from the > Erlang Extensions document, but following good programming > practice by using a meaningful variable name, we have: > > > Person = #person{name = "Joe", [0,8,2,3,4,3,1,2]}. > {person, "Joe", [0,8,2,3,4,3,1,2], undefined} > > Person#person.name. > "Joe" > > Since the Person variable is bound to an instance of person > records, it seems to me that it should be possible to use > syntax like one of the following examples to retrieve field > data (and avoid duplicity and unnecessary keyboard typing > in the code): > > 1) > Person#.name > 2) > Person#name > 3) > Person.name But consider the case of there being another record definition with a field called 'name', e.g. Country#country.name. If one were then to write a function like print_name(X) -> io:fwrite("~p~n", [X#name]). There is no way for the compiler to infer what field #name refers to. The practical recourse at the moment, at least for me, is: a) if performance is critical, use records and accept the silly syntax b) if flexibility is more important, use dictionaries Quite often I find myself wrapping record accesses in functions, although "person:name(X)" is just as verbose as "X#person.name" (in fact it's one character longer :) but it looks nicer, plus it abstracts the access so that e.g. person:name(X) could be derived from X#person.first_name and X#person.last_name at some future point in development. Again, if performance is critical, this sort of thing should still be avoided, because unlike "X#person.name", you can't tell what the complexity of "person:name(X)" is just by looking at it. -Chris From matthias@REDACTED Fri Jan 3 14:38:54 2003 From: matthias@REDACTED (Matthias Lang) Date: Fri, 3 Jan 2003 14:38:54 +0100 Subject: Record selectors In-Reply-To: <20030103051526.115c4004.cpressey@catseye.mb.ca> References: <009f01c2b287$67808440$18d1b33e@dld2000> <20030103051526.115c4004.cpressey@catseye.mb.ca> Message-ID: <15893.37486.931486.505561@antilipe.corelatus.se> Daniel> I'm curious as to why it is necessary to specify the record Daniel> name when selecting a record instance bound to a variable, Daniel> i.e., Variable#RecordName.Field. Chris> Because Erlang is a dynamically-typed language. In a Chris> dynamically-typed language, values have types, but variables Chris> do not. _If_ the runtime system had a table of {recordname, fieldname} -> index, it would be possible to allow: P = #person{name = "Bruce", occupation = "language designer"}, Name = P#name. where P#name is sugar for record_field(P, name), which could be implemented to do something like: record_field(Record, Field) -> {ok, Index} = magic_table_lookup(element(1, Record), Field), element(Index, Record). There is no such table of record information AFAIK, so the above is just speculation. The cost? Zero for existing code. For code which uses the new feature there'd be an extra lookup operation for each such field access. There are some solvable wrinkles, e.g. handling the common case where the same record is defined several times in a system. But the best reason not to do it is fear of making the record mess worse than it already is. Matthias From hakan.stenholm@REDACTED Sat Jan 4 03:55:38 2003 From: hakan.stenholm@REDACTED (=?ISO-8859-1?Q?H=E5kan_Stenholm?=) Date: Sat, 4 Jan 2003 03:55:38 +0100 Subject: Record selectors In-Reply-To: <20030103051526.115c4004.cpressey@catseye.mb.ca> Message-ID: <013326B2-1F90-11D7-811C-000393B8AB26@mbox304.swipnet.se> On fredag, jan 3, 2003, at 12:15 Europe/Stockholm, Chris Pressey wrote: > On Thu, 2 Jan 2003 18:50:14 +0100 > "Daniel Dudley" wrote: > >> I'm curious as to why it is necessary to specify the record >> name when selecting a record instance bound to a variable, >> i.e., Variable#RecordName.Field. > > Because Erlang is a dynamically-typed language. In a dynamically-typed > language, values have types, but variables do not. > >> Using an example from the >> Erlang Extensions document, but following good programming >> practice by using a meaningful variable name, we have: >> >>> Person = #person{name = "Joe", [0,8,2,3,4,3,1,2]}. >> {person, "Joe", [0,8,2,3,4,3,1,2], undefined} >>> Person#person.name. >> "Joe" >> >> Since the Person variable is bound to an instance of person >> records, it seems to me that it should be possible to use >> syntax like one of the following examples to retrieve field >> data (and avoid duplicity and unnecessary keyboard typing >> in the code): >> >> 1) > Person#.name >> 2) > Person#name >> 3) > Person.name > > But consider the case of there being another record definition with a > field called 'name', e.g. Country#country.name. If one were then to > write > a function like > > print_name(X) -> io:fwrite("~p~n", [X#name]). Sure there is if the Virtual machine would keep track of the record definitions (the fieldname - index mapping) and records would be tagged as records rather than being implemented as tuples in the VM. A: Person.name would be the same as: RecordName = element(1,Person), FieldValue = element(#RecordName.name, Person), Assuming that the VM knew about the record definition, which it currently doesn't as records only exist during the preprocessor stage. Records are a late Erlang addition which is one of the reasons why there is number of problems that need to be solved to handle records properly: * Records are implemented as tuples, this leads to problems with properly identifying records as records (they will always be identified as tuples as well), I don't think this should be a major problem as the worst case should be a failed element/2 access (or runtime errors later on trying to update a tuple as a record), one would assume that code that acts on records only receives records - making this a unlikely bug generator. * The tuple implementation is sometimes used directly during code change (when record defs. have been updated), as there can be only one record definition at the same time. So changing the implementation might yield some problems - but to me it appears that the Person.name syntax would work without this kind of change. There is of course the question how the VM should handle the fieldname - index mapping in this kind of cases (a old and new version might be useful to keep around and to be able to use as well). * There is also compatibility problem as it isn't possible to determine which record definition was actually used when a module was compiled. It might be useful to keep a fieldname - index mapping for each record as well as one for each unique version used by the modules. Drawbacks: * Doing a #RecordName.FieldName access dynamically during runtime will obviously be more costly - retrieving the record name and doing a lookup on the {RecordName, FieldName} key. > > There is no way for the compiler to infer what field #name refers to. > > The practical recourse at the moment, at least for me, is: > a) if performance is critical, use records and accept the silly syntax > b) if flexibility is more important, use dictionaries > > Quite often I find myself wrapping record accesses in functions, > although > "person:name(X)" is just as verbose as "X#person.name" (in fact it's > one > character longer :) but it looks nicer, plus it abstracts the access so > that e.g. person:name(X) could be derived from X#person.first_name and > X#person.last_name at some future point in development. Again, if > performance is critical, this sort of thing should still be avoided, > because unlike "X#person.name", you can't tell what the complexity of > "person:name(X)" is just by looking at it. > > -Chris > From kent@REDACTED Sat Jan 4 04:49:36 2003 From: kent@REDACTED (Kent Boortz) Date: 04 Jan 2003 04:49:36 +0100 Subject: Visualization tools for Erlang/OTP programs? In-Reply-To: Message-ID: Has anyone tested any general visualization tools to describe Erlang/OTP programs, i.e. to visually describe the supervision, process structure, messages, state etc? Like "ROOM Diagrams"? Any success, i.e. was the the time it takes to draw them worth it in your case? Do you find the visualization useful in the design phase before coding or as a way to create internal design documumentation? Are any of the nine types of diagrams defined in UML usable for describing Erlang/OTP programs? Do you use any free or commercial drawing tools that you recommend for drawing diagrams to describe Erlang/OTP programs? The only drawings I have done myself is ascii drawings of the supervision structure, I'm just curious about what others do and if there is any potential for creating visual programming tools to generate Erlang programs or part of Erlang programs like processes that use gen_fsm, kent Ref: http://www.smartdraw.com/resources/centers/software/room.htm From enewhuis@REDACTED Sat Jan 4 06:16:03 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 3 Jan 2003 23:16:03 -0600 Subject: Efficient Functional Data Structures Message-ID: <000901c2b3b0$609049c0$8c00a8c0@XENO> Is there any good information out there on efficient functional data structures? This is my first crack at one in Erlang and I'd like someone to poke holes in my implementation and point out Erlang hot spots. This is a trie. I think the word trie is taken from reTRIEve. A useful definition for my purposes here is that a trie is an unbalanced tree with a child node for every possible next term in a sentence. So you can think of a trie as a data structure that can store every possible list of Erlang terms in a tight space. (Tries are sometimes used as symbol tables in parsers; since they don't require you to store each identifier you get good space savings for very large symbol tables.) Walking a trie from root to any node recreates the list of terms that was stored in the trie. I am impressed by Erlang's ability to represent this functional data structure so concisely. This really is impressive. Each node in the trie contains a dictionary that maps the next term to another node and a "slot" (a list of length 1) that stores an object. I have a variation on this that appends to the slot thereby redefining the slot as a list of objects. In that case duplicate strings are allowed. -module (trie). ... % Creates an empty trie. new () -> {[], []}. % Adds or updates an object with the given key and returns the new trie. store ([], Object, {TrieDict, _}) -> {TrieDict, [Object]}; store ([Elem | StringTail], Object, {TrieDict, Slot}) -> case orddict:find (Elem, TrieDict) of {ok, Subtrie} -> {orddict:store (Elem, store (StringTail, Object, Subtrie), TrieDict), Slot}; error -> {orddict:store (Elem, store (StringTail, Object, new ()), TrieDict), Slot} end. Examples: T0 = trie:new(). T1 = trie:store ("there", 1, T0). T2 = trie:store ("therein", 2, T1). T3 = trie:store ("therein lies the problem", 3, T2). T4 = trie:store ([therein,lies,the,problem], 4, T3). I have search functions that I've omitted because I am primarily concerned about the efficiency of building the trie and updating the object stored in the "slot". I use orddict because dict seems to have a lot of space overhead for small dictionaries and I need to know the representation for other operations and pattern-matching on the empty dictionary []. I have two concerns. The small concern: Every time I add a child node I need to rebuild the trie all the way back up to the root. {orddict:store (Elem, store (...), ...), ...} The big concern: I need to replace objects stored in each "slot" at a high rate ~10,000 times per second. (Or at least I desire this; I don't think I can currently do it on a 1GHz CPU.) It seems to me that if Erlang had a "ref" object like ObjectiveCaml I could introduce a small side-effect and store a reference to a value in the trie instead of rebuilding the trie every time the object is updated. Questions for the experts: What can I do with "textbook" Erlang? What can I do to cheat (possibly with a C "hack")? Am I doing things as good as I can with clean Erlang? What can I do to speed things up? Sincerely, Eric Newhuis From matthias@REDACTED Sat Jan 4 09:47:16 2003 From: matthias@REDACTED (Matthias Lang) Date: Sat, 4 Jan 2003 09:47:16 +0100 Subject: Efficient Functional Data Structures In-Reply-To: <000901c2b3b0$609049c0$8c00a8c0@XENO> References: <000901c2b3b0$609049c0$8c00a8c0@XENO> Message-ID: <15894.40852.583138.709170@antilipe.corelatus.se> Eric Newhuis writes: > Is there any good information out there on efficient functional data > structures? The classic is Chris Okasaki Purely Functional Data Structures Cambridge University Press; ISBN: 0521663504; 0 edition (July 1, 1999) He also has a lot of articles online at http://www.eecs.usma.edu/Personnel/okasaki/pubs.html#cup98 Reading the book was a bit of an "a-ha" experience for me. It clarified the muddy ideas I had about functional data structures. Unfortunately half the book is about lazy data structures. > I have two concerns. > > The small concern: Every time I add a child node I need to rebuild the > trie all the way back up to the root. {orddict:store (Elem, store > (...), ...), ...} This is a fundamental property of purely functional trees. You can only get around it by introducing destructive update in one guise or another. See also: http://www.research.avayalabs.com/user/wadler/topics/monads.html > Questions for the experts: What can I do with "textbook" Erlang? What > can I do to cheat (possibly with a C "hack")? Am I doing things as good > as I can with clean Erlang? What can I do to speed things up? I haven't tried very hard to understanding your code, so I won't comment. My experience is that ETS is hard to beat as soon as you get even a moderate amount of data (a few thousand nodes). Chances for beating ETS improve if your data structure doesn't have a simple mapping to ETS or if the data structure tends to be short-lived. Previous related discussions: http://www.erlang.org/ml-archive/erlang-questions/200010/msg00193.html http://www.erlang.org/ml-archive/erlang-questions/200012/msg00045.html Matthias From cpressey@REDACTED Sat Jan 4 12:59:50 2003 From: cpressey@REDACTED (Chris Pressey) Date: Sat, 4 Jan 2003 05:59:50 -0600 Subject: Record selectors In-Reply-To: <013326B2-1F90-11D7-811C-000393B8AB26@mbox304.swipnet.se> References: <20030103051526.115c4004.cpressey@catseye.mb.ca> <013326B2-1F90-11D7-811C-000393B8AB26@mbox304.swipnet.se> Message-ID: <20030104055950.77e1974c.cpressey@catseye.mb.ca> On Sat, 4 Jan 2003 03:55:38 +0100 H?kan Stenholm wrote: > > On fredag, jan 3, 2003, at 12:15 Europe/Stockholm, Chris Pressey wrote: > > > On Thu, 2 Jan 2003 18:50:14 +0100 > > "Daniel Dudley" wrote: > > > >> I'm curious as to why it is necessary to specify the record > >> name when selecting a record instance bound to a variable, > >> i.e., Variable#RecordName.Field. > > > > Because Erlang is a dynamically-typed language. In a > > dynamically-typed language, values have types, but variables do not. > > [...] > > But consider the case of there being another record definition with a > > field called 'name', e.g. Country#country.name. If one were then to > > write > > a function like > > > > print_name(X) -> io:fwrite("~p~n", [X#name]). > > Sure there is if the Virtual machine would keep track of the record > definitions (the fieldname - index mapping) and records would be tagged > as records rather than being implemented as tuples in the VM. OK, I guess I should clarify: what I meant was that there's no way that the *compiler* could tell; the runtime is another matter. Moreover, it seems clear to me that records in Erlang were designed to have minimal (essentially zero) impact on performance (they're almost entirely syntactic.) This seems very reasonable in light of Erlang being a language for soft real-time systems. While the VM could keep a table of which fields belong to which records, it would mean that Person#person.name instead of compiling to something like element(5, Person) would compile to something like element(ets:lookup(field_matrix, {element(1, Person), name}), Person) Now, my reasoning is, if you're willing to take this sort of performance hit to access aggregates of data, why restrict yourself to records, when you could be using dictionaries or "objects" (accessor functions) and get the benefits associated with those? In other words, having the VM know which fields go in which records, only saves you typing (um, keyboard-banging-type typing :), whereas using dictionaries or objects would also give you extensibility or encapsulation respectively, for a comparable performance hit. I'm sure most Erlangers realize that OO techniques are overrated, but on the other hand, silly is the Erlanger who intentionally avoids an OO technique when it would actually be useful, simply because "we don't do it that way." Encapsulation is, I think, one of those techniques that is especially germane to this example (e.g. a wrapper function could prevent Person#person.name from taking on an integer value.) I guess what I'm saying is that it would probably be more productive to consider alternative ways of aggregating data, than to try to improve the existing record system. A crucial first step, I think, is to allow the programmer to create truly unique user-defined types - not just using a tuple with the convention that the first element is the name of the type. Something like Perl's "bless" operation comes to mind - a way to create an opaque value with a type name that may be associated with a module which provides the operations applicable to values of that type. This way, a syntax like Person#name could compile to something like type_of(Person):name(Person) or even type_of(Person):get_property(Person, name) This wouldn't interfere with the existing record mechanism (which could be thought of as "raw" access in comparison to this) while providing the flexibility, terseness, and abstraction desired by high-level programmers (without forcing a full-blown OO paradigm on them.) -Chris From daniel.dudley@REDACTED Sun Jan 5 11:43:37 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Sun, 5 Jan 2003 11:43:37 +0100 Subject: Record selectors References: <009f01c2b287$67808440$18d1b33e@dld2000> Message-ID: <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> This thread has generated some interesting replies, but I'm left wondering whether I have been entirely understood. Here's a sample test module, which I hope will help clarify my original message: -module(test). -export([selector/0]). -record(person, {name, phone, address}). -record(country, {code, name}). selector() -> Person = #person{name = "Joe", phone = [0,8,2,3,4,3,1,2]}, Country = #country{code = 47, name = "Norway"}, print_name(Person). print_name(X) -> io:fwrite("~p~n", [X#country.name]), io:fwrite("~p~n", [X#person.name]). Note the reference to a country record in print_name/1 (using the prescribed record selector syntax), and the result of the following dialog: 1> c:c(test). {ok,test} 2> test:selector(). [0,8,2,3,4,3,1,2] "Joe" ok The call X#country.name does not produce an error or failure because the name of the country record's second field is 'name'. Consequently, the value of the second field (third element) in the X variable, which is bound to a person record, is returned. This example illustrates that not only is the reference to a specific record-type in the record selector syntax superflous, it is downright "dangerous" because it invites error-prone code. The bottom line is that a record selector is tied to the type of value stored in the variable being investigated. If this type is (as expected) a tuple, then the actual record type is (must be) determined by reading the first element of the tuple. Only then can one decide which of the remaining elements in the tuple corresponds to the specified field. Daniel From thomas.arts@REDACTED Sat Jan 4 13:37:44 2003 From: thomas.arts@REDACTED (Thomas Arts) Date: Sat, 4 Jan 2003 13:37:44 +0100 Subject: Visualization tools for Erlang/OTP programs? References: Message-ID: <001901c2b3ee$15497840$76c31081@ituniv398> Hi Kent I made a small supervisor visualisation tool two years ago. It is based on Hans Nilsson's graph drawing program, whish in particular is good in drawing trees (what one needs for supervision trees ;0). I would recommend the SVG format nowadays. This Scaled Vector Graphics is a standard from Adobe that can be used to draw vector graphics. It is an open standard and plug-ins exist for Netscape and Explorer, for example. Another cool drawing package is "dot" from Lucent (Bell Labs). There is a backend for dot to produce SVG. I attached my drawing software. If you would start the supervision tree with supervisor:start(M,F,Args), then the visualization is started with: visualize:supervisor(M,F,Args). I had to change "eval.erl" slightly, but with the three modules attached and Hans' graph drawing package (see user contributions), this should work well. Let me know if it doesn't, then I'll look into it a bit better. /Thomas --- FMICS 03, June 5-7 in Trondheim. Call for papers: http://www.inrialpes.fr/vasy/fmics/workshop-8/ Dr Thomas Arts Program Manager Software Engineering and Management IT-university of Gothenburg Box 8718, 402 75 Gothenburg, Sweden Tel +46 31 772 6031 Fax +46 31 772 4899 ----- Original Message ----- From: "Kent Boortz" To: Sent: Saturday, January 04, 2003 4:49 AM Subject: Visualization tools for Erlang/OTP programs? > > Has anyone tested any general visualization tools to describe > Erlang/OTP programs, i.e. to visually describe the supervision, > process structure, messages, state etc? Like "ROOM Diagrams"? > Any success, i.e. was the the time it takes to draw them worth it in > your case? Do you find the visualization useful in the design phase > before coding or as a way to create internal design documumentation? > > Are any of the nine types of diagrams defined in UML usable for > describing Erlang/OTP programs? > > Do you use any free or commercial drawing tools that you recommend for > drawing diagrams to describe Erlang/OTP programs? > > The only drawings I have done myself is ascii drawings of the > supervision structure, I'm just curious about what others do and if > there is any potential for creating visual programming tools to > generate Erlang programs or part of Erlang programs like processes > that use gen_fsm, > > kent > > Ref: http://www.smartdraw.com/resources/centers/software/room.htm > -------------- next part -------------- A non-text attachment was scrubbed... Name: app.erl Type: application/octet-stream Size: 13655 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: eval.erl Type: application/octet-stream Size: 24264 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: visualize.erl Type: application/octet-stream Size: 2392 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: supervior.jpg Type: image/jpeg Size: 31666 bytes Desc: not available URL: From daniel.dudley@REDACTED Sun Jan 5 04:21:03 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Sun, 5 Jan 2003 04:21:03 +0100 Subject: Visualization tools for Erlang/OTP programs? References: Message-ID: <007101c2b469$7ab14980$26d0b33e@dld2000> Kent Boortz wrote: > Has anyone tested any general visualization tools to describe > Erlang/OTP programs, i.e. to visually describe the supervision, > process structure, messages, state etc? Like "ROOM Diagrams"? > Any success, i.e. was the the time it takes to draw them worth > it in your case? Do you find the visualization useful in the > design phase before coding or as a way to create internal > design documumentation? > > Are any of the nine types of diagrams defined in UML usable for > describing Erlang/OTP programs? > > Do you use any free or commercial drawing tools that you > recommend for drawing diagrams to describe Erlang/OTP programs? > > The only drawings I have done myself is ascii drawings of the > supervision structure, I'm just curious about what others do > and if there is any potential for creating visual programming > tools to generate Erlang programs or part of Erlang programs > like processes that use gen_fsm, You could test out "Libero" (freeware) from iMatix Corp http://www.imatix.com/html/libero/index.htm With Libero you: - design your program visually as a state diagram; - choose your programming language; - generate a framework for your program; - fill-in the framework to get from rapid prototype to working program; - repeat until your program is perfect. You can generate code in a number of programming languages and Unix shells. Although Erlang is not one of the supported languages, you can write a schema that does so. Note that I'll soon be working on just that, so if you would like to cooperate or exchange experiences, please let me know. Libero seems to be well-suited for concurrent, functional programming. However, only experience will tell. Libero runs on Windows, MS-DOS, VAX/VMS, UNIX and is supplied with full portable ANSI C sources. Imatix has a number of other tools you may be interested in, visit http://www.imatix.com/tools.htm HTH, Daniel From svg@REDACTED Sat Jan 4 18:45:13 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Sat, 04 Jan 2003 22:45:13 +0500 (YEKT) Subject: [PATCH]:erts/emulator/beam/erl_time_sup.c Message-ID: <20030104.224513.41651862.svg@surnet.ru> Good day, This simple patch is intended to new Linux kernels (2.5.*) where sysconf(_SC_CLK_TCK) == 1024 but some code in `erts/emulator/beam/erl_time_sup.c' were written with assumption that this value is far less than 1000(it is traditionally 100 on most systems). Best regards, Vladimir Sekissov --- erts/emulator/beam/erl_time_sup.c.orig 2003-01-04 22:30:47.000000000 +0500 +++ erts/emulator/beam/erl_time_sup.c 2003-01-04 22:27:00.000000000 +0500 @@ -219,7 +219,7 @@ Milli act_correction; /* long showed to be too small */ Milli max_adjust; -#define TICK_MS (1000 / SYS_CLK_TCK) +#define TICK_MS (1000.0 / SYS_CLK_TCK) current_ct = KERNEL_TICKS(); sys_gettimeofday(¤t_tv); From sureshsaragadam@REDACTED Tue Jan 7 05:51:38 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Tue, 7 Jan 2003 04:51:38 +0000 (GMT) Subject: How To Start and Stop an user Application in erlang Message-ID: <20030107045138.80866.qmail@web8206.mail.in.yahoo.com> ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com -------------- next part -------------- An embedded message was scrubbed... From: =?iso-8859-1?q?Suresh=20S?= Subject: How To Start and Stop an user Application in erlang Date: Mon, 6 Jan 2003 07:11:11 +0000 (GMT) Size: 970 URL: From jocke@REDACTED Mon Jan 6 00:31:41 2003 From: jocke@REDACTED (Joakim G.) Date: Mon, 06 Jan 2003 00:31:41 +0100 Subject: Release: xmlrpc-1.0 Message-ID: <3E18C05D.9020602@bluetail.com> Hi, Someone asked for an XML-RPC library for Erlang some time back. I needed such a beast myself. Here it is: http://www.gleipnir.com/xmlrpc/xmlrpc-1.0.tgz An unpacked version of it can be found here: http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/ Read the man page and examples for a quick understanding of what the library provides: http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/doc/ http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/examples/ Cheers /Jocke From hal@REDACTED Sat Jan 4 18:53:28 2003 From: hal@REDACTED (Hal Snyder) Date: Sat, 04 Jan 2003 11:53:28 -0600 Subject: Visualization tools for Erlang/OTP programs? In-Reply-To: (Kent Boortz's message of "04 Jan 2003 04:49:36 +0100") References: Message-ID: <87vg14pzs7.fsf@ghidra.vail> Kent Boortz writes: ... > Are any of the nine types of diagrams defined in UML usable for > describing Erlang/OTP programs? > Do you use any free or commercial drawing tools that you recommend for > drawing diagrams to describe Erlang/OTP programs? I picked up Yourdon-DeMarco DFD techniques during a 4-year stint at Motorola. This approach can be helpful during development of larger OTP projects. For software, I now use Bill Cheng's TGIF as it runs on our OSes of choice and is open source - but, it's a drawing program, not a CASE tool. From wwasilev@REDACTED Tue Jan 7 04:22:29 2003 From: wwasilev@REDACTED (Wwas) Date: Mon, 6 Jan 2003 22:22:29 -0500 Subject: www.erlang.org ? Message-ID: <002701c2b5fc$0342f120$0a7ba8c0@was> I've been unable to reach www.erlang.org for the past several days (DNS lookup error reported). Is anyone else having this problem? -was From enewhuis@REDACTED Mon Jan 6 01:28:03 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Sun, 5 Jan 2003 18:28:03 -0600 Subject: Efficient Functional Data Structures In-Reply-To: <15894.40852.583138.709170@antilipe.corelatus.se> Message-ID: <000001c2b51a$9cd86640$8c00a8c0@XENO> I threw out ETS perhaps prematurely (?) when I realized I couldn't match on variable-length keys. In my world keys are lists of Erlang terms. Can ETS find matches when some terms are don't-care? I think the answer is yes. But can ETS match on variable-length keys? I don't know the answer. Given a set of keys such as [a,b,c], [a,b,c,d], and [a,b,c,d,e], can ETS find all three keys given a search pattern like [a,b,'*'] ? I think I tried with patterns like [a,b,'_'] but that only finds [a,b,c] and fails to get the others. I suppose I could keep track of the longest keys inserted and expand queries containing '*' into all permutations of a,b,'_','_',... up to the maximum key length and execute multiple searches. But that feels so dirty. Sincerely, Eric -----Original Message----- From: Matthias [mailto:matthias@REDACTED] On Behalf Of Matthias Lang Sent: Saturday, January 04, 2003 2:47 AM To: Eric Newhuis Cc: erlang-questions@REDACTED Subject: Re: Efficient Functional Data Structures Eric Newhuis writes: > Is there any good information out there on efficient functional data > structures? The classic is Chris Okasaki Purely Functional Data Structures Cambridge University Press; ISBN: 0521663504; 0 edition (July 1, 1999) He also has a lot of articles online at http://www.eecs.usma.edu/Personnel/okasaki/pubs.html#cup98 Reading the book was a bit of an "a-ha" experience for me. It clarified the muddy ideas I had about functional data structures. Unfortunately half the book is about lazy data structures. > I have two concerns. > > The small concern: Every time I add a child node I need to rebuild the > trie all the way back up to the root. {orddict:store (Elem, store > (...), ...), ...} This is a fundamental property of purely functional trees. You can only get around it by introducing destructive update in one guise or another. See also: http://www.research.avayalabs.com/user/wadler/topics/monads.html > Questions for the experts: What can I do with "textbook" Erlang? What > can I do to cheat (possibly with a C "hack")? Am I doing things as good > as I can with clean Erlang? What can I do to speed things up? I haven't tried very hard to understanding your code, so I won't comment. My experience is that ETS is hard to beat as soon as you get even a moderate amount of data (a few thousand nodes). Chances for beating ETS improve if your data structure doesn't have a simple mapping to ETS or if the data structure tends to be short-lived. Previous related discussions: http://www.erlang.org/ml-archive/erlang-questions/200010/msg00193.html http://www.erlang.org/ml-archive/erlang-questions/200012/msg00045.html Matthias From enewhuis@REDACTED Mon Jan 6 17:28:10 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Mon, 6 Jan 2003 10:28:10 -0600 Subject: Advanced ETS Pattern Matching Message-ID: <003f01c2b5a0$c69e4090$9ec3cf0a@XENO> (My Trie has morphed into consideration of ETS pattern matching.) Does anyone know if ETS can support pattern matching on "the rest of a list of terms" if the key is a list of terms? All my keys are lists. I need to match on parts of the key and on the elements near the head of the list. Examples: Given keys: [a,b,c,d] [a,b,c] [a,b] Find all three with the following pattern: [a,'*'] Find the last two with this pattern: [a,b,'*'] Find [a,b] with this pattern: ['_',b] etc. I think the '_' works. But is there a mechanism like '*' that can match the rest of an arbitrary length key that is a list, sort of like _='_' in some other database module? I know I could keep track of the maximum list length and perform multiple queries appending '_' to the maximum length. But that seems yucky. Sincerely, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Jan 7 19:26:50 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Tue, 7 Jan 2003 19:26:50 +0100 Subject: Stream and binary C/C++ Port usage Message-ID: <009901c2b67a$59270530$1e00a8c0@design> I'm having some trouble with stream and binary properties in C/C++ ports. Does someone have used this properties or have some code to share ? Thanks, Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From sureshsaragadam@REDACTED Mon Jan 6 08:11:11 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Mon, 6 Jan 2003 07:11:11 +0000 (GMT) Subject: How To Start and Stop an user Application in erlang Message-ID: <20030106071111.7824.qmail@web8204.mail.in.yahoo.com> Hi, we have a utility to start an application like application:start(sasl). I have my applicaiton(i have not made a release yet for my applicaiton ) can i make use of applicaiton:start(myapp). application:stop(myapp). what should i do to make use of this utility Thanks in adavance suresh s ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From Erik.Reitsma@REDACTED Tue Jan 7 09:14:58 2003 From: Erik.Reitsma@REDACTED (Erik Reitsma (ELN)) Date: Tue, 7 Jan 2003 09:14:58 +0100 Subject: Advanced ETS Pattern Matching Message-ID: <440A2703A54A8F4FB2AC2AE34F27129D2159A4@ESEALNT889.al.sw.ericsson.se> > Does anyone know if ETS can support pattern matching on "the > rest of a list of terms" if the key is a list of terms? Yes, it does in the cases you describe. > Examples: > > Given keys: > > [a,b,c,d] > [a,b,c] > [a,b] Eshell V5.2 (abort with ^G) 1> T=ets:new(my_table,[]). 11 2> ets:insert(T,[{[a,b,c,d],1},{[a,b,c],2},{[a,b],3}]). true > Find all three with the following pattern: > > [a,'*'] 3> ets:match(T,{[a|'$1'],'$2'}). [[[b,c,d],1],[[b],3],[[b,c],2]] > Find the last two with this pattern: > > [a,b,'*'] If '*' means zero or more elements, it would match all keys: 4> ets:match(T,{[a,b|'$1'],'$2'}). [[[c,d],1],[[],3],[[c],2]] If it matches one or more elements, I have to add another element: 5> ets:match(T,{[a,b,'$3'|'$1'],'$2'}). [[[d],1,c],[[],2,c]] > Find [a,b] with this pattern: > > ['_',b] 6> ets:match(T,{['$1',b],'$2'}). [[a,3]] It seems to work fine. Regards, *Erik. From w_w@REDACTED Mon Jan 6 23:49:01 2003 From: w_w@REDACTED (ww) Date: 06 Jan 2003 17:49:01 -0500 Subject: erlang.org Message-ID: <1041893343.29000.2.camel@homey> I've been unable to access www.erlang.org for the past several days (no DNS entry). Is anyone else having this problem? -was From sureshsaragadam@REDACTED Mon Jan 6 07:19:47 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Mon, 6 Jan 2003 06:19:47 +0000 (GMT) Subject: How to stop an Application Message-ID: <20030106061947.81072.qmail@web8203.mail.in.yahoo.com> Hi , This is the start module of my aplicaiton, there r two call back functions start and stop So can i use stop function (i.e entry_app:stop([]) from an other module) to stop this applicaiton i am calling stop function but it is not working what parameter i have to pass to this stop function inorder to stop the application from an other module. -module(entry_app). -behaviour(application). -export([start/2,stop/1]). start(Type, _Args) -> io:format("In Application Start Module.~n"), entry_sup:start_link(). stop(S) -> ok. Thanks in advace suresh s ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From micael.karlberg@REDACTED Tue Jan 7 09:33:13 2003 From: micael.karlberg@REDACTED (Micael Karlberg) Date: Tue, 7 Jan 2003 09:33:13 +0100 Subject: erlang.org In-Reply-To: <1041893343.29000.2.camel@homey> References: <1041893343.29000.2.camel@homey> Message-ID: <15898.37065.703117.467816@gargle.gargle.HOWL> The server should be up and running now. /BMK ww writes: > I've been unable to access www.erlang.org for the past several days (no > DNS entry). Is anyone else having this problem? > > -was From msanjay@REDACTED Tue Jan 7 09:39:12 2003 From: msanjay@REDACTED (Sanjay Mehta) Date: Tue, 07 Jan 2003 14:09:12 +0530 Subject: Efficient Functional Data Structures References: <000901c2b3b0$609049c0$8c00a8c0@XENO> <15894.40852.583138.709170@antilipe.corelatus.se> Message-ID: <3E1A9230.B1B79AA1@lucent.com> The original PhD report is at: http://www-2.cs.cmu.edu/~rwh/theses/okasaki.pdf I had trouble obtaining the book ... this should get you started. Matthias Lang wrote: > > Eric Newhuis writes: > > Is there any good information out there on efficient functional data > > structures? > > The classic is > > Chris Okasaki > Purely Functional Data Structures > Cambridge University Press; ISBN: 0521663504; 0 edition (July 1, 1999) From mike@REDACTED Tue Jan 7 09:59:44 2003 From: mike@REDACTED (Mike Williams) Date: 7 Jan 2003 08:59:44 GMT Subject: Word origins (mnensia and mnemosyne) References: <001b01c2b019$1dcf96d0$86d0b33e@dld2000>, <20021230183623.A24257@bluetail.com> Message-ID: In article <20021230183623.A24257@REDACTED>, klacke@REDACTED (Klacke) writes: |> On Mon, Dec 30, 2002 at 04:35:43PM +0100, Daniel Dudley wrote: |> Once the OTP kit was getting ready for prime time, a couple |> of serious suits came into my little research cubicle, closed |> the door and said - Klacke, we must do something about this |> non-proffesional-sounding name of the OTP database. |> |> I dropped the A. Klacke, I may wear a tie, but I don't wear a suit. Getting a new technology accepted means (unfortunately) getting the technology accepted by management who have different criteria for acceptance than the programming community. Look at all the industry committees which have grown up arround Linux. At the end of day it is the same people who do the practical work. It pays to endure a small measure of political correctness to achieve one's goals, (which is why you were prepared to change the name). /mike PS. When the measure of political correctness gets out of hand, then you have to take drastic measures. From klacke@REDACTED Tue Jan 7 10:17:39 2003 From: klacke@REDACTED (Klacke) Date: Tue, 7 Jan 2003 10:17:39 +0100 Subject: Efficient Functional Data Structures In-Reply-To: <000001c2b51a$9cd86640$8c00a8c0@XENO>; from enewhuis@futuresource.com on Sun, Jan 05, 2003 at 06:28:03PM -0600 References: <15894.40852.583138.709170@antilipe.corelatus.se> <000001c2b51a$9cd86640$8c00a8c0@XENO> Message-ID: <20030107101739.A5029@bluetail.com> On Sun, Jan 05, 2003 at 06:28:03PM -0600, Eric Newhuis wrote: > I threw out ETS perhaps prematurely (?) when I realized I couldn't match > on variable-length keys. > > In my world keys are lists of Erlang terms. Can ETS find matches when > some terms are don't-care? I think the answer is yes. But can ETS > match on variable-length keys? I don't know the answer. > > Given a set of keys such as [a,b,c], [a,b,c,d], and [a,b,c,d,e], can ETS > find all three keys given a search pattern like [a,b,'*'] ? > > I think I tried with patterns like [a,b,'_'] but that only finds [a,b,c] > and fails to get the others. ets:match_object(T, {[a, b | '_'] ..... a cons pattern would do the trick /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From thomas.arts@REDACTED Tue Jan 7 10:30:42 2003 From: thomas.arts@REDACTED (Thomas Arts) Date: Tue, 7 Jan 2003 10:30:42 +0100 Subject: Fw: Visualization tools for Erlang/OTP programs? Message-ID: <003c01c2b62f$729c9de0$f62d1081@ituniv398> --- FMICS 03, June 5-7 in Trondheim. Call for papers: http://www.inrialpes.fr/vasy/fmics/workshop-8/ Dr Thomas Arts Program Manager Software Engineering and Management IT-university of Gothenburg Box 8718, 402 75 Gothenburg, Sweden Tel +46 31 772 6031 Fax +46 31 772 4899 ----- Original Message ----- From: "Thomas Arts" To: ; "Kent Boortz" Sent: Saturday, January 04, 2003 1:37 PM Subject: Re: Visualization tools for Erlang/OTP programs? > Hi Kent > > I made a small supervisor visualisation tool two years ago. It is > based on Hans Nilsson's graph drawing program, whish in particular > is good in drawing trees (what one needs for supervision trees ;0). > > I would recommend the SVG format nowadays. This Scaled Vector Graphics > is a standard from Adobe that can be used to draw vector graphics. It is > an open standard and plug-ins exist for Netscape and Explorer, for example. > Another cool drawing package is "dot" from Lucent (Bell Labs). There > is a backend for dot to produce SVG. > > I attached my drawing software. If you would start the supervision > tree with supervisor:start(M,F,Args), then the visualization is started > with: visualize:supervisor(M,F,Args). > > I had to change "eval.erl" slightly, but with the three modules attached and > Hans' graph drawing package (see user contributions), this should work well. > Let me know if it doesn't, then I'll look into it a bit better. > > /Thomas > > > --- > FMICS 03, June 5-7 in Trondheim. > Call for papers: http://www.inrialpes.fr/vasy/fmics/workshop-8/ > > > Dr Thomas Arts > Program Manager > Software Engineering and Management > IT-university of Gothenburg > Box 8718, 402 75 Gothenburg, Sweden > > Tel +46 31 772 6031 > Fax +46 31 772 4899 > > > ----- Original Message ----- > From: "Kent Boortz" > To: > Sent: Saturday, January 04, 2003 4:49 AM > Subject: Visualization tools for Erlang/OTP programs? > > > > > > Has anyone tested any general visualization tools to describe > > Erlang/OTP programs, i.e. to visually describe the supervision, > > process structure, messages, state etc? Like "ROOM Diagrams"? > > Any success, i.e. was the the time it takes to draw them worth it in > > your case? Do you find the visualization useful in the design phase > > before coding or as a way to create internal design documumentation? > > > > Are any of the nine types of diagrams defined in UML usable for > > describing Erlang/OTP programs? > > > > Do you use any free or commercial drawing tools that you recommend for > > drawing diagrams to describe Erlang/OTP programs? > > > > The only drawings I have done myself is ascii drawings of the > > supervision structure, I'm just curious about what others do and if > > there is any potential for creating visual programming tools to > > generate Erlang programs or part of Erlang programs like processes > > that use gen_fsm, > > > > kent > > > > Ref: http://www.smartdraw.com/resources/centers/software/room.htm > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: app.erl Type: application/octet-stream Size: 13655 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: eval.erl Type: application/octet-stream Size: 24264 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: visualize.erl Type: application/octet-stream Size: 2392 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: supervior.jpg Type: image/jpeg Size: 31666 bytes Desc: not available URL: From etxuwig@REDACTED Tue Jan 7 10:42:43 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 7 Jan 2003 10:42:43 +0100 (MET) Subject: How to stop an Application In-Reply-To: <20030106061947.81072.qmail@web8203.mail.in.yahoo.com> Message-ID: On Mon, 6 Jan 2003, Suresh S wrote: >Hi , > >This is the start module of my aplicaiton, >there r two call back functions start and stop > >So can i use stop function (i.e entry_app:stop([]) >from an other module) to stop this applicaiton The way to stop the application would be application:stop(entry_app). (or whatever the actual application is called, if it`s not `entry_app`) The application controller will call the entry_app:stop/1 function to allow for e.g. some cleanup procedures to execute. Similarly, you use application:start(entry_app) to start the application. Depending on what you want to see happen if an application crashes, you could use either application:start(entry_app, permanent) (which means the node will terminate if your application crashes) or application:start(entry_app, temporary) (which means the node will stay up.) In the entry_app.app file, you need to insert a `mod` attribute like so: {mod, {entry_app, []}} ([] will work fine, since your entry_app module doesn`t care about the args anyway.) /Uffe >i am calling stop function but it is not working >what parameter i have to pass to this stop function >inorder to stop the application from an other module. > >-module(entry_app). >-behaviour(application). >-export([start/2,stop/1]). > >start(Type, _Args) -> > io:format("In Application Start Module.~n"), > entry_sup:start_link(). > >stop(S) -> > ok. > >Thanks in advace > >suresh s > >________________________________________________________________________ >Missed your favourite TV serial last night? Try the new, Yahoo! TV. > visit http://in.tv.yahoo.com > -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From etxuwig@REDACTED Tue Jan 7 10:51:55 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 7 Jan 2003 10:51:55 +0100 (MET) Subject: Efficient Functional Data Structures In-Reply-To: <20030107101739.A5029@bluetail.com> Message-ID: On Tue, 7 Jan 2003, Klacke wrote: >ets:match_object(T, {[a, b | '_'] ..... > > >a cons pattern would do the trick > >/klacke For searches like the one above, an ordered_set table is actually more efficient than a set, since it will not scan all objects -- only the ones that start with [a, b]. The same is true when using ets:select/2, as long as the first part(s) of the key is bound, and (if I recall correctly), there are no guard patterns. In other words, ets:match_object(T, {[`_`,b ? `_`], ...}) will have to search the entire table for both set and ordered_set. Also, ets:select(T,ets:fun2ms(fun({[H?T],Val} when H > 10 -> {[H?T], Val} end)). For really sophisticated ets searches, look at ets:select/2, and also take a look at the ms_transform module. (My X client seems to map the vertical bar to something that the Erlang parser doesn`t like, so I`ve had trouble producing a working example... I have yet to figure this out.) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From klacke@REDACTED Tue Jan 7 10:57:44 2003 From: klacke@REDACTED (Klacke) Date: Tue, 7 Jan 2003 10:57:44 +0100 Subject: Word origins (mnensia and mnemosyne) In-Reply-To: ; from mike@erix.ericsson.se on Tue, Jan 07, 2003 at 08:59:44AM +0000 References: <001b01c2b019$1dcf96d0$86d0b33e@dld2000>, <20021230183623.A24257@bluetail.com> Message-ID: <20030107105744.B5029@bluetail.com> On Tue, Jan 07, 2003 at 08:59:44AM +0000, Mike Williams wrote: > In article <20021230183623.A24257@REDACTED>, > klacke@REDACTED (Klacke) writes: > |> On Mon, Dec 30, 2002 at 04:35:43PM +0100, Daniel Dudley wrote: > > |> Once the OTP kit was getting ready for prime time, a couple > |> of serious suits came into my little research cubicle, closed > |> the door and said - Klacke, we must do something about this > |> non-proffesional-sounding name of the OTP database. > |> > |> I dropped the A. > > Klacke, > > I may wear a tie, but I don't wear a suit. > Mike, It wasn't you as fas as I can recall. It was that Jorma Mobrin guy and some of his apparatcniks. And they were serious (noclue) suits. Besides, you always wore a suit, sort of anyway. The kinda clothing that fits with a tie is called a suit. ... I think. I never wore a suit :-) /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From jocke@REDACTED Tue Jan 7 11:00:27 2003 From: jocke@REDACTED (Joakim G.) Date: Tue, 07 Jan 2003 11:00:27 +0100 Subject: Release: xmlrpc-1.0 References: <3E18C05D.9020602@bluetail.com> Message-ID: <3E1AA53B.9040203@bluetail.com> Btw, I have an Erlang XML-RPC server running on mes.gleipnir.com:4567 which is an implementation of the XML-RPC validation suite as decribed in http://www.xmlrpc.com/validator1Docs The server looks like this: http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/examples/validator.erl You can try the server yourself if you go to http://validator.xmlrpc.org/ and specify mes.gleipnir.com:4567 as server. Cheers /Jocke Joakim G. wrote: > Hi, > Someone asked for an XML-RPC library for Erlang some time back. I > needed such a beast myself. Here it is: > > http://www.gleipnir.com/xmlrpc/xmlrpc-1.0.tgz > > An unpacked version of it can be found here: > > http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/ > > Read the man page and examples for a quick understanding of what the > library provides: > > http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/doc/ > http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/examples/ > > Cheers > /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From matthias@REDACTED Tue Jan 7 14:46:02 2003 From: matthias@REDACTED (Matthias Lang) Date: Tue, 7 Jan 2003 14:46:02 +0100 Subject: Record selectors In-Reply-To: <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> References: <009f01c2b287$67808440$18d1b33e@dld2000> <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> Message-ID: <15898.55834.427525.928739@antilipe.corelatus.se> Daniel Dudley writes: > -module(test). > -export([selector/0]). > > -record(person, {name, phone, address}). > -record(country, {code, name}). > > selector() -> > Person = #person{name = "Joe", > phone = [0,8,2,3,4,3,1,2]}, > Country = #country{code = 47, > name = "Norway"}, > print_name(Person). > > print_name(X) -> > io:fwrite("~p~n", [X#country.name]), > io:fwrite("~p~n", [X#person.name]). [...] > The call X#country.name does not produce an error or > failure because the name of the country record's second > field is 'name'. Consequently, the value of the second > field (third element) in the X variable, which is bound to > a person record, is returned. > This example illustrates that not only is the reference to > a specific record-type in the record selector syntax > superflous, it is downright "dangerous" because it invites > error-prone code. [...] > The bottom line is that a record selector is tied to the > type of value stored in the variable being investigated. If > this type is (as expected) a tuple, then the actual record > type is (must be) determined by reading the first element > of the tuple. Only then can one decide which of the > remaining elements in the tuple corresponds to the > specified field. A way to do that without having to paste on a guard is to pattern match: print_name(#country{name = Name}) -> io:fwrite("~p~n", [Name]). this causes the above to fail, which is probably what you wanted. But no matter what you do, you can never be sure that a value really is what you think it is. Example: %% a.erl -module(a). -export([go/0]). -record(person, {name, age}). go() -> X = b:person(), name(X). name(X) when record(X, person) -> X#person.name. %% b.erl -module(b). -export([person/0]). -record(person, {age, name}). person() -> #person{name = "Robert was (ir)responsible", age = 45}. %% Erlang shell: 9> a:go(). 45 Contrived? No. This is a typical 'gotcha' when doing a hot upgrade. For instance, you might have removed some fields from the 'state' record in a gen_server. You load in the new code and forget to convert the old state to the new state in code_change/3 and the gen_server chokes on the next request it gets. You were talking about Erlang's bottom line. Records are a wart on Erlang's bottom. Not pretty. Not really that useful. Cause a few somewhat uncomfortable problems. But they're not going to kill you and they're surprisingly difficult to remove. Fiddling with them isn't going to improve things. (milked that metaphor for all it was worth and then some...) The only nice thing about records is that they're considerably less error prone than using bare tuples. In some situations. See also http://www.bluetail.com/wiki/showPage?node=ErlangFlaws Matthias From mike@REDACTED Tue Jan 7 14:48:09 2003 From: mike@REDACTED (Mike Williams) Date: 7 Jan 2003 13:48:09 GMT Subject: Missing bookmarks in Erlang book (pdf-version) References: <00a301c2b10d$313986a0$add0b33e@dld2000>, <15891.58627.430834.472522@antilipe.corelatus.se>, <00d601c2b292$83621dd0$18d1b33e@dld2000> Message-ID: In article <00d601c2b292$83621dd0$18d1b33e@REDACTED>, daniel.dudley@REDACTED (Daniel Dudley) writes: |> How would Erlang feel about releasing the copyright on |> their documentation? This would include "Concurrent |> Programming In Erlang" -- there's too much well-written |> stuff there to let it go to waste! As the docemnation is Open Source, it is distributed under the same Open Source license as the software. The copyright of "Concurrent Programming In Erlang" is owned by the publisher, origionally Prentice Hall, but now taken over by another company. As long as they are still sellimg the book, I can't see why they would be prepared to release the copyright. /mike From cpressey@REDACTED Tue Jan 7 14:51:27 2003 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 7 Jan 2003 07:51:27 -0600 Subject: Record selectors In-Reply-To: <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> References: <009f01c2b287$67808440$18d1b33e@dld2000> <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> Message-ID: <20030107075127.6e2143f1.cpressey@catseye.mb.ca> On Sun, 5 Jan 2003 11:43:37 +0100 "Daniel Dudley" wrote: > This thread has generated some interesting replies, but I'm > left wondering whether I have been entirely understood. > Here's a sample test module, which I hope will help clarify > my original message: > [...] > This example illustrates that not only is the reference to > a specific record-type in the record selector syntax > superflous, it is downright "dangerous" because it invites > error-prone code. Yep, it *is* dangerous, in the same way as omitting bounds-checking on fixed-length arrays is dangerous. It is not, however, superfluous (from the compiler's point of view.) The compiler has to know which record you mean, in order to generate efficient code. If it isn't told which record you mean, it would have to leave that decision up to the runtime, which would result in less efficient code. In essence, when you use records in Erlang, you're trading off safety for performance (just like when you omit bounds-checking in some other languages.) If this is a conscious, intentional tradeoff, there's nothing really wrong with it - assuming the programmers who are using your code can be trusted to have a certain minimum level of discipline. Another way to put this might be that, while Erlang is a dynamically-typed language, it currently uses a record mechanism taken straight from the pages of a textbook on statically-typed languages :) So, it's awkward. It is, however, a slightly nicer syntax than saying: -define(COUNTRY_NAME_POS, 3). ... MyCountryName = element(?COUNTRY_NAME_POS, MyCountry). > The bottom line is that a record selector is tied to the > type of value stored in the variable being investigated. If > this type is (as expected) a tuple, then the actual record > type is (must be) determined by reading the first element > of the tuple. Only then can one decide which of the > remaining elements in the tuple corresponds to the > specified field. In regards to safety, your point is *very* valid. The only thing I can add to it is that IMO it would be better if a new mechanism to enable such be added to the language, rather than changing the existing implementation of records and possibly breaking programs which have made performance assumptions about them. Actually, thinking about it a bit, a nifty trick could be to have the first element, instead of being an atom, be a fun that maps field names to positions. Like: CountryTag = fun (code) -> 2; (name) -> 3 end, Country = {CountryTag, 47, "Norway"}. This way, 'X#Y' would compile to element(element(1, X)(Y), X) While this provides a simple and inexpensive (I think) way for the runtime to decide which field goes where, it still doesn't address the more important issue that 'country' and 'tuple' are overlapping types. It would be much better if country could be a real, unique, opaque type, that couldn't be confused with any other type. It's all well and good to say that the representation of some data type (like those exported by the dict module etc) is undefined, but if that means that one could unknowingly write a pattern that accidentally matches it, it's still not very safe :) -Chris From enewhuis@REDACTED Tue Jan 7 15:42:02 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Tue, 7 Jan 2003 08:42:02 -0600 Subject: Advanced ETS Pattern Matching In-Reply-To: <440A2703A54A8F4FB2AC2AE34F27129D2159A4@ESEALNT889.al.sw.ericsson.se> Message-ID: <002501c2b65a$f0bd12b0$52c3cf0a@XENO> How can I convert a given list like [a,b] into a match specification like [a,b|'_'] to pass to ets? i.e. I may conditionally want to employ the use of |'_' in the match spec. I see that Erlang treats this as a literal: [a,b|'_'] But how can I construct it from its constituents a, b, and |'_' ? Sincerely, Eric From Erik.Reitsma@REDACTED Tue Jan 7 15:48:13 2003 From: Erik.Reitsma@REDACTED (Erik Reitsma (ELN)) Date: Tue, 7 Jan 2003 15:48:13 +0100 Subject: Advanced ETS Pattern Matching Message-ID: <440A2703A54A8F4FB2AC2AE34F27129D2159A7@ESEALNT889.al.sw.ericsson.se> > How can I convert a given list like [a,b] into a match specification > like [a,b|'_'] to pass to ets? i.e. I may conditionally want > to employ the use of |'_' in the match spec. Is this what you mean? Eshell V5.2 (abort with ^G) 1> L=[a,b]. [a,b] 2> L++'_'. [a,b|'_'] Regards, *Erik. From enewhuis@REDACTED Tue Jan 7 15:59:26 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Tue, 7 Jan 2003 08:59:26 -0600 Subject: Advanced ETS Pattern Matching In-Reply-To: <440A2703A54A8F4FB2AC2AE34F27129D2159A7@ESEALNT889.al.sw.ericsson.se> Message-ID: <002801c2b65d$5ef84d60$52c3cf0a@XENO> Thank you very much. I no longer feel ignorant. I probably just appear to be ignorant. The former was quick to resolve. The latter will take some time. But this is great. I will now flush my Trie down the toilet. ETS does everything I need. ETS rules!! Sincerely, Eric -----Original Message----- From: Erik Reitsma (ELN) [mailto:Erik.Reitsma@REDACTED] Sent: Tuesday, January 07, 2003 8:48 AM To: 'Eric Newhuis'; erlang-questions@REDACTED Subject: RE: Advanced ETS Pattern Matching > How can I convert a given list like [a,b] into a match specification > like [a,b|'_'] to pass to ets? i.e. I may conditionally want to > employ the use of |'_' in the match spec. Is this what you mean? Eshell V5.2 (abort with ^G) 1> L=[a,b]. [a,b] 2> L++'_'. [a,b|'_'] Regards, *Erik. From svg@REDACTED Tue Jan 7 18:41:21 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Tue, 07 Jan 2003 22:41:21 +0500 (YEKT) Subject: Y-combinator in Erlang Message-ID: <20030107.224121.85391035.svg@surnet.ru> Good day, I've surprisingly found Y-combinator very useful to solve practical problem of writing recursive anonymous functions in Erlang. Code were translated to Erlang from http://www.ece.uc.edu/~franco/C511/html/Scheme/ycomb.html. -module(lambda). -export([y/1, mk_fact/0]). %% Y-combinator itself y(X) -> F = fun (P) -> X(fun (Arg) -> (P(P))(Arg) end) end, F(F). %% Factorial example mk_fact() -> F = fun (FA) -> fun (N) -> if (N == 0) -> 1; true -> N * FA(N-1) end end end, y(F). >From shell: 1> F = mk_fact(). #Fun 2> F(5). 120 Best Regards, Vladimir Sekissov From hakanm@REDACTED Tue Jan 7 21:00:19 2003 From: hakanm@REDACTED (Hakan Millroth) Date: Tue, 7 Jan 2003 21:00:19 +0100 Subject: Y-combinator in Erlang In-Reply-To: <20030107.224121.85391035.svg@surnet.ru> Message-ID: Now you see why I used to argue that introducing funs etc into Erlang would make life tougher for the average joe :-) -- Hakan On Tuesday, January 7, 2003, at 06:41 PM, Vladimir Sekissov wrote: > Good day, > > I've surprisingly found Y-combinator very useful to solve practical > problem of writing recursive anonymous functions in Erlang. > > Code were translated to Erlang from > http://www.ece.uc.edu/~franco/C511/html/Scheme/ycomb.html. > > > -module(lambda). > > -export([y/1, mk_fact/0]). > > %% Y-combinator itself > y(X) -> > F = fun (P) -> X(fun (Arg) -> (P(P))(Arg) end) end, > F(F). > > %% Factorial example > mk_fact() -> > F = > fun (FA) -> > fun (N) -> > if (N == 0) -> 1; > true -> N * FA(N-1) > end > end > end, > y(F). > > > From shell: > > 1> F = mk_fact(). > #Fun > > 2> F(5). > 120 > > Best Regards, > Vladimir Sekissov From sureshsaragadam@REDACTED Wed Jan 8 06:33:07 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Wed, 8 Jan 2003 05:33:07 +0000 (GMT) Subject: Fw: Visualization tools for Erlang/OTP programs? In-Reply-To: <003c01c2b62f$729c9de0$f62d1081@ituniv398> Message-ID: <20030108053307.46284.qmail@web8205.mail.in.yahoo.com> Hi Thomas , I have down loaded This Visualization tool Is there any of the documentation work on this tool which better explains how to make use of this tool Thanks in advance suresh s > > Hi Kent > > > > I made a small supervisor visualisation tool two > years ago. It is > > based on Hans Nilsson's graph drawing program, > whish in particular > > is good in drawing trees (what one needs for > supervision trees ;0). > > > > I would recommend the SVG format nowadays. This > Scaled Vector Graphics > > is a standard from Adobe that can be used to draw > vector graphics. It is > > an open standard and plug-ins exist for Netscape > and Explorer, for > example. > > Another cool drawing package is "dot" from Lucent > (Bell Labs). There > > is a backend for dot to produce SVG. > > > > I attached my drawing software. If you would start > the supervision > > tree with supervisor:start(M,F,Args), then the > visualization is started > > with: visualize:supervisor(M,F,Args). > > > > I had to change "eval.erl" slightly, but with the > three modules attached > and > > Hans' graph drawing package (see user > contributions), this should work > well. > > Let me know if it doesn't, then I'll look into it > a bit better. ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From sureshsaragadam@REDACTED Wed Jan 8 11:42:20 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Wed, 8 Jan 2003 10:42:20 +0000 (GMT) Subject: Error when running boot script of an application Message-ID: <20030108104220.80817.qmail@web8206.mail.in.yahoo.com> Hi , i had generated a boot script for my application, but when i run that boot script this error is seen. [root@REDACTED 1.0]# erl -boot ./entry -boot_var SamApp Dir Erlang (BEAM) emulator version 5.0.1.1 [source] Eshell V5.0.1.1 (abort with ^G) 1> =INFO REPORT==== 8-Jan-2003::21:10:58 === application: entry exited: "invalid return value from entry_app:start(normal,[]) -> {'EXIT',{undef,\n [{entry_app,start,[normal,[]]},\n {application_master,start_it_old,4}]}}" type: permanent {'Kernel pid terminated',application_controller,shutdown} Kernel pid terminated (application_controller) (shutdown) What may be the solution probobly Thanking u in advance suresh s ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From sureshsaragadam@REDACTED Wed Jan 8 11:51:11 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Wed, 8 Jan 2003 10:51:11 +0000 (GMT) Subject: Error when running boot script of an application Message-ID: <20030108105111.30387.qmail@web8204.mail.in.yahoo.com> Hi , i had generated a boot script for my application, but when i run that boot script this error is seen. [root@REDACTED 1.0]# erl -boot ./entry -boot_var SamApp Dir Erlang (BEAM) emulator version 5.0.1.1 [source] Eshell V5.0.1.1 (abort with ^G) 1> =INFO REPORT==== 8-Jan-2003::21:10:58 === application: entry exited: "invalid return value from entry_app:start(normal,[]) -> {'EXIT',{undef,\n [{entry_app,start,[normal,[]]},\n {application_master,start_it_old,4}]}}" type: permanent {'Kernel pid terminated',application_controller,shutdown} Kernel pid terminated (application_controller) (shutdown) What may be the solution probobly Thanking u in advance suresh s ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From joe@REDACTED Wed Jan 8 12:31:04 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 8 Jan 2003 12:31:04 +0100 (CET) Subject: Y-combinator in Erlang In-Reply-To: Message-ID: I *strongly* object - the average joe would *not* use the Y combinator but write factorial thus: > Fac = fun(0, F) -> 1; (N, F) -> N * F(N-1, F) end. #Fun This is because the above form looks pretty much like factorial as God intended it to be written. It is called thus: > Fac(6, Fac). 720 /Joe Now how the average H?kan might have written it is a entirely different matter :-) On Tue, 7 Jan 2003, Hakan Millroth wrote: > Now you see why I used to argue that introducing funs etc into Erlang > would make life tougher for the average joe :-) > > -- Hakan > > On Tuesday, January 7, 2003, at 06:41 PM, Vladimir Sekissov wrote: > > > Good day, > > > > I've surprisingly found Y-combinator very useful to solve practical > > problem of writing recursive anonymous functions in Erlang. > > > > Code were translated to Erlang from > > http://www.ece.uc.edu/~franco/C511/html/Scheme/ycomb.html. > > > > > > -module(lambda). > > > > -export([y/1, mk_fact/0]). > > > > %% Y-combinator itself > > y(X) -> > > F = fun (P) -> X(fun (Arg) -> (P(P))(Arg) end) end, > > F(F). > > > > %% Factorial example > > mk_fact() -> > > F = > > fun (FA) -> > > fun (N) -> > > if (N == 0) -> 1; > > true -> N * FA(N-1) > > end > > end > > end, > > y(F). > > > > > > From shell: > > > > 1> F = mk_fact(). > > #Fun > > > > 2> F(5). > > 120 > > > > Best Regards, > > Vladimir Sekissov > From bertil.karlsson@REDACTED Wed Jan 8 14:03:56 2003 From: bertil.karlsson@REDACTED (Bertil Karlsson) Date: Wed, 08 Jan 2003 14:03:56 +0100 Subject: asn1: swapped fields References: <9CC6CC2973F2D211B3580008C70DB2D205708975@eatvint903.dsa.ericsson.se> Message-ID: <3E1C21BC.8A6D51D5@uab.ericsson.se> Hello, This is definitely a bug, and it will be corrected in the next patch. /Bertil Karlsson "Jozsef Berces (QCZ)" wrote: > > Hi, > > I have compiled RANAP with asn1ct and the decoder erlang code produces swapped fields for ProtocolIE-FieldPair: firstValue and secondCriticality are swapped in the resulting record. Here I am posting a simplified example. > > If you try to compile the attached file RAB-SetupOrModifyList.asn with option per, then for the sequence > > ProtocolIE-FieldPair {RANAP-PROTOCOL-IES-PAIR : IEsSetParam} ::= SEQUENCE { > id RANAP-PROTOCOL-IES-PAIR.&id ({IEsSetParam}), > firstCriticality RANAP-PROTOCOL-IES-PAIR.&firstCriticality ({IEsSetParam}{@id}), > firstValue RANAP-PROTOCOL-IES-PAIR.&FirstValue ({IEsSetParam}{@id}), > secondCriticality RANAP-PROTOCOL-IES-PAIR.&secondCriticality ({IEsSetParam}{@id}), > secondValue RANAP-PROTOCOL-IES-PAIR.&SecondValue ({IEsSetParam}{@id}) > } > > the erlang code will be > > 'dec_RAB-SetupOrModifyList_SEQOF_ProtocolIE-FieldPair'(Bytes,Telltype) -> > > %% attribute number 1 with type id > {Term1,Bytes1} = ?RT_PER:decode_integer(Bytes,[{'ValueRange',{0,65535}}]), > > %% attribute number 2 with type firstCriticality > {Term2,Bytes2} = ?RT_PER:decode_enumerated(Bytes1,[{'ValueRange',{0,2}}],{reject,ignore,notify}), > > %% attribute number 3 with type FirstValue > {Tmpterm1, Bytes3} = ?RT_PER:decode_open_type(Bytes2, []), > > %% attribute number 4 with type secondCriticality > {Term3,Bytes4} = ?RT_PER:decode_enumerated(Bytes3,[{'ValueRange',{0,2}}],{reject,ignore,notify}), > > %% attribute number 5 with type SecondValue > {Tmpterm2, Bytes5} = ?RT_PER:decode_open_type(Bytes4, []), > DecObjidTerm1 = > 'getdec_RAB-SetupOrModifyItem-IEs'(id, Term1), > {Term4, _} = > case DecObjidTerm1('FirstValue', Tmpterm1, telltype,[]) of > {'EXIT', Reason1} -> > exit({'Type not compatible with table constraint',Reason1}); > Tmpterm3 -> > Tmpterm3 > end, > {Term5, _} = > case DecObjidTerm1('SecondValue', Tmpterm2, telltype,[]) of > {'EXIT', Reason2} -> > exit({'Type not compatible with table constraint',Reason2}); > Tmpterm4 -> > Tmpterm4 > end, > > {{'ProtocolIE-FieldPair',Term1,Term2,Term3,Term4,Term5},Bytes5}. > > > It can be seen that attribute number 3 is assigned to Term4 and attribute number 4 goes to Term3. It seems that the problem is to have the 'getdec_RAB-SetupOrModifyItem-IEs'(id, Term1) call too late, so Term4 will receive attribute number 3. > > I attached the results for different options: per, per_bin, and ber. per and per_bin are the same but ber is even worse (however, RANAP uses PER encoding)! > > Could someone post a fix? Until then we have to modify the erang code manually. > > Thanks in advance, > Jozsef > > ------------------------------------------------------------------------ > > RAB-SetupOrModifyList.asnName: RAB-SetupOrModifyList.asn > Type: unspecified type (application/octet-stream) > > Name: RAB-SetupOrModifyList.ber.erl > RAB-SetupOrModifyList.ber.erl Type: unspecified type (application/octet-stream) > Encoding: quoted-printable > > Name: RAB-SetupOrModifyList.per.erl > RAB-SetupOrModifyList.per.erl Type: unspecified type (application/octet-stream) > Encoding: quoted-printable > > Name: RAB-SetupOrModifyList.per_bin.erl > RAB-SetupOrModifyList.per_bin.erl Type: unspecified type (application/octet-stream) > Encoding: quoted-printable -- / Bertil Karlsson From hakanm@REDACTED Wed Jan 8 15:18:27 2003 From: hakanm@REDACTED (Hakan Millroth) Date: Wed, 8 Jan 2003 15:18:27 +0100 Subject: Y-combinator in Erlang In-Reply-To: Message-ID: <0E06C606-2314-11D7-BDB8-0003939B65EA@nortelnetworks.com> > Now how the average H?kan might have written it is a entirely > different matter :-) As a named function. Whatever you gain in expressive power with funs you risk losing by people using them in a way that is hard to understand. Classic example. Consider the higher-order function (standard math notation): twice(F)(X) = F(F(X)) Let double(X)=X+X and figure out what F(1) is, where F=twice(twice(twice(twice(double)))). I'm just arguing that sometimes power tools are not good things. -- Hakan From svg@REDACTED Wed Jan 8 15:15:38 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Wed, 08 Jan 2003 19:15:38 +0500 (YEKT) Subject: Y-combinator in Erlang In-Reply-To: References: Message-ID: <20030108.191538.39175848.svg@surnet.ru> Good day, joe> > Fac = fun(0, F) -> 1; joe> (N, F) -> N * F(N-1, F) end. Yes, I deed so many times but using fixed-point property of Y we can easy get some interesing results. For example, lets slightly modify our y definition: ya(A, X) -> F = fun (P) -> X(fun (Arg) -> A(P(P), Arg) end) end, F(F). fact(FA) -> fun (0) -> 1; (N) -> N * FA(N-1) end. mk_fact1() -> Apply = fun (F, A) -> R=apply(F, [A]), io:format("arg:~p, result:~p~n", [A, R]), R end, ya(Apply, fun fact/1). >From shell: (svg@REDACTED)20> F = svglib.lambda:mk_fact1(). #Fun (svg@REDACTED)21> F(5). arg:0, result:1 arg:1, result:1 arg:2, result:2 arg:3, result:6 arg:4, result:24 120 Please mention that we didn't modify our core function `fact/1' at all. Best Regards, Vladimir Sekissov joe> I *strongly* object - the average joe would *not* use the Y combinator joe> but write factorial thus: joe> joe> > Fac = fun(0, F) -> 1; joe> (N, F) -> N * F(N-1, F) end. joe> joe> #Fun joe> joe> This is because the above form looks pretty much like factorial as God joe> intended it to be written. joe> joe> It is called thus: joe> joe> > Fac(6, Fac). joe> 720 joe> joe> /Joe joe> joe> Now how the average H?kan might have written it is a entirely joe> different matter :-) joe> joe> joe> joe> On Tue, 7 Jan 2003, Hakan Millroth wrote: joe> joe> > Now you see why I used to argue that introducing funs etc into Erlang joe> > would make life tougher for the average joe :-) joe> > joe> > -- Hakan joe> > joe> > On Tuesday, January 7, 2003, at 06:41 PM, Vladimir Sekissov wrote: joe> > joe> > > Good day, joe> > > joe> > > I've surprisingly found Y-combinator very useful to solve practical joe> > > problem of writing recursive anonymous functions in Erlang. joe> > > joe> > > Code were translated to Erlang from joe> > > http://www.ece.uc.edu/~franco/C511/html/Scheme/ycomb.html. joe> > > joe> > > joe> > > -module(lambda). joe> > > joe> > > -export([y/1, mk_fact/0]). joe> > > joe> > > %% Y-combinator itself joe> > > y(X) -> joe> > > F = fun (P) -> X(fun (Arg) -> (P(P))(Arg) end) end, joe> > > F(F). joe> > > joe> > > %% Factorial example joe> > > mk_fact() -> joe> > > F = joe> > > fun (FA) -> joe> > > fun (N) -> joe> > > if (N == 0) -> 1; joe> > > true -> N * FA(N-1) joe> > > end joe> > > end joe> > > end, joe> > > y(F). joe> > > joe> > > joe> > > From shell: joe> > > joe> > > 1> F = mk_fact(). joe> > > #Fun joe> > > joe> > > 2> F(5). joe> > > 120 joe> > > joe> > > Best Regards, joe> > > Vladimir Sekissov joe> > From joe@REDACTED Wed Jan 8 15:57:48 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 8 Jan 2003 15:57:48 +0100 (CET) Subject: Y-combinator in Erlang In-Reply-To: <0E06C606-2314-11D7-BDB8-0003939B65EA@nortelnetworks.com> Message-ID: > > Now how the average H?kan might have written it is a entirely > > different matter :-) > > As a named function. Whatever you gain in expressive power with funs > you risk losing by people using them in a way that is hard to > understand. > Almost anything can be abused if you try hard enough. What does: foo() -> Z = make_ref(), bar(self() ! {Z, left}, self() ! {Z, right}), receive {Z, I} -> receive {Z, J} -> I end end. bar(_, _) -> void. do? > Classic example. Consider the higher-order function (standard math > notation): > > twice(F)(X) = F(F(X)) > > Let double(X)=X+X and figure out what F(1) is, where > F=twice(twice(twice(twice(double)))). > > I'm just arguing that sometimes power tools are not good things. > I agree entirely - you must constantly strive to write "mind boggling simple code" One good way to to this is to mentally repeat the phrase: "I must write as inefficient code as possible" one thousand times before breakfast ever day :-) K & P still applies: (I paraphrase) 1) make it right 2) make it fast once you've got it right 3) keep it right as you make it faster IMHO the fast majority of programmers (myself included) don't get past 1) The well tried method used by many large industrial concerns is: 1a) Ship it first 1b) Make it fast 2) Debug it 3a) Understand the problem 3b) Discontinue the product 1a and 1b are done concurrently as are 3a and 3b Often they never get to 3a - sometimes they use the accelerated design method of 1b followed 3b. This method is not recommended. /Joe > -- Hakan > From hakanm@REDACTED Wed Jan 8 16:26:56 2003 From: hakanm@REDACTED (Hakan Millroth) Date: Wed, 8 Jan 2003 16:26:56 +0100 Subject: Y-combinator in Erlang In-Reply-To: Message-ID: <9F41FEF0-231D-11D7-B8C4-0003939B65EA@nortelnetworks.com> > Almost anything can be abused if you try hard enough. Yes, of course. However, certain things are easier than others to misuse. There is sometimes a tradeoff between expressability and transparency. -- Hakan From matthias@REDACTED Wed Jan 8 16:26:05 2003 From: matthias@REDACTED (Matthias Lang) Date: Wed, 8 Jan 2003 16:26:05 +0100 Subject: [PATCH]:erts/emulator/beam/erl_time_sup.c In-Reply-To: <20030104.224513.41651862.svg@surnet.ru> References: <20030104.224513.41651862.svg@surnet.ru> Message-ID: <15900.17165.346143.36202@antilipe.corelatus.se> This patch has a couple of problems. Firstly, it breaks the existing code. Example: this line (in the same function as the code the patch changes): current_correction = ((ct_diff - tv_diff) / TICK_MS) * TICK_MS; /* trunc */ does not work if TICK_MS is floating point. With floating point, it won't truncate the value as advertised. With integer arithmetic it will. Secondly, it introduces more floating point code into areas of Erlang which aren't directly related to floating point. For desktop PCs, this isn't a problem since they all have CPUs with hardware floating point support. But most embedded CPUs don't have that, so at best it's a performance hit (if the OS has floating point emulation) and at worst it causes a crash (I think this is the case for VxWorks). Aside: a quick grep of the sources showed that the GC and memory allocation code has floating point code in it now. What do the VxWorks users do? Are there any left? Matthias Vladimir Sekissov writes: > Good day, > > This simple patch is intended to new Linux kernels (2.5.*) where > > sysconf(_SC_CLK_TCK) == 1024 > > but some code in `erts/emulator/beam/erl_time_sup.c' were written with > assumption that this value is far less than 1000(it is traditionally > 100 on most systems). > > Best regards, > Vladimir Sekissov > > --- erts/emulator/beam/erl_time_sup.c.orig 2003-01-04 22:30:47.000000000 +0500 > +++ erts/emulator/beam/erl_time_sup.c 2003-01-04 22:27:00.000000000 +0500 > @@ -219,7 +219,7 @@ > Milli act_correction; /* long showed to be too small */ > Milli max_adjust; > > -#define TICK_MS (1000 / SYS_CLK_TCK) > +#define TICK_MS (1000.0 / SYS_CLK_TCK) > > current_ct = KERNEL_TICKS(); > sys_gettimeofday(¤t_tv); From jabba@REDACTED Wed Jan 8 21:56:25 2003 From: jabba@REDACTED (Jani Launonen) Date: Wed, 8 Jan 2003 22:56:25 +0200 (EET) Subject: Heart problem with dist_ac-example Message-ID: Hello, I've been studying Ulf's distributed application controller example http://www.erlang.org/ml-archive/erlang-questions/200212/msg00009.html and reading manuals to understand it's structure. I tried to amuse myself with making the two nodes required by the example to restart in case of crash by heart. Unfortunately, something doesn't go quite right as I got the next kind of message: (at node n2 after applications have started and I'm about to signal kill to the beam to crash it): "... =PROGRESS REPORT==== 8-Jan-2003::22:20:46 === application: erlyhack_map_app started_at: 'n2@REDACTED' Killed jabba@REDACTED:~/temp/dist_ac> heart: Wed Jan 8 22:22:24 2003: Erlang has closed. Kernel pid terminated (application_controller) (shutdown) heart: Wed Jan 8 22:22:39 2003: Executed "/usr/local/bin/erl -name n2@REDACTED -boot /home/jabba/temp/dist_ac/releases/1.0/hack -config /home/jabba/temp/dist_ac/releases/1.0/sys". Terminating." I've set up HEART_COMMAND as export HEART_COMMAND='/usr/local/bin/erl -name n2@REDACTED -boot /home/jabba/temp/dist_ac/releases/1.0/hack -config /home/jabba/temp/dist_ac/releases/1.0/sys' and started the node by manually by command: erl -name n2@REDACTED -boot /home/jabba/temp/dist_ac/releases/1.0/hack -config /home/jabba/temp/dist_ac/releases/1.0/sys -heart Here's the erl_crash.dump's first lines (the whole dump is compressed and attached): " Wed Jan 8 22:22:38 2003 Slogan: Kernel pid terminated (application_controller) (shutdown) Erlang (BEAM) emulator version 5.2 Compiled on Fri Dec 13 17:30:24 2002 Process Information -------------------------------------------------- <0.0.0> Running. Registered as: init Spawned as: otp_ring0:start/2 Message queue (1 message): [{'EXIT',<0.1.0>,{noproc,{gen_server,call,[applicatio n_controller,{load_application,stdlib},infinity]}}}] Link list: [<0.4.0>,<0.2.0>] Reductions 4854 heap_sz 121393 old_heap_sz=28657 Heap unused=120759 OldHeap unused=28657 Stack dump: program counter = 0x83a230c (init:sleep/1 + 32) cp = 0x839fc08 (init:things_to_string/1 + 68) 0x40243c78 Return addr 0x83A02EC (init:boot_loop/2 + 1412) 0x40243c7c Return addr 0x815E448 () y(0) [] y(1) {state,[{'-root',[<<21 bytes>>]},{'-progname',[<<3 bytes>>]},{'-home',[ <<11 bytes>>]},{'-name',[<<12 bytes>>]},{'-boot',[<<42 bytes>>]},{'-config',[<<4 1 bytes>>]}],[],[],[{application_controller,<0.5.0>},{error_logger,<0.4.0>},{erl _prim_loader,<0.2.0>}],<0.1.0>,{starting,applications_loaded},{"Hack","1.0"},[]} y(2) <0.1.0> -------------------------------------------------- " If I understand it, stdlib could not be loaded. I just cannot understand why. Manually executing the HEART_COMMAND works just ok, so I'm bit puzzled with this. Propably it's just something simple, that I just cannot find by myself. If you know the problem or can point to a direction, please help me. Thank you, -+-+-+- Jani Launonen Student. . . . . . . . . .University of Oulu, Dept. of EE Assistant Researcher . . .Apricot Project "Computing is a field which has one of the shortest collective memories of any engineering or scientific discipline." - Marty Fouts, comp.distributed -------------- next part -------------- A non-text attachment was scrubbed... Name: erl_crash.dump.gz Type: application/octet-stream Size: 24134 bytes Desc: URL: From per@REDACTED Thu Jan 9 00:00:33 2003 From: per@REDACTED (Per Hedeland) Date: Thu, 9 Jan 2003 00:00:33 +0100 (CET) Subject: [PATCH]:erts/emulator/beam/erl_time_sup.c In-Reply-To: <15900.17165.346143.36202@antilipe.corelatus.se> Message-ID: <200301082300.h08N0XK56746@tordmule.bluetail.com> Matthias Lang wrote: > >Secondly, it introduces more floating point code into areas of Erlang >which aren't directly related to floating point. For desktop PCs, this >isn't a problem since they all have CPUs with hardware floating point >support. But most embedded CPUs don't have that, so at best it's a >performance hit (if the OS has floating point emulation) and at worst >it causes a crash (I think this is the case for VxWorks). > >Aside: a quick grep of the sources showed that the GC and memory > allocation code has floating point code in it now. What do > the VxWorks users do? Are there any left? There are a couple of us around here (still at R7 for this application though) - and while I'm not a fan of VxWorks (wasn't our choice:-), I think you're a bit unfair - it includes fully usable SW FP emulation for most supported architectures AFAIK. Of course in our case, the company we collaborate with on this, which provides both BSP and basic VxWorks setup, had managed to neither properly initialize the HW FP that was actually there in the CPU (MIPS 4000-ish) nor activate the FP emulation - this didn't cause a crash in our case, but most FP operations and functions just returned 0.0, which had some "interesting" effects. (Well we did get crashes when we tried to change that...) And to get somewhat back on-topic for the list, you can now all make a note in your calendars that Erlang (with some very minor porting tweaks) runs just fine on VxWorks on MIPS - though I wouldn't be surprised if we're the only ones in the world that care.:-) --Per Hedeland per@REDACTED From enewhuis@REDACTED Thu Jan 9 01:01:27 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Wed, 8 Jan 2003 18:01:27 -0600 Subject: Release: xmlrpc-1.0 In-Reply-To: <3E1AA53B.9040203@bluetail.com> Message-ID: <001101c2b772$4200f930$54c3cf0a@XENO> Nice work! However, it looks like your distribution is missing the xmlrpc.hrl file. Sincerely, Eric -----Original Message----- From: owner-erlang-questions@REDACTED [mailto:owner-erlang-questions@REDACTED] On Behalf Of Joakim G. Sent: Tuesday, January 07, 2003 4:00 AM To: Joakim G. Cc: erlang-questions@REDACTED Subject: Re: Release: xmlrpc-1.0 Btw, I have an Erlang XML-RPC server running on mes.gleipnir.com:4567 which is an implementation of the XML-RPC validation suite as decribed in http://www.xmlrpc.com/validator1Docs The server looks like this: http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/examples/validator.er l You can try the server yourself if you go to http://validator.xmlrpc.org/ and specify mes.gleipnir.com:4567 as server. Cheers /Jocke Joakim G. wrote: > Hi, > Someone asked for an XML-RPC library for Erlang some time back. I > needed such a beast myself. Here it is: > > http://www.gleipnir.com/xmlrpc/xmlrpc-1.0.tgz > > An unpacked version of it can be found here: > > http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/ > > Read the man page and examples for a quick understanding of what the > library provides: > > http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/doc/ > http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/examples/ > > Cheers > /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From enewhuis@REDACTED Thu Jan 9 01:55:30 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Wed, 8 Jan 2003 18:55:30 -0600 Subject: Binary Large Erlang Dump Message-ID: <002501c2b779$cf1634a0$54c3cf0a@XENO> What is the Erlang way to serialize/pickle a large stream of Erlang terms? We have these Erlang processes spitting out vast amounts of Erlang terms that we would like to capture on disk for later playback. We're talking about 20 MB per hour at least. So we figure we'll create one file every 20 minutes. But we just started using Erlang and have no idea what the best serialization format is. Also, we need to quickly play the data back into an Erlang process. So we don't want to have to parse the data. It would be nice to have some kind of automatic stream that just regenerated messages. We'll have a recorder that creates the files and a player that plays the files. I suppose, related conceptually, would be the idea of a transaction log on disk for arbitrary Erlang messages. Sincerely, Eric From dgud@REDACTED Thu Jan 9 07:38:13 2003 From: dgud@REDACTED (Dan Gudmundsson) Date: Thu, 9 Jan 2003 07:38:13 +0100 Subject: Binary Large Erlang Dump In-Reply-To: <002501c2b779$cf1634a0$54c3cf0a@XENO> References: <002501c2b779$cf1634a0$54c3cf0a@XENO> Message-ID: <15901.6357.106627.816315@gargle.gargle.HOWL> Eric Newhuis writes: > > We'll have a recorder that creates the files and a player that plays the > files. I suppose, related conceptually, would be the idea of a > transaction log on disk for arbitrary Erlang messages. > Take a look at 'disk_log' manual. That is used in mnesia and often used as an error_logger. /Dan From thomas.arts@REDACTED Thu Jan 9 09:29:05 2003 From: thomas.arts@REDACTED (Thomas Arts) Date: Thu, 9 Jan 2003 09:29:05 +0100 Subject: Fw: Visualization tools for Erlang/OTP programs? References: <20030108053307.46284.qmail@web8205.mail.in.yahoo.com> Message-ID: <004201c2b7b9$2be42540$f62d1081@ituniv398> Hi Suresh > I have down loaded This Visualization tool > Is there any of the documentation work on this tool > which better explains how to make use of this tool There's not much documentation for this software, I used it for my own pleasure. There are some explaining lines of comment in the code, I hope. The principle is rather simple, though. You interpret the code by using erlang's eval module. The eval module is changed in such a way that every "spawn" (gen_server:start etc) returns the command to the caller of the evaluator, instead of really spawning the process. One starts with the supervisor node and evaluates all children upto the spawn moment. Recursively for all child supervisors. Dead-easy, but gives for well written code a nice picture for a certian CONFIGURATION! You have to initialize the supervision tree with certain values, thus you get one instance of the system. Jan Nystr?m, previously doing a PhD at Uppsala university, also worked on a visualization tool. You might ask him for his version, which has the same ideas in the background, but is more elaborated then my version. /Thomas --- FMICS 03, June 5-7 in Trondheim. Call for papers: http://www.inrialpes.fr/vasy/fmics/workshop-8/ Dr Thomas Arts Program Manager Software Engineering and Management IT-university of Gothenburg Box 8718, 402 75 Gothenburg, Sweden Tel +46 31 772 6031 Fax +46 31 772 4899 From jocke@REDACTED Thu Jan 9 09:51:58 2003 From: jocke@REDACTED (Joakim G.) Date: Thu, 09 Jan 2003 09:51:58 +0100 Subject: Release: xmlrpc-1.0 References: <001101c2b772$4200f930$54c3cf0a@XENO> Message-ID: <3E1D382E.50302@bluetail.com> Argh! Thanks. I have built a new release (version 1.1). Get it at: http://www.gleipnir.com/xmlrpc/ == Thu Jan 9 08:16:45 CET 2003 == Version 1.1 * src/xmlrpc.hrl missing in the release package (bah!). * xmlrpc.pub added to make addition to http://www.erlang.org/user.html possible. * Not possible to start several servers in single Erlang node. Cheers /Jocke Eric Newhuis wrote: > Nice work! However, it looks like your distribution is missing the > xmlrpc.hrl file. > > Sincerely, > Eric > > > > -----Original Message----- > From: owner-erlang-questions@REDACTED > [mailto:owner-erlang-questions@REDACTED] On Behalf Of Joakim G. > Sent: Tuesday, January 07, 2003 4:00 AM > To: Joakim G. > Cc: erlang-questions@REDACTED > Subject: Re: Release: xmlrpc-1.0 > > > Btw, I have an Erlang XML-RPC server running on mes.gleipnir.com:4567 > which is an implementation of the XML-RPC validation suite as decribed > in http://www.xmlrpc.com/validator1Docs > > The server looks like this: > http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/examples/validator.er > l > > You can try the server yourself if you go to > http://validator.xmlrpc.org/ and specify mes.gleipnir.com:4567 as > server. > > Cheers > /Jocke > > Joakim G. wrote: > >>Hi, >>Someone asked for an XML-RPC library for Erlang some time back. I >>needed such a beast myself. Here it is: >> >>http://www.gleipnir.com/xmlrpc/xmlrpc-1.0.tgz >> >>An unpacked version of it can be found here: >> >>http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/ >> >>Read the man page and examples for a quick understanding of what the >>library provides: >> >>http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/doc/ >>http://www.gleipnir.com/xmlrpc/unpacked/xmlrpc-1.0/examples/ >> >>Cheers >>/Jocke > > > From enano@REDACTED Thu Jan 9 10:22:01 2003 From: enano@REDACTED (Miguel Barreiro Paz) Date: Thu, 9 Jan 2003 10:22:01 +0100 (CET) Subject: Binary Large Erlang Dump In-Reply-To: <002501c2b779$cf1634a0$54c3cf0a@XENO> References: <002501c2b779$cf1634a0$54c3cf0a@XENO> Message-ID: > What is the Erlang way to serialize/pickle a large stream of Erlang > terms? We have these Erlang processes spitting out vast amounts of > Erlang terms that we would like to capture on disk for later playback. > > We're talking about 20 MB per hour at least. So we figure we'll create > one file every 20 minutes. But we just started using Erlang and have no > idea what the best serialization format is. In my humble erlang experience, 20 MB per hour is very far from "vast amounts" of data as far as Erlang is concerned. Now, 20MB per second, that would be something :-) Erlang is certainly not C in execution speed, but in general terms you shouldn't worry too much about speed. Not at least until you have proven that you do have performance problems. Regards, Miguel From etxuwig@REDACTED Thu Jan 9 11:27:39 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 9 Jan 2003 11:27:39 +0100 (MET) Subject: Fw: Visualization tools for Erlang/OTP programs? In-Reply-To: <004201c2b7b9$2be42540$f62d1081@ituniv398> Message-ID: On Thu, 9 Jan 2003, Thomas Arts wrote: >Jan Nystr?m, previously doing a PhD at Uppsala university, >also worked on a visualization tool. You might ask him for >his version, which has the same ideas in the background, >but is more elaborated then my version. > >/Thomas Not sure if Jan Nystr?m is active on this list, but his current email is: Jan Henry Nystrom Jan now has a post-doc at the Herriot-Watt University in Edinburgh. Google revealed the following snippet in a Haskell group, posted by Paul Trinder at H-W Uni: "Jan Nystrom will join us at Heriot-Watt in November from Upsala as the RA on a new EPSRC/Motorola Research Labs project investigating Erlang & GdH for distributed telecoms applications." Jan has "promised" to continue working on his visualization tool as time allows. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From sureshsaragadam@REDACTED Fri Jan 10 13:03:26 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Fri, 10 Jan 2003 12:03:26 +0000 (GMT) Subject: {'Kernel pid terminated',application_controller,shutdown} Message-ID: <20030110120326.86027.qmail@web8203.mail.in.yahoo.com> hi, => Kernel pid terminated (application_controller) (shutdown) I am starting my own applicaiton from shell with the boot script generated for it to start, I had an invalid return value from entry_app:start(normal,[]) i am starting this way from the shell prompt erl -boot ./entry -boot_var SamApp Dir My approach ----------- My application does not use any behaviour other than start module(behaves as an applicaiton) and supervisor module, Here i have to make use of Supervisor behaviour( Supervisor tree ) even though other modules of my applicaiton does not follow any protocol (i.e Any Other behavious) Here i have to make a release, the release resourse file will check the correctness of my application , So i think the way out is i have to make use of supervisor_bridge, i inculded a supervisor_bridge module which should start my own applicaiton.. Is this a correct Approach My sample work on this is attached please c to this if possible and let me know for any corrections thanking u [root@REDACTED 1.0]# erl -boot ./entry -boot_var SamApp Dir Erlang (BEAM) emulator version 5.0.1.1 [source] Eshell V5.0.1.1 (abort with ^G) 1> =INFO REPORT==== 10-Jan-2003::22:29:50 === application: entry exited: "invalid return value from entry_app:start(normal,[]) -> {'EXIT',{undef,\n [{entry_app,start,[normal,[]]},\n {application_master,start_it_old,4}]}}" type: permanent {'Kernel pid terminated',application_controller,shutdown} Kernel pid terminated (application_controller) (shutdown) ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: test_app.tar Type: application/x-tar Size: 1710080 bytes Desc: test_app.tar URL: From bjarne@REDACTED Fri Jan 10 15:17:34 2003 From: bjarne@REDACTED (Bjarne Däcker) Date: Fri, 10 Jan 2003 15:17:34 +0100 Subject: {'Kernel pid terminated',application_controller,shutdown} References: <20030110120326.86027.qmail@web8203.mail.in.yahoo.com> Message-ID: <3E1ED5FE.50118E3@erix.ericsson.se> Hello Suresh > My sample work on this is attached please c to this if > possible and let me know for any corrections Please do not send mails with such voluminous attachments. Keep them on your homepage where interested parties may collect them. Best wishes Bjarne From valentin@REDACTED Fri Jan 10 18:16:01 2003 From: valentin@REDACTED (Valentin) Date: Fri, 10 Jan 2003 19:16:01 +0200 Subject: {'Kernel pid terminated',application_controller,shutdown} References: <20030110120326.86027.qmail@web8203.mail.in.yahoo.com> Message-ID: <008a01c2b8cb$f3b2ac00$9ced1ec4@moneymaker> Suresh was it really necessary to post the whole 1.68 Meg of data to the mailing list? I might be out of line, but sending it to an individual might have been a better choice. Valentin. ----- Original Message ----- From: "Suresh S" To: Cc: Sent: Friday, January 10, 2003 2:03 PM Subject: {'Kernel pid terminated',application_controller,shutdown} > hi, > > => Kernel pid terminated (application_controller) > (shutdown) > > I am starting my own applicaiton from shell with the > boot script generated for it to start, I had an > invalid return value from > entry_app:start(normal,[]) > > i am starting this way from the shell prompt > > erl -boot ./entry -boot_var SamApp Dir > > My approach > ----------- > My application does not use any behaviour other than > start module(behaves as an applicaiton) and supervisor > module, > > Here i have to make use of Supervisor behaviour( > Supervisor tree ) even though other modules of my > applicaiton does not follow any protocol (i.e Any > Other behavious) > > Here i have to make a release, the release resourse > file will check the correctness of my application , So > i think the way out is i have to make use of > supervisor_bridge, i inculded a supervisor_bridge > module which should start my own applicaiton.. > > Is this a correct Approach > > My sample work on this is attached please c to this if > possible and let me know for any corrections > > thanking u > [root@REDACTED 1.0]# erl -boot ./entry -boot_var > SamApp Dir > Erlang (BEAM) emulator version 5.0.1.1 [source] > > Eshell V5.0.1.1 (abort with ^G) > 1> > =INFO REPORT==== 10-Jan-2003::22:29:50 === > application: entry > exited: "invalid return value from > entry_app:start(normal,[]) -> {'EXIT',{undef,\n > > [{entry_app,start,[normal,[]]},\n > > {application_master,start_it_old,4}]}}" > type: permanent > {'Kernel pid > terminated',application_controller,shutdown} > Kernel pid terminated (application_controller) > (shutdown) > > > ________________________________________________________________________ > Missed your favourite TV serial last night? Try the new, Yahoo! TV. > visit http://in.tv.yahoo.com From sureshsaragadam@REDACTED Sat Jan 11 07:16:21 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Sat, 11 Jan 2003 06:16:21 +0000 (GMT) Subject: {'Kernel pid terminated',application_controller,shutdown} In-Reply-To: <3E1ED5FE.50118E3@erix.ericsson.se> Message-ID: <20030111061621.46011.qmail@web8204.mail.in.yahoo.com> >Please do not send mails with >such voluminous attachments. >Keep them on your homepage >where interested parties may >collect them. >Best wishes >Bjarne Hi Bjarne, Morning when i logged in to ckeck my mails, i noticed my InBox is out of storage memory , then later when i checked ur mail i came to know that all the erlang subscrers might have suffered from the same problem I rellay Appriciate such good suggestions , Thank u suresh s Catch all the cricket action. Download Yahoo! Score tracker -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.dudley@REDACTED Sun Jan 12 09:42:00 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Sun, 12 Jan 2003 09:42:00 +0100 Subject: Record selectors References: <009f01c2b287$67808440$18d1b33e@dld2000> <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> Message-ID: <001401c2ba16$7947a320$26d0b33e@dld2000> Thanks for your imput, lads. I think I'll conclude that Erlang's implementation of records is a mess (a wart on Erlang's bottom as Matthias puts it) and thus best avoided. They must be a big embarrassment to Erlang. In fact, I should think it would be a great service to the community if records (in their current form) were phased out as soon as possible. Call it an experiment that went horribly wrong. Chris proposes that country (for example) be a real, unique, opaque type that couldn't be confused with any other type. I couldn't agree more; record is a type that has specific subtypes. This is analogous to objects, which are derived from an abstract base object. Clearly implementable (efficiently and safely) without use of 'orrible syntax. I'm disheartened now, but I do remain hopeful of soon-to-be encouraging changes. Cheers, Daniel From jay@REDACTED Sat Jan 11 23:23:50 2003 From: jay@REDACTED (Jay Nelson) Date: Sat, 11 Jan 2003 14:23:50 -0800 Subject: PDF documentation in protected directory Message-ID: <4.2.2.20030111141824.00d47da0@duomark.com> I tried to download the PDF documentation for OTP 5.2 based on the link in the HTML docs that are part of the distribution. They take me to a page that has a link to the previous versions and a link to R9B in both HTML and PDF. The PDF link points to http://www.erlang.se/doc/doc-5.2/pdf/ but the directory cannot be read. I just noticed that if I go to erlang.org I can get to the documentation via the link http://www.erlang.org/doc/r9b/pdf/index.html but if I try that page on erlang.se it doesn't work either. Now that I found it, I'm set to print the manuals, but thought I'd give someone the heads up on the bad link. jay From vlad_dumitrescu@REDACTED Sun Jan 12 14:14:48 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Sun, 12 Jan 2003 14:14:48 +0100 Subject: Record selectors References: <009f01c2b287$67808440$18d1b33e@dld2000> <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> <001401c2ba16$7947a320$26d0b33e@dld2000> Message-ID: Hi Daniel, Without pretending that I hold the answer to the problem, I think you are a little bit too harsh. If I am not too wrong, implementing a "regular" type system with user-defined types for a dynamically-typed functional language will add in one way or another to the complexity of the syntax. I simply can't come up with an existing language where this is solved elegantly (i.e. without contriving the language) while keeping a reasonable amount of efficiency - if anyone has any examples, please let me know. I think the already expressed opinions about using for example dictionaries instead of today's records are closer to the soul of Erlang. If one would come up with a nice piece of syntactic sugar that would make the implementation transparent to the user, and also allow switching it easily between debug and release builds in order to trade type-safety for speed, then that would be very welcomed. best regards, Vlad From cpressey@REDACTED Sun Jan 12 21:05:25 2003 From: cpressey@REDACTED (Chris Pressey) Date: Sun, 12 Jan 2003 14:05:25 -0600 Subject: Record selectors In-Reply-To: <001401c2ba16$7947a320$26d0b33e@dld2000> References: <009f01c2b287$67808440$18d1b33e@dld2000> <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> <001401c2ba16$7947a320$26d0b33e@dld2000> Message-ID: <20030112140525.0e5183be.cpressey@catseye.mb.ca> On Sun, 12 Jan 2003 09:42:00 +0100 "Daniel Dudley" wrote: > Thanks for your imput, lads. I think I'll conclude that > Erlang's implementation of records is a mess (a wart on > Erlang's bottom as Matthias puts it) and thus best avoided. > They must be a big embarrassment to Erlang. In fact, I > should think it would be a great service to the community > if records (in their current form) were phased out as soon > as possible. Call it an experiment that went horribly wrong. I'm not so sure. Take file:read_file_info/1. If it didn't return a record, it would have to return a plain tuple or list (lower level of organization, easier to make mistakes) or a dictionary or object of some sort (slower - not much slower, but considering that read_file_info is likely to be called in an inner loop, and that Erlang is supposed to be a language for real-time processing, it could be significant). > Chris proposes that country (for example) be a real, > unique, opaque type that couldn't be confused with any > other type. It's actually easy to make opaque values in Erlang (references) but you can't match on them in case statements, at least not in very many useful ways. Ideally I think you'd like to be able to say 'when type_of(X) == country' or something like that. As a workaround, you could say 'T = type_of(X), case ... when T == country', I suppose. > I couldn't agree more; record is a type that > has specific subtypes. This is analogous to objects, which > are derived from an abstract base object. I'm also not sure about that. A record is merely an implementation measure - it's not a supertype in the same way that Animal is a supertype of Mammal. Nothing is really inherited from a record. Sure, you can think of all objects being subclasses of a single Object class at the top of the tree, but that doesn't really give you anything useful in a dynamically-typed language. > Clearly > implementable (efficiently and safely) without use of > 'orrible syntax. Sorry, I'm not sure what you're referring to here. Essentially, you can't increase the safety of records without also reducing their efficiency - unless you turn Erlang into a statically-typed language... > I'm disheartened now, but I do remain hopeful of soon-to-be > encouraging changes. Well, the most likely changes in this regard are probably: a) someone develops a good system for representing objects in Erlang, and it becomes fairly widely adopted. This is essentially how Perl has done it - there's no 'real' support for objects in the language itself, but there is a sanctioned way of representing them. b) someone takes all these ideas and develops a new Erlang-like language without as many blemishes. The design of such a language would probably be straightforward, but its implementation would be a massive undertaking (in which Ericsson wouldn't be expected to have much interest, naturally.) In the meantime, I still think the best bet is to roll your own objects. If, in doing this, you make a consistent system that's simple and efficient and general enough that it fulfills the requirements for a), all the better. One of the better starting points for this I've found is how GS organizes widgets, using gs:config/2 and gs:read/2 to get and set their properties. I've extended this significantly, but in rather specialized and experimental variations which support fancy things like 'active values', and certainly not everyone needs or wants features like that (didn't work out too well what with the incremental error creeping into floats anyway...) It should also be possible to implement subclassing by intercepting the 'this function doesn't exist in this module' error, and trying to call the function of the same name in the module of the parent class. But, I haven't looked into this yet. -Chris From matthias@REDACTED Mon Jan 13 00:36:20 2003 From: matthias@REDACTED (Matthias Lang) Date: Mon, 13 Jan 2003 00:36:20 +0100 Subject: Record selectors In-Reply-To: <001401c2ba16$7947a320$26d0b33e@dld2000> References: <009f01c2b287$67808440$18d1b33e@dld2000> <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> <001401c2ba16$7947a320$26d0b33e@dld2000> Message-ID: <15905.64500.84965.526235@antilipe.corelatus.se> Daniel Dudley writes: > Thanks for your imput, lads. I think I'll conclude that > Erlang's implementation of records is a mess (a wart on > Erlang's bottom as Matthias puts it) and thus best avoided. > They must be a big embarrassment to Erlang. In fact, I > should think it would be a great service to the community > if records (in their current form) were phased out as soon > as possible. Call it an experiment that went horribly wrong. An embarrassment, yes, but not a huge one. Nor has the experiment had horrible effects beyond a bit of ugly code and a few gotchas. If you're out to have fun by trying something new, I'll be so bold as to recommend temporarily accepting the lack of a complex type system and moving on to some of the things which are unique to Erlang. Specifically: the medium-grained & explicit concurrency, a neat message passing model, painless distribution, hot code loading and the 'kill-the-process' approach to handling errors. Distribution and code loading create some interesting problems which make a more ambitious type system rather more interesting than they'd otherwise be. Aside: I was given a copy of the Erlang book and told to "learn it" when I started work for Ericsson in Melbourne a few years ago. I noticed that one of the authors' surnames was "Wikstr?m" and assumed it was the same Wikstr?m behind ML. I soon noticed that Erlang seemed to lack a type system and wondered what on earth had happened to Wikstr?m---what made him go from designing a language with a very nice, strict type system to designing a language where types have very little importance? Eventually, I met the Wikstr?m fellow and discovered that he wasn't the same Wikstr?m of ML fame. But by then I wasn't interested in type systems any longer anyway :-) Matthias From sureshsaragadam@REDACTED Mon Jan 13 06:15:04 2003 From: sureshsaragadam@REDACTED (=?iso-8859-1?q?Suresh=20S?=) Date: Mon, 13 Jan 2003 05:15:04 +0000 (GMT) Subject: To bridge my applicaiton to supervisor module Message-ID: <20030113051504.80018.qmail@web8201.mail.in.yahoo.com> Hi My application does not use any behaviour other than start module (behaves as an applicaiton) and supervisor module, Here i have to make use of Supervisor behaviour ( Supervisor tree ) even though other modules of my applicaiton does not follow any protocol (i.e Any Other behavious or supervision principles ) Here i have to make a release, the release resourse file will check the correctness of my application , So i think the way out is i have to make use of supervisor_bridge, i included a supervisor_bridge module in between supervisor and my own applicaiton which should start my own applicaiton.. Start Module (behaviour Applicaiton) |_Super Module (behaviour supervisor) |_Sup bridge(supervisor_brodge) |_MyApp start |_x.erl |_y.erl start_module.erl - Applicaiton behaviour Super_Module.erl - Supervisor behaviour Sup_Brodge.erl - sup bridge behaviour x.erl - No Behaviour y.erl - No Behaviour z.erl - No behaviour Is this a correct approah, Because i made a boot script , using make_scrit i could generate a boot script successfully , but i failed to start the script i generated This is the error message i had when i am starting my application using the script i generated erl -boot ./entry -boot_var SamApp Dir Kernel pid terminated (application_controller) (shutdown) Thanking u suresh s ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From luke@REDACTED Mon Jan 13 10:59:13 2003 From: luke@REDACTED (Luke Gorrie) Date: Mon, 13 Jan 2003 10:59:13 +0100 (CET) Subject: newer patch to ftp.erl Message-ID: <20030113.105913.71085382.luke@bluetail.com> Here's an update of a previously posted patch to ftp.erl, against inets 2.6.7. The patch is to add incremental (chunked) file downloading. This newer patch fixes a bug in the old one (on incremental download of a non-existent file), and changes an io:format into an error_logger call. Also at http://www.bluetail.com/~luke/misc/erlang/otp_ftp.patch -Luke -------------- next part -------------- --- ftp.erl 2003-01-07 08:15:46.000000000 +0100 +++ /home/luke/misc/ftp.erl 2003-01-13 10:35:01.000000000 +0100 @@ -13,7 +13,7 @@ %% Portions created by Ericsson are Copyright 1999, Ericsson Utvecklings %% AB. All Rights Reserved.'' %% -%% $Id: ftp.erl,v 1.1.1.3 2002/10/08 07:42:22 magnus Exp $ +%% $Id: ftp.erl,v 1.1.2.3 2002/12/05 13:49:15 klacke Exp $ %% -module(ftp). @@ -33,7 +33,7 @@ -export([cd/2, close/1, delete/2, formaterror/1, help/0, lcd/2, lpwd/1, ls/1, ls/2, mkdir/2, nlist/1, nlist/2, open/1, open/2, open/3, pwd/1, recv/2, recv/3, - recv_bin/2, rename/3, rmdir/2, send/2, send/3, + recv_bin/2, recv_chunk/2, rename/3, rmdir/2, send/2, send/3, send_bin/3, send_chunk/2, send_chunk_end/1, send_chunk_start/2, type/2, user/3,user/4,account/2, append/3,append/2,append_bin/3, @@ -233,6 +233,11 @@ recv_bin(Pid, RFile) -> gen_server:call(Pid, {recv_bin, RFile}, infinity). +recv_chunk(Pid, RFile) -> + Ref = make_ref(), + gen_server:cast(Pid, {recv_chunk, self(), Ref, RFile}), + Ref. + %% send(Pid, LFile [, RFile]) %% %% Purpose: Transfer file to remote server. @@ -530,7 +535,7 @@ {error,enotconn}-> ?STOP_RET(econn); Error -> - io:format("~p",[Error]), + error_logger:info_msg("~p",[Error]), {reply, {error, eacct}, State} end; @@ -779,6 +784,22 @@ handle_call(_, _From, State) when State#state.chunk == true -> {reply, {error, echunk}, State}. +handle_cast({recv_chunk, From, Ref, RFile}, State) -> + #state{csock = CSock, ldir = LDir} = State, + LSock = listen_data(CSock, binary), + case ctrl_cmd(CSock, "RETR ~s", [RFile]) of + pos_prel -> + DSock = accept_data(LSock), + Reply = recv_chunk(DSock,CSock,From,Ref), + sock_close(DSock), + {noreply, State}; + {error, enotconn} -> + ?STOP_RET(econn); + Err -> + From ! {ftp, Ref, {finished, {error, epath}}}, + {noreply, State} + end; + handle_cast(Msg, State) -> {noreply, State}. @@ -944,6 +965,42 @@ %% -------------------------------------------------- +%% recv_chunk(DSock, CSock, From, Ref) -> ok +%% Streams data from DSock to the From process with this protocol: +%% From ! {ftp, Ref, {data, Pid, Bin}} +%% From ? {ftp_ack, Ref} +%% ... +%% From ! {ftp, Ref, {finished, Result}} + +recv_chunk(DSock,CSock, From, Ref) -> + Result = recv_chunk1(recv_chunk2(DSock,From,Ref,0),CSock), + From ! {ftp, Ref, {finished, Result}}. + +recv_chunk1(Reply,Sock) -> + case result(Sock) of + pos_compl -> Reply; + _ -> {error, epath} + end. + +recv_chunk2(Sock, From, Ref, ?OPER_TIMEOUT) -> + sock_close(Sock), + {error,eclosed}; +recv_chunk2(Sock, From, Ref, Retry) -> + case sock_read(Sock) of + {ok, Bin} -> + From ! {ftp, Ref, {data, self(), Bin}}, + receive + {ftp_ack, Ref} -> + recv_chunk2(Sock, From, Ref, 0) + end; + {error, timeout} -> + recv_chunk2(Sock, From, Ref, Retry+1); + {closed, _Why} -> + ok + end. + +%% -------------------------------------------------- + %% recv_binary(Sock) = {ok, Bin} %% %recv_binary(Sock) -> From Vlad.Dumitrescu@REDACTED Mon Jan 13 11:03:53 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Mon, 13 Jan 2003 11:03:53 +0100 Subject: Record selectors Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F694@esemont203.gbg.edt.ericsson.se> Hello again, I reviewed this whole thread and found plenty of good ideas about ways to improve the record handling. And also a comprehensive list of possible drawbacks. One important point is that it's probably not an Ericsson priority to fix this. That said and while at it, I think I have found another way to handle this (not entirely original), that might be even compatible with most existing codebase. I'd even would give a try at implementing it, if I wasn't sitting on Windows... Well, picture this: Sicily. 1927. A young fatherless boy decides to... Erm, sorry, that was not it! ;-D Here we go: - one problem today is that records are effectively module local (since they only exist as such at compile-time). One straightforward way to turn them into global types would be to create a module for each record type. [From now on, I will refer to them as "user-defined types" or "utypes"] This module (having the same name as the utype) might have a special flag to it, marking it as a type definition module and will export at least a function like for example: type_info() -> {field1, field2, field3}. Utype instances will look exactly as records do today {record_name, field1, field2, ..} - This module has to be accessible to the compiler, when compiling modules using the utype. [I think a way to mark this use may be necessary - a module attribute?] This removes the need for a global table inside the VM, because the compiler can optimize most utype accesses to "regular" tuple access. This also allows to write Person.name instead of Person#person.name in those cases. Where can we optimize? Where the type can be assessed at compile time - subsequent uses of variable X are "typed" - bla() where record(X, person) -> - X = #person{} - Y = , X = Y - maybe other cases, but you get the idea In the other cases, one either needs to write Person#person.name, or if writing Person.name one accepts that it is syntactic sugar for something like erlang:access_field(Person) that will find record's name (person) and then use person:type_info() at runtime to select the right field. The compiler might warn for this. Matching would work in the same way, most of the times there would not be any penalty. - Implementing utypes as a module also allows for other access ways than direct tuple access. I am not sure though if this wouldn't break compatibility. - Ensuring that all users of an utype use the same version of it is still difficult, but on the other hand the same applies to any module in a system. I hope it was clearly explained. I'd like very much to hear what you think. best regards, Vlad From Sean.Hinde@REDACTED Mon Jan 13 11:30:02 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 13 Jan 2003 10:30:02 -0000 Subject: Record selectors Message-ID: <04D356A3B172D611981B0008C791C3126BF6EE@imp02mbx.t-mobile.co.uk> Hi, All attempts to make records a bit safer are welcome - I have a couple of comments on your suggestion: > - one problem today is that records are effectively > module local (since they only exist as such at compile-time). I have grown very used to using the same record name (locally defined) in lots of different modules - not least in the gen_server where just about every one ever written surely has a #st() or #state{} record. I think that such a scheme as you suggest would need to kep the ability to have totally module private record definitions as well as your global definitions. One further thought - we use the xref tool as part of our build process. This is invaluable in discovering calls to undefined modules in corner cases (try calling error_logger:format("Aargh") ). If xref could be extended to find inconsistencies in use of records across a set of modules maybe that would be sufficient? Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke@REDACTED Mon Jan 13 11:48:07 2003 From: luke@REDACTED (Luke Gorrie) Date: Mon, 13 Jan 2003 11:48:07 +0100 (CET) Subject: Record selectors In-Reply-To: <04D356A3B172D611981B0008C791C3126BF6EE@imp02mbx.t-mobile.co.uk> References: <04D356A3B172D611981B0008C791C3126BF6EE@imp02mbx.t-mobile.co.uk> Message-ID: <20030113.114807.85416923.luke@bluetail.com> Sean Hinde wrote: > One further thought - we use the xref tool as part of our build > process. This is invaluable in discovering calls to undefined > modules in corner cases (try calling error_logger:format("Aargh") > ). If xref could be extended to find inconsistencies in use of > records across a set of modules maybe that would be sufficient? Just tried this in a few dirs in our system with xref:d("lib/foo/ebin"). Within 2 minutes it found a bug (missing -export) that looks like its been hiding for about 2 years :-) Cheers, Luke (printing the xref manual..) From Vlad.Dumitrescu@REDACTED Mon Jan 13 11:51:05 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Mon, 13 Jan 2003 11:51:05 +0100 Subject: Record selectors Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F695@esemont203.gbg.edt.ericsson.se> Hi, > All attempts to make records a bit safer are welcome - I have a couple of comments on your suggestion: >> - one problem today is that records are effectively >> module local (since they only exist as such at compile-time). >I have grown very used to using the same record name (locally defined) in lots of different modules - >not least in the gen_server where just about every one ever written surely has a #st() or #state{} >record. >I think that such a scheme as you suggest would need to kep the ability to have totally module private >record definitions as well as your global definitions. well, what about packages? This is basically what they were designed for! regards, Vlad From Sean.Hinde@REDACTED Mon Jan 13 12:40:27 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 13 Jan 2003 11:40:27 -0000 Subject: Record selectors Message-ID: <04D356A3B172D611981B0008C791C3126BF6F1@imp02mbx.t-mobile.co.uk> > well, what about packages? This is basically what they were > designed for! Well, if I wanted to play the great directory hunt then I'd use Java! Seriously there is a great deal of legacy code (perhaps every system written since the invention of gen_server) which relies on this behaviour so I don't think removing it is an option. I also just thought for a few milliseconds more about my suggestion of using xref, and realised that all knowledge of records is lost pretty early in compilation. This information certainly does not make it into the abstract code stored in beam chunks used by xref and not even through the "All source code transformations" stage - compiler option 'E'. So, it would seem that even to make a simple analysis tool would require the compiler to hold onto the knowledge of record definitions a few more steps into the process (before finally turning accesses into erlang:element/2 calls). Any comments from Compiler writers?? Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Vlad.Dumitrescu@REDACTED Mon Jan 13 12:54:45 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Mon, 13 Jan 2003 12:54:45 +0100 Subject: Record selectors Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F696@esemont203.gbg.edt.ericsson.se> Hi, Well, if I wanted to play the great directory hunt then I'd use Java! Seriously there is a great deal of legacy code (perhaps every system written since the invention of gen_server) which relies on this behaviour so I don't think removing it is an option. True. If the compiler had -record() info available, then this could be fixed by having it check first if there is a -record() included into the file with the current name, then check if there is an utype module present. But since -record()s are a preprocessor thing, it would require more changes... So, it would seem that even to make a simple analysis tool would require the compiler to hold onto the knowledge of record definitions a few more steps into the process (before finally turning accesses into erlang:element/2 calls). Yep, a source code tool is called for... Richard Carlsson's Igor showed pretty neat things that can be done with those. A source code analyzer seems very doable. One caveat is that the result may be dependent of the compilation options (i.e. library dirs and such), and thus such options need to be fed into the analyzer. regards, Vlad From etxuwig@REDACTED Mon Jan 13 13:04:34 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 13 Jan 2003 13:04:34 +0100 (MET) Subject: Record selectors In-Reply-To: <5F03ACA2F76DD411B8BC00508BE3B4D71200F694@esemont203.gbg.edt.ericsson.se> Message-ID: On Mon, 13 Jan 2003, Vlad Dumitrescu (EAW) wrote: >Hello again, > >I reviewed this whole thread and found plenty of good ideas >about ways to improve the record handling. And also a >comprehensive list of possible drawbacks. One important >point is that it's probably not an Ericsson priority to fix >this. Joe Armstrong, who is no longer at Ericsson, once drew an idea about efficient and safe records on my whiteboard. AFAIR, each record would carry its own dictionary which would not be copied -- only referenced -- when the record is updated. I think I also recall concluding that Joe's "records" could be made syntactically compatible with today's records. One would probably still use a new (cleaner) syntax though, esp. since there would be no need to specify the record type in each operation. Perhaps Joe could recap the idea on this list, and perhaps explain what was wrong with it -- since he has not aggressively pushed the idea through? (: /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From bjorn@REDACTED Mon Jan 13 14:03:18 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 13 Jan 2003 14:03:18 +0100 Subject: Record selectors In-Reply-To: Sean Hinde's message of "Mon, 13 Jan 2003 11:40:27 -0000" References: <04D356A3B172D611981B0008C791C3126BF6F1@imp02mbx.t-mobile.co.uk> Message-ID: Sean Hinde writes: > > So, it would seem that even to make a simple analysis tool would require the > compiler to hold onto the knowledge of record definitions a few more steps > into the process (before finally turning accesses into erlang:element/2 > calls). Any comments from Compiler writers?? Changing the compiler would be simplest part. Updating all tools that use the abstract code (the debugger, xref, and cover) would be more work. > > Sean > /Bjorn -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From Sean.Hinde@REDACTED Mon Jan 13 14:16:08 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 13 Jan 2003 13:16:08 -0000 Subject: Record selectors Message-ID: <04D356A3B172D611981B0008C791C3126BF6F6@imp02mbx.t-mobile.co.uk> > > So, it would seem that even to make a simple analysis tool > would require the > > compiler to hold onto the knowledge of record definitions a > few more steps > > into the process (before finally turning accesses into > erlang:element/2 > > calls). Any comments from Compiler writers?? > > Changing the compiler would be simplest part. Updating all tools that > use the abstract code (the debugger, xref, and cover) would > be more work. Well this sounds very positive. I guess you see no issue with the principle of getting xref to do record consistency checking - it is simply a matter of prioritisation and work.. Or am I reading too much into your reply??! Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sean.Hinde@REDACTED Mon Jan 13 15:16:35 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 13 Jan 2003 14:16:35 -0000 Subject: http client problems Message-ID: <04D356A3B172D611981B0008C791C3126BF6F9@imp02mbx.t-mobile.co.uk> Hi, Has anyone had much luck getting the http client included in inets 3.0 working? It seems to work OK in R9B-0 win32 commercial release: 1> http:request_sync(get, {"http://evasdev:8080",[{"Header","Val"}]}). but on UNIX I get: =ERROR REPORT==== 13-Jan-2003::14:16:55 === Error in process <0.55.0> with exit value: {{case_clause,{'EXIT',{function_claus e,[{httpc_handler,headers,[[{"Heade","Val"}]]},{httpc_handler,http_request,2 },{h ttpc_handler,init_connection,2}]}}},[{httpc_handler,init_connection,2}]} ERROR httpc_manager:handle_info {'EXIT', <0.55.0>, {{case_clause, {'EXIT', {function_clause, [{httpc_handler, headers, [[{"Heade","Val"}]]}, {httpc_handler, http_request, 2}, {httpc_handler, init_connection, 2}]}}}, [{httpc_handler,init_connection,2}]}} There appears to be some pretty basic stuff wrong here but before diving in I wondered if I was doing something wrong?? Anyone? Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sean.Hinde@REDACTED Mon Jan 13 15:37:47 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 13 Jan 2003 14:37:47 -0000 Subject: http client problems Message-ID: <04D356A3B172D611981B0008C791C3126BF6FB@imp02mbx.t-mobile.co.uk> OK, It seems that the Ericsson release was missing some changes which are in Johans sowap sourceforge repository - It is still weird that only the windows version got all the correct patches - commercial UNIX and opensource were behind (and still are).. Sean -----Original Message----- From: Sean Hinde [mailto:Sean.Hinde@REDACTED] Sent: 13 January 2003 14:17 To: 'Erlang Questions' Subject: http client problems Hi, Has anyone had much luck getting the http client included in inets 3.0 working? It seems to work OK in R9B-0 win32 commercial release: 1> http:request_sync(get , {" http://evasdev:8080 ",[{"Header","Val"}]}). but on UNIX I get: =ERROR REPORT==== 13-Jan-2003::14:16:55 === Error in process <0.55.0> with exit value: {{case_clause,{'EXIT',{function_claus e,[{httpc_handler,headers,[[{"Heade","Val"}]]},{httpc_handler,http_request,2 },{h ttpc_handler,init_connection,2}]}}},[{httpc_handler,init_connection,2}]} ERROR httpc_manager:handle_info {'EXIT', <0.55.0>, {{case_clause, {'EXIT', {function_clause, [{httpc_handler, headers, [[{"Heade","Val"}]]}, {httpc_handler, http_request, 2}, {httpc_handler, init_connection, 2}]}}}, [{httpc_handler,init_connection,2}]}} There appears to be some pretty basic stuff wrong here but before diving in I wondered if I was doing something wrong?? Anyone? Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe@REDACTED Mon Jan 13 17:06:47 2003 From: joe@REDACTED (Joe Armstrong) Date: Mon, 13 Jan 2003 17:06:47 +0100 (CET) Subject: Record selectors In-Reply-To: Message-ID: I will dig it out and post it tomorrow /Joe On Mon, 13 Jan 2003, Ulf Wiger wrote: > On Mon, 13 Jan 2003, Vlad Dumitrescu (EAW) wrote: > > >Hello again, > > > >I reviewed this whole thread and found plenty of good ideas > >about ways to improve the record handling. And also a > >comprehensive list of possible drawbacks. One important > >point is that it's probably not an Ericsson priority to fix > >this. > > Joe Armstrong, who is no longer at Ericsson, once drew an > idea about efficient and safe records on my whiteboard. > > AFAIR, each record would carry its own dictionary which > would not be copied -- only referenced -- when the record is > updated. I think I also recall concluding that Joe's > "records" could be made syntactically compatible with > today's records. One would probably still use a new > (cleaner) syntax though, esp. since there would be no need > to specify the record type in each operation. > > Perhaps Joe could recap the idea on this list, and perhaps > explain what was wrong with it -- since he has not > aggressively pushed the idea through? (: > > /Uffe > From martin@REDACTED Mon Jan 13 18:56:22 2003 From: martin@REDACTED (martin j logan) Date: 13 Jan 2003 11:56:22 -0600 Subject: Record selectors In-Reply-To: References: <009f01c2b287$67808440$18d1b33e@dld2000> <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> <001401c2ba16$7947a320$26d0b33e@dld2000> Message-ID: <1042480583.1632.51.camel@berimbau> On Sun, 2003-01-12 at 07:14, Vlad Dumitrescu wrote: > Hi Daniel, > > Without pretending that I hold the answer to the problem, I think you are a > little bit too harsh. > > If I am not too wrong, implementing a "regular" type system with > user-defined types for a dynamically-typed functional language will add in > one way or another to the complexity of the syntax. I simply can't come up > with an existing language where this is solved elegantly (i.e. without > contriving the language) while keeping a reasonable amount of efficiency - > if anyone has any examples, please let me know. Phil Wadler tried to implement a type system for erlang. The experiment was discussed at PLI 2002. The proceedings can be obtained from ACM. The experiment was basically determined to be a lesson in what not to do. I think many hope that a coherent type system for erlang will one day be developed. As of today, as far as I know, no such type system has been conceived of. Cheers, Martin > > I think the already expressed opinions about using for example dictionaries > instead of today's records are closer to the soul of Erlang. If one would > come up with a nice piece of syntactic sugar that would make the > implementation transparent to the user, and also allow switching it easily > between debug and release builds in order to trade type-safety for speed, > then that would be very welcomed. > > best regards, > Vlad > From Anders.Fluur@REDACTED Mon Jan 13 19:10:03 2003 From: Anders.Fluur@REDACTED (Anders Fluur (EAB)) Date: Mon, 13 Jan 2003 19:10:03 +0100 Subject: Non-intrusive intercept Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D70AFDE85A@esemont203.gbg.edt.ericsson.se> Hi, I am writing a test application and I would like to verify that the tested application makes a call: module_x:function_y()! Preferrably, this should be performed as a call to my testapplication. How can I do this without modifying the tested application? Best regards, Anders -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.karlsson@REDACTED Mon Jan 13 23:31:19 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Mon, 13 Jan 2003 23:31:19 +0100 Subject: stl and yaws Message-ID: <200301132331.19668.mikael.karlsson@creado.com> I recalled that Mickael Remond mentioned the public contribution STL (Simple Template Language) - http://www.erlang.org/user.html#stl-1.0 by Vladimir Sekissov at his talk EUC2002. STL is described as: >> STL as `Simple Template Language' is a clone of Bruce R. Lewis's BRL (http://brl.sourceforge.net) implemented in Erlang. It deals with template processing and has most capabilities which user expects from web template engines. << I looked at it and thought of using it for Yaws, but at first sight I can not see what the gain would be compared to using Yaws own tags. instead of the (* *) and *) (* delimiters? Greatful for any explanation. Thanks Mikael From hal@REDACTED Tue Jan 14 06:54:51 2003 From: hal@REDACTED (Hal Snyder) Date: Mon, 13 Jan 2003 23:54:51 -0600 Subject: www_tools http client Message-ID: <871y3g9syc.fsf@ghidra.vail> Sean's recent postings on http clients reminded me, there is a nice, small http client in Joe Armstrong's contrib, http://www.erlang.org/user.html#www_tools-1.0 but it doesn't compile with recent releases of OTP. With apologies to Joe, I've posted an updated version of url.erl at ftp://ftp.enteract.com/users/hal/url.erl The new version makes the jump from socket to gen_tcp, so it compiles with R9. Also added are raw_post_url/3 and /4 entries. There is a dependency on the url_parse.erl module from Joe's tarball, but that compiles unmodified. Comments/brickbats welcome. Caveat utilitor. From siri@REDACTED Tue Jan 14 08:54:58 2003 From: siri@REDACTED (Siri Hansen (EAB)) Date: Tue, 14 Jan 2003 08:54:58 +0100 Subject: Non-intrusive intercept In-Reply-To: <5F03ACA2F76DD411B8BC00508BE3B4D70AFDE85A@esemont203.gbg.edt.ericsson.se> References: <5F03ACA2F76DD411B8BC00508BE3B4D70AFDE85A@esemont203.gbg.edt.ericsson.se> Message-ID: <15907.49746.630591.490684@gargle.gargle.HOWL> Hello Anders! You can use tracing. In OTP there are several ways of doing this. Have a look at the runtime_tools and observer(R9) applications. Here is a very simple example using the dbg module in runtime_tools. It produces a printout in the erlang shell when the traced function is called: 6> % start at tracer 6> dbg:tracer(). {ok,<0.37.0>} 7> 7> % set the 'call' trace flag on all processes 7> dbg:p(all,call). {ok,[{matched,nonode@REDACTED,24}]} 8> 8> % set a trace pattern (here []) on the function to trace 8> % First an exported function 8> dbg:tp(m,f,0,[]). {ok,[{matched,nonode@REDACTED,1}]} 9> % then an internal function 9> dbg:tpl(m,internal,0,[]). {ok,[{matched,nonode@REDACTED,0}]} 10> 10> m:f(). (<0.25.0>) call m:f() {3,2,1} (<0.25.0>) call m:internal() 11> 11> % clear all trace patterns 11> dbg:ctp('_'). {ok,[]} 12> % stop trace tool 12> dbg:stop(). ok runtime_tools and observer also provide functions for directing the trace result to e.g. a file instead of the erlang shell. See also the documentation of the trace BIF (Ref man for the erlang module in the kernel application), and match specifications (for setting trace patterns) in the ERTS user guide. Good luck! /siri Anders Fluur (EAB) wrote: > Hi, > > I am writing a test application and I would like to verify that the tested application makes a call: module_x:function_y()! > Preferrably, this should be performed as a call to my testapplication. > How can I do this without modifying the tested application? > > Best regards, > Anders From mickael.remond@REDACTED Tue Jan 14 09:16:13 2003 From: mickael.remond@REDACTED (Mickael Remond) Date: Tue, 14 Jan 2003 09:16:13 +0100 Subject: stl and yaws In-Reply-To: <200301132331.19668.mikael.karlsson@creado.com> References: <200301132331.19668.mikael.karlsson@creado.com> Message-ID: <20030114081612.GB6688@mremond.cgey.capgemini.fr> * Mikael Karlsson [2003-01-13 23:31:19 +0100]: > I recalled that Mickael Remond mentioned the public contribution > STL (Simple Template Language) > - http://www.erlang.org/user.html#stl-1.0 > by Vladimir Sekissov at his talk EUC2002. > STL is described as: > >> > STL as `Simple Template Language' is a clone of Bruce R. Lewis's BRL > (http://brl.sourceforge.net) implemented in Erlang. It deals with template > processing and has most capabilities which user expects from web template > engines. > << > I looked at it and thought of using it for Yaws, but at first sight I can not > see what the gain would be compared to using Yaws own tags. > instead of the (* *) and *) (* delimiters? > > Greatful for any explanation. Thanks In fact, the STL thing allows easy integration of variables (That is to say insertion of dynamic content) easily in different part of the template. In yaws to insert data in the HTML, you have to declare an out/1 function. Moreover, each insertion of dynamic content implies an erl set of tag, with a out function declaration. Each erl zone ends up being compiled as a separate Erlang module. Finally, with Yaws system, I often end up with one erl zone covering the all .yaws file. The main out/1 function is then calling other functions (from the same yaws file or from an Erlang module) to insert HTML templating element (Header/ Footer). BRL is not the perfect templating system, but it avoid this problem. I still think the way to go would be to code a Zope like (ZPT) templating system, each template ending up compile as one module. ZPT allows to define the rendering logic in the template (Variables area, iterations) and refers to core "business application" code for getting the data or triggering the processing writing as Erlang module. I hope this is more clear for you, now. Happy new Erlang year ! -- Micka?l R?mond From joe@REDACTED Tue Jan 14 10:41:44 2003 From: joe@REDACTED (Joe Armstrong) Date: Tue, 14 Jan 2003 10:41:44 +0100 (CET) Subject: Structs (was RE: Record selectors) In-Reply-To: Message-ID: On Mon, 13 Jan 2003, Ulf Wiger wrote: > On Mon, 13 Jan 2003, Vlad Dumitrescu (EAW) wrote: > > >Hello again, > > > >I reviewed this whole thread and found plenty of good ideas > >about ways to improve the record handling. And also a > >comprehensive list of possible drawbacks. One important > >point is that it's probably not an Ericsson priority to fix > >this. > > Joe Armstrong, who is no longer at Ericsson, once drew an > idea about efficient and safe records on my whiteboard. > > AFAIR, each record would carry its own dictionary which > would not be copied -- only referenced -- when the record is > updated. I think I also recall concluding that Joe's > "records" could be made syntactically compatible with > today's records. One would probably still use a new > (cleaner) syntax though, esp. since there would be no need > to specify the record type in each operation. > > Perhaps Joe could recap the idea on this list, and perhaps > explain what was wrong with it -- since he has not > aggressively pushed the idea through? (: There was nothing wrong with the idea. Let me call the thing I like structs (to distinguish them from records). With structs you can write things like: A = ~{name="joe", footSize=42}, %% define a struct A.footSize, %% access a field B = ~A{likes="motorbikes"}, %% add a new field ~{likes=X, name=N} = B} %% pattern match etc. *without* any record defs. Everything is dynamic (which gives it a nice Erlang flavor) and things are consistent between different modules - so no .hrl files are needed. Efficiency would be *jolly good* (TM) if implemented in the VM. --- I have appended a pdf file describing structs as I would like to see them and a test implementation. The test implementation only allows compilation of programs containing structs. I have not changed the evaluator, so you can't use structs in the shell. The implementation in the appended file is inefficient - it just uses a simple parse transform. To do this properly would need a new data type in the virtual machine and a number of changes to the compiler. I will now (for Uffe's sake) "aggressively push the idea". "structs are jolly good - please bring pressure to bear on you local Erlang implementor to implement them" Was that aggressive enough? Possibly if some of the big (paying :-) customers ask OTP to prioritize this then it will happen - a real implementation needs: 1) Compiler changes (Robert says this is easy) 2) Changes to shell erl_eval parser etc. (easy) 3) VM changes (Bj?rn says these are easy) And eventually tool changes (xref) etc. One thing I haven't investigated is the interaction between this and the packages stuff. "." (DOT) is getting pretty overloaded - so ~A.tag might collide with the dot notation used in packages (perhaps Richard could comment on this) /Joe > /Uffe > -------------- next part -------------- A non-text attachment was scrubbed... Name: structs.tgz Type: application/x-gzip Size: 126657 bytes Desc: URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: structs.pdf Type: application/pdf Size: 27090 bytes Desc: URL: From svg@REDACTED Tue Jan 14 11:24:00 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Tue, 14 Jan 2003 15:24:00 +0500 (YEKT) Subject: stl and yaws In-Reply-To: <20030114081612.GB6688@mremond.cgey.capgemini.fr> References: <200301132331.19668.mikael.karlsson@creado.com> <20030114081612.GB6688@mremond.cgey.capgemini.fr> Message-ID: <20030114.152400.41632348.svg@surnet.ru> Good day, I'm now working on Yaws extension for STL. It is finished on 90% and already contains: 1. Continuation-passing style sessions based on modified Ulf Wiger's `mdisp' module. Idea was borrowed from PLT Web-server. 2. Support for Yaws ehtml syntax, so you can use ehtml, html, content, ... yaws expressions directly in templates. Two following expressions produce the same results: ... ,*)
(*, MyVar ,*)
(*, ... ... ,*) {ehtml, {table, [], {tr, [], {td, [], MyVar}} } } (*, ... 3. Exml (xml like ehtml) processor. Not as complex as XSLT but enough for easy transformation things like {user, [{id, 1}, {name, undefined}]} to {ehtml, {form [{action, "myaction"}], [{input, [{type, text}, {name, "id"}, {value, "1"}]}, {input, [{type, text}, {name, "name"}, {value, ""}]} ]} } 4. Utilities - forms validator, phrase dictionary, odbc connection pool. Best Regards, Vladimir Sekissov mickael.remond> * Mikael Karlsson [2003-01-13 23:31:19 +0100]: mickael.remond> mickael.remond> > I recalled that Mickael Remond mentioned the public contribution mickael.remond> > STL (Simple Template Language) mickael.remond> > - http://www.erlang.org/user.html#stl-1.0 mickael.remond> > by Vladimir Sekissov at his talk EUC2002. mickael.remond> > STL is described as: mickael.remond> > >> mickael.remond> > STL as `Simple Template Language' is a clone of Bruce R. Lewis's BRL mickael.remond> > (http://brl.sourceforge.net) implemented in Erlang. It deals with template mickael.remond> > processing and has most capabilities which user expects from web template mickael.remond> > engines. mickael.remond> > << mickael.remond> > I looked at it and thought of using it for Yaws, but at first sight I can not mickael.remond> > see what the gain would be compared to using Yaws own tags. mickael.remond> > instead of the (* *) and *) (* delimiters? mickael.remond> > mickael.remond> > Greatful for any explanation. Thanks mickael.remond> mickael.remond> In fact, the STL thing allows easy integration of variables (That is to mickael.remond> say insertion of dynamic content) easily in different part of the mickael.remond> template. mickael.remond> In yaws to insert data in the HTML, you have to declare an out/1 function. mickael.remond> Moreover, each insertion of dynamic content implies an erl set of tag, mickael.remond> with a out function declaration. Each erl zone ends up being compiled as mickael.remond> a separate Erlang module. mickael.remond> mickael.remond> Finally, with Yaws system, I often end up with one erl zone covering the mickael.remond> all .yaws file. The main out/1 function is then calling other functions mickael.remond> (from the same yaws file or from an Erlang module) to insert HTML mickael.remond> templating element (Header/ Footer). mickael.remond> mickael.remond> BRL is not the perfect templating system, but it avoid this problem. I mickael.remond> still think the way to go would be to code a Zope like (ZPT) templating mickael.remond> system, each template ending up compile as one module. ZPT allows to mickael.remond> define the rendering logic in the template (Variables area, iterations) mickael.remond> and refers to core "business application" code for getting the data or mickael.remond> triggering the processing writing as Erlang module. mickael.remond> mickael.remond> I hope this is more clear for you, now. mickael.remond> mickael.remond> Happy new Erlang year ! mickael.remond> mickael.remond> -- mickael.remond> Micka?l R?mond From Vlad.Dumitrescu@REDACTED Tue Jan 14 12:14:15 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Tue, 14 Jan 2003 12:14:15 +0100 Subject: Structs (was RE: Record selectors) Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6A4@esemont203.gbg.edt.ericsson.se> I have to say: wow Joe, great! This I haven't thought about! I'll throw in some wild ideas that might (if they can be made to work) to alleviate some of the disadvantages of structs and/or to ease the transition from records. * Add a mk_static_struct(Name, Fields) function that will make the struct be implemented just like a record and will disallow the add/delete key features. This could be used when efficiency is more important than flexibility. * Modify the -record() directive to create a static struct instead. This will enable the same kind of consistency between modules as today. Not the best solution, but an acceptable first step, I think. * I still feel that turning somehow a struct/record/utype into a module describing & implementing it, would be a good idea. Or at least not a bad one :-) One reason would be that this would make default values for structs possible by defining a set of keys to be included at creation time. Another reason would be that by using packages, one might solve the problem with the same record name in different hrl files - and discovering one needs to include both in the same module... The possible drawback is efficiency, but if the compiler can optimize most things, then that might not be a big problem. best regards, Vlad From luke@REDACTED Tue Jan 14 12:22:01 2003 From: luke@REDACTED (Luke Gorrie) Date: Tue, 14 Jan 2003 12:22:01 +0100 (CET) Subject: stl and yaws In-Reply-To: <20030114.152400.41632348.svg@surnet.ru> References: <200301132331.19668.mikael.karlsson@creado.com> <20030114081612.GB6688@mremond.cgey.capgemini.fr> <20030114.152400.41632348.svg@surnet.ru> Message-ID: <20030114.122201.126573444.luke@bluetail.com> Vladimir Sekissov wrote: > Good day, > > I'm now working on Yaws extension for STL. It is finished on 90% and > already contains: > > 1. Continuation-passing style sessions based on modified Ulf Wiger's > `mdisp' module. Idea was borrowed from PLT Web-server. This I'm looking forward to :-) For people who haven't seen, the PLT paper is "Programming the Web with High-Level Programming Languages", http://readscheme.org/xml-web/ Their main trick is to make sending a HTML form to the user and receiving the POSTed reply look, from the server program's point of view, just like making a function call. The function can even return multiple times, corresponding to the user going BACK to a previous form and resubmitting it. Super clever! Like the difference between Erlang processes and event-loop programming, but applied to the web. Not that I've actually tried it :-) They do this in Scheme using call/cc. Looking forward to seeing how the mdisp-based approach works! Cheers, Luke From Sean.Hinde@REDACTED Tue Jan 14 12:45:30 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 14 Jan 2003 11:45:30 -0000 Subject: T-Mobile UK is hiring Message-ID: <04D356A3B172D611981B0008C791C3126BF70E@imp02mbx.t-mobile.co.uk> Hi all, We are looking for someone to come and help us develop new SMS, messaging and Web style services. We currently have something like 50 systems running a whole range of Erlang apps, and the requests for new stuff are coming in at the rate of about one new project every two weeks - life is never dull! So if you are interested in coming to join us and have something like the following skills and background: * Several years of solid Erlang experience including OTP. * Ability to make really solid systems in short timescales - with a well diciplined well thought out approach to correctness in a free flowing environment. * Good knowledge of Web development. * Knowledge of GSM, SMS, XML(Ugh!) and doubtless many other TLAs * Plenty of ideas about new services, and the will to see them all the way through to deployement (and use by real customers!) The vacancy is based in the UK just north of London in our new Hatfield offices. CVs, questions, and current details to me please. Regards, Sean Hinde IN Services Design Manager - T-Mobile International (UK) 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svg@REDACTED Tue Jan 14 14:13:53 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Tue, 14 Jan 2003 18:13:53 +0500 (YEKT) Subject: stl and yaws In-Reply-To: <20030114.122201.126573444.luke@bluetail.com> References: <20030114081612.GB6688@mremond.cgey.capgemini.fr> <20030114.152400.41632348.svg@surnet.ru> <20030114.122201.126573444.luke@bluetail.com> Message-ID: <20030114.181353.71090806.svg@surnet.ru> luke> They do this in Scheme using call/cc. Looking forward to seeing how luke> the mdisp-based approach works! Without support for call-with-current-continuation I see only two approaches: 1. syntax transformation (may be I try it somewhere). 2. Continuation style programming as Distel does. Now I use the second one. Every function must return {ok, Result, ContFun, ContArgs} | {ok, Result, die} Best Regards, Vladimir Sekissov luke> Vladimir Sekissov wrote: luke> > Good day, luke> > luke> > I'm now working on Yaws extension for STL. It is finished on 90% and luke> > already contains: luke> > luke> > 1. Continuation-passing style sessions based on modified Ulf Wiger's luke> > `mdisp' module. Idea was borrowed from PLT Web-server. luke> luke> This I'm looking forward to :-) luke> luke> For people who haven't seen, the PLT paper is "Programming the Web luke> with High-Level Programming Languages", http://readscheme.org/xml-web/ luke> luke> Their main trick is to make sending a HTML form to the user and luke> receiving the POSTed reply look, from the server program's point of luke> view, just like making a function call. The function can even return luke> multiple times, corresponding to the user going BACK to a previous luke> form and resubmitting it. Super clever! Like the difference between luke> Erlang processes and event-loop programming, but applied to the web. luke> luke> Not that I've actually tried it :-) luke> luke> They do this in Scheme using call/cc. Looking forward to seeing how luke> the mdisp-based approach works! luke> luke> Cheers, luke> Luke From luke@REDACTED Tue Jan 14 15:25:08 2003 From: luke@REDACTED (Luke Gorrie) Date: Tue, 14 Jan 2003 15:25:08 +0100 (CET) Subject: stl and yaws In-Reply-To: <20030114.181353.71090806.svg@surnet.ru> References: <20030114.152400.41632348.svg@surnet.ru> <20030114.122201.126573444.luke@bluetail.com> <20030114.181353.71090806.svg@surnet.ru> Message-ID: <20030114.152508.29578549.luke@bluetail.com> Vladimir Sekissov wrote: > > luke> They do this in Scheme using call/cc. Looking forward to seeing how > luke> the mdisp-based approach works! > > Without support for call-with-current-continuation I see only two > approaches: > > 1. syntax transformation (may be I try it somewhere). > 2. Continuation style programming as Distel does. > > Now I use the second one. Every function must return > > {ok, Result, ContFun, ContArgs} | {ok, Result, die} Sounds good, since that's basically the same style as e.g. gen_fsm. I guess the idea is to keep all the continuations (states) in the server for a period of time, and give the client some ID that he can post in his forms to say which state he's posting towards? So it would be like regular state machines, except every state you reach is persistent, so you can go "back in time" with the BACK button, and explore parallel universes :-) BTW, the other day I wrote a little server for storing temporary (time-limited) server state like that - attached, incase it's useful. In our application though, we encode pretty much all of our state into fairly meaningful URLs by hand. This is nice since we don't have to remember continuations (they're in the URL / query string), and as a user you can take shortcuts by writing the magic URLs by hand (we smile upon this.) The encoding/decoding of the URLs is fairly ad hoc just now though. Cheers, Luke -------------- next part -------------- %%%---------------------------------------------------------------------- %%% File : portal_servcookie.erl %%% Author : Luke Gorrie %%% Purpose : Server for temporary "server cookies" -- time-limited %%% key/value pairs. %%% Created : 10 Jan 2003 by Luke Gorrie %%%---------------------------------------------------------------------- %% This server has two ets tables: "new" and "old." Both contain %% {{Session, Key}, Value} tuples of temporary key/value associations %% belonging to portal user sessions. %% %% The "old" table is periodically cleared and swapped with the "new" %% table. -module(portal_servcookie). -author('luke@REDACTED'). %%-compile(export_all). %%-export([Function/Arity, ...]). -behaviour(gen_server). %% External exports -export([start_link/0, set_value/2, get_value/2]). %% gen_server callbacks -export([init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3]). -record(state, {new, old, counter=0}). %% By default, swap new/old tables every 2 minutes, giving each entry %% a lifetime of between 2 and 4 mintues. -define(DEFAULT_INTERVAL, 120000). %%%---------------------------------------------------------------------- %%% API %%%---------------------------------------------------------------------- start_link() -> start_link(?DEFAULT_INTERVAL). start_link(Interval) -> gen_server:start_link({local, portal_servcookie}, portal_servcookie, Interval, []). %% Set a value in the session and return a "cookie". The value can be %% read back using the cookie with get_value/2, but will time-out and %% disappear after a few minutes. %% %% Returns: Cookie = integer(), cookie to read the value back with. set_value(Session, Value) -> gen_server:call(?MODULE, {set_value, Session, Value}). %% Read a previously set value, if it still exists. %% %% Returns: {ok, Value} | not_found get_value(Session, Cookie) -> gen_server:call(?MODULE, {get_value, Session, Cookie}). %%%---------------------------------------------------------------------- %%% Callback functions from gen_server %%%---------------------------------------------------------------------- init(Interval) -> timer:send_interval(Interval, time_to_swap), %% Tables are only named for debugging purposes. {ok, #state{new=ets:new(portal_servercookie_a, [set, public, named_table]), old=ets:new(portal_servercookie_b, [set, public, named_table])}}. handle_call({set_value, Session, Value}, From, State) -> Key = State#state.counter, ets:insert(State#state.new, {{Session, Key}, Value}), {reply, Key, State#state{counter=Key+1}}; handle_call({get_value, Session, Key}, From, State=#state{new=New, old=Old}) -> Reply = case lookup(New, Session, Key) of {ok, Value} -> {ok, Value}; not_found -> lookup(Old, Session, Key) end, {reply, Reply, State}. handle_cast(Msg, State) -> {noreply, State}. %% Handle periodic swap. handle_info(time_to_swap, State = #state{new=New, old=Old}) -> ets:delete_all_objects(Old), ets:insert(New, {status, old}), ets:insert(Old, {status, new}), %% Wrap counter after ten million entries, just to keep it from %% growing indefinitely. "defensive programming" Counter = if State#state.counter > 10000000 -> 0; true -> State#state.counter end, {noreply, #state{new=Old, old=New, counter=Counter}}; handle_info(Info, State) -> {noreply, State}. terminate(Reason, State) -> ok. code_change(OldVsn, State, Extra) -> {ok, State}. %%%---------------------------------------------------------------------- %%% Internal functions %%%---------------------------------------------------------------------- lookup(Table, Session, Key) -> case ets:lookup(Table, {Session, Key}) of [{_, Value}] -> {ok, Value}; [] -> not_found end. From jeinhorn@REDACTED Tue Jan 14 16:44:45 2003 From: jeinhorn@REDACTED (Jeff Einhorn) Date: Tue, 14 Jan 2003 09:44:45 -0600 Subject: Packaging an application. Message-ID: I've been trying to create a simple application following the example Scott Lystig Fritchie posted to the mailing list(http://www.erlang.org/ml-archive/erlang-questions/200001/msg00037.html) , but I'm having some trouble. Here is my directory structure. simpleapp/ simpleapp/ebin/simpleapp.app simpleapp/src/simpleapp.erl simpleapp/src/simpleapp.beam simpleapp/src/simpleapp.rel Contents of simpleapp.app. {application, simpleapp, [ {description, "A Simple App Test"}, {vsn, "0.01"}, {id, "Simple Id1"}, {modules, [simpleapp]}, {registered, [simpleapp] }, %% NOTE: It seems as if you don't want to list below libraries %% that are load-only. This is only a list of applications that must %% be started before this application is started. In the case of %% increment, we'll be starting it ourselves. {applications, [ kernel, stdlib ] }, %% This is the statement that triggers the loading process to call %% the start function (and arguments) for the application. {mod, {simpleapp, []} } ] }. Contents of simpleapp.rel. {release, {"simpleapp", "0.01"}, {erts, "5.2"}, [{kernel, "2.8.0"}, {stdlib, "1.11.0"}, {simpleapp, "0.01"}]}. When I try and run the following command I get an error, which seems to idicate it is not able to find my simpleapp file. I run the following from the src directory. $erl -pa ../ebin -s systools make_script simpleapp -s erlang halt -noshell {{module_not_found,simpleapp,simpleapp}, {simpleapp,'$$ignore$$',simpleapp,"0.01","../ebin"}} thank you for your time, -jeff e From francesco@REDACTED Tue Jan 14 18:17:59 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 14 Jan 2003 17:17:59 +0000 Subject: The Need for Erlang Courses World-Wide? Message-ID: <3E244647.6040604@erlang-consulting.com> In recent months, I have noticed an increase in the request for Erlang training by individuals rather than requests for whole courses. Lennart Ohman, at Sj?land and Thyselius, has noticed the same trend. We were debating on if we should start offering scheduled Erlang courses again, and if so, where to place them. Do you see a need for them in your project / organization? Do you think you will be sending participants to them. Where should they be placed? What courses would you be interested in? Are the one day seminars we offer also of interest? We had in mind to offer one to two Introductory courses a year in Stockholm (In conjunction with EUC?) London, US (Where? East/West coast? Both?) and possibly one in Asia (Singapore?) or Australia (Melbourne?). Based on these courses (We would require a minimum number of participants for them to go ahead), we would then schedule the follow up OTP courses a couple of months later. All comments and suggestions are appreciated. If you could send general comments and discussions to the list, but express suggestions on locations and times you would like to see these courses scheduled alongside any interest directly to us. We will post a summary here. Regards, Francesco -- http://www.erlang-consulting.com From mikael.karlsson@REDACTED Tue Jan 14 20:48:41 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Tue, 14 Jan 2003 20:48:41 +0100 Subject: stl and yaws In-Reply-To: <20030114081612.GB6688@mremond.cgey.capgemini.fr> References: <200301132331.19668.mikael.karlsson@creado.com> <20030114081612.GB6688@mremond.cgey.capgemini.fr> Message-ID: <200301142048.41196.mikael.karlsson@creado.com> Thanks for the explanations Mickael et.al. It is quite clear now :-) I look forward for the release of STL for Yaws. Mikael tisdag 14 januari 2003 09:16 skrev Mickael Remond: > In fact, the STL thing allows easy integration of variables (That is to > say insertion of dynamic content) easily in different part of the > template. > In yaws to insert data in the HTML, you have to declare an out/1 function. > Moreover, each insertion of dynamic content implies an erl set of tag, > with a out function declaration. Each erl zone ends up being compiled as > a separate Erlang module. > > Finally, with Yaws system, I often end up with one erl zone covering the > all .yaws file. The main out/1 function is then calling other functions > (from the same yaws file or from an Erlang module) to insert HTML > templating element (Header/ Footer). > > BRL is not the perfect templating system, but it avoid this problem. I > still think the way to go would be to code a Zope like (ZPT) templating > system, each template ending up compile as one module. ZPT allows to > define the rendering logic in the template (Variables area, iterations) > and refers to core "business application" code for getting the data or > triggering the processing writing as Erlang module. > > I hope this is more clear for you, now. > > Happy new Erlang year ! > -- > Micka?l R?mond From spearce@REDACTED Tue Jan 14 22:46:03 2003 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 14 Jan 2003 16:46:03 -0500 Subject: www_tools http client In-Reply-To: <871y3g9syc.fsf@ghidra.vail> References: <871y3g9syc.fsf@ghidra.vail> Message-ID: <20030114214603.GB4593@spearce.org> This couldn't have been more timely for me. I was opening my email to write a gen_tcp question, as I was trying to port this to use gen_tcp rather than socket. Thanks Hal. My problem is now that I'm trying to make this thing use non-active sockets, so I can passively poll for TCP data rather than get it via messages. My intended application is in a load testing tool where I may be getting back a few hundred KB of data per process, and having a few hundred processes running. I'm wondering if I can get away with active sockets, or have to use passive. The process won't do anything once the HTTP request is sent off other than receive data. Right now I'm getting from gen_tcp:recv {error,enotsock} rather than {error, closed} as the docs state, when I connect the socket with {active, false}. Here's what I changed in Hal's url.erl: 114c114 < case catch gen_tcp:connect(IP, Port, [binary, {packet, 0}]) of --- > case catch gen_tcp:connect(IP, Port, [binary, {packet, 0}, {active, false} ]) of 129,130c129,130 < receive < {tcp,Socket,B} -> --- > case gen_tcp:recv(Socket, 0) of > {ok,B} -> 139,143c139,141 < {error, {tcp_error, Reason}} < after < Timeout -> < gen_tcp:close(Socket), < {error, timeout} --- > {error, {tcp_error, Reason}}; > Other -> > io:format("What the? ~p~n", [Other]) Its printing: 42> url:raw_get_url("http://xenon:80/",6000). Socket = #Port<0.119> What the? {error,enotsock} ok 43> Huh? Why is gen_tcp:recv/2 giving me {error,enotsock} rather than {error, closed} as the docs state? I get {ok, B} for the data packet, but that's it. This is R9B-0. Hal Snyder wrote: > Sean's recent postings on http clients reminded me, there is a nice, > small http client in Joe Armstrong's contrib, > > http://www.erlang.org/user.html#www_tools-1.0 > > but it doesn't compile with recent releases of OTP. With apologies to > Joe, I've posted an updated version of url.erl at > > ftp://ftp.enteract.com/users/hal/url.erl > > The new version makes the jump from socket to gen_tcp, so it compiles > with R9. Also added are raw_post_url/3 and /4 entries. > > There is a dependency on the url_parse.erl module from Joe's tarball, > but that compiles unmodified. > > Comments/brickbats welcome. Caveat utilitor. -- Shawn. From spearce@REDACTED Tue Jan 14 22:53:04 2003 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 14 Jan 2003 16:53:04 -0500 Subject: www_tools http client In-Reply-To: <871y3g9syc.fsf@ghidra.vail> References: <871y3g9syc.fsf@ghidra.vail> Message-ID: <20030114215304.GC4593@spearce.org> Ok, new info: I was calling it with: url:raw_get_url("http://xenon:80)/", 6000). This was giving me a problem as IIS (the webserver at xenon, port 80) was responding with "400 Bad Request". Turns out the request line looked like: Cmd=["GET ",[]," HTTP/1.0\r\n\r\n"] bug in the URL parser? So I tried: 49> url:raw_get_url("http://xenon:80/index",6000). Cmd=["GET ","index"," HTTP/1.0\r\n\r\n"] url_server: fetching "xenon" 80 "index" Which is also illegal, as "index" is missing the leading /. Turns out this works: 50> url:raw_get_url("http://xenon:80//index",6000). Cmd=["GET ","/index"," HTTP/1.0\r\n\r\n"] url_server: fetching "xenon" 80 "/index" Socket = #Port<0.130> What the? {error,closed} And gen_tcp provides the closed message, I just didn't handle it. So somehow IIS is killing the socket on me and as a result is making Erts think the socket is no longer a socket, and therefore we can't close it... odd.. -- Shawn. From Sean.Hinde@REDACTED Tue Jan 14 22:56:31 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 14 Jan 2003 21:56:31 -0000 Subject: Structs (was RE: Record selectors) Message-ID: <04D356A3B172D611981B0008C791C3126BF71A@imp02mbx.t-mobile.co.uk> > With structs you can write things like: > > A = ~{name="joe", footSize=42}, %% define a struct > A.footSize, %% access a field > B = ~A{likes="motorbikes"}, %% add a new field > ~{likes=X, name=N} = B} %% pattern match etc. > > *without* any record defs. > > Everything is dynamic (which gives it a nice Erlang flavor) and > things are consistent between different modules - so no .hrl files are > needed. Efficiency would be *jolly good* (TM) if implemented in the > VM. We have been thinking about the strengths and weaknesses of structs and how we might have written some of our recent systems using them. A number of our recent systems seem to follow a pattern of: - Decode input data into some tagged tuple format (e.g. HTTP Header, Billing Record) - Convert this into a record for lots of nice random access and processing. - Make a tagged tuple list from the relevant parts of the record. - Send this to another process - Other process converts it into a record of a new type for random access - Other process makes some wierd output packet structure using named record fields. I guess this is driven by the need for nice named random access for the processing parts of the application but flexible and extensible tagged tuple lists for communicating between different parts of the app - no need for global .hrl files amd the headaches they bring. For this application structs would appear to be a magic bullet - they are extensible and also random access. Some concerns would be: a) A typo in the name of a single field would be a fairly hard to find bug - unwittingly creating a new field rather than just updating an existing one would be hard to see. b) The absense of default values would make explicit initialisation of many structs mandatory - lots more typing for little gain and potential for more unchecked and hard to find field naming errors. c) It would be very easy to make fairly unreadable code where the same struct name was used many times in the same module to refer to totally different structs. d) We concluded we probably wouldn't use anonymous structs over simple tagged tuples - the possibility for error in field naming and the potential confusion from using the same field names for different instances of a struct (which one is this one again ??) probably outweigh the advantages. One nice benefit would be that it would be very easy to check that input data had the correct number of entries - at the moment validating that the following type of code has filled in all entries in the record needs an extra longwinded trawl through all fields: parse(Vals) -> parse(Vals, #person{}). parse([{name, Name}|T], Rec) -> parse(T, Rec#person{name = Name}); parse([{job, Job}|T], Rec) -> parse(T, Rec#person{job = Job}); parse([], Rec) -> Rec. with structs it would be sufficient to check the number of fields created. I think that named structs with the addition of optional static definitions would be an excellent addition to Erlang. (The definitions would have no effect at runtime but would provide a very useful crutch for those of us with weak typing skills.) I would also still like to see xref style support for checking cross module record definitions - and why not global struct definitions as well.. Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Tue Jan 14 23:23:06 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Tue, 14 Jan 2003 19:23:06 -0300 Subject: Packaging an application. References: Message-ID: <001201c2bc1b$8400d0a0$1400a8c0@tdapi> Jeff, You have to move the file "simpleapp.beam" from "simpleapp/src" to "simpleapp/ebin" ----- Original Message ----- From: "Jeff Einhorn" To: "Erlang-Questions" Cc: "Jeff Einhorn" Sent: Tuesday, January 14, 2003 12:44 PM Subject: Packaging an application. > I've been trying to create a simple application following the example Scott > Lystig Fritchie posted to the mailing > list(http://www.erlang.org/ml-archive/erlang-questions/200001/msg00037.html) > , but I'm having some trouble. > > Here is my directory structure. > simpleapp/ > simpleapp/ebin/simpleapp.app > simpleapp/src/simpleapp.erl > simpleapp/src/simpleapp.beam > simpleapp/src/simpleapp.rel > > Contents of simpleapp.app. > {application, simpleapp, > [ > {description, "A Simple App Test"}, > {vsn, "0.01"}, > {id, "Simple Id1"}, > {modules, [simpleapp]}, > {registered, [simpleapp] }, > %% NOTE: It seems as if you don't want to list below libraries > %% that are load-only. This is only a list of applications that > must > %% be started before this application is started. In the case of > %% increment, we'll be starting it ourselves. > {applications, [ kernel, stdlib ] }, > > %% This is the statement that triggers the loading process to call > %% the start function (and arguments) for the application. > {mod, {simpleapp, []} } > ] > }. > > Contents of simpleapp.rel. > {release, {"simpleapp", "0.01"}, {erts, "5.2"}, > [{kernel, "2.8.0"}, > {stdlib, "1.11.0"}, > {simpleapp, "0.01"}]}. > > When I try and run the following command I get an error, which seems to > idicate it is not able to find my simpleapp file. I run the following from > the src directory. > $erl -pa ../ebin -s systools make_script simpleapp -s erlang halt -noshell > > {{module_not_found,simpleapp,simpleapp}, > {simpleapp,'$$ignore$$',simpleapp,"0.01","../ebin"}} > > thank you for your time, > -jeff e > > From cpressey@REDACTED Wed Jan 15 02:31:45 2003 From: cpressey@REDACTED (Chris Pressey) Date: Tue, 14 Jan 2003 19:31:45 -0600 Subject: Structs (was RE: Record selectors) In-Reply-To: References: Message-ID: <20030114193145.46178fb6.cpressey@catseye.mb.ca> On Tue, 14 Jan 2003 10:41:44 +0100 (CET) Joe Armstrong wrote: > [...] > With structs you can write things like: > > A = ~{name="joe", footSize=42}, %% define a struct > A.footSize, %% access a field > B = ~A{likes="motorbikes"}, %% add a new field > ~{likes=X, name=N} = B} %% pattern match etc. > > *without* any record defs. Hm, OK, I've read the paper, let me see if I've got this straight. Structs are basically dictionaries a la the dict module, except: 1) you can pattern-match on their contents 2) they have their own special syntactic sugar 3) they're implemented directly in the VM for performance Well, #1 is a great advantage over dicts, of course. #2 is a mixed blessing - A.footSize is easier to read and to type out than dict:fetch(A, footSize), but it's also rather unorthogonal, symbolspace is getting more and more crowded, "~" is easy to confuse with "-" in many fonts, plus I personally think tildes are kind of ugly :) #3 is arbitrary (there's no reason dicts or any other data type couldn't be implemented in the VM too.) Also, since it's one of the considerations that sparked this thread, it's worth noting that structs are in no way safer that records; in fact, they're so flexible that they're arguably less safe. Records have rigid structure, while structs, like dicts, are just random bags of data. So, I don't want to sound too negative, but honestly, I'm less than thrilled by the idea. But, that's possibly because the world I live and program in puts an emphasis on validation. I still think you can get more "bang for your buck" with "objects" - if you write a module for each data type you use, you have full control over the interface, you can screen out bad data before it gets into the aggregate, you can use whatever storage scheme you like (and change it at a later date,) you have a convenient place to group all the applicable functions, etc etc, at a base cost surely not *too* much greater than using structs... Forgive me, but is Erlang really so object-shy that encapsulation is something that we feel we can afford to avoid simply because "they" have turned it into a meaningless buzzword? -Chris From matthias@REDACTED Wed Jan 15 09:05:39 2003 From: matthias@REDACTED (Matthias Lang) Date: Wed, 15 Jan 2003 09:05:39 +0100 Subject: Structs (was RE: Record selectors) In-Reply-To: <20030114193145.46178fb6.cpressey@catseye.mb.ca> References: <20030114193145.46178fb6.cpressey@catseye.mb.ca> Message-ID: <15909.5715.795358.380448@antilipe.corelatus.se> Chris Pressey writes: > Forgive me, but is Erlang really so object-shy that encapsulation is > something that we feel we can afford to avoid simply because "they" have > turned it into a meaningless buzzword? If you have a language feature and call it an "object", then a large number of people are going to be vocally disappointed that these "objects" don't have member functions, inheritance, access control and... What is an object? Asking google, I get An object has state, behavior, and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable This is what Booch says. Does behaviour mean "functions with side effects"? What does Rumbaugh have to say? We define an object as a concept, abstraction or thing with crisp boundaries and meaning for the problem at hand. Pretty vague, despite the wishful inclusion of "crisp". 'Object' is a word to avoid. Now, if only I could invent a record replacement I could give it a new and cool name, like "mutable coagulator". Matthias From sam@REDACTED Tue Jan 14 17:45:19 2003 From: sam@REDACTED (Samuel Tardieu) Date: Tue, 14 Jan 2003 17:45:19 +0100 Subject: Packaging an application. References: Message-ID: <87wul7d6jk.fsf@inf.enst.fr> You should put your beam files in your ebin directory, not src. Sam -- Samuel Tardieu -- sam@REDACTED -- http://www.rfc1149.net/sam From Vlad.Dumitrescu@REDACTED Wed Jan 15 09:18:38 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Wed, 15 Jan 2003 09:18:38 +0100 Subject: Structs (was RE: Record selectors) Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6AB@esemont203.gbg.edt.ericsson.se> Hi Chris, >Forgive me, but is Erlang really so object-shy that encapsulation is >something that we feel we can afford to avoid simply because "they" have >turned it into a meaningless buzzword? I am by no means an Erlang guru, but I was once for not so long ago just as puzzled by the same question. Now I got used to the "hard core" Erlang way and it works just as well. To make sure we are referring to the same thing: encapsulation is one issue, having support from the compiler & run-time for a nice syntax and better efficiency is another. In fact, in Erlang one can use encapsulation on two levels: by writing wrapper functions and by using a server process. One can also use both (even if I remember someone arguing that it is better to write "Pid ! Msg" than encapsulate it in a function call, because the former does not hide that there is a process doing the work). The latter issue is at stake, together with the expressed need to have some kind of type checking. If there is a way to get the best of both worlds without paying too much for it, then it will be found and implemented. As for objects, I think processes can implement the underlying concept better than for example C++ objects. Hey, one could even think of compiling today's records (or tomorrow's mutable coagulators :-) into processes! The big minus is efficiency, but the coolness factor might be bigger :-) best regards, Vlad From hakan@REDACTED Wed Jan 15 10:02:43 2003 From: hakan@REDACTED (Hakan Mattsson) Date: Wed, 15 Jan 2003 10:02:43 +0100 (MET) Subject: www_tools http client In-Reply-To: <20030114214603.GB4593@spearce.org> Message-ID: On Tue, 14 Jan 2003, Shawn Pearce wrote: Shawn> My problem is now that I'm trying to make this thing use non-active Shawn> sockets, so I can passively poll for TCP data rather than get it via Shawn> messages. Shawn> Shawn> My intended application is in a load testing tool where I may be Shawn> getting back a few hundred KB of data per process, and having a few Shawn> hundred processes running. I'm wondering if I can get away with active Shawn> sockets, or have to use passive. The process won't do anything once Shawn> the HTTP request is sent off other than receive data. You could also consider using {active, once} as it gives you the benefits of both {active, true} and {active, false}. The usage is like active sockets without loosing the congestion control in TCP/IP. /H?kan --- H?kan Mattsson Ericsson High Availability Software, DBMS Internals http://www.ericsson.com/cslab/~hakan/ From etxuwig@REDACTED Wed Jan 15 10:21:00 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 15 Jan 2003 10:21:00 +0100 (MET) Subject: Structs (was RE: Record selectors) In-Reply-To: Message-ID: On Tue, 14 Jan 2003, Joe Armstrong wrote: >Let me call the thing I like structs (to distinguish them >from records). > > With structs you can write things like: > > A = ~{name="joe", footSize=42}, %% define a struct > A.footSize, %% access a field > B = ~A{likes="motorbikes"}, %% add a new field I'm wary about the ease of which one can add a new field. It has a feel of BASIC over it (mistyping a variable name creates a new variable.) Erlang's dynamic typing of variables is still reasonably safe from typos due to single assignment (if you mis-type a variable name and then refer to that variable without the typo, the compiler will complain.) Personally, I would prefer it if fields could only be added using an add_field/2 function. I think it's an uncommon operation. Most of the time, assigning a value to a non-existing field is probably an error. The issue of default values could be addressed for named structs using the pre-processor: -struct(guru, {name = "joe", footSize = 42, likes = "motorbikes"}). Then, one could create a named struct just like a new record: C = ~guru{name = "robert", likes="water rockets"}. But this would of course not solve the compile-time dependencies that now plague records. On the other hand, if one writes a module that is the "home" of a struct, and makes sure to instantiate a struct using a dedicated function, the issue of defaults is not a big one: -module(mystructs). -export([new/1]). new(guru) -> ~guru{name, footSize, likes}. ...introducing some syntactic sugar that allows us to avoid having to type "= undefined" for all fields that should have a default value. D = (mystructs:new(guru))~{name="klacke", likes="whitewater rafting"} This would also perhaps make it possible to introduce real handling of undefined fields: erlang:is_nil(D.footSize) -> true | false. (where accessing a non-initialized field is an error. I'm not totally convinced that this is a good idea, but then again, we could stick to the heretic practice of using the legal value 'undefined') Anonymous structs could perhaps be kept super-dynamic. I don't know if this would complicate the implementation or compromise efficiency. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From joe@REDACTED Wed Jan 15 10:39:07 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 15 Jan 2003 10:39:07 +0100 (CET) Subject: Structs (was RE: Record selectors) In-Reply-To: <20030114193145.46178fb6.cpressey@catseye.mb.ca> Message-ID: > Joe Armstrong wrote: > > > [...] > > With structs you can write things like: > > > > A = ~{name="joe", footSize=42}, %% define a struct > > A.footSize, %% access a field > > B = ~A{likes="motorbikes"}, %% add a new field > > ~{likes=X, name=N} = B} %% pattern match etc. > > > > *without* any record defs. > > Hm, OK, I've read the paper, let me see if I've got this straight. > > Structs are basically dictionaries a la the dict module, except: > > 1) you can pattern-match on their contents > 2) they have their own special syntactic sugar > 3) they're implemented directly in the VM for performance > > Well, #1 is a great advantage over dicts, of course. > > #2 is a mixed blessing - A.footSize is easier to read and to type out than > dict:fetch(A, footSize), but it's also rather unorthogonal, symbolspace > is getting more and more crowded, "~" is easy to confuse with "-" in many > fonts, plus I personally think tildes are kind of ugly :) > The problem is more due to the dot than the tilde :-) . means - end of a function or attribute - the separator in a floating point number - separator in a structured module name - record separator That's why you need a tilde or hash to help the parser (and the human) ~ means here comes a struct # means here comes a record > #3 is arbitrary (there's no reason dicts or any other data type couldn't > be implemented in the VM too.) > It's not really *arbitrary* - this is one of the most tricky design decisions there is. The choices of what you do in compact syntax and what you do efficiently in the VM are crucial. The "send" operation is written A ! B And compiles down to a single Op code in the VM - also a great deal of effort has gone into the implementation of send. This is not an arbitrary decision but something that is at the very heart of language design. If the user had to write. send_message(A, B) And if the *implementation* of send was slow - then Erlang would be useless as a concurrent PL. Language design *is* (in a sense) choosing which operations should be expressed by succinct syntax and efficiently implemented. > Also, since it's one of the considerations that sparked this thread, it's > worth noting that structs are in no way safer that records; in fact, > they're so flexible that they're arguably less safe. Records have > rigid structure, while structs, like dicts, are just random bags of data. Yes - but structs do fit nicely with the rest of the language. Records do not have the Erlang "feel" - they are too rigid for my liking - and the mess with include files is very non-Erlang. You will introduce new errors by typos in struct member names, but this is no worse than mis-spelling an atom in any other context, and while mis-spelt atom names *is* a problem it is not a *big* problem. I routinely run all my code through "coverage" - and this picks up virtually all errors due to mis-spelt atom names. > So, I don't want to sound too negative, but honestly, I'm less than > thrilled by the idea. > > But, that's possibly because the world I live and program in puts an > emphasis on validation. I still think you can get more "bang for your > buck" with "objects" - if you write a module for each data type you use, > you have full control over the interface, you can screen out bad data > before it gets into the aggregate, you can use whatever storage scheme you > like (and change it at a later date,) you have a convenient place to group > all the applicable functions, etc etc, at a base cost surely not *too* > much greater than using structs... My view is that data validation *only* occurs at a human -> computer interface and at a boundary where two components communicate via. a protocol and where the components are not trusted. For this something like my UBF system http://www.sics.se/~joe/ubf seems to be a step in the right direction. UBF + timing + (other non functional stuff) + invariants would seem to be the right way to go. Basically you validate data (as hard you can) when it enters the system. Thereafter, and internally there should be no validation - just let things crash and design the error recovery through the application of carefully chosen invariants. > > Forgive me, but is Erlang really so object-shy that encapsulation is > something that we feel we can afford to avoid simply because "they" have > turned it into a meaningless buzzword? > No encapsulation is fine - but objects (as in OO languages) do a lot more than just encapsulate things. /Joe > -Chris > From martin-g@REDACTED Wed Jan 15 10:34:12 2003 From: martin-g@REDACTED (Martin Gustafsson) Date: Wed, 15 Jan 2003 10:34:12 +0100 Subject: Win 2k Message-ID: <1042623252.50ecae20martin-g@home.se> Hello! One of our customers has a project where Erlang would be the perfect tool and maybe I have persuaded them to use it:-) But they want the application to run on a Win 2k machine. Has anyone tested Erlang on Win 2k? Is it working or is it possible to get it to work? Best regards Martin From kent@REDACTED Wed Jan 15 10:56:17 2003 From: kent@REDACTED (Kent Boortz) Date: 15 Jan 2003 10:56:17 +0100 Subject: Win 2k In-Reply-To: <1042623252.50ecae20martin-g@home.se> References: <1042623252.50ecae20martin-g@home.se> Message-ID: "Martin Gustafsson" writes: > One of our customers has a project where Erlang would be the perfect > tool and maybe I have persuaded them to use it:-) But they want the > application to run on a Win 2k machine. Has anyone tested Erlang on > Win 2k? Is it working or is it possible to get it to work? The graphical development tools don't work correctly on some (all?) Windows platforms, this will be corrected in the next OpenSource release R9B-1. kent From joe@REDACTED Wed Jan 15 11:01:25 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 15 Jan 2003 11:01:25 +0100 (CET) Subject: Structs (was RE: Record selectors) In-Reply-To: Message-ID: On Wed, 15 Jan 2003, Ulf Wiger wrote: > > -struct(guru, {name = "joe", > footSize = 42, > likes = "motorbikes"}). > > Then, one could create a named struct just like a new > record: > > C = ~guru{name = "robert", likes="water rockets"}. > > But this would of course not solve the compile-time > dependencies that now plague records. > > > On the other hand, if one writes a module that is the "home" > of a struct, and makes sure to instantiate a struct using a > dedicated function, the issue of defaults is not a big one: > > -module(mystructs). > -export([new/1]). > > new(guru) -> > ~guru{name, footSize, likes}. > > ...introducing some syntactic sugar that allows us to avoid > having to type "= undefined" for all fields that should have > a default value. > > D = (mystructs:new(guru))~{name="klacke", > likes="whitewater rafting"} > Brilliant ... (this is (essentially) what Robert and I came up with a while ago, and I'd forgotten) - can I change the syntax a bit: In the module that defines the struct -module(xx) -export_structs([guru]). -struct(guru, {name = "uffe", likes = "opera"}). C = ~guru{name = "robert", likes="water rockets"}. In an external module -module(yy). -import_struct(xx, [guru]). C = ~guru{name="jim"} % if guru is imported D = ~yy:anotherStruct{env="abc", count=0} In this scheme the tag checking is done at run-time *not* compile time and structs are represented as in my paper. If you want more control you could add guards to the structs -struct1(foo, {on_create, fun(X) -> check_it(X) end}, {on_set, [{name, fun(I) -> check_name(I) end}, {likes, fun(J) -> check_likes(I) end}} ). Then every time you call ~foo{name="joe", links="aaaa"} check_name("joe") would be called, then check_likes("aaaa") would be called, then check_it(~foo{name="joe", linkes="aaaa"}) would be called > This would also perhaps make it possible to introduce real > handling of undefined fields: > > erlang:is_nil(D.footSize) -> true | false. > > (where accessing a non-initialized field is an error. > I'm not totally convinced that this is a good idea, but > then again, we could stick to the heretic practice of > using the legal value 'undefined') > > Anonymous structs could perhaps be kept super-dynamic. I > don't know if this would complicate the implementation or > compromise efficiency. > I don't thing so - it's a hash lookup the first time you do anything, thereafter you can cache the result (yes the object code is self-modifying) the second time you check to see if things have changed. (Like how they do dispatches in smalltalk :-) /Joe > /Uffe > From ingela@REDACTED Wed Jan 15 11:16:54 2003 From: ingela@REDACTED (Ingela Anderton) Date: Wed, 15 Jan 2003 11:16:54 +0100 Subject: Win 2k References: <1042623252.50ecae20martin-g@home.se> Message-ID: <15909.13590.823800.750852@gargle.gargle.HOWL> Martin Gustafsson wrote: > Hello! > > One of our customers has a project where Erlang would be the perfect tool and maybe I have persuaded them to use it:-) But they want the application to run on a Win 2k machine. Has anyone tested Erlang on Win 2k? Is it working or is it possible to get it to work? > > Best regards > > Martin As Kent pointed out there might currently be some problems with gs-related stuff on windows platforms, that of course will be corrected. But apart from that Erlang works fine on Win 2000. Win 2000 is one of the supported platforms for Erlang/OTP. -- /m.v.h Ingela Ericsson AB - OTP team From Vlad.Dumitrescu@REDACTED Wed Jan 15 11:19:15 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Wed, 15 Jan 2003 11:19:15 +0100 Subject: Timer server Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6AE@esemont203.gbg.edt.ericsson.se> Hi, does anyone have had problems with the timer server, involving the timer_server process to grow larger and larger, until the whole VM crashes? It's in R7/R8. We observed such a behaviour, and are puzzled. The memory consumption graph looks something like this: | |---| | | | | |----| | |---| | |---| | --| The trouble is that we can't reproduce it in the lab, so if anyone could provide a clue, we'd be very thankful. Best regards, Vlad From mickael.remond@REDACTED Wed Jan 15 16:28:54 2003 From: mickael.remond@REDACTED (Mickael Remond) Date: Wed, 15 Jan 2003 16:28:54 +0100 Subject: stl and yaws In-Reply-To: <20030114.122201.126573444.luke@bluetail.com> References: <200301132331.19668.mikael.karlsson@creado.com> <20030114081612.GB6688@mremond.cgey.capgemini.fr> <20030114.152400.41632348.svg@surnet.ru> <20030114.122201.126573444.luke@bluetail.com> Message-ID: <20030115152853.GF14886@mremond.cgey.capgemini.fr> * Luke Gorrie [2003-01-14 12:22:01 +0100]: > Vladimir Sekissov wrote: > > Good day, > > > > I'm now working on Yaws extension for STL. It is finished on 90% and > > already contains: > > > > 1. Continuation-passing style sessions based on modified Ulf Wiger's > > `mdisp' module. Idea was borrowed from PLT Web-server. > > This I'm looking forward to :-) So am I ! > For people who haven't seen, the PLT paper is "Programming the Web > with High-Level Programming Languages", http://readscheme.org/xml-web/ I did not knew this paper, but I really think your work is very promising Vladimir. I am very eager to see the result and try it. Cheers, -- Micka?l R?mond From etxuwig@REDACTED Wed Jan 15 17:25:19 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 15 Jan 2003 17:25:19 +0100 (MET) Subject: partial restart of epmd? Message-ID: I have a machine where one node is running (and I don't want to touch it), and another node has crashed (but epmd still has the name). To make matters more interesting, one node runs OTP R9B, and the other ran OTP R7B. How do I resolve this without restarting epmd? /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From kent@REDACTED Wed Jan 15 17:56:05 2003 From: kent@REDACTED (Kent Boortz) Date: 15 Jan 2003 17:56:05 +0100 Subject: partial restart of epmd? In-Reply-To: References: Message-ID: Ulf Wiger writes: > I have a machine where one node is running (and I don't want > to touch it), and another node has crashed (but epmd still > has the name). > > To make matters more interesting, one node runs OTP R9B, and > the other ran OTP R7B. > > How do I resolve this without restarting epmd? My guess it that you can write a small C program that uses the erl_interface function erl_unpublish() to unregister the node name. In the current implementation of the erl_interface library there is no state kept between a erl_publish() and erl_unpublish() so this should work. You can also write a small erlang program that contact epmd with TCP on port 4369 and that sends a packet, I think it should be something like Two bytes length of packet excluding these two bytes (big endian) The byte 115 (ERL_EPMD_STOP_REQ) The name to unregister (short name without @xxxxx part and no \0) See "erl_ext_dist.txt", "epmd_srv.c" and "epmd_unpublish.c". On Unix it should not be possible that epmd keeps the name after crash of an Erlang node. If this is the case epmd is in a bad state caused by a bug in epmd that we don't know of, kent From etxuwig@REDACTED Wed Jan 15 18:09:12 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 15 Jan 2003 18:09:12 +0100 (MET) Subject: partial restart of epmd? In-Reply-To: Message-ID: Uh... never mind. The crashed node was alive after all... a combination of forgotten cookie and run_erl pipe problems. /Uffe On Wed, 15 Jan 2003, Ulf Wiger wrote: > >I have a machine where one node is running (and I don't want >to touch it), and another node has crashed (but epmd still >has the name). > >To make matters more interesting, one node runs OTP R9B, and >the other ran OTP R7B. > >How do I resolve this without restarting epmd? > >/Uffe > > -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From cpressey@REDACTED Wed Jan 15 21:13:15 2003 From: cpressey@REDACTED (Chris Pressey) Date: Wed, 15 Jan 2003 14:13:15 -0600 Subject: Structs (was RE: Record selectors) In-Reply-To: References: <20030114193145.46178fb6.cpressey@catseye.mb.ca> Message-ID: <20030115141315.795085fa.cpressey@catseye.mb.ca> On Wed, 15 Jan 2003 10:39:07 +0100 (CET) Joe Armstrong wrote: > [...] > Language design *is* (in a sense) choosing which operations should be > expressed by succinct syntax and efficiently implemented. That is very important, but it's stage 2. Stage 1 is deciding which semantics should be present in the language in the first place. And I'm just trying to point out that the struct semantics are essentially already there in the guise of the dict module. I don't really have any objections to having a nice syntax & efficient implementation of dictionaries per se. (We'd be catching up to Perl.) I only suggest that it might be smoother to extend dictionaries rather than to introduce a new concept - structs are so similar that it's hard to imagine them breaking anything that currently uses dictionaries. > [...] > My view is that data validation *only* occurs at a human -> computer > interface and at a boundary where two components communicate via. a > protocol and where the components are not trusted. Ah! I feel very similarly, except my view is that I shouldn't fully trust *anything* outside the current module - not even my own code, since I'm human and I make mistakes. In other words, every module is a boundary where components communicate with a protocol, even if that protocol is just a set of exported Erlang functions. > [...] > No encapsulation is fine - but objects (as in OO languages) do a lot > more than just encapsulate things. Yet strangely, the definitions Matthias produced are so vague that they hardly seem to warrant such expectations :) Anyway - OK, so forget the term "object", it's only a hint at what I mean (encapsulation), which is why I put it in quotes. But I don't agree that "no encapsulation is fine." My experience is that no encapsulation makes it a lot easier for a subtle bug to hide for a long time, while rigorous encapsulation makes it much more likely that a subtle bug will be exposed quickly. (Even if your validation of 'foreign' data is perfect, invalid data can still be generated internally by buggy code.) So, unless performance is utterly crucial, why chance it? Even then, do it with encapsulation first, until you are as positive as you can be that there are no hidden bugs, and only take it out when you hit the performance wall. However, if, as you mention in your other message, you're willing to add guards to structs, I'm all for it. Whether it's a proper module or a 'lambda module' made up of named funs, it makes little difference, it's still a "skin" and that's something that I consider highly important. -Chris From etxuwig@REDACTED Thu Jan 16 10:35:30 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 16 Jan 2003 10:35:30 +0100 (MET) Subject: Structs (was RE: Record selectors) In-Reply-To: <20030115141315.795085fa.cpressey@catseye.mb.ca> Message-ID: On Wed, 15 Jan 2003, Chris Pressey wrote: >But I don't agree that "no encapsulation is fine." I think Joe meant to write: "no, encapsulation is fine." At least that's how I chose to read it. (: /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From joe@REDACTED Thu Jan 16 10:48:53 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 16 Jan 2003 10:48:53 +0100 (CET) Subject: Structs (was RE: Record selectors) In-Reply-To: <20030115141315.795085fa.cpressey@catseye.mb.ca> Message-ID: On Wed, 15 Jan 2003, Chris Pressey wrote: > On Wed, 15 Jan 2003 10:39:07 +0100 (CET) > Joe Armstrong wrote: > > > [...] > > My view is that data validation *only* occurs at a human -> computer > > interface and at a boundary where two components communicate via. a > > protocol and where the components are not trusted. > > Ah! I feel very similarly, except my view is that I shouldn't fully trust > *anything* outside the current module - not even my own code, since I'm > human and I make mistakes. In other words, every module is a boundary > where components communicate with a protocol, even if that protocol is > just a set of exported Erlang functions. > You are right - but please don't tell anybody outside this mailing list... I will tell you a little story about what happened when people did things this way ... In one project that I know about, project management, in its "wisdom" forced the programmers to specify all interfaces in a "language neutral manner [1]" (the thinking behind this was, "so we can ditch Erlang and re-write it later in God's own language[2]"). This approach was ruthlessly enforced, resulting in code that ran like soggy treacle and to the obvious conclusion that Erlang was crap. Moral: By all means enforce internal boundaries but do so in manner which is appropriate to the problem. /Joe [1] When a "suit" say "language neutral IDL" they mean the language *must* be C++ and the IDL *must* be Corba. [2] GOL varies with time - it was C++ then became Java and I note a creeping tendency towards C#, but I might wrong about the C#. Thus it is is that projects are done in C++ (because it is "future proof") - the future being that period in time during which the entire application is re-written in Java. Erlang, however, cannot be used because it is not "future proof". From etxuwig@REDACTED Thu Jan 16 10:50:19 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 16 Jan 2003 10:50:19 +0100 (MET) Subject: Structs (was RE: Record selectors) In-Reply-To: <20030115141315.795085fa.cpressey@catseye.mb.ca> Message-ID: On Wed, 15 Jan 2003, Chris Pressey wrote: >On Wed, 15 Jan 2003 10:39:07 +0100 (CET) >Joe Armstrong wrote: >> My view is that data validation *only* occurs at a >> human -> computer interface and at a boundary >> where two components communicate via. a protocol >> and where the components are not trusted. > >Ah! I feel very similarly, except my view is that I >shouldn't fully trust *anything* outside the current module >- not even my own code, since I'm human and I make >mistakes. In other words, every module is a boundary where >components communicate with a protocol, even if that >protocol is just a set of exported Erlang functions. I think there is a difference in programming cultures that might cause some misunderstanding here. Good Erlang programs actually do tons of validation on internal data structures, but implicitly through pattern matching. The philosophy is rather one of always trying to write functions that either return a valid response or fail. This is most similar to assertions. Some typical examples would be: read_config(ConfigFile) -> {ok, Term} = file:consult(ConfigFile), load_config(Term). The implicit assumption here is that (a) ConfigFile actually exists and is readable, and (b) it contains one or more Erlang terms (in ASCII format), each terminated with '.' We do not attempt to resolve in our code whether (a) and (b) in fact hold, but rely on the fact that file:consult/1 will not return the pattern {ok, Term} otherwise. An example that I have in fact encountered in real code is: {_, Result} = mnesia:transaction(F), This is horrid and absolutely forbidden, since it will potentially bind Result to what is effectively garbage (the error description if the transaction were aborted.) The fundamental difference to most other programming environments is, I believe, the rule that "crashing is a valid, and recommended, way to handle bad data." This holds for internal data that _should_ be OK. It does not hold for user input, where you actually have to respond to the user in a civilised fashion (exploding or returning a 50-line erlang crash report does not qualify as civilised.) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From enano@REDACTED Thu Jan 16 10:55:35 2003 From: enano@REDACTED (Miguel Barreiro Paz) Date: Thu, 16 Jan 2003 10:55:35 +0100 (CET) Subject: Structs (was RE: Record selectors) In-Reply-To: References: Message-ID: > The fundamental difference to most other programming > environments is, I believe, the rule that "crashing is a > valid, and recommended, way to handle bad data." > > This holds for internal data that _should_ be OK. It does > not hold for user input, where you actually have to respond > to the user in a civilised fashion (exploding or returning a > 50-line erlang crash report does not qualify as civilised.) May I quote you, print it in \huge{} and hang it all around? From joe@REDACTED Thu Jan 16 11:00:07 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 16 Jan 2003 11:00:07 +0100 (CET) Subject: Structs (was RE: Record selectors) In-Reply-To: Message-ID: Golly, you're right. There once was a sign painter who had to make a sign saying: "James and son" He was wasn't very good at placing commas ,so he asked the person who wanted the sign: "Should there be a comma between James and and and and and son" Now I'm not sure about the placement of the commas between the placement of commas between the and's. Challenge: Produce a valid English sentence with more than five consecutive ands. /Joe On Thu, 16 Jan 2003, Ulf Wiger wrote: > On Wed, 15 Jan 2003, Chris Pressey wrote: > > >But I don't agree that "no encapsulation is fine." > > I think Joe meant to write: > > "no, encapsulation is fine." > > At least that's how I chose to read it. (: > > /Uffe > From Vlad.Dumitrescu@REDACTED Thu Jan 16 11:22:41 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Thu, 16 Jan 2003 11:22:41 +0100 Subject: Joe's challenge Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6B5@esemont203.gbg.edt.ericsson.se> What about "Wouldn't the sentence 'I want to put a hyphen between the words Fish and And and And and Chips in my Fish-And-Chips sign' have been clearer if quotation marks had been placed before Fish, and between Fish and and, and and and And, and And and and, and and and And, and And and and, and and and Chips, as well as after Chips?" (fount on the 'net) regards, Vlad -----Original Message----- From: Joe Armstrong [mailto:joe@REDACTED] Sent: Thursday, January 16, 2003 11:00 AM To: Ulf Wiger Cc: Chris Pressey; erlang-questions@REDACTED; Helen Taylor Subject: Re: Structs (was RE: Record selectors) Golly, you're right. There once was a sign painter who had to make a sign saying: "James and son" He was wasn't very good at placing commas ,so he asked the person who wanted the sign: "Should there be a comma between James and and and and and son" Now I'm not sure about the placement of the commas between the placement of commas between the and's. Challenge: Produce a valid English sentence with more than five consecutive ands. /Joe On Thu, 16 Jan 2003, Ulf Wiger wrote: > On Wed, 15 Jan 2003, Chris Pressey wrote: > > >But I don't agree that "no encapsulation is fine." > > I think Joe meant to write: > > "no, encapsulation is fine." > > At least that's how I chose to read it. (: > > /Uffe > From Erik.Reitsma@REDACTED Thu Jan 16 11:30:42 2003 From: Erik.Reitsma@REDACTED (Erik Reitsma (ELN)) Date: Thu, 16 Jan 2003 11:30:42 +0100 Subject: Joe's challenge Message-ID: <440A2703A54A8F4FB2AC2AE34F27129D2159AD@ESEALNT889.al.sw.ericsson.se> > Challenge: Produce a valid English sentence with more than five > consecutive ands. Since referring to words and groups of words is valid, I suggest: "And and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and and is a sequence of 21 consecutive ands." I know that this looks like cheating, but is it so much different from the other examples? *Erik. From etxuwig@REDACTED Thu Jan 16 11:33:36 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 16 Jan 2003 11:33:36 +0100 (MET) Subject: Structs (was RE: Record selectors) In-Reply-To: Message-ID: On Thu, 16 Jan 2003, Miguel Barreiro Paz wrote: >> The fundamental difference to most other programming >> environments is, I believe, the rule that "crashing is a >> valid, and recommended, way to handle bad data." >> >> This holds for internal data that _should_ be OK. It does >> not hold for user input, where you actually have to respond >> to the user in a civilised fashion (exploding or returning a >> 50-line erlang crash report does not qualify as civilised.) > > May I quote you, print it in \huge{} and hang it all around? Oh well, anything on this list is quotable of course. (: /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From enano@REDACTED Thu Jan 16 12:04:56 2003 From: enano@REDACTED (Miguel Barreiro Paz) Date: Thu, 16 Jan 2003 12:04:56 +0100 (CET) Subject: Structs (was RE: Record selectors) In-Reply-To: References: Message-ID: > >> The fundamental difference to most other programming > >> environments is, I believe, the rule that "crashing is a > >> valid, and recommended, way to handle bad data." (...) > > May I quote you, print it in \huge{} and hang it all around? > > > Oh well, anything on this list is quotable of course. (: I suppose exception throwing mechanisms were invented among other reasons to simplify the horrible code that results from defensive programming; ie., after a few burnouts C programmers turn every function call and assignment line into ten lines or so (check whether results are valid, then do something sensible if they aren't, continue otherwise). Now, languages like Java do have exception throwing mechanisms, but many programmers insist on C-style manual result checking. Some people around does suffer from Java daily :) From luke@REDACTED Thu Jan 16 13:04:41 2003 From: luke@REDACTED (Luke Gorrie) Date: Thu, 16 Jan 2003 13:04:41 +0100 (CET) Subject: Structs In-Reply-To: References: Message-ID: <20030116.130441.07646878.luke@bluetail.com> Miguel Barreiro Paz wrote: > I suppose exception throwing mechanisms were invented among other > reasons to simplify the horrible code that results from defensive > programming; ie., after a few burnouts C programmers turn every function > call and assignment line into ten lines or so (check whether results are > valid, then do something sensible if they aren't, continue otherwise). > Now, languages like Java do have exception throwing mechanisms, but many > programmers insist on C-style manual result checking. I still have problems in Erlang in the cases where I don't want to crash, i.e. the non-assertion type of error detection. Here's a function I wrote recently: connect(Host, User, Password) -> case otp_ftp:open(Host) of {ok, Pid} -> link(Pid), case otp_ftp:user(Pid, User, Password) of ok -> case otp_ftp:pwd(Pid) of {ok, Home} -> ?event(ftp, "~p: Home is ~p", [self(), Home]), case otp_ftp:type(Pid, binary) of ok -> %% It is at about this level of nesting %% that better exception handling in %% erlang becomes appetizing.. {ok, Pid, Home}; {error, Rsn} -> {error, otp_ftp:formaterror(Rsn)} end; {error, Rsn} -> {error, otp_ftp:formaterror(Rsn)} end; {error, Rsn} -> {error, otp_ftp:formaterror(Rsn)} end; {error, Rsn} -> {error, otp_ftp:formaterror(Rsn)} end. Cheers, Luke From etxuwig@REDACTED Thu Jan 16 13:38:48 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 16 Jan 2003 13:38:48 +0100 (MET) Subject: Structs In-Reply-To: <20030116.130441.07646878.luke@bluetail.com> Message-ID: On Thu, 16 Jan 2003, Luke Gorrie wrote: >I still have problems in Erlang in the cases where I don't >want to crash, i.e. the non-assertion type of error >detection. Here's a function I wrote recently: If the philosophy of making functions return a correct value or exit were followed more consistently, one only needs to catch exceptions at the top and format a nice message. The following implementation avoids the indentation misery. We have to wrap some functions to give them correct-or-exit semantics. /Uffe connect(Host, User, Password) -> case catch begin Pid = open(Host), user(Pid, User, Password), Home = pwd(Pid), type(Pid, binary), {ok, Pid, Home} end of {'EXIT', Reason} -> {error, otp_ftp:formaterror(Reason)}; Result -> Result end. open(Host) -> ok_value(otp_ftp:open(Host)). user(Pid, User, Password) -> ok(otp_ftp:user(Pid, User, Password)). pwd(Pid) -> ok_value(otp_ftp:pwd(Pid)). type(Pid, Type) -> ok(otp_ftp:type(Pid, Type)). ok_value({ok, Result}) -> Result; ok_value({error, Reason}) -> exit(Reason). ok(ok) -> ok; ok({error, Reason}) -> exit(Reason). > connect(Host, User, Password) -> > case otp_ftp:open(Host) of > {ok, Pid} -> > link(Pid), > case otp_ftp:user(Pid, User, Password) of > ok -> > case otp_ftp:pwd(Pid) of > {ok, Home} -> > ?event(ftp, "~p: Home is ~p", [self(), Home]), > case otp_ftp:type(Pid, binary) of > ok -> > %% It is at about this level of nesting > %% that better exception handling in > %% erlang becomes appetizing.. > {ok, Pid, Home}; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end. > >Cheers, >Luke > > -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From mikael.karlsson@REDACTED Thu Jan 16 13:55:05 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Thu, 16 Jan 2003 13:55:05 +0100 Subject: Structs In-Reply-To: <20030116.130441.07646878.luke@bluetail.com> References: <20030116.130441.07646878.luke@bluetail.com> Message-ID: <200301161355.05844.mikael.karlsson@creado.com> Hi Luke, Whats wrong with: connect(Host, User, Password) -> case catch connect1(Host, User, Password) of {ok,Result} -> {ok,Result}; {badmatch,{{error, Rsn}} -> {error, otp_ftp:formaterror(Rsn)} end. connect1(Host, User, Password) -> {ok, Pid} = otp_ftp:open(Host), link(Pid), ok = otp_ftp:user(Pid, User, Password), {ok, Home} = otp_ftp:pwd(Pid), ?event(ftp, "~p: Home is ~p", [self(), Home]), ok = otp_ftp:type(Pid, binary), {ok, {Pid, Home}}. ?/Mikael torsdag 16 januari 2003 13:04 skrev Luke Gorrie: > > I still have problems in Erlang in the cases where I don't want to > crash, i.e. the non-assertion type of error detection. Here's a > function I wrote recently: > > connect(Host, User, Password) -> > case otp_ftp:open(Host) of > {ok, Pid} -> > link(Pid), > case otp_ftp:user(Pid, User, Password) of > ok -> > case otp_ftp:pwd(Pid) of > {ok, Home} -> > ?event(ftp, "~p: Home is ~p", [self(), > Home]), case otp_ftp:type(Pid, binary) of > ok -> > %% It is at about this level of > nesting %% that better exception handling in %% erlang becomes appetizing.. > {ok, Pid, Home}; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end. > > Cheers, > Luke From luke@REDACTED Thu Jan 16 14:01:29 2003 From: luke@REDACTED (Luke Gorrie) Date: Thu, 16 Jan 2003 14:01:29 +0100 (CET) Subject: Structs In-Reply-To: References: <20030116.130441.07646878.luke@bluetail.com> Message-ID: <20030116.140129.63131495.luke@bluetail.com> Ulf Wiger wrote: > On Thu, 16 Jan 2003, Luke Gorrie wrote: > > >I still have problems in Erlang in the cases where I don't > >want to crash, i.e. the non-assertion type of error > >detection. Here's a function I wrote recently: > > If the philosophy of making functions return a correct value > or exit were followed more consistently, one only needs to > catch exceptions at the top and format a nice message. > > The following implementation avoids the indentation misery. > We have to wrap some functions to give them correct-or-exit > semantics. But the cost is that you can accidentally catch crashes inside the otp_ftp module, right? That means you could feed arbitrary crash-reasons into otp_ftp:formaterror. I find this a bit confusing compared with the ugly-but-simple deeply nested code. What I'd like is a 'try-catch' language feature that I've heard Robert Virding talk about, where you say something like: try E catch Pat1 -> ..; ... PatN -> ... end And it only catches exceptions matching the patterns; others continue uncaught. That way we could use throw({error, Reason}) and catch {error, Reason}, and never have to worry about accidentally catching real crashes. I don't think that try-catch snippet is actually how he described it, but something like that. It would make a good addition I think, since I need 'catch' quite often, and it rarely does exactly what I want. In particular I don't like losing the backtrace of the original error, after I catch something that I didn't really want to. Cheers, Luke From mikael.karlsson@REDACTED Thu Jan 16 14:22:54 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Thu, 16 Jan 2003 14:22:54 +0100 Subject: Structs In-Reply-To: <200301161355.05844.mikael.karlsson@creado.com> References: <20030116.130441.07646878.luke@bluetail.com> <200301161355.05844.mikael.karlsson@creado.com> Message-ID: <200301161422.54229.mikael.karlsson@creado.com> Sorry, wrong badmatch guess it should be connect(Host, User, Password) -> case catch connect1(Host, User, Password) of {ok,Result} -> {ok,Result}; {'EXIT?,{ {badmatch,{error, Rsn}},_}} -> {error, otp_ftp:formaterror(Rsn)} end. /Mikael > Hi Luke, > Whats wrong with: > > connect(Host, User, Password) -> > case catch connect1(Host, User, Password) of > {ok,Result} -> > {ok,Result}; > {badmatch,{{error, Rsn}} -> > {error, otp_ftp:formaterror(Rsn)} > end. > > connect1(Host, User, Password) -> > {ok, Pid} = otp_ftp:open(Host), > link(Pid), > ok = otp_ftp:user(Pid, User, Password), > {ok, Home} = otp_ftp:pwd(Pid), > ?event(ftp, "~p: Home is ~p", [self(), Home]), > ok = otp_ftp:type(Pid, binary), > {ok, {Pid, Home}}. > > ?/Mikael > From richardc@REDACTED Thu Jan 16 14:25:01 2003 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 16 Jan 2003 14:25:01 +0100 (MET) Subject: Structs In-Reply-To: <20030116.140129.63131495.luke@bluetail.com> Message-ID: It's actually just been implemented all the way through, and will most probably be in the next release from OTP. Actually, you'll even be able to write the following, if you intend to switch on the result of the operation in the normal case when everything worked: try Exprs of ... -> ... catch ... -> ... end (i.e., skipping the 'of ...' part is equivalent to writing 'of Result -> Result', if Result is a new variable) Credits to Fredrik Linder for this idea. /Richard On Thu, 16 Jan 2003, Luke Gorrie wrote: > What I'd like is a 'try-catch' language feature that I've heard Robert > Virding talk about, where you say something like: > > try E > catch > Pat1 -> ..; > ... > PatN -> ... > end > > And it only catches exceptions matching the patterns; others continue > uncaught. That way we could use throw({error, Reason}) and catch > {error, Reason}, and never have to worry about accidentally catching > real crashes. Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ From luke@REDACTED Thu Jan 16 14:26:13 2003 From: luke@REDACTED (Luke Gorrie) Date: Thu, 16 Jan 2003 14:26:13 +0100 (CET) Subject: Structs In-Reply-To: <200301161422.54229.mikael.karlsson@creado.com> References: <20030116.130441.07646878.luke@bluetail.com> <200301161355.05844.mikael.karlsson@creado.com> <200301161422.54229.mikael.karlsson@creado.com> Message-ID: <20030116.142613.97296389.luke@bluetail.com> Mikael Karlsson wrote: > Sorry, wrong badmatch > guess it should be > > connect(Host, User, Password) -> > case catch connect1(Host, User, Password) of > {ok,Result} -> > {ok,Result}; > {'EXIT?,{ {badmatch,{error, Rsn}},_}} -> > {error, otp_ftp:formaterror(Rsn)} > end. I'm too scared of catching badmatch errors caused by other code that I'm calling, in the otp_ftp module :-) -Luke From luke@REDACTED Thu Jan 16 14:27:34 2003 From: luke@REDACTED (Luke Gorrie) Date: Thu, 16 Jan 2003 14:27:34 +0100 (CET) Subject: Structs In-Reply-To: References: <20030116.140129.63131495.luke@bluetail.com> Message-ID: <20030116.142734.122622344.luke@bluetail.com> Richard Carlsson wrote: > > It's actually just been implemented all the way through, > and will most probably be in the next release from OTP. Hurray!! -Luke From spearce@REDACTED Thu Jan 16 16:58:10 2003 From: spearce@REDACTED (Shawn Pearce) Date: Thu, 16 Jan 2003 10:58:10 -0500 Subject: Structs (was RE: Record selectors) In-Reply-To: References: Message-ID: <20030116155810.GA9630@spearce.org> Miguel Barreiro Paz wrote: > I suppose exception throwing mechanisms were invented among other > reasons to simplify the horrible code that results from defensive > programming; ie., after a few burnouts C programmers turn every function > call and assignment line into ten lines or so (check whether results are > valid, then do something sensible if they aren't, continue otherwise). > Now, languages like Java do have exception throwing mechanisms, but many > programmers insist on C-style manual result checking. > > Some people around does suffer from Java daily :) Not that exception throwing helps any: InputStream file = null; try { file = new FileInputStream(...); read from file file.close(); } catch (IOException ioe) { if (file != null) { try { file.close(); } catch (IOException ioe2) { // What do i do if i can't close the // file during an error? Assume it's // ok to ignore the second error? } } throw ioe; } is just an annoying mess in Java. Exceptions are not always what their designers thought they would be. I'm sure someone here could come up with a better format for that mess though. Personally, I prefer Erlang, but am told to write Java, as its GOL. *sigh* -- Shawn. From richardc@REDACTED Thu Jan 16 17:31:51 2003 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 16 Jan 2003 17:31:51 +0100 (MET) Subject: Exceptions (was Re: Structs (was RE: Record selectors)) In-Reply-To: <20030116155810.GA9630@spearce.org> Message-ID: It looks like the only real problem here is that the file API does not offer a function that captures one of the most common uses (the traditional "just close this file if it's open, dammit") but only the totally generic "I'll tell you about anything that might happen during the operation" method file.close(). Of course, you can write that one yourself as a utility function, which might be a good idea in this example. Apart from that, I don't think you can come up with any piece of code that gives you the exact (and nontrivial, if you think about what it does) error handling that your example contains, using fewer tests and/or being more concisely written. (Maybe test for file==null before reading starts?) /Richard On Thu, 16 Jan 2003, Shawn Pearce wrote: > InputStream file = null; > > try > { > file = new FileInputStream(...); > read from file > file.close(); > } catch (IOException ioe) > { > if (file != null) > { > try > { > file.close(); > } catch (IOException ioe2) > { > // What do i do if i can't close the > // file during an error? Assume it's > // ok to ignore the second error? > } > } > > throw ioe; > } > > is just an annoying mess in Java. Exceptions are not always > what their designers thought they would be. I'm sure someone > here could come up with a better format for that mess though. > Personally, I prefer Erlang, but am told to write Java, as its > GOL. *sigh* > > -- > Shawn. > > Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ From hal@REDACTED Thu Jan 16 17:35:20 2003 From: hal@REDACTED (Hal Snyder) Date: Thu, 16 Jan 2003 10:35:20 -0600 Subject: Structs In-Reply-To: <20030116.130441.07646878.luke@bluetail.com> (Luke Gorrie's message of "Thu, 16 Jan 2003 13:04:41 +0100 (CET)") References: <20030116.130441.07646878.luke@bluetail.com> Message-ID: <878yxlrr1z.fsf@ghidra.vail> Luke Gorrie writes: > I still have problems in Erlang in the cases where I don't want to > crash, i.e. the non-assertion type of error detection. Here's a > function I wrote recently: What about cond (or something like it)? Isn't that coming soon to Erlang? > connect(Host, User, Password) -> > case otp_ftp:open(Host) of > {ok, Pid} -> > link(Pid), > case otp_ftp:user(Pid, User, Password) of > ok -> > case otp_ftp:pwd(Pid) of > {ok, Home} -> > ?event(ftp, "~p: Home is ~p", [self(), Home]), > case otp_ftp:type(Pid, binary) of > ok -> > %% It is at about this level of nesting > %% that better exception handling in > %% erlang becomes appetizing.. > {ok, Pid, Home}; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end; > {error, Rsn} -> > {error, otp_ftp:formaterror(Rsn)} > end. From richardc@REDACTED Thu Jan 16 17:42:11 2003 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 16 Jan 2003 17:42:11 +0100 (MET) Subject: Structs In-Reply-To: <878yxlrr1z.fsf@ghidra.vail> Message-ID: On Thu, 16 Jan 2003, Hal Snyder wrote: > What about cond (or something like it)? > Isn't that coming soon to Erlang? It has some weird complications due to Erlang's variable binding/scoping rules, so don't expect it just yet. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ From luke@REDACTED Thu Jan 16 17:58:36 2003 From: luke@REDACTED (Luke Gorrie) Date: 16 Jan 2003 17:58:36 +0100 Subject: Exceptions (was Re: Structs (was RE: Record selectors)) In-Reply-To: References: Message-ID: Richard Carlsson writes: > It looks like the only real problem here is that the file API does not > offer a function that captures one of the most common uses (the > traditional "just close this file if it's open, dammit") but only the > totally generic "I'll tell you about anything that might happen during > the operation" method file.close(). Of course, you can write that one > yourself as a utility function, which might be a good idea in this > example. > > Apart from that, I don't think you can come up with any piece of code > that gives you the exact (and nontrivial, if you think about what it > does) error handling that your example contains, using fewer tests > and/or being more concisely written. (Maybe test for file==null before > reading starts?) How about: InputStream file = null; try { file = new FileInputStream(...); read from file; } finally { if (file != null) file.close(); } That should be within spitting distance of the same semantics, I *think* the only difference is that it will never try to close() the file twice. Well, and if an exception is trigged inside the 'try' and also by file.close(), I'm not exactly sure which one propagates - but "probably" you don't care. I think this captures the intent better too: you don't want to catch (suppress) any errors, you just want to setup the invariant that the file will be closed. > On Thu, 16 Jan 2003, Shawn Pearce wrote: > > > InputStream file = null; > > > > try > > { > > file = new FileInputStream(...); > > read from file > > file.close(); > > } catch (IOException ioe) > > { > > if (file != null) > > { > > try > > { > > file.close(); > > } catch (IOException ioe2) > > { > > // What do i do if i can't close the > > // file during an error? Assume it's > > // ok to ignore the second error? > > } > > } > > > > throw ioe; > > } From richardc@REDACTED Thu Jan 16 18:47:39 2003 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 16 Jan 2003 18:47:39 +0100 (MET) Subject: Exceptions (was Re: Structs (was RE: Record selectors)) In-Reply-To: Message-ID: On 16 Jan 2003, Luke Gorrie wrote: > InputStream file = null; > > try { > file = new FileInputStream(...); > read from file; > } finally { > if (file != null) > file.close(); > } Ah! Of course - I'd forgotten about 'finally'. (Note that what "finally" does in the case there was an exception is exactly what Shawn's code did: catch E, execute finally-body, re-throw E.) Interestingly, "finally" does not mix well with Erlang (and other functional languages), mainly because of tail recursion. If an exception occurs in the try-body, the finally-body is supposed to be executed *after* the catch-body has its say. But the catch-body might do a tail call, possibly never indended to return. If so: should we insert a call to the finally-code *before* the tail call (possibly making the code hard to understand), or should we force those calls to be non-tail recursive, always returning to perform the cleanup code afterwards (does not seem like a good idea either). /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ From enewhuis@REDACTED Thu Jan 16 19:35:17 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 16 Jan 2003 12:35:17 -0600 Subject: Meaning of [a]++b Message-ID: <004e01c2bd8e$048b02e0$9400a8c0@XENO> Can someone provide or point me in the direction of an explanation of what this means? > [a] ++ b [a|b] Is this a quirk that has a useful side-effect that is a feature? Or was this an intentional feature from the beginning? It reminds me of something I saw in Lisp, the dot operator or something. My memory fails me. Sincerely, Eric Newhuis From matthias@REDACTED Thu Jan 16 20:03:36 2003 From: matthias@REDACTED (Matthias Lang) Date: Thu, 16 Jan 2003 20:03:36 +0100 Subject: Meaning of [a]++b In-Reply-To: <004e01c2bd8e$048b02e0$9400a8c0@XENO> References: <004e01c2bd8e$048b02e0$9400a8c0@XENO> Message-ID: <15911.520.525904.931336@antilipe.corelatus.se> Eric Newhuis writes: > Can someone provide or point me in the direction of an explanation of > what this means? > > > [a] ++ b > [a|b] > > Is this a quirk that has a useful side-effect that is a feature? Or was > this an intentional feature from the beginning? It reminds me of > something I saw in Lisp, the dot operator or something. My memory fails > me. Since you appear to be familiar with Lisp, take a look at http://cs.gmu.edu/~sean/cs480/cons/ [a|b] is Erlang notation for a cons cell. You can implement many data structures using a cons cell, including linked lists. The ++ operator is intended for concatenating lists, but it happens to work for some other arguments too. Try writing an 'append' function by hand and you'll see why. I'd call it a quirk, though a well-defined one. Matthias From seb@REDACTED Thu Jan 16 20:13:16 2003 From: seb@REDACTED (Sebastian Strollo) Date: 16 Jan 2003 11:13:16 -0800 Subject: Meaning of [a]++b In-Reply-To: <004e01c2bd8e$048b02e0$9400a8c0@XENO> References: <004e01c2bd8e$048b02e0$9400a8c0@XENO> Message-ID: <4wwn0m0kiwj.fsf@locke.strollo.org> "Eric Newhuis" writes: > Can someone provide or point me in the direction of an explanation of > what this means? > > > [a] ++ b It means lists:append([a], b).... :-) > [a|b] Which is an "inproper" list, i.e. a list where the last tail isn't an empty list, []. E.g. [a] is a proper list, because hd([a]) -> 'a' and tl([a]) -> [] and so is [a,b] because tl(tl([a,b])) -> []. But [a|b] isn't a proper list because tl([a|b]) -> b. Not sure if this is the best way to explain it though... :-) I guess it might be worth to mention that after the | is the remainder of the list, but it isn't printed when you have a proper list (the remainder is nil), here are some examples from the shell: > [a,b,c|[]]. [a,b,c] > [a,b,c|[d,e]]. [a,b,c,d,e] > [a,b,c|d]. [a,b,c|d] The fact that append behaves this way is described in the man-page for lists:append/1. > It reminds me of > something I saw in Lisp, the dot operator or something. Yes it is equivalent of the "dotted pair" in lisp. Cheers, /Sebastian From jamesh@REDACTED Thu Jan 16 20:53:33 2003 From: jamesh@REDACTED (James Hague) Date: Thu, 16 Jan 2003 13:53:33 -0600 Subject: Structs Message-ID: >What about cond (or something like it)? >Isn't that coming soon to Erlang? I was always under the impression that the reason records were never replaced with something neater was because there was little incentive to go in and fiddle with the core language. But now "try" is on the way, as are structured modules, and possibly "cond." Surely record improvements are a higher priority? James From cpressey@REDACTED Thu Jan 16 21:51:28 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 16 Jan 2003 14:51:28 -0600 Subject: Structs (was RE: Record selectors) In-Reply-To: References: Message-ID: <20030116145128.1fe189eb.cpressey@catseye.mb.ca> On Thu, 16 Jan 2003 11:00:07 +0100 (CET) Joe Armstrong wrote: > > Golly, you're right. Whoops, sorry! I should have thrown an ambiguity exception. > There once was a sign painter who had to make a sign saying: > > "James and son" > > He was wasn't very good at placing commas ,so he asked the person > who wanted the sign: > > "Should there be a comma between James and and and and and son" > > Now I'm not sure about the placement of the commas between the > placement of commas between the and's. > > Challenge: Produce a valid English sentence with more than five > consecutive ands. Errr... I don't think I can, at least not without getting a headache. But my girlfriend, who has a degree in this sort of thing, tells me that the sentence "Buffalo buffalo buffalo Buffalo buffalo" is valid English (meaning "Bison from a city in New York confuse other bison from the same city") I conclude that language is more trouble than it's worth. From now on, I'm just going to point and grunt. :) -Chris From daniel.dudley@REDACTED Fri Jan 17 00:35:26 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Fri, 17 Jan 2003 00:35:26 +0100 Subject: Structs References: Message-ID: <001901c2bdb7$f916a1b0$85d1b33e@dld2000> Be careful, James, with a suggestion like that you will probably be accused of attacking the whole Erlang language, or that you should like it or lump it, or even that you should write your own replacement language. :-( That the record 'saga' is a recurring embarrassment to Erlang is evident in Joe's fine work on structs. What doesn't seem to be apparent to the implementors is that the problem isn't going to go away by itself. A year from now some smart-alec is going to raise the same questions again, then a year on from that ..., then a year on from that ..., then a year on from that ..., then a year on from that ..., ... And all this time the code base is growing, requiring more -- albeit not difficult -- work to correct one's code should the implementors ever get their heads out of the sand and make necessary changes. But as I said, one should be careful not to promote such wild suggestions -- we really must learn to accept the (im)perfect Erlang world as it is today. So everyone: please don't read this message, I really wouldn't want to be accused of attacking the whole Erlang language (again). Daniel ----- Original Message ----- From: "James Hague" To: Sent: Thursday, January 16, 2003 8:53 PM Subject: Re: Structs > >What about cond (or something like it)? > >Isn't that coming soon to Erlang? > > I was always under the impression that the reason records were > never replaced with something neater was because there was > little incentive to go in and fiddle with the core language. > But now "try" is on the way, as are structured modules, and > possibly "cond." Surely record improvements are a higher > priority? > > James From Lawrie.Brown@REDACTED Fri Jan 17 01:29:40 2003 From: Lawrie.Brown@REDACTED (Lawrie Brown) Date: Fri, 17 Jan 2003 11:29:40 +1100 Subject: Query about external format for lists (strings) Message-ID: <20030117002940.GA18713@icarus.itsc.adfa.edu.au> Hi everyone As part of my work developing the runtime for the EC Erlang Compiler, I've recently been implementing its support for the external binary format, based heavily on the low-level (en/decode*.c) erl_interface code, but adapted to suit the rather different term coding we use. I have a query about the list coding. From my reading of the code, and playing with binaries created on a standard erlang node, I take it that a list is always terminated with the ER_NIL_EXT (106) tag. However the code for encoding very large strings in encode_string.c as lists does not seem to write this trailing marker. Should it do so??? It confused me at first since I based my overall list encoder on it, then wondered why the binary from a conventional Erlang node for a list which I decoded and then regenerated as a binary wasn't the same size as the original, sigh. Anyway, I'd appreciate any feedback: 1) confirming that ALL lists (incl those generated for very large strings) should always be terminated by ER_NIL_EXT; 2) and if so, whether the code in erl_interface*/src/en/decode_string.c is hence incorrect. Thanks Cheers Lawrie ------------------------------------ <*> ------------------------------------ Post: Dr Lawrie Brown, Computer Science, UNSW@REDACTED, Canberra 2600 Australia Phone: 02 6268 8816 Fax: 02 6268 8581 Web: http://www.adfa.edu.au/~lpb/ From kent@REDACTED Fri Jan 17 03:24:57 2003 From: kent@REDACTED (Kent Boortz) Date: 17 Jan 2003 03:24:57 +0100 Subject: Query about external format for lists (strings) In-Reply-To: <20030117002940.GA18713@icarus.itsc.adfa.edu.au> References: <20030117002940.GA18713@icarus.itsc.adfa.edu.au> Message-ID: Lawrie Brown writes: > As part of my work developing the runtime for the EC Erlang Compiler, > I've recently been implementing its support for the external binary > format, based heavily on the low-level (en/decode*.c) erl_interface > code, but adapted to suit the rather different term coding we use. I > have a query about the list coding. From my reading of the code, and > playing with binaries created on a standard erlang node, I take it that > a list is always terminated with the ER_NIL_EXT (106) tag. However the > code for encoding very large strings in encode_string.c as lists does > not seem to write this trailing marker. Should it do so??? It confused > me at first since I based my overall list encoder on it, then wondered > why the binary from a conventional Erlang node for a list which I > decoded and then regenerated as a binary wasn't the same size as the > original, sigh. > > Anyway, I'd appreciate any feedback: > > 1) confirming that ALL lists (incl those generated for very large strings) > should always be terminated by ER_NIL_EXT; > > 2) and if so, whether the code in erl_interface*/src/en/decode_string.c > is hence incorrect. I'm currently looking over the erl_interface/ei source but haven't gone deeply into the external format yet. But this seem to be a bug. Strangely enough the decoding function also ignore the tail of the list (i.e. the last element). Because I'm working on improving the erl_interface code we have just begun to discuss some aspects of the interpretation of the external format. There is very little written about it. Some examples of problems with the interpretation - An Erlang node in the current implementation will always pack an Erlang integer into the smallest container possible in the external format but there is nothing said about this in "erts/emulator/internal_doc/erl_ext_dist.txt". Erl_interface can't for example decode a long string with ei_decode_string() if one of the elements is between 0 and 255 but coded into a bignum in the external format. I think even the emulator will break if the number 42 is sent to it as a large integer or bignum in the external format. It should fit into a small integer on the heap but will be coded into a bignum. If I'm not mistaken a compare for equality between the integer 42 created on the heap from the external format and the integer 42 created from your program could fail because the internal type is checked first and it is assumed that if the type is different then the integer can't be the same (I'm not 100% sure about this). - Reading the list header will not give the list length in all cases. If the tail of the list is also a list it will add elements to the list, i.e. ei_encode_list_header(buf, &i, 2); ei_encode_integer(buf, &i, 'a'); ei_encode_integer(buf, &i, 'b'); ei_encode_list_header(buf, &i, 1); ei_encode_integer(buf, &i, 'c'); ei_encode_empty_list(buf, &i); is actually the list [$a,$b,$c], i.e. a list of length 3. Again the emulator will not create lists coded like this but if a list like this was created by erl_interface then decoding it with ei_decode_string() will break. With the current bug not checking for [] it will return the string "ab". It is not currently decided if we will tighten up the definition of the external format, what is allowed or not, or if we will correct all source code that make false assumptions about how things are coded, kent From Lawrie.Brown@REDACTED Fri Jan 17 04:57:15 2003 From: Lawrie.Brown@REDACTED (Lawrie Brown) Date: Fri, 17 Jan 2003 14:57:15 +1100 Subject: Structs - thoughts on implementation In-Reply-To: References: Message-ID: <20030117035715.GA22863@icarus.itsc.adfa.edu.au> Hi Joe & everyone On Tue, Jan 14, 2003 at 10:41:44AM +0100, Joe Armstrong wrote: > > Joe Armstrong, who is no longer at Ericsson, once drew an > > idea about efficient and safe records on my whiteboard. .... > A = ~{name="joe", footSize=42}, %% define a struct > A.footSize, %% access a field > B = ~A{likes="motorbikes"}, %% add a new field > ~{likes=X, name=N} = B} %% pattern match etc. > *without* any record defs. .... > I have appended a pdf file describing structs as I would like to see > them and a test implementation. I've been following the discussion with some interest, and pondering how easy it'd be to add this to the EC Erlang Compiler & runtime I'm busy working on. However in going over the proposals, I have a suggestion for a slightly different implementation to the one Joe suggested in his paper. Also tracking Ulf's suggestions ... On Wed, 15 Jan 2003, Ulf Wiger wrote: > Then, one could create a named struct just like a new record: > C = ~guru{name = "robert", likes="water rockets"}. I'm pondering an implementation that would basically be a "structured" tuple (sorry for the pun ;-) looking thus: {structname, flag, tag1, val1, tag2, val2, ..., tagn, valn} where - structname is the name of the structure (atom) - flag is 'static_struct' (tags fixed) or 'dynamic_struct" (extensible) - tag1 & val1 are the first field tag and value up to the nth and importantly, the tags are stored in sorted order to allow an efficient binary search to locate any desired tag & value in the runtime. The size of the tuple will be 2n+2 for a struct with n fields. Hence Ulf's example above would be represented by: C = {guru, dynamic_struct, likes, "water rockets", name, "robert"} a statement like: D = ~C{likes="motorbikes"} results in: D = {guru, dynamic_struct, likes, "motorbikes", name, "robert"} and a statement like: E = ~C{hates="skiing"} results in: E = {guru, dynamic_struct, hates, "skiing", likes, "water rockets", name, "robert"} I think this has the nice advantage of being dynamic, self-documenting, and compatible with existing Erlang types (& distribution protocol). In terms of run-time support, I lean towards extending/overloading some of the tuple BIFs thus: + element(Var, Type, Tag) - checks Var is a struct of specified Type, and returns the Value associated with Tag (or undefined), a guard + setelement(Var, Type, Tag, Value) - checks Var is a struct of specified Type, and either updates the value associated with Tag if present or (provided it s dynamic struct) extends the struct to support the new Tag & Value inserted into the appropriate position + size(Var, Type) - checks Var is a struct of specified Type, and returns the number of fields in it (its arity) + struct(Var, Type) - a recognizer for a struct of specified Type (cf record) And whilst the stored form would be basically a tuple, it'd be easy enough to add a flag to say it was created as a struct to improve efficiency. And of course you need the compiler to recognise the new syntax. Also need some way of saying the you want a static struct (with tags fixed upon creation) vs a dynamic one. Comments???? Cheers Lawrie ------------------------------------ <*> ------------------------------------ Post: Dr Lawrie Brown, Computer Science, UNSW@REDACTED, Canberra 2600 Australia Phone: 02 6268 8816 Fax: 02 6268 8581 Web: http://www.adfa.edu.au/~lpb/ From spearce@REDACTED Fri Jan 17 05:15:25 2003 From: spearce@REDACTED (Shawn Pearce) Date: Thu, 16 Jan 2003 23:15:25 -0500 Subject: Structs - thoughts on implementation In-Reply-To: <20030117035715.GA22863@icarus.itsc.adfa.edu.au> References: <20030117035715.GA22863@icarus.itsc.adfa.edu.au> Message-ID: <20030117041525.GA10639@spearce.org> I've been following this quite a bit, and have these two comments: - Dynamic structs are just asking for trouble. I run into this problem in Perl so often: I spell 'upper' in one spot and 'uper' in the other, thanks to having human fingers. Program doesn't work for 3 days while I debug my hash keys. - Dynamic structs are cool, but a dyanmic struct is really just a tagged list: [{key, val},{key, val}] stored in sorted order or such. Although a tagged list isn't very fast to search. Plus, with some of the syntax being kicked around, structs vs. records will get very complex, very fast. Erlang is starting to become almost as grotty as Perl! static structs meanwhile.... ohhhhh the possibilities.... no more records! :) Faster implementation possible. Maybe. I especially liked the proposal (I forget who proposed it, sorry) to have guards on fields and on the struct itself to validate the struct on all modifications, preventing improper modification of the struct. Sweet. Now all I need is a good business case to do my next project in Erlang. I think a load testing environment in Erlang could be very easy to build... and fun. Lawrie Brown wrote: > where > - structname is the name of the structure (atom) > - flag is 'static_struct' (tags fixed) or 'dynamic_struct" (extensible) > - tag1 & val1 are the first field tag and value up to the nth -- Shawn. From fritchie@REDACTED Fri Jan 17 08:30:03 2003 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 17 Jan 2003 01:30:03 -0600 Subject: Announce: tcpbalance 1.0 for distcc Message-ID: <200301170730.h0H7U3H9030802@snookles.snookles.com> Attached is a message I sent to the mailing list yesterday about a TCP load-balancing proxy I wrote in Erlang. Of the load-balancing TCP proxies I'd found before, none were ideally suited for use with distcc. So I wrote one I wanted in about an afternoon. :-) Of interest to erlang-questions readers? Perhaps. It's an example of an application, complete with supervisor. The overall packaging isn't complete, (intentionally) nowhere near Ulf Wiger's recently-posted example ... but perhaps the README, which describes a bit of fun to be had with hot code loading and using "appmon" to simulate fault injection, may be a useful example for introducing the language to newcomers? -Scott P.S. Distcc is a wonderful utility for helping distribute C & C++ compilation to remote machines ... without having to worry (much) about compiler versions, file system layout mismatches, header file differences, etc. See http://distcc.samba.org/. I've used it with Make and SCons (http://www.scons.org/) with happy results. (Much happier with SCons, BTW.) ------- Forwarded Message From: Scott Lystig Fritchie To: distcc@REDACTED Subject: Announce: tcpbalance 1.0 for distcc Date: Thu, 16 Jan 2003 17:51:24 -0600 Here's the beginning of the README file I've created for tcpbalance version 1.0. Nice, original name, huh? The full README file, as well as the source code, is available at http://www.snookles.com/erlang/tcpbalance/. Please email me with comments, bug fixes, critique, etc. I hope that my proxy is useful in either of two ways: 1. Used as-is to help share distcc back-end hosts for multiple developers working on multiple workstations. 2. Used as a model for a "real", full-featured proxy that otherwise does the same as #1. Special thanks to Martin Pool for his work in bringing distcc version 1.0 to the world. - -Scott - --- snip --- snip --- snip --- snip --- snip --- snip --- snip --- TCPBalance, a load-balancing TCP proxy for distcc ================================================= There are dozens of Open Source TCP proxies available, written in close to a dozen languages, many of them capable of load balancing. Many of them would work with "distcc". Why write yet another TCP proxy? Why do it in Erlang? All of the TCP proxies I found, none appeared to have the following combination of features: 1. Not be too HTTP-centric to not be able to work with "distcc". 2. Be aware that some back-end hosts may be faster than other hosts. For each client connection, the proxy should choose the fastest back-end host that is currently idle. 3. Be aware of back-end hosts with multiple CPUs. 4. When all back-end hosts are busy, make the client wait for the next available back-end host when it is available, rather than giving a back-end host more work than it is configured to handle. 5. Detect when a back-end host is down and do something sane (like avoid giving future jobs to the dead machine). 6. Permit an administrator to put back-end hosts back in service, take them out of service, as well as add and remove hosts from the pool without adversely affecting clients using the proxy. 7. Keep basic statistics about back-end hosts and make them available via HTTP or Telnet. Features 1-5 were mandatory. Features 6-7 would be nice. In a couple of hours of Web surfing, I didn't find a TCP proxy that was capable of doing 1-5, so I decided to write my own. I knew it would be fairly easy to implement features 6-7 as well as 1-5 in Erlang (see http://www.erlang.org/), so that's what I used. This proxy has been in use at Caspian Networks for over two months. It's pretty solid. This README file is quite long. Sorry about that. However, much of it is a tutorial for Erlang newbies ... and perhaps a bit of evangelism. :-) I'll try to keep things straightforward, but I will also demonstrate some of the nifty communication, fault-tolerance, and hot code upgrade features of Erlang. ------- End of Forwarded Message From cpressey@REDACTED Thu Jan 16 23:28:56 2003 From: cpressey@REDACTED (Chris Pressey) Date: Thu, 16 Jan 2003 16:28:56 -0600 Subject: Structs (was RE: Record selectors) In-Reply-To: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6AB@esemont203.gbg.edt.ericsson.se> References: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6AB@esemont203.gbg.edt.ericsson.se> Message-ID: <20030116162856.7cc2a15c.cpressey@catseye.mb.ca> On Wed, 15 Jan 2003 09:18:38 +0100 "Vlad Dumitrescu (EAW)" wrote: > Hi Chris, Hey :) Sorry if this reply is a bit rambling, it prompted me to get down some of my thoughts. > >Forgive me, but is Erlang really so object-shy that encapsulation is > >something that we feel we can afford to avoid simply because "they" > >have turned it into a meaningless buzzword? > > I am by no means an Erlang guru, but I was once for not so long ago just > as puzzled by the same question. Now I got used to the "hard core" > Erlang way and it works just as well. I can appreciate that, but I've gone back and forth a bit lately. OO is a weirdly nebulous school of thought... there's a tendency to fall into a false dilemma of "either you worship it or you despise it", while it's of almost no value to say "this language is OO but this one isn't", so some deconstruction is probably in order. >From the OO literature I've read, three tenets seems to be universally agreed upon: encapsulation, polymorphism, and inheritance. Two others get mentioned often enough, abstraction and identity, but they seem less well understood. I can live without inheritance - when it is called for, it's rarely more than one level deep (any deeper than that usually stems from an almost Platonic desire to categorize everything perfectly, which strikes me as doomed.) Erlang's behaviours accomplish the equivalent of one level of inheritance beautifully, and so much more too. Polymorphism pretty much comes "for free" in any dynamically-typed language, so it's not really worth worrying about. Abstraction seems to take on a special meaning to some OO folks - I have a hard time distinguishing it from encapsulation 90% of the time. My feeling is that if something has been encapsulated, then it's also been abstracted, so it's also not worth worrying much about. Identity is similarly subjective - you could argue that this 5 doesn't have a distinct identity from this 5, therefore integers are not objects, or, you could argue that those two 5's do have distinct identities because they appear in different places in this paragraph. It depends on the model. Either way, identity issues are easy enough to implement by using references or names or other keys into an ETS table or something similar (and you can address mutability issues at the same time.) Which leaves us with encapsulation, which has been around a lot longer than OO of course, and can be seen in lots of places - local variables, namespaces, even protected memory is a form of encapsulation at the hardware level. I consider it to be the most important of these concepts (although it is of course still possible to overdo it) > To make sure we are referring to the same thing: encapsulation is one > issue, having support from the compiler & run-time for a nice syntax and > better efficiency is another. Yes. If encapsulation isn't provided (as is the case with records), I find it important enough that I'll roll my own. (I can't really roll my own syntax or implementation without a lot of ugliness.) My point regarding structs is that if I still have to roll my own encapsulation "on top" of them, the net gain from using them instead of records is very small. > In fact, in Erlang one can use > encapsulation on two levels: by writing wrapper functions and by using a > server process. One can also use both (even if I remember someone > arguing that it is better to write "Pid ! Msg" than encapsulate it in a > function call, because the former does not hide that there is a process > doing the work). That was me. I should take this opportunity to clarify, though. If you think that, syntactically, '!' implies a probable change of state (as in ServerPid ! do_something), while '()' implies no change of state (as in math:sin(Theta),) then encapsulating a message send with a wrapper function makes code less clear. To make things clearer, a message send (or anything else that changes state or otherwise has side-effects) should be encapsulated with a wrapper *process*. In practical terms this is somewhat expensive, since you now have two processes per server, one of which is only there to translate messages from the external format used by the client to the internal format used by the server. > The latter issue is at stake, together with the expressed need to have > some kind of type checking. If there is a way to get the best of both > worlds without paying too much for it, then it will be found and > implemented. > > As for objects, I think processes can implement the underlying concept > better than for example C++ objects. Hey, one could even think of > compiling today's records (or tomorrow's mutable coagulators :-) into > processes! The big minus is efficiency, but the coolness factor might be > bigger :-) It's not as absurd as it sounds! I'll put it this way: if you're going to do this, then Erlang is definately the language to do it in. An example of this sort of 'use processes for *everything*' approach might be a project I want to try sometime this year, that is, to write a digital circuit simulator in Erlang. Instead of messing with nasty physics equations, I think the problem could be modelled with one process per gate (or chip). Each chip process would receive a message every time one of it's pins changed state, so messages would essentially look like {N, M} where N is the pin number and M is either rising_edge or falling_edge. The process itself would take care of 'steady' state by tracking it every time a new message came in, and would also produce new messages to send to other chips wired to its output pins. Doing this with one process per truly concurrent unit should make it simple (almost trivial) to implement - but the thought of doing it this way with any language besides Erlang gives me shivers. But (again in regards to structs) there are still going to be cases where you have basically 'passive' data structures that don't have any dynamic behaviour, so modelling them as processes *is* going to be wasteful. I do grasp that the Erlang Way is to do validation is aggressively, by writing code for the correct case and then just letting it crash (and be caught from on high) when things don't work out as planned - but in the case of passive data structures, you still need some sort of entry point where you can describe the correct case (with guards) - currently I use wrapper functions for this purpose, but if that entry point can be put on the data structure itself, all the better (I dimly recall suggesting guards on records once, a long time ago - it's the same basic idea.) -Chris not a guru, but possibly a bishop-errant or something From Vlad.Dumitrescu@REDACTED Fri Jan 17 10:22:48 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Fri, 17 Jan 2003 10:22:48 +0100 Subject: Structs (was RE: Record selectors) Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6BD@esemont203.gbg.edt.ericsson.se> > Hey :) Sorry if this reply is a bit rambling, it prompted me > to get down some of my thoughts. No problem, I see these discussions as brainstorming, and all ideas might trigger a better idea in someone else's head. > Abstraction seems to take on a special meaning to some OO > folks - I have a > hard time distinguishing it from encapsulation 90% of the time. I see abstraction in OO context as encapsulation+polymorphism. > If encapsulation isn't provided (as is the case with records), I > find it important enough that I'll roll my own. One problem with encapsulating record accesses into functions is that if collides somewhat with pattern matching, and also if modifying more than one field, it is a less efficient than direct access. > An example of this sort of 'use processes for *everything*' approach might > be a project I want to try sometime this year, that is, to write a digital > circuit simulator in Erlang. Instead of messing with nasty physics > equations, I think the problem could be modelled with one process per gate > (or chip). I have a (permanently ongoing :-) project where I would use Erlang processes to model real world objects, in a robotics environment. If you get started on your project, maybe you can let me know and we could see if we could help each other. best regards, Vlad From etxuwig@REDACTED Fri Jan 17 11:37:44 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 17 Jan 2003 11:37:44 +0100 (MET) Subject: Structs In-Reply-To: Message-ID: On Thu, 16 Jan 2003, James Hague wrote: >>What about cond (or something like it)? >>Isn't that coming soon to Erlang? > >I was always under the impression that the reason records >were never replaced with something neater was because there >was little incentive to go in and fiddle with the core >language. Until fairly recently, and at the time when records were added to the language, it would have been a huge undertaking to records "right", since there were not more type tags to use. Rest assured that the internal discussions about the proposed record syntax were quite animated (Erlang was not Open Source back then.) At the end, the proposed solution did address some real problems (while introducing some new ones), and I think that it was a reasonable tradeoff. As of R7 (I think), Erlang has a new tagging system (thanks to the HIPE group), and adding a 'struct' type would be quite feasible. Reforming records has been on the agenda since the possibility arose to do it right. Now, what constitutes the "right" way of replacing records has been discussed a few times. For a while, Richard O'Keefe's abstract patterns looked promising. Now, Joe's structs look more promising, but we need to work out what the syntax and semantics should really be, and make sure that we don't replace records with something that will be subject to the same discussions a few years from now. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From jocke@REDACTED Fri Jan 17 12:33:24 2003 From: jocke@REDACTED (Joakim G.) Date: Fri, 17 Jan 2003 12:33:24 +0100 Subject: Structs References: Message-ID: <3E27EA04.10409@bluetail.com> Ulf Wiger wrote: > On Thu, 16 Jan 2003, James Hague wrote: > > As of R7 (I think), Erlang has a new tagging system (thanks > to the HIPE group), and adding a 'struct' type would be > quite feasible. as well a 'string' type. (Oh no! Not that thread again :-) /Jocke From eleberg@REDACTED Fri Jan 17 12:31:21 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Fri, 17 Jan 2003 12:31:21 +0100 (MET) Subject: Structs Message-ID: <200301171131.h0HBVLH15299@cbe.ericsson.se> > Date: Fri, 17 Jan 2003 12:33:24 +0100 > From: "Joakim G." > > Ulf Wiger wrote: > > On Thu, 16 Jan 2003, James Hague wrote: > > > > As of R7 (I think), Erlang has a new tagging system (thanks > > to the HIPE group), and adding a 'struct' type would be > > quite feasible. > > as well a 'string' type. yes, please. bengt From Sean.Hinde@REDACTED Fri Jan 17 12:37:21 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Fri, 17 Jan 2003 11:37:21 -0000 Subject: Strings (was RE: Structs) Message-ID: <04D356A3B172D611981B0008C791C3126BF737@imp02mbx.t-mobile.co.uk> > as well a 'string' type. (Oh no! Not that thread again :-) > > /Jocke Well, as you mention it - I've been dabbling with XML recently and (apart from a growing view that for anything telecoms related this is quite the worst coding scheme I have had the misfortune to work with) I am running into the UNICODE issue. Lon Willets ucs contrib is great and all, but it would be awesome to have unicode strings in the core of Erlang (or at least unicode chars with the various conversions built in). Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth@REDACTED Fri Jan 17 15:12:33 2003 From: kenneth@REDACTED (Kenneth Lundin) Date: Fri, 17 Jan 2003 15:12:33 +0100 Subject: Timer server References: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6AE@esemont203.gbg.edt.ericsson.se> Message-ID: <3E280F51.7090609@erix.ericsson.se> Vlad Dumitrescu EAW wrote: > Hi, > > does anyone have had problems with the timer server, involving the timer_server process to grow larger and larger, until the whole VM crashes? It's in R7/R8. > > We observed such a behaviour, and are puzzled. The memory consumption graph looks something like this: > | > |---| | > | | | > |----| | |---| > | |---| > | > --| > > The trouble is that we can't reproduce it in the lab, so if anyone could provide a clue, we'd be very thankful. > > Best regards, > Vlad The timer_server (timer module) is in the process of beeing rewritten right now. The new implementation will use the timer BIFs (see the man page for the erlang module) as much as possible. The current implementation is inefficient (use the timer BIFs if you can) especially if there are many timers at the same time. There is a function which is non tail recursive which traverses the list of timers linearly each time a new timer is about to be inserted. This might be an explanation to your observation. Another thought is that there might be code in your system that inserts a huge amount of timers by mistake. Regards Kenneth Lundin (Product Manager for OTP) From Vlad.Dumitrescu@REDACTED Fri Jan 17 15:52:27 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Fri, 17 Jan 2003 15:52:27 +0100 Subject: Timer server Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6C0@esemont203.gbg.edt.ericsson.se> > The timer_server (timer module) is in the process of beeing rewritten > right now. The new implementation will use the timer BIFs > (see the man > page for the erlang module) as much as possible. > The current implementation is inefficient (use the timer BIFs if you > can) especially if there are many timers at the same time. > > Regards Kenneth Lundin (Product Manager for OTP) Thanks a lot! The timer BIFs accept only 32 bit arguments... In milliseconds, that's not a high upper limit. Will that change? regards, Vlad From jamesh@REDACTED Fri Jan 17 16:17:43 2003 From: jamesh@REDACTED (James Hague) Date: Fri, 17 Jan 2003 09:17:43 -0600 Subject: Structs Message-ID: > Now, Joe's structs look more promising, but we need to work > out what the syntax and semantics should really be, and make > sure that we don't replace records with something that will > be subject to the same discussions a few years from now. Agreed. It's very exciting, though, that this is being addressed, even if only at the discussion stage. From jocke@REDACTED Fri Jan 17 16:42:22 2003 From: jocke@REDACTED (Joakim G.) Date: Fri, 17 Jan 2003 16:42:22 +0100 Subject: Strings (was RE: Structs) References: <04D356A3B172D611981B0008C791C3126BF737@imp02mbx.t-mobile.co.uk> Message-ID: <3E28245E.6020809@bluetail.com> Sean Hinde wrote: > > as well a 'string' type. (Oh no! Not that thread again :-) > > > > /Jocke > > Well, as you mention it - I've been dabbling with XML recently and > (apart from a growing view that for anything telecoms related this is > quite the worst coding scheme I have had the misfortune to work with) I > am running into the UNICODE issue. > > Lon Willets ucs contrib is great and all, but it would be awesome to > have unicode strings in the core of Erlang (or at least unicode chars > with the various conversions built in). Like Java. A space effective string type would be nice. Unicode or not. The same for destructive assignment (A := 7). Almost joking. It would be bad indeed to be flamed to death. /Jocke From mikael.karlsson@REDACTED Fri Jan 17 18:51:24 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Fri, 17 Jan 2003 18:51:24 +0100 Subject: Structs (was RE: Record selectors) In-Reply-To: <20030116162856.7cc2a15c.cpressey@catseye.mb.ca> References: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6AB@esemont203.gbg.edt.ericsson.se> <20030116162856.7cc2a15c.cpressey@catseye.mb.ca> Message-ID: <200301171851.24134.mikael.karlsson@creado.com> Thursday 16 january 2003 23:28 Chris Pressey wrote: > On Wed, 15 Jan 2003 09:18:38 +0100 . > An example of this sort of 'use processes for *everything*' approach might > be a project I want to try sometime this year, that is, to write a digital > circuit simulator in Erlang. Instead of messing with nasty physics > equations, I think the problem could be modelled with one process per gate > (or chip). Each chip process would receive a message every time one of > it's pins changed state, so messages would essentially look like {N, M} > where N is the pin number and M is either rising_edge or falling_edge. > The process itself would take care of 'steady' state by tracking it every > time a new message came in, and would also produce new messages to send to > other chips wired to its output pins. > > Doing this with one process per truly concurrent unit should make it > simple (almost trivial) to implement - but the thought of doing it this > way with any language besides Erlang gives me shivers. Maybe Timber, derived from O'Haskell could be worth looking at? Erlang is really what I like for "production" code but I must confess that I do like the O'Haskell approach (were state is taken care of by object encapsulation, and records by Haskell typing, I think? :) http://www.cs.chalmers.se/~nordland/ohaskell/ O'Haskell is the purely functional language Haskell, conservatively extended with: - subtyping - monadic objects an object-oriented imperative language, enhanced with -parameteric polymorphism -automatic type inference a concurrent language, with -a reactive communication model -asynchronous and synchronous message-passing The author references both Erlang and Java in his thesis: http://www.cs.chalmers.se/~nordland/ohaskell/thesis.ps.gz I guess it is could be better to start with the the 4 page paper on Reactive Objects: http://www.cse.ogi.edu/~nordland/isorc.pdf I can not judge how it compares with Erlang regarding concurrency model etc., but I think it would be interesting to get comments from any Erlang linguist. Regards Mikael PS Use the CVS version if you want to test the O'Hugs interpreter, it is much later than the tarball. DS From Sean.Hinde@REDACTED Fri Jan 17 19:42:07 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Fri, 17 Jan 2003 18:42:07 -0000 Subject: Structs (was RE: Record selectors) Message-ID: <04D356A3B172D611981B0008C791C3126BF740@imp02mbx.t-mobile.co.uk> > O'Haskell is > the purely functional language Haskell, conservatively extended with: > - subtyping > - monadic objects > > an object-oriented imperative language, enhanced with > -parameteric polymorphism > -automatic type inference > > a concurrent language, with > -a reactive communication model > -asynchronous and synchronous message-passing > > The author references both Erlang and Java in his thesis: > http://www.cs.chalmers.se/~nordland/ohaskell/thesis.ps.gz > > I guess it is could be better to start with the the 4 page > paper on Reactive > Objects: http://www.cse.ogi.edu/~nordland/isorc.pdf > > I can not judge how it compares with Erlang regarding > concurrency model > etc., but I think it would be interesting to get comments > from any Erlang > linguist. Well, the comments to their version of the POTS program from the Erlang book suggest that they see the erlang ability to "selectively receive" to be merely a way of avoiding deadlock, and they avoid such nastiness by statically ensuring that all objects are capable of receiving all valid messages at all times. This ability to "leave some messages in the message queue until I have dealt with the ones I want to" is of course a very powerful part of Erlang.. I'll leave deeper analysis to the real language linguists. Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From etxuwig@REDACTED Fri Jan 17 23:50:01 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 17 Jan 2003 23:50:01 +0100 (MET) Subject: Structs (was RE: Record selectors) In-Reply-To: <04D356A3B172D611981B0008C791C3126BF740@imp02mbx.t-mobile.co.uk> Message-ID: On Fri, 17 Jan 2003, Sean Hinde wrote: >Well, the comments to their version of the POTS program >from the Erlang book suggest that they see the erlang >ability to "selectively receive" to be merely a way of >avoiding deadlock, and they avoid such nastiness by >statically ensuring that all objects are capable of >receiving all valid messages at all times. I would say that this is a big misunderstanding. Selective receive is not at all about that, and forcing all objects to have to deal with all messages as they come in drastically complicates your state machine programming. Erlang's selective receive -- being able to pattern-match on the entire message queue -- is perhaps not absolutely necessary (even though it is sometimes extremely valuable), but what you need to have for complex state machine programming is (a) the ability to stop and wait for a specific message, and (b) the ability to single out one or a few senders, buffering any other messages until later. (This might also be achieved by having separate channels.) Without this, you end up having to invent quasi states in your code and introducing timing dependencies that will cause nightmares in testing. Let's take the POTS example to illustrate getting_first_digit() -> receive {lim, onhook} -> lim:stop_tone(), idle(); {lim, {digit, Digit}} -> lim:stop_tone(), getting_number(Digit, number:analyse( Digit, number:valid_sequences())); ... end. getting_number(Number, {incomplete, ValidSeqs}) -> receive {lim, onhook} -> idle(); {lim, {digit, Digit}} -> getting_number(10 * Number + Digit, number:analyse( Digit, ValidSeqs)); ... end. The function lim:stop_tone() actually involves sending a message to the hardware and waiting for a reply (selective receive). If we don't have that ability, we need to handle a stop_tone_reply message in our state machine. Now, what if the next digit comes in before stop_tone_reply? We must now introduce a state (receiving a digit while waiting for stop_tone_reply), and we must process the digit (in most other states, we may happily ignore a pressed digit.) In the specification of the state machine, this is not necessary. It's a product of our programming model. And it's a timing-dependent state, so we will have difficulty provoking it on a real system. We can easily see that there is absolutely no dependency in real life between the response from our hardware and the pressing of a button on the caller's phone. The dependency exists only in our implementation. If we introduce distribution, timing dependencies change, and our code may start breaking because of untested timing-dependent states in our code. The original Erlang state machine is resistant to such problems because it handles events in a logically sound order. _That's_ why selective receive is necessary. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From erlang@REDACTED Sat Jan 18 17:00:05 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Sat, 18 Jan 2003 13:00:05 -0300 Subject: io:format memory problem Message-ID: <003901c2bf0a$af6623c0$1400a8c0@tdapi> Hello, While executing this program, the memory increases constantly. But, if I comment the lines "io:format(.)" it doesn't happen (the memory stabilizes). Is this behaviour correct? 1> example:start(1000). -module(example). -export([start/1, stop/0]). start(Cant) -> init_process(Cant), register(?MODULE, spawn_link(fun() -> loop() end)). stop() -> ?MODULE ! {stop}. init_process(0) -> ok; init_process(Cant) -> spawn_link(fun() -> proc() end), init_process(Cant - 1). proc() -> io:fwrite("In proc~n", []), receive after 4000 -> io:fwrite("TimeOut~n", []), proc() end. loop() -> receive {stop} -> io:format("Bye~n", []), ok end. Thanks, Bernardo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Sun Jan 19 00:58:55 2003 From: roger@REDACTED (Roger) Date: Sat, 18 Jan 2003 15:58:55 -0800 Subject: No subject Message-ID: <200301182358.PAA08176@amber.he.net> I had asked this on comp.lang.functional, and Ulf kindly pointed me to this email list. I have a problem getting distributed erlang working on my home network. I think I may be missing a step. Step 1: start epmd on both machines, Server and Client % ./epmd -d -daemon % ./epmd -names epmd: up and running on port 4369 with data: % Start erl on Server: % erl -sname Server -setcookie ABC Start erl on Client % erl -sname Client -setcookie ABC Check epmd: % ./epmd -names epmd: up and running on port 4369 with data: name Server at port 54143 I then compile the bank_client and bank_server erl examples. This works on the same local machine, but I cannot get it to work with the client running on one, and the server on another machine. Any ideas ? Thanks, -Roger From klacke@REDACTED Sun Jan 19 02:27:32 2003 From: klacke@REDACTED (Klacke) Date: Sun, 19 Jan 2003 02:27:32 +0100 Subject: your mail In-Reply-To: <200301182358.PAA08176@amber.he.net>; from roger@young-river.com on Sat, Jan 18, 2003 at 03:58:55PM -0800 References: <200301182358.PAA08176@amber.he.net> Message-ID: <20030119022732.B18259@bluetail.com> On Sat, Jan 18, 2003 at 03:58:55PM -0800, Roger wrote: > I had asked this on comp.lang.functional, and Ulf kindly pointed me to this email list. I have a problem getting distributed erlang working on my home network. I think I may be missing a step. > > Step 1: > > start epmd on both machines, Server and Client > > % ./epmd -d -daemon > % ./epmd -names > epmd: up and running on port 4369 with data: > % > > > Start erl on Server: > > % erl -sname Server -setcookie ABC > > Start erl on Client > > % erl -sname Client -setcookie ABC > > Check epmd: > % ./epmd -names > epmd: up and running on port 4369 with data: > name Server at port 54143 > > > > I then compile the bank_client and bank_server erl examples. This works on the same local machine, but I cannot get it to work with the client running on one, and the server on another machine. > > Any ideas ? sounds like a cookie problem. 1. Don't start epmd manually, it'l be started correctly for you if it isn't running. 2. Create a ~/.erlamg.cookie file with perms -r-------- in your HOME dir on both machines. 3. Check connectivity by calling, (a@REDACTED)1> rpc:call(a@REDACTED, erlang, nodes, []). Or any other Mod, Fun, ArgsList If that doesn't work and since it;s your home network, maybe you have a DNS lookup problem. Try by calling inet:gethostbyname("host1") on host2 ... and vice versa. /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From matthias@REDACTED Sun Jan 19 09:36:11 2003 From: matthias@REDACTED (Matthias Lang) Date: Sun, 19 Jan 2003 09:36:11 +0100 Subject: io:format memory problem In-Reply-To: <003901c2bf0a$af6623c0$1400a8c0@tdapi> References: <003901c2bf0a$af6623c0$1400a8c0@tdapi> Message-ID: <15914.25467.459236.888717@antilipe.corelatus.se> Inswitch Solutions - Erlang Evaluation writes: > Hello, > > While executing this program, the memory increases constantly. > But, if I comment the lines "io:format(.)" it doesn't happen (the > memory stabilizes). Is this behaviour correct? To make it reasonably easy for people to give you a sensible answer, you need to include a decent description of the problem. Attaching a short program which demonstrates the problem was a good start, but there's a lot missing, including: 1. How much memory do you expect the program to consume when started with an argument of 1000? 2. How much memory does it actually consume? 3. How long are you waiting before deciding whether memory use has stabilised or not? 4. How are you measuring memory use? 5. Which version of Erlang are you using? Which OS? In my case, the answers are: < 10M, < 7M, 30 minutes, 'top' and R8B/linux. I.e. I'm not seeing anything unexpected. Matthias From farzin_b23@REDACTED Sun Jan 19 12:39:43 2003 From: farzin_b23@REDACTED (Farzin_B23 SOORI) Date: Sun, 19 Jan 2003 11:39:43 +0000 Subject: Erland Paradign and OO paradigm! Message-ID: Dear sir/mdm I am the VoIP project manager in ITMC Corporations in IRAN. i have been so interested in your Erlang platform for developing application like Megaco. But i want to know if this platform is Functional based or Object Oriented based? Isn't it better to develope megaco application with OO based scheme? I asked this question based on megaco nature , i think it can be developed with OO idea , what do you think?why? thank you sincerely Bastani _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From svenolof@REDACTED Sun Jan 19 14:37:24 2003 From: svenolof@REDACTED (Sven-Olof Nystr|m) Date: Sun, 19 Jan 2003 14:37:24 +0100 Subject: Structs (was RE: Record selectors) In-Reply-To: References: <04D356A3B172D611981B0008C791C3126BF740@imp02mbx.t-mobile.co.uk> Message-ID: <15914.43540.628082.548532@harpo.it.uu.se> Ulf Wiger writes: > On Fri, 17 Jan 2003, Sean Hinde wrote: > > >Well, the comments to their version of the POTS program > >from the Erlang book suggest that they see the erlang > >ability to "selectively receive" to be merely a way of > >avoiding deadlock, and they avoid such nastiness by > >statically ensuring that all objects are capable of > >receiving all valid messages at all times. > > I would say that this is a big misunderstanding. > > Selective receive is not at all about that, and forcing all > objects to have to deal with all messages as they come in > drastically complicates your state machine programming. > > Erlang's selective receive -- being able to pattern-match on > the entire message queue -- is perhaps not absolutely > necessary (even though it is sometimes extremely valuable), > but what you need to have for complex state machine > programming is (a) the ability to stop and wait for a > specific message, and (b) the ability to single out one or a > few senders, buffering any other messages until later. > (This might also be achieved by having separate channels.) > Without this, you end up having to invent quasi states in > your code and introducing timing dependencies that will > cause nightmares in testing. > > Let's take the POTS example to illustrate > > getting_first_digit() -> > receive > {lim, onhook} -> > lim:stop_tone(), > idle(); > {lim, {digit, Digit}} -> > lim:stop_tone(), > getting_number(Digit, > number:analyse( > Digit, > number:valid_sequences())); > ... > end. > > getting_number(Number, {incomplete, ValidSeqs}) -> > receive > {lim, onhook} -> > idle(); > {lim, {digit, Digit}} -> > getting_number(10 * Number + Digit, > number:analyse( > Digit, > ValidSeqs)); > ... > end. > > The function lim:stop_tone() actually involves sending a > message to the hardware and waiting for a reply (selective > receive). If we don't have that ability, we need to handle a > stop_tone_reply message in our state machine. Now, what if > the next digit comes in before stop_tone_reply? We must now > introduce a state (receiving a digit while waiting for > stop_tone_reply), and we must process the digit (in most > other states, we may happily ignore a pressed digit.) > > In the specification of the state machine, this is not > necessary. It's a product of our programming model. And it's > a timing-dependent state, so we will have difficulty > provoking it on a real system. We can easily see that there > is absolutely no dependency in real life between the > response from our hardware and the pressing of a button on > the caller's phone. The dependency exists only in our > implementation. > > If we introduce distribution, timing dependencies change, > and our code may start breaking because of untested > timing-dependent states in our code. The original Erlang > state machine is resistant to such problems because it > handles events in a logically sound order. > > _That's_ why selective receive is necessary. I suppose you have something like this in mind: (in module lim) stop_tone() -> ! {stop, self()}, receive {ok, } -> true after ... end. Implementing this without selective (matching) receive would require the ability to create a new channel, something like this: stop_tone() -> Ch = new_channel() % Create a new channel ! {stop, Ch}, receive(Ch) of % Read message from channel Ch ok -> true after ... end. As far as I can see, the second solution introduces no new complications in the state machine nor any new dependencies. I don't know anything about the Haskell solution, but I wouldn't be surprised if they are doing something similar. It would be interesting to see examples where matching receive couldn't be replaced by the creation of a temporary channel. It seems to me that matching receive is just a way to compensate for Erlang's inability to create temporary channels... yours, Sven-Olof Nystr?m From milanvuk@REDACTED Sun Jan 19 16:44:39 2003 From: milanvuk@REDACTED (Milan Vukoslavcevic) Date: Sun, 19 Jan 2003 16:44:39 +0100 Subject: MTP simulator? Message-ID: <008101c2bfd4$8f5f3ab0$4200a8c0@telekom.ftn.ns.ac.yu> Since I am interested in AXE 10 switch I found on web that: Netsim is a network simulator sold by Ericsson/Hewlit packard. NETSim simulates the operations and maintenance behavior of AXE Network Elements (AXE is a very large switching system product). NETSim simulates commands, printouts, alarms and files transfers. NETSim supports the Message Transfer Protocol (MTP) and communicates through a X.25 protocol. If this is true where I can find list of command line parameter(commands) used in MTP protocol ? Thanks in advance, Best regards, postgraduate student of telecommunication, Milan Vukoslavcevic University of Novi Sad http://www.ftn.ns.ac.yu/ Yugoslavia -------------- next part -------------- An HTML attachment was scrubbed... URL: From etxuwig@REDACTED Sun Jan 19 19:28:11 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Sun, 19 Jan 2003 19:28:11 +0100 (MET) Subject: Structs (was RE: Record selectors) In-Reply-To: <15914.43540.628082.548532@harpo.it.uu.se> Message-ID: On Sun, 19 Jan 2003, Sven-Olof Nystr|m wrote: >Ulf Wiger writes: > > Erlang's selective receive -- being able to pattern-match on > > the entire message queue -- is perhaps not absolutely > > necessary (even though it is sometimes extremely valuable), > > but what you need to have for complex state machine > > programming is (a) the ability to stop and wait for a > > specific message, and (b) the ability to single out one or a > > few senders, buffering any other messages until later. > > (This might also be achieved by having separate channels.) [snipped] >I suppose you have something like this in mind: > >(in module lim) > >stop_tone() -> > ! {stop, self()}, > receive > {ok, } -> > true > after ... > end. Yes. >Implementing this without selective (matching) receive >would require the ability to create a new channel, >something like this: > >stop_tone() -> > Ch = new_channel() % Create a new channel > ! {stop, Ch}, > receive(Ch) of % Read message from channel Ch > ok -> > true > after ... > end. Yes, except I would still call it selective receive. >As far as I can see, the second solution introduces no new >complications in the state machine nor any new >dependencies. I don't know anything about the Haskell >solution, but I wouldn't be surprised if they are doing >something similar. They might well be doing it like that (it was not obvious to me how they do it.) I agree that being able to create temporary channels solves the lim:stop_tone() problem nicely. This is what I had in mind when I wrote: > > (This might also be achieved by having separate channels.) To implement it without introducing additional complexity to your state machine, you need to be able to (a) block, and (b) single out a specific message/sender. There are other issues when comparing message-oriented programming a'la the OHaskell example and state-oriented programming a'la Erlang. One obvious advantage to the latter is that all the protocol specifications I've seen are described in a state-oriented fashion. It is easier to follow such a description/program. >It would be interesting to see examples where matching >receive couldn't be replaced by the creation of a temporary >channel. > >It seems to me that matching receive is just a way to >compensate for Erlang's inability to create temporary >channels... I can't say whether Erlang ended up with pattern matching on one message queue because Joe, Robert, Mike et al found it too difficult to figure out how to create temporary channels. (: I think a single message queue and pattern matching go well in hand with state-oriented programming. Again, the POTS example: speech(OtherPid) -> receive {lim, onhook} -> lim:disconnect_from(OtherPid), OtherPid ! {self(), cancel}, idle(); {lim, {digit, _Digit}} -> speech(OtherPid); {OtherPid, cancel} -> wait_on_hook(false); {Pid, request_connection} -> Pid ! {self(), reject}, speech(OtherPid); Other -> speech(OtherPid) end. Here, we react to messages from 4 different senders (consuming and ignoring any message from anyone else). One could of course imagine an equally concise syntax that scanned separate channels, pattern-matching over them, blocking if desired and necessary. I find very little wrong with the notion of having a single message queue. BTW, I read the OHaskell example/comments. The reference to resolving deadlock was something else, and I think they read too much into the implementation of the seize message in the Erlang POTS example. First of all, it's not a deadlock situation: make_call_to_B(Address, B_Pid, B_Address) -> receive seized -> ...; rejected -> ...; {seize, Pid} -> ... after 1000 -> ... wait_on_hook(Address, fault) end. The concurrently incoming 'seize' message is from another Pid -- not B_Pid. One could argue the program should also handle other important messages (e.g. onhook) in this state, and in the POTS control program that is the suggested solution to the final exercise in the Basic Erlang Course, the 'calling_B' state does handle other message, like for example onhook. This is not to say that the version in the book is necessarily unsafe. It will handle a non-normal situation and eventually return to idle. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From per@REDACTED Sun Jan 19 19:53:58 2003 From: per@REDACTED (Per Bergqvist) Date: Sun, 19 Jan 2003 19:53:58 +0100 Subject: MTP =?iso-8859-1?q?simulator=3F?= In-Reply-To: <008101c2bfd4$8f5f3ab0$4200a8c0@telekom.ftn.ns.ac.yu> Message-ID: <200301191853.h0JIrww14325@hunden.levonline.com> Since you will probably have a lot of answers telling you that MTP is defined in ITU-T Q.701-Q.709 recommendations I tell everybody that the MTP you are looking is another MTP used by the IOG. You should be able to find the interworking description in the AXE-10 documentation. If you don't have it this list is not the right place to ask for it ... /Per > > Since I am interested in AXE 10 switch I found on web that: > > Netsim is a network simulator sold by Ericsson/Hewlit packard. NETSim simulates the operations and maintenance behavior of AXE Network Elements (AXE is a very large switching system product). NETSim simulates commands, printouts, alarms and files transfers. NETSim supports the Message Transfer Protocol (MTP) and communicates through a X.25 protocol. > > If this is true where I can find list of command line parameter(commands) used in MTP protocol ? > > Thanks in advance, > > Best regards, > postgraduate student of telecommunication, > Milan Vukoslavcevic > University of Novi Sad > http://www.ftn.ns.ac.yu/ > Yugoslavia > > > ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From bjarne@REDACTED Sun Jan 19 22:00:03 2003 From: bjarne@REDACTED (Bjarne Däcker) Date: Sun, 19 Jan 2003 22:00:03 +0100 Subject: MTP simulator? References: <008101c2bfd4$8f5f3ab0$4200a8c0@telekom.ftn.ns.ac.yu> Message-ID: <3E2B11D3.3646C4EF@erix.ericsson.se> Hello Milan Vukoslavcevic wrote: > Since I am interested in AXE 10 switch I found on web that: Netsim > is a network simulator sold by Ericsson/Hewlit packard. NETSim > simulates the operations and maintenance behavior of AXE Network > Elements (AXE is a very large switching system product). NETSim > simulates commands, printouts, alarms and files transfers. NETSim > supports the Message Transfer Protocol (MTP) and communicates through > a X.25 protocol. There was a paper on NetSIM presented at the Erlang/OTP User Conference in 2000. http://www.erlang.se/euc/00/ Best regards Bjarne -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.virding@REDACTED Sun Jan 19 23:10:34 2003 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 19 Jan 2003 23:10:34 +0100 Subject: Structs (was RE: Record selectors) References: Message-ID: <3E2B225A.7070609@telia.com> Ulf Wiger wrote: > Then, one could create a named struct just like a new > record: > > C = ~guru{name = "robert", likes="water rockets"}. > Yes, I do actually. They're alot of fun. Joe has the pictures somewhere. :-) Robert From mikael.karlsson@REDACTED Sun Jan 19 23:49:57 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Sun, 19 Jan 2003 23:49:57 +0100 Subject: Structs (was RE: Record selectors) In-Reply-To: References: Message-ID: <200301192349.58007.mikael.karlsson@creado.com> s?ndag 19 januari 2003 19:28 skrev Ulf Wiger: > On Sun, 19 Jan 2003, Sven-Olof Nystr|m wrote: . . > >Implementing this without selective (matching) receive > >would require the ability to create a new channel, > >something like this: > > > >stop_tone() -> > > Ch = new_channel() % Create a new channel > > ! {stop, Ch}, > > receive(Ch) of % Read message from channel Ch > > ok -> > > true > > after ... > > end. > > Yes, except I would still call it selective receive. > > >As far as I can see, the second solution introduces no new > >complications in the state machine nor any new > >dependencies. I don't know anything about the Haskell > >solution, but I wouldn't be surprised if they are doing > >something similar. > > They might well be doing it like that (it was not obvious to > me how they do it.) I agree that being able to create > temporary channels solves the lim:stop_tone() problem > Well, actually it seems they are "cheating" and just send an asynchrounous stop_tone message without expecting any return and then immediately set the state to Idle: .... on_hook' = do if null nr then tele_os.stop_tone myaddr state := idle ... Timber ( or O'Haskell ) actually have both asynchronous (Actions) and synchronous (Requests) methods, so making stop_tone a synchronous request would make it more similar to the Erlang way. The synchronous calls I have seen seem only to access and return internal state variables though. I guess in order to avoid deadlock :-). The normal way when things take time seems to be to install callbacks. The point about selective receive from the message queue is quite a good one, but if you want to simulate digital circuits which was Chris intention, I think that reactive objects are quite appropriate. It is quite difficult to do a selective receive of whathever the state changes on the pins are. I just finish up with a small Queue example from the O'Haskell distro , were you can see their solution on records, destructive assignment (yes, you are allowed to do it on state variables), encapsulation, message passing and typing. And then I'll resume only asking questions about Erlang :-) Thanks Mikael --------------------------- module Queue where record Queue a = insert :: a -> Action announce :: (a -> Action) -> Action queue = template packets := [] servers := [] in record insert p = action case servers of [] -> do packets := packets ++ [p] s:ss -> do s p; servers := ss announce s = action case packets of [] -> do servers := servers ++ [s] p:ps -> do s p; packets := ps From robert.virding@REDACTED Mon Jan 20 00:05:37 2003 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 20 Jan 2003 00:05:37 +0100 Subject: Structs - thoughts on implementation References: <20030117035715.GA22863@icarus.itsc.adfa.edu.au> Message-ID: <3E2B2F41.5050204@telia.com> Lawrie Brown wrote: > Hi Joe & everyone > > On Tue, Jan 14, 2003 at 10:41:44AM +0100, Joe Armstrong wrote: >... > Hence Ulf's example above would be represented by: > > C = {guru, dynamic_struct, likes, "water rockets", name, "robert"} > > a statement like: D = ~C{likes="motorbikes"} results in: > > D = {guru, dynamic_struct, likes, "motorbikes", name, "robert"} > > and a statement like: E = ~C{hates="skiing"} results in: > > E = {guru, dynamic_struct, hates, "skiing", likes, "water rockets", name, "robert"} > > I think this has the nice advantage of being dynamic, self-documenting, > and compatible with existing Erlang types (& distribution protocol). Actually I like skiing. :-) I wonder if this will be fast enough. If we are really serious about structs then we should them as a replacement for records sometime in the future, and this would be logN time with at least one atom comparison. When we introduced records users were very worried that they would be slower than using records straight off. It took some convincing. How would you handle anonymous structs? > > In terms of run-time support, I lean towards extending/overloading some of > the tuple BIFs thus: > > + element(Var, Type, Tag) - checks Var is a struct of specified Type, > and returns the Value associated with Tag (or undefined), a guard > > + setelement(Var, Type, Tag, Value) - checks Var is a struct of specified > Type, and either updates the value associated with Tag if present > or (provided it s dynamic struct) extends the struct to support > the new Tag & Value inserted into the appropriate position > > + size(Var, Type) - checks Var is a struct of specified Type, and returns > the number of fields in it (its arity) > > + struct(Var, Type) - a recognizer for a struct of specified Type (cf record) > > And whilst the stored form would be basically a tuple, it'd be easy enough to > add a flag to say it was created as a struct to improve efficiency. > > And of course you need the compiler to recognise the new syntax. Also need > some way of saying the you want a static struct (with tags fixed upon > creation) vs a dynamic one. > > Comments???? It would be an relatively easy way of properly introducing structs into the language, not just as pass to the compiler. I am a bit wary of overloading BIFs too much. I know I am guilty of doing it in the past but it was probably wrong in many cases. Robert From Lawrie.Brown@REDACTED Mon Jan 20 00:51:20 2003 From: Lawrie.Brown@REDACTED (Lawrie Brown) Date: Mon, 20 Jan 2003 10:51:20 +1100 Subject: Structs - thoughts on implementation In-Reply-To: <3E2B2F41.5050204@telia.com> References: <20030117035715.GA22863@icarus.itsc.adfa.edu.au> <3E2B2F41.5050204@telia.com> Message-ID: <20030119235120.GA13800@icarus.itsc.adfa.edu.au> Hi Robert > Lawrie Brown wrote: > >On Tue, Jan 14, 2003 at 10:41:44AM +0100, Joe Armstrong wrote: > >and a statement like: E = ~C{hates="skiing"} results in: > > E = {guru, dynamic_struct, hates, "skiing", likes, "water rockets", > > name, "robert"} > Actually I like skiing. :-) ... Sorry - first thing off the top of my head ;-) > I wonder if this will be fast enough. If we are really serious about > structs then we should them as a replacement for records sometime in the > future, and this would be logN time with at least one atom comparison. > When we introduced records users were very worried that they would be > slower than using records straight off. It took some convincing. I'm not disagreeing with any of the above, but frankly I can't think of any way to allow dynamically varying structures at run-time without having some tradeoff like the above. However for my 'static_struct' variant, if you used a struct meta-command as someone (sorry forgot who) suggested, something perhaps like (haven't thought this one out fully yet): -struct(guru, static_struct, {hates, likes, name}). you could then have the compiler optimise to use fixed offsets into the tuple for any constant field references. You could also extend the above syntax in some manner to provide for default field values for those not explicitly specified in the assignment. I also liked the idea of some type of struct import at runtime (perhaps in the user attribute table or similar for a module), but you'd then still have to have some sort of runtime initialisation stage to cache the offsets used. My inital thoughts on how ... you'd have the compiler build a table that for each struct used in the module, lists all field names used along with offset to use when known (say 0 default), and the initial field value if defined. Then at runtime, when the module is loaded you also have to load any module it imports struct info from, and have the code check to see if the struct is static, and if so fill in the offsets to use for each of the field names used in this module. And also fill in the defaults regardless. At this point you can also check that the field names used if its static, and throw an error if they don't match (as in the fields used for any given struct in a module must be a subset of all fields defined by the import, witht eh rest taking their default values). Any code in the module that needs to access a struct field would then just access the relevant entry in this table (directly if its a constant ref eg ~C{likes="motorbikes"}) and either use the saved offset, or realise it must do a search. If its a dynamic struct, then you're forced to do a runtime search for the field. > How would you handle anonymous structs? The same as I think Joe suggested in one of his emails - just use a reserved name tag eg anonymous or perhaps [] (which was I think Joe's suggestion), which would be treated specially, and explicitly flag that no match on the record name was required. And you might want alternate forms of the BIFs below (or whatever they evolve into) that don't specify the structure name explicitly, which then implies anonymous (and indeed would be then be essentially identical to the existing tuple BIFs just with atom instead of numeric field identifiers). > >In terms of run-time support, I lean towards extending/overloading some of > >the tuple BIFs thus: ... > > + element(Var, Type, Tag) - checks Var is a struct of specified Type, ... > > + setelement(Var, Type, Tag, Value) - checks Var is a struct of specified ... > > + size(Var, Type) - checks Var is a struct of specified Type, and returns ... > > + struct(Var, Type) - a recognizer for a struct of specified Type (cf ... > It would be an relatively easy way of properly introducing structs into > the language, not just as pass to the compiler. I am a bit wary of > overloading BIFs too much. I know I am guilty of doing it in the past > but it was probably wrong in many cases. Hmmm - I must admit that within reason, I actually rather like overloading. When the meaning is essentially similar it saves inventing multiple nearly identical names just to satisfy a fetish that every name must be distinct. And in the specific cases here, to me the intent of the BIFs is essentially the same - eg. get/set a field in "collection" data type (vis tuple or struct) etc. Overloading feels rather natural and eases the learning load. Cheers Lawrie ------------------------------------ <*> ------------------------------------ Post: Dr Lawrie Brown, Computer Science, UNSW@REDACTED, Canberra 2600 Australia Phone: 02 6268 8816 Fax: 02 6268 8581 Web: http://www.adfa.edu.au/~lpb/ From roger@REDACTED Mon Jan 20 01:47:49 2003 From: roger@REDACTED (roger) Date: Sun, 19 Jan 2003 16:47:49 -0800 Subject: Erland Paradign and OO paradigm! In-Reply-To: Message-ID: Hi, this is answered by the FAQ: 10.9.4. Erlang should be object oriented People coming to Erlang from object-oriented languages sometimes spend a while trying to write programs in an object-oriented style in Erlang before "seeing the light" and giving up. Several papers have been published about how to "do OO in Erlang", including a chapter in the Erlang book. A common conservative position is to say that processes, asynchronous messages, functions and modules provide the same ability to structure systems as do threads, classes, methods, inheritance and aggregation. An aggressive position is to say that OO is just snake oil, that inheritance is error prone and that any system which doesn't model concurrent problems with concurrency in the program is defective. Taking this position in newsgroups tends to trigger a flamewar. This article is one of the highlights of such a flamewar (follow the thread to read the whole saga). On Sunday, January 19, 2003, at 03:39 AM, Farzin_B23 SOORI wrote: > > Dear sir/mdm > I am the VoIP project manager in ITMC Corporations in IRAN. > i have been so interested in your Erlang platform for developing > application like Megaco. > But i want to know if this platform is Functional based > or Object Oriented based? Isn't it better to develope megaco > application with OO based scheme? > I asked this question based on megaco nature , i think > it can be developed with OO idea , what do you think?why? > thank you > sincerely > Bastani > > > > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1904 bytes Desc: not available URL: From DANIESC.SCHUTTE@REDACTED Mon Jan 20 06:17:02 2003 From: DANIESC.SCHUTTE@REDACTED (DANIESC SCHUTTE) Date: Mon, 20 Jan 2003 07:17:02 +0200 Subject: Erlang OTP 9 Install on Solaris x86 Message-ID: Morning all, I would like to enquire if there are any special "instructions" for compilation of Erlang OTP R9B on a Solaris 8 x86 machine. When we try it - the make terminates with the following - any suggestions (to all those who reply and help - thanks in advance - we aprreciate it, as I think this is one of the languages with the best support groups on the planet): gcc -g -O2 -I/usr/local/erlang/otp_src_R9B-0/erts/i386-pc-solaris2.8 -DINSTRUME NT -DHAVE_CONFIG_H -Wall -DHIPE_ARCHITECTURE=x86 -Ibeam -Isys/unix -Ii386-pc-so laris2.8 -Izlib -Ihipe -c hipe/hipe_x86_glue.S -o /usr/local/erlang/otp_src_R9B- 0/erts/obj.instr.beam/i386-pc-solaris2.8/hipe_x86_glue.o Assembler: "/var/tmp/ccrswnA8.s", line 1 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 1 : Syntax error "/var/tmp/ccrswnA8.s", line 6 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 6 : Syntax error "/var/tmp/ccrswnA8.s", line 82 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 82 : Syntax error "/var/tmp/ccrswnA8.s", line 84 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 84 : Syntax error "/var/tmp/ccrswnA8.s", line 178 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 178 : Syntax error "/var/tmp/ccrswnA8.s", line 181 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 181 : Syntax error "/var/tmp/ccrswnA8.s", line 210 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 210 : Syntax error "/var/tmp/ccrswnA8.s", line 214 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 214 : Syntax error "/var/tmp/ccrswnA8.s", line 217 : Syntax error "/var/tmp/ccrswnA8.s", line 224 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 224 : Syntax error "/var/tmp/ccrswnA8.s", line 224 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 225 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 225 : Syntax error "/var/tmp/ccrswnA8.s", line 225 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 248 : Syntax error "/var/tmp/ccrswnA8.s", line 259 : Syntax error "/var/tmp/ccrswnA8.s", line 261 : Syntax error "/var/tmp/ccrswnA8.s", line 277 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 277 : Syntax error "/var/tmp/ccrswnA8.s", line 277 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 301 : Illegal mnemonic "/var/tmp/ccrswnA8.s", line 301 : Syntax error Too many errors - Goodbye gmake[2]: *** [/usr/local/erlang/otp_src_R9B-0/erts/obj.instr.beam/i386-pc-solar is2.8/hipe_x86_glue.o] Error 1 gmake[2]: Leaving directory `/usr/local/erlang/otp_src_R9B-0/erts/emulator' gmake[1]: *** [instr] Error 2 gmake[1]: Leaving directory `/usr/local/erlang/otp_src_R9B-0/erts/emulator' *** Error code 2 make: Fatal error: Command failed for target `emulator.instr' ?--------------------------------------------------- regards Daniel Schutte Danie Schutte Phone: +27 - 11 - 203 - 1613 Mobile: 084-468-3138 e-Mail: Daniesc@REDACTED ##################################################################################### 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 and copies. ##################################################################################### From hal@REDACTED Mon Jan 20 07:15:45 2003 From: hal@REDACTED (Hal Snyder) Date: Mon, 20 Jan 2003 00:15:45 -0600 Subject: Erlang OTP 9 Install on Solaris x86 In-Reply-To: ("DANIESC SCHUTTE"'s message of "Mon, 20 Jan 2003 07:17:02 +0200") References: Message-ID: <878yxgs5wu.fsf@ghidra.vail> "DANIESC SCHUTTE" writes: > I would like to enquire if there are any special "instructions" for > compilation of Erlang OTP R9B on a Solaris 8 x86 machine. When we > try it - the make terminates with the following - any suggestions > (to all those who reply and help - thanks in advance - we aprreciate > it, as I think this is one of the languages with the best support > groups on the planet): > > gcc -g -O2 -I/usr/local/erlang/otp_src_R9B-0/erts/i386-pc-solaris2.8 > -DINSTRUME NT -DHAVE_CONFIG_H -Wall -DHIPE_ARCHITECTURE=x86 -Ibeam > -Isys/unix -Ii386-pc-so laris2.8 -Izlib -Ihipe -c > hipe/hipe_x86_glue.S -o /usr/local/erlang/otp_src_R9B- > 0/erts/obj.instr.beam/i386-pc-solaris2.8/hipe_x86_glue.o Assembler: > "/var/tmp/ccrswnA8.s", line 1 : Illegal mnemonic Don't turn on hipe, or else, use custom gcc: http://www.erlang.org/ml-archive/erlang-questions/200110/msg00201.html We do ...configure --disable-hipe ... and use unmodified gcc. We usually also install openssl-0.9.6h as well as tcl8.4.1 and tk8.4.1 before installing OTP R9B on i386 Solaris 8. From lennart.ohman@REDACTED Mon Jan 20 09:38:34 2003 From: lennart.ohman@REDACTED (Lennart =?iso-8859-1?Q?=D6hman?=) Date: Mon, 20 Jan 2003 09:38:34 +0100 Subject: Erland Paradign and OO paradigm! References: Message-ID: <3E2BB58A.E44B4CA1@st.se> You may also like to watch Joe Armstrong's (one of the creators of the programming language Erlang) talk he gave at MIT in November 2002. In his talk he speaks about that Erlang actually is about 'Concurrent Oriented Programming' rather than functional programming (though Erlang of course is a functional programming language). The video and his slides can be found at http://ll2.ai.mit.edu/ (click on the morning session to get the video. Joe is on first after the introduction). Best Regards, Lennart Farzin_B23 SOORI wrote: > > Dear sir/mdm > I am the VoIP project manager in ITMC Corporations in IRAN. > i have been so interested in your Erlang platform for developing application > like Megaco. > But i want to know if this platform is Functional based > or Object Oriented based? Isn't it better to develope megaco application > with OO based scheme? > I asked this question based on megaco nature , i think > it can be developed with OO idea , what do you think?why? > thank you > sincerely > Bastani > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus ------------------------------------------------------------- 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 kenneth@REDACTED Mon Jan 20 09:56:05 2003 From: kenneth@REDACTED (Kenneth Lundin) Date: Mon, 20 Jan 2003 09:56:05 +0100 Subject: Timer server References: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6C0@esemont203.gbg.edt.ericsson.se> Message-ID: <3E2BB9A5.8080508@erix.ericsson.se> > > Thanks a lot! > > The timer BIFs accept only 32 bit arguments... In milliseconds, that's not a high upper limit. Will that change? > > regards, > Vlad > We have no plans to accept bigger input than 32 bit to the timer BIFs. At least not in the 32 bit verion of the Erlang VM. The new timer module will continue to support bigger values just like the old one. It will do this by dividing a long timeout into several shorter timeouts that the timer BIFs can handle. With 32 bit you can represent 1193 hours and I think that is quite a long time for a timeout. To set a timer for something to happen a specific time on a specific date I think should be handled in a different way than by just calculating the difference from now and then set a timer on that. This could then go wrong if the time is adjusted for some reason (e.g daylight savings ). In those cases I think it is necessary to check against local time with a suitable periodicity. The accuracy of a timer on a specific time and date need probably not be on the millisecond level either. Regards Kenneth Lundin (Product Manager Erlang/OTP) -- From etxuwig@REDACTED Mon Jan 20 10:44:35 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 20 Jan 2003 10:44:35 +0100 (MET) Subject: Timer server In-Reply-To: <3E2BB9A5.8080508@erix.ericsson.se> Message-ID: On Mon, 20 Jan 2003, Kenneth Lundin wrote: >With 32 bit you can represent 1193 hours and I think that >is quite a long time for a timeout. To set a timer for >something to happen a specific time on a specific date I >think should be handled in a different way than by just >calculating the difference from now and then set a timer on >that. This could then go wrong if the time is adjusted for >some reason (e.g daylight savings ). In those cases I think >it is necessary to check against local time with a suitable >periodicity. > >The accuracy of a timer on a specific time and date need >probably not be on the millisecond level either. I fully agree. One may disagree regarding what would be "suitable periodicity". I know we once had date-time timers that would sleep for 24 hours at a time. Personally, I think 15-30 minutes, or even shorter, would be perfectly OK as well. Compared to the amount of work required to re-calculate the timer, 15 minutes is an eternity. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From vlad_dumitrescu@REDACTED Mon Jan 20 10:59:29 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Mon, 20 Jan 2003 10:59:29 +0100 Subject: Timer server Message-ID: >We have no plans to accept bigger input than 32 bit to the timer BIFs. >At least not in the 32 bit verion of the Erlang VM. >The new timer module will continue to support bigger values just like the >old one. It will do this by dividing a long timeout into several shorter >timeouts that the timer BIFs can handle. As long as it's transparently done, it's okay. You are right of course that such long timeouts should not be used, but sometimes one has to deal with older versions and there's no time to rewrite them... I think everyone can relat to that :-) regards, Vlad _________________________________________________________________ Hela veckans v?der http://www.msn.se/vader From etxuwig@REDACTED Mon Jan 20 11:26:33 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 20 Jan 2003 11:26:33 +0100 (MET) Subject: O'Haskell (was Re: Structs (was RE: Record selectors)) In-Reply-To: <200301192349.58007.mikael.karlsson@creado.com> Message-ID: On Sun, 19 Jan 2003, Mikael Karlsson wrote: >Well, >actually it seems they are "cheating" and just send an >asynchrounous stop_tone message without expecting any >return and then immediately set the state to Idle: >.... > on_hook' = do > if null nr then > tele_os.stop_tone myaddr > state := idle >... >Timber ( or O'Haskell ) actually have both asynchronous >(Actions) and synchronous (Requests) methods, so making >stop_tone a synchronous request would make it more similar >to the Erlang way. The synchronous calls I have seen seem >only to access and return internal state variables though. >I guess in order to avoid deadlock :-). The normal way when >things take time seems to be to install callbacks. ... and this is where things start falling apart. Complexity rises enormously in your application if you cannot avoid this. Some form of selective receive is required for the model to remain stable, I think. >The point about selective receive from the message queue is >quite a good one, but if you want to simulate digital >circuits which was Chris intention, I think that reactive >objects are quite appropriate. It is quite difficult to do >a selective receive of whathever the state changes on the >pins are. If anyone was wondering why I was so trigger-happy on this particular POTS-issue, I can reveal that I'm actually trying to do some syntax-neutral comparisons between different ways of programming the POTS example. One of my implementations (which actually works too) is fairly similar to the "reactive objects" idea: First, an event loop: event_loop(M, S) -> receive {From, {Event, Arg}} -> S1 = M:Event(From, Arg, S), event_loop(M, S1); {From, Event} when atom(Event) -> S1 = M:Event(From, S), event_loop(M, S1) end. Then, the actual control logic: -module(control). % asynch_0 (asynch model, blocking hardware API) -compile(export_all). -record(s, {state = idle}). start() -> asynch_main:event_loop(?MODULE, #s{}). offhook(lim, #s{state = idle} = S) -> lim:start_tone(dial), S#s{state = getting_first_digit}; offhook(lim, #s{state = {ringing_B_side, PidA}} = S) -> lim:stop_ringing(), PidA ! {self(), connect}, S#s{state = {speech, PidA}}; offhook(From, S) -> io:format("Got unknown message in ~p: ~p~n", [S#s.state, {From, offhook}]), S. ... and so on. It turns out that this implementation is a bit shorter than the "original", and does seem to have some advantages. (My subjective opinion is that it's harder to follow, but this may be in part because I've been corrupted by Erlang for so long.) Note, however, the comment "blocking hardware API". I'm cheating, and pretending that I can control the hardware easily, without re-writing my state machine. The big issues are: - Can I be sure that the components I use from my state machine are always non-blocking and deterministic? - Am I allowed to block? If, say, I handle all my calls in one erlang process, I cannot block the process an wait for a message from another node or some hardware. Then, I must break up the calls into asynchronous messages, and the complexity of my state machine quickly grows into unmanageable proportions. Try one non-blocking component, then add another one, and see what happens. - Can I do selective receive (assuming I can block)? If I can, my state machine can remain stable even if it uses components with blocking semantics. I don't think the issue is really state-oriented vs message-oriented programming. There are a few core tenets of soft real-time programming that you simply have to get right. Erlang does it pretty well. Most languages don't, and I think many language designers haven't really thought about what those core tenets really are. I note that the comments to the O'Haskell POTS example claimed that objects in telecom applications must be reactive. This is only partly true. Tele-/Datacom Signaling control differs from e.g. control of anti-lock breaks in that it is often no disaster if a thread remains partially unresponsive for some milliseconds, or even more. The specifications talk of e.g. being able to serve 95% of all calls within certain time limits, but beyond that, it's even OK to drop some calls now and then. This would be less than satisfactory for an anti-lock break system. This is an important difference between "soft" real-time and "hard" real-time. Programming of hard real-time mission-critical systems must be an amazingly difficult discipline (I've never done it), but some of the non-negotiable aspects of such programming simply do not hold as much for "soft" real-time, and this can be used to greatly simplify the programming model. /Uffe (*) We once ran a stress test on an unused AXD301 field system. AFAIR, pushing through 140 million calls over a long weekend, I believe we dropped some 1 or 2 ppm of the calls. This is pretty cool for telephony, but if we had built a car and received these figures from a break test, we'd probably recall the model. -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From Sean.Hinde@REDACTED Mon Jan 20 13:41:47 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Mon, 20 Jan 2003 12:41:47 -0000 Subject: Structs (was RE: Record selectors) Message-ID: I'm not sure if all of this has been suggested somewhere.. and I don't have time to re-read the whole thread, but I've been thinking of how to help the situation where people would define a struct locally in two modules (with perhaps an erroneous difference in definition), and send a message containing that struct: -module(a). -struct(msg, {header, content}). loop() -> receive ~msg{header = H, content = C} end. -module(b). -struct(msg, {header, conten}). send() -> a ! ~msg{header = <<1,2,3>>, conten = <<4,5,6>>}. My proposal is that structs should be made strictly local or external - just like function calls. So: * Sending a locally defined struct to another module with the "same" struct also locally defined would *never* match (I see some implementation where the module name is encoded into the opaque struct type). * In order to match an externally defined struct it would need to be imported or fully qualified: -module(a). -export_struct([msg/2]). -struct(msg, {header, content}). loop() -> receive ~msg{header = H, content = C} end. -module(b). -import_struct(a, [msg/2]). send() -> a ! ~msg{header = <<1,2,3>>, content = <<4,5,6>>}, a ! ~a:msg{header = <<1,2,3>>, content = <<4,5,7>>}. Overlapping named locally defined structs would behave in the same way as a name clash for modules (dunno which way round, never used import!) but generate a compiler warning. The problem of code replacement is then no worse than for modules. This would give tools like xref all the help they needed to know which struct was being referred to at any time. And I would dump anonymous structs (sorry Joe). I think it would then be OK to reduce runtime checking to the minimum needed to ensure emulator safety (bounds checking). Thoughts? Particularly about the locally defined structs never matching between modules (as I do recall seeing everything else before.. Aternatively we could move wholesale to UBF :-) Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke@REDACTED Mon Jan 20 14:40:04 2003 From: luke@REDACTED (Luke Gorrie) Date: 20 Jan 2003 14:40:04 +0100 Subject: Structs (was RE: Record selectors) In-Reply-To: <20030116162856.7cc2a15c.cpressey@catseye.mb.ca> References: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6AB@esemont203.gbg.edt.ericsson.se> <20030116162856.7cc2a15c.cpressey@catseye.mb.ca> Message-ID: Chris Pressey writes: > An example of this sort of 'use processes for *everything*' approach might > be a project I want to try sometime this year, that is, to write a digital > circuit simulator in Erlang. Instead of messing with nasty physics > equations, I think the problem could be modelled with one process per gate > (or chip). Each chip process would receive a message every time one of > it's pins changed state, so messages would essentially look like {N, M} > where N is the pin number and M is either rising_edge or falling_edge. > The process itself would take care of 'steady' state by tracking it every > time a new message came in, and would also produce new messages to send to > other chips wired to its output pins. > > Doing this with one process per truly concurrent unit should make it > simple (almost trivial) to implement - but the thought of doing it this > way with any language besides Erlang gives me shivers. Have you seen the lovely Scheme one in SICP? http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-22.html#%_sec_3.3.4 Along with the next little section (3.3.5) that's got to be one of the coolest things I've seen. Cheers, Luke From svenolof@REDACTED Mon Jan 20 16:02:48 2003 From: svenolof@REDACTED (Sven-Olof Nystr|m) Date: Mon, 20 Jan 2003 16:02:48 +0100 Subject: Selective receive (RE: Structs (was RE: Record selectors)) In-Reply-To: References: <15914.43540.628082.548532@harpo.it.uu.se> Message-ID: <15916.3992.349946.693793@harpo.it.uu.se> Ulf Wiger writes: > >It seems to me that matching receive is just a way to > >compensate for Erlang's inability to create temporary > >channels... > > I can't say whether Erlang ended up with pattern matching on > one message queue because Joe, Robert, Mike et al found it > too difficult to figure out how to create temporary > channels. (: The implementation is not that hard. Maybe they thought that it would be superfluous to have an implicit channel for each process AND the ability to create temporary channels. > I think a single message queue and pattern matching go well > in hand with state-oriented programming. Again, the POTS > example: > > speech(OtherPid) -> > receive > {lim, onhook} -> > lim:disconnect_from(OtherPid), > OtherPid ! {self(), cancel}, > idle(); > {lim, {digit, _Digit}} -> > speech(OtherPid); > {OtherPid, cancel} -> > wait_on_hook(false); > {Pid, request_connection} -> > Pid ! {self(), reject}, > speech(OtherPid); > Other -> > speech(OtherPid) > end. > > Here, we react to messages from 4 different senders > (consuming and ignoring any message from anyone else). One > could of course imagine an equally concise syntax that > scanned separate channels, pattern-matching over them, > blocking if desired and necessary. Yes. This could be written with a receive operation that simply grabs the next message in the mailbox + a case statement. > I find very little wrong with the notion of having a single > message queue. Matching receive is a rather strange construct. If arbitrary expressions were allowed in guards, it would be possible to write a receive that counted the messages in a mailbox. Unlike case statements, there is no way to translate a receive into simpler things (this affected the design of Core Erlang). As far as I know, no other programming language has anything similar. [Comment on OHaskell deleted.] Sven-Olof Nystr?m From bengt.tillman@REDACTED Mon Jan 20 16:31:22 2003 From: bengt.tillman@REDACTED (Bengt Tillman (EAB)) Date: Mon, 20 Jan 2003 16:31:22 +0100 Subject: MTP simulator? Message-ID: <4E4C7D1B13A5C840B0BF2A9B80FEC18201784392@esealnt913.al.sw.ericsson.se> Hi Milan, Yes, you are right, NETSim is an internal Ericsson product, which is extensively used when Ericsson's network management products are developed and tested. NETSim is written mostly in Erlang (more than 500,000 lines of source code and growing). If you are on the Ericsson intranet, you can order NETSim and download the product and its documentation from http://sps.lmera.ericsson.se/interior/netsim/ but this will probably not help you. >From your mail I cannot tell if you are interested in NETSim as an AXE simulator or in AXE behaviour in general (MTP and commands over the MTP protocol). In the first case you can contact me for technical information and the NETSim product manager, Torbj?rn Nyman torbjorn.nyman@REDACTED , in commercial matters. In the second case you could get some information from the NETSim documentation, but I would certainly recommend the documentation of the AXE system itself. Best regards, Bengt Tillman (NETSim software architect). -----Original Message----- From: Milan Vukoslavcevic [mailto:milanvuk@REDACTED] Sent: den 19 januari 2003 16:45 To: erlang-questions@REDACTED Subject: MTP simulator? Since I am interested in AXE 10 switch I found on web that: Netsim is a network simulator sold by Ericsson/Hewlit packard. NETSim simulates the operations and maintenance behavior of AXE Network Elements (AXE is a very large switching system product). NETSim simulates commands, printouts, alarms and files transfers. NETSim supports the Message Transfer Protocol (MTP) and communicates through a X.25 protocol. If this is true where I can find list of command line parameter(commands) used in MTP protocol ? Thanks in advance, Best regards, postgraduate student of telecommunication, Milan Vukoslavcevic University of Novi Sad http://www.ftn.ns.ac.yu/ Yugoslavia -------------- next part -------------- An HTML attachment was scrubbed... URL: From etxuwig@REDACTED Mon Jan 20 17:12:31 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 20 Jan 2003 17:12:31 +0100 (MET) Subject: Selective receive (RE: Structs (was RE: Record selectors)) In-Reply-To: <15916.3992.349946.693793@harpo.it.uu.se> Message-ID: On Mon, 20 Jan 2003, Sven-Olof Nystr|m wrote: >Ulf Wiger writes: > > I think a single message queue and pattern matching go well > > in hand with state-oriented programming. Again, the POTS > > example: > > > > speech(OtherPid) -> > > receive > > {lim, onhook} -> > > lim:disconnect_from(OtherPid), > > OtherPid ! {self(), cancel}, > > idle(); > > {lim, {digit, _Digit}} -> > > speech(OtherPid); > > {OtherPid, cancel} -> > > wait_on_hook(false); > > {Pid, request_connection} -> > > Pid ! {self(), reject}, > > speech(OtherPid); > > Other -> > > speech(OtherPid) > > end. > > > > Here, we react to messages from 4 different senders > > (consuming and ignoring any message from anyone else). One > > could of course imagine an equally concise syntax that > > scanned separate channels, pattern-matching over them, > > blocking if desired and necessary. > >Yes. This could be written with a receive operation that >simply grabs the next message in the mailbox + a case >statement. Yes, because the receive statement in this case has a catch-all branch, which means that it will always consume the first message that comes along. The following is a state from a prototype ATM call control state machine: loop_setup_sent(HcData, VolData) -> receive {setupB, PidB, MsgType, IEs, HcIdB, ResourcesB} -> %%from bside case MsgType of ?CONNECT -> connect(...); ?RELEASE -> placeholder(?PHARGS); ?ALERTING -> placeholder(?PHARGS); _ -> placeholder(?PHARGS) end; {from_dispatch, HcIdAfromA, MessageType, Message} -> %%from sigport (Aside) case {uniccLibrary:tokenize_sort(Message), MessageType} of {{ok, IEs}, ?CONNECT_ACKNOWLEDGE} -> connect_ack(); {{ok, IEs}, ?RELEASE} -> placeholder(?PHARGS); {{ok, IEs}, _} -> placeholder(?PHARGS); {{error, Cause}, _} -> placeholder(?PHARGS) end end This is slightly more difficult to rewrite as a case statement, because the code is doing a blocking wait on two "channels" simultaneously. One may assume that in the normal case, the program will consume the first message on any of the channels which it is currently monitoring. Then, this amounts to a blocking poll() on a subset of open channels followed by a case. I have trouble finding example code where this would not be adequate. >Matching receive is a rather strange construct. If >arbitrary expressions were allowed in guards, it would be >possible to write a receive that counted the messages in a >mailbox. Unlike case statements, there is no way to >translate a receive into simpler things (this affected the >design of Core Erlang). As far as I know, no other >programming language has anything similar. This need not be an argument against matchin receive per se, as few other languages have a track record in concurrent programming that matches that of Erlang... (: But I cannot argue that matching receive is indispensable as long as I cannot find a single good example where one couldn't do equally well (more or less) with multiple channels. (: /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From erlang@REDACTED Tue Jan 21 13:58:24 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Tue, 21 Jan 2003 13:58:24 +0100 Subject: FSM advantages ? Message-ID: <009201c2c14c$c91ad790$1e00a8c0@design> Could someone tell me the advantages of using FSM to Erlang receive & send messaging using functions (states), please ? Thanks, Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vances@REDACTED Mon Jan 20 21:05:09 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 20 Jan 2003 15:05:09 -0500 Subject: FSM advantages ? In-Reply-To: <009201c2c14c$c91ad790$1e00a8c0@design> References: <009201c2c14c$c91ad790$1e00a8c0@design> Message-ID: <20030120200509.GB3115@frogman.motivity.ca> On Tue, Jan 21, 2003 Eduardo Figoli wrote: } } Could someone tell me the advantages of using } FSM to Erlang receive & send messaging using functions (states), please ? Eduardo, Until you have decided that you are an Erlang Guru you should use the standard behaviours whenever applicable (knowing when they are applicable being the only challenge). There are several really good reasons for this. >From the "Programming Rules and Conventions" doc we are told: (http://www.erlang.se/doc/programming_rules.shtml#HDR4) "Whenever you have the same pattern of code in two or more places in the code try to isolate this in a common function and call this function instead of having the code in two different places. Copied code requires much effort to maintain." By utilizing the gen_fsm behaviour you have done this for much of the common overhead of handling processes which implement finite state machines. >From the "Design Principles" doc we are told: (http://www.erlang.org/doc/r9b/doc/design_principles/des_princ.html#1) "Applications must obey certain laws and must follow certain protocols so that they present a uniform interface to the Erlang runtime system. For example, they must be written so that the code can be changed without stopping the system. "The easiest way to program a new application is to make use of the behaviours which are included in the system. A behaviour is a "pattern of design" which can be used to build an application. Applications which are programmed with the standard behaviours automatically follow the required protocols." By doing things "Erlang Way" you will get a lot of things for free. Just look at the source file gen_fsm.erl and see if you want to understand all that it is doing for you. -Vance From erlang@REDACTED Mon Jan 20 22:16:06 2003 From: erlang@REDACTED (Inswitch Soluctions - Erlang Evaluation) Date: Mon, 20 Jan 2003 18:16:06 -0300 Subject: web server security Message-ID: <001001c2c0c9$2605d0b0$1400a8c0@tdapi> Hi: I?m investigating about erlang web server security. So, after read all about SSL,Plain and Mnesia authentication, I have some questions about it: First: I read that SSL library have some troubles. Those troubles makes this method unsafe? Second: Between make plain and mnesia authentication technique, I prefer the second way; but i'm not sure about the encryptation of password in mnesia... how mnesia store encripted passwords? it is possible? mnesia does it or I must do it manually? Third: Could you tell me your experience using those methods, and why do you recommended it or not? Thanks for all, gabriel... -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad_dumitrescu@REDACTED Tue Jan 21 09:00:55 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Tue, 21 Jan 2003 09:00:55 +0100 Subject: Rw: FSM advantages? Message-ID: Hi, Adding to Vance's comment, let's not forget that the predefined behaviours do quite a lot of things behind the scenes, things that otherwise need to be handled explicitly. Among them: tracing and error reporting, code change, works in a supervision tree, a standardized API. For a simple FSM, it is quite educative to implement it as a basic function-based one. The next step would be trying to introduce one of the things mentioned above, and I think it will be easy to appreciate that one could use the already written and tested ones instead. best regards, Vlad -----Original Message----- From: Inswitch Solutions - Erlang Evaluation [mailto:erlang@REDACTED] Sent: Tuesday, January 21, 2003 1:58 PM To: erlang-questions@REDACTED Subject: FSM advantages ? Could someone tell me the advantages of using FSM to Erlang receive & send messaging using functions (states), please ? Thanks, Eduardo Figoli INSwitch Solutions _________________________________________________________________ Senaste nytt fr?n motormarknaden http://motor.msn.se/ From svenolof@REDACTED Tue Jan 21 13:06:58 2003 From: svenolof@REDACTED (Sven-Olof Nystr|m) Date: Tue, 21 Jan 2003 13:06:58 +0100 Subject: Selective receive (RE: Structs (was RE: Record selectors)) In-Reply-To: References: <15916.3992.349946.693793@harpo.it.uu.se> Message-ID: <15917.14306.970335.812307@harpo.it.uu.se> Ulf Wiger writes: > > > I think a single message queue and pattern matching go well > > > in hand with state-oriented programming. Again, the POTS > > > example: [Snip] > >Yes. This could be written with a receive operation that > >simply grabs the next message in the mailbox + a case > >statement. > > Yes, because the receive statement in this case has a > catch-all branch, which means that it will always consume > the first message that comes along. > > The following is a state from a prototype ATM call control > state machine: > > loop_setup_sent(HcData, VolData) -> > receive > {setupB, PidB, MsgType, IEs, HcIdB, ResourcesB} -> > %%from bside > case MsgType of [...] > end; > {from_dispatch, HcIdAfromA, MessageType, Message} -> > %%from sigport (Aside) > case {uniccLibrary:tokenize_sort(Message), > MessageType} of [...] > end > end > > > This is slightly more difficult to rewrite as a case > statement, because the code is doing a blocking wait on two > "channels" simultaneously. One may assume that in the normal > case, the program will consume the first message on any of > the channels which it is currently monitoring. Then, this > amounts to a blocking poll() on a subset of open channels > followed by a case. I have trouble finding example code > where this would not be adequate. In other words, the multi-channel solution would use two channels, one from B side and one from A side, and the receiving process would look for messages on both channels. > >Matching receive is a rather strange construct. If > >arbitrary expressions were allowed in guards, it would be > >possible to write a receive that counted the messages in a > >mailbox. Unlike case statements, there is no way to > >translate a receive into simpler things (this affected the > >design of Core Erlang). As far as I know, no other > >programming language has anything similar. > > This need not be an argument against matchin receive per se, > as few other languages have a track record in concurrent > programming that matches that of Erlang... (: No, not necessarily. On the other hand, I suppose it would be interesting for future language designers to learn _why_ Erlang is the best concurrent language available. Is it because of matching receive or something else? > But I cannot argue that matching receive is indispensable as > long as I cannot find a single good example where one > couldn't do equally well (more or less) with multiple > channels. (: Sven-Olof Nystr?m From bjorn@REDACTED Tue Jan 21 14:13:58 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 21 Jan 2003 14:13:58 +0100 Subject: Structs In-Reply-To: James Hague's message of "Thu, 16 Jan 2003 13:53:33 -0600" References: Message-ID: Because records are so important, we must really make sure we do it right this time. We can't do another attempt (for one thing, it will be difficult to find a new good keyword when both "record" and "struct" are in use :) ). That's why other less important language features get done first. /Bjorn James Hague writes: > >What about cond (or something like it)? > >Isn't that coming soon to Erlang? > > I was always under the impression that the reason records were never > replaced with something neater was because there was little incentive to go > in and fiddle with the core language. But now "try" is on the way, as are > structured modules, and possibly "cond." Surely record improvements are a > higher priority? > > James > -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From richardc@REDACTED Tue Jan 21 15:39:53 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 21 Jan 2003 15:39:53 +0100 (MET) Subject: Structs (was RE: Record selectors) In-Reply-To: Message-ID: I've been postponing reading this thread properly since it exploded on the list, but I've finally got some time to catch up. Joe wrote: > One thing I haven't investigated is the interaction between this and > the packages stuff. > > "." (DOT) is getting pretty overloaded - so ~A.tag might collide > with the dot notation used in packages (perhaps Richard could comment > on this) Eh, in fact it's not a problem with packages. The problem is that the Thing.tag notation (where Thing is anything that's not an atom) is already stolen by the fairly obscure Mnemosyne syntax. (It denotes a record access to some implicitly-named record - I don't even want to know the details.) Anyhow, this reminds me that I actually would like to ask this eminent list whether the Mnemosyne syntax could be lifted out of the Erlang language - instead one could have a separate preprocessor for those that use Mnemosyne, creating Normal Erlang (TM) files from ".erm" files or whatever. Would this be a too big penalty on some people out there? /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ From etxuwig@REDACTED Tue Jan 21 17:13:42 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 21 Jan 2003 17:13:42 +0100 (MET) Subject: Structs (was RE: Record selectors) In-Reply-To: Message-ID: On Tue, 21 Jan 2003, Richard Carlsson wrote: >Eh, in fact it's not a problem with packages. The problem >is that the Thing.tag notation (where Thing is anything >that's not an atom) is already stolen by the fairly obscure >Mnemosyne syntax. (It denotes a record access to some >implicitly-named record - I don't even want to know the >details.) If we introduce proper structs, then shouldn't mnemosyne be updated to use those? >Anyhow, this reminds me that I actually would like to ask >this eminent list whether the Mnemosyne syntax could be >lifted out of the Erlang language - instead one could have >a separate preprocessor for those that use Mnemosyne, >creating Normal Erlang (TM) files from ".erm" files or >whatever. Would this be a too big penalty on some people >out there? One interesting aspect of the mnemosyne support is the 'query ... end' construct. To say that it's well documented would be an exaggeration. My understanding is that it returns a handle that can later be used when executing a query. Cool, but couldn't one try to unify normal list comprehensions, the struct semantics and the 'query ... end' construct to provide real language support for query processing? I imagine that 'query NormalListComprehension end' could return something that could be post-processed and optimized, even though it is only used on normal lists, and a mnemosyne-like utility could be made to work against other databases than mnesia -- perhaps even across multiple databases -- or perhaps not a database at all, but rather using WSDL or other to query internet sites for data. (I'm assuming that backward compatibility with the existing mnemosyne is not a topmost priority. Please correct me, those of you out there who consider yourselves heavy mnemosyne users.) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From etxuwig@REDACTED Tue Jan 21 17:37:52 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 21 Jan 2003 17:37:52 +0100 (MET) Subject: Selective receive (RE: Structs (was RE: Record selectors)) In-Reply-To: <15917.14306.970335.812307@harpo.it.uu.se> Message-ID: On Tue, 21 Jan 2003, Sven-Olof Nystr|m wrote: >On the other hand, I suppose it would be interesting for >future language designers to learn _why_ Erlang is the best >concurrent language available. Is it because of matching >receive or something else? This is a very interesting question, and one that we need to be able to answer. Assuming that Erlang _is_ the best concurrent language available (which of course it is ;), I would like to start proposing a few explanations (possibly in priority order -- I'm not sure): 1. A community of users who have been at it writing massively concurrent, robust and scalabe applications for years, and who are eager to share their knowledge. 2. An execution model that encourages people to use lots of processes (i.e. processes are _cheap_; asynchronous message passing scales well; and preemptive multi-tasking frees the programmer from the horrors of must-never-block-so-everything-is-asynchronous programming.) 3. Share-nothing semantics, avoiding many of the horrible synchronization problems that may otherwise plague concurrency programming. 4. A syntax that makes it very easy to wrap asynchronous communication inside a synchronous API, which means that the majority of programs don't need to know whether other processes/nodes are involved in the execution of a particular functions. 5. A variety of good support libraries for building robust and scalable servers. I left out a few things. Others are welcome to comment on the list. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From DANIESC.SCHUTTE@REDACTED Tue Jan 21 19:51:04 2003 From: DANIESC.SCHUTTE@REDACTED (DANIESC SCHUTTE) Date: Tue, 21 Jan 2003 20:51:04 +0200 Subject: CRYPTO inclusion in another app startup Message-ID: Greetings to all the wise men, I would like to enquire if and or what the requirements are for including the crypto application in an otp boot up script in order to function. We are starting up all the other supervisors and we only get a failure on trying to start crypto. The error message: crypto.drv not found (although the file is in both the priv directory of the application as well as the root directory of the application) Any other suggestions are welcome. Thanks again for all the support we receive. Daniel Schutte ##################################################################################### 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 and copies. ##################################################################################### From daniel.dudley@REDACTED Tue Jan 21 19:10:15 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Tue, 21 Jan 2003 19:10:15 +0100 Subject: Structs References: Message-ID: <003501c2c178$59411930$85d1b33e@dld2000> Bjorn Gustavsson wrote: > Because records are so important, we must really make sure > we do it right this time. No argument there! > We can't do another attempt (for one thing, it will be > difficult to find a new good keyword when both "record" and > "struct" are in use :) ). Sorry, Bjorn, that must be just about the lamest excuse yet. I'm sure an imaginative person on this mailing list could help you out there. I'll even throw in my 2 bits: 'domain' -- a user-defined static type, normally with non-local scope. (Borrowed from Turbo/PDC/Visual Prolog, incidently -- except the scope qualification.) Anyway, isn't 'struct' meant to replace 'record'? > That's why other less important language features get > done first. Well, that sounds reasonable as long as you're 100% sure that such work won't influence the options available for a new record/struct/domain implementation. Just make sure you're not putting the cart before the horse! ;-) But really, IMHO it probably would be best if one cleaned up existing language features before introducing new ones. It's *always* better to build on a clean base. [snipped James Hague's message] Regards, Daniel From luke@REDACTED Tue Jan 21 20:07:51 2003 From: luke@REDACTED (Luke Gorrie) Date: 21 Jan 2003 20:07:51 +0100 Subject: Structs In-Reply-To: <003501c2c178$59411930$85d1b33e@dld2000> References: <003501c2c178$59411930$85d1b33e@dld2000> Message-ID: "Daniel Dudley" writes: > But really, IMHO it probably would be best if one cleaned > up existing language features before introducing new ones. > It's *always* better to build on a clean base. Please don't talk them out of adding try/catch to the next release. I really want it, more than structs. :-) Cheers, Luke From peter@REDACTED Tue Jan 21 20:35:08 2003 From: peter@REDACTED (Peter H|gfeldt) Date: Tue, 21 Jan 2003 20:35:08 +0100 (MET) Subject: CRYPTO inclusion in another app startup In-Reply-To: Message-ID: On Tue, 21 Jan 2003, DANIESC SCHUTTE wrote: > Greetings to all the wise men, > > I would like to enquire if and or what the requirements are for > including the crypto application in an otp boot up script in order to > function. We are starting up all the other supervisors and we only get > a failure on trying to start crypto. > > The error message: crypto.drv not found (although the file is in both > the priv directory of the application as well as the root directory of > the application) The name of the file is `crypto_drv' (and not `crypto.drv') and the file must be in `crypto-Vsn/priv/lib'. Please tell us more: 1) operating system; 2) Erlang/OTP version; 3) Crypto version; 4) if you created a separate package with `systools' and unpacked that in a new directory location, or not; 5) how you created the boot script; 6) If you used opensource Erlang and really did build the crypto application, or if you used a binary Erlang/OTP distribution. > > Any other suggestions are welcome. > > Thanks again for all the support we receive. > > Daniel Schutte > [...] > /Peter From Sean.Hinde@REDACTED Tue Jan 21 21:26:21 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Tue, 21 Jan 2003 20:26:21 -0000 Subject: Structs (was RE: Record selectors) Message-ID: > Anyhow, this reminds me that I actually would like to ask this > eminent list whether the Mnemosyne syntax could be lifted out of > the Erlang language - instead one could have a separate preprocessor > for those that use Mnemosyne, creating Normal Erlang (TM) files > from ".erm" files or whatever. Would this be a too big penalty > on some people out there? OK by us. We removed the last bit of mnesonyne from our systems last year (which was a shame because it would be an elegant way to perform complex queries if it really worked well) Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rprice@REDACTED Tue Jan 21 22:39:37 2003 From: rprice@REDACTED (Roger Price) Date: Tue, 21 Jan 2003 22:39:37 +0100 (CET) Subject: Why Erlang is the best concurrent language available In-Reply-To: Message-ID: On Tue, 21 Jan 2003, Ulf Wiger wrote: > On Tue, 21 Jan 2003, Sven-Olof Nystr|m wrote: > >.. _why_ Erlang is the best concurrent language available. > I left out a few things. Others are welcome to comment on the list. May I suggest "simplicity" - Erlang is a simple language which concentrates on simple, powerful ideas. Simplicity is a virtue which so many have forgotten. Best Regards, Roger From klacke@REDACTED Tue Jan 21 23:05:51 2003 From: klacke@REDACTED (Klacke) Date: Tue, 21 Jan 2003 23:05:51 +0100 Subject: Structs (was RE: Record selectors) In-Reply-To: ; from Sean.Hinde@t-mobile.co.uk on Tue, Jan 21, 2003 at 08:26:21PM -0000 References: Message-ID: <20030121230551.A30352@bluetail.com> On Tue, Jan 21, 2003 at 08:26:21PM -0000, Sean Hinde wrote: > > Anyhow, this reminds me that I actually would like to ask this > > eminent list whether the Mnemosyne syntax could be lifted out of > > the Erlang language - instead one could have a separate preprocessor > > for those that use Mnemosyne, creating Normal Erlang (TM) files > > from ".erm" files or whatever. Would this be a too big penalty > > on some people out there? > > OK by us. We removed the last bit of mnesonyne from our systems last year > (which was a shame because it would be an elegant way to perform complex > queries if it really worked well) Us too, no mnemosyne at Nortel. /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From enano@REDACTED Tue Jan 21 23:23:56 2003 From: enano@REDACTED (Miguel Barreiro Paz) Date: Tue, 21 Jan 2003 23:23:56 +0100 (CET) Subject: Selective receive (RE: Structs (was RE: Record selectors)) In-Reply-To: References: Message-ID: > I left out a few things. Others are welcome to comment on > the list. Language developers are focused on making sure things work, and sometimes on adding useful features (...that work). Comparing this situation to other fancy functional languages is left as an exercise to the reader in order to avoid injured egos. Regards, Miguel From Vlad.Dumitrescu@REDACTED Wed Jan 22 08:47:59 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Wed, 22 Jan 2003 08:47:59 +0100 Subject: Use of mnemosyne Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6DD@esemont203.gbg.edt.ericsson.se> Hi, Here at ERV, I only can see a few uses of mnemosyne, and I guess they aren't any complex queries, so it would be okay to enhance it without backwards compatibility. However, I don't know what they do at the higher levels (GSN). regards, Vlad From martin-g@REDACTED Wed Jan 22 10:44:21 2003 From: martin-g@REDACTED (Martin Gustafsson) Date: Wed, 22 Jan 2003 10:44:21 +0100 Subject: Job offer! Message-ID: <1043228661.3d8db4c0martin-g@home.se> Hello Everybody! Today I work for a small Consultant Company suited in Stockholm called Esplanad Business Solutions AB. The last weeks we have negotiated with one of our customers about building a Serverprogram for distribution of parameters to Creditcard Terminals (ftp and Modem protocol). Yesterday their board had a meeting and recommended us :-), Although they want to meet us and discuss the technical issues so I cant garantee whether it will be Erlang or C/C++ but probably in Erlang since I have promoted it so hard! In any case some parts must be written in C/C++ knowledge and experience in these languages are required. In any case we need at least one developer for at least 6 month with good chances to get it prolonged. If you are interested or want more information contact me at: phone: +46 73 - 720 25 12 mail: martin.gustafsson@REDACTED The project will start immediately so it is very good if you can start soon. Best Regards Martin Gustafsson From erlang@REDACTED Thu Jan 23 09:31:48 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Thu, 23 Jan 2003 09:31:48 +0100 Subject: FSM advantages? References: Message-ID: <00de01c2c2b9$dff3a460$1e00a8c0@design> Hi ! Thank you for your answers. Suppose I have to implement a timed automata (timed temporal graph) in Erlang. Would FSM be the right choice to receive/send messaging with "after" timeouts ? A finite state machine (FSM) says what to do and a timed automata is a finite state machine but also saying when (time) to do it. Does someone already get in touch with implementations in Erlang for this type of Real Time systems model ? Regards, Eduardo Figoli INSwitch Solutions ----- Original Message ----- From: "Vlad Dumitrescu" To: Sent: Tuesday, January 21, 2003 9:00 AM Subject: Rw: FSM advantages? Hi, Adding to Vance's comment, let's not forget that the predefined behaviours do quite a lot of things behind the scenes, things that otherwise need to be handled explicitly. Among them: tracing and error reporting, code change, works in a supervision tree, a standardized API. For a simple FSM, it is quite educative to implement it as a basic function-based one. The next step would be trying to introduce one of the things mentioned above, and I think it will be easy to appreciate that one could use the already written and tested ones instead. best regards, Vlad -----Original Message----- From: Inswitch Solutions - Erlang Evaluation [mailto:erlang@REDACTED] Sent: Tuesday, January 21, 2003 1:58 PM To: erlang-questions@REDACTED Subject: FSM advantages ? Could someone tell me the advantages of using FSM to Erlang receive & send messaging using functions (states), please ? Thanks, Eduardo Figoli INSwitch Solutions _________________________________________________________________ Senaste nytt fr?n motormarknaden http://motor.msn.se/ From kefeer@REDACTED Wed Jan 22 14:41:51 2003 From: kefeer@REDACTED (Ivan Tihonov) Date: Wed, 22 Jan 2003 18:41:51 +0500 Subject: Programming rules Message-ID: <000801c2c21c$0524dd10$0a01a8c0@kefeer> Does somebody works over http://www.erlang.se/doc/programming_rules.shtml now? Last update was on 2000-02-08. From matthias@REDACTED Wed Jan 22 14:57:27 2003 From: matthias@REDACTED (Matthias Lang) Date: Wed, 22 Jan 2003 14:57:27 +0100 Subject: Structs In-Reply-To: <003501c2c178$59411930$85d1b33e@dld2000> References: <003501c2c178$59411930$85d1b33e@dld2000> Message-ID: <15918.41799.55130.275993@antilipe.corelatus.se> > Well, that sounds reasonable as long as you're 100% sure > that such work won't influence the options available for a > new record/struct/domain implementation. Oh yes, 100%-sure is the only way to go! Don't be misled by those pragmatists. They may appear to be getting useful work done, but remember: 99% certainty is no better than having the devil himself in charge of your project. Matt From carlos@REDACTED Wed Jan 22 15:51:58 2003 From: carlos@REDACTED (Carlos Silva) Date: Wed, 22 Jan 2003 11:51:58 -0300 Subject: Mnemosyne query by a partial key Message-ID: <005401c2c225$dbcf2740$4b00a8c0@ss7link> Hi everybody. I'd like to know if it is possible to include a function call in the body of a Mnemosyne query. Knowing that a query is declared as: query [ || ] end The doubt comes to me when I tried to run this example: Q = query [{E.item, E.url} || E <- table(menus), element(1, E.item) = Level] end, but a "{aborted,mnemosyne_not_running}" is all I've obtained from the shell :o( Neither I could run my example in this way: ... Menus = #menus{item = '$1'}, Guard = {'==','element(1, $1)',Level}, mnesia:select(menus, [{Menus , [Guard], [['$1','$2']]}]) ... I'd be happy if someone could tell me how to execute a query by a partial key, when the key of a Mnesia table is a compound key as {elem1, elem2, elem3} and I want to search only by elem1 for example. Thanks a lot, Ing. Carlos E. Silva INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgud@REDACTED Wed Jan 22 16:20:56 2003 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 22 Jan 2003 16:20:56 +0100 Subject: Mnemosyne query by a partial key In-Reply-To: <005401c2c225$dbcf2740$4b00a8c0@ss7link> References: <005401c2c225$dbcf2740$4b00a8c0@ss7link> Message-ID: <15918.46808.857880.444640@gargle.gargle.HOWL> {aborted,mnemosyne_not_running} means that you forgot to start the application mnemosyne, i.e. use application:start(mnemosyne). before any mnemosyne queries. But the select call is the preferred way.. Though you forgot to bind the $2 in your select expr. /Dan PS: Yes I know I got a bug in select, a bad match-spec will loop the transaction forever :-(, will be corrected in next patch. In the mean time use ets:test_ms/2 to check your match_spec. Carlos Silva writes: > Hi everybody. > > I'd like to know if it is possible to include a function call in the body of a Mnemosyne query. Knowing that a query is declared as: query [ || ] end > > The doubt comes to me when I tried to run this example: > Q = query [{E.item, E.url} || E <- table(menus), element(1, E.item) = Level] end, > > but a "{aborted,mnemosyne_not_running}" is all I've obtained from the shell :o( > > Neither I could run my example in this way: > ... > Menus = #menus{item = '$1'}, > Guard = {'==','element(1, $1)',Level}, > mnesia:select(menus, [{Menus , [Guard], [['$1','$2']]}]) > ... > > I'd be happy if someone could tell me how to execute a query by a partial key, when the key of a Mnesia table is a compound key as {elem1, elem2, elem3} and I want to search only by elem1 for example. > > Thanks a lot, > > Ing. Carlos E. Silva > INSwitch Solutions > > > > > > > >
Hi everybody.
>
 
>
I'd like to know if it is possible to include a > function call in the body of a Mnemosyne query. Knowing that a query is declared > as: query [ <pattern> || <body> ] > end
>
 
>
The doubt comes to me when I tried to run this > example:
>
size=2>          Q = query > [{E.item, E.url} || E <- table(menus), element(1, E.item) = > Level] end,
>
 
>
but a "{aborted,mnemosyne_not_running}" is all I've > obtained from the shell :o(
>
 
>
Neither I could run my example in this > way:
>
...
>
    Menus = #menus{item = > '$1'},
>
    Guard = > {'==','element(1, $1)',Level},
    > mnesia:select(menus, [{Menus , [Guard], [['$1','$2']]}])
>
...
>
 
>
I'd be happy if someone could tell me how to > execute a query by a partial key, when the key of a Mnesia table is a compound > key as {elem1, elem2, elem3} and I want to search only by elem1 for > example.
>
 
>
Thanks a lot,
>
 
>
Ing. Carlos E. Silva
>
INSwitch Solutions size=2>
-- 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 carlos@REDACTED Wed Jan 22 16:35:52 2003 From: carlos@REDACTED (Carlos Silva) Date: Wed, 22 Jan 2003 12:35:52 -0300 Subject: Mnemosyne query by a partial key References: <005401c2c225$dbcf2740$4b00a8c0@ss7link> <15918.46808.857880.444640@gargle.gargle.HOWL> Message-ID: <006701c2c22b$f37ad190$4b00a8c0@ss7link> OK Dan, it works. Thank you very much. But, tell me please, why I could run queries like the following without using application:start(mnemosyne) ? sel_menus(Item) -> F = fun() -> Q = query [{E.item, E.url} || E <- table(menus), E.item = Item] end, mnemosyne:eval(Q) end, mnesia:transaction(F). Regards, Ing. Carlos E. Silva INSwitch Solutions ----- Original Message ----- From: "Dan Gudmundsson" To: "Carlos Silva" Cc: "Erlang Questions" Sent: Wednesday, January 22, 2003 12:20 PM Subject: Mnemosyne query by a partial key > > {aborted,mnemosyne_not_running} > > means that you forgot to start the application mnemosyne, > i.e. use application:start(mnemosyne). before any mnemosyne queries. > > But the select call is the preferred way.. > Though you forgot to bind the $2 in your select expr. > > /Dan > PS: Yes I know I got a bug in select, a bad match-spec will loop > the transaction forever :-(, will be corrected in next patch. > In the mean time use ets:test_ms/2 to check your match_spec. > > > Carlos Silva writes: > > Hi everybody. > > > > I'd like to know if it is possible to include a function call in the body of a Mnemosyne query. Knowing that a query is declared as: query || ] end > > > > The doubt comes to me when I tried to run this example: > > Q = query [{E.item, E.url} || E <- table(menus), element(1, E.item) = Level] end, > > > > but a "{aborted,mnemosyne_not_running}" is all I've obtained from the shell :o( > > > > Neither I could run my example in this way: > > ... > > Menus = #menus{item = '$1'}, > > Guard = {'==','element(1, $1)',Level}, > > mnesia:select(menus, [{Menus , [Guard], [['$1','$2']]}]) > > ... > > > > I'd be happy if someone could tell me how to execute a query by a partial key, when the key of a Mnesia table is a compound key as {elem1, elem2, elem3} and I want to search only by elem1 for example. > > > > Thanks a lot, > > > > Ing. Carlos E. Silva > > INSwitch Solutions > > > > > > > > > > > > > > > >
Hi everybody.
> >
 
> >
I'd like to know if it is possible to include a > > function call in the body of a Mnemosyne query. Knowing that a query is declared > > as: query [ <pattern> || <body> ] > > end
> >
 
> >
The doubt comes to me when I tried to run this > > example:
> >
> size=2>          Q = query > > [{E.item, E.url} || E <- table(menus), element(1, E.item) = > > Level] end,
> >
 
> >
but a "{aborted,mnemosyne_not_running}" is all I've > > obtained from the shell :o(
> >
 
> >
Neither I could run my example in this > > way:
> >
...
> >
    Menus = #menus{item = > > '$1'},
> >
    Guard = > > {'==','element(1, $1)',Level},
    > > mnesia:select(menus, [{Menus , [Guard], [['$1','$2']]}])
> >
...
> >
 
> >
I'd be happy if someone could tell me how to > > execute a query by a partial key, when the key of a Mnesia table is a compound > > key as {elem1, elem2, elem3} and I want to search only by elem1 for > > example.
> >
 
> >
Thanks a lot,
> >
 
> >
Ing. Carlos E. Silva
> >
INSwitch Solutions > size=2>
> > -- > 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 martin@REDACTED Wed Jan 22 19:11:53 2003 From: martin@REDACTED (martin j logan) Date: 22 Jan 2003 12:11:53 -0600 Subject: FSM advantages? In-Reply-To: <00de01c2c2b9$dff3a460$1e00a8c0@design> References: <00de01c2c2b9$dff3a460$1e00a8c0@design> Message-ID: <1043259118.1632.153.camel@berimbau> The fsm is fine for an automaton with time constraints. gen_fsm supports user defined states and user defined transitions between those states. Any state can be augmented with a timeout. A programmer can specify the behavior of the fsm when such a timeout occurs. Cheers, Martin On Thu, 2003-01-23 at 02:31, Inswitch Solutions - Erlang Evaluation wrote: > Hi ! > > Thank you for your answers. > Suppose I have to implement a timed automata (timed temporal graph) in > Erlang. > Would FSM be the right choice to receive/send messaging with "after" > timeouts ? > A finite state machine (FSM) says what to do and a timed automata is a > finite state machine but also saying when (time) to do it. > Does someone already get in touch with implementations in Erlang for > this type of Real Time systems model ? > > > Regards, > Eduardo Figoli > INSwitch Solutions > > > ----- Original Message ----- > From: "Vlad Dumitrescu" > To: > Sent: Tuesday, January 21, 2003 9:00 AM > Subject: Rw: FSM advantages? > > > Hi, > > Adding to Vance's comment, let's not forget that the predefined behaviours > do quite a lot of things behind the scenes, things that otherwise need to be > handled explicitly. Among them: tracing and error reporting, code change, > works in a supervision tree, a standardized API. > > For a simple FSM, it is quite educative to implement it as a basic > function-based one. The next step would be trying to introduce one of the > things mentioned above, and I think it will be easy to appreciate that one > could use the already written and tested ones instead. > > best regards, > Vlad > -----Original Message----- > From: Inswitch Solutions - Erlang Evaluation [mailto:erlang@REDACTED] > Sent: Tuesday, January 21, 2003 1:58 PM > To: erlang-questions@REDACTED > Subject: FSM advantages ? > > > > Could someone tell me the advantages of using > FSM to Erlang receive & send messaging using functions (states), please ? > > > Thanks, > Eduardo Figoli > INSwitch Solutions > > > > > > > > > _________________________________________________________________ > Senaste nytt fr?n motormarknaden http://motor.msn.se/ > > From erlang@REDACTED Thu Jan 23 15:18:01 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Thu, 23 Jan 2003 15:18:01 +0100 Subject: FSM advantages? References: <00de01c2c2b9$dff3a460$1e00a8c0@design> <1043259118.1632.153.camel@berimbau> Message-ID: <013901c2c2ea$3d48eb40$1e00a8c0@design> Martin, Thank you I've found the function sync_send_event(FsmRef, Event, Timeout) -> Reply which does exactly what I need. I just only need to know what's the reply term when the Timeout ocurr? Regards, Eduardo Figoli INSwitch Solutions ----- Original Message ----- From: "martin j logan" To: "Inswitch Solutions - Erlang Evaluation" Cc: Sent: Wednesday, January 22, 2003 7:11 PM Subject: Re: FSM advantages? The fsm is fine for an automaton with time constraints. gen_fsm supports user defined states and user defined transitions between those states. Any state can be augmented with a timeout. A programmer can specify the behavior of the fsm when such a timeout occurs. Cheers, Martin On Thu, 2003-01-23 at 02:31, Inswitch Solutions - Erlang Evaluation wrote: > Hi ! > > Thank you for your answers. > Suppose I have to implement a timed automata (timed temporal graph) in > Erlang. > Would FSM be the right choice to receive/send messaging with "after" > timeouts ? > A finite state machine (FSM) says what to do and a timed automata is a > finite state machine but also saying when (time) to do it. > Does someone already get in touch with implementations in Erlang for > this type of Real Time systems model ? > > > Regards, > Eduardo Figoli > INSwitch Solutions > > > ----- Original Message ----- > From: "Vlad Dumitrescu" > To: > Sent: Tuesday, January 21, 2003 9:00 AM > Subject: Rw: FSM advantages? > > > Hi, > > Adding to Vance's comment, let's not forget that the predefined behaviours > do quite a lot of things behind the scenes, things that otherwise need to be > handled explicitly. Among them: tracing and error reporting, code change, > works in a supervision tree, a standardized API. > > For a simple FSM, it is quite educative to implement it as a basic > function-based one. The next step would be trying to introduce one of the > things mentioned above, and I think it will be easy to appreciate that one > could use the already written and tested ones instead. > > best regards, > Vlad > -----Original Message----- > From: Inswitch Solutions - Erlang Evaluation [mailto:erlang@REDACTED] > Sent: Tuesday, January 21, 2003 1:58 PM > To: erlang-questions@REDACTED > Subject: FSM advantages ? > > > > Could someone tell me the advantages of using > FSM to Erlang receive & send messaging using functions (states), please ? > > > Thanks, > Eduardo Figoli > INSwitch Solutions > > > > > > > > > _________________________________________________________________ > Senaste nytt fr?n motormarknaden http://motor.msn.se/ > > From martin@REDACTED Wed Jan 22 19:41:21 2003 From: martin@REDACTED (martin j logan) Date: 22 Jan 2003 12:41:21 -0600 Subject: Why Erlang is the best concurrent language available In-Reply-To: References: Message-ID: <1043260886.1632.184.camel@berimbau> I fully agree. I think that simplicity & practicality are some of the prime virtues of erlang. These properties lend themselves to making any language, system, or construction of any sort that is to be used by an operator, better at allowing the operator to leverage the strength of the tool and concentrate on the problem at hand and not on the vast non-intuitive intricacies of the tool(enter C++ and pthreads). In my honest opinion erlang is largely successful due to the coupling of its smart paradigm, concurrency, and its simple straightforward (for the most part) syntax and semantics. When looking at an erlang program it is easy to see what it does - the code is, on the whole, short concise and readable. Try saying the same for, or a step better, refactoring, a program built with an advanced hybrid OO modular encapsulated statically typed everything is an object except these five things - oh and you can configure it with XML and... Like Joe says its all just too hard!!! Cheers, Martin On Tue, 2003-01-21 at 15:39, Roger Price wrote: > On Tue, 21 Jan 2003, Ulf Wiger wrote: > > > On Tue, 21 Jan 2003, Sven-Olof Nystr|m wrote: > > >.. _why_ Erlang is the best concurrent language available. > > > I left out a few things. Others are welcome to comment on the list. > > May I suggest "simplicity" - Erlang is a simple language which > concentrates on simple, powerful ideas. > > Simplicity is a virtue which so many have forgotten. > > Best Regards, > Roger > From martin@REDACTED Wed Jan 22 19:44:12 2003 From: martin@REDACTED (martin j logan) Date: 22 Jan 2003 12:44:12 -0600 Subject: FSM advantages? In-Reply-To: <013901c2c2ea$3d48eb40$1e00a8c0@design> References: <00de01c2c2b9$dff3a460$1e00a8c0@design> <1043259118.1632.153.camel@berimbau> <013901c2c2ea$3d48eb40$1e00a8c0@design> Message-ID: <1043261052.1632.186.camel@berimbau> Module:StateName(Event, StateData) -> Result Types: Event = timeout | term() -Martin On Thu, 2003-01-23 at 08:18, Inswitch Solutions - Erlang Evaluation wrote: > Martin, > > Thank you I've found the function > sync_send_event(FsmRef, Event, Timeout) -> Reply > which does exactly what I need. > > I just only need to know what's the reply term when the Timeout ocurr? > > > Regards, > Eduardo Figoli > INSwitch Solutions > > > ----- Original Message ----- > From: "martin j logan" > To: "Inswitch Solutions - Erlang Evaluation" > Cc: > Sent: Wednesday, January 22, 2003 7:11 PM > Subject: Re: FSM advantages? > > > The fsm is fine for an automaton with time constraints. gen_fsm supports > user defined states and user defined transitions between those states. > Any state can be augmented with a timeout. A programmer can specify the > behavior of the fsm when such a timeout occurs. > > Cheers, > Martin > > > On Thu, 2003-01-23 at 02:31, Inswitch Solutions - Erlang Evaluation > wrote: > > Hi ! > > > > Thank you for your answers. > > Suppose I have to implement a timed automata (timed temporal graph) in > > Erlang. > > Would FSM be the right choice to receive/send messaging with "after" > > timeouts ? > > A finite state machine (FSM) says what to do and a timed automata is a > > finite state machine but also saying when (time) to do it. > > Does someone already get in touch with implementations in Erlang for > > this type of Real Time systems model ? > > > > > > Regards, > > Eduardo Figoli > > INSwitch Solutions > > > > > > ----- Original Message ----- > > From: "Vlad Dumitrescu" > > To: > > Sent: Tuesday, January 21, 2003 9:00 AM > > Subject: Rw: FSM advantages? > > > > > > Hi, > > > > Adding to Vance's comment, let's not forget that the predefined behaviours > > do quite a lot of things behind the scenes, things that otherwise need to > be > > handled explicitly. Among them: tracing and error reporting, code change, > > works in a supervision tree, a standardized API. > > > > For a simple FSM, it is quite educative to implement it as a basic > > function-based one. The next step would be trying to introduce one of the > > things mentioned above, and I think it will be easy to appreciate that one > > could use the already written and tested ones instead. > > > > best regards, > > Vlad > > -----Original Message----- > > From: Inswitch Solutions - Erlang Evaluation [mailto:erlang@REDACTED] > > Sent: Tuesday, January 21, 2003 1:58 PM > > To: erlang-questions@REDACTED > > Subject: FSM advantages ? > > > > > > > > Could someone tell me the advantages of using > > FSM to Erlang receive & send messaging using functions (states), please ? > > > > > > Thanks, > > Eduardo Figoli > > INSwitch Solutions > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > Senaste nytt fr?n motormarknaden http://motor.msn.se/ > > > > > > > From vances@REDACTED Wed Jan 22 19:48:51 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 22 Jan 2003 13:48:51 -0500 Subject: FSM advantages? In-Reply-To: <013901c2c2ea$3d48eb40$1e00a8c0@design> References: <00de01c2c2b9$dff3a460$1e00a8c0@design> <1043259118.1632.153.camel@berimbau> <013901c2c2ea$3d48eb40$1e00a8c0@design> Message-ID: <20030122184851.GP3115@frogman.motivity.ca> Eduardo, You should also note that you can set a timeout as the FSM enters each state. Your callback function for init may return: {ok, idle, #s{}, 4000} In which case it will enter state "idle" and if no event is received in four seconds the event "timeout" will be received. idle(seize, State) -> ... {next_state, seized, State, 1000}. idle(timeout, State) -> ... {next_state, idle, State, 4000}. Each state handler, as well as handle_event/3, handle_sync_event/4 and handle_info/3, may include a timeout in their return. In addition to this method you can of course use timers explicitly: idle(seize, State) -> ... {ok, TimerReference} = timer:apply_after(1000, gen_fsm, send_event, [self(), seize_timer]), NewState#s{seize_ref = TimerReference}; {next_state, seized, NewState}. seized(seize_timer, State) -> ... seized(Other, State) -> timer:cancel(State#s.seize_ref), ... On Thu, Jan 23, 2003 at 03:18:01PM +0100, Eduardo Figoli wrote: } } Thank you I've found the function } sync_send_event(FsmRef, Event, Timeout) -> Reply } which does exactly what I need. } } I just only need to know what's the reply term when the Timeout ocurr? } } } Regards, } Eduardo Figoli } INSwitch Solutions This doesn't seem to be documented does it? I don't know the answer as I've never found a reason to program synchronously in Erlang. Try it and see. I suspect the answer is the atom timeout. -Vance From vances@REDACTED Wed Jan 22 20:27:24 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 22 Jan 2003 14:27:24 -0500 Subject: FSM advantages? In-Reply-To: <20030122184851.GP3115@frogman.motivity.ca> References: <00de01c2c2b9$dff3a460$1e00a8c0@design> <1043259118.1632.153.camel@berimbau> <013901c2c2ea$3d48eb40$1e00a8c0@design> <20030122184851.GP3115@frogman.motivity.ca> Message-ID: <20030122192724.GR3115@frogman.motivity.ca> OK, I stand corrected. The documentation for gen_fsm:sync_send_event/2,3 clearly says: If no reply is received within the specified time, the function call fails. -Vance On Wed, Jan 22, 2003 at 01:48:51PM -0500, Vance Shipley wrote: } } On Thu, Jan 23, 2003 at 03:18:01PM +0100, Eduardo Figoli wrote: } } } } Thank you I've found the function } } sync_send_event(FsmRef, Event, Timeout) -> Reply } } which does exactly what I need. } } } } I just only need to know what's the reply term when the Timeout ocurr? } } This doesn't seem to be documented does it? I don't know the answer as } I've never found a reason to program synchronously in Erlang. Try it and } see. I suspect the answer is the atom timeout. } } -Vance } From erlang@REDACTED Thu Jan 23 16:54:30 2003 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Thu, 23 Jan 2003 16:54:30 +0100 Subject: FSM advantages? References: <00de01c2c2b9$dff3a460$1e00a8c0@design> <1043259118.1632.153.camel@berimbau> <013901c2c2ea$3d48eb40$1e00a8c0@design> <20030122184851.GP3115@frogman.motivity.ca> <20030122192724.GR3115@frogman.motivity.ca> Message-ID: <017701c2c2f7$b8470d10$1e00a8c0@design> Vance, What does it mean, timeout will be returned ? Thanks, Eduardo Figoli INSwitch Solutions ----- Original Message ----- From: "Vance Shipley" To: "Eduardo Figoli" Cc: Sent: Wednesday, January 22, 2003 8:27 PM Subject: Re: FSM advantages? > > OK, I stand corrected. The documentation for gen_fsm:sync_send_event/2,3 > clearly says: > > If no reply is received within the specified time, the > function call fails. > > -Vance > > On Wed, Jan 22, 2003 at 01:48:51PM -0500, Vance Shipley wrote: > } > } On Thu, Jan 23, 2003 at 03:18:01PM +0100, Eduardo Figoli wrote: > } } > } } Thank you I've found the function > } } sync_send_event(FsmRef, Event, Timeout) -> Reply > } } which does exactly what I need. > } } > } } I just only need to know what's the reply term when the Timeout ocurr? > } > } This doesn't seem to be documented does it? I don't know the answer as > } I've never found a reason to program synchronously in Erlang. Try it and > } see. I suspect the answer is the atom timeout. > } > } -Vance > } From vances@REDACTED Wed Jan 22 20:54:06 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 22 Jan 2003 14:54:06 -0500 Subject: FSM advantages? In-Reply-To: <017701c2c2f7$b8470d10$1e00a8c0@design> References: <00de01c2c2b9$dff3a460$1e00a8c0@design> <1043259118.1632.153.camel@berimbau> <013901c2c2ea$3d48eb40$1e00a8c0@design> <20030122184851.GP3115@frogman.motivity.ca> <20030122192724.GR3115@frogman.motivity.ca> <017701c2c2f7$b8470d10$1e00a8c0@design> Message-ID: <20030122195406.GS3115@frogman.motivity.ca> Eduardo, The function gen_fsm:sync_send_event will fail when the timeout is reached. Take this example: -module(test_fsm). -behaviour(gen_fsm). -export([start/0, init/1, one/3, two/3]). start() -> gen_fsm:start_link(test_fsm, [], []). init(Args) -> {ok, one, []}. one(Event, From, State) -> {reply, one_two, two, State}. two(Event, From, State) -> {next_state, one, State}. Here the state handler for state "one" will return a reply. The second state will not. This is because the return for state one is {reply,..} while the return for state two is {next_state,...} which does not return a reply but simply transitions to the next state. 1> {ok, Pid} = test_fsm:start(). {ok,<0.30.0>} 2> gen_fsm:sync_send_event(Pid, foo). one_two 3> gen_fsm:sync_send_event(Pid, foo). ** exited: {timeout,{gen_fsm,sync_send_event,[<0.30.0>,foo]}} ** In the second case the default timeout (5000) took place and then the function failed. The exit value was {timeout,...}. To use this you either let the crash occur and use the system supervision principles or you wrap the call to gen_fsm:sync_send_event with a catch: case catch gen_fsm:sync_send_event(Pid, foo) of {'EXIT',{timeout, _} -> ... Other -> ... end, -Vance -Vance From vances@REDACTED Thu Jan 23 03:04:28 2003 From: vances@REDACTED (Vance Shipley) Date: Wed, 22 Jan 2003 21:04:28 -0500 Subject: bug in pg2? Message-ID: <20030123020428.GV3115@frogman.motivity.ca> pg2:join/2 allows you to add the same Pid to the same group more than once. Do we want to call this a bug or just an optimized implementation? -Vance Erlang (BEAM) emulator version 5.1.2 [source] [threads:0] Eshell V5.1.2 (abort with ^G) 1> pg2:create(foo). ok 2> pg2:get_members(foo). [] 3> pg2:join(foo, self()). ok 4> pg2:get_members(foo). [<0.23.0>] 5> pg2:join(foo, self()). ok 6> pg2:get_members(foo). [<0.23.0>,<0.23.0>] From Dolly095@REDACTED Thu Jan 23 10:05:06 2003 From: Dolly095@REDACTED (Dolly095@REDACTED) Date: Thu, 23 Jan 2003 04:05:06 -0500 Subject: No subject Message-ID: <1B9E5D7B.4F95B949.0071F5FA@aol.com> hello do you know where i can download a sip proxy server for windows thank you From joe@REDACTED Thu Jan 23 11:04:20 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 23 Jan 2003 11:04:20 +0100 (CET) Subject: Why Erlang is the best concurrent language available In-Reply-To: <1043260886.1632.184.camel@berimbau> Message-ID: On 22 Jan 2003, martin j logan wrote: > I fully agree. I think that simplicity & practicality are some of the > prime virtues of erlang. These properties lend themselves to making any > language, system, or construction of any sort that is to be used by an > operator, better at allowing the operator to leverage the strength of > the tool and concentrate on the problem at hand and not on the vast > non-intuitive intricacies of the tool(enter C++ and pthreads). In my > honest opinion erlang is largely successful due to the coupling of its > smart paradigm, concurrency, and its simple straightforward (for the > most part) syntax and semantics. When looking at an erlang program it > is easy to see what it does - the code is, on the whole, short concise > and readable. Try saying the same for, or a step better, refactoring, a > program built with an advanced hybrid OO modular encapsulated statically > typed everything is an object except these five things - oh and you can > configure it with XML and... Like Joe says its all just too hard!!! > > Cheers, > Martin > Thank you Martin, yes - C++, java, ... etc. programming is too hard. My philosophy is "write as *beautiful* code as possible" - if it's too slow buy a faster machine. My 350 MHz celerion (at home) is fast enough for *everything* I I write in Erlang - (except video rendering :- - I tried, but it was to slow) - Projects fail because the SW does not work and *not* because the SW was too slow - remember this and you will have a long and happy life as a programmer. /Joe BTW - as programmers it is our job to write as inefficient code as possible - otherwise mass unemployment and economic disaster would strike the hardware industry with negative knock on effects for the entire economy. From etxuwig@REDACTED Thu Jan 23 13:14:41 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 23 Jan 2003 13:14:41 +0100 (MET) Subject: Why Erlang is the best concurrent language available In-Reply-To: Message-ID: On Thu, 23 Jan 2003, Joe Armstrong wrote: > My 350 MHz celerion (at home) is fast enough for >*everything* I I write in Erlang - (except video rendering >:- - I tried, but it was to slow) - Bah! That's nothing. I have a 90 MHz Pentium at home. (: (I also have a working 16 MHz Apple Powerbook Duo 270 and a working 32 MHz Powerbook 140 -- ah, the memories... The 140 boots up several times faster than my 400 MHz Windows 2000 laptop at work, and feels more responsive. Alas they cannot run Erlang (I've tried, but the old '93 vintage Mac port was too unstable to be useful.) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From etxuwig@REDACTED Thu Jan 23 13:42:52 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 23 Jan 2003 13:42:52 +0100 (MET) Subject: Structs (was RE: Record selectors) In-Reply-To: <15914.43540.628082.548532@harpo.it.uu.se> Message-ID: I have now read (OK, browsed) the "Reactive Objects and Functional Programming" thesis, and my understanding is that the O'Haskell version of the POTS program simply dodged the issue and pretended either (a) that the response from the hardware is either always immediate, or (b) control of the hardware simply could not go wrong. Moreover, O'Haskell does not allow the programmer to block or do selective receive. Concurrent Haskell does that, I believe, but not O'Haskell. The synchronous method invocation in O'Haskell can only be used in cases where the other party is guaranteed to return a value immediately. Thus, it would be an interesting challenge for someone to rewrite the O'Haskell POTS implementation such that it deals with the hardware properly (which the Erlang version actually does.) If I've understood the O'Haskell semantics correctly, the result will be less than elegant, but I welcome anyone to prove me wrong. (: /Uffe On Sun, 19 Jan 2003, Sven-Olof Nystr|m wrote: >Ulf Wiger writes: > > On Fri, 17 Jan 2003, Sean Hinde wrote: > > > > >Well, the comments to their version of the POTS program > > >from the Erlang book suggest that they see the erlang > > >ability to "selectively receive" to be merely a way of > > >avoiding deadlock, and they avoid such nastiness by > > >statically ensuring that all objects are capable of > > >receiving all valid messages at all times. > > > > I would say that this is a big misunderstanding. > > > > Selective receive is not at all about that, and forcing all > > objects to have to deal with all messages as they come in > > drastically complicates your state machine programming. > > > > Erlang's selective receive -- being able to pattern-match on > > the entire message queue -- is perhaps not absolutely > > necessary (even though it is sometimes extremely valuable), > > but what you need to have for complex state machine > > programming is (a) the ability to stop and wait for a > > specific message, and (b) the ability to single out one or a > > few senders, buffering any other messages until later. > > (This might also be achieved by having separate channels.) > > Without this, you end up having to invent quasi states in > > your code and introducing timing dependencies that will > > cause nightmares in testing. > > > > Let's take the POTS example to illustrate > > > > getting_first_digit() -> > > receive > > {lim, onhook} -> > > lim:stop_tone(), > > idle(); > > {lim, {digit, Digit}} -> > > lim:stop_tone(), > > getting_number(Digit, > > number:analyse( > > Digit, > > number:valid_sequences())); > > ... > > end. > > > > getting_number(Number, {incomplete, ValidSeqs}) -> > > receive > > {lim, onhook} -> > > idle(); > > {lim, {digit, Digit}} -> > > getting_number(10 * Number + Digit, > > number:analyse( > > Digit, > > ValidSeqs)); > > ... > > end. > > > > The function lim:stop_tone() actually involves sending a > > message to the hardware and waiting for a reply (selective > > receive). If we don't have that ability, we need to handle a > > stop_tone_reply message in our state machine. Now, what if > > the next digit comes in before stop_tone_reply? We must now > > introduce a state (receiving a digit while waiting for > > stop_tone_reply), and we must process the digit (in most > > other states, we may happily ignore a pressed digit.) > > > > In the specification of the state machine, this is not > > necessary. It's a product of our programming model. And it's > > a timing-dependent state, so we will have difficulty > > provoking it on a real system. We can easily see that there > > is absolutely no dependency in real life between the > > response from our hardware and the pressing of a button on > > the caller's phone. The dependency exists only in our > > implementation. > > > > If we introduce distribution, timing dependencies change, > > and our code may start breaking because of untested > > timing-dependent states in our code. The original Erlang > > state machine is resistant to such problems because it > > handles events in a logically sound order. > > > > _That's_ why selective receive is necessary. > >I suppose you have something like this in mind: > >(in module lim) > >stop_tone() -> > ! {stop, self()}, > receive > {ok, } -> > true > after ... > end. > >Implementing this without selective (matching) receive would require >the ability to create a new channel, something like this: > >stop_tone() -> > Ch = new_channel() % Create a new channel > ! {stop, Ch}, > receive(Ch) of % Read message from channel Ch > ok -> > true > after ... > end. > > >As far as I can see, the second solution introduces no new >complications in the state machine nor any new dependencies. I don't >know anything about the Haskell solution, but I wouldn't be surprised >if they are doing something similar. > >It would be interesting to see examples where matching receive >couldn't be replaced by the creation of a temporary channel. > >It seems to me that matching receive is just a way to compensate for >Erlang's inability to create temporary channels... > > >yours, > >Sven-Olof Nystr?m > > > > > -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From feeley@REDACTED Thu Jan 23 14:58:05 2003 From: feeley@REDACTED (Marc Feeley) Date: Thu, 23 Jan 2003 08:58:05 -0500 Subject: Why Erlang is the best concurrent language available In-Reply-To: (message from Joe Armstrong on Thu, 23 Jan 2003 11:04:20 +0100 (CET)) References: Message-ID: <200301231358.h0NDw5Y28879@dino00.iro.umontreal.ca> > BTW - as programmers it is our job to write as inefficient code as possible - > otherwise mass unemployment and economic disaster would strike the > hardware industry with negative knock on effects for the entire economy. Ha! Time to revise all my course notes and my teaching habits! Marc From jamesh@REDACTED Thu Jan 23 16:21:20 2003 From: jamesh@REDACTED (James Hague) Date: Thu, 23 Jan 2003 09:21:20 -0600 Subject: Why Erlang is the best concurrent language available Message-ID: Joe Armstrong wrote: >My philosophy is "write as *beautiful* code as >possible" - if it's too slow buy a faster machine. When I first saw you write this a few years ago, I laughed and disagreed, but now I'm a convert. "Beautiful" doesn't mean "dumb," but it does mean "clean and understandable," so there's a good chance that the beautiful code may end up being speedy anyway, because it's so easy to fiddle with. A project falls apart when the code gets so tangled and confusing that you're afraid to touch it, and, wow, is that an easy line to cross C or C++. Aside #1: I am *stunned* at how quick the Erlang compiler is, especially considering just how much stuff is going on under the hood, and how much the code leans on higher order functions. If someone tried to write the compiler in C, I doubt they could improve its performance (and I also doubt it would ever get finished!) Aside #2: I do think all the effort put into speeding up the Erlang emulator and runtime system has been well spent, though, as it makes my 333MHz P2 at home seem speedy :) From spearce@REDACTED Thu Jan 23 16:59:02 2003 From: spearce@REDACTED (Shawn Pearce) Date: Thu, 23 Jan 2003 10:59:02 -0500 Subject: Why Erlang is the best concurrent language available In-Reply-To: References: Message-ID: <20030123155902.GB29049@spearce.org> James Hague wrote: > Joe Armstrong wrote: > >My philosophy is "write as *beautiful* code as > >possible" - if it's too slow buy a faster machine. > > Aside #2: I do think all the effort put into speeding up the Erlang emulator > and runtime system has been well spent, though, as it makes my 333MHz P2 at > home seem speedy :) I think Joe's point is more about "write *beautiful* code that is correct" then worry about the speed once you have nothing else better to do. Unlike the Java VM, the Erlang runtime is small, lean and doesn't need much added to it with each release. Thus the C level guys working on that part of the system must have gotten bored at some point and spent a few minutes optimizing. :) Its better that its _correct_ though than it is fast. We have _enourmous_ stability problems with the Java VM here at work, and the company is starting to regret the millions we have poured into the Java platform because of its inherent instability. One of Erlang's best features is its STABLE! Most developers focus too early on speed and not enough on just writing clear, concise code that does only what is required of it (and correctly). Erlang developers are either just better, or the language allows them to more easily focus on these more important points of development (then overoptimizing too early). -- Shawn. From enewhuis@REDACTED Thu Jan 23 17:02:21 2003 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 23 Jan 2003 10:02:21 -0600 Subject: Why Erlang is the best concurrent language available References: Message-ID: <004501c2c2f8$d0274e30$34c2cf0a@futuresource.com> I don't have enough experience to pass judgement yet but so far I will say that Erlang is the best language that I have found for doing concurrent programming in an Extreme Programming environment. Erlang is a great language for testing Erlang. And I've not found any parallel in other languages that allows me to test the complexities of concurrency as easily as in Erlang. We have adopted an OO style whereby each module is a distinct active object. And our unit tests are developed along side each object. This is the most fun I've had writing software in my life. I've done C, C++, Java, K (like APL), C#, tiny amounts of Perl, VB, many other things, and now Erlang. I've even tried ObjectiveCaml. I've even tried Douglass Schmidt's Reactor in C++, both the ACE and my own proprietary stuff. So far, among all of these, Erlang seems the best for my problem space. There is only one stumbling block for my team right now. Because we don't know how to check for module dependencies during compilation time, when we refactor module names we sometimes forget to modify the import statements and it takes a long time to figure out why our unit tests break. I recall that there was some utility or feature that does module dependency checking but I think I need two things: 1. Within a module I want strict explicit import rules. I want the compiler to bark if I use a module that I haven't explicity imported. If not the compiler then some sort of tool I can invoke from make. 2. Among interdependent modules I want something to check that all modules actually exist before I run my code. I need something I can invoke from make. I think these are the two things that are holding us up from claiming that Erlang is ideal as Erlang can be. So once we figure out how to do these things we'll be very happy and convinced. Sincerely, Eric Newhuis From Sean.Hinde@REDACTED Thu Jan 23 17:26:49 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 23 Jan 2003 16:26:49 -0000 Subject: Why Erlang is the best concurrent language available Message-ID: xref is your friend. It will analyse a set of modules (e.g. a whole installation) for calls to non-existing functions in other modules. Sean > -----Original Message----- > From: Eric Newhuis [mailto:enewhuis@REDACTED] > Sent: 23 January 2003 16:02 > To: erlang-questions@REDACTED > Subject: Re: Why Erlang is the best concurrent language available > > > I don't have enough experience to pass judgement yet but so > far I will say > that Erlang is the best language that I have found for doing > concurrent > programming in an Extreme Programming environment. > > Erlang is a great language for testing Erlang. And I've not found any > parallel in other languages that allows me to test the complexities of > concurrency as easily as in Erlang. > > We have adopted an OO style whereby each module is a distinct > active object. > And our unit tests are developed along side each object. > > This is the most fun I've had writing software in my life. > I've done C, > C++, Java, K (like APL), C#, tiny amounts of Perl, VB, many > other things, > and now Erlang. I've even tried ObjectiveCaml. I've even > tried Douglass > Schmidt's Reactor in C++, both the ACE and my own proprietary stuff. > > So far, among all of these, Erlang seems the best for my > problem space. > > There is only one stumbling block for my team right now. > Because we don't > know how to check for module dependencies during compilation > time, when we > refactor module names we sometimes forget to modify the > import statements > and it takes a long time to figure out why our unit tests break. > > I recall that there was some utility or feature that does > module dependency > checking but I think I need two things: > > 1. Within a module I want strict explicit import rules. I > want the compiler > to bark if I use a module that I haven't explicity imported. > If not the > compiler then some sort of tool I can invoke from make. > > 2. Among interdependent modules I want something to check > that all modules > actually exist before I run my code. I need something I can > invoke from > make. > > I think these are the two things that are holding us up from > claiming that > Erlang is ideal as Erlang can be. So once we figure out how > to do these > things we'll be very happy and convinced. > > Sincerely, > Eric Newhuis > > 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 Chandrashekhar.Mullaparthi@REDACTED Thu Jan 23 17:28:15 2003 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Thu, 23 Jan 2003 16:28:15 -0000 Subject: Why Erlang is the best concurrent language available Message-ID: I agree with all comments made about why Erlang is so good. Learning erlang after programming in C, C++ and Java was pure joy. I loved it so much, I vowed that I wouldn't leave Ericsson until I found a job where I could use Erlang. Now it feels like I'm paid to have fun :) That aside, xref does all that you want and more. Checkout http://www.erlang.org/ml-archive/erlang-questions/200201/msg00085.html to see how you can integrate xref into your build process. Chandru -----Original Message----- From: Eric Newhuis [mailto:enewhuis@REDACTED] Sent: 23 January 2003 16:02 To: erlang-questions@REDACTED Subject: Re: Why Erlang is the best concurrent language available 1. Within a module I want strict explicit import rules. I want the compiler to bark if I use a module that I haven't explicity imported. If not the compiler then some sort of tool I can invoke from make. 2. Among interdependent modules I want something to check that all modules actually exist before I run my code. I need something I can invoke from make. I think these are the two things that are holding us up from claiming that Erlang is ideal as Erlang can be. So once we figure out how to do these things we'll be very happy and convinced. Sincerely, Eric Newhuis NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From Sean.Hinde@REDACTED Thu Jan 23 19:58:45 2003 From: Sean.Hinde@REDACTED (Sean Hinde) Date: Thu, 23 Jan 2003 18:58:45 -0000 Subject: Why Erlang is the best concurrent language available Message-ID: > Projects fail because the SW does not work and *not* because the SW > was too slow - remember this and you will have a long and happy life > as a programmer. Not always true.. We have a multi million pound project which needs to run at 200 calls per second - but after 2 years or trying (and buying almost the biggest UNIX machines we can find) has now reached the awesome speed of 20 per second. Scary! Sean NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From spearce@REDACTED Thu Jan 23 20:29:05 2003 From: spearce@REDACTED (Shawn Pearce) Date: Thu, 23 Jan 2003 14:29:05 -0500 Subject: Why Erlang is the best concurrent language available In-Reply-To: References: Message-ID: <20030123192905.GC29049@spearce.org> Sean Hinde wrote: > > Projects fail because the SW does not work and *not* because the SW > > was too slow - remember this and you will have a long and happy life > > as a programmer. > > Not always true.. We have a multi million pound project which needs to run > at 200 calls per second - but after 2 years or trying (and buying almost the > biggest UNIX machines we can find) has now reached the awesome speed of 20 > per second. Scary! Almost all projects fail because the SW does not work, and not because the software was too slow then. :) If you get over the correctness hurdle, then you can address the performance issue. Few projects are ever correct, many can perform well. Probably by not doing the work actually required. We're neither at work right now with the systems written in Java. These are 4 year old products too. (Not that 4 years old is old, but come on, 4 years and we have yet to be correct, let alone fast?) -- Shawn. From daniel.dudley@REDACTED Thu Jan 23 20:51:07 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Thu, 23 Jan 2003 20:51:07 +0100 Subject: Why Erlang is the best concurrent language available References: Message-ID: <001b01c2c318$c55468b0$85d1b33e@dld2000> Sean Hinde wrote: > > Projects fail because the SW does not work and *not* > > because the SW was too slow - remember this and you will > > have a long and happy life as a programmer. > > Not always true.. We have a multi million pound project which > needs to run at 200 calls per second - but after 2 years or > trying (and buying almost the biggest UNIX machines we can > find) has now reached the awesome speed of 20 per second. > Scary! Ow, such hair-raising tales are enough to shock a bald man! Damn it, where are my pills? :-) Daniel From cyberlync@REDACTED Thu Jan 23 21:29:31 2003 From: cyberlync@REDACTED (Eric Merritt) Date: Thu, 23 Jan 2003 12:29:31 -0800 (PST) Subject: Mnemosyne Problems? In-Reply-To: <001b01c2c318$c55468b0$85d1b33e@dld2000> Message-ID: <20030123202931.28375.qmail@web40808.mail.yahoo.com> Latly there have been a few posts (in the structs thread) that indicated that there were some serious problems with mnemosyne. I am not using it yet, but I have thought about using it in my next project and I would really like to know what the problems are before I get started. It would be great if some of you could elaborate on the problems you have had with mnemosyne. It looked like an elegant way to handle complex queries to me, so I would be very interested in your insights. Thanks, Eric __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com From mikael.karlsson@REDACTED Thu Jan 23 21:35:30 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Thu, 23 Jan 2003 21:35:30 +0100 Subject: Why Erlang is the best concurrent language available In-Reply-To: References: Message-ID: <200301232135.30359.mikael.karlsson@creado.com> Thursday 23 Jan 2003 11:04 Joe Armstrong wrote: > Projects fail because the SW does not work and *not* because the SW > was too slow - remember this and you will have a long and happy life > as a programmer. > > /Joe Ehhrm, so why do you show the Apache vs. Yaws comparison :-) http://www.sics.se/~joe/apachevsyaws.html Could it be that if you stay with Erlang your code will be fast enough, and faster than others in many cases. But if you use Java for instance you might be lost both ways, it won't work and it will be too slow. From joe@REDACTED Thu Jan 23 21:54:22 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 23 Jan 2003 21:54:22 +0100 (CET) Subject: Why Erlang is the best concurrent language available In-Reply-To: <200301232135.30359.mikael.karlsson@creado.com> Message-ID: On Thu, 23 Jan 2003, Mikael Karlsson wrote: > Thursday 23 Jan 2003 11:04 Joe Armstrong wrote: > > > Projects fail because the SW does not work and *not* because the SW > > was too slow - remember this and you will have a long and happy life > > as a programmer. > > > > /Joe > > Ehhrm, so why do you show the Apache vs. Yaws comparison :-) > http://www.sics.se/~joe/apachevsyaws.html Because yaws is faster than apache under conditions of load. Comment1: In the early days of Erlang Mike Williams and I discussed the "fast-sexy-optimized-possibly-incorrect" vs. "build-it-like-a-tank-slow-but-it-works" dilemma. We decided to leave out *all* tricky optimizations and concentrate on the simplest possible solutions that were guaranteed to work - that's probably one reason why the compiler is so fast - it doesn't do many optimizations - Roberts new compiler followed in this tradition - I guess the Erlang compiler is orders of magnitude smaller than most Java/Haskell compilers :-) Comment 2: In developing Erlang Robert and I had many discussions of the form "should we add optimizations" - we always said "no, we'll carry on as we are and add them later if we need them." - we discussed dirty destructive updates for *years* and were even prepared to add them if necessary - we always thought that "one day we'll have to add them" but since nobody had complained we left them out. Comment 3: For years I didn't do performance comparisons between Erlang and C because I *thought* without measuring that Erlang would be slower than C and that the results would be embarrassing. When we made some measurements (like in Yaws) Erlang turned out to be faster than C - the same story is true for Oz - at SICS we do Oz vs. Erlang battles for "who can do concurrency better" - amazingly *both* oz and Erlang are many orders of magnitude better than (Java/C#/C++/...) - we (at SICS) take this for granted (oh those languages ... *everybody knows that java concurrency sucks) - the *interesting* question is why is Oz better than Erlang or vice versa - we (the Oz and Erlang implementors) know why our languages are better than Java etc. Now its just the problem of convincing the other 99.99999999% of programmers :-) /Joe > > Could it be that if you stay with Erlang your code will be fast enough, > and faster than others in many cases. > But if you use Java for instance you might be lost both ways, it won't work > and it will be too slow. > From ulf.wiger@REDACTED Thu Jan 23 21:55:15 2003 From: ulf.wiger@REDACTED (Wiger Ulf) Date: Thu, 23 Jan 2003 21:55:15 +0100 Subject: Mnemosyne Problems? References: <20030123202931.28375.qmail@web40808.mail.yahoo.com> Message-ID: <004c01c2c321$bad5b520$f67a40d5@telia.com> I can only speak for the AXD 301 project. We decided early on not to use mnemosyne because it was too slow. I will qualify that: AXD 301 is at its core an ATM call control machine, and it's supposed to be really fast and responsive (e.g. ~100 calls/s per processor). We avoided mnemosyne for the same reason we would have avoided using SQL. We did not have complex enough queries that really warranted the use of mnemosyne anywhere, and it was never intended for real-time database accesses. Personally, I think mnemosyne is a great idea (albeit not for telecom switches). The thesis "SQL compiler for the Mnesia DBMS" (http://www.erlang.se/publications/xjobb/sql_compiler_report.pdf) lists a few things that should be fixed in mnemosyne, but also hints that it does a pretty good job already. Others who have actually used it more may have more information. I'd like to see the "bugs" in mnemosyne fixed and the SQL prototype productified, but someone has to want it badly enough... For historical reasons, it was never really given a chance to mature from prototype to product, but was basically just thrown into the first OTP together with mnesia. While mnesia _was_ extremely useful for telecoms and was put under high pressure to improve over the years, mnemosyne was not given the same attention. /Uffe ----- Original Message ----- From: "Eric Merritt" To: Sent: den 23 januari 2003 21:29 Subject: Mnemosyne Problems? > Latly there have been a few posts (in the structs > thread) that indicated that there were some serious > problems with mnemosyne. I am not using it yet, but I > have thought about using it in my next project and I > would really like to know what the problems are before > I get started. > > It would be great if some of you could elaborate on > the problems you have had with mnemosyne. It looked > like an elegant way to handle complex queries to me, > so I would be very interested in your insights. > > Thanks, > Eric > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com From spearce@REDACTED Thu Jan 23 21:58:35 2003 From: spearce@REDACTED (Shawn Pearce) Date: Thu, 23 Jan 2003 15:58:35 -0500 Subject: Why Erlang is the best concurrent language available In-Reply-To: <200301232135.30359.mikael.karlsson@creado.com> References: <200301232135.30359.mikael.karlsson@creado.com> Message-ID: <20030123205835.GE29049@spearce.org> Mikael Karlsson wrote: > Could it be that if you stay with Erlang your code will be fast enough, > and faster than others in many cases. > But if you use Java for instance you might be lost both ways, it won't work > and it will be too slow. I wholehartedly agree! Certainly has seemed to be the case in my limited Erlang experience. -- Shawn. From joe@REDACTED Thu Jan 23 22:05:38 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 23 Jan 2003 22:05:38 +0100 (CET) Subject: Why Erlang is the best concurrent language available In-Reply-To: Message-ID: On Thu, 23 Jan 2003, James Hague wrote: > Joe Armstrong wrote: > >My philosophy is "write as *beautiful* code as > >possible" - if it's too slow buy a faster machine. > > When I first saw you write this a few years ago, I laughed and disagreed, > but now I'm a convert. "Beautiful" doesn't mean "dumb," but it does mean > "clean and understandable," so there's a good chance that the beautiful code > may end up being speedy anyway, because it's so easy to fiddle with. A > project falls apart when the code gets so tangled and confusing that you're > afraid to touch it, and, wow, is that an easy line to cross C or C++. I never said "write dumb code" - to me beautiful code is clear, concise and does *exactly* what it is supposed to and *nothing* else with a minuimum of fuss. It usually ends up being faster than ugly code - that's because God likes your code if it's beautiful. Think of code as an exercise in applied poetry - rather like Haiku only more difficult - now writing Haiku Erlang functions *that* would be difficult > > Aside #1: I am *stunned* at how quick the Erlang compiler is, especially > considering just how much stuff is going on under the hood, and how much the > code leans on higher order functions. If someone tried to write the > compiler in C, I doubt they could improve its performance (and I also doubt > it would ever get finished!) Oh dear and there I was *appauled* at how slow it was :-) > > Aside #2: I do think all the effort put into speeding up the Erlang emulator > and runtime system has been well spent, though, as it makes my 333MHz P2 at > home seem speedy :) > It's not bad actually - hat's off to Bjorn and co. /Joe From luke@REDACTED Thu Jan 23 22:12:57 2003 From: luke@REDACTED (Luke Gorrie) Date: 23 Jan 2003 22:12:57 +0100 Subject: Why Erlang is the best concurrent language available In-Reply-To: References: Message-ID: Joe Armstrong writes: > On Thu, 23 Jan 2003, Mikael Karlsson wrote: > > > Thursday 23 Jan 2003 11:04 Joe Armstrong wrote: > > > > > Projects fail because the SW does not work and *not* because the SW > > > was too slow - remember this and you will have a long and happy life > > > as a programmer. > > > > Ehhrm, so why do you show the Apache vs. Yaws comparison :-) > > http://www.sics.se/~joe/apachevsyaws.html > > Because yaws is faster than apache under conditions of load. But then, Klacke has implemented Yaws with maximum performance in mind from the beginning, using lots of fancy tricks. :-) -Luke From jamesh@REDACTED Thu Jan 23 23:19:17 2003 From: jamesh@REDACTED (James Hague) Date: Thu, 23 Jan 2003 16:19:17 -0600 Subject: Why Erlang is the best concurrent language available Message-ID: Joe Armstrong wrote: > > I never said "write dumb code" - to me beautiful code > is clear, concise and does *exactly* what it is > supposed to and *nothing* else with a minuimum of > fuss. It usually ends up being faster than ugly > code - that's because God likes your code if it's > beautiful. Oh, I didn't mean to imply that you said to write dumb code--my apologies for that--but I think the typical reaction to what you consider "beautiful" code, at least from many programmers, is that it's horribly inefficient. If you really stop and think about what's going on in some Erlang programs, like "I build up this list backward, then I reverse it at the end, creating an entirely new copy of the list," then it *sounds* pretty appalling. But that reaction is out of context. When your frame of reference involves hundreds of millions or billions of cycles per second, with multiple machine instructions executing per cycle, well, that's the stuff of fairy tales. It's all so meaningless. I say to go ahead and make use of all that nonsense to make things wonderful and understandable, not an intangible savings of thousands of cycles here and there. :) James From daniel.dudley@REDACTED Fri Jan 24 03:32:54 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Fri, 24 Jan 2003 03:32:54 +0100 Subject: Why Erlang is the best concurrent language available References: Message-ID: <000f01c2c350$e68bd940$85d1b33e@dld2000> James Hague wrote: > Joe Armstrong wrote: > > > > I never said "write dumb code" - to me beautiful code > > is clear, concise and does *exactly* what it is > > supposed to and *nothing* else with a minuimum of > > fuss. It usually ends up being faster than ugly > > code - that's because God likes your code if it's > > beautiful. > > Oh, I didn't mean to imply that you said to write dumb code-- > my apologies for that--but I think the typical reaction to > what you consider "beautiful" code, at least from many > programmers, is that it's horribly inefficient. If you really > stop and think about what's going on in some Erlang programs, > like "I build up this list backward, then I reverse it at the > end, creating an entirely new copy of the list," then it > *sounds* pretty appalling. Well, it is appalling. Knowing that recursion "winds up" before it "winds down", why do it twice when once will suffice? (Hey, I'm a poet but didn't know it!) :-) > But that reaction is out of context. Really? Try adding some costs, ie money, to the operation. To most businesses, profitability is the driving context. > When your frame of reference involves hundreds of millions or > billions of cycles per second, with multiple machine > instructions executing per cycle, well, that's the stuff of > fairy tales. It's all so meaningless. I say to go ahead and > make use of all that nonsense to make things wonderful and > understandable, not an intangible savings of thousands of > cycles here and there. > > :) If an operation can be made more efficient, the result of which is an increase in turnover without an increase in costs, then inherent lack of efficiency *is* appalling. In other words, the opportunity to process more paying customers in the same time frame -- without adding to your costs, is hardly meaningless to the average businessman or -woman. That said, everything is relative; compared to other systems on the market, the Erlang way may not appear so meaningless. ;-) Should one rest on one's laurels? Well, no, because the competition is catching up. Regards, Daniel From matthias@REDACTED Fri Jan 24 11:02:14 2003 From: matthias@REDACTED (Matthias Lang) Date: Fri, 24 Jan 2003 11:02:14 +0100 Subject: Why Erlang is the best concurrent language available In-Reply-To: <000f01c2c350$e68bd940$85d1b33e@dld2000> References: <000f01c2c350$e68bd940$85d1b33e@dld2000> Message-ID: <15921.3878.894539.513218@antilipe.corelatus.se> > > "I build up this list backward, then I reverse it at the > > end, creating an entirely new copy of the list," then it > > *sounds* pretty appalling. > Well, it is appalling. Knowing that recursion "winds up" > before it "winds down", why do it twice when once will > suffice? Because tail recursion allows you to avoid the winding altogether. Avoiding the winding is useful because (a) it may help you avoid running out of memory and (b) it may be faster. See also: http://www.erlang.org/doc/r8b/doc/efficiency_guide/functions.html and http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-34.html#%_sec_5.4.2 Matthias From Vlad.Dumitrescu@REDACTED Fri Jan 24 12:46:44 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Fri, 24 Jan 2003 12:46:44 +0100 Subject: Why Erlang is the best concurrent language available Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6F1@esemont203.gbg.edt.ericsson.se> Hi, > > If you really > > stop and think about what's going on in some Erlang programs, > > like "I build up this list backward, then I reverse it at the > > end, creating an entirely new copy of the list," then it > > *sounds* pretty appalling. Well, isn't it an unefficiency only apparently (to the untrained eye)? The reason for doing this is *exactly* because it is more efficient than adding every time an item to the end of the list to be returned. regards, Vlad From Vlad.Dumitrescu@REDACTED Fri Jan 24 12:51:56 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Fri, 24 Jan 2003 12:51:56 +0100 Subject: Why Erlang is the best concurrent language available Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6F2@esemont203.gbg.edt.ericsson.se> Beauty is in the eye of the beholder, actually :-) I think Perl adepts would not fail to remind us that there are actually poems written in Perl. Don't know how useful those programs are, but that's another thing. I prefer to see it from a slightly different perspective (and I feel that nobody on this list will disagree with me :-) -- Erlang attracts to it the best programmers around, and then of course that the code is beautiful! [Well, I have to confess I've seen (and debugged) some really ugly Erlang code, but I conject that those programmers used Erlang only because the employer forced them to, not because they were attracted by it] regards, Vlad From joe@REDACTED Fri Jan 24 12:57:46 2003 From: joe@REDACTED (Joe Armstrong) Date: Fri, 24 Jan 2003 12:57:46 +0100 (CET) Subject: Why Erlang is the best concurrent language available In-Reply-To: <000f01c2c350$e68bd940$85d1b33e@dld2000> Message-ID: On Fri, 24 Jan 2003, Daniel Dudley wrote: > James Hague wrote: > > Joe Armstrong wrote: > > > > > > I never said "write dumb code" - to me beautiful code > > > is clear, concise and does *exactly* what it is > > > supposed to and *nothing* else with a minuimum of > > > fuss. It usually ends up being faster than ugly > > > code - that's because God likes your code if it's > > > beautiful. > > > > Oh, I didn't mean to imply that you said to write dumb code-- > > my apologies for that--but I think the typical reaction to > > what you consider "beautiful" code, at least from many > > programmers, is that it's horribly inefficient. If you really > > stop and think about what's going on in some Erlang programs, > > like "I build up this list backward, then I reverse it at the > > end, creating an entirely new copy of the list," then it > > *sounds* pretty appalling. > > Well, it is appalling. Knowing that recursion "winds up" > before it "winds down", why do it twice when once will > suffice? (Hey, I'm a poet but didn't know it!) :-) > > > But that reaction is out of context. > > Really? Try adding some costs, ie money, to the operation. > To most businesses, profitability is the driving context. > > > When your frame of reference involves hundreds of millions or > > billions of cycles per second, with multiple machine > > instructions executing per cycle, well, that's the stuff of > > fairy tales. It's all so meaningless. I say to go ahead and > > make use of all that nonsense to make things wonderful and > > understandable, not an intangible savings of thousands of > > cycles here and there. > > > > :) Business people say that the most important thing is "time to market" - that's why you should use Erlang (if the language is appropriate for you problem) The Bluetail idea was "use Erlang to get products to market before the competition" - the idea worked - and we made tons of money. Nortel is now cranking out products in Erlang quicker than the opposition. Now luck comes in to the equation - have Nortel chosen the right products? - all other things being equal companies using Erlang will slaughter companies using Java and C++ - Just like C slaughtered assembler. It is commercial pressure that will cause Erlang to succeed - now this might not happen with Erlang - bit it will happen one day with a language in the Erlang/Prolog/Haskell/Miranda/... school. The funny thing is the suits say "give us time to market" - but they are scared when you deliver ... The management wet-dream is to use employ Apes give them "me too" technology and produce "world class innovate products" - forget it. If you want to be first to market you have to do something "different" to all the rest. Easy, use a better technology than the competition. > > If an operation can be made more efficient, the result of > which is an increase in turnover without an increase in > costs, then inherent lack of efficiency *is* appalling. In > other words, the opportunity to process more paying > customers in the same time frame -- without adding to your > costs, is hardly meaningless to the average businessman or > -woman. > > That said, everything is relative; compared to other > systems on the market, the Erlang way may not appear so > meaningless. ;-) Should one rest on one's laurels? Well, > no, because the competition is catching up. Great - let's have a fight /Joe From svg@REDACTED Fri Jan 24 08:36:55 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Fri, 24 Jan 2003 12:36:55 +0500 (YEKT) Subject: Why Erlang is the best concurrent language available In-Reply-To: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6F2@esemont203.gbg.edt.ericsson.se> References: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6F2@esemont203.gbg.edt.ericsson.se> Message-ID: <20030124.123655.41638193.svg@surnet.ru> Good day, Vlad.Dumitrescu> I think Perl adepts would not fail to remind us that Vlad.Dumitrescu> there are actually poems written in Perl. Don't know how useful those Vlad.Dumitrescu> programs are, but that's another thing. It wouldn't fail to remind Perl adepts that latest Perl hit POE (http://poe.perl.org/) looks like ugly implementation of core Erlang and small OTP stuff. Best Regards, Vladimir Sekissov Vlad.Dumitrescu> Beauty is in the eye of the beholder, actually :-) Vlad.Dumitrescu> Vlad.Dumitrescu> I think Perl adepts would not fail to remind us that there are actually poems written in Perl. Don't know how useful those programs are, but that's another thing. Vlad.Dumitrescu> Vlad.Dumitrescu> I prefer to see it from a slightly different perspective (and I feel that nobody on this list will disagree with me :-) -- Erlang attracts to it the best programmers around, and then of course that the code is beautiful! Vlad.Dumitrescu> Vlad.Dumitrescu> [Well, I have to confess I've seen (and debugged) some really ugly Erlang code, but I conject that those programmers used Erlang only because the employer forced them to, not because they were attracted by it] Vlad.Dumitrescu> Vlad.Dumitrescu> regards, Vlad.Dumitrescu> Vlad From mikael.karlsson@REDACTED Fri Jan 24 14:22:52 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Fri, 24 Jan 2003 14:22:52 +0100 Subject: Why Erlang is the best concurrent language available In-Reply-To: References: Message-ID: <200301241422.53006.mikael.karlsson@creado.com> Thursday 23 Jan 2003 Luke Gorrie: > Joe Armstrong writes: > > On Thu, 23 Jan 2003, Mikael Karlsson wrote: > > > Thursday 23 Jan 2003 11:04 Joe Armstrong wrote: > > > > Projects fail because the SW does not work and *not* because the > > > > SW was too slow - remember this and you will have a long and happy > > > > life as a programmer. > > > > > > Ehhrm, so why do you show the Apache vs. Yaws comparison :-) > > > http://www.sics.se/~joe/apachevsyaws.html > > > > Because yaws is faster than apache under conditions of load. > > But then, Klacke has implemented Yaws with maximum performance in mind > from the beginning, using lots of fancy tricks. :-) > > -Luke Simplicity, practicality, stability etc. is mentioned as why Erlang is the best concurrent language available. I agree. But the fact that it performs well or even excellent does not make things worse. My point was, I think :-), that if you use Erlang in it's application domain (concurrency), you can focus on get things working. Performance is something that you get anyway, thanks Joe et. al. :-), so you can have a long and happy life as a programmer. This is not true for all other languages. I think Yaws, let it be that it is tweaked and optimized by brilliant Erlang programmers, actually points out the concurrent world of Web applications as a field were Erlang can be a killer app. It seems that most Web application frameworks like jboss, tomcat, zope etc are built aroung Java (Python in Zope's case), and I am not so sure that performance may not be an issue when you want to add things like PKI/SSL, XML transforms, reverse proxying, ODBC connections etc. Especially if your organisation do not afford the latest cluster of Enterprise Servers. And if you get the things faster out of the door as well.... I would really like to see Erlang going in the directions of web application/services, and not only remain as OTP, THE Telecom platform. /Mikael From etxuwig@REDACTED Fri Jan 24 14:31:17 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 24 Jan 2003 14:31:17 +0100 (MET) Subject: Why Erlang is the best concurrent language available In-Reply-To: <200301241422.53006.mikael.karlsson@creado.com> Message-ID: On Fri, 24 Jan 2003, Mikael Karlsson wrote: >I would really like to see Erlang going in the directions >of web application/services, and not only remain as OTP, >THE Telecom platform. No, that would be TTP. TTP is designed in GOL (http://www.erlang.org/ml-archive/erlang-questions/200301/msg00135.html), and, like GOL, TTP varies with time. (: /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From garry@REDACTED Fri Jan 24 14:37:03 2003 From: garry@REDACTED (Garrett G. Hodgson) Date: Fri, 24 Jan 2003 08:37:03 -0500 Subject: Why Erlang is the best concurrent language available In-Reply-To: Message from "Daniel Dudley" of "Fri, 24 Jan 2003 03:32:54 +0100." <000f01c2c350$e68bd940$85d1b33e@dld2000> Message-ID: <200301241337.h0ODb3p01981@kestrel.sage.att.com> > James Hague wrote: > > Oh, I didn't mean to imply that you said to write dumb code-- > > my apologies for that--but I think the typical reaction to > > what you consider "beautiful" code, at least from many > > programmers, is that it's horribly inefficient. If you really > > stop and think about what's going on in some Erlang programs, > > like "I build up this list backward, then I reverse it at the > > end, creating an entirely new copy of the list," then it > > *sounds* pretty appalling. > > Well, it is appalling. Knowing that recursion "winds up" > before it "winds down", why do it twice when once will > suffice? (Hey, I'm a poet but didn't know it!) :-) > > > But that reaction is out of context. > > Really? Try adding some costs, ie money, to the operation. > To most businesses, profitability is the driving context. to most businesses, cost of cpu cycles is way cheaper than cost of development and maintenance. profitability involves time to market, life cycle costs, etc. hardware gets cheaper every day. people don't. > > When your frame of reference involves hundreds of millions or > > billions of cycles per second, with multiple machine > > instructions executing per cycle, well, that's the stuff of > > fairy tales. It's all so meaningless. I say to go ahead and > > make use of all that nonsense to make things wonderful and > > understandable, not an intangible savings of thousands of > > cycles here and there. > > > > :) > > If an operation can be made more efficient, the result of > which is an increase in turnover without an increase in > costs, yes. "without an increase in costs" is the problem, though. the world is full of buggy systems prematurely optimized and difficult to maintain. -- Garry Hodgson Let my inspiration flow Senior Hacker in token rhyme suggesting rhythm Software Innovation Services that will not forsake me AT&T Labs 'til my tale is told and done. garry@REDACTED From luke@REDACTED Fri Jan 24 15:35:05 2003 From: luke@REDACTED (Luke Gorrie) Date: 24 Jan 2003 15:35:05 +0100 Subject: Why Erlang is the best concurrent language available In-Reply-To: <15921.3878.894539.513218@antilipe.corelatus.se> References: <000f01c2c350$e68bd940$85d1b33e@dld2000> <15921.3878.894539.513218@antilipe.corelatus.se> Message-ID: Matthias Lang writes: > > > "I build up this list backward, then I reverse it at the > > > end, creating an entirely new copy of the list," then it > > > *sounds* pretty appalling. > > > Well, it is appalling. Knowing that recursion "winds up" > > before it "winds down", why do it twice when once will > > suffice? > > Because tail recursion allows you to avoid the winding altogether. > > Avoiding the winding is useful because (a) it may help you avoid > running out of memory and (b) it may be faster. Efficiency-hack-wise, see also a thread on this list from about a year ago, where a lot of different implementations of the same stack-using recursive function were benchmarked. Richard Carlsson summarised the results in: http://www.erlang.org/ml-archive/erlang-questions/200110/msg00024.html But I reckon a seriously cool feature of the Erlang implementation is that you *can* build up a huge stack and unwind it if you want to, which tends to be pretty often for me. Consider the implementation of 'map' from lists.erl: map(F, [H|T]) -> [F(H)|map(F, T)]; map(_, []) -> []. This "blindingly obvious" implementation is perfectly correct and works just fine even for very large lists. It's a very nice way for code to be, and life is good :-) Surprisingly this is *not* the case in many implementations of other languages, even when they have the same recursive programming style as Erlang, like Scheme and ML. The trouble is that they put artificial limits on stack usage, so that if you have tens- or hundreds of thousands of elements in a list (which isn't *that* much), you will segfault by blowing the stack. Segfault! The accumulator+reverse() version does work with large lists, however, so you have to use it even when it's just more coding to say the same thing, unless you can somehow know that all your list arguments will be small. So, I reckon it's great that Erlang makes the "blindingly obvious" code actually work properly, and you don't have to always use fancy tricks in your "production" code for fear of horrible crashes. Richard's benchmark suggests you could write a more efficient map using fancy tricks, but I think this is like the C trick of counting down towards 0 in 'for' loops to save a comparison instruction: it might give you the boost you need in a few cases, but it's nice that most code doesn't need to be written like that. Just my 10 ?re (that's two Australian cents :-)) Cheers, Luke From luke@REDACTED Fri Jan 24 15:42:28 2003 From: luke@REDACTED (Luke Gorrie) Date: 24 Jan 2003 15:42:28 +0100 Subject: Why Erlang is the best concurrent language available In-Reply-To: References: <000f01c2c350$e68bd940$85d1b33e@dld2000> <15921.3878.894539.513218@antilipe.corelatus.se> Message-ID: Luke Gorrie writes: > Consider the implementation of 'map' from lists.erl: > > map(F, [H|T]) -> > [F(H)|map(F, T)]; > map(_, []) -> []. BTW, here's another style of writing those functions, which I find completely impenetrable :-). It's a grand-unified backend for the various types of map functions, from the list module of a Lisp system I've been playing with: (defun map1 (function original-arglists accumulate take-car) "This function is called by mapc, mapcar, mapcan, mapl, maplist, and mapcon. It Maps function over the arglists in the appropriate way. It is done when any of the arglists runs out. Until then, it CDRs down the arglists calling the function and accumulating results as desired." (let* ((arglists (copy-list original-arglists)) (ret-list (list nil)) (temp ret-list)) (do ((res nil) (args '() '())) ((dolist (x arglists nil) (if (null x) (return t))) (if accumulate (cdr ret-list) (car original-arglists))) (do ((l arglists (cdr l))) ((null l)) (push (if take-car (caar l) (car l)) args) (setf (car l) (cdar l))) (setq res (apply function (nreverse args))) (case accumulate (:nconc (setq temp (last (nconc temp res)))) (:list (rplacd temp (list res)) (setq temp (cdr temp))))))) I really prefer the Erlang style, even if you need to write each function separately :-) Cheers, Luke From jamesh@REDACTED Fri Jan 24 16:26:35 2003 From: jamesh@REDACTED (James Hague) Date: Fri, 24 Jan 2003 09:26:35 -0600 Subject: Why Erlang is the best concurrent language available Message-ID: Note! This completely off of the original subject! :) Luke Gorrie wrote: >But I reckon a seriously cool feature of the Erlang >implementation is that you *can* build up a huge stack >and unwind it if you want to, which tends to be pretty >often for me. Consider the implementation of >'map' from lists.erl: > > map(F, [H|T]) -> > [F(H)|map(F, T)]; > map(_, []) -> []. Ah, but technically that's tail recursive modulo cons (i.e. the only thing keeping it from being tail recursive is that you need the result in order to build a cons cell). If you were writing this in Scheme, you could keep a pointer to the end of the list and the whole thing would be tail recursive (and at least all of that nonsense would be hidden inside of map). Some Prolog compilers do this automatically. (I don't think Erlang desperately needs this--though sure, it would be cool--but lack of this is something that might look 'horrifying' to someone not used to writing code in functional languages.) P.S. I still love how list comprehensions have made map obsolete: map(F, L) -> [F(X) || X <- L]. From daniel.dudley@REDACTED Fri Jan 24 16:26:49 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Fri, 24 Jan 2003 16:26:49 +0100 Subject: Why Erlang is the best concurrent language available References: <000f01c2c350$e68bd940$85d1b33e@dld2000><15921.3878.894539.513218@antilipe.corelatus.se> Message-ID: <006801c2c3bd$0385c990$85d1b33e@dld2000> Enlightening stuff, Luke. I particularly liked -- and feel comfortable with -- your map example, which is reminicent of "the Prolog way" of processing lists (in most cases). Yep, your 10 ?re was well spent. ;-) Cheers, Daniel ----- Original Message ----- From: "Luke Gorrie" To: Sent: Friday, January 24, 2003 3:35 PM Subject: Re: Why Erlang is the best concurrent language available Matthias Lang writes: > > > "I build up this list backward, then I reverse it at the > > > end, creating an entirely new copy of the list," then it > > > *sounds* pretty appalling. > > > Well, it is appalling. Knowing that recursion "winds up" > > before it "winds down", why do it twice when once will > > suffice? > > Because tail recursion allows you to avoid the winding altogether. > > Avoiding the winding is useful because (a) it may help you avoid > running out of memory and (b) it may be faster. Efficiency-hack-wise, see also a thread on this list from about a year ago, where a lot of different implementations of the same stack-using recursive function were benchmarked. Richard Carlsson summarised the results in: http://www.erlang.org/ml-archive/erlang-questions/200110/msg00024.html But I reckon a seriously cool feature of the Erlang implementation is that you *can* build up a huge stack and unwind it if you want to, which tends to be pretty often for me. Consider the implementation of 'map' from lists.erl: map(F, [H|T]) -> [F(H)|map(F, T)]; map(_, []) -> []. This "blindingly obvious" implementation is perfectly correct and works just fine even for very large lists. It's a very nice way for code to be, and life is good :-) Surprisingly this is *not* the case in many implementations of other languages, even when they have the same recursive programming style as Erlang, like Scheme and ML. The trouble is that they put artificial limits on stack usage, so that if you have tens- or hundreds of thousands of elements in a list (which isn't *that* much), you will segfault by blowing the stack. Segfault! The accumulator+reverse() version does work with large lists, however, so you have to use it even when it's just more coding to say the same thing, unless you can somehow know that all your list arguments will be small. So, I reckon it's great that Erlang makes the "blindingly obvious" code actually work properly, and you don't have to always use fancy tricks in your "production" code for fear of horrible crashes. Richard's benchmark suggests you could write a more efficient map using fancy tricks, but I think this is like the C trick of counting down towards 0 in 'for' loops to save a comparison instruction: it might give you the boost you need in a few cases, but it's nice that most code doesn't need to be written like that. Just my 10 ?re (that's two Australian cents :-)) Cheers, Luke From daniel.dudley@REDACTED Fri Jan 24 16:40:42 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Fri, 24 Jan 2003 16:40:42 +0100 Subject: Why Erlang is the best concurrent language available References: <000f01c2c350$e68bd940$85d1b33e@dld2000> <15921.3878.894539.513218@antilipe.corelatus.se> Message-ID: <006901c2c3be$f43e4780$85d1b33e@dld2000> I'm aware that tail-recursion can be implemented (behind- the-scenes) as iteration, Matthias, and thus reduce stack usage. But without use of reference variables the need to specifically reverse the list still remains. Cheers, Daniel ----- Original Message ----- From: "Matthias Lang" To: "Daniel Dudley" Cc: Sent: Friday, January 24, 2003 11:02 AM Subject: Re: Why Erlang is the best concurrent language available > > > "I build up this list backward, then I reverse it at the > > > end, creating an entirely new copy of the list," then it > > > *sounds* pretty appalling. > > > Well, it is appalling. Knowing that recursion "winds up" > > before it "winds down", why do it twice when once will > > suffice? > > Because tail recursion allows you to avoid the winding altogether. > > Avoiding the winding is useful because (a) it may help you avoid > running out of memory and (b) it may be faster. See also: > > http://www.erlang.org/doc/r8b/doc/efficiency_guide/functions.html > > and > > http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-34.html#%_sec_5.4 .2 > > Matthias From DANIESC.SCHUTTE@REDACTED Fri Jan 24 16:41:49 2003 From: DANIESC.SCHUTTE@REDACTED (DANIESC SCHUTTE) Date: Fri, 24 Jan 2003 17:41:49 +0200 Subject: Greetings all, Message-ID: Greetings all, I would like to enquire about where I can look for clues as to why I get this message. The system is running on two nodes and the dbi_crm application is running on the db@REDACTED server. Executing the same command on the database server itself, gives me a correct response. Both nodes can see each other. Any suggestions? (tebacrm@REDACTED)1> dbi_crm:get_crm_008('01'). ** exited: {undef,[{dbi_crm,get_crm_008,['01']}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** (tebacrm@REDACTED)2> Regards Danie Schutte Danie Schutte Phone: +27 - 11 - 203 - 1613 Mobile: 084-468-3138 e-Mail: Daniesc@REDACTED ##################################################################################### 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 and copies. ##################################################################################### From Chandrashekhar.Mullaparthi@REDACTED Fri Jan 24 17:06:57 2003 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Fri, 24 Jan 2003 16:06:57 -0000 Subject: Greetings all, Message-ID: Check that the module is loaded using m(dbi_crm). or dbi_crm:module_info(). If the module is not loaded, it is probably not in the code path. use code:add_patha/1 to add a directory in which the VM will look for beam files. Use code:get_path/0 to see the list of directories which will be searched for beam files. Chandru -----Original Message----- From: DANIESC SCHUTTE [mailto:DANIESC.SCHUTTE@REDACTED] Sent: 24 January 2003 15:42 To: < Subject: Greetings all, Greetings all, I would like to enquire about where I can look for clues as to why I get this message. The system is running on two nodes and the dbi_crm application is running on the db@REDACTED server. Executing the same command on the database server itself, gives me a correct response. Both nodes can see each other. Any suggestions? (tebacrm@REDACTED)1> dbi_crm:get_crm_008('01'). ** exited: {undef,[{dbi_crm,get_crm_008,['01']}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** (tebacrm@REDACTED)2> Regards Danie Schutte NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From luke@REDACTED Fri Jan 24 17:01:20 2003 From: luke@REDACTED (Luke Gorrie) Date: 24 Jan 2003 17:01:20 +0100 Subject: Greetings all, In-Reply-To: References: Message-ID: "DANIESC SCHUTTE" writes: > I would like to enquire about where I can look for clues as to > why I get this message. The system is running on two nodes and > the dbi_crm application is running on the db@REDACTED > server. Executing the same command on the database server > itself, gives me a correct response. Both nodes can see each > other. Any suggestions? I'm not sure if there is a higher-level problem, but: > (tebacrm@REDACTED)1> dbi_crm:get_crm_008('01'). > ** exited: {undef,[{dbi_crm,get_crm_008,['01']}, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This means that the function dbi_crm:get_crm_008/1 doesn't exist in that node, possibly because it can't find the dbi_crm module in its load path. If you wanted to run the code over on the DB node using an RPC, you could say: rpc:call('db@REDACTED', dbi_crm, get_crm_008, ['01']). -Luke From etxuwig@REDACTED Fri Jan 24 17:11:35 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 24 Jan 2003 17:11:35 +0100 (MET) Subject: Greetings all, In-Reply-To: Message-ID: The module dbi_crm must be loaded on the node where you call the function. It seems as if it _is_ loaded on the db node, but not on the tebacrm node. (Chandru already wrote this in another msg.) The normal way to write multi-node Erlang applications is to load all the code on all nodes. Remember that beam files are very compact, so you won't sacrifice much memory. You may then start different applications on each node, but all the code is available everywhere. The advantage of this is that you may hide the rpc calls behind the API functions of the application. ...or you do what Luke just wrote: use rpc:call(). /Uffe On Fri, 24 Jan 2003, DANIESC SCHUTTE wrote: >Greetings all, > I would like to enquire about where I can look for clues >as to why I get this message. The system is running on two >nodes and the dbi_crm application is running on the >db@REDACTED server. Executing the same command >on the database server itself, gives me a correct response. >Both nodes can see each other. Any suggestions? > >(tebacrm@REDACTED)1> dbi_crm:get_crm_008('01'). >** exited: {undef,[{dbi_crm,get_crm_008,['01']}, > {erl_eval,expr,3}, > {erl_eval,exprs,4}, > {shell,eval_loop,2}]} ** >(tebacrm@REDACTED)2> > >Regards >Danie Schutte > >Danie Schutte >Phone: +27 - 11 - 203 - 1613 >Mobile: 084-468-3138 >e-Mail: Daniesc@REDACTED > >##################################################################################### >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 and copies. >##################################################################################### > -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From daniel.dudley@REDACTED Fri Jan 24 17:16:30 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Fri, 24 Jan 2003 17:16:30 +0100 Subject: Why Erlang is the best concurrent language available References: Message-ID: <00a301c2c3c3$f4bdbe70$85d1b33e@dld2000> Your reference to Prolog compilers that keep a pointer to the end of the list is what I was thinking about in my last message (to Luke). Yes, it would be nice to see this implemented in Erlang, but then again there's list comprehension... (I'll have to give this some thought!) Cheers, Daniel ----- Original Message ----- From: "James Hague" To: Sent: Friday, January 24, 2003 4:26 PM Subject: Re: Why Erlang is the best concurrent language available > Note! This completely off of the original subject! :) > > Luke Gorrie wrote: > >But I reckon a seriously cool feature of the Erlang > >implementation is that you *can* build up a huge stack > >and unwind it if you want to, which tends to be pretty > >often for me. Consider the implementation of > >'map' from lists.erl: > > > > map(F, [H|T]) -> > > [F(H)|map(F, T)]; > > map(_, []) -> []. > > Ah, but technically that's tail recursive modulo cons (i.e. the > only thing keeping it from being tail recursive is that you need > the result in order to build a cons cell). If you were writing > this in Scheme, you could keep a pointer to the end of the list > and the whole thing would be tail recursive (and at least all of > that nonsense would be hidden inside of map). Some Prolog > compilers do this automatically. > > (I don't think Erlang desperately needs this--though sure, ite > would b cool--but lack of this is something that might look > 'horrifying' to someone not used to writing code in functional > languages.) > > P.S. I still love how list comprehensions have made map obsolete: > > map(F, L) -> [F(X) || X <- L]. From daniel.dudley@REDACTED Fri Jan 24 17:43:01 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Fri, 24 Jan 2003 17:43:01 +0100 Subject: Why Erlang is the best concurrent language available References: <00a301c2c3c3$f4bdbe70$85d1b33e@dld2000> Message-ID: <010d01c2c3c7$a89d1410$85d1b33e@dld2000> Rather sloppy of me, but the reference to my last message should have been (Matthias), not (Luke). Sorry for any confusion this may have caused. Daniel ----- Original Message ----- From: "Daniel Dudley" To: "James Hague" ; Sent: Friday, January 24, 2003 5:16 PM Subject: Re: Why Erlang is the best concurrent language available > Your reference to Prolog compilers that keep a pointer to > the end of the list is what I was thinking about in my > last message (to Luke). Yes, it would be nice to see this > implemented in Erlang, but then again there's list > comprehension... (I'll have to give this some thought!) > > Cheers, > Daniel [snipped] From daniel.dudley@REDACTED Sat Jan 25 05:17:16 2003 From: daniel.dudley@REDACTED (Daniel Dudley) Date: Sat, 25 Jan 2003 05:17:16 +0100 Subject: Record selectors References: <009f01c2b287$67808440$18d1b33e@dld2000> <001b01c2b4a7$4dcb9180$26d0b33e@dld2000> <001401c2ba16$7947a320$26d0b33e@dld2000> Message-ID: <000901c2c428$a50bdff0$85d1b33e@dld2000> Here are some papers that may be of interest to the community. Judge freely, there may be some useful stuff in the context of this thread. http://www.cs.washington.edu/research/projects/cecil/www/research.html Daniel ----- Original Message ----- From: "Daniel Dudley" To: "erlang-questions" Sent: Sunday, January 12, 2003 9:42 AM Subject: Re: Record selectors > Thanks for your imput, lads. I think I'll conclude that > Erlang's implementation of records is a mess (a wart on > Erlang's bottom as Matthias puts it) and thus best avoided. > They must be a big embarrassment to Erlang. In fact, I > should think it would be a great service to the community > if records (in their current form) were phased out as soon > as possible. Call it an experiment that went horribly wrong. > > Chris proposes that country (for example) be a real, > unique, opaque type that couldn't be confused with any > other type. I couldn't agree more; record is a type that > has specific subtypes. This is analogous to objects, which > are derived from an abstract base object. Clearly > implementable (efficiently and safely) without use of > 'orrible syntax. > > I'm disheartened now, but I do remain hopeful of soon-to-be > encouraging changes. > > Cheers, > Daniel From shrogers@REDACTED Sat Jan 25 07:21:53 2003 From: shrogers@REDACTED (steve@shrogers.com) Date: Sat, 25 Jan 2003 00:21:53 -0600 (GMT) Subject: R9 toolbar and Red Hat 8 Message-ID: <47173.1043472281356.JavaMail.nobody@wamui03.slb.atl.earthlink.net> I've compiled Erlang/OTP R9 on Red Hat 8.0 and Erlang seems to work for command line programs but I can't lanuch the toolbar. I get the following error. erl -s toolbar Erlang (BEAM) emulator version 5.2 [source] [hipe] Eshell V5.2 (abort with ^G) 1> {"init terminating in do_boot",{startup_timeout,toolbar}} init terminating in do_boot () I see in the release notes that R9 uses Tcl/Tk 8.3.4 while RH 8 has 8.3.3. Could this be the source of my problem, or should I be looking elsewhere? Regards, Steve From bjorn.bylander@REDACTED Sat Jan 25 11:54:35 2003 From: bjorn.bylander@REDACTED (=?ISO-8859-15?Q?Bj=F6rn_Bylander?=) Date: Sat, 25 Jan 2003 11:54:35 +0100 Subject: R9 toolbar and Red Hat 8 In-Reply-To: <47173.1043472281356.JavaMail.nobody@wamui03.slb.atl.earthlink.net> References: <47173.1043472281356.JavaMail.nobody@wamui03.slb.atl.earthlink.net> Message-ID: <3E326CEB.4000905@telia.com> steve@REDACTED wrote: > I've compiled Erlang/OTP R9 on Red Hat 8.0 and Erlang seems to work for command line programs but I can't lanuch the toolbar. I get the following error. > > erl -s toolbar > Erlang (BEAM) emulator version 5.2 [source] [hipe] > > Eshell V5.2 (abort with ^G) > 1> {"init terminating in do_boot",{startup_timeout,toolbar}} > init terminating in do_boot () > > I see in the release notes that R9 uses Tcl/Tk 8.3.4 while RH 8 has 8.3.3. Could this be the source of my problem, or should I be looking elsewhere? I'm using Red Hat 8.0 and Erlang/OTP R9 too with Tcl/Tk 8.3.3. The toolbar works fine for me. > > Regards, > Steve > Regards, Bj?rn From kent@REDACTED Sat Jan 25 16:56:43 2003 From: kent@REDACTED (Kent Boortz) Date: 25 Jan 2003 16:56:43 +0100 Subject: R9 toolbar and Red Hat 8 In-Reply-To: <47173.1043472281356.JavaMail.nobody@wamui03.slb.atl.earthlink.net> References: <47173.1043472281356.JavaMail.nobody@wamui03.slb.atl.earthlink.net> Message-ID: "steve@REDACTED" writes: > I've compiled Erlang/OTP R9 on Red Hat 8.0 and Erlang seems to work > for command line programs but I can't lanuch the toolbar. I get the > following error. > > erl -s toolbar > Erlang (BEAM) emulator version 5.2 [source] [hipe] > > Eshell V5.2 (abort with ^G) > 1> {"init terminating in do_boot",{startup_timeout,toolbar}} > init terminating in do_boot () > > I see in the release notes that R9 uses Tcl/Tk 8.3.4 while RH 8 has > 8.3.3. Could this be the source of my problem, or should I be > looking elsewhere? Does it take unusual long time to run the "wish8.3" or "wish" program? If you start a new shell and it takes a long time to start "wish8.3" the first time but not after that then it can be that your PATH is incorrect, i.e. points to a non existing directory that the operating system try to automount or something but fails after a long timeout. Is it working if you start erlang first and then start the toolbar? % erl Erlang (BEAM) emulator version 5.2 [source] [hipe] 1> toolbar:start(). If it still times out, do you have the same problem if you start GS first? % erl Erlang (BEAM) emulator version 5.2 [source] [hipe] 1> gs:start([{kernel,true}]). 2> toolbar:start(). kent From shrogers@REDACTED Sat Jan 25 21:44:28 2003 From: shrogers@REDACTED (steve@shrogers.com) Date: Sun, 26 Jan 2003 04:44:28 0800 (UTC) Subject: R9 toolbar and Red Hat 8 Message-ID: <3382545.1043574271085.JavaMail.nobody@wamui01.slb.atl.earthlink.net> Thanks for the suggestions. It turned out that I'd neglected to install Tk when I installed Tcl. After correcting this omission, it works like a charm. Regards, Steve From jocke@REDACTED Mon Jan 27 10:24:30 2003 From: jocke@REDACTED (Joakim G.) Date: Mon, 27 Jan 2003 10:24:30 +0100 Subject: A Joeish Erlang distribution (long) Message-ID: <3E34FACE.8090605@bluetail.com> Hi all, After recent discussions on this list and after the work with the xmlrpc library I have come to a conclusion: Erlang is ready for an alternative distribution. In the same way Mandrake Linux successfully enhance/extend each RedHat release this could be done for Erlang. God bless Open Source. I'm not saying that we should branch off from the Erlang/OTP code base but rather morph each new Erlang/OTP release into something different. The Erlang/OTP group at Ericsson is doing an excellent job and it would be insane run a paralell race. I'm not sure they are prepared (or even allowed) to do the thing I describe below. You may of course tell me I'm wrong. Non would be happier. Erlang/OTP today have these characteristics (and more for certain): 1 Telecom programming focus 2 Functional Programming Language 3 Complex design patterns (due to 4) 4 Can handle humongously large software projects. 5 Conservative to addition/removal of language constructs/libraries (thus 6). 6 Focus on backwards compatibility. An alternative distribution would have these characteristics: 1 Internet (server) programming focus 2 Concurrency Oriented Programming Language 3 Simplicity (due to 4) 4 Capable of handling small/middle/largish software projects 5 Aggressive towards addition/removal of language constructs/libraries (thus 6) [*]. 6 Less focus on backwards compatibility. * = For example: mnemosyne is out, yaws replaces inets. Joe's !! addition is in (http://www.sics.se/~joe/nerl.html) etc. I will not delve deeper into this. To achieve such a distribution someone has to take the burden of dictatorship. Like Linus does for the Linux kernel. Someone has to manage the TODO list; deciding what goes into the distribution (and what's not), deciding which person to entrust with this and that action point on the TODO list etc. This person is *certainly* not me. I would suggest Joe. We could even call the distribution 'Joe' if he is willing to take up the flag. :-) No. I have not talked with Joe about this. He may very well skin me for these blasphemous thoughts. Cheers /Jocke Below follows more advanced ramblings (in comparison with the lesser ramblings above): Positioning ----------- Erase the Telecom label. Put the OTP libraries in the background. All to remove unnecessary complexity when working in small/middle or largish software projects. Really large projects may prefer the original Erlang/OTP distribution. Instead position Erlang as a Concurrency Oriented Programming Language (COPL) as described by Joe at the ll2 conference (http://ll2.ai.mit.edu/) with hype and all. COPL is especially geared towards Internet (server) programming and its simplicity and support for massive concurrency makes it easy to write distributed and robust applications. The language happens to be functional. This is less important. Documentation ------------- Documentation is the key to the spread the COPL message/distribution. Because of the "pure" Erlang (read: non-OTP) nature of the distribution a revised version of the Erlang book would suffice. I know: It has to be written from scratch to avoid copyright infringement. At least is doesn't need to describe OTP so the work involved would be _somewhat_ restricted. This means a lot of work. I can volunteer with a chapter on how to write an xmlrpc servers/clients [if this is what the editor wants]. Even though OTP is a part of stdlib (and heavily used by Erlang itself) there is no need to describe it. Just refer to the Erlang/OTP documentation. Lets keep things simple. The complexity of OTP can be replaced by a small set of guidelines when it comes to small/middle and largish projects; how to write a server, how to write an application controller etc. The distribution's Web server could very well be fully centered around this new documentation. Packaging --------- I propose that the distribution is released as two packages: 'core' and 'tools'. Everything needed to be exceptionally productive within the focus of the new distribution is included in these two packages. A large part of OTP is today included in stdlib (application, supervisor, gen_server, gen_fsm, sasl, app, appup, relup and dist_ac etc.). It would stay there in the background being described elsewhere. The packages: Core (random order) sae xmerl asn1 yaws xmlrpc soap compiler erl_interface stdlib mnesia mnesia_session crypto ic kernel http client library smtp client library ldap client library parsetools ssl runtime_tools jinterface odbc ucs Tools (random order) et appmon debugger pman toolbar tv tools observer We leave these applications out. If you want these or explicit OTP support go for the Erlang/OTP distribution: eva sasl snmp megaco os_mon orber cosEvent cosFileTransfer cosNotification cosProperty cosTime cosTransactions gs etk inets mnemosyne webtool -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From etxuwig@REDACTED Mon Jan 27 11:46:23 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 27 Jan 2003 11:46:23 +0100 (MET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E34FACE.8090605@bluetail.com> Message-ID: On Mon, 27 Jan 2003, Joakim G. wrote: >Erlang is ready for an alternative distribution. Hmm. The idea of introducing a different packaging and documentation without spawning off another Erlang code base might work, if someone is willing to champion it. Couldn't one create a "profile" with a certain collection of applications, and then have an installation procedure similar to e.g. Cygwin, RPM or FreeBSD? Basically, you would download a small installation program which reads a text file, identifying the applications (+ vsn) that should be downloaded -- and from where. One could later use the same installation program to add other programs (for example mnemosyne, if one really wants to make complex queries), and upgrade the profile or a specific application. Given a list of web servers, the tool could perform a web query to find which applications are available (very similar to RPM.) The idea of providing a certain profile would be to allow people to get started quickly, and also that the applications in the profile would be "certified" by someone. One could then also provide profile-oriented documentation and tutorials on some appropriate web server. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From Vlad.Dumitrescu@REDACTED Mon Jan 27 12:15:08 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Mon, 27 Jan 2003 12:15:08 +0100 Subject: A Joeish Erlang distribution (long) Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6FB@esemont203.gbg.edt.ericsson.se> Hi, > Erlang is ready for an alternative distribution. I won't comment on that part yet, I have to think more about it, but it might be a good idea. There have actually been some separate distributions (although not public ones, I think). The most proeminent is Hipe, before getting integrated with the mainstrean distribution. > * = For example: mnemosyne is out, yaws replaces inets. Joe's !! > addition is in (http://www.sics.se/~joe/nerl.html) etc. Having read Joe's ideas about "everything is a process" and appreciating the power of such an abstraction, I have also been struck by a different kind of revelation. If we take this "everything is a process" idea, and put it beside another of Joe's ideas, UBF and the contracted communication protocols, I think it begins to look *very* similar to an OO setting! Knowing Joe's opinion about OO, it may be just an artifact, but it might also show that it is a way worth investigating (given that IMHO the OO paradigm isn't flawed in itself, just the way it is implemented today). The link to Cecil that Daniel posted opens another interesting view that I confess didn't consider before - the classless object system, which might translate here into a dynamic UBF contract system, or dynamic gen_server behaviours... Just some wild ideas. I look forward to hearing Joe's comments (and everybody else's as well, of course!). regards, Vlad From DANIESC.SCHUTTE@REDACTED Mon Jan 27 13:19:10 2003 From: DANIESC.SCHUTTE@REDACTED (DANIESC SCHUTTE) Date: Mon, 27 Jan 2003 14:19:10 +0200 Subject: Killing a erlang process. Message-ID: Good afternoon to everyone, Defaults: (OS - Solaris 5.8, Erlang R8B1) Today my question is about killing and releasing a globally registered process on a node, created in a telnet session, where the telnet session timed out. (The session was created by running a boot script). Whenever another session is started - it stops with errors that the global name is already registered. What is the CORRECT procedure to kill that node and release the resources. In the same vain, would (I think it is) it be possible to attach to a currently running node, from a remote telnet session in order to monitor the node operation and the gracefully disconnect? Thanks for all of you providing us with helpful insight. Regards Daniel Schutte Danie Schutte Phone: +27 - 11 - 203 - 1613 Mobile: 084-468-3138 e-Mail: Daniesc@REDACTED ##################################################################################### 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 and copies. ##################################################################################### From eleberg@REDACTED Mon Jan 27 13:43:41 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Mon, 27 Jan 2003 13:43:41 +0100 (MET) Subject: Structs (was RE: Record selectors) Message-ID: <200301271243.h0RChfH00749@cbe.ericsson.se> > On Wed, 15 Jan 2003 09:18:38 +0100 > "Vlad Dumitrescu (EAW)" wrote: > ...deleted > From the OO literature I've read, three tenets seems to be universally > agreed upon: encapsulation, polymorphism, and inheritance. Two others get > mentioned often enough, abstraction and identity, but they seem less well > understood. sorry about this late email, but i had to get my copy of ''object oriented software construction'', by bertrand meyer, back before i wrote anything. in chapter 2, ''criteria of object orientation'' there are 15 pages devoted to what object orientation (o-o) is. there are 3 cathegories 1 method and language (20 criteria) 2 implementation and environment (5 criteria) 3 libraries (4 criteria) also mentioned is the fact that o-o is not a boolean concept. ''environment a, although not 100% o-o, may be more o-o than environment b''. i like that book. bengt From mickael.remond@REDACTED Mon Jan 27 13:49:46 2003 From: mickael.remond@REDACTED (Mickael Remond) Date: Mon, 27 Jan 2003 13:49:46 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E34FACE.8090605@bluetail.com> References: <3E34FACE.8090605@bluetail.com> Message-ID: <20030127124945.GA3882@mremond.cgey.capgemini.fr> * Joakim G. [2003-01-27 10:24:30 +0100]: > Hi all, > After recent discussions on this list and after the work with the > xmlrpc library I have come to a conclusion: > > Erlang is ready for an alternative distribution. This is strange because this idea converge with something I had in mind. I was looking for a good way to integrate contributed modules into an Erlang installation. One approach that has been successfull for Perl is to have some kind of interface to an Erlang repository. For Perl this kind of tool is call CPAN (Comprehensive Perl Archive Network). The main idea is that you get a way to quickly download, compile a given module and all its dependency. CPAN.org has a website but the easiest access to the repository is through the dedicated Perl client that handles the dependancy, recompilation and installation part). I think we could build this kind of network on top of RPM. The main drawback is that this is Linux only. I think it is important to have such a front-end in Erlang, so that it can work on others Unixes and Windows. I think this approach could be more scalable (I mean easily integrate more man power) that managing an Erlang distribution. What do you think ? -- Micka?l R?mond From mikael.karlsson@REDACTED Mon Jan 27 14:07:30 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Mon, 27 Jan 2003 14:07:30 +0100 Subject: Why Erlang is the best concurrent language available In-Reply-To: References: Message-ID: <200301271407.30324.mikael.karlsson@creado.com> fredag 24 januari 2003 14:31 skrev Ulf Wiger: > On Fri, 24 Jan 2003, Mikael Karlsson wrote: > >I would really like to see Erlang going in the directions > >of web application/services, and not only remain as OTP, > >THE Telecom platform. > > No, that would be TTP. TTP is designed in GOL > (http://www.erlang.org/ml-archive/erlang-questions/200301/msg00135.html), > and, like GOL, TTP varies with time. (: > You are right, you can't be a prophet in your own country, can you? :-) The more the reason to switch focus and pack the stuff for the rest of the world as Jocke suggests in "A Joeish Erlang distribution (long): http://www.erlang.org/ml-archive/erlang-questions/200301/msg00288.html /Mikael From Vlad.Dumitrescu@REDACTED Mon Jan 27 14:05:03 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Mon, 27 Jan 2003 14:05:03 +0100 Subject: Structs (was RE: Record selectors) Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6FC@esemont203.gbg.edt.ericsson.se> > > On Wed, 15 Jan 2003 09:18:38 +0100 > > "Vlad Dumitrescu (EAW)" wrote: > > > ...deleted > > From the OO literature I've read, three tenets seems to be > universally > > agreed upon: encapsulation, polymorphism, and inheritance. > Two others get > > mentioned often enough, abstraction and identity, but they > seem less well > > understood. Just to put things straight, this was Chris' comment. It just got a ">" in front, so it seems like a quote :-) Yes, Bertrand Meyer's book makes very interesting reading, even when not using OO. And it explains quite well that OO is not necessarily about classes and objects (or so I chose to understand it :-) regards, Vlad From eleberg@REDACTED Mon Jan 27 14:16:06 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Mon, 27 Jan 2003 14:16:06 +0100 (MET) Subject: A Joeish Erlang distribution (long) Message-ID: <200301271316.h0RDG6H04980@cbe.ericsson.se> > Date: Mon, 27 Jan 2003 13:49:46 +0100 > From: Mickael Remond ...deleted > One approach that has been successfull for Perl is to have some kind of > interface to an Erlang repository. For Perl this kind of tool is call > CPAN (Comprehensive Perl Archive Network). The main idea is that you get > a way to quickly download, compile a given module and all its > dependency. CPAN.org has a website but the easiest access to the > repository is through the dedicated Perl client that handles the > dependancy, recompilation and installation part). > > I think we could build this kind of network on top of RPM. The main > drawback is that this is Linux only. I think it is important to have > such a front-end in Erlang, so that it can work on others Unixes and > Windows. i must admit that my first suggestion would be to build this with CPAN, instead of RPM. what are the alternatives? what are their pros and cons? bengt From enano@REDACTED Mon Jan 27 14:29:11 2003 From: enano@REDACTED (Miguel Barreiro Paz) Date: Mon, 27 Jan 2003 14:29:11 +0100 (CET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <20030127124945.GA3882@mremond.cgey.capgemini.fr> References: <3E34FACE.8090605@bluetail.com> <20030127124945.GA3882@mremond.cgey.capgemini.fr> Message-ID: > This is strange because this idea converge with something I had in mind. > I was looking for a good way to integrate contributed modules into an > Erlang installation. In my humble opinion, the ability to automatically download, compile and install modules would be nice, but not extremely useful (do you really think that's a limiting factor for new or experienced Erlang users?). On the other hand, a clearer and better established open source development process for those modules or the core language itself would be great. It has already been suggested before IIRC. Somebody submits a patch or contrib, a commitee or iron-hand project lead either accepts or rejects it with a reason. A more inviting "user contributions" page would be nice too - to an Erlang newcomer, the current erlang.org/user.html page basically reads "Erlang is an Ericsson thingie, and these are contributions from users without our blessing - God knows if they work or not". > I think we could build this kind of network on top of RPM. The main > drawback is that this is Linux only. I think it is important to have (No longer - AIX includes some RPM support, and you can compile RPM on other platforms). Anyway, it would be trivial to make .rpm or .deb packages of all user contribs. I (mostly in a Debian world) just apt-get install lib*-perl, whenever I need yet another perl module, so why not do the same with erlang? Regards, Miguel From jocke@REDACTED Mon Jan 27 14:55:00 2003 From: jocke@REDACTED (Joakim G.) Date: Mon, 27 Jan 2003 14:55:00 +0100 Subject: A Joeish Erlang distribution (long) References: <3E34FACE.8090605@bluetail.com> <20030127124945.GA3882@mremond.cgey.capgemini.fr> Message-ID: <3E353A34.2090008@bluetail.com> Hi, Both Ulf and Micka?l (Hi!) goes directly for the nitty gritty details. I don't mind this but to me the switch of paradigm towards COPL *and* simplicity is in itself more important than if we choose this or that CPAN or RPM packaging support. I agree: A package mechanism would be great when building a new distribution. Not required though. Erlang needs to come out of the closet. Erlang is to good to niche itself as a Telecom Functional Language. Talk about a small niche. Erlang needs a larger user base if it is to survive. IMO a COPL distribution could achieve this. > An alternative distribution would have these characteristics: > > 1 Internet (server) programming focus > 2 Concurrency Oriented Programming Language > 3 Simplicity (due to 4) > 4 Capable of handling small/middle/largish software projects > 5 Aggressive towards addition/removal of language constructs/libraries > (thus 6) [*]. > 6 Less focus on backwards compatibility. > > * = For example: mnemosyne is out, yaws replaces inets. Joe's !! > addition is in (http://www.sics.se/~joe/nerl.html) etc. I know. This would require a substantial amount of work. Especially the documentation. A TODO list (in some detail) of stuff needed in order to achieve it would be a good start. Then we just need volunteers. /Jocke From valentin@REDACTED Mon Jan 27 15:26:12 2003 From: valentin@REDACTED (Valentin) Date: Mon, 27 Jan 2003 16:26:12 +0200 Subject: A Joeish Erlang distribution (long) References: Message-ID: <001201c2c610$1dcce9a0$8db01fc4@moneymaker> > > >Erlang is ready for an alternative distribution. > I would strongly oppose this view as it can easily kill Erlang. You cannot possibly judge about ability to sustain more than one distribution based on a "recent discussion on the list". Partitioning Erlang would only reduce from critical mass required to raise Erlang to the next level (whatever that might be). Let' s keep things together for another few years -- if Eralng has to evolve, let it evolve as a whole... Valentin. From taavi@REDACTED Mon Jan 27 15:26:53 2003 From: taavi@REDACTED (Taavi Talvik) Date: Mon, 27 Jan 2003 16:26:53 +0200 (EET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <200301271316.h0RDG6H04980@cbe.ericsson.se> Message-ID: <20030127160459.H53127-100000@valu.uninet.ee> On Mon, 27 Jan 2003, Bengt Kleberg wrote: > > > Date: Mon, 27 Jan 2003 13:49:46 +0100 > > From: Mickael Remond > ...deleted > > One approach that has been successfull for Perl is to have some kind of > > interface to an Erlang repository. For Perl this kind of tool is call > > CPAN (Comprehensive Perl Archive Network). The main idea is that you get > > a way to quickly download, compile a given module and all its > > dependency. CPAN.org has a website but the easiest access to the > > repository is through the dedicated Perl client that handles the > > dependancy, recompilation and installation part). > > > > I think we could build this kind of network on top of RPM. The main > > drawback is that this is Linux only. I think it is important to have > > such a front-end in Erlang, so that it can work on others Unixes and > > Windows. > > i must admit that my first suggestion would be to build this with CPAN, > instead of RPM. > what are the alternatives? > what are their pros and cons? System like FreeBSD ports. It describes package locations (sources, patches), dependencies and is actually bunch of makefiles, which define certain predefined targets. best regards, taavi From joe@REDACTED Mon Jan 27 15:40:59 2003 From: joe@REDACTED (Joe Armstrong) Date: Mon, 27 Jan 2003 15:40:59 +0100 (CET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6FB@esemont203.gbg.edt.ericsson.se> Message-ID: > I look forward to hearing Joe's comments (and everybody else's as well, of course!). Yes - this is all very flattering - and I really appreciate the attempt to find more things for me to do :-) - for some reason people seem to think I can't think of things to do so they come up with helpful suggests for things I might like to do .. My wife, for example, thinks that if I haven't got anything else to do than "clicking away on that computer" I could do something useful like washing the cat or feeding the dishes ... sigh On reflection I'm against this - why? - The Erlang OTP release is a very high quality release - I wouldn't like people to think that there were several different Erlang's and have to put them in the position of having to choose "which is the better" of these - as far as new users are concerned there should be only ONE Erlang and that's the Erlang that you get from the OTP people. I would, however, like to see a much smaller core release. In order to compile up the OTP release I need to have Java installed, and I need to compile up loads of things that I will never use. When I get and build Erlang I have to wait a longish time while all the corba and ASN.1 and XYZ stuff is compiled. Now cobra is, no doubt, absolutely splendid - but I have never ever used it nor have I had the slightest desire to use it, so as far as I'm concerned, it might as well not clutter up my disk - if I want it I'll go and get it. Even worse, sometimes an error occurring when compiling up some application that I have zero interest in - breaks the build process. People have said to me "Erlang is very big" the download is XXX MBytes - but this is because of the large number of apps that are bundled into the main tarball. The next small step for mankind would be to split off the applications from the core and distribute them separately. Core Erlang should be just the compiler and the essential run-time - nothing else - I think this would make the system easier to understand and manage. I'd also like to see many more "stand alone applications" that are written using only the core - these would be programs that "did something useful" - a lot of the contributions are "libraries that you can use to build fun things" rather than "fun things" - yaws and wings are outstanding examples of these. /Joe From jocke@REDACTED Mon Jan 27 15:49:48 2003 From: jocke@REDACTED (Joakim G.) Date: Mon, 27 Jan 2003 15:49:48 +0100 Subject: A Joeish Erlang distribution (long) References: Message-ID: <3E35470C.3030506@bluetail.com> OK. I rest my case. /Jocke Joe Armstrong wrote: >>I look forward to hearing Joe's comments (and everybody else's as well, of course!). > > > Yes - this is all very flattering - and I really appreciate the > attempt to find more things for me to do :-) - for some reason people > seem to think I can't think of things to do so they come up with > helpful suggests for things I might like to do .. > > My wife, for example, thinks that if I haven't got anything else to > do than "clicking away on that computer" I could do something useful > like washing the cat or feeding the dishes ... sigh > > On reflection I'm against this - why? - The Erlang OTP release is a > very high quality release - I wouldn't like people to think that there > were several different Erlang's and have to put them in the position of > having to choose "which is the better" of these - as far as new users > are concerned there should be only ONE Erlang and that's the Erlang > that you get from the OTP people. > > I would, however, like to see a much smaller core release. > > In order to compile up the OTP release I need to have Java > installed, and I need to compile up loads of things that I will never > use. > > When I get and build Erlang I have to wait a longish time while all > the corba and ASN.1 and XYZ stuff is compiled. Now cobra is, no > doubt, absolutely splendid - but I have never ever used it nor have I > had the slightest desire to use it, so as far as I'm concerned, it > might as well not clutter up my disk - if I want it I'll go and get > it. > > Even worse, sometimes an error occurring when compiling up some > application that I have zero interest in - breaks the build process. > > People have said to me "Erlang is very big" the download is XXX > MBytes - but this is because of the large number of apps that are > bundled into the main tarball. > > The next small step for mankind would be to split off the > applications from the core and distribute them separately. > > Core Erlang should be just the compiler and the essential run-time - > nothing else - I think this would make the system easier to understand > and manage. > > I'd also like to see many more "stand alone applications" that are > written using only the core - these would be programs that "did > something useful" - a lot of the contributions are "libraries that you > can use to build fun things" rather than "fun things" - yaws and wings > are outstanding examples of these. > > /Joe > > > > > > -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From Simon.Chappell@REDACTED Mon Jan 27 15:57:15 2003 From: Simon.Chappell@REDACTED (Chappell, Simon P) Date: Mon, 27 Jan 2003 08:57:15 -0600 Subject: A Joeish Erlang distribution (long) Message-ID: <1AA6971F96FADB4A96CF73E4729B05F103F25D@USEVS012.leinternal.com> >-----Original Message----- >From: Valentin [mailto:valentin@REDACTED] >Sent: Monday, January 27, 2003 8:26 AM >To: Ulf Wiger >Cc: erlang-questions@REDACTED >Subject: Re: A Joeish Erlang distribution (long) > > >> >> >Erlang is ready for an alternative distribution. >> >I would strongly oppose this view as it can easily kill >Erlang. You cannot All of the evidence that I have seen shows the opposite to be true. Linux certainly does not seem to be in danger of dying out. I think a web-oriented Erlang would be just the way to spark people into looking into it more. >possibly judge about ability to sustain more than one >distribution based on >a "recent discussion on the list". Partitioning Erlang would >only reduce >from critical mass required to raise Erlang to the next level >(whatever that I don't think that the hard-core Erlang folks are going to stop using it just because the web folks start using it. Remember, Perl was a sys. admin tool until the web folks discovered it. >might be). Let' s keep things together for another few years >-- if Eralng >has to evolve, let it evolve as a whole... No one is asking that anything negative be done to the core Erlang, only that further avenues be created to bring people to Erlang usage. I think that I would be a good example of the target for this new proposed distribution. I am a Java programmer that specialises in web application development and I would love to have some help getting into Erlang to the point where I could produce fast, robust web apps using it. >Valentin. Simon ----------------------------------------------------------------- Simon P. Chappell simon.chappell@REDACTED Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 From mbj@REDACTED Mon Jan 27 16:11:33 2003 From: mbj@REDACTED (Martin Bjorklund) Date: Mon, 27 Jan 2003 16:11:33 +0100 (CET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <1AA6971F96FADB4A96CF73E4729B05F103F25D@USEVS012.leinternal.com> References: <1AA6971F96FADB4A96CF73E4729B05F103F25D@USEVS012.leinternal.com> Message-ID: <20030127.161133.93222421.mbj@bluetail.com> "Chappell, Simon P" wrote: > >> >Erlang is ready for an alternative distribution. > >> > >I would strongly oppose this view as it can easily kill > >Erlang. You cannot > > All of the evidence that I have seen shows the opposite to be > true. Linux certainly does not seem to be in danger of dying out. I > think a web-oriented Erlang would be just the way to spark people > into looking into it more. I agree. But the alternative distrib should be just that - I think the language should be exactly the same (and probably the runtime too, although this is probably not essential). An alternative would be if the OTP release could be made more modular as Joe suggested. Linux does have some problems with different "patches" in different distribs. Just as one example, see the libpcap stuff... /martin From Simon.Chappell@REDACTED Mon Jan 27 16:17:25 2003 From: Simon.Chappell@REDACTED (Chappell, Simon P) Date: Mon, 27 Jan 2003 09:17:25 -0600 Subject: A Joeish Erlang distribution (long) Message-ID: <1AA6971F96FADB4A96CF73E4729B05F1DCABE2@USEVS012.leinternal.com> >-----Original Message----- >From: Martin Bjorklund [mailto:mbj@REDACTED] >Sent: Monday, January 27, 2003 9:12 AM >To: Chappell, Simon P >Cc: erlang-questions@REDACTED >Subject: Re: A Joeish Erlang distribution (long) > > >"Chappell, Simon P" wrote: > >> >> >Erlang is ready for an alternative distribution. >> >> >> >I would strongly oppose this view as it can easily kill >> >Erlang. You cannot >> >> All of the evidence that I have seen shows the opposite to be >> true. Linux certainly does not seem to be in danger of dying out. I >> think a web-oriented Erlang would be just the way to spark people >> into looking into it more. > >I agree. But the alternative distrib should be just that - I think >the language should be exactly the same (and probably the runtime too, >although this is probably not essential). An alternative would be if >the OTP release could be made more modular as Joe suggested. That would certainly work. I keep trying to find time to learn Erlang, but it's hard when I know that all the web stuff I want either isn't there or is buried somewhere and I don't know where to look. >Linux does have some problems with different "patches" in different >distribs. Just as one example, see the libpcap stuff... I only said it wasn't dying out, not that it didn't have problems! ;-) >/martin Simon From Marc.Vanwoerkom@REDACTED Mon Jan 27 16:17:55 2003 From: Marc.Vanwoerkom@REDACTED (Marc Ernst Eddy van Woerkom) Date: Mon, 27 Jan 2003 16:17:55 +0100 (MET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E34FACE.8090605@bluetail.com> (jocke@bluetail.com) Message-ID: <200301271517.h0RFHtn09807@bonsai.fernuni-hagen.de> > 1 Internet (server) programming focus > 2 Concurrency Oriented Programming Language > 3 Simplicity (due to 4) > 4 Capable of handling small/middle/largish software projects > 5 Aggressive towards addition/removal of language constructs/libraries > (thus 6) [*]. > 6 Less focus on backwards compatibility. What if one wants to create a cute looking rich client in Erlang? The present graphical user interface is looking very old fashioned. > Documentation > ------------- > Documentation is the key to the spread the COPL message/distribution. > Because of the "pure" Erlang (read: non-OTP) nature of the > distribution a revised version of the Erlang book would suffice. I > know: It has to be written from scratch to avoid copyright > infringement. At least is doesn't need to describe OTP so the work > involved would be _somewhat_ restricted. This means a lot of work. I > can volunteer with a chapter on how to write an xmlrpc servers/clients > [if this is what the editor wants]. I see Java's available free documentation, the well done online tutorials and even the use of the javadoc tool as big plus of that language. The Erlang documentation seems less accessable to me. Regards, Marc From Vlad.Dumitrescu@REDACTED Mon Jan 27 16:18:07 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Mon, 27 Jan 2003 16:18:07 +0100 Subject: A Joeish Erlang distribution (long) Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6FD@esemont203.gbg.edt.ericsson.se> > > I look forward to hearing Joe's comments (and everybody > else's as well, of course!). > > Yes - this is all very flattering - and I really appreciate the > attempt to find more things for me to do :-) - for some reason people > seem to think I can't think of things to do so they come up with > helpful suggests for things I might like to do .. Oh, that was not my meaning at all! As far as I am concerned, I was just referring to work you already did: UBF and the "bang bang" ideas... And I thought that you being "accused" to have an OO-friendly attitude would have a somewhat provocative effect! ;-) I am always interested in exploring the edges of any domain, and that's why I sometimes poke people in the eye while fumbling around... regards, Vlad From mikael.karlsson@REDACTED Mon Jan 27 16:24:35 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Mon, 27 Jan 2003 16:24:35 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: <001201c2c610$1dcce9a0$8db01fc4@moneymaker> References: <001201c2c610$1dcce9a0$8db01fc4@moneymaker> Message-ID: <200301271624.35457.mikael.karlsson@creado.com> Mon 27 Jan 2003 Valentin wrote: > > >Erlang is ready for an alternative distribution. > > I would strongly oppose this view as it can easily kill Erlang. You cannot > possibly judge about ability to sustain more than one distribution based on > a "recent discussion on the list". Partitioning Erlang would only reduce > from critical mass required to raise Erlang to the next level (whatever > that might be). Let' s keep things together for another few years -- if > Eralng has to evolve, let it evolve as a whole... > > Valentin. I am very much in favour of an alternative distibution or a distribution that would focus on web application development. I think Jocke is pointing somehow out that the next level is reached, and that focus is much on Internet applications. Open Source Erlang is getting a lot of attention and contributions that fall outside the telecom sector but are useful for others. It would be nice to somehow get those in, but I do not think this is a task, nor possible from resource point of view, for the OTP group. We should of course be careful not to partition Erlang. So if not an alternative distribution, maybe as Joe suggests a much smaller core, and then the possibility to add on applications or bundles of applications to "personalize" Erlang, to for instance *Web Applications* ( I know, I said it again :). This could also have the positive effect of getting new users attracted to Erlang as it would be easier to use it for their application domain. /Mikael From jocke@REDACTED Mon Jan 27 16:35:44 2003 From: jocke@REDACTED (Joakim G.) Date: Mon, 27 Jan 2003 16:35:44 +0100 Subject: A Joeish Erlang distribution (long) References: <200301271517.h0RFHtn09807@bonsai.fernuni-hagen.de> Message-ID: <3E3551D0.5000502@bluetail.com> Marc Ernst Eddy van Woerkom wrote: >> 1 Internet (server) programming focus >> 2 Concurrency Oriented Programming Language >> 3 Simplicity (due to 4) >> 4 Capable of handling small/middle/largish software projects >> 5 Aggressive towards addition/removal of language constructs/libraries >> (thus 6) [*]. >> 6 Less focus on backwards compatibility. > > What if one wants to create a cute looking rich client in Erlang? > The present graphical user interface is looking very old fashioned. Erlang is so much better suited for the server side. Lets forget building product quality GUIs in Erlang. You can't be everywhere. :-) >> Documentation >> ------------- >> Documentation is the key to the spread the COPL message/distribution. >> Because of the "pure" Erlang (read: non-OTP) nature of the >> distribution a revised version of the Erlang book would suffice. I >> know: It has to be written from scratch to avoid copyright >> infringement. At least is doesn't need to describe OTP so the work >> involved would be _somewhat_ restricted. This means a lot of work. I >> can volunteer with a chapter on how to write an xmlrpc servers/clients >> [if this is what the editor wants]. > > I see Java's available free documentation, the well done online tutorials > and even the use of the javadoc tool as big plus of that language. > The Erlang documentation seems less accessable to me. I fully agree. Dense. Steep learning curve. Geared towards zealots. Cheers /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From Vlad.Dumitrescu@REDACTED Mon Jan 27 16:36:34 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Mon, 27 Jan 2003 16:36:34 +0100 Subject: Killing a erlang process. Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F6FE@esemont203.gbg.edt.ericsson.se> Hi, > Whenever another session is > started - it stops with errors that the global name is > already registered. What is the CORRECT procedure to kill > that node and release the resources. When trying to start the process again, do you check first to see if it exists? The usual pattern is to check and if it exists, use it; otherwise create a new one and register it. > In the same vain, would (I think it is) it be possible to > attach to a currently running node, from a remote telnet > session in order to monitor the node operation and the > gracefully disconnect? There is an application named reshd written by Tomas Abrahamsson (from the User Contributions at erlang.org) which does exact that. regards, Vlad From kenneth@REDACTED Mon Jan 27 17:32:33 2003 From: kenneth@REDACTED (Kenneth Lundin) Date: Mon, 27 Jan 2003 17:32:33 +0100 Subject: A Joeish Erlang distribution (long) References: <3E34FACE.8090605@bluetail.com> Message-ID: <3E355F21.4010005@erix.ericsson.se> Hi all, Here are some comments from the Erlang/OTP Product Manager at Ericsson. 1) We have plans to divide the Erlang/OTP distribution into s number of separate packages. Preliminary we are thinking of 3 packages: - Core package (erts,kernel,stdlib,sasl,mnesia,os_mon,inets,compiler,..) - Tools&Utilities (parse_tools, tools, debugger, observer, et, tv, ... - Telecom/protocols (snmp, asn1, orber, megaco, ... The exact contents is not settled yet. When this happens is not decided either but an optimistic guess is before the end of 2003. I am not very positive to the idea with an alternative distribution where applications from us are exchanged with other similar applications (e.g inets replaced by yaws). I think it can be confusing for the users that the contents varies for different distributions and that the quality and compatibility strategy varies, between different applications within the same package. I think it is better that the concept where an Erlang/OTP installation can be put together from several separate packages is defined and then there can be additional packages for example one with internet_server related applications that can be maintained and distributed separately from the packages from us (OTP group at Ericsson). Joakim G. wrote: > Hi all, > After recent discussions on this list and after the work with the > xmlrpc library I have come to a conclusion: > > Erlang is ready for an alternative distribution. > > In the same way Mandrake Linux successfully enhance/extend each RedHat > release this could be done for Erlang. God bless Open Source. > > I'm not saying that we should branch off from the Erlang/OTP code base > but rather morph each new Erlang/OTP release into something different. > The Erlang/OTP group at Ericsson is doing an excellent job and it would > be insane run a paralell race. I'm not sure they are prepared (or even > allowed) to do the thing I describe below. You may of course tell me > I'm wrong. Non would be happier. > > Erlang/OTP today have these characteristics (and more for certain): > > 1 Telecom programming focus > 2 Functional Programming Language > 3 Complex design patterns (due to 4) I don't think there is to much focus on design patterns and most of them are useful in any SW project. > 4 Can handle humongously large software projects. I don't think there are any specific SW within Erlang/OTP or the documentation which only is relevant for "humongously large" projects. > 5 Conservative to addition/removal of language constructs/libraries > (thus 6). Very important to have a stable foundation. It is hard to remove things because of backwards compatibility issues. Before we add things we like to be reasonably sure thast we want to support it for a long time. We must also be able to guarantee the quality. Sometimes we add things which we point out as unsupported just to let the users try it. > 6 Focus on backwards compatibility. Yes, that is important and one of our strengths. (although it sometimes stops us from doing nice improvements). The backward compatibility strategy saves us a lot of work since it is quite easy to convince a large/huge user project to change to the latest version. By this we don't need to support an overwhelming amount of old versions. I think this is good for the Open Source users too. > > An alternative distribution would have these characteristics: > > 1 Internet (server) programming focus > 2 Concurrency Oriented Programming Language I agree that this is a better positioning than as a functional programming. > 3 Simplicity (due to 4) > 4 Capable of handling small/middle/largish software projects > 5 Aggressive towards addition/removal of language constructs/libraries > (thus 6) [*]. > 6 Less focus on backwards compatibility. > > * = For example: mnemosyne is out, yaws replaces inets. Joe's !! > addition is in (http://www.sics.se/~joe/nerl.html) etc. > > I will not delve deeper into this. > > To achieve such a distribution someone has to take the burden of > dictatorship. Like Linus does for the Linux kernel. Someone has to > manage the TODO list; deciding what goes into the distribution (and > what's not), deciding which person to entrust with this and that > action point on the TODO list etc. > > This person is *certainly* not me. I would suggest Joe. We could even > call the distribution 'Joe' if he is willing to take up the flag. :-) > > No. I have not talked with Joe about this. He may very well skin me > for these blasphemous thoughts. > > Cheers > /Jocke > > Below follows more advanced ramblings (in comparison with the lesser > ramblings above): > > Positioning > ----------- > Erase the Telecom label. Put the OTP libraries in the background. All > to remove unnecessary complexity when working in small/middle or largish > software projects. Really large projects may prefer the original > Erlang/OTP distribution. Instead position Erlang as a Concurrency > Oriented Programming Language (COPL) as described by Joe at the ll2 > conference (http://ll2.ai.mit.edu/) with hype and all. > > COPL is especially geared towards Internet (server) programming and > its simplicity and support for massive concurrency makes it easy to > write distributed and robust applications. The language happens to be > functional. This is less important. > > Documentation > ------------- > Documentation is the key to the spread the COPL message/distribution. > Because of the "pure" Erlang (read: non-OTP) nature of the > distribution a revised version of the Erlang book would suffice. I > know: It has to be written from scratch to avoid copyright > infringement. At least is doesn't need to describe OTP so the work > involved would be _somewhat_ restricted. This means a lot of work. I > can volunteer with a chapter on how to write an xmlrpc servers/clients > [if this is what the editor wants]. We have work in progress here too. The goal is of course that our documentation fully can replace the need of the the book. > > Even though OTP is a part of stdlib (and heavily used by Erlang > itself) there is no need to describe it. Just refer to the Erlang/OTP > documentation. Lets keep things simple. The complexity of OTP can be > replaced by a small set of guidelines when it comes to small/middle > and largish projects; how to write a server, how to write an > application controller etc. > > The distribution's Web server could very well be fully centered around > this new documentation. > > Packaging > --------- > I propose that the distribution is released as two packages: 'core' > and 'tools'. Everything needed to be exceptionally productive within > the focus of the new distribution is included in these two > packages. A large part of OTP is today included in stdlib (application, > supervisor, gen_server, gen_fsm, sasl, app, appup, relup and dist_ac > etc.). It would stay there in the background being described elsewhere. > > The packages: > > Core (random order) > sae > xmerl > asn1 > yaws > xmlrpc > soap > compiler > erl_interface > stdlib > mnesia > mnesia_session > crypto > ic > kernel > http client library > smtp client library > ldap client library > parsetools > ssl > runtime_tools > jinterface > odbc > ucs > > Tools (random order) > et > appmon > debugger > pman > toolbar > tv > tools > observer > > We leave these applications out. If you want these or explicit OTP > support go for the Erlang/OTP distribution: > > eva > sasl > snmp > megaco > os_mon > orber > cosEvent > cosFileTransfer > cosNotification > cosProperty > cosTime > cosTransactions > gs > etk > inets > mnemosyne > webtool Regards Kenneth Lundin (Product Manager of Erlang/OTP) -- From jocke@REDACTED Mon Jan 27 18:48:31 2003 From: jocke@REDACTED (Joakim G.) Date: Mon, 27 Jan 2003 18:48:31 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E3551D0.5000502@bluetail.com> References: <200301271517.h0RFHtn09807@bonsai.fernuni-hagen.de> <3E3551D0.5000502@bluetail.com> Message-ID: <3E3570EF.605@bluetail.com> Joakim G. wrote: > Marc Ernst Eddy van Woerkom wrote: > >>> 1 Internet (server) programming focus >>> 2 Concurrency Oriented Programming Language >>> 3 Simplicity (due to 4) >>> 4 Capable of handling small/middle/largish software projects >>> 5 Aggressive towards addition/removal of language constructs/libraries >>> (thus 6) [*]. >>> 6 Less focus on backwards compatibility. >> >> >> What if one wants to create a cute looking rich client in Erlang? >> The present graphical user interface is looking very old fashioned. > > > Erlang is so much better suited for the server side. Lets forget building > product quality GUIs in Erlang. You can't be everywhere. :-) That was uneccesary harsh. What I meant to say was that only a few have managed to create a GUI using the avilalable Erlang/OTP and still maintain a smile on people sitting on win32 clients. The same is true far Java as well I suppose. Cheers /Jocke From luke@REDACTED Mon Jan 27 18:17:22 2003 From: luke@REDACTED (Luke Gorrie) Date: 27 Jan 2003 18:17:22 +0100 Subject: test_server Message-ID: Howdy, I just downloaded and ran the test server application -- very nice. I got some failed cases though, using R9B-0 and building with a plain "./configure": 8 cases in the emulator suite, and one in the stdlib suite. Details attached. Just wondering if these are known problems, or if they suggest a problem with my setup? (Pardon the wide formatting. if you read this in Emacs you probably want to use M-x toggle-truncate-lines to avoid wrapping, and then C-x > and C-x < to scroll horizontally.) Emulator suite: |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 299 | sl_alloc_SUITE | bucket_index | 0.014 s | FAILED | {sl_alloc_SUITE,662} | | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 300 | sl_alloc_SUITE | coalesce | 0.013 s | FAILED | {sl_alloc_SUITE,662} | | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 301 | sl_alloc_SUITE | coalesce_debug | 0.013 s | FAILED | {sl_alloc_SUITE,662} | | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 302 | sl_alloc_SUITE | sl_realloc_copy | 0.013 s | FAILED | {sl_alloc_SUITE,662} | | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 303 | sl_alloc_SUITE | sl_realloc_copy_debug | 0.014 s | FAILED | {sl_alloc_SUITE,662} | | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 304 | sl_alloc_SUITE | threads | 0.013 s | FAILED | {sl_alloc_SUITE,662} | | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 305 | sl_alloc_SUITE | threads_debug | 0.014 s | FAILED | {sl_alloc_SUITE,662} | | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 306 | sl_alloc_SUITE | halloc_wrap | 0.013 s | FAILED | {sl_alloc_SUITE,662} | | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| === *** FAILED *** test case 299 of 389 =case sl_alloc_SUITE:coalesce =logfile sl_alloc_suite.coalesce.html =started 2003-01-27 17:48:50 =ended 2003-01-27 17:48:51 =result failed:{sl_alloc_SUITE,662} === *** FAILED *** test case 300 of 389 =case sl_alloc_SUITE:coalesce_debug =logfile sl_alloc_suite.coalesce_debug.html =started 2003-01-27 17:48:51 =ended 2003-01-27 17:48:51 =result failed:{sl_alloc_SUITE,662} === *** FAILED *** test case 301 of 389 =case sl_alloc_SUITE:sl_realloc_copy =logfile sl_alloc_suite.sl_realloc_copy.html =started 2003-01-27 17:48:51 =ended 2003-01-27 17:48:51 =result failed:{sl_alloc_SUITE,662} === *** FAILED *** test case 302 of 389 =case sl_alloc_SUITE:sl_realloc_copy_debug =logfile sl_alloc_suite.sl_realloc_copy_debug.html =started 2003-01-27 17:48:51 =ended 2003-01-27 17:48:51 =result failed:{sl_alloc_SUITE,662} === *** FAILED *** test case 303 of 389 =case sl_alloc_SUITE:threads =logfile sl_alloc_suite.threads.html =started 2003-01-27 17:48:51 =ended 2003-01-27 17:48:51 =result failed:{sl_alloc_SUITE,662} === *** FAILED *** test case 304 of 389 =case sl_alloc_SUITE:threads_debug =logfile sl_alloc_suite.threads_debug.html =started 2003-01-27 17:48:51 =ended 2003-01-27 17:48:51 =result failed:{sl_alloc_SUITE,662} === *** FAILED *** test case 305 of 389 =case sl_alloc_SUITE:halloc_wrap =logfile sl_alloc_suite.halloc_wrap.html =started 2003-01-27 17:48:51 =ended 2003-01-27 17:48:51 =result failed:{sl_alloc_SUITE,662} === *** FAILED *** test case 306 of 389 =case sl_alloc_SUITE:skipped_cases =logfile sl_alloc_suite.skipped_cases.html =started 2003-01-27 17:48:51 =ended 2003-01-27 17:48:51 =result skipped Stdlib suite: |-----+-------------------------+----------------------------+-----------+---------+--------------------------------------| | 142 | ets_SUITE | partly_bound | 4.180 s | FAILED | {ets_SUITE,525} | |-----+-------------------------+----------------------------+-----------+---------+--------------------------------------| === Test case started with ets_SUITE:partly_bound[[{data_dir, "/tmp/test/stdlib_test/ets_SUITE_data/"}, {priv_dir, "/tmp/test/test_server/stdlib.logs/run.2003-01-27_17.56.44/log_private"}, {nodes,[]}]] === Current directory is "/tmp/test/test_server" === Started at 2003-01-27 17:59:16 20.9500>36 20.2867>34 21.8183>33 21.2500>35 20.6350>36 21.1350>34 20.7283>36 20.5000>37 21.2850>33 20.9267>36 === Ended at 2003-01-27 17:59:20 === location {ets_SUITE,525}, reason={{badmatch,false}, [{ets_SUITE,seventyfive_percent_success,4}, {ets_SUITE,partly_bound,1}, {test_server,ts_tc,3}, {test_server,run_test_case_eval,5}]} From luke@REDACTED Mon Jan 27 18:20:07 2003 From: luke@REDACTED (Luke Gorrie) Date: 27 Jan 2003 18:20:07 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E3570EF.605@bluetail.com> References: <200301271517.h0RFHtn09807@bonsai.fernuni-hagen.de> <3E3551D0.5000502@bluetail.com> <3E3570EF.605@bluetail.com> Message-ID: "Joakim G." writes: > That was uneccesary harsh. What I meant to say was that only a few have > managed to create a GUI using the avilalable Erlang/OTP and still maintain > a smile on people sitting on win32 clients. Of course this problem is now solved by the emacs-based user interface toolkit. ;-) -Luke From etxuwig@REDACTED Mon Jan 27 18:47:24 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 27 Jan 2003 18:47:24 +0100 (MET) Subject: gen_server:selective_receive/1 Message-ID: Perhaps a really bad idea, but I thought I'd through it out there to see what responses I get... Gen_server is great in many ways, but now and again, I stumble upon the need to do a selective receive to see if there is an important message already in the queue. Traditionally, I've done this by sending all "important" messages as plain messages, and handling them in handle_info/2, but this is of course cheating and "bad" for a couple of reasons. Another way to solve it is to simply do a receive, looking for messages tagged as '$gen_call' or '$gen_cast, but this breaks the gen_server abstraction -- and the format of these messages is not defined in the gen_server API. Also, we would probably like to avoid the gen_server callback looking for messages that mean something to the gen_server module. Now for the potentially disgusting idea -- I wrote this in gen_server.erl: selective_receive(Filter) -> {_, Messages} = process_info(self(), messages), Parent = get_parent(), select(Messages, Filter, Parent). select([{'$gen_call',From,Request} = X|Rest], Filter, Parent) -> select_test({call,From,Request}, Filter, Rest, Parent); select([{'$gen_cast',Msg} = X|Rest], Filter, Parent) -> select_test({cast, Msg}, Filter, Rest, Parent); select([{'EXIT',Parent,Why}|Rest], Filter, Parent) -> %% ignore select(Rest, Filter, Parent); select([Msg|Rest], Filter, Parent) when size(Msg) == 6, element(1,Msg) == system -> %% ignore select(Rest, Filter, Parent); select([Msg|Rest], Filter, Parent) -> select_test({info, Msg}, Filter, Rest, Parent); select([], _, _) -> false. select_test(Msg, Filter, Rest, Parent) -> case Filter(Msg) of true -> receive X -> {ok, X} end; false -> select(Rest, Filter, Parent) end. Here's an example of where I'd like to use it: handle_cast({global_state, S1}, S) -> {noreply, S#state{global_state = S1}}; handle_cast({new_master, Pid}, S) when Pid == self() -> case gen_server:selective_receive( fun({cast, {global_state, _}}) -> true; (_) -> false end) of false -> {noreply, become_master(S)}; {ok, {cast, {global_state, GS}}} -> {noreply, become_master(S#state{global_state = GS})} end. (Of course, one would want to iterate over this function to make sure that we get the last version of the global state, but that doesn't necessarily bear on the idea as such.) What do you think -- stupid? unnecessary? dangerous? ...good? /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From etxuwig@REDACTED Mon Jan 27 18:50:26 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Mon, 27 Jan 2003 18:50:26 +0100 (MET) Subject: gen_server:selective_receive/1 In-Reply-To: Message-ID: On Mon, 27 Jan 2003, Ulf Wiger wrote: > >Perhaps a really bad idea, but I thought I'd through it out ^^^^^^^ >there to see what responses I get... Ehh, that would be "throw". Apologies. I think I will go home now... /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From martin@REDACTED Mon Jan 27 20:23:47 2003 From: martin@REDACTED (martin j logan) Date: 27 Jan 2003 13:23:47 -0600 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E3551D0.5000502@bluetail.com> References: <200301271517.h0RFHtn09807@bonsai.fernuni-hagen.de> <3E3551D0.5000502@bluetail.com> Message-ID: <1043695428.30928.382.camel@berimbau> > > I see Java's available free documentation, the well done online tutorials > > and even the use of the javadoc tool as big plus of that language. > > The Erlang documentation seems less accessable to me. Richard Carlsson, has done a great job with edoc. It is an erlang specific doc generation tool. I have modified my erlang emacs mode to spit out all skeletons fully edoc'd. Edoc has increased the amount of useful documentation that I have with a minimum of pain. If anyone wants the emacs stuff just ask. Martin > > I fully agree. Dense. Steep learning curve. Geared towards zealots. > > Cheers > /Jocke > -- > If you think the pen is mightier than the sword, the next time someone > pulls out a sword I'd like to see you get up there with your Bic. > From vances@REDACTED Mon Jan 27 21:13:07 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 27 Jan 2003 15:13:07 -0500 Subject: Killing a erlang process. In-Reply-To: References: Message-ID: <20030127201307.GD16587@frogman.motivity.ca> Daniel, I'm not sure what you mean by "the telnet session timed out" as telnet sessions don't "time out" to my knowledge. However if you are connected through a NAT box that box may very well time out the assignment of your port and your telnet session will no longer be usable. The solution to these types of problems is to turn keep alives on. How to do that I'll leave you to discover. I suspect though that your Erlang node is still running as it doesn't know that you are no longer connected. Your shell process is still running and a netstat will show the telnet session as still connected. If there are no keep alives in use it has no way of knowing that the session is gone unless there is output from the process. If the telnet session is dropped, from the perspective of the your server, a SIGHUP will be received and the node should be killed. The other nodes will see that is gone and the name will be unregistered. As far as connecting to a running process is concerned I recommend following the embedded systems procedures for running your application. Once you have your application set up this way it is started using run_erl and you can connect to it using to_erl. -Vance From vances@REDACTED Mon Jan 27 21:21:40 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 27 Jan 2003 15:21:40 -0500 Subject: A Joeish Erlang distribution (long) In-Reply-To: References: <3E34FACE.8090605@bluetail.com> <20030127124945.GA3882@mremond.cgey.capgemini.fr> Message-ID: <20030127202140.GE16587@frogman.motivity.ca> On Mon, Jan 27, 2003 at 02:29:11PM +0100, Miguel Barreiro Paz wrote: } } ... On the other hand, a clearer and better established open source } development process for those modules or the core language itself would be } great. It has already been suggested before IIRC. Somebody submits a patch } or contrib, a commitee or iron-hand project lead either accepts or rejects } it with a reason. This is sorely missing IMHO. As it is the only way to submit bug reports or patches (for non license holders) is to email the erlang-questions list. I would suggest creating a seperate list for these. Even if the OTP crew entirely ignore it at least it would be there to read by anyone who cared. As it is I think it it takes a big issue to bother the list with. -Vance From vances@REDACTED Mon Jan 27 21:28:01 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 27 Jan 2003 15:28:01 -0500 Subject: A Joeish Erlang distribution (long) In-Reply-To: <200301271517.h0RFHtn09807@bonsai.fernuni-hagen.de> References: <3E34FACE.8090605@bluetail.com> <200301271517.h0RFHtn09807@bonsai.fernuni-hagen.de> Message-ID: <20030127202801.GF16587@frogman.motivity.ca> On Mon, Jan 27, 2003 at 04:17:55PM +0100, Marc Ernst Eddy van Woerkom wrote: } } What if one wants to create a cute looking rich client in Erlang? http://erlgtk.sourceforge.net I've never quite understood the problem with this. In as much as I love Erlang I still use C for some things and building a GUI would be one of them. The old saying goes when you're holding a hammer in your hand everything looks like a nail. -Vance From vances@REDACTED Mon Jan 27 21:41:38 2003 From: vances@REDACTED (Vance Shipley) Date: Mon, 27 Jan 2003 15:41:38 -0500 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E355F21.4010005@erix.ericsson.se> References: <3E34FACE.8090605@bluetail.com> <3E355F21.4010005@erix.ericsson.se> Message-ID: <20030127204138.GG16587@frogman.motivity.ca> On Mon, Jan 27, 2003 at 05:32:33PM +0100, Kenneth Lundin wrote: } } Here are some comments from the Erlang/OTP Product Manager at Ericsson. } } 1) We have plans to divide the Erlang/OTP distribution into s number of } separate packages. Preliminary we are thinking of 3 packages: } - Core package (erts,kernel,stdlib,sasl,mnesia,os_mon,inets,compiler,..) } - Tools&Utilities (parse_tools, tools, debugger, observer, et, tv, ... } - Telecom/protocols (snmp, asn1, orber, megaco, ... I would suggest that the core package be even more limited. All you really need to run Erlang is erts, kernel and stdlib. A "Development" package would be appropriate. If you think in terms of embedded systems and what they require it makes a cleaner seperation. It would be nice if the build process asked what you wanted to build. It is a pain to be waiting for your shiny new emulator to arrive and see that it's wasting your time building Corba tools. I've adopted the procedure of first touching lib/cosEvent/SKIP etc. -Vance From jamesh@REDACTED Mon Jan 27 22:58:41 2003 From: jamesh@REDACTED (James Hague) Date: Mon, 27 Jan 2003 15:58:41 -0600 Subject: A Joeish Erlang distribution (long) Message-ID: >I would suggest that the core package be even >more limited. All you really need to run Erlang >is erts, kernel and stdlib. Basic stuff like compiler and parsetools are pretty lightweight, and useful. It would be annoying, I think, if the core Erlang package was no good for development and you had to grab an additional small package in order to compile code. And, okay, like parsetools :) But I agree that mnesia should be moved out of the core. It's far from lightweight, and it's certainly not something that most people use. Isn't the crypto module semi-obsolete, because the MD5 digest functions have been added as BIFs? From roger@REDACTED Tue Jan 28 00:20:47 2003 From: roger@REDACTED (Roger) Date: Mon, 27 Jan 2003 15:20:47 -0800 Subject: A Joeish Erlang distribution (long) Message-ID: <200301272320.PAA07599@amber.he.net> I'm an erlang newbie. I think the language and it's distribution have a lot of potential. I would not suggest to take any of the packages out at this point. I would consider mnesia to be one of the killer apps of erlang. Try and create your own persistent (and even replicated) database in java or anything else, good luck, goodbye :-) I would definitly loose the OTP references though. It scared me ! When you talk about how it runs the routers in the various telecom companies, it causes all kinds of misconceptions. I would market erlang as a distributed, fault tolerant, send and pray semantics functional language. (Joe, did I miss anything). The main complaint I would have is that it doesn't have multibyte support. Other than that, I think it's pretty darn good. Wrt documentation, it would be great if all the pdf doc could zipped for download somewhere on the Erlang website (currently it's on a file by file basis, and web spiders don't work either). Another point of advocay, we should rank higher on the shootout list :-) http://www.bagley.org/~doug/shootout/ anyway, just my ramblings .. -Roger > >I would suggest that the core package be even > >more limited. All you really need to run Erlang > >is erts, kernel and stdlib. > > Basic stuff like compiler and parsetools are pretty lightweight, and useful. > It would be annoying, I think, if the core Erlang package was no good for > development and you had to grab an additional small package in order to > compile code. And, okay, like parsetools :) But I agree that mnesia should > be moved out of the core. It's far from lightweight, and it's certainly not > something that most people use. > > Isn't the crypto module semi-obsolete, because the MD5 digest functions have > been added as BIFs? > > From luke@REDACTED Tue Jan 28 00:32:12 2003 From: luke@REDACTED (Luke Gorrie) Date: 28 Jan 2003 00:32:12 +0100 Subject: site-erlang hack Message-ID: Ahoy, I just did a small hack that really didn't turn out as well as I'd hoped, but I'm posting it anyway :-) I'm trying to untangle the mess of directories added to my code path from my ~/.erlang. For example I have three unrelated modules called 'test' in my load path, not counting the 'test' module in our source tree at work :-) I just did a quick-and-dirty port of the basic Emacs Lisp code-loading idea, so you say: site_code:require(xmerl). and it looks for xmerl/ebin/ in ~/site-erlang/ or other configurable places, adds it to the path, and calls xmerl:site_init() if that function exists (and it can require other packages, etc.) The idea was to keep unneeded stuff out of my path, so if a program says require(erlrpc) it only gets the erlrpc/ebin/, and not the other copy of erlrpc in my NFS server's source tree :-) But in the cold light of evening it looks pretty low tech compared with namespaces from a hierarchical packaging system. What's the status of that now? Anyhow, here's the code incase someone has an idea to make it right: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: site_code.erl URL: From per@REDACTED Tue Jan 28 03:04:23 2003 From: per@REDACTED (Per Bergqvist) Date: Tue, 28 Jan 2003 03:04:23 +0100 Subject: =?iso-8859-1?q?gen=5Fserver:selective=5Freceive/1?= In-Reply-To: Message-ID: <200301280204.h0S24Nn20985@sork.levonline.com> Except that the tag is changed from '$gen_cast' to 'cast' etc. isn't this equivalent to a receive ... after 0 ? /Per ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From per@REDACTED Tue Jan 28 03:14:56 2003 From: per@REDACTED (Per Bergqvist) Date: Tue, 28 Jan 2003 03:14:56 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E355F21.4010005@erix.ericsson.se> Message-ID: <200301280214.h0S2EtL19816@lejon.levonline.com> Hi, > - Telecom/protocols (snmp, asn1, orber, megaco, ... Being a true telecom nerd I never understood what corba had to do with proper telecom protocols... :-) If you're going to do separate packages please send all the Corba stuff to its own peaceful heaven ... /Per From battelle@REDACTED Tue Jan 28 07:47:35 2003 From: battelle@REDACTED (Joe Battelle) Date: Mon, 27 Jan 2003 22:47:35 -0800 Subject: A Joeish Erlang distribution (long) References: <3E34FACE.8090605@bluetail.com> <3E355F21.4010005@erix.ericsson.se> Message-ID: <003701c2c699$24267030$6601a8c0@slim> As it seems difficult to package things in a way that suits everyone, I would like to propose that the main OTP release continue to contain everything, but that a script could be provided to crack the distribution into a subset'ed archive that suits the user. This subset can then be used for multi-machine installs, or hosted by people with a specific interest in Erlang (e.g. webservers). The base script could be provided and enhanced by members of the open source community, as well as by Ericsson. In fact, there would then not be much harm in having third-parties provide their own scripts and subset'ed distributions (that would include YAWS, etc.) because they could provide a link to the main distribution along with the source for the script that generated the subset. If users would like a minimal (or YAWS specialized) Erlang system, but don't have the computing resources (bandwidth/diskspace/development environment) to create it themselves, it shouldn't be hard to get an Erlang community member to run the script and provide the minimal distribution for them. -joe b. From seb@REDACTED Tue Jan 28 08:42:36 2003 From: seb@REDACTED (Sebastian Strollo) Date: 27 Jan 2003 23:42:36 -0800 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E34FACE.8090605@bluetail.com> References: <3E34FACE.8090605@bluetail.com> Message-ID: <4wwptqhwwib.fsf@locke.strollo.org> "Joakim G." writes: > Erlang is ready for an alternative distribution. It seems that this subject was pretty much dealt with in less than a day, so being on the west coast of continental USA I guess I am a little bit late... :-) Just wanted to add a comment (okay I wanted to "just add a comment" but it turned into a long babble:-) The thought of dividing up the Erlang distribution into smaller apps is at least as old as the Open Source release - I was trying really hard to implement it back in 1998 but the problems I had was that the build system was monolithic and very interdependent (for some applications no-one really knew exactly which the dependency applications were...) For example: a bunch of the apps have snmp MIBS, this meant that the whole ASN.1 compiler plus snmp app was needed to compile e.g. stdlib. One idea would then perhaps be to only compile the mibs if you had the snmp app, but then what would you do when you at a later stage when you realized you wanted snmp support in your project? And so on... I'm not saying it can't be done - it should be done, but it is tricky to get it right (at least it was). But, a good packaging system would be great, I would really like a more modularized distribution and from Kenneth it seems that it is on the way - great! But given that, I really don't see how your (i.e. Jocke:-) other ideas (apart perhaps from new language constructs, and without branching off the Erlang/OTP code base which no-one including yourself seems to think is a good idea, I don't see how it could be done) would require a new distribution? If people got together to write good documentation with more web inspired examples that would be great, and talks promoting Erlang as a COPL is also a good thing! I say lets work on making the existing distribution better and complement it with as much external resources as we can. A more systematic way of dealing with patches from the community by the OTP (as has been suggested before) would be great. Another idea for the OTP team: maybe a list of things that you feel needs work, but is currently not being worked on by the OTP group (due to lack of time or whatever). Hmm, I vaguely recall that there used to be such a page on erlang.org with future project ideas or whatever... Well I don't know, I'm just rambling here... :-) My 2c worth et.c. et.c. /Sebastian From richardc@REDACTED Tue Jan 28 10:04:57 2003 From: richardc@REDACTED (Richard Carlsson) Date: Tue, 28 Jan 2003 10:04:57 +0100 (MET) Subject: site-erlang hack In-Reply-To: Message-ID: On 28 Jan 2003, Luke Gorrie wrote: > But in the cold light of evening it looks pretty low tech compared > with namespaces from a hierarchical packaging system. What's the > status of that now? The packages (hierarchical module namespace) are in R9, "for evaluation" - but so far, nobody has reported any experiences at all, so please do try it out. The following page is the only documentation so far: http://www.erlang.se/publications/packages.html (Can also be found from the "Release highlights" chapter of the R9 documentation. Don't ask me why this page ended up where it did.) Packages are really easy to learn and use - go ahead and make my day! Try a small project first and see if you want to use it for larger things. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ From jocke@REDACTED Tue Jan 28 10:34:01 2003 From: jocke@REDACTED (Joakim G.) Date: Tue, 28 Jan 2003 10:34:01 +0100 Subject: A Joeish Erlang distribution (long) References: <3E34FACE.8090605@bluetail.com> <3E355F21.4010005@erix.ericsson.se> Message-ID: <3E364E89.50409@bluetail.com> This is good news indeed! *A warm feeling is spreading through my veins* Kenneth Lundin wrote: > Hi all, > > Here are some comments from the Erlang/OTP Product Manager at Ericsson. > > 1) We have plans to divide the Erlang/OTP distribution into s number of > separate packages. Preliminary we are thinking of 3 packages: > - Core package (erts,kernel,stdlib,sasl,mnesia,os_mon,inets,compiler,..) > - Tools&Utilities (parse_tools, tools, debugger, observer, et, tv, ... > - Telecom/protocols (snmp, asn1, orber, megaco, ... Very good. Hopefully you got som input/inspiration from this thread as well. > The exact contents is not settled yet. > When this happens is not decided either but an optimistic guess is > before the end of 2003. Sigh. One year is a long time but I understand. > I am not very positive to the idea with an alternative distribution > where applications from us are exchanged with other similar applications > (e.g inets replaced by yaws). > I think it can be confusing for the users that the contents varies > for different distributions and that the quality and compatibility > strategy varies, between different applications within the same package. > > I think it is better that the concept where an Erlang/OTP installation > can be put together from several separate packages is defined and then > there can be additional packages for example one with internet_server > related applications that can be maintained and distributed separately > from the packages from us (OTP group at Ericsson). In that case I suppose an RPM:ish application in the core package would be nice. To me it seems wise to keep the Telecom label away from the core package. The focus could be on something like (I take the risk saying this again): 1 Internet (server) programming focus 2 Concurrency Oriented Programming Language 3 Simplicity (OTP not. Thus 4) 4 Capable of handling small/middle/largish software projects >> 3 Complex design patterns (due to 4) > > I don't think there is to much focus on design patterns and most of > them are useful in any SW project. What I meant was that new small and/middle sized software projects is IMO advised to avoid gen_servers, supervisors, application controllers, appup, relup, boot scripts, gen_fsm, release_handler and the stuff described in the "OTP Design Principles". It scares Erlang newcomers sh?tless. Rogers comment is probably typical: "I would definitly loose the OTP references though. It scared me ! When you talk about how it runs the routers in the various telecom companies, it causes all kinds of misconceptions." I know. An Erlang core package itself uses OTP a lot. That doesn't need to show in the Core User Guide though. For small/middle sized software projects its better to write native and transparant pure Erlang code. The core package documentation could include a number of simple pure best practice Erlang skeleton code for: tcp_server gen_server (loop, recieved based, nice init phase etc.) application controller (top level process handling child process re/starts etc.). A steep learning curve. Not. >> 4 Can handle humongously large software projects. > > I don't think there are any specific SW within Erlang/OTP or the > documentation which only is relevant for "humongously large" projects. Then we disagree. >> 5 Conservative to addition/removal of language constructs/libraries >> (thus 6). > > Very important to have a stable foundation. It is hard to remove things > because of backwards compatibility issues. Before we add things we like > to be reasonably sure thast we want to support it for a long time. We > must also be able to guarantee the quality. > Sometimes we add things which we point out as unsupported just to let > the users try it. I see your point and want argue. >> Documentation >> ------------- >> Documentation is the key to the spread the COPL message/distribution. >> Because of the "pure" Erlang (read: non-OTP) nature of the >> distribution a revised version of the Erlang book would suffice. I >> know: It has to be written from scratch to avoid copyright >> infringement. At least is doesn't need to describe OTP so the work >> involved would be _somewhat_ restricted. This means a lot of work. I >> can volunteer with a chapter on how to write an xmlrpc servers/clients >> [if this is what the editor wants]. > > We have work in progress here too. The goal is of course that our > documentation fully can replace the need of the the book. Splendid! Do you have a time plan for this (which you can share?) Happier /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From jocke@REDACTED Tue Jan 28 10:41:21 2003 From: jocke@REDACTED (Joakim G.) Date: Tue, 28 Jan 2003 10:41:21 +0100 Subject: A Joeish Erlang distribution (long) References: <3E34FACE.8090605@bluetail.com> <4wwptqhwwib.fsf@locke.strollo.org> Message-ID: <3E365041.4030307@bluetail.com> Sebastian Strollo wrote: > > But, a good packaging system would be great, I would really like a > more modularized distribution and from Kenneth it seems that it is on > the way - great! But given that, I really don't see how your > (i.e. Jocke:-) other ideas (apart perhaps from new language > constructs, and without branching off the Erlang/OTP code base which > no-one including yourself seems to think is a good idea, I don't see > how it could be done) would require a new distribution? It may not. I didn't have a clue that Kenneth&Co was about to repackage Erlang/OTP. If they decide retarget/reniche the core target as well (in the vicinity of my propsal) I would swoon (if possible). > If people got > together to write good documentation with more web inspired examples > that would be great, and talks promoting Erlang as a COPL is also a > good thing! A new book is on its way it seems. Really good news. The way it describes and examplifies the "new" Erlang is crucial. OTP? Pure Erlang? COPL? ... > I say lets work on making the existing distribution better and > complement it with as much external resources as we can. A more > systematic way of dealing with patches from the community by the OTP > (as has been suggested before) would be great. Another idea for the > OTP team: maybe a list of things that you feel needs work, but is > currently not being worked on by the OTP group (due to lack of time or > whatever). Hmm, I vaguely recall that there used to be such a page on > erlang.org with future project ideas or whatever... Well I don't know, Yes, yes, yes. Cheers /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From klacke@REDACTED Tue Jan 28 10:45:17 2003 From: klacke@REDACTED (Klacke) Date: Tue, 28 Jan 2003 10:45:17 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E365041.4030307@bluetail.com>; from jocke@bluetail.com on Tue, Jan 28, 2003 at 10:41:21AM +0100 References: <3E34FACE.8090605@bluetail.com> <4wwptqhwwib.fsf@locke.strollo.org> <3E365041.4030307@bluetail.com> Message-ID: <20030128104517.B9116@bluetail.com> > > If people got > > together to write good documentation with more web inspired examples > > that would be great, and talks promoting Erlang as a COPL is also a > > good thing! > > A new book is on its way it seems. Really good news. The way it describes > and examplifies the "new" Erlang is crucial. OTP? Pure Erlang? COPL? ... Who is working on this ?? I would be willing to contribute a chapter on the theme of "Server side web programming" /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From bjarne@REDACTED Tue Jan 28 10:44:31 2003 From: bjarne@REDACTED (=?iso-8859-1?Q?Bjarne_D=E4cker?=) Date: Tue, 28 Jan 2003 10:44:31 +0100 Subject: A Joeish Erlang distribution Message-ID: <003801c2c6b1$dc50f780$de0b69d4@segeltorp> Hello Kenneth Lundin wrote: Hi all, Here are some comments from the Erlang/OTP Product Manager at Ericsson. 1) We have plans to divide the Erlang/OTP distribution into s number of separate packages. Preliminary we are thinking of 3 packages: - Core package (erts,kernel,stdlib,sasl,mnesia,os_mon,inets,compiler,..) - Tools&Utilities (parse_tools, tools, debugger, observer, et, tv, ... - Telecom/protocols (snmp, asn1, orber, megaco, ... The exact contents is not settled yet. When this happens is not decided either but an optimistic guess is before the end of 2003. Do you think that further such packages could be developed by people outside the Erlang/OTP team? There is some research money available both on national and European level (for example Eureka). Perhaps we could put together some proposal. Bjarne -------------- next part -------------- An HTML attachment was scrubbed... URL: From jocke@REDACTED Tue Jan 28 10:48:51 2003 From: jocke@REDACTED (Joakim G.) Date: Tue, 28 Jan 2003 10:48:51 +0100 Subject: A Joeish Erlang distribution (long) References: <3E34FACE.8090605@bluetail.com> <4wwptqhwwib.fsf@locke.strollo.org> <3E365041.4030307@bluetail.com> <20030128104517.B9116@bluetail.com> Message-ID: <3E365203.9070003@bluetail.com> Klacke wrote: >>>If people got >>>together to write good documentation with more web inspired examples >>>that would be great, and talks promoting Erlang as a COPL is also a >>>good thing! >> >>A new book is on its way it seems. Really good news. The way it describes >>and examplifies the "new" Erlang is crucial. OTP? Pure Erlang? COPL? ... > > > > Who is working on this ?? I would be willing to contribute > a chapter on the theme of "Server side web programming" Me too. If the editor wants an xmlrpc subsection in the book. /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From Niclas.Eklund@REDACTED Tue Jan 28 10:58:55 2003 From: Niclas.Eklund@REDACTED (Niclas Eklund) Date: Tue, 28 Jan 2003 10:58:55 +0100 (MET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <200301280214.h0S2EtL19816@lejon.levonline.com> Message-ID: Hello! Besides the fact that Telecom is one most productive domains within OMG, CORBA is widely used within telecom (Ericsson, Lucent, Siemens, Nokia, Motorola, Nortel etc etc). On the other hand, should one, for example, consider SNMP to be a "pure" telecom protocol? IMHO, the answer is no in both cases. I assume that's the reason why the package was named "Telecom/protocols" instead of "Telecom protocols" ;-) /Nick > Hi, > > > - Telecom/protocols (snmp, asn1, orber, megaco, ... > Being a true telecom nerd I never understood what corba had > to do with proper telecom protocols... :-) > If you're going to do separate packages please send all the Corba > stuff to its own peaceful heaven ... > > /Per > From etxuwig@REDACTED Tue Jan 28 11:10:08 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 28 Jan 2003 11:10:08 +0100 (MET) Subject: =?iso-8859-1?q?gen=5Fserver:selective=5Freceive/1?= In-Reply-To: <200301280204.h0S24Nn20985@sork.levonline.com> Message-ID: On Tue, 28 Jan 2003, Per Bergqvist wrote: >Except that the tag is changed from '$gen_cast' to 'cast' >etc. isn't this equivalent to a receive ... after 0 ? > >/Per It's supposed to be the semantic equivalent of receive ... after 0, except for a couple of details: - gen_server handles some messages in a special way. These messages are (a) EXIT from the parent, and (b) system messages. Inadvertedly consuming and perhaps discarding these messages can have very bad effects on the system. - It's difficult to write a receive clause that fetches calls, casts and info messages without also consuming the other messages. It can be done, but you really have to give it some thought. - The gen_server API doesn't define what messages are special, what are the invariants of the internal gen_server messages, or what one is really allowed to do with the messages that gen_server cares about. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From hans@REDACTED Tue Jan 28 11:27:35 2003 From: hans@REDACTED (Hans Nilsson) Date: Tue, 28 Jan 2003 11:27:35 +0100 (CET) Subject: Mnemosyne Problems? In-Reply-To: <004c01c2c321$bad5b520$f67a40d5@telia.com> Message-ID: On Thu, 23 Jan 2003, Wiger Ulf wrote: > (http://www.erlang.se/publications/xjobb/sql_compiler_report.pdf) lists a > few things that should be fixed in mnemosyne, but also hints that it does a > pretty good job already. Others who have actually used it more may have more The focus in the Mnemosyne prototype was on query *optimization*. In DBMS query evaluation one have to change evaluation strategy completly depending on the actual data sets involved in the query. There are extreme cases reported in the litterature (with other DBMS) were execution time could go from 24 hours to 1 minute by just swithcing two subgoals in a complex query with large and nasty data sets. If there is a simple query or small and "nice" data sets this effect is not messurable and the optimization phase is just a timecomsuming null operation: the optimizer just suggests to evaluate the query straight on from the begining to the end. I agree completly that the kind of data where Mnemosyne's query otimization present good result is not present in telecom systems. > > For historical reasons, it was never really given a chance to mature from > prototype to product, but was basically just thrown into the first OTP > together with mnesia. While mnesia _was_ extremely useful for telecoms and > was put under high pressure to improve over the years, mnemosyne was not > given the same attention. Exactly!! /Hans From D.WILLIAMS@REDACTED Tue Jan 28 11:34:06 2003 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Tue, 28 Jan 2003 11:34:06 +0100 Subject: A Joeish Erlang distribution (long) Message-ID: I am currently evaluating Erlang with a view to adopting it for a railway traffic supervision system. Here is my view on a separate Erlang distribution, and on the packaging, and how all that would affect my evaluation process. I would have been put off if I had discovered that there were several Erlang distributions. It is hard enough to decide whether or not to adopt Erlang without having to decide which one to use, or being afraid that the one I choose would one day become obsolete because the other one is better. I also would be less impressed with Erlang if it did not come with so much stuff, even though all of it may not be useful for me. So I think having several packages is also a bad idea. Java is (for some reason) very popular, so no one seems to be put off having to download a huge, single package, which includes lots of stuff they don't need. I think this need to leave out certain things is only for experienced users: the solution I would favour is simply a better quality overall makefile, where dependencies are not broken, and where you can choose your targets... There is nothing preventing other folks extending Erlang (e.g. the web stuff that has been mentioned) by providing additional apps, that can be downloaded separately... It is up to these contributors to provide good quality code, and also good quality build/installation scripts, and documentation, so that the contributions become used by the Erlang community! Just my two cents worth... From D.WILLIAMS@REDACTED Tue Jan 28 11:42:36 2003 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Tue, 28 Jan 2003 11:42:36 +0100 Subject: A Joeish Erlang distribution (long) Message-ID: > From: Joakim G. [mailto:jocke@REDACTED] > > [...] > What I meant was that new small and/middle sized software projects is > IMO advised to avoid gen_servers, supervisors, application > controllers, > appup, relup, boot scripts, gen_fsm, release_handler and the stuff > described in the "OTP Design Principles". > > It scares Erlang newcomers sh?tless. Sorry, but I am an Erlang newcomer, and the OTP Design Principles and implementation of design patterns and architectural modules, and all the production tools (boot scripts etc.), are among the things that attract me to Erlang! From bjorn@REDACTED Tue Jan 28 11:48:10 2003 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 28 Jan 2003 11:48:10 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: Sebastian Strollo's message of "27 Jan 2003 23:42:36 -0800" References: <3E34FACE.8090605@bluetail.com> <4wwptqhwwib.fsf@locke.strollo.org> Message-ID: Sebastian Strollo writes: > Just wanted to add a comment (okay I wanted to "just add a comment" > but it turned into a long babble:-) The thought of dividing up the > Erlang distribution into smaller apps is at least as old as the Open > Source release - I was trying really hard to implement it back in 1998 > but the problems I had was that the build system was monolithic and > very interdependent (for some applications no-one really knew exactly > which the dependency applications were...) > > For example: a bunch of the apps have snmp MIBS, this meant that the > whole ASN.1 compiler plus snmp app was needed to compile > e.g. stdlib. One idea would then perhaps be to only compile the mibs > if you had the snmp app, but then what would you do when you at a > later stage when you realized you wanted snmp support in your project? > And so on... I'm not saying it can't be done - it should be done, but > it is tricky to get it right (at least it was). > We still have the same kind of problems, except that we maybe understand more about the application dependencies by now. Now that splitting up OTP in several parts has got higher priority than is used to have, we have hope that it will get done before the end of 2003. /Bjorn -- Bj?rn Gustavsson Ericsson Utvecklings AB bjorn@REDACTED ?T2/UAB/F/P BOX 1505 +46 8 727 56 87 125 25 ?lvsj? From jocke@REDACTED Tue Jan 28 12:17:35 2003 From: jocke@REDACTED (Joakim G.) Date: Tue, 28 Jan 2003 12:17:35 +0100 Subject: A Joeish Erlang distribution (long) References: Message-ID: <3E3666CF.3000905@bluetail.com> WILLIAMS Dominic wrote: >>From: Joakim G. [mailto:jocke@REDACTED] >> >>[...] >>What I meant was that new small and/middle sized software projects is >>IMO advised to avoid gen_servers, supervisors, application >>controllers, >>appup, relup, boot scripts, gen_fsm, release_handler and the stuff >>described in the "OTP Design Principles". >> >>It scares Erlang newcomers sh?tless. > > Sorry, but I am an Erlang newcomer, and the OTP Design Principles and > implementation of design patterns and architectural modules, and all the > production tools (boot scripts etc.), are among the things that attract > me to Erlang! That is nice (for Erlang/OTP). I doubt that you are that representative though. _One_ of the reasons for Erlang not having the same user base as for example python is the steep OTP learning curve. Cheers /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From francesco@REDACTED Tue Jan 28 12:22:27 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 28 Jan 2003 11:22:27 +0000 Subject: A Joeish Erlang distribution (long) References: <3E34FACE.8090605@bluetail.com> <3E355F21.4010005@erix.ericsson.se> <3E364E89.50409@bluetail.com> Message-ID: <3E3667F3.7020405@erlang-consulting.com> > What I meant was that new small and/middle sized software projects is > IMO advised to avoid gen_servers, supervisors, application controllers, > appup, relup, boot scripts, gen_fsm, release_handler and the stuff > described in the "OTP Design Principles". I totally disagree. It is the above that adds even more to the productive factor of the programmers using Erlang, allowing small to medium size projects to be successful. I might agree to bypassing the above design principles when putting together the evaluation prototype, but absolutely not when building the product itself. The design principles give you what lacks in basic Erlang, namely a way to design the system, a way to organize and reuse parts of the source code, and a way to reason when putting it together. I have seen people reinvent the wheel so many times when not using OTP correctly, and I will stop here as I could go on for ages... The above will eventually deter potential users, as they will not experience the factor 4 - 10 of the productivity increase we who know OTP usually ramble about, and get stuck in trying to solve problems the OTP developers have taken hundreds of hours to think of, test and develop. Back to work.. Have a nice day :-) Francesco -- http://www.erlang-consulting.com From jocke@REDACTED Tue Jan 28 12:24:34 2003 From: jocke@REDACTED (Joakim G.) Date: Tue, 28 Jan 2003 12:24:34 +0100 Subject: A Joeish Erlang distribution (long) References: <3E34FACE.8090605@bluetail.com> <3E355F21.4010005@erix.ericsson.se> <3E364E89.50409@bluetail.com> <3E3667F3.7020405@erlang-consulting.com> Message-ID: <3E366872.3020707@bluetail.com> Francesco Cesarini wrote: >> What I meant was that new small and/middle sized software projects is >> IMO advised to avoid gen_servers, supervisors, application controllers, >> appup, relup, boot scripts, gen_fsm, release_handler and the stuff >> described in the "OTP Design Principles". > > > > I totally disagree. It is the above that adds even more to the > productive factor of the programmers using Erlang, allowing small to > medium size projects to be successful. I might agree to bypassing the > above design principles when putting together the evaluation prototype, > but absolutely not when building the product itself. > > The design principles give you what lacks in basic Erlang, namely a way > to design the system, a way to organize and reuse parts of the source > code, and a way to reason when putting it together. I have seen people > reinvent the wheel so many times when not using OTP correctly, and I > will stop here as I could go on for ages... > > The above will eventually deter potential users, as they will not > experience the factor 4 - 10 of the productivity increase we who know > OTP usually ramble about, and get stuck in trying to solve problems the > OTP developers have taken hundreds of hours to think of, test and develop. > > Back to work.. Have a nice day :-) Couldn't disagree more. Back to work - yes. /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From per@REDACTED Tue Jan 28 12:34:50 2003 From: per@REDACTED (Per Bergqvist) Date: Tue, 28 Jan 2003 12:34:50 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: Message-ID: <200301281134.h0SBYoh12793@lejon.levonline.com> I don't doubt that the telecom sector produce a lot of paperwork within OMG :-) (After working with implementations of telecom protocols for the last 16 years I haven't seen a core telecom system using corba for external communication. I have seen one using it for internal comms and that was probably not the wisest move...) Anyway, the point was that is a VERY large chunk of the OTP distribution and I have never used it. /Per > > Hello! > > Besides the fact that Telecom is one most productive domains within OMG, > CORBA is widely used within telecom (Ericsson, Lucent, Siemens, Nokia, > Motorola, Nortel etc etc). On the other hand, should one, for example, > consider SNMP to be a "pure" telecom protocol? IMHO, the answer is no in > both cases. I assume that's the reason why the package was named > "Telecom/protocols" instead of "Telecom protocols" ;-) > > /Nick > > > > Hi, > > > > > - Telecom/protocols (snmp, asn1, orber, megaco, ... > > Being a true telecom nerd I never understood what corba had > > to do with proper telecom protocols... :-) > > If you're going to do separate packages please send all the Corba > > stuff to its own peaceful heaven ... > > > > /Per > > > > > > > ========================================================= Per Bergqvist Synapse Systems AB Phone: +46 709 686 685 Email: per@REDACTED From joe@REDACTED Tue Jan 28 12:42:58 2003 From: joe@REDACTED (Joe Armstrong) Date: Tue, 28 Jan 2003 12:42:58 +0100 (CET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <20030127204138.GG16587@frogman.motivity.ca> Message-ID: On Mon, 27 Jan 2003, Vance Shipley wrote: > On Mon, Jan 27, 2003 at 05:32:33PM +0100, Kenneth Lundin wrote: > } > } Here are some comments from the Erlang/OTP Product Manager at Ericsson. > } > } 1) We have plans to divide the Erlang/OTP distribution into s number of > } separate packages. Preliminary we are thinking of 3 packages: > } - Core package (erts,kernel,stdlib,sasl,mnesia,os_mon,inets,compiler,..) > } - Tools&Utilities (parse_tools, tools, debugger, observer, et, tv, ... > } - Telecom/protocols (snmp, asn1, orber, megaco, ... > > I would suggest that the core package be even more limited. All you really > need to run Erlang is erts, kernel and stdlib. A "Development" package > would be appropriate. If you think in terms of embedded systems and what > they require it makes a cleaner seperation. I entirely agree - snmp mensia etc are *applications that are written in Erlang - they should not therefore be in the core release. The core should be: 1) The compiler 2) The run time 3) A minimal set of libraries to do something "useful" Think C - a minimal set of stuff is - A compiler that runs "out of the box" - A minimal set of libraries (libc) so you can do something. IMHO we should have: - A compiler that runs "out of the box" - Minimal library support Somewhere you have to "draw the line" My "minimal support" really means device drivers - so support for files, sockets, binary filers, ... etc. is in - everything else is out. also ets is so low level that it can be considered "part of the language" We have to be pragmatic as well so I'd include - dets - dynamic code loading - the shell As well in the core. (But no snmp, mnesia, .... asn1 etc.) these are *applications* written in Erlang - and no gen_server ... etc.) IMHO gen_tcp etc. dets should be written so they don't use gen_severer etc. - BTW my stand-alone Erlang broke just when I wanted to use dets and gen_tcp - the reason was the dets and gen_tcp uses all the application stuff and the gen_* stuff. One of the basic design principles underlying the system is (as Martin Bj?rkland said) "There is stuff that has to be right, and stuff that doesn't - you have to make you mind up." IMHO the core should NOT be able to recover from errors - you get the core right - period. Applications outside the core can if they wish build upon gen_* modules to make the apps. fault-tolerant - but the core should be A. Priori assumed correct - and have no such code. This is *why* the core should be as small as possible and include as much pure code as possible (i.e code like in lists etc.) I think the discussion should proceed upon a module per. module basis. We should not be talking about which component lives in the core (i.e. do we include snmp, corba etc.) but the discussion should be ... The core is compiler+stdlib+sasl+kernel with the following changes: The following modules are *removed* supervisor_bridge.erl sos.erl supervisor.erl gen_*.erl ... etc. Then all the remaining modules should be re-written so that NO references are made to the stuff that is removed. Finally we will be able to give an exact and final list of every module in the core with a written argument that motivates *exactly* why it in the core. When this has been done I will be happy. IMHO the average programmer should be able to easily remember all the Erlang primitive and know about *all* the core modules do - Erlang should and must be a *small* langauge - that is easy top learn - the core libraries should have the same properties. I can volunteer to do this (I can't do Jocke's big project) - but I'd need help (i.e. volunteers to *remove* non core-dependencies from dets and gen_tcp etc.). All this pre-supposes that the OTP people like the idea - since I don't want to get into the "two systems" argument. For those people who like the "big and everything release" we can bundle the core with *all* the applications - if that's what turns them on. I view recoding and re-organizing the core as *essential* - in so much as this will yield a tighter and more easily maintained system. Actually the job is easier than you imaging - you first throw out *everything* you cannot explicitly motivate - then run - xref - this tells you which modules you have to re-write. The modules you have removed you move to a set of libraries outside the core, and then re-write them using stuff *inside* core. Comments? /Joe > > It would be nice if the build process asked what you wanted to build. It > is a pain to be waiting for your shiny new emulator to arrive and see that > it's wasting your time building Corba tools. I've adopted the procedure > of first touching lib/cosEvent/SKIP etc. > > -Vance > From joe@REDACTED Tue Jan 28 12:50:57 2003 From: joe@REDACTED (Joe Armstrong) Date: Tue, 28 Jan 2003 12:50:57 +0100 (CET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E3667F3.7020405@erlang-consulting.com> Message-ID: On Tue, 28 Jan 2003, Francesco Cesarini wrote: > > What I meant was that new small and/middle sized software projects is > > IMO advised to avoid gen_servers, supervisors, application controllers, > > appup, relup, boot scripts, gen_fsm, release_handler and the stuff > > described in the "OTP Design Principles". > > > I totally disagree. It is the above that adds even more to the > productive factor of the programmers using Erlang, allowing small to > medium size projects to be successful. I might agree to bypassing the > above design principles when putting together the evaluation prototype, > but absolutely not when building the product itself. > I totally disagree - The OTP libraries "jump start" you into a way of programming fault tolerant apps. If you haven't thought long and deeply about how to program FT apps then by all means use the generics (that's what they are there for) - If you are in a BIG project use the generics (that's so you can understand the other peoples code). Once you get good at this you can start "rolling you own" - I usually re-invent gen_server for *every different complex program I write* they are subtly different - often the resultant code is much prettier - and *much* more inefficient I'm proud to say :-) /Joe > The design principles give you what lacks in basic Erlang, namely a way > to design the system, a way to organize and reuse parts of the source > code, and a way to reason when putting it together. I have seen people > reinvent the wheel so many times when not using OTP correctly, and I > will stop here as I could go on for ages... > Dyson re-invented the wheel and it was much better :-) http://www.searchappliance.co.uk/Manufacturers_Info/dyson.htm > The above will eventually deter potential users, as they will not > experience the factor 4 - 10 of the productivity increase we who know > OTP usually ramble about, and get stuck in trying to solve problems the > OTP developers have taken hundreds of hours to think of, test and develop. > > Back to work.. Have a nice day :-) You too > > Francesco > -- > http://www.erlang-consulting.com > From tobbe@REDACTED Tue Jan 28 13:01:03 2003 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Tue, 28 Jan 2003 13:01:03 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: References: Message-ID: <3E3670FF.3000007@bluetail.com> > > >I am currently evaluating Erlang with a view to adopting it for a railway traffic supervision system. > Ahh...I remember a nice little hack I, Magnus and Robert wrote once: We wrote a train supervision/control system for a Maerklin railway set that we showed at a big fair here in Stockholm. Robert wrote the control parts, dealing with sensors and switches etc, and Magnus and I wrote the GUI which consisted of an exact drawing of the real setup, where you could see where the different trainset were etc. Those were the days... :-) Cheers /Tobbe (Ps. some old GUI code can be found here: http://www.bluetail.com/~tobbe/train/ ) From enano@REDACTED Tue Jan 28 11:30:04 2003 From: enano@REDACTED (Miguel Barreiro Paz) Date: Tue, 28 Jan 2003 11:30:04 +0100 (CET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E364E89.50409@bluetail.com> References: <3E34FACE.8090605@bluetail.com> <3E355F21.4010005@erix.ericsson.se> <3E364E89.50409@bluetail.com> Message-ID: > What I meant was that new small and/middle sized software projects is > IMO advised to avoid gen_servers, supervisors, application controllers, > appup, relup, boot scripts, gen_fsm, release_handler and the stuff > described in the "OTP Design Principles". While that stuff is probably a bit scary for the average new erlang user, *please* don't forget that keeping certain design principles is a key differentiation factor for Erlang. One can write horrible code even in Erlang. A "design principles" section is, IMVHO, necessary, even if it's a bit lighter than today. Regards, Miguel From Vlad.Dumitrescu@REDACTED Tue Jan 28 13:48:04 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Tue, 28 Jan 2003 13:48:04 +0100 Subject: A Joeish Erlang distribution (long) Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F705@esemont203.gbg.edt.ericsson.se> Hi, another reason for which the distribution structure would benefit from being revised (with ot without repackaging, but more so with) is that the build process will have to be revisited too. Cleaning up all dependencies and generally streamlining the Makefiles would make life much easier for maintainance. Not to mention that it might make possible to build on Cygwin! ;-) A sidenote regarding use of Corba: here it is used in order to provide a common API to both a Java GUI and the C CLI. Possibly even higher-level OSS applications might use it, but I am not sure. I don't know about the Java side, but on the Erlang side using JInterface/erl_interface would have saved many many manhours... Last, about Miguel's comment about writing horrible code in Erlang: please don't get me started, I get to debug and fix and maintain such old code on a daily basis... Could it be that the "design guidelines" were not written back then? :-) regards, Vlad From rickard.green@REDACTED Tue Jan 28 13:57:10 2003 From: rickard.green@REDACTED (Rickard Green) Date: Tue, 28 Jan 2003 13:57:10 +0100 Subject: test_server References: Message-ID: <3E367E26.F5ABB134@uab.ericsson.se> Hello, The sl_alloc test cases fails in this case because 'make' fails (port programs are built). I guess that if you set the environment variable ERL_TOP to the source code root of Erlang/OTP, it will work. Hopefully I have rewritten the port program build part in R10B. Regards, Rickard Green (Erlang/OTP) Luke Gorrie wrote: > > Howdy, > > I just downloaded and ran the test server application -- very nice. > > I got some failed cases though, using R9B-0 and building with a plain > "./configure": 8 cases in the emulator suite, and one in the stdlib > suite. Details attached. > > Just wondering if these are known problems, or if they suggest a > problem with my setup? > > (Pardon the wide formatting. if you read this in Emacs you probably > want to use M-x toggle-truncate-lines to avoid wrapping, and then C-x > > and C-x < to scroll horizontally.) > > Emulator suite: > > |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | 299 | sl_alloc_SUITE | bucket_index | 0.014 s | FAILED | {sl_alloc_SUITE,662} | > | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | > |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | 300 | sl_alloc_SUITE | coalesce | 0.013 s | FAILED | {sl_alloc_SUITE,662} | > | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | > |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | 301 | sl_alloc_SUITE | coalesce_debug | 0.013 s | FAILED | {sl_alloc_SUITE,662} | > | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | > |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | 302 | sl_alloc_SUITE | sl_realloc_copy | 0.013 s | FAILED | {sl_alloc_SUITE,662} | > | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | > |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | 303 | sl_alloc_SUITE | sl_realloc_copy_debug | 0.014 s | FAILED | {sl_alloc_SUITE,662} | > | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | > |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | 304 | sl_alloc_SUITE | threads | 0.013 s | FAILED | {sl_alloc_SUITE,662} | > | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | > |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | 305 | sl_alloc_SUITE | threads_debug | 0.014 s | FAILED | {sl_alloc_SUITE,662} | > | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | > |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > | 306 | sl_alloc_SUITE | halloc_wrap | 0.013 s | FAILED | {sl_alloc_SUITE,662} | > | | | | | | {[77,97,107,101,32,102,97,105,108,101,100,32,119,105,116,104,32,101,114,114,111,114,32,99,111,100,101,58],2} | > |-----+-------------------------+--------------------------------------+----------+---------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| > > === *** FAILED *** test case 299 of 389 > =case sl_alloc_SUITE:coalesce > =logfile sl_alloc_suite.coalesce.html > =started 2003-01-27 17:48:50 > =ended 2003-01-27 17:48:51 > =result failed:{sl_alloc_SUITE,662} > === *** FAILED *** test case 300 of 389 > =case sl_alloc_SUITE:coalesce_debug > =logfile sl_alloc_suite.coalesce_debug.html > =started 2003-01-27 17:48:51 > =ended 2003-01-27 17:48:51 > =result failed:{sl_alloc_SUITE,662} > === *** FAILED *** test case 301 of 389 > =case sl_alloc_SUITE:sl_realloc_copy > =logfile sl_alloc_suite.sl_realloc_copy.html > =started 2003-01-27 17:48:51 > =ended 2003-01-27 17:48:51 > =result failed:{sl_alloc_SUITE,662} > === *** FAILED *** test case 302 of 389 > =case sl_alloc_SUITE:sl_realloc_copy_debug > =logfile sl_alloc_suite.sl_realloc_copy_debug.html > =started 2003-01-27 17:48:51 > =ended 2003-01-27 17:48:51 > =result failed:{sl_alloc_SUITE,662} > === *** FAILED *** test case 303 of 389 > =case sl_alloc_SUITE:threads > =logfile sl_alloc_suite.threads.html > =started 2003-01-27 17:48:51 > =ended 2003-01-27 17:48:51 > =result failed:{sl_alloc_SUITE,662} > === *** FAILED *** test case 304 of 389 > =case sl_alloc_SUITE:threads_debug > =logfile sl_alloc_suite.threads_debug.html > =started 2003-01-27 17:48:51 > =ended 2003-01-27 17:48:51 > =result failed:{sl_alloc_SUITE,662} > === *** FAILED *** test case 305 of 389 > =case sl_alloc_SUITE:halloc_wrap > =logfile sl_alloc_suite.halloc_wrap.html > =started 2003-01-27 17:48:51 > =ended 2003-01-27 17:48:51 > =result failed:{sl_alloc_SUITE,662} > === *** FAILED *** test case 306 of 389 > =case sl_alloc_SUITE:skipped_cases > =logfile sl_alloc_suite.skipped_cases.html > =started 2003-01-27 17:48:51 > =ended 2003-01-27 17:48:51 > =result skipped > > Stdlib suite: > > |-----+-------------------------+----------------------------+-----------+---------+--------------------------------------| > | 142 | ets_SUITE | partly_bound | 4.180 s | FAILED | {ets_SUITE,525} | > |-----+-------------------------+----------------------------+-----------+---------+--------------------------------------| > > === Test case started with ets_SUITE:partly_bound[[{data_dir, > "/tmp/test/stdlib_test/ets_SUITE_data/"}, > {priv_dir, > "/tmp/test/test_server/stdlib.logs/run.2003-01-27_17.56.44/log_private"}, > {nodes,[]}]] > > === Current directory is "/tmp/test/test_server" > > === Started at 2003-01-27 17:59:16 > 20.9500>36 > > 20.2867>34 > > 21.8183>33 > > 21.2500>35 > > 20.6350>36 > > 21.1350>34 > > 20.7283>36 > > 20.5000>37 > > 21.2850>33 > > 20.9267>36 > > === Ended at 2003-01-27 17:59:20 > === location {ets_SUITE,525}, reason={{badmatch,false}, > [{ets_SUITE,seventyfive_percent_success,4}, > {ets_SUITE,partly_bound,1}, > {test_server,ts_tc,3}, > {test_server,run_test_case_eval,5}]} From kenneth@REDACTED Tue Jan 28 14:14:20 2003 From: kenneth@REDACTED (Kenneth Lundin) Date: Tue, 28 Jan 2003 14:14:20 +0100 Subject: A Joeish Erlang distribution (long) References: Message-ID: <3E36822B.7090105@erix.ericsson.se> Joe Armstrong wrote: > On Mon, 27 Jan 2003, Vance Shipley wrote: > > >>On Mon, Jan 27, 2003 at 05:32:33PM +0100, Kenneth Lundin wrote: >>} >>} Here are some comments from the Erlang/OTP Product Manager at Ericsson. >>} >>} 1) We have plans to divide the Erlang/OTP distribution into s number of >>} separate packages. Preliminary we are thinking of 3 packages: >>} - Core package (erts,kernel,stdlib,sasl,mnesia,os_mon,inets,compiler,..) >>} - Tools&Utilities (parse_tools, tools, debugger, observer, et, tv, ... >>} - Telecom/protocols (snmp, asn1, orber, megaco, ... >> >>I would suggest that the core package be even more limited. All you really >>need to run Erlang is erts, kernel and stdlib. A "Development" package >>would be appropriate. If you think in terms of embedded systems and what >>they require it makes a cleaner seperation. I think a "core" package should contain the basic runtime environment, minimal set of tools for creating your own erlang modules (i.e the compiler) and some applications that almost everyone who want to try Erlang is interested in. snmp of course out, mnesia is in or out. > > > I entirely agree - snmp mensia etc are *applications that are > written in Erlang - they should not therefore be in the core release. > > The core should be: > > 1) The compiler > 2) The run time > 3) A minimal set of libraries to do something "useful" > > Think C - a minimal set of stuff is > > - A compiler that runs "out of the box" > - A minimal set of libraries (libc) so you can do something. > > IMHO we should have: > > - A compiler that runs "out of the box" > - Minimal library support > Somewhere you have to "draw the line" > > My "minimal support" really means device drivers - so support > for files, sockets, binary filers, ... etc. is in - everything else is out. > also ets is so low level that it can be considered "part of the language" > > We have to be pragmatic as well so I'd include > > - dets > - dynamic code loading > - the shell > > As well in the core. > > (But no snmp, mnesia, .... asn1 etc.) these are *applications* written in > Erlang - and no gen_server ... etc.) > > IMHO gen_tcp etc. dets should be written so they don't use > gen_severer etc. - BTW my stand-alone Erlang broke just when I wanted > to use dets and gen_tcp - the reason was the dets and gen_tcp uses all > the application stuff and the gen_* stuff. The division of the Erlang/OTP distribution into several (e.g 3) packages and the reorganization of individual applications such as kernel, stdlib etc. are two different matters that are to treated separately. I agree that there are many things within kernel and stdlib that could/should be rewritten to make the "core" parts cleaner independent from other "optional" stuff. BUT the division into several packages will not involve rewriting of modules or dratical changes in the contents of kernel and stdlib. Some small justifications are planned, such as a removal of the snmp-mibs from sasl. Since several years this unfortunate placing of the MIBs has created a build dependency between the current core parts and SNMP forcing every one to build the SNMP compiler before the runtime system could be built. > > One of the basic design principles underlying the system is (as > Martin Bj?rkland said) > > "There is stuff that has to be right, and stuff that doesn't - you > have to make you mind up." > > IMHO the core should NOT be able to recover from errors - you get the core > right - period. > > Applications outside the core can if they wish build upon gen_* > modules to make the apps. fault-tolerant - but the core should be > A. Priori assumed correct - and have no such code. > > This is *why* the core should be as small as possible and include as > much pure code as possible (i.e code like in lists etc.) > > I think the discussion should proceed upon a module per. module basis. > > We should not be talking about which component lives in the core > (i.e. do we include snmp, corba etc.) but the discussion should be ... > > The core is compiler+stdlib+sasl+kernel with the following > changes: > > The following modules are *removed* > > supervisor_bridge.erl > sos.erl > supervisor.erl > gen_*.erl > ... etc. I agree with the way of thinking but the number of modules in kernel and stdlib is not a problem for most of our customers, it is mainly a problem (small) for us when maintaining and developing the system. If we make drastical changes in these applications we will whoever create problems for our customers. Therefore we will make such changes step by step in a way that we can handle. The transition will not be fast and the removal of the gen_*.erl modules is certainly not one of the most important ones as I see it. > > Then all the remaining modules should be re-written so that NO > references are made to the stuff that is removed. > > Finally we will be able to give an exact and final list of every > module in the core with a written argument that motivates *exactly* > why it in the core. > > When this has been done I will be happy. > > IMHO the average programmer should be able to easily remember all > the Erlang primitive and know about *all* the core modules do - Erlang > should and must be a *small* langauge - that is easy top learn - the > core libraries should have the same properties. > > I can volunteer to do this (I can't do Jocke's big project) - but > I'd need help (i.e. volunteers to *remove* non core-dependencies from > dets and gen_tcp etc.). I don't agree that the removal of e.g gen_server and the dependencies to gen_server is top priority when it comes to improve and clean up in kernel and stdlib. Since many years we have treated kernel and stdlib as one application since the interdependencies are impossible to handle. A way to solve this step by step is to move out modules that don't belong in kernel+stdlib one by one util we have a useful result. > > All this pre-supposes that the OTP people like the idea - since I > don't want to get into the "two systems" argument. > > For those people who like the "big and everything release" we can > bundle the core with *all* the applications - if that's what turns > them on. > > I view recoding and re-organizing the core as *essential* - in so > much as this will yield a tighter and more easily maintained system. > > Actually the job is easier than you imaging - you first throw out > *everything* you cannot explicitly motivate - then run - xref - this > tells you which modules you have to re-write. The modules you have > removed you move to a set of libraries outside the core, and then > re-write them using stuff *inside* core. > > Comments? In principle ok, but in practice we have to be very careful and take this in small smart steps where we can keep the backward compatibility for all relevant interfaces as well as sequre the quality. > > > > /Joe > > > >>It would be nice if the build process asked what you wanted to build. It >>is a pain to be waiting for your shiny new emulator to arrive and see that >>it's wasting your time building Corba tools. I've adopted the procedure >>of first touching lib/cosEvent/SKIP etc. >> >> -Vance >> > /Kenneth (Product Manager of Erlang/OTP) -- Kenneth Lundin Ericsson AB kenneth@REDACTED ?T2/UAB/UKH/K BOX 1505 +46 8 727 57 25 125 25 ?lvsj? From etxuwig@REDACTED Tue Jan 28 14:25:57 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 28 Jan 2003 14:25:57 +0100 (MET) Subject: =?iso-8859-1?q?gen=5Fserver:selective=5Freceive/1?= In-Reply-To: <200301280204.h0S24Nn20985@sork.levonline.com> Message-ID: On Tue, 28 Jan 2003, Per Bergqvist wrote: >Except that the tag is changed from '$gen_cast' to 'cast' >etc. isn't this equivalent to a receive ... after 0 ? > >/Per OK, to follow up on the idea a step further, below's an implementation that actually works. The following code was written to test the new implementation (in a gen_server callback): handle_call(start_test, From, State) -> timer:sleep(3000), Reply = timer:tc( gen_server,fold_messages, [ fun({cast, _} = Msg, Acc) -> {true, [Msg|Acc]}; (Msg, Acc) -> false end, []]), {reply, Reply, State}. Basically gen_server:fold_messages(Fun, Acc), where Fun(Msg, Acc) should return {true, Acc1} or false (in the former case, the message is consumed, in the latter, not), had the following performance on my machine: # msgs in the queue exec. time (us) 10 6.5 100 300 1,000 3,000 10,000 40,000 The cost is, I think, reasonable. Still, after having gotten some sleep, I've decided that it doesn't solve the problem. It just reduces it (possibly creating other problems in the process.) The real problem is one of serialization, and cannot be addressed this way. I withdraw my suggestion. Bad idea. /Uffe fold_messages(Fun, Acc) -> {_, Messages} = process_info(self(), messages), Parent = get_parent(), fold(Messages, Fun, Acc, Parent). fold([{'$gen_call',From,Request} = X|Rest], Fun, Acc, Parent) -> fold_one({call,From,Request}, X, Fun, Acc, Rest, Parent); fold([{'$gen_cast',Msg} = X|Rest], Fun, Acc, Parent) -> fold_one({cast, Msg}, X, Fun, Acc, Rest, Parent); fold([{'EXIT',Pid,Why} = X|Rest], Fun, Acc, Parent) when Pid /= Parent -> fold_one(X, X, Fun, Acc, Rest, Parent); fold([Msg|Rest], Fun, Acc, Parent) when size(Msg) == 6, element(1,Msg) == system -> %% ignore fold(Rest, Fun, Acc, Parent); fold([Msg|Rest], Fun, Acc, Parent) -> fold_one({info, Msg}, Msg, Fun, Acc, Rest, Parent); fold([], _, Acc, _) -> Acc. fold_one(Msg, X, Fun, Acc, Rest, Parent) -> NewAcc = case Fun(Msg, Acc) of {true, Acc1} -> %% consume the message receive X -> X end, Acc1; false -> Acc end, fold(Rest, Fun, NewAcc, Parent). -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From Niclas.Eklund@REDACTED Tue Jan 28 14:30:16 2003 From: Niclas.Eklund@REDACTED (Niclas Eklund) Date: Tue, 28 Jan 2003 14:30:16 +0100 (MET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <200301281134.h0SBYoh12793@lejon.levonline.com> Message-ID: Hello! CORBA is usually used for OAM. See for example the following pdf-file: http://java.sun.com/products/oss/pdf/corba-wp-integration.0.10.pdf On page 8 you find a rather good overview. See also www.parlay.org or www.3gpp.org. Yes, Orber is a little bit bigger now, and the number of COS-applications have been increased, but to limit the number of packages it's a good choice. After all, CORBA & SNMP often co-exists to be able to support different/preferd OAM API's used by the customers. The bottom line is how many packages there should be. /Nick > I don't doubt that the telecom sector produce a lot of paperwork > within OMG :-) > (After working with implementations of telecom protocols for the last > 16 years I haven't seen a core telecom system using corba for external > > communication. I have seen one using it for internal comms and that > was probably not the wisest move...) > > Anyway, the point was that is a VERY large chunk of the OTP > distribution and I have never used it. > > /Per > > > > > Hello! > > > > Besides the fact that Telecom is one most productive domains within > OMG, > > CORBA is widely used within telecom (Ericsson, Lucent, Siemens, > Nokia, > > Motorola, Nortel etc etc). On the other hand, should one, for > example, > > consider SNMP to be a "pure" telecom protocol? IMHO, the answer is > no in > > both cases. I assume that's the reason why the package was named > > "Telecom/protocols" instead of "Telecom protocols" ;-) > > > > /Nick > > > > > > > Hi, > > > > > > > > > - Telecom/protocols (snmp, asn1, orber, megaco, ... > > > > Being a true telecom nerd I never understood what corba had > > > > to do with proper telecom protocols... :-) > > > > If you're going to do separate packages please send all the Corba > > > > stuff to its own peaceful heaven ... > > > > > > > > /Per > > > > > > > > > > > > > > > ========================================================= > Per Bergqvist > Synapse Systems AB > Phone: +46 709 686 685 > Email: per@REDACTED From francesco@REDACTED Tue Jan 28 15:27:08 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 28 Jan 2003 14:27:08 +0000 Subject: A Joeish Erlang distribution (long) References: Message-ID: <3E36933C.9090903@erlang-consulting.com> > I totally disagree - The OTP libraries "jump start" you into a way > of programming fault tolerant apps. > > If you haven't thought long and deeply about how to program FT apps > then by all means use the generics (that's what they are there for) - > If you are in a BIG project use the generics (that's so you can > understand the other peoples code). > > Once you get good at this you can start "rolling you own" - > I usually re-invent gen_server for *every different complex program > I write* they are subtly different - often the resultant code is much > prettier - and *much* more inefficient I'm proud to say :-) I think we are pretty much into the same line of thought, and I don't agree that we disagree :-p. The discussion where I jumped in was on the steep learning curve of OTP. Correct me if I am wrong, but writing your own behaviors means you are using the OTP's design principles, but not the generic libraries. I think it is pretty rare for the average Joe to go as far as developing their own behaviors in their first couple of projects (even if they might soon pick up and start patching in places where OTP's functionality is not enough). The majority of the people evaluating Erlang are self learned. Prototypes are excellent excuses to learn Erlang and test suitability, but for them, going ahead and building a product without the OTP design principles will mean a lot of extra work and is not recommended. Their energy should instead be placed in the learning curve. If you put Joe, Klacke, Jocke and others with years of large scale Erlang SW development in one room, then anything goes.. But right now, I doubt that is the reality out there (Even if I am happy to say that this is changing.. Just give it a couple of years). Back to work.. Francesco -- http://www.erlang-consulting.com From etxuwig@REDACTED Tue Jan 28 15:41:42 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Tue, 28 Jan 2003 15:41:42 +0100 (MET) Subject: preservation of message order Message-ID: Erlang guarantees that the order of messages from one sender to another is preserved. Does this also mean that a {'DOWN',process,Who,Why} message, or an {'EXIT',Pid,Why} message can never reach the recipient ahead of the last message sent to same recipient? I hope so. There are probably restrictions, such as: if the message is sent using global:send(...), no such guarantee can be made, but if the message is sent using the Pid or locally registered name of the process, the guarantee should hold. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From klacke@REDACTED Tue Jan 28 16:01:40 2003 From: klacke@REDACTED (Klacke) Date: Tue, 28 Jan 2003 16:01:40 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E36933C.9090903@erlang-consulting.com>; from francesco@erlang-consulting.com on Tue, Jan 28, 2003 at 02:27:08PM +0000 References: <3E36933C.9090903@erlang-consulting.com> Message-ID: <20030128160140.A20074@bluetail.com> On Tue, Jan 28, 2003 at 02:27:08PM +0000, Francesco Cesarini wrote: > energy should instead be placed in the learning curve. If you put Joe, > Klacke, Jocke and others with years of large scale Erlang SW development > in one room, then anything goes.. But right now, I doubt that is the Interesting choice of SW developers there. As a matter of fact, if Jocke, Joe and I were to write something BIG together, we probably wouldn't use the the "OTP design principles" or whatever they are called. Not me anyway, I don't like them (because I don't understand them) /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From Marc.Vanwoerkom@REDACTED Tue Jan 28 17:45:21 2003 From: Marc.Vanwoerkom@REDACTED (Marc Ernst Eddy van Woerkom) Date: Tue, 28 Jan 2003 17:45:21 +0100 (MET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E3551D0.5000502@bluetail.com> (jocke@bluetail.com) Message-ID: <200301281645.h0SGjLt08226@bonsai.fernuni-hagen.de> > Erlang is so much better suited for the server side. Lets forget building > product quality GUIs in Erlang. You can't be everywhere. :-) I still dream of it. :) By the way, I have Chris Okasaki's "Purely Functional Data Structures" on my desk here, which is very interesting. Is there something like a work on "Functional Computer Graphics"? Regards, Marc From Marc.Vanwoerkom@REDACTED Tue Jan 28 17:58:46 2003 From: Marc.Vanwoerkom@REDACTED (Marc Ernst Eddy van Woerkom) Date: Tue, 28 Jan 2003 17:58:46 +0100 (MET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E3570EF.605@bluetail.com> (jocke@bluetail.com) Message-ID: <200301281658.h0SGwke10551@bonsai.fernuni-hagen.de> > The same is true far Java as well I suppose. Nah, one can create some damn fine GUIs with Java and Web Start allows the uncomplicated deployment of these apps from a web server to a user's box. In that aspect Java is better than its reputation, it really improved the last years. Of course it helped that GHz boxes with 256 MB RAM and more are what you get today. Regards, Marc From jamesh@REDACTED Tue Jan 28 19:59:23 2003 From: jamesh@REDACTED (James Hague) Date: Tue, 28 Jan 2003 12:59:23 -0600 Subject: A Joeish Erlang distribution (long) Message-ID: >on my desk here, which is very interesting. >Is there something like a work on "Functional >Computer Graphics"? I haven't seen much, but here are a couple of interesting references: Geometric Modelling in a Functional Style: The Haskell School of Expression: The second of these has a chapter on "functional reactive animation," which I have to admit that I still don't understand :) From victoriak@REDACTED Tue Jan 28 21:05:37 2003 From: victoriak@REDACTED (Victoria Kulikou) Date: Tue, 28 Jan 2003 14:05:37 -0600 Subject: How to interpret module with no empty namespace in debugger? Message-ID: <000d01c2c708$a017b810$10c3cf0a@victoriaXP> I am trying to debug a module that belongs to some namespace by using debugger. But I can run neither debugger:quick nor Module-> Interpret Dialog successfully. Does debugger support namespaces? Sincerely, Victoria. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svg@REDACTED Tue Jan 28 16:49:46 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Tue, 28 Jan 2003 20:49:46 +0500 (YEKT) Subject: How to interpret module with no empty namespace in debugger? In-Reply-To: <000d01c2c708$a017b810$10c3cf0a@victoriaXP> References: <000d01c2c708$a017b810$10c3cf0a@victoriaXP> Message-ID: <20030128.204946.122616779.svg@surnet.ru> Good day, It' seems debugger knows nothing about packages. It can interpret module `foo.str' if it finds `str.beam' somewhere in the path but treats it as `str' module not `foo.str'. 145> il(). Module File str /home/svg/wrk/erlang/foo/src/foo/str.erl 146> debugger:quick(foo.str, capitalize, ["abba"]). ** Invalid beam file or no abstract code: 'foo.str' "Abba" 147> m(foo.str). Module 'foo.str' compiled: Date: January 28 2003, Time: 15.11 Compiler options: [v3, debug_info, {i,"./inc"}, {i,"."}, {outdir,"ebin/foo/"}, {cwd,"/home/svg/wrk/erlang/foo"}] Object file: /home/svg/wrk/erlang/foo/ebin/foo/str.beam Exports: capitalize/1 join/2 module_info/0 module_info/1 to_lower/1 to_upper/1 trim/2 trim/3 ok Best Regards, Vladimir Sekissov victoriak> I am trying to debug a module that belongs to some namespace by using victoriak> debugger. But I can run neither debugger:quick nor Module-> Interpret victoriak> Dialog successfully. Does debugger From per@REDACTED Wed Jan 29 00:16:44 2003 From: per@REDACTED (Per Bergqvist) Date: Wed, 29 Jan 2003 00:16:44 +0100 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) In-Reply-To: Message-ID: <200301282316.h0SNGi918268@vargen.levonline.com> Regarding parlay they have now started to publish xml/soap interfaces. xml/soap for traffical interfaces is even more bizarro. I asked a colleague the other day if he could explain one good thing with xml and the funny thing is that he was totally confused about this too. If I think xml as such is totally overrated, I believe that soap is pure stupidity. Since this xml hysteria has been bugging for quite some time now it would be interesting to hear others opinions. Am I way off here ??? (I'm sorry if this all sounds like I have pms, but I truly believe that traffical interfaces should have simple and efficient codings.) /Per From spearce@REDACTED Wed Jan 29 00:35:27 2003 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 28 Jan 2003 18:35:27 -0500 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) In-Reply-To: <200301282316.h0SNGi918268@vargen.levonline.com> References: <200301282316.h0SNGi918268@vargen.levonline.com> Message-ID: <20030128233527.GB11911@spearce.org> I too haven't been very much in favor of XML at my company, but nobody listen's to little 'ole me. XML is great for a markup when humans are the majority of the systems involved in processing / reading the format. But when its a computer system, its so much simpler (or so it seems) to use a tagged binary format. But just my opinion. Per Bergqvist wrote: > Regarding parlay they have now started to publish xml/soap interfaces. > xml/soap for traffical interfaces is even more bizarro. > > I asked a colleague the other day if he could explain one good thing > with xml and the funny thing is that he was totally confused about > this too. > > If I think xml as such is totally overrated, I believe that soap is > pure stupidity. Since this xml hysteria has been bugging for quite > some time now it would be interesting to hear others opinions. > > Am I way off here ??? > (I'm sorry if this all sounds like I have pms, but I truly believe > that traffical interfaces should have simple and efficient codings.) -- Shawn. From hal@REDACTED Wed Jan 29 00:41:20 2003 From: hal@REDACTED (Hal Snyder) Date: Tue, 28 Jan 2003 17:41:20 -0600 Subject: Other things I don't get In-Reply-To: <200301282316.h0SNGi918268@vargen.levonline.com> (Per Bergqvist's message of "Wed, 29 Jan 2003 00:16:44 +0100") References: <200301282316.h0SNGi918268@vargen.levonline.com> Message-ID: <871y2wq1un.fsf@ghidra.vail> Per Bergqvist writes: > Regarding parlay they have now started to publish xml/soap interfaces. > xml/soap for traffical interfaces is even more bizarro. > > I asked a colleague the other day if he could explain one good thing > with xml and the funny thing is that he was totally confused about > this too. > > If I think xml as such is totally overrated, I believe that soap is > pure stupidity. Since this xml hysteria has been bugging for quite > some time now it would be interesting to hear others opinions. > > Am I way off here ??? Maybe, but you're not alone. One of my favorite XML debunking rants came from Marcus Ranum on the loganalysis list: http://lists.jammed.com/loganalysis/2002/06/0027.html From roger@REDACTED Wed Jan 29 00:59:09 2003 From: roger@REDACTED (Roger) Date: Tue, 28 Jan 2003 15:59:09 -0800 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) Message-ID: <200301282359.PAA02631@amber.he.net> I'm not alone, I'm not alone :-) No I think you're right on the money. As part of a large company I've been evaluating companies for their IP (intellectual property) as well as their technology. Whenever we would get in the room with a bunch of XML zealots I would ask them what problem XML solves. You'd be amazed at the answers. I'll give you some: - XML is human readable I'll send you a couple of EDI XML documents (or Hipaa) and you may read them. They're about a MB in size, and trust me, even though they have tags, no human should or could read them - XML garantuees interoperability Not true, as the semantic meaning of any of the fields is totally unspecified. If I send you an order with a delivery date, no one specifies what that order date is (date of actual delivery, latest day that this will be delivered by, best guess delvery etc. etc.) - Half of the XML people don't even know why a dtd or xsd is kinda handy to go with the XML doc :-) There's lots more, but the bottom line on XML is IMNSHO that it is a message syntax with good programming language support for parsing (i.e. java classes) It could have been comma separated files, but by pure chance that didn't happen.. -Roger > Regarding parlay they have now started to publish xml/soap interfaces. > xml/soap for traffical interfaces is even more bizarro. > > I asked a colleague the other day if he could explain one good thing > with xml and the funny thing is that he was totally confused about > this too. > > If I think xml as such is totally overrated, I believe that soap is > pure stupidity. Since this xml hysteria has been bugging for quite > some time now it would be interesting to hear others opinions. > > Am I way off here ??? > (I'm sorry if this all sounds like I have pms, but I truly believe > that traffical interfaces should have simple and efficient codings.) > > /Per > > > From robert.virding@REDACTED Wed Jan 29 01:25:34 2003 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 29 Jan 2003 01:25:34 +0100 Subject: A Joeish Erlang distribution (long) References: Message-ID: <3E371F7E.9090303@telia.com> Yes Joe I completley agree! This is a change I have been pushing for years. The core should be small, correct and not contain gen_* etc. Put these in a separate package which people can include when needed. They should also be rewritten only to use the stuff in the core. It is very important to get proper layering so as not to have the all-or-nothing situation of today. especially when it is not needed. I think the lower layers should be something like: Layer 0 - the emulator and BIF modules (BIFs are part of the language when you think about it) Layer 1 - small basic kernel + stdlib Layer 2 - this would contain other orthogonal groups which only use layer 0+1, e.g. - compiler - gen_* supervisor etc Layer 3 - applications built on layer 0+1+2 etc. I use groups here instead of calling them applications or packages so as not to clash with the existing ue of the words. It is very important that different groups in a layer only depend on lower layers and not on other groups within the same layer. Strict layering like this would make it easier to build streamlined applications as dependencies would be easy to trace. Now it is a mess, look at all the modules loaded just to get a prompt. Joe found he needed something like 30 modules just to run the compiler. Note that this in no way stops Richard Carlssons packages, the groups above could be packages. Robert ----- Original Message ----- From: "Joe Armstrong" > On Mon, 27 Jan 2003, Vance Shipley wrote: > > > On Mon, Jan 27, 2003 at 05:32:33PM +0100, Kenneth Lundin wrote: > > } > > } Here are some comments from the Erlang/OTP Product Manager at Ericsson. > > } > > } 1) We have plans to divide the Erlang/OTP distribution into s number of > > } separate packages. Preliminary we are thinking of 3 packages: > > } - Core package (erts,kernel,stdlib,sasl,mnesia,os_mon,inets,compiler,..) > > } - Tools&Utilities (parse_tools, tools, debugger, observer, et, tv, ... > > } - Telecom/protocols (snmp, asn1, orber, megaco, ... > > > > I would suggest that the core package be even more limited. All you really > > need to run Erlang is erts, kernel and stdlib. A "Development" package > > would be appropriate. If you think in terms of embedded systems and what > > they require it makes a cleaner seperation. > > I entirely agree - snmp mensia etc are *applications that are > written in Erlang - they should not therefore be in the core release. > > The core should be: > > 1) The compiler > 2) The run time > 3) A minimal set of libraries to do something "useful" > > Think C - a minimal set of stuff is > > - A compiler that runs "out of the box" > - A minimal set of libraries (libc) so you can do something. > > IMHO we should have: > > - A compiler that runs "out of the box" > - Minimal library support > Somewhere you have to "draw the line" > > My "minimal support" really means device drivers - so support > for files, sockets, binary filers, ... etc. is in - everything else is out. > also ets is so low level that it can be considered "part of the language" > > We have to be pragmatic as well so I'd include > > - dets > - dynamic code loading > - the shell > > As well in the core. > > (But no snmp, mnesia, .... asn1 etc.) these are *applications* written in > Erlang - and no gen_server ... etc.) > > IMHO gen_tcp etc. dets should be written so they don't use > gen_severer etc. - BTW my stand-alone Erlang broke just when I wanted > to use dets and gen_tcp - the reason was the dets and gen_tcp uses all > the application stuff and the gen_* stuff. > > One of the basic design principles underlying the system is (as > Martin Bj?rkland said) > > "There is stuff that has to be right, and stuff that doesn't - you > have to make you mind up." > > IMHO the core should NOT be able to recover from errors - you get the core > right - period. > > Applications outside the core can if they wish build upon gen_* > modules to make the apps. fault-tolerant - but the core should be > A. Priori assumed correct - and have no such code. > > This is *why* the core should be as small as possible and include as > much pure code as possible (i.e code like in lists etc.) > > I think the discussion should proceed upon a module per. module basis. > > We should not be talking about which component lives in the core > (i.e. do we include snmp, corba etc.) but the discussion should be ... > > The core is compiler+stdlib+sasl+kernel with the following > changes: > > The following modules are *removed* > > supervisor_bridge.erl > sos.erl > supervisor.erl > gen_*.erl > ... etc. > > Then all the remaining modules should be re-written so that NO > references are made to the stuff that is removed. > > Finally we will be able to give an exact and final list of every > module in the core with a written argument that motivates *exactly* > why it in the core. > > When this has been done I will be happy. > > IMHO the average programmer should be able to easily remember all > the Erlang primitive and know about *all* the core modules do - Erlang > should and must be a *small* langauge - that is easy top learn - the > core libraries should have the same properties. > > I can volunteer to do this (I can't do Jocke's big project) - but > I'd need help (i.e. volunteers to *remove* non core-dependencies from > dets and gen_tcp etc.). > > All this pre-supposes that the OTP people like the idea - since I > don't want to get into the "two systems" argument. > > For those people who like the "big and everything release" we can > bundle the core with *all* the applications - if that's what turns > them on. > > I view recoding and re-organizing the core as *essential* - in so > much as this will yield a tighter and more easily maintained system. > > Actually the job is easier than you imaging - you first throw out > *everything* you cannot explicitly motivate - then run - xref - this > tells you which modules you have to re-write. The modules you have > removed you move to a set of libraries outside the core, and then > re-write them using stuff *inside* core. > > Comments? > > > > /Joe > > > > > > It would be nice if the build process asked what you wanted to build. It > > is a pain to be waiting for your shiny new emulator to arrive and see that > > it's wasting your time building Corba tools. I've adopted the procedure > > of first touching lib/cosEvent/SKIP etc. > > > > -Vance > > > > From robert.virding@REDACTED Wed Jan 29 01:31:19 2003 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 29 Jan 2003 01:31:19 +0100 Subject: A Joeish Erlang distribution (long) References: <3E3670FF.3000007@bluetail.com> Message-ID: <3E3720D7.4070709@telia.com> Torbjorn Tornkvist wrote: >> >> >> I am currently evaluating Erlang with a view to adopting it for a >> railway traffic supervision system. >> > Ahh...I remember a nice little hack I, Magnus and Robert wrote once: > We wrote a train supervision/control system for a Maerklin railway set > that we showed at a big fair here in Stockholm. Robert wrote the control > parts, dealing with sensors and switches etc, and Magnus and I wrote the > GUI which consisted of an exact drawing of the real setup, where you > could see where the different trainset were etc. Those were the days... :-) I have still got the ATC stuff somewhere as well. I remember that it was fault tolerant (of course :-) as well because Marklin digital sensors sometimes missed or gave spurious signals. If it got something it didn't understand then it would just stop the train. The core was suprising simple as well. Rogers dsiplay was much more complex. Robert From robert.virding@REDACTED Wed Jan 29 02:22:58 2003 From: robert.virding@REDACTED (Robert Virding) Date: Wed, 29 Jan 2003 02:22:58 +0100 Subject: A Joeish Erlang distribution (long) References: <3E3670FF.3000007@bluetail.com> <3E3720D7.4070709@telia.com> Message-ID: <3E372CF2.2080708@telia.com> Robert Virding wrote: > I have still got the ATC stuff somewhere as well. I remember that it was > fault tolerant (of course :-) as well because Marklin digital sensors > sometimes missed or gave spurious signals. If it got something it didn't > understand then it would just stop the train. The core was suprising > simple as well. Rogers dsiplay was much more complex. Whoops! Magnus wrote the display stuff not Roger. Sorry. Robert From vances@REDACTED Wed Jan 29 05:42:46 2003 From: vances@REDACTED (Vance Shipley) Date: Tue, 28 Jan 2003 23:42:46 -0500 Subject: Other things I don't get In-Reply-To: <20030128233527.GB11911@spearce.org> References: <200301282316.h0SNGi918268@vargen.levonline.com> <20030128233527.GB11911@spearce.org> Message-ID: <20030129044246.GM16587@frogman.motivity.ca> The World Wide Web was a huge success. The protocols used were HTTP and TCP/IP. Therefore textual protocols are better than binary and IP is better than TDM, ATM, etc. It's obvious isn't it? :) Don't get me started on SIP ... -Vance On Tue, Jan 28, 2003 at 06:35:27PM -0500, Shawn Pearce wrote: } } XML is great for a markup when humans are the majority of the systems } involved in processing / reading the format. But when its a computer } system, its so much simpler (or so it seems) to use a tagged binary } format. From ulf.wiger@REDACTED Wed Jan 29 09:21:36 2003 From: ulf.wiger@REDACTED (Wiger Ulf) Date: Wed, 29 Jan 2003 09:21:36 +0100 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) References: <200301282316.h0SNGi918268@vargen.levonline.com> Message-ID: <001701c2c76f$709f98c0$f67a40d5@telia.com> I can see one good thing about XML: - It's one syntax that everyone seems to be able to agree upon. As soon as you say the 'X' word, people stop arguing. Since it's fairly easy to map XML to Erlang tuples, you can sneak some Erlang in there under the XML cloak. It's even perfectly OK to propose XML for log files in telecom systems. We should do that in OTP as well, even though you'll only get half as much relevant data into a given wrap log. (-: Apart from that, XML doesn't solve nearly as many problems as it creates. It's a typical example of a solution that's superficially simple but leads to endless complexity when applied to a slightly bigger problem. SOAP is hideous, and so is WSDL, XMLSchema, etc. XMLQuery looks nice in the beginning, until you get to the section, page after page, of "unresolved issues", most of which originate from the fact that XML is the chosen syntax. /Uffe ----- Original Message ----- From: "Per Bergqvist" To: "Niclas Eklund" Cc: "Per Bergqvist" ; Sent: den 29 januari 2003 00:16 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) > Regarding parlay they have now started to publish xml/soap interfaces. > xml/soap for traffical interfaces is even more bizarro. > > I asked a colleague the other day if he could explain one good thing > with xml and the funny thing is that he was totally confused about > this too. > > If I think xml as such is totally overrated, I believe that soap is > pure stupidity. Since this xml hysteria has been bugging for quite > some time now it would be interesting to hear others opinions. > > Am I way off here ??? > (I'm sorry if this all sounds like I have pms, but I truly believe > that traffical interfaces should have simple and efficient codings.) > > /Per > From Niclas.Eklund@REDACTED Wed Jan 29 10:07:40 2003 From: Niclas.Eklund@REDACTED (Niclas Eklund) Date: Wed, 29 Jan 2003 10:07:40 +0100 (MET) Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) In-Reply-To: <001701c2c76f$709f98c0$f67a40d5@telia.com> Message-ID: Rather interesting benchmarks (CORBA vs JavaRMI vs XML-RPC) can be found via: http://www.xmlBlaster.org/performance.html /Nick > I can see one good thing about XML: > > - It's one syntax that everyone seems to be able to agree upon. As soon as > you say the 'X' word, people stop arguing. Since it's fairly easy to map XML > to Erlang tuples, you can sneak some Erlang in there under the XML cloak. > It's even perfectly OK to propose XML for log files in telecom systems. We > should do that in OTP as well, even though you'll only get half as much > relevant data into a given wrap log. (-: > > Apart from that, XML doesn't solve nearly as many problems as it creates. > It's a typical example of a solution that's superficially simple but leads > to endless complexity when applied to a slightly bigger problem. SOAP is > hideous, and so is WSDL, XMLSchema, etc. XMLQuery looks nice in the > beginning, until you get to the section, page after page, of "unresolved > issues", most of which originate from the fact that XML is the chosen > syntax. > > /Uffe > > ----- Original Message ----- > From: "Per Bergqvist" > To: "Niclas Eklund" > Cc: "Per Bergqvist" ; > Sent: den 29 januari 2003 00:16 > Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution > (long)) > > > > Regarding parlay they have now started to publish xml/soap interfaces. > > xml/soap for traffical interfaces is even more bizarro. > > > > I asked a colleague the other day if he could explain one good thing > > with xml and the funny thing is that he was totally confused about > > this too. > > > > If I think xml as such is totally overrated, I believe that soap is > > pure stupidity. Since this xml hysteria has been bugging for quite > > some time now it would be interesting to hear others opinions. > > > > Am I way off here ??? > > (I'm sorry if this all sounds like I have pms, but I truly believe > > that traffical interfaces should have simple and efficient codings.) > > > > /Per From francesco@REDACTED Wed Jan 29 10:50:56 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Wed, 29 Jan 2003 09:50:56 +0000 Subject: A Joeish Erlang distribution (long) References: <3E36933C.9090903@erlang-consulting.com> <20030128160140.A20074@bluetail.com> Message-ID: <3E37A400.8040809@erlang-consulting.com> > Interesting choice of SW developers there. You need many (very many) hands and feet to add up the years of Erlang experience you guys have among you, so it was not an accidental pick. The discussion was about people evaluating Erlang and using it in small to medium projects. Jocke says people get scared of the Erlang/OTP design principles. I say it is a necessary hurdle for them to see how to design and reason when building their programs, and to unleash Erlang's full potential. > As a matter of fact, if > Jocke, Joe and I were to write something BIG together, we probably > wouldn't use the the "OTP design principles" or whatever they are called. You would not divide the processes into behaviors? You would not place your behaviors in supervision trees? You would not encapsulate your supervision trees in applications? You would not glue together your applications and start them using a boot file? If you use the generic behaviors or not, that is another story The OTP design principles are something beginners *should* start doing as soon as they are confident with Erlang, as it is the natural step towards writing their own. If you prefer to avoid the systools, or implement your own application controller as the existing one lacks many features, fine. If you stay away from the release handler, you are not alone (I avoid it myself whenever possible). And if you use your own error logging mechanism, that makes two of us. But I have a hard time following how you can not build a large coherent system without using the theory behind the Erlang/OTP design principles as it is described in the documentation manuals or in the OTP course material we have been using on thousands of people for almost 8 years. I would be very careful to recommending people evaluating Erlang or building their first product to bypass the principles, as that is what makes Erlang even more powerful than what it already is. > Not me anyway, I don't like them (because I don't understand them) I am sure we can invite you when we give a course near you ;-) Cheers, Francesco -- http://www.erlang-consulting.com From Marc.Vanwoerkom@REDACTED Wed Jan 29 10:48:52 2003 From: Marc.Vanwoerkom@REDACTED (unknown) Date: Wed, 29 Jan 2003 10:48:52 +0100 (MET) Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) In-Reply-To: <200301282316.h0SNGi918268@vargen.levonline.com> (message from Per Bergqvist on Wed, 29 Jan 2003 00:16:44 +0100) Message-ID: <200301290948.h0T9mqI00325@bonsai.fernuni-hagen.de> > Regarding parlay they have now started to publish xml/soap interfaces. Yea, the pinnacle of pro SOAP argumentation was that it is especially suited to tunnel those "pesky" firewalls which hinder work done anyway. :) This led to some nice sarcastic comment by crypto expert Bruce Schneier. Another argument is that an ASCII format is easier to work with than a binary format. After writing some longish JNLP descriptors for Java Web Start and adapting/changing them a bit over time on the app server, errors started to creep in. I had to check them with a validator to ensure their correctness. It is not HTML after all, where browsers are programmed to be fault tolerant to a large degree, a working XML file must be 100% correct. This is already hard with manually maintained XML files of certain size. Maschine generated XML tends to be completely unreadable and even cranking that stuff through a beautifier is not always a help. So I tend to think that non trivial XML is an order less unreadble than a binary format, but it is still unreadable. :) > xml/soap for traffical interfaces is even more bizarro. The JXTA suite of Peer 2 Peer protocols is using XML. > I asked a colleague the other day if he could explain one good thing > with xml and the funny thing is that he was totally confused about > this too. I too think that XML is just a glorified way to store attributed trees in ASCII but.. In the Java world XML is *very* common. APIs for parsing and storing the stuff in a DOM are built in the system. Lots of data formats are XML now (I had to work with JNLP and Java Help), many frame works use it for storage. Example code to use that stuff is available. This makes it very easy for a Java programmer to work with XML data and give him the perceiption that this is a natural way to do things. If these XML techniques are more useful than an approach based on some common binary format (like CORBA IDL), I don't know. My strong feeling is that the XML approach wastes lots of clock cycles and RAM cells. But XML and related stuff like XSLT transformation are in fashion, they look good on your resume and you are unlikely to get fired for using them thus for whatever voodoo reason it gets used, and that is all that matters, I fear. And to be honest, I am not sure if alternatives are developed as well. The transformation of one kind of XML in another for example is not a bad thing (e.g. docbook/xml to Java Help XML conversion). Is there any systematic conversion for binary based formats? Regards, Marc From klacke@REDACTED Wed Jan 29 11:18:36 2003 From: klacke@REDACTED (Klacke) Date: Wed, 29 Jan 2003 11:18:36 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: <3E37A400.8040809@erlang-consulting.com>; from francesco@erlang-consulting.com on Wed, Jan 29, 2003 at 09:50:56AM +0000 References: <3E36933C.9090903@erlang-consulting.com> <20030128160140.A20074@bluetail.com> <3E37A400.8040809@erlang-consulting.com> Message-ID: <20030129111836.C27679@bluetail.com> > You would not divide the processes into behaviors? Nope > You would not place > your behaviors in supervision trees? Nope > You would not encapsulate your > supervision trees in applications? Nope > You would not glue together your > applications and start them using a boot file? Nope > If you use the generic > behaviors or not, that is another story The OTP design principles are > something beginners *should* start doing as soon as they are confident > with Erlang, as it is the natural step towards writing their own. Sorry, don't agree. > > If you prefer to avoid the systools, Yes, > or implement your own application > controller as the existing one lacks many features, fine. If you stay > away from the release handler, Absolutely. > you are not alone (I avoid it myself > whenever possible). And if you use your own error logging mechanism, > that makes two of us. But I have a hard time following how you can not > build a large coherent system without using the theory behind the > Erlang/OTP design principles as it is described in the documentation > manuals or in the OTP course material we have been using on thousands of > people for almost 8 years. I would be very careful to recommending > people evaluating Erlang or building their first product to bypass the > principles, as that is what makes Erlang even more powerful than what it > already is. > > > > Not me anyway, I don't like them (because I don't understand them) > > > I am sure we can invite you when we give a course near you ;-) :-) I'll tell you what I use. I use the gen_servers. I have never used any of the other gen_ modules (except gen_tcp of cource ... but that is an entirely different beast, then gen_ in gen_tcp only has the name in common with gen_fsm and gen_event) I actually do use applications. Not that I like them but if I want to write an erlang program that fits into the otp tree I must do that. I've never used the release handler, I barely understand the error_logger. Everytime I need to do something with the error_logger such a duplicating error_messages to go to yet another place I have to look deep and hard at the code again. I've never had a supervision tree deeper than 1. /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From joe@REDACTED Wed Jan 29 12:18:43 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 29 Jan 2003 12:18:43 +0100 (CET) Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) In-Reply-To: <200301282316.h0SNGi918268@vargen.levonline.com> Message-ID: On Wed, 29 Jan 2003, Per Bergqvist wrote: > Regarding parlay they have now started to publish xml/soap interfaces. > xml/soap for traffical interfaces is even more bizarro. > > I asked a colleague the other day if he could explain one good thing > with xml and the funny thing is that he was totally confused about > this too. > > If I think xml as such is totally overrated, I believe that soap is > pure stupidity. Since this xml hysteria has been bugging for quite > some time now it would be interesting to hear others opinions. It has *one* benefit - it's a standard for a strongly typed data schema. Amazingly (and stupidly) the majority of applications do not verify the XML against a DTD or schema but only check that the stuff is "tag balanced" - if you're going to do this there is NO benefit and you might as well have used lisp S-expressions. SOAP will however enable vast numbers of new applications (like postscript did :-) It's very good for the industry - Microsoft have re-invented the RPC - twenty years later and horrendously inefficient - but baking a SOAP app together must be orders of magnitude easier than grappling with DCOM or Corba - so we can expect a rosy future. If we wait a few years, we'll see lots of interesting problems occur with "web services" based on SOAP. In five years Microsoft will have to re-invent transactions, and in ten years time *distributed* transactions (like in Mnesia) - this will be done in the SOAP framework - and be so horrendously complicated that'll we'll remember with fondness the Halycon days of programming with Corba and DCOM ... Consultants will love this and the good 'ol heady days of full employment for programmers and thousands of man hours overruns in SW budgets will be back. > > Am I way off here ??? > (I'm sorry if this all sounds like I have pms, but I truly believe > that traffical interfaces should have simple and efficient codings.) > (pms - I didn't know - when did you have the op?) No we need even more innefficient protocols - this will sell more H/W (Ericsson out the crisis) and employ more programmers. I guess in a few years streaming media will be transmitted thus: 1 big hex fu 2 big hex ck ... If every adopted this the demand for H/W would rise - with great ensuing benefit for the western economy. What else are we going to do with the gazillions of GHz and petra-bytes/sec of bandwidth ???? /Joe PS - If you want simplicity and expressive power use my UBF format http://www.sics.se/~joe/ubf/site/home.html > > From Chandrashekhar.Mullaparthi@REDACTED Wed Jan 29 12:16:39 2003 From: Chandrashekhar.Mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Wed, 29 Jan 2003 11:16:39 -0000 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) Message-ID: I couldn't agree more. I dont why anyone would want a human-readable format for messages which are exchanged by machines. I think it(XML) was formulated by people who couldn't debug their application when implementing a protocol exchanging messages in binary format. A Tag,Length,Value form of encoding is all we need. I saw this as someone's signature... There are 10 kinds of people in this world. Those who understand binary, and those who don't. cheers Chandru -----Original Message----- From: Per Bergqvist [mailto:per@REDACTED] Sent: 28 January 2003 23:17 To: Niclas Eklund Cc: Per Bergqvist; erlang-questions@REDACTED Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) Regarding parlay they have now started to publish xml/soap interfaces. xml/soap for traffical interfaces is even more bizarro. I asked a colleague the other day if he could explain one good thing with xml and the funny thing is that he was totally confused about this too. If I think xml as such is totally overrated, I believe that soap is pure stupidity. Since this xml hysteria has been bugging for quite some time now it would be interesting to hear others opinions. Am I way off here ??? (I'm sorry if this all sounds like I have pms, but I truly believe that traffical interfaces should have simple and efficient codings.) /Per 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 Wed Jan 29 12:41:47 2003 From: joe@REDACTED (Joe Armstrong) Date: Wed, 29 Jan 2003 12:41:47 +0100 (CET) Subject: A Joeish Erlang distribution (long) In-Reply-To: <20030129111836.C27679@bluetail.com> Message-ID: The whole idea of the OTP design principles was to a make a "common way of doing things" for large programming teams (i.e. 2 or more programmers). If you have 20 programmers on the same projects is is desirable, indeed beneficial if they don't all waltz off and invent their own way of writing client-servers, loggers etc. If you have one man projects - done by the people who invented half the things in the language - this is not necessary. If you're a one man project and you start from scratch - you could: 1) - spend 20 years thinking about it 2) - start hacking immediately 3) - read the OTP documentation and use the design principles Id recommend 2) followed by 3) then 1) - after about 5-10 years you should be able to "roll your own", I've had some 25 odd years of serious "warming up" and I still don't know how to write beautiful code :-) << Sometimes I think it's time to write "Programming made difficult in 25 years" Me, I hate all the "Learn SQL in 20 minutes" type books - something that takes 20 minutes to learn can't be worth learning. Programming is *difficult* and takes a long time to get right. Simple and transparently correct algorithms are difficult to write - making them correct is the difficult bit - indeed vast teams of mathematicians could spend decades trying to prove the simplest program I write correct. >> /Joe From msanjay@REDACTED Wed Jan 29 13:05:40 2003 From: msanjay@REDACTED (Sanjay Mehta) Date: Wed, 29 Jan 2003 17:35:40 +0530 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution(long)) References: Message-ID: <3E37C394.DB33C472@lucent.com> Joe Armstrong wrote: > If every adopted this the demand for H/W would rise - with great > ensuing benefit for the western economy. But that's exactly what M and I are doing right now ... M writes slower and fatter s/w so that I can sell faster h/w. 15 years ago a PC used to take around 2 minutes to boot DOS off a floppy. Today it takes 2 minutes to boot Windoze off a 7200 RPM hd. My good old ZX81 used to have BASIC in ROM and "booted" in a couple of seconds. From Marc.Vanwoerkom@REDACTED Wed Jan 29 13:05:40 2003 From: Marc.Vanwoerkom@REDACTED (Marc Ernst Eddy van Woerkom) Date: Wed, 29 Jan 2003 13:05:40 +0100 (MET) Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) In-Reply-To: (message from Joe Armstrong on Wed, 29 Jan 2003 12:18:43 +0100 (CET)) Message-ID: <200301291205.h0TC5e023132@bonsai.fernuni-hagen.de> > I guess in a few years streaming media will be transmitted thus: > > > > > > > 1 At first I laughed out .. :-) .. but on the second thought you might be very right with that prognosis, and in that case it less funny. Regards, Marc From david.wallin@REDACTED Wed Jan 29 13:17:56 2003 From: david.wallin@REDACTED (david wallin) Date: Wed, 29 Jan 2003 12:17:56 +0000 Subject: A Joeish Erlang distribution (long) In-Reply-To: <200301281645.h0SGjLt08226@bonsai.fernuni-hagen.de> References: <200301281645.h0SGjLt08226@bonsai.fernuni-hagen.de> Message-ID: <1043842676.21936.17.camel@wintermute.csis.ul.ie> On Tue, 2003-01-28 at 16:45, Marc Ernst Eddy van Woerkom wrote: > > Erlang is so much better suited for the server side. Lets forget building > > product quality GUIs in Erlang. You can't be everywhere. :-) > > I still dream of it. :) > > By the way, I have Chris Okasaki's "Purely Functional Data Structures" > on my desk here, which is very interesting. > Is there something like a work on "Functional Computer Graphics"? > > > Regards, > Marc Well, there is something called "Functional PostScript" which might be what you're looking for. (An implementation of PS operators in Scheme AFAICT.) http://www.scsh.net/resources/fps.html cheers, --david. -- david wallin From garry@REDACTED Wed Jan 29 15:24:25 2003 From: garry@REDACTED (Garrett G. Hodgson) Date: Wed, 29 Jan 2003 09:24:25 -0500 Subject: Other things I don't get In-Reply-To: Message from Vance Shipley of "Tue, 28 Jan 2003 23:42:46 EST." <20030129044246.GM16587@frogman.motivity.ca> Message-ID: <200301291424.h0TEOPD26684@kestrel.sage.att.com> > > The World Wide Web was a huge success. The protocols used were HTTP and > TCP/IP. Therefore textual protocols are better than binary and IP is > better than TDM, ATM, etc. It's obvious isn't it? :) it also uses html. so everything must angle brackets. -- Garry Hodgson Let my inspiration flow Senior Hacker in token rhyme suggesting rhythm Software Innovation Services that will not forsake me AT&T Labs 'til my tale is told and done. garry@REDACTED From mikael.karlsson@REDACTED Wed Jan 29 15:29:57 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Wed, 29 Jan 2003 15:29:57 +0100 Subject: XSLT like transforms in Erlang using xmerl Message-ID: <200301291529.57493.mikael.karlsson@creado.com> Hi, I posted something similar earlier, 3 months ago, but I'll do it again, since I would like to make a humble request to add a couple of functions to the xmerl application. I implemented a small set of functions that makes it possible to write XSLT like transforms in Erlang. They actually uses xmerl and just adds "syntactic sugar" to make the Erlang "stylesheets" look more like XSLT stylesheets. They are not many, but seem to be enough for most simple transforms, more complex things can be done better in straight Erlang I think.They are too few to make an own contribution, but they would fit nicely in xmerl. Are there any others that feel that such functions would add value to xmerl, or maybe you would like to see more/other XSLT type of functions (or other implementations of the ones I made). I have been able to use this in yaws scripts and perform transformations of xml to html "on the fly". Check the little Yaws server at: http://213.64.169.87:8001/ to see what you can do and for comparing examples between XSLT and Erlang stylesheets. (And to see "on the fly" transformations live :-) NOTE, my IP is dynamically set by dhcp from my ISP so I can not promise it will last so many days. But it will hopefully last long enough, so you can have a chance to respond. Thanks Mikael -------------------- The functions ------------------------------------------ %%% File : xserl.erl %%% Author : Mikael Karlsson %%% Description : XSLT lookalike transformation in Erlang %%% %%% -module(xserl). -vsn('0.1'). -date('02-10-18'). -author('mikael.karlsson@REDACTED'). -export([xslapply/2, value_of/1, select/2, built_in_rules/2 ]). -export([mapxml/2, foldxml/3, mapfoldxml/3]). -include("xmerl.hrl"). %% Wrapper to make things look similar to xsl:apply-templates xslapply(Fun, EList) when list(EList) -> lists:map( Fun, EList); xslapply(Fun, E = #xmlElement{})-> lists:map( Fun, E#xmlElement.content). %% value_of concatenates all text nodes within the tree value_of(E)-> lists:reverse(foldxml(fun value_of1/2, [], E)). value_of1(#xmlText{}=T1, Accu)-> [T1#xmlText.value|Accu]; value_of1(E, Accu) -> Accu. %% xmerl_xpath does the job. select(Str,E)-> xmerl_xpath:string(Str,E). %% The default fallback behaviour, template funs should %% end with: %% template(E)->built_in_rules(fun template/1, E). built_in_rules(Fun, E = #xmlElement{})-> lists:map(Fun, E#xmlElement.content); built_in_rules(Fun, E = #xmlText{}) -> E#xmlText.value; built_in_rules(Fun, E = #xmlAttribute{}) -> E#xmlAttribute.value; built_in_rules(Fun, E) ->[]. %%% -------------------- Utilities ------------------------- %%% funs working on the xmerl tree %%% %% mapxml %% Fun is fun(Old#xmlElement) -> New#xmlElement mapxml(Fun, #xmlElement{}= E) -> C1 = Fun(E), C2 = mapxml(Fun,lists:flatten(C1#xmlElement.content)), C1#xmlElement{content=C2}; mapxml(Fun, List) when list(List) -> AFun = fun(E) -> mapxml(Fun, E) end, lists:map(AFun, List); mapxml(Fun, E) -> Fun(E). %% foldxml %% Fun is fun(#xmlElement, OldAccu) -> NewAccu foldxml(Fun, Accu0, #xmlElement{content=C}=E) -> Accu1 = Fun(E, Accu0), foldxml(Fun, Accu1, C); foldxml(Fun, Accu, List) when list(List) -> AFun = fun(E,A) -> foldxml(Fun, A, E) end, lists:foldl(AFun, Accu, List); foldxml(Fun, Accu, E) -> Fun(E, Accu). %% mapfoldxml %% Fun is fun(Old#xmlElement, OldAccu) -> {New#xmlElement, NewAccu} mapfoldxml(Fun, Accu0, #xmlElement{}=E) -> {C1,Accu1} = Fun(E, Accu0), {C2,Accu2} = mapfoldxml(Fun, Accu1, lists:flatten(C1#xmlElement.content)), {C1#xmlElement{content=C2},Accu2}; mapfoldxml(Fun, Accu, List) when list(List) -> AFun = fun(E,A) -> mapfoldxml(Fun, A, E) end, lists:mapfoldl(AFun, Accu, List); mapfoldxml(Fun, Accu, E) -> Fun(E,Accu). From bjarne.dacker@REDACTED Wed Jan 29 16:01:25 2003 From: bjarne.dacker@REDACTED (=?iso-8859-1?Q?Bjarne_Olov_D=E4cker?=) Date: Wed, 29 Jan 2003 16:01:25 +0100 Subject: Other things I don't get References: <200301291424.h0TEOPD26684@kestrel.sage.att.com> Message-ID: <001701c2c7a7$4bebb6c0$fe0469d4@segeltorp> Hi > Therefore textual protocols are better than binary The world at large is at last discovering S expressions. Think if we all used Lisp machines how much faster processing would be. Bjarne From richardc@REDACTED Wed Jan 29 16:30:05 2003 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 29 Jan 2003 16:30:05 +0100 (MET) Subject: preservation of message order In-Reply-To: Message-ID: On Tue, 28 Jan 2003, Ulf Wiger wrote: > Erlang guarantees that the order of messages from one sender > to another is preserved. > > Does this also mean that a {'DOWN',process,Who,Why} message, > or an {'EXIT',Pid,Why} message can never reach the recipient > ahead of the last message sent to same recipient? I hope so. All signals have this ordering guarantee. Messages are just a subset of "signals", and so are Exit signals. (There are other, more obscure signals also, e.g. link requests, which the user never sees directly.) So if the originating process is the same, the ordering is guaranteed regardless of the type of signal. (All of this according to the Erlang reference manual by Barklund/Virding.) > There are probably restrictions, such as: if the message > is sent using global:send(...), no such guarantee can be > made, but if the message is sent using the Pid or > locally registered name of the process, the guarantee should > hold. In fact, even if you use global:send/2, the message is still dispatched directly by the calling process (after doing a lookup) so it should not lose the ordering guarantee. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ From etxuwig@REDACTED Wed Jan 29 16:43:25 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 29 Jan 2003 16:43:25 +0100 (MET) Subject: preservation of message order In-Reply-To: Message-ID: On Wed, 29 Jan 2003, Richard Carlsson wrote: > >On Tue, 28 Jan 2003, Ulf Wiger wrote: > >> Erlang guarantees that the order of messages from one sender >> to another is preserved. >> >> Does this also mean that a {'DOWN',process,Who,Why} message, >> or an {'EXIT',Pid,Why} message can never reach the recipient >> ahead of the last message sent to same recipient? I hope so. > >All signals have this ordering guarantee. Messages are just >a subset of "signals", and so are Exit signals. (There are >other, more obscure signals also, e.g. link requests, which >the user never sees directly.) So if the originating >process is the same, the ordering is guaranteed regardless >of the type of signal. (All of this according to the Erlang >reference manual by Barklund/Virding.) Of course. Thank you. I have the specification in my bookshelf (doesn't everyone?), but it didn't occur to me to look there. (: >> There are probably restrictions, such as: if the message >> is sent using global:send(...), no such guarantee can be >> made, but if the message is sent using the Pid or >> locally registered name of the process, the guarantee should >> hold. > >In fact, even if you use global:send/2, the message is >still dispatched directly by the calling process (after >doing a lookup) so it should not lose the ordering >guarantee. Right again. I was thinking about the global:safe_whereis_name/1 semantics, but I see now that this is not even a documented function. Still, since the 'global' reference manual doesn't specify what exactly goes on in global:send/2, I wouldn't presume that it guarantees ordering (even if the current _implementation_ does.) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From richardc@REDACTED Wed Jan 29 16:54:40 2003 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 29 Jan 2003 16:54:40 +0100 (MET) Subject: preservation of message order In-Reply-To: Message-ID: On Wed, 29 Jan 2003, Ulf Wiger wrote: > ... Still, since the > 'global' reference manual doesn't specify what exactly goes > on in global:send/2, I wouldn't presume that it guarantees > ordering (even if the current _implementation_ does.) Let me put it this way: I can't think of a good reason why global:send/2 should ever need to first pass the message to another process, instead of just performing a lookup followed by a send (note that the lookup can be arbitrarily complicated and involve any number of messages) - especially since it would lose the nice ordering property and possibly break some existing applications. So I think that it should be safe to actually put this guarantee in the documentation for global. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ From etxuwig@REDACTED Wed Jan 29 16:57:03 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Wed, 29 Jan 2003 16:57:03 +0100 (MET) Subject: preservation of message order In-Reply-To: Message-ID: On Wed, 29 Jan 2003, Richard Carlsson wrote: >Let me put it this way: I can't think of a good reason why >global:send/2 should ever need to first pass the message to >another process, instead of just performing a lookup >followed by a send (note that the lookup can be arbitrarily >complicated and involve any number of messages) - >especially since it would lose the nice ordering property >and possibly break some existing applications. So I think >that it should be safe to actually put this guarantee in >the documentation for global. I agree, but then it should also be safe to amend the documentation to state what guarantees are actually made. (; /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From spearce@REDACTED Wed Jan 29 18:12:29 2003 From: spearce@REDACTED (Shawn Pearce) Date: Wed, 29 Jan 2003 12:12:29 -0500 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) In-Reply-To: References: Message-ID: <20030129171229.GA14394@spearce.org> I'm debating this with a coworker, and his attitude was that it is easier to maintain an XML protocol's source code than it is to maintain a binary protocol's source code, thus making the product cheaper to produce (and thus higher profits). Therefore, from a business perspective any XML protocol is the best protocol currently available, as it is easier to maintain backwards/fowards compatibility as necessary to not piss off customers. I think he's full of it. If you have a nice tagged format, and within that tagged format a way to expose structure (if structure is necessary for you to do, like list enumeration, etc) then you can still be as compatible, and most likely actually make the software cheaper to develop as you don't have to bend your application to the weird rules of XML. We're struggling at work to deal with escaping quotes in XML attributes and embedding binary image data in an XML document. *sigh* I'll put good money on the table that our currently binary data file format we have used for the past 10 years will be rewritten soon in XML. 5 GB of binary data in a highly compressed file will explode. "But its ok, most customers have 36 GB drives today." :) *puke* Our current XML transfer formats are already unreadable or uneditable by a human once they get beyond 1KB in size. We don't use LFs inside of the XML tags, so no editor will read it beyond a certain size (and most of our docs are over that size). Things over 1 KB are too complex to read in a text editor, so we use XML Spy. We might as well just use a simple binary editor written in house. Would actually work better. Oh wait, we did that for the XML, and our own developers hate it. :) XML has too few advantages to be used, but yet its everywhere, which is its biggest advantage. Chandrashekhar Mullaparthi wrote: > I couldn't agree more. I dont why anyone would want a human-readable format > for messages which are exchanged by machines. I think it(XML) was formulated > by people who couldn't debug their application when implementing a protocol > exchanging messages in binary format. A Tag,Length,Value form of encoding is > all we need. > > I saw this as someone's signature... > > There are 10 kinds of people in this world. Those who understand binary, and > those who don't. > > cheers > Chandru > > -----Original Message----- > From: Per Bergqvist [mailto:per@REDACTED] > Sent: 28 January 2003 23:17 > To: Niclas Eklund > Cc: Per Bergqvist; erlang-questions@REDACTED > Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution > (long)) > > > Regarding parlay they have now started to publish xml/soap interfaces. > xml/soap for traffical interfaces is even more bizarro. > > I asked a colleague the other day if he could explain one good thing > with xml and the funny thing is that he was totally confused about > this too. > > If I think xml as such is totally overrated, I believe that soap is > pure stupidity. Since this xml hysteria has been bugging for quite > some time now it would be interesting to hear others opinions. > > Am I way off here ??? > (I'm sorry if this all sounds like I have pms, but I truly believe > that traffical interfaces should have simple and efficient codings.) > > /Per > > > > > 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. > -- Shawn. From lps@REDACTED Wed Jan 29 20:21:33 2003 From: lps@REDACTED (Leon Smith) Date: Wed, 29 Jan 2003 14:21:33 -0500 Subject: On Erlang distributions Message-ID: <200301291921.OAA05101@pom.INS.cwru.edu> I don't like the idea of fragmenting Erlang into multiple distributions, unless we are going to have another implementation of Erlang. However, making a more modular distribution is in order. Personally, I strongly dislike "make". Makefiles are large, ugly, and usually ad-hoc. Different people use drastically different conventions. For example, with the Erlang distribution, you can't cd into a given directory that you've made some changes to and type "make" and "make install" to update that directory alone. Many other packages support this. SRC Modula-3 had 'quake', a simple language that was Modula-3's integrated build system. It was far more intelligent than "make" about recompiling and relinking only when necessary. Dependencies were automatically gathered from source files and accounted for in the build process. All you had to do in the makefile was point the build system at the files you were interested in, though you weren't limited to this. Nearly every aspect of compilation was controllable within quake. Once the Modula-3 source was downloaded, it was really quite simple to compile/not compile any number of the extensive libraries and (large) example application programs that came with the distribution, by simply commenting/uncommenting a single line in the main m3makefile. So, here is my idea: strip down Erlang/OTP to the bare essentials. Create a simple, intelligent, distributed builld system, perhaps in the spirit of Modula-3's quake. Then, have all the non-core libraries and applications relegated to separate packages. Allow packages to be installed or updated with one or two simple Erlang commands. I don't think that basing this system around RPM or Debian Packages is really worth the time and effort, nor do I think these standards would give an erlang build system any significant benefit. In the short run, this is a fair bit of work. In the long run, this would be a lot less work than trying to create a separate distribution every time Ericcson releases another version. It would be easy to create your very own personal distribution by simply creating/editing a erlmakefile to suit your needs. Maybe downloading stuff from the internet yourself and unzipping it and building doesn't give most people much difficultly, but hey, programmers are supposed to be lazy. I'd much rather just type "erlbuild" some directory to update what I want, or type a single short command into eshell to download and compile a package I need. Plus, this would give people a better, standard, cross-platform build system for their own Erlang apps. And much of the erlang distribution is (quite rightly) based around standard ways of accomplishing such common tasks. best, leon From vlad_dumitrescu@REDACTED Wed Jan 29 20:40:43 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 29 Jan 2003 20:40:43 +0100 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) References: <20030129171229.GA14394@spearce.org> Message-ID: ----- Original Message ----- From: "Shawn Pearce" > XML has too few advantages to be used, but yet its everywhere, which > is its biggest advantage. Having also struggled with XML, but in it's proper environment, I have to say that there it does it's job well. The proper environment is text processing. The predecessor SGML has been used for more than 20 years with success, and I think that the heavy users won't switch to XML. It really isn't XML's fault that it has been abused to the extent it became just as bad as the things it was supposed to replace. But it isn't our fault either to have to fight with it... Oh, well, life isn't fair! regards, Vlad From spearce@REDACTED Wed Jan 29 20:59:25 2003 From: spearce@REDACTED (Shawn Pearce) Date: Wed, 29 Jan 2003 14:59:25 -0500 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) In-Reply-To: References: <20030129171229.GA14394@spearce.org> Message-ID: <20030129195925.GB14394@spearce.org> Vlad Dumitrescu wrote: > Having also struggled with XML, but in it's proper environment, I have to > say that there it does it's job well. The proper environment is text > processing. The predecessor SGML has been used for more than 20 years with > success, and I think that the heavy users won't switch to XML. Yes. SGML is great for text, and for those who thought HTML was good for text, XML is better than HTML, but I doubt SGML will be replaced. I'd guess most SGML installs stick with SGML. XML's biggest win for me has always been in marking up text as XML and turning it into HTML or other XML document formats for other document tools to read. But XML as a configuration file format or an application control file, or a log file, its never been helpful. Perhaps the only use I've seen is that if a file is stored in a structured format, and is mostly text data, XML helps in that although the grammer is unknown, you can at least find a tool that will tokenize the file for you. I've got a commerical software tool here that we bought which outputs data in XML. If it had been a binary file, I would have been up a creek trying to tokenize the file into something meaningful without docs. With XML, at least I can grab an XML parser and tokenize it. > It really isn't XML's fault that it has been abused to the extent it became > just as bad as the things it was supposed to replace. But it isn't our fault > either to have to fight with it... Oh, well, life isn't fair! That's the fault of Dave Winer. He started SOAP by finding out XML and HTTP were just made for each other somehow. :) -- Shawn. From klacke@REDACTED Wed Jan 29 22:11:56 2003 From: klacke@REDACTED (Klacke) Date: Wed, 29 Jan 2003 22:11:56 +0100 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) In-Reply-To: ; from vlad_dumitrescu@hotmail.com on Wed, Jan 29, 2003 at 08:40:43PM +0100 References: <20030129171229.GA14394@spearce.org> Message-ID: <20030129221156.B19317@bluetail.com> On Wed, Jan 29, 2003 at 08:40:43PM +0100, Vlad Dumitrescu wrote: > ----- Original Message ----- > From: "Shawn Pearce" > > XML has too few advantages to be used, but yet its everywhere, which > > is its biggest advantage. > > Having also struggled with XML, but in it's proper environment, I have to > say that there it does it's job well. The proper environment is text > processing. The predecessor SGML has been used for more than 20 years with > success, and I think that the heavy users won't switch to XML. > Ho ho ho, When writing the Yaws documentation I thought -- I'll have a crack at writing all the docs in XML and use the XML toolchain to transform that documentation to man pages and pdf docs. What can I say, NOT. Maybe I'll have another look at that stuff in 3 years or so. What a pain. /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From mikael.karlsson@REDACTED Wed Jan 29 22:50:57 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Wed, 29 Jan 2003 22:50:57 +0100 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) In-Reply-To: <20030129221156.B19317@bluetail.com> References: <20030129221156.B19317@bluetail.com> Message-ID: <200301292250.57798.mikael.karlsson@creado.com> onsdag 29 januari 2003 22:11 skrev Klacke: > On Wed, Jan 29, 2003 at 08:40:43PM +0100, Vlad Dumitrescu wrote: > > ----- Original Message ----- > > From: "Shawn Pearce" > > > > > XML has too few advantages to be used, but yet its everywhere, which > > > is its biggest advantage. > > > > Having also struggled with XML, but in it's proper environment, I have to > > say that there it does it's job well. The proper environment is text > > processing. The predecessor SGML has been used for more than 20 years > > with success, and I think that the heavy users won't switch to XML. > > Ho ho ho, When writing the Yaws documentation I thought -- > I'll have a crack at writing all the docs in XML and use the XML > toolchain to transform that documentation to man pages and pdf docs. > > What can I say, NOT. > > Maybe I'll have another look at that stuff in 3 years or so. > What a pain. > > /klacke Ho ho ho ho, Yaws compiles fine for me but not the docs, beleive it or not I do not have all the TeX packages, dvips etc. installed (I wonder how the Windows folks do it?.) Now if you had written it in an xml document that could be parsed and transformed by xmerl, then Yaws could have been the engine to provide the docs on the fly, wouldn't that have been nice? All the code needed for documentation production in Erlang? Just some stylesheets for man pages and PDF missing :-). -> http://213.64.169.87:8001/ But then again I guess it is not so much pain to write the doc in TeX then in XML? NowYaws has excellent documentation, did not mean to say anything else. /Mikael From garry@REDACTED Thu Jan 30 02:31:37 2003 From: garry@REDACTED (Garrett G. Hodgson) Date: Wed, 29 Jan 2003 20:31:37 -0500 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution(long)) In-Reply-To: Message from Sanjay Mehta of "Wed, 29 Jan 2003 17:35:40 +0530." <3E37C394.DB33C472@lucent.com> Message-ID: <200301300131.h0U1VbB31947@kestrel.sage.att.com> > Joe Armstrong wrote: > > If every adopted this the demand for H/W would rise - with great > > ensuing benefit for the western economy. > > But that's exactly what M and I are doing right now ... M writes > slower and fatter s/w so that I can sell faster h/w. > > 15 years ago a PC used to take around 2 minutes to boot DOS off > a floppy. Today it takes 2 minutes to boot Windoze off a 7200 > RPM hd. My good old ZX81 used to have BASIC in ROM and "booted" in a couple > of seconds. as a friend of mine put it, "remember when computers were slow and applications were fast?". -- Garry Hodgson Let my inspiration flow Senior Hacker in token rhyme suggesting rhythm Software Innovation Services that will not forsake me AT&T Labs 'til my tale is told and done. garry@REDACTED From vlad_dumitrescu@REDACTED Thu Jan 30 06:18:10 2003 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 30 Jan 2003 06:18:10 +0100 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) References: <20030129171229.GA14394@spearce.org> <20030129221156.B19317@bluetail.com> Message-ID: ----- Original Message ----- From: "Klacke" > Ho ho ho, When writing the Yaws documentation I thought -- > I'll have a crack at writing all the docs in XML and use the XML > toolchain to transform that documentation to man pages and pdf docs. Ah well, I suppose you mean you tried to write it by hand? Then I fully agree it's tedious. But really heavy users have tools like "PageMaker+SGML" where you don't even see the SGML or XML. We mere mortals can't afford those :-) /Vlad From valentin@REDACTED Thu Jan 30 08:27:20 2003 From: valentin@REDACTED (Valentin) Date: Thu, 30 Jan 2003 09:27:20 +0200 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distribution (long)) References: <200301282316.h0SNGi918268@vargen.levonline.com> Message-ID: <004a01c2c831$0ba39da0$70ec1ec4@moneymaker> Dear friends, > If I think xml as such is totally overrated, I believe that soap is > pure stupidity. Since this xml hysteria has been bugging for quite > some time now it would be interesting to hear others opinions. > IMHO, XML is not that bad, however, it seems to me that no matter how good an idea, industry will find the way to corrupt it. Sure, you can use it XML as a marshalling mechanism (i.e. xmlrpc & SOAP) for some kind of remote procedure/function/method invocation, but if we did not learn by now that such an effort becomes its own purpose, and usually miss the point completely... well, we never will. > > I asked a colleague the other day if he could explain one good thing > with xml and the funny thing is that he was totally confused about > this too. > Unlike ASN.1/BER (or, God forbid CORBA/COM/ similar), where both parties must know everything about each other before starting to exchange data, what I like about XML is that does not need to be the case. For example, although you could decode with ease a BER pdu, you will never be sure what the data is all about without a relevant ASN.1 specification. On the other hand, one can extract and use a fragment of "well formed" XML document, and, even better, "inject" the things dynamically without compromising the structure. A very interesting service provisioning/management system(s) can be implemented/integrated in that way. Or think of a root-cause analysis system -- a whole history and/or reasoning can be encoded and specified in a single PDU. A very flexible first normal form. Ability to specify and encode at the same time I found a pretty useful concept. Of course, there is Xerces...Damn, could anybody tell these people that there is no Noble Prize for programming. So why try so hard? V. From svg@REDACTED Thu Jan 30 03:13:24 2003 From: svg@REDACTED (Vladimir Sekissov) Date: Thu, 30 Jan 2003 07:13:24 +0500 (YEKT) Subject: XSLT like transforms in Erlang using xmerl In-Reply-To: <200301291529.57493.mikael.karlsson@creado.com> References: <200301291529.57493.mikael.karlsson@creado.com> Message-ID: <20030130.071324.28787110.svg@surnet.ru> Good day, Yaws has simple and excellent idea of EHTML. Here are my two cents. XSLT like transforms in Erlang without xmerl. Example in source (exmlt:test/0) transforms {user, [], [{first_name, [], "Tom"}, {last_name, [], "Jones"} ]} to {form,[{action,"adduser"}], [{table,[], [{tr,[{class,"rowset0"}], [{td,[],"first_name"}, {td,[],[{input,[{name,"first_name"},{value,"Tom"}]}]}]}, {tr,[{class,"rowset1"}], [{td,[],"last_name"}, {td,[],[{input,[{name,"last_name"},{value,"Jones"}]}]}]}| {tr,[{colspan,"2"}], [{td,[],[{input,[{type,"submit"},{name,"save"}]}]}]}]}]} Best Regards, Vladimir Sekissov ------------------------------ cut here --------------------------- %%%------------------------------------------------------------------- %%% File : exmlt.erl %%% Author : %%% Description : XML like EHTML transformation %%% %%% Created : 10 Jan 2003 by %%%------------------------------------------------------------------- %% %% $Id$ %% %% $Log$ %% %%** %% %% @doc XML like EHTML transformation %% @end %%* -module(exmlt). -export([transform/3, rule_normalize/2, text/1, default/1, r/2, param_new/3, param_set/3, param_get/2, param_find/2]). -export([mapfold/3]). -export([test/0]). transform(Rs, Ps, Tree) -> Ctxt = create_context(Ps), mapfold(Rs, Ctxt, Tree). default(Rs) -> r('#default#', Rs). text(Rs) -> r('#text#', Rs). r(Name, {PreHlr, PostHlr, Rs}) -> {Name, {wrap_pre_hlr(PreHlr), wrap_post_hlr(PostHlr), Rs}}; r(Name, Hlr) when function(Hlr) -> {Name, wrap_post_hlr(wrap_pre_hlr(Hlr))}; r(Name, {Hlr, Rs}) -> r(Name, {fun dummy_rule/2, Hlr, Rs}). wrap_pre_hlr(Hlr) -> fun (Node, Ctxt) -> Hlr(Node, push_context(Ctxt)) end. wrap_post_hlr(Hlr) -> fun (Node0, Ctxt0) -> {Node1, Ctxt1} = Hlr(Node0, Ctxt0), {Node1, pop_context(Ctxt1)} end. param_new(N, V, Cs=[C|Rest]) -> [orddict:store(N, V, C)|Rest]. param_set(N, V, Cs) -> case context_map(fun (C) -> case orddict:is_key(N, C) of true -> {ok, ok, orddict:store(N, V, C)}; false -> false end end, Cs) of false -> exit({param_undef, N}); {ok, _, NCs} -> NCs end. param_find(N, Cs) -> context_map(fun (C) -> orddict:find(N, C) end, Cs). param_get(N, Cs) -> case param_find(N, Cs) of {ok, V} -> V; _ -> exit({param_undef, N}) end. push_context(Cs) -> [orddict:new()|Cs]. pop_context([_|Rest]) -> Rest. context_map(Fun, Cs) -> context_map(Fun, Cs, []). context_map(Fun, [], _) -> false; context_map(Fun, [C|Rest], A) -> case Fun(C) of Ret={ok, _} -> Ret; {ok, Res, NC} -> {ok, Res, lists:reverse(A) ++ [NC|Rest]}; _ -> context_map(Fun, Rest, [C|A]) end. %%context_merge(From, To) -> %% lists:foldl(fun ({K, V}, D) -> %% case orddict:is_key(K, D) of %% true -> %% orddict:store(K, V, D); %% false -> %% D %% end %% end, To, orddict:to_list(From)). create_context(Ps) -> [orddict:from_list(Ps)]. %% mapfold(Rs, Acc, Node={Name, Args}) -> mapfold(Rs, Acc, Node={Name, Args, []}); mapfold(Rs0, Acc0, Node0={Name0, _Args0, Cont0}) -> {PreHlr, PostHlr, ContRs} = match_rule(Name0, Rs0), {{Name1, Args1, Cont1}, Acc1} = PreHlr(Node0, Acc0), {Cont2, Acc2} = mapfold_content(ContRs, Acc1, [], Cont1), PostHlr({Name1, Args1, Cont2}, Acc2); mapfold(Rs, Acc, Tree) when list(Tree) -> mapfold_content(Rs, Acc, [], Tree). mapfold_content(_Rs, Acc, Tree, []) -> {lists:append(lists:reverse(Tree)), Acc}; mapfold_content(Rs, Acc0, Tree, TextNode=[I|_]) when not(is_tuple(I)) -> {PreHlr, PostHlr, _} = match_rule(TextNode, Rs), {Add1, Acc1} = PreHlr(TextNode, Acc0), {Add2, Acc2} = PostHlr(Add1, Acc1), {mk_list(Add2), Acc2}; mapfold_content(Rs, Acc0, Tree, [Node|Rest]) -> {Add1, Acc1} = mapfold(Rs, Acc0, Node), mapfold_content(Rs, Acc1, [mk_list(Add1)|Tree], Rest). match_rule(Node, Rs) -> Rule = match_rule(Node, Rs, nodefault), rule_normalize(Rule, Rs). match_rule(Node, [], nodefault) -> exit({no_rule, Node}); match_rule(Node, [], DefRule) -> DefRule; match_rule(Node, [{'#default#', Rule}|Rs], nodefault) -> match_rule(Node, Rs, Rule); match_rule(Name, [{Name, Rule}|_], _) when atom(Name) -> Rule; %%text node match_rule(Str, [{'#text#', Rule}|_], _) when list(Str) -> Rule; match_rule(Node, [_|Rs], DefRule) -> match_rule(Node, Rs, DefRule). rule_normalize(Hlr, Rs) when function(Hlr) -> {fun dummy_rule/2, Hlr, Rs}; rule_normalize(NRs, _) when list(NRs) -> {fun dummy_rule/2, fun dummy_rule/2, NRs}; rule_normalize({PostHlr, Rs}, _) when function(PostHlr) -> {fun dummy_rule/2, PostHlr, Rs}; rule_normalize(R={_PreHlr, _PostHlr, _NRs}, _) -> R. mk_list(L) when list(L) -> L; mk_list(V) -> [V]. dummy_rule(Node, Acc) -> {Node, Acc}. test() -> FieldRule = exmlt:default( fun ({N, Args, Content}, Params) -> Row = exmlt:param_get(rowcnt, Params), NameStr = atom_to_list(N), Out = {tr, [{class, "rowset"++integer_to_list(Row band 16#1)}], [{td, [], NameStr}, {td, [], [{input, [{name, NameStr}, {value, Content}|Args]}]} ]}, {Out, exmlt:param_set(rowcnt, Row+1, Params)}; (V, Params) -> {V, Params} end), StyleSheet = [exmlt:r(user, {fun (Node, Params) -> {Node, exmlt:param_new(rowcnt, 0, Params)} end, fun ({N, Args, Contents}, Params) -> Out = {form, [{action, exmlt:param_get(action, Params)}|Args], [{table, [], Contents ++ {tr, [{colspan, "2"}], [{td, [], [{input, [{type, "submit"}, {name, "save"}]}]} ]} }] }, {Out, Params} end, [FieldRule] }) ], TestInput = {user, [], [{first_name, [], "Tom"}, {last_name, [], "Jones"} ]}, {Result, OutParams} = exmlt:transform(StyleSheet, [{action, "adduser"}], TestInput), Result. From mikael.karlsson@REDACTED Thu Jan 30 11:41:35 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Thu, 30 Jan 2003 11:41:35 +0100 Subject: XSLT like transforms in Erlang using xmerl In-Reply-To: <20030130.071324.28787110.svg@surnet.ru> References: <200301291529.57493.mikael.karlsson@creado.com> <20030130.071324.28787110.svg@surnet.ru> Message-ID: <200301301141.35224.mikael.karlsson@creado.com> Morning, looks great, I hope this is something thats targeted for your next version of STL? I think I will need a coup of coffe or so before I dive into your code details though :-) Now this assumes that you have a source formatted in EHTML, meaning you need a parser if your source is XML or that you already are in "Yaws space" , doesn't it ? My reason to use xmerl is: 1. I can read (parse) an ordinary XML document. 2. the xpath implementation in xmerl combined with pattern matching in Erlang makes it quite easy to write "stylesheets" that look very similar to XSLT sheets. It is rather straighforward to grab an XSLT sheet and rewrite it as an Erlang sheet. The select(Str,E) function below is just a call to xmerl_xpath:string(Str,E). Xpath is a quite substantial part of XSLT. ex:

becomes: template(E = #xmlElement{name='title'}) -> ["

", value_of(select(".", E)), "

"]; and:

becomes: template(E = #xmlElement{ parents=[{'doc',_}|_], name='title'}) -> ["

", xslapply( fun template/1, E), "

"]; Easy, peasy :-) 3. You can export directly to XML (and other formats), so you do not need Yaws. This might happen. My request was if this would add value to the xmerl application, I hope it does. If Yaws and other apps would benefit as well, so much better. Thanks Mikael Thursday 30 Jan 2003 Vladimir Sekissov wrote: > Good day, > > Yaws has simple and excellent idea of EHTML. Here are my two cents. > XSLT like transforms in Erlang without xmerl. > > Example in source (exmlt:test/0) transforms > > {user, [], > [{first_name, [], "Tom"}, > {last_name, [], "Jones"} > ]} > > to > > {form,[{action,"adduser"}], > [{table,[], > [{tr,[{class,"rowset0"}], > [{td,[],"first_name"}, > > {td,[],[{input,[{name,"first_name"},{value,"Tom"}]}]}]}, > {tr,[{class,"rowset1"}], > [{td,[],"last_name"}, > > {td,[],[{input,[{name,"last_name"},{value,"Jones"}]}]}]}| > {tr,[{colspan,"2"}], > [{td,[],[{input,[{type,"submit"},{name,"save"}]}]}]}]}]} > > Best Regards, > Vladimir Sekissov > > ------------------------------ cut here --------------------------- .. From eleberg@REDACTED Thu Jan 30 12:24:45 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Thu, 30 Jan 2003 12:24:45 +0100 (MET) Subject: On Erlang distributions, bulding erlang Message-ID: <200301301124.h0UBOjH11898@cbe.ericsson.se> > From: Leon Smith > To: erlang-questions@REDACTED > Subject: On Erlang distributions > Date: Wed, 29 Jan 2003 14:21:33 -0500 > MIME-Version: 1.0 > Content-Transfer-Encoding: 8bit > > I don't like the idea of fragmenting Erlang into multiple distributions, > unless we are going to have another implementation of Erlang. However, > making a more modular distribution is in order. > > Personally, I strongly dislike "make". Makefiles are large, ugly, and > usually ad-hoc. Different people use drastically different conventions. > For example, with the Erlang distribution, you can't cd into a given > directory that you've made some changes to and type "make" and "make install" > to update that directory alone. Many other packages support this. ...deleted > So, here is my idea: strip down Erlang/OTP to the bare essentials. Create > a simple, intelligent, distributed builld system, perhaps in the spirit of > Modula-3's quake. Then, have all the non-core libraries and applications > relegated to separate packages. Allow packages to be installed or updated > with one or two simple Erlang commands. I don't think that basing this > system around RPM or Debian Packages is really worth the time and effort, nor > do I think these standards would give an erlang build system any significant > benefit. > there is a erlang ''make'' module that can be used once the compiler/runtime is ready. only c source need a c compiler and the make program (may it soon be replaced). bengt From Vlad.Dumitrescu@REDACTED Thu Jan 30 13:12:23 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Thu, 30 Jan 2003 13:12:23 +0100 Subject: XSLT like transforms in Erlang using xmerl Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F71D@esemont203.gbg.edt.ericsson.se> Hi, > From: Mikael Karlsson [mailto:mikael.karlsson@REDACTED] > 3. You can export directly to XML (and other formats), so you do not > need Yaws. This might happen. > > My request was if this would add value to the xmerl > application, I hope it > does. If Yaws and other apps would benefit as well, so much better. Well, I think it would be useful for edoc too. I have been trying to implement support for the Zope template language (which has some advantages over XSLT, as for example being simpler and one is able to edit the template as a regular XML/HTML file with demo values included) but I got stuck and then external pressure made me put it on the shelf... It's half done, but if you are done with your module it might be just as well to use it instead. regards, Vlad From matthias@REDACTED Thu Jan 30 13:20:39 2003 From: matthias@REDACTED (Matthias Lang) Date: Thu, 30 Jan 2003 13:20:39 +0100 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) In-Reply-To: References: <20030129171229.GA14394@spearce.org> <20030129221156.B19317@bluetail.com> Message-ID: <15929.6295.960740.604403@antilipe.corelatus.se> Vlad Dumitrescu writes: klacke> Ho ho ho, When writing the Yaws documentation I thought -- klacke> I'll have a crack at writing all the docs in XML and use the XML klacke> toolchain to transform that documentation to man pages and pdf docs. vlad> Ah well, I suppose you mean you tried to write it by hand? Then I fully vlad> agree it's tedious. But really heavy users have tools like vlad> "PageMaker+SGML" where you don't even see the SGML or XML. For what it's worth: I wrote the Erlang FAQ in SGML by hand, hoping to escape the fiddly problems that LaTex tends to create as soon as you want to do something a little out of the ordinary. The experience was so incredibly frustrating that I went back to the relaxing, sane world of LaTex and stayed there. The main problem was that I had to hack some pseudo-lisp programs devoid of useful comments to get basic things done, e.g. changing page layout. Problem #2 was that everything was awfully verbose. The straw that broke the camel's back was trying to get images and maths to work. Consider the latex inline math expression $ [a + b]^{260} + \{a + b\}_i $ and write the same thing in MathML a+b 260 + a+b i Doesn't seem fit for human consumption. Maybe better with good tools. Matthias ---------------------------------------------------------------------- Links: Much better docbook manual than was available in 2000: http://www.docbook.org/tdg/en/html/docbook.html Erlang FAQ SGML source (for curiosity) http://www.erlang.org/faq/faq.sgml The source for the above maths example: http://www.w3.org/Math/XSL/pmathml2.xml From mikael.karlsson@REDACTED Thu Jan 30 13:33:40 2003 From: mikael.karlsson@REDACTED (Mikael Karlsson) Date: Thu, 30 Jan 2003 13:33:40 +0100 Subject: XSLT like transforms in Erlang using xmerl In-Reply-To: <5F03ACA2F76DD411B8BC00508BE3B4D71200F71D@esemont203.gbg.edt.ericsson.se> References: <5F03ACA2F76DD411B8BC00508BE3B4D71200F71D@esemont203.gbg.edt.ericsson.se> Message-ID: <200301301333.40912.mikael.karlsson@creado.com> torsdag 30 januari 2003 13:12 skrev Vlad Dumitrescu (EAW): > Hi, > > > From: Mikael Karlsson [mailto:mikael.karlsson@REDACTED] > > 3. You can export directly to XML (and other formats), so you do not > > need Yaws. This might happen. > > > > My request was if this would add value to the xmerl > > application, I hope it > > does. If Yaws and other apps would benefit as well, so much better. > > Well, I think it would be useful for edoc too. I have been trying to > implement support for the Zope template language (which has some advantages > over XSLT, as for example being simpler and one is able to edit the > template as a regular XML/HTML file with demo values included) but I got > stuck and then external pressure made me put it on the shelf... It's half > done, but if you are done with your module it might be just as well to use > it instead. My module http://213.64.169.87:8001/xserl.yaws is just 4+3 functions basically that adds some syntactic sugar to xmerl, to make XSLT like stylesheets. I do not think it can be used instead of your templates so please implement them as well! Thanks Mikael From etxuwig@REDACTED Thu Jan 30 13:55:21 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Thu, 30 Jan 2003 13:55:21 +0100 (MET) Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) In-Reply-To: <15929.6295.960740.604403@antilipe.corelatus.se> Message-ID: On Thu, 30 Jan 2003, Matthias Lang wrote: >Consider the latex inline math expression > > $ [a + b]^{260} + \{a + b\}_i $ > >and write the same thing in MathML > > > > a+b > > > 260 > > + > > a+b > > > i > > The best proof yet that XML is indeed perfectly suitable for every kind of application. (: I think universities should enforce the rule that all mathematical expressions be formulated in MathML, even when handwritten! People will get used to it after a while, and before you know it, they will insist that math cannot be expressed in any other way. /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From luke@REDACTED Thu Jan 30 14:54:55 2003 From: luke@REDACTED (Luke Gorrie) Date: 30 Jan 2003 14:54:55 +0100 Subject: A Joeish Erlang distribution (long) In-Reply-To: References: Message-ID: Joe Armstrong writes: > << Sometimes I think it's time to write > > "Programming made difficult in 25 years" > > Me, I hate all the "Learn SQL in 20 minutes" type books - > > something that takes 20 minutes to learn can't be worth learning. See also: "Teach Yourself Programming in Ten Years", http://www.norvig.com/21-days.html -Luke From joe@REDACTED Thu Jan 30 16:55:02 2003 From: joe@REDACTED (Joe Armstrong) Date: Thu, 30 Jan 2003 16:55:02 +0100 (CET) Subject: A Joeish Erlang distribution (long) In-Reply-To: Message-ID: Nice one - actually what I had in mind was Brian Church's stunningly funny "Learn Greek in 25 Years" To quote from the Athen's news: Brian Church's 'Learn Greek in 25 Years' is on sale in Eleftheroudakis (17 Panepistimiou St) and Compendium (28 Nikis St). Price: 2,500 drachmas. His latest writings are still worth reading Last week's article http://www.athensnews.gr/athweb/nathens.print_unique?e=C&f=12998&m=A99&aa=0&eidos=S Tells the tragic tale of the trouble that the monks of Esfigmenou monastery on Mount Athos have gotten into for not taking their rubbish out for the last 356 years ... Heady stuff /Joe On 30 Jan 2003, Luke Gorrie wrote: > Joe Armstrong writes: > > > << Sometimes I think it's time to write > > > > "Programming made difficult in 25 years" > > > > Me, I hate all the "Learn SQL in 20 minutes" type books - > > > > something that takes 20 minutes to learn can't be worth learning. > > See also: "Teach Yourself Programming in Ten Years", > http://www.norvig.com/21-days.html > > -Luke > From vances@REDACTED Fri Jan 31 07:20:40 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 31 Jan 2003 01:20:40 -0500 Subject: {error,sticky_directory} In-Reply-To: <7487496.1043991943114.JavaMail.nobody@wamui02.slb.atl.earthlink.net> References: <7487496.1043991943114.JavaMail.nobody@wamui02.slb.atl.earthlink.net> Message-ID: <20030131062040.GC28236@frogman.motivity.ca> Steve, Actually what it's telling you is that the there is already a module named "sets" in a directory within the code path which has previously been marked as "sticky". See code:stick_dir/1 and code:unstick_dir/1. You'll find that it is the stdlib directory which has been set this way. You should rename your module to something which doesn't conflict or if you like to live dangerously just unsrick the stdlib directory: 1> c(sets). % note that ".erl" extension uneeded {error,sticky_directory} =ERROR REPORT==== 31-Jan-2003::01:37:25 === Can't load module that resides in sticky dir 2> code:which(sets). "/usr/local/lib/erlang/lib/stdlib-1.10.1.1/ebin/sets.beam" 3> code:unstick_dir("/usr/local/lib/erlang/lib/stdlib-1.10.1.1/ebin"). ok 4> c(sets). ./sets.erl:85: Warning: function do_find_path/3 is unused ./sets.erl:85: Warning: function find_path/3 is unused {ok,sets} 5> code:clash(). ** ./sets.beam hides /usr/local/lib/erlang/lib/stdlib-1.10.1.1/ebin/sets.beam ** Found 1 name clashes in code paths ok 6> code:which(sets). "/export/home/vances/sets.beam" -Vance On Fri, Jan 31, 2003 at 04:49:20PM -0800, steve@REDACTED wrote: } When compiling the sets.erl example in "Concurrent Programming in Erlang" I get this error: } } Erlang (BEAM) emulator version 5.2 [source] [hipe] } } Eshell V5.2 (abort with ^G) } 1> c(sets.erl). } {error,sticky_directory} } } =ERROR REPORT==== 30-Jan-2003::22:52:02 === } Can't load module that resides in sticky dir } 2> } } What is this telling me? I might guess that the module is the one I'm trying to compile and sticky directory is the current directory. } } Rgds, } Steve From eleberg@REDACTED Fri Jan 31 07:49:25 2003 From: eleberg@REDACTED (Bengt Kleberg) Date: Fri, 31 Jan 2003 07:49:25 +0100 (MET) Subject: {error,sticky_directory} Message-ID: <200301310649.h0V6nPH24696@cbe.ericsson.se> > Date: Fri, 31 Jan 2003 16:49:20 -0800 (PST) > From: "steve@REDACTED" ...deleted > 1> c(sets.erl). > {error,sticky_directory} > > =ERROR REPORT==== 30-Jan-2003::22:52:02 === > Can't load module that resides in sticky dir > 2> > > What is this telling me? I might guess that the module is the one I'm trying to compile and sticky directory is the current directory. > this was on the list a few months ago. good faq candidate, say in ''9. Troubleshooting, Problems and Gotchas''. according to the manual for the ''code'' module: stick_dir(Dir) -> ok | {error, term()} Types: Dir = string() This function marks Dir as 'sticky'. The system issues a warning and rejects the request if a user tries to re-load a module in a sticky directory. Sticky directories are used to warn the user about inadvertent changes to system software. which means that ''sets'' is a system software module. you are not allowed to replace it. unless you un-stick the directory where system software module ''sets'' is located. bengt From vances@REDACTED Fri Jan 31 07:43:51 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 31 Jan 2003 01:43:51 -0500 Subject: {error,sticky_directory} In-Reply-To: <20030131062040.GC28236@frogman.motivity.ca> References: <7487496.1043991943114.JavaMail.nobody@wamui02.slb.atl.earthlink.net> <20030131062040.GC28236@frogman.motivity.ca> Message-ID: <20030131064351.GD28236@frogman.motivity.ca> On Fri, Jan 31, 2003 at 01:20:40AM -0500, Vance Shipley wrote: } } 4> c(sets). } ./sets.erl:85: Warning: function do_find_path/3 is unused } ./sets.erl:85: Warning: function find_path/3 is unused Oops, ignore those errors, they're mine. :) From jocke@REDACTED Fri Jan 31 09:47:24 2003 From: jocke@REDACTED (Joakim G.) Date: Fri, 31 Jan 2003 09:47:24 +0100 Subject: A Joeish Erlang distribution (long) References: <3E36933C.9090903@erlang-consulting.com> <20030128160140.A20074@bluetail.com> <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> Message-ID: <3E3A381C.4050502@bluetail.com> Hi, I have thought about Francesco's questions about how to structure an Erlang system with/without OTP. I would avoid OTP at least for a middle sized software projects involving 5-35 programmers. Why? I would like to keep full transparency to the use of primitive Erlang constructs, e.g. (async/sync) message passing, receive statements, loop based servers, EXIT signal propagation etc. OTP's high level abstraction and callback oriented approach alienates the programmer from what actually is going on in the system. This is bad. It also extremely boring. If you want Xt programming why not go for that directly. In larger project (>35) I might use OTP or maybe even better: Don't start the project at all. Too big. I would prefer to divide the larger project into *very* (as in *very*) separate middle sized projects instead. You know all that. If not possible. Do something else. This is how I would go about it: Compile a short best practice guideline on how two write three types of servers, i.e. gen_serv.erl, tcp_serv.erl, app_serv.erl. I would keep the majority of the guidelines as in-line comments in the code skeletons for these servers. gen_serv Loop based, receive based, message passed based, nice init phase, clear API. {tcp,udp}_serv s`Same characteristics as for gen_serv above but for tcp and udp. app_serv Supervision of gen_serv and {tcp,udp}_serv instances. (I will not delve deeper here). Each sub-group within the larger project would be responsible for its app_serv instance and all started processes should adhere to the mechanisms "enforced" by gen_serv and tcp_serv skeletons. Not that far from what OTP tries to give! Only *much* more light weight and without sacrificing Erlang transparency. No "fun" removed. I would setup two global services (servers) as well to be used by all sub-groups within the project: 1. Distributed and persistent configuration registry (ala Window's Registry) with support for set, get, and validation rules for values as well as subscription support for value changes. Nice export/dump format etc. 2. An extensible log server. The error_logger module comes pretty close with OTP contamination and all. I may rewrite it. That concludes my "pure" Erlang approach to OTP. All the above might be possible to describe in a single chapter in the new Erlang book (code skeletons and all). Cheers /Jocke Klacke wrote: >>You would not divide the processes into behaviors? > > > Nope > > >>You would not place >>your behaviors in supervision trees? > > > > Nope > > >>You would not encapsulate your >>supervision trees in applications? > > > Nope > > >>You would not glue together your >>applications and start them using a boot file? > > > Nope > > >>If you use the generic >>behaviors or not, that is another story The OTP design principles are >>something beginners *should* start doing as soon as they are confident >>with Erlang, as it is the natural step towards writing their own. > > > > Sorry, don't agree. > > >>If you prefer to avoid the systools, > > > > Yes, > > >>or implement your own application >>controller as the existing one lacks many features, fine. If you stay >>away from the release handler, > > > Absolutely. > > > >>you are not alone (I avoid it myself >>whenever possible). And if you use your own error logging mechanism, >>that makes two of us. But I have a hard time following how you can not >>build a large coherent system without using the theory behind the >>Erlang/OTP design principles as it is described in the documentation >>manuals or in the OTP course material we have been using on thousands of >>people for almost 8 years. I would be very careful to recommending >>people evaluating Erlang or building their first product to bypass the >>principles, as that is what makes Erlang even more powerful than what it >>already is. >> >> >> >>>Not me anyway, I don't like them (because I don't understand them) >> >> >>I am sure we can invite you when we give a course near you ;-) > > > :-) > > > I'll tell you what I use. I use the gen_servers. I have never used any > of the other gen_ modules (except gen_tcp of cource ... but that > is an entirely different beast, then gen_ in gen_tcp only has the > name in common with gen_fsm and gen_event) > > I actually do use applications. Not that I like them but if I want to > write an erlang program that fits into the otp tree I must do that. > > I've never used the release handler, I barely understand the > error_logger. Everytime I need to do something with the error_logger such > a duplicating error_messages to go to yet another place I have to look > deep and hard at the code again. > > I've never had a supervision tree deeper than 1. > > > /klacke From vances@REDACTED Fri Jan 31 10:02:39 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 31 Jan 2003 04:02:39 -0500 Subject: A Joeish Erlang distribution In-Reply-To: <3E3A381C.4050502@bluetail.com> References: <3E36933C.9090903@erlang-consulting.com> <20030128160140.A20074@bluetail.com> <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> <3E3A381C.4050502@bluetail.com> Message-ID: <20030131090239.GG28236@frogman.motivity.ca> You guys are confusing the people on this list who haven't had the benefit of years of Erlang coding experience. It's hard to wrap your head around the difference between Erlang and OTP when what you're working with is the documentation for the Erlang/OTP distribution. In my case I embraced Erlang because the OTP was built using it. I wasn't looking for a cool new language that I'd be the only one on my block who knew.(*) I was looking to manage all the problems that come with building a telecom system. OTP may not be perfect but until you're ready to build a better one you should be using it. For all the folks still on the learning curve (most): Follow the OTP design principles, and use the OTP tools. You will stay out of trouble and build systems which work well while concentrating on your application itself. -Vance On Fri, Jan 31, 2003 at 09:47:24AM +0100, Joakim G. wrote: } } I would avoid OTP at least for a middle sized software projects } involving 5-35 programmers. } } Why? I would like to keep full transparency to the use of primitive } Erlang constructs, e.g. (async/sync) message passing, receive } statements, loop based servers, EXIT signal propagation etc. } } OTP's high level abstraction and callback oriented approach alienates } the programmer from what actually is going on in the system. This is } bad. It also extremely boring. If you want Xt programming why not go } for that directly. (*) Erlang certainly is cool and using the language to code our applications has been both a joy and a boon to our productivity. (...and I'm pretty sure I'm the only one on the block ...) From jocke@REDACTED Fri Jan 31 10:49:04 2003 From: jocke@REDACTED (Joakim G.) Date: Fri, 31 Jan 2003 10:49:04 +0100 Subject: A Joeish Erlang distribution References: <3E36933C.9090903@erlang-consulting.com> <20030128160140.A20074@bluetail.com> <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> <3E3A381C.4050502@bluetail.com> <20030131090239.GG28236@frogman.motivity.ca> Message-ID: <3E3A4690.4010906@bluetail.com> True, true. But this needs to be discussed somewhere?! We may divide the 'erlang-questions' list into a 'devel' and 'user' list I suppose? Probably not. The things I propose here is meant make Erlang easier to use (not Erlang/OTP). If you want a *Telecom* platform. Please, go ahead use OTP! It's solid and does what it's suppose to do. I'm just telling you what my "years of Erlang coding experience" has learnt me. Be it politically correct or not. Telecom:ish or not. I don't care. /Jocke Vance Shipley wrote: > You guys are confusing the people on this list who haven't had the > benefit of years of Erlang coding experience. It's hard to wrap > your head around the difference between Erlang and OTP when what > you're working with is the documentation for the Erlang/OTP > distribution. > > In my case I embraced Erlang because the OTP was built using it. > I wasn't looking for a cool new language that I'd be the only one > on my block who knew.(*) I was looking to manage all the problems > that come with building a telecom system. OTP may not be perfect > but until you're ready to build a better one you should be using > it. > > For all the folks still on the learning curve (most): > > Follow the OTP design principles, and use the OTP > tools. You will stay out of trouble and build > systems which work well while concentrating on > your application itself. > > -Vance > > > On Fri, Jan 31, 2003 at 09:47:24AM +0100, Joakim G. wrote: > } > } I would avoid OTP at least for a middle sized software projects > } involving 5-35 programmers. > } > } Why? I would like to keep full transparency to the use of primitive > } Erlang constructs, e.g. (async/sync) message passing, receive > } statements, loop based servers, EXIT signal propagation etc. > } > } OTP's high level abstraction and callback oriented approach alienates > } the programmer from what actually is going on in the system. This is > } bad. It also extremely boring. If you want Xt programming why not go > } for that directly. > > > (*) Erlang certainly is cool and using the language to code our > applications has been both a joy and a boon to our productivity. > (...and I'm pretty sure I'm the only one on the block ...) -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From Vlad.Dumitrescu@REDACTED Fri Jan 31 10:51:18 2003 From: Vlad.Dumitrescu@REDACTED (Vlad Dumitrescu (EAW)) Date: Fri, 31 Jan 2003 10:51:18 +0100 Subject: A Joeish Erlang distribution Message-ID: <5F03ACA2F76DD411B8BC00508BE3B4D71200F729@esemont203.gbg.edt.ericsson.se> Hi, > In my case I embraced Erlang because the OTP was built using it. > I wasn't looking for a cool new language that I'd be the only one > on my block who knew.(*) I was looking to manage all the problems > that come with building a telecom system. OTP may not be perfect > but until you're ready to build a better one you should be using > it. I think there are two kinds of potential new users: those working with telecom (who actually need OTP) and those who don't (who might be "scared" by OTP). *IF* there will be a modularization of Erlang/OTP, I think it will be worth considering to "split" the marketing message: - Erlang -- the cool COPL that will let you do all this wonderous stuff and never crashes. - OTP -- the super-duper telecom framework, which happens to be implemented in Erlang. (*) - ... -- I can think even of an "Internet Platform" that will promote that aspect (a better name is needed). I think this will not alienate any of the two categories mentioned. (*) I thing gen_server and gen_fsm, for example, are general enough concepts to not belong to OTP. When I learned about Erlang, I belonged to "those who don't" and it wasn't really a problem just to ignore all the OTP stuff at first. But it took a while to gather the courage to dig into Erlang, and when it comes to OTP I didn't really get the hang of it until I attended the course. There is a lot more to babble about, but I won't bore you with it :-) regards, Vlad From mbj@REDACTED Fri Jan 31 10:54:01 2003 From: mbj@REDACTED (Martin Bjorklund) Date: Fri, 31 Jan 2003 10:54:01 +0100 (CET) Subject: OTP vs. non-OTP (was: A Joeish Erlang distribution (long)) In-Reply-To: <3E3A381C.4050502@bluetail.com> References: <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> <3E3A381C.4050502@bluetail.com> Message-ID: <20030131.105401.70223322.mbj@bluetail.com> "Joakim G." wrote: > I would avoid OTP at least for a middle sized software projects > involving 5-35 programmers. Can't just listen quietly anymore... It's very interesting to hear opinions from different people; people who have built shipping erlang products and people that have not. Interstingly, people who haven't shipped products seem to think that OTP is an unnecessary burden, and people who actually have built products tend to like the support OTP gives you. In your case, and klacke's (except for yaws, see below), you have other people around you that take care of the productification; building software packages, taking care of upgrades, start of the system, configuring the system etc. You think this is better done w/o OTP? Fine, go ahead and prove me wrong. Of course it's possible to do this without OTP, you can do anything with a turing machine... Klacke wrote: > >>You would not divide the processes into behaviors? > > > > > > Nope Oh yes you would and you even do that. > > I actually do use applications. Not that I like them but if I want to > > write an erlang program that fits into the otp tree I must do that. Right, and this is one of the objectives for OTP - if you structure your code as an application with behaviours other people can easily integrate it into their own products. Since even you wrote Yaws in this way I think we succeded! Now, of course OTP is not perfect. As been stated before, the documentation needs to be better. However, it's not _that bad_. People (on this list e.g.) who are actually facing a real problem (not just theoretically thik about it) have read the docs (and code) and use OTP to solve the problem. To comment on the original subject on this thread, I would also like to see a more modular Erlang/OTP distribution from erlang.org. /martin From francesco@REDACTED Fri Jan 31 11:34:22 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Fri, 31 Jan 2003 10:34:22 +0000 Subject: To OTP or not to OTP (Was a Joeish distribution) References: <3E36933C.9090903@erlang-consulting.com> <20030128160140.A20074@bluetail.com> <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> <3E3A381C.4050502@bluetail.com> Message-ID: <3E3A512E.2080109@erlang-consulting.com> I would be *very* careful to go out and say what you did when the majority of non ericsson people on this list have learnt Erlang on their own, and are developing systems without the proper mentorship of people who have used Erlang on a large scale. OTP was built based on many years of project experiences, feedback from users, and extensive prototyping. The design principles which came out of it fill a gap which exists in pure Erlang. The best example that comes to my mind is people asking "How can I apply OO design" in Erlang? The reason is that they are trying to fill in this gap. The gap covers * Structuring programs & general SW architecture issues * Reusability * Maintenance * Fault Tolerance * Design Patterns I would agree that there are some pretty ugly inconsistencies and constructs in some of the principles. But they are minor, and often just syntactical compared to the advantages you get from using them. I work with people who have learnt Erlang on their own, with out the proper mentorship, on a daily basis. They do not have the time to develop their own theories on how to structure and develop large scale SW development using Erlang. There is no need for them to reinvent the wheel. They need to get products out, and they need to get them out as fast as possible. Using OTP and the libraries' well tested code is today the only way to do it efficiently. You guys developed OTP. Developed Erlang. Have massive experience and knowledge and know from the start what is right, what is wrong, alongside all the special cases to handle. What you do not seem to understand is that that is not the case out there. The 50% code reduction we usually achieve when migrating a non OTP system to OTP says it all. And that covers just the code size, not the added functionality. Francesco -- http://www.erlang-consulting.com Joakim G. wrote: > Hi, > I have thought about Francesco's questions about how to structure an > Erlang system with/without OTP. > > I would avoid OTP at least for a middle sized software projects > involving 5-35 programmers. > > Why? I would like to keep full transparency to the use of primitive > Erlang constructs, e.g. (async/sync) message passing, receive > statements, loop based servers, EXIT signal propagation etc. > > OTP's high level abstraction and callback oriented approach alienates > the programmer from what actually is going on in the system. This is > bad. It also extremely boring. If you want Xt programming why not go > for that directly. > > In larger project (>35) I might use OTP or maybe even better: Don't > start the project at all. Too big. I would prefer to divide the larger > project into *very* (as in *very*) separate middle sized projects > instead. You know all that. If not possible. Do something else. > > This is how I would go about it: > > Compile a short best practice guideline on how two write three types > of servers, i.e. gen_serv.erl, tcp_serv.erl, app_serv.erl. I would > keep the majority of the guidelines as in-line comments in the code > skeletons for these servers. > > gen_serv > Loop based, receive based, message passed based, nice init > phase, clear API. > {tcp,udp}_serv > s`Same characteristics as for gen_serv above but for tcp and > udp. > app_serv > Supervision of gen_serv and {tcp,udp}_serv instances. > > (I will not delve deeper here). > > Each sub-group within the larger project would be responsible for its > app_serv instance and all started processes should adhere to the > mechanisms "enforced" by gen_serv and tcp_serv skeletons. > > Not that far from what OTP tries to give! Only *much* more light > weight and without sacrificing Erlang transparency. No "fun" removed. > > I would setup two global services (servers) as well to be used by all > sub-groups within the project: > > 1. Distributed and persistent configuration registry (ala Window's > Registry) with support for set, get, and validation rules for > values as well as subscription support for value changes. Nice > export/dump format etc. > 2. An extensible log server. The error_logger module comes pretty close > with OTP contamination and all. I may rewrite it. > > That concludes my "pure" Erlang approach to OTP. > > All the above might be possible to describe in a single chapter in the > new Erlang book (code skeletons and all). > > Cheers > /Jocke > > Klacke wrote: > >>> You would not divide the processes into behaviors? >> >> >> >> Nope >> >> >>> You would not place your behaviors in supervision trees? >> >> >> >> >> Nope >> >> >>> You would not encapsulate your supervision trees in applications? >> >> >> >> Nope >> >> >>> You would not glue together your applications and start them using a >>> boot file? >> >> >> >> Nope >> >> >>> If you use the generic behaviors or not, that is another story The >>> OTP design principles are something beginners *should* start doing as >>> soon as they are confident with Erlang, as it is the natural step >>> towards writing their own. >> >> >> >> >> Sorry, don't agree. >> >> >>> If you prefer to avoid the systools, >> >> >> >> >> Yes, >> >> >>> or implement your own application controller as the existing one >>> lacks many features, fine. If you stay away from the release handler, >> >> >> >> Absolutely. >> >> >> >>> you are not alone (I avoid it myself whenever possible). And if you >>> use your own error logging mechanism, that makes two of us. But I >>> have a hard time following how you can not build a large coherent >>> system without using the theory behind the Erlang/OTP design >>> principles as it is described in the documentation manuals or in the >>> OTP course material we have been using on thousands of people for >>> almost 8 years. I would be very careful to recommending people >>> evaluating Erlang or building their first product to bypass the >>> principles, as that is what makes Erlang even more powerful than what >>> it already is. >>> >>> >>> >>>> Not me anyway, I don't like them (because I don't understand them) >>> >>> >>> >>> I am sure we can invite you when we give a course near you ;-) >> >> >> >> :-) >> >> >> I'll tell you what I use. I use the gen_servers. I have never used any >> of the other gen_ modules (except gen_tcp of cource ... but that >> is an entirely different beast, then gen_ in gen_tcp only has the >> name in common with gen_fsm and gen_event) >> >> I actually do use applications. Not that I like them but if I want to >> write an erlang program that fits into the otp tree I must do that. >> >> I've never used the release handler, I barely understand the >> error_logger. Everytime I need to do something with the error_logger such >> a duplicating error_messages to go to yet another place I have to look >> deep and hard at the code again. >> >> I've never had a supervision tree deeper than 1. >> >> >> /klacke > > > > > From etxuwig@REDACTED Fri Jan 31 11:33:19 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 31 Jan 2003 11:33:19 +0100 (MET) Subject: OTP vs. non-OTP (was: A Joeish Erlang distribution (long)) In-Reply-To: <20030131.105401.70223322.mbj@bluetail.com> Message-ID: On Fri, 31 Jan 2003, Martin Bjorklund wrote: >It's very interesting to hear opinions from different >people; people who have built shipping erlang products and >people that have not. Interstingly, people who haven't >shipped products seem to think that OTP is an unnecessary >burden, and people who actually have built products tend to >like the support OTP gives you. I second that opinion. Most people here at AXD301 are not that familiar with OTP (except for the parts that are relevant to them). Most programmers use gen_server, mnesia and the standard libraries; a few use things like gen_tcp; many come in contact with SNMP somehow; and INETS, but only indirectly, using our internal web page building support. A handful of people really get OTP dirt under their fingernails on a daily basis, working with the application controller, release handler, etc. Supervision structures are built using templates, and a few people get involved in doing it once, and then forget about it. Very few actually understand how it all works, but don't have to, either. (*) >In your case, and klacke's (except for yaws, see below), >you have other people around you that take care of the >productification; building software packages, taking care >of upgrades, start of the system, configuring the system >etc. You think this is better done w/o OTP? Fine, go ahead >and prove me wrong. I was expecting this retort. What kept you? (: For those relatively new to Erlang, Martin and Magnus Fr?berg (also at Nortel) used to work on the OTP team and support the application controller, release handler, global, etc.(**) Even then, most of the others (e.g. Klacke and Jocke ;) in the group didn't really know all that stuff, and didn't want to know. I have no objection to this, but remember that both Klacke and Jocke have had the good fortune to have some of the top experts in this area sitting next to them. Then it's easy to just forget about all that complexity and what it does for you. This is as it should be. I have stayed out of the discussion mainly because I'm one of the OTP experts at AXD301, a Large Telecom Project (even though it's not particularly large by Ericsson standards...) Noone has questioned our need for OTP, and I felt that I shouldn't necessarily speak for the rest of you. I think what's needed is primarily better tutorials, and better support for a gentle introduction to OTP. I fully agree with Francesco and Martin. /Uffe (*) This has a downside, though. One of our finest programmers once tried to demonstrate to some sceptics how easy things were if you used Erlang, but he found that he didn't know how to put together a distributed OTP-based system from scratch. Some quick-start examples are badly needed. (**) Others (e.g. Lennart ?hman) have been involved as well, but of the people I know to be at Nortel now, I think M&M were most active in this area. Jocke designed INETS and fathered Eddie, and Klacke, well... lots -- Distributed Erlang and Mnesia (and, IIR global and rpc), for example. I would not think of trying to belittle their achievements in any way. Just suggesting that they could both afford to forget about many of the problems that OTP solves. -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From francesco@REDACTED Fri Jan 31 11:41:47 2003 From: francesco@REDACTED (Francesco Cesarini) Date: Fri, 31 Jan 2003 10:41:47 +0000 Subject: A Joeish Erlang distribution References: <5F03ACA2F76DD411B8BC00508BE3B4D71200F729@esemont203.gbg.edt.ericsson.se> Message-ID: <3E3A52EB.1000702@erlang-consulting.com> > I think there are two kinds of potential new users: those working > with telecom (who actually need OTP) and those who don't (who might > be "scared" by OTP). OTP is a bad name, as the T should stand for * Distributed * Fault Tolerant * Soft Real time * Massively concurrent and not Telecom. OTP consists of three components: * Erlang * Applications (Of which some *might* be telecom related) * Design Principles It is unfortunate that when Erlang went open source, they never picked up the name we were using it when commercially selling in, namely Erlang System. Francesco -- http://www.erlang-consulting.com From enano@REDACTED Fri Jan 31 11:54:00 2003 From: enano@REDACTED (Miguel Barreiro Paz) Date: Fri, 31 Jan 2003 11:54:00 +0100 (CET) Subject: A Joeish Erlang distribution In-Reply-To: <3E3A4690.4010906@bluetail.com> References: <3E36933C.9090903@erlang-consulting.com> <20030128160140.A20074@bluetail.com> <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> <3E3A381C.4050502@bluetail.com> <20030131090239.GG28236@frogman.motivity.ca> <3E3A4690.4010906@bluetail.com> Message-ID: > If you want a *Telecom* platform. Please, go ahead use OTP! It's solid and > does what it's suppose to do. But then probably gen_server, gen_fsm et al are not exactly "Telecom". What is exclusively Telecom in Erlang? The ASN.1 compiler? H.323, LDAP and Kerberos5 are all spread in the common, non-Telecom world :) and their wire formats are specified in asn1. The CORBA apps? the GNOME desktop is as little Telecom-oriented as it can be and gnome apps communicate to each other using CORBA. SNMP? Pieces of software as commonplace as the Squid http cache or Windows2k have an SNMP interface and are not generally considered Telecom world only. My point is that OTP is not really Telecom-only. The gen_* behaviours especially. And half of the usefulness of Erlang is due to that set of design principles, libraries and applications that has the bad luck of having a "T" for "Telecom" in its name. Kindest regards, Miguel From DANIESC.SCHUTTE@REDACTED Fri Jan 31 12:47:49 2003 From: DANIESC.SCHUTTE@REDACTED (DANIESC SCHUTTE) Date: Fri, 31 Jan 2003 13:47:49 +0200 Subject: A Joeish Erlang distribution / OTP / NON-OTP Message-ID: What's in a name? :) an OTP by any other name would work just as well. We just completed a full banking system using erlang - so Open Transaction / Transacting Platform is also applicable. (BTW - the system is a full billing system as well - all nicely integrated in an OTP fashion. Regards Daniel Danie Schutte Phone: +27 - 11 - 203 - 1613 Mobile: 084-468-3138 e-Mail: Daniesc@REDACTED >>> Miguel Barreiro Paz 01/31/03 12:54PM >>> > If you want a *Telecom* platform. Please, go ahead use OTP! It's solid and > does what it's suppose to do. But then probably gen_server, gen_fsm et al are not exactly "Telecom". What is exclusively Telecom in Erlang? The ASN.1 compiler? H.323, LDAP and Kerberos5 are all spread in the common, non-Telecom world :) and their wire formats are specified in asn1. The CORBA apps? the GNOME desktop is as little Telecom-oriented as it can be and gnome apps communicate to each other using CORBA. SNMP? Pieces of software as commonplace as the Squid http cache or Windows2k have an SNMP interface and are not generally considered Telecom world only. My point is that OTP is not really Telecom-only. The gen_* behaviours especially. And half of the usefulness of Erlang is due to that set of design principles, libraries and applications that has the bad luck of having a "T" for "Telecom" in its name. Kindest regards, Miguel ##################################################################################### 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 and copies. ##################################################################################### From jocke@REDACTED Fri Jan 31 13:13:45 2003 From: jocke@REDACTED (Joakim G.) Date: Fri, 31 Jan 2003 13:13:45 +0100 Subject: OTP vs. non-OTP (was: A Joeish Erlang distribution (long)) References: <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> <3E3A381C.4050502@bluetail.com> <20030131.105401.70223322.mbj@bluetail.com> Message-ID: <3E3A6879.3060303@bluetail.com> Martin Bjorklund wrote: > "Joakim G." wrote: > >>I would avoid OTP at least for a middle sized software projects >>involving 5-35 programmers. > > Can't just listen quietly anymore... Said one (of three) people who designed OTP in the first place. > It's very interesting to hear opinions from different people; people > who have built shipping erlang products and people that have not. > Interstingly, people who haven't shipped products seem to think that > OTP is an unnecessary burden, and people who actually have built > products tend to like the support OTP gives you. > > In your case, and klacke's (except for yaws, see below), you have other > people around you that take care of the productification; building > software packages, taking care of upgrades, start of the system, > configuring the system etc. Now we are talking! Martin came into my office and gave me the evil eye btw. :-) I just say this: 1) Did we have any choice but to use OTP having the three designers behind OTP itself in the project? Not. 2) Only a handful of people seems to be able to grasp all what OTP has to offer. Klacke and me doesn't after all these years it seems. I may just be plain stupid but I know Klacke isn't. 3) There was no alternative at the time. If the thing I describe here was in place I would have voted on using that instead. 4) I have worked for years with OTP now and I'm obviously not satisfied. That may not mean anything to you. It means something for me though. > You think this is better done w/o OTP? > Fine, go ahead and prove me wrong. OK, next *new* project. I don't plan on rewriting all OTP stuff we have now which actually works. > Of course it's possible to do this without OTP, you can do anything > with a turing machine... Huh! We should probably not burden the erlang-questions lists with further discussions about this. Cheers /Jocke > Klacke wrote: > > >>>>You would not divide the processes into behaviors? >>> >>> >>>Nope >> > > Oh yes you would and you even do that. > > >>>I actually do use applications. Not that I like them but if I want to >>>write an erlang program that fits into the otp tree I must do that. >> > > Right, and this is one of the objectives for OTP - if you structure > your code as an application with behaviours other people can easily > integrate it into their own products. Since even you wrote Yaws in > this way I think we succeded! > > > Now, of course OTP is not perfect. As been stated before, the > documentation needs to be better. However, it's not _that bad_. > People (on this list e.g.) who are actually facing a real problem (not > just theoretically thik about it) have read the docs (and code) and > use OTP to solve the problem. > > > To comment on the original subject on this thread, I would also like > to see a more modular Erlang/OTP distribution from erlang.org. > > > > /martin -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From jocke@REDACTED Fri Jan 31 13:40:19 2003 From: jocke@REDACTED (Joakim G.) Date: Fri, 31 Jan 2003 13:40:19 +0100 Subject: A Joeish Erlang distribution References: <3E36933C.9090903@erlang-consulting.com> <20030128160140.A20074@bluetail.com> <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> <3E3A381C.4050502@bluetail.com> <20030131090239.GG28236@frogman.motivity.ca> <3E3A4690.4010906@bluetail.com> Message-ID: <3E3A6EB3.5070009@bluetail.com> Miguel Barreiro Paz wrote: >>If you want a *Telecom* platform. Please, go ahead use OTP! It's solid and >>does what it's suppose to do. > > But then probably gen_server, gen_fsm et al are not exactly > "Telecom". What is exclusively Telecom in Erlang? The ASN.1 compiler? > H.323, LDAP and Kerberos5 are all spread in the common, non-Telecom world > :) and their wire formats are specified in asn1. The CORBA apps? the GNOME > desktop is as little Telecom-oriented as it can be and gnome apps > communicate to each other using CORBA. SNMP? Pieces of software as > commonplace as the Squid http cache or Windows2k have an SNMP interface > and are not generally considered Telecom world only. > > My point is that OTP is not really Telecom-only. The gen_* > behaviours especially. And half of the usefulness of Erlang is due to that > set of design principles, libraries and applications that has the bad luck > of having a "T" for "Telecom" in its name. Supervisor trees. More and less complex restart strategies. Possible to nest supervisor in supervisor trees to group gen_servers having this or that common crash recovery pattern. Hot code swapping, which we never use in the field anyway etc = To much generic robustness library functionality. All this to make it possible to build really large, soft real time, robust systems. This used to be the charcteristics for Telecom projects. This may have become relevant for *all* software projects out there today. It's just a pity that so few has understood this (at least if we compare the Erlang's user base with for example Python's.). I believe it would be easier to gain more Erlang followers if we had a simpler middle way to achieve what OTP promises, i.e. the thing I propose. If you think the user base is unimportant or me being silly and rhetoric you are probably right. Cheers /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From mbj@REDACTED Fri Jan 31 13:44:01 2003 From: mbj@REDACTED (Martin Bjorklund) Date: Fri, 31 Jan 2003 13:44:01 +0100 (CET) Subject: OTP vs. non-OTP In-Reply-To: <3E3A6879.3060303@bluetail.com> References: <3E3A381C.4050502@bluetail.com> <20030131.105401.70223322.mbj@bluetail.com> <3E3A6879.3060303@bluetail.com> Message-ID: <20030131.134401.28392865.mbj@bluetail.com> "Joakim G." wrote: > 2) Only a handful of people seems to be able to grasp all what OTP has > to offer. So is this a problem? I don't grasp all of OTP (e.g. I know nothing about Corba). Does that make OTP a bad thing? How many people understand (or even know) everything in libc, and they still use it. > We should probably not burden the erlang-questions lists with further > discussions about this. All right; in your office... :) /martin From jocke@REDACTED Fri Jan 31 13:52:53 2003 From: jocke@REDACTED (Joakim G.) Date: Fri, 31 Jan 2003 13:52:53 +0100 Subject: OTP vs. non-OTP (was: A Joeish Erlang distribution (long)) References: Message-ID: <3E3A71A5.4090206@bluetail.com> Ulf Wiger wrote: >>In your case, and klacke's (except for yaws, see below), >>you have other people around you that take care of the >>productification; building software packages, taking care >>of upgrades, start of the system, configuring the system >>etc. You think this is better done w/o OTP? Fine, go ahead >>and prove me wrong. > > > I was expecting this retort. What kept you? (: > > For those relatively new to Erlang, Martin and Magnus > Fr?berg (also at Nortel) used to work on the OTP team and > support the application controller, release handler, global, > etc.(**) Even then, most of the others (e.g. Klacke and > Jocke ;) in the group didn't really know all that stuff, and > didn't want to know. I have no objection to this, but > remember that both Klacke and Jocke have had the good > fortune to have some of the top experts in this area sitting > next to them. Then it's easy to just forget about all that > complexity and what it does for you. This is as it should > be. We are lucky indeed having Martin and Magnus on the team. Very so! I'm very glad. The more problem for other projects which don't have Martin, Magnus and Uffe onboard. There isn't many out there with their OTP capacity which actually understands how to benefit the most from OTP. Things could be simpler. That's the only thing I'm saying. No offense. > /Uffe > > (*) This has a downside, though. One of our finest > programmers once tried to demonstrate to some sceptics how > easy things were if you used Erlang, but he found that he > didn't know how to put together a distributed OTP-based > system from scratch. Some quick-start examples are badly > needed. What a good example. Thanks. :-) > (**) Others (e.g. Lennart ?hman) have been involved as well, > but of the people I know to be at Nortel now, I think M&M > were most active in this area. Jocke designed INETS and > fathered Eddie, and Klacke, well... lots -- Distributed > Erlang and Mnesia (and, IIR global and rpc), for example. I > would not think of trying to belittle their achievements in > any way. Just suggesting that they could both afford to > forget about many of the problems that OTP solves. For sure. But we also see things OTP solve for us which we rather see it didn't. Stuff just adding steepnes to the Erlang/OTP learning curve. Cheers /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From enano@REDACTED Fri Jan 31 13:54:28 2003 From: enano@REDACTED (Miguel Barreiro Paz) Date: Fri, 31 Jan 2003 13:54:28 +0100 (CET) Subject: A Joeish Erlang distribution In-Reply-To: <3E3A6EB3.5070009@bluetail.com> References: <3E36933C.9090903@erlang-consulting.com> <20030128160140.A20074@bluetail.com> <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> <3E3A381C.4050502@bluetail.com> <20030131090239.GG28236@frogman.motivity.ca> <3E3A4690.4010906@bluetail.com> <3E3A6EB3.5070009@bluetail.com> Message-ID: > this or that common crash recovery pattern. Hot code swapping, which we > never use in the field anyway etc = To much generic robustness library > functionality. Never underestimate the selling power of hot code swapping :-) > I believe it would be easier to gain more Erlang followers if we had a > simpler middle way to achieve what OTP promises, i.e. the thing I propose. I agree completely. I'm just objecting that leaving OTP for telecom use only is in my humble opinion a big mistake. Until there is something better, of course. > If you think the user base is unimportant or me being silly and rhetoric > you are probably right. None of them - sorry if I sounded harsh. Kindest regards, Miguel From jocke@REDACTED Fri Jan 31 14:00:39 2003 From: jocke@REDACTED (Joakim G.) Date: Fri, 31 Jan 2003 14:00:39 +0100 Subject: OTP vs. non-OTP References: <3E3A381C.4050502@bluetail.com> <20030131.105401.70223322.mbj@bluetail.com> <3E3A6879.3060303@bluetail.com> <20030131.134401.28392865.mbj@bluetail.com> Message-ID: <3E3A7377.70501@bluetail.com> Martin Bjorklund wrote: > "Joakim G." wrote: > > >>2) Only a handful of people seems to be able to grasp all what OTP has >> to offer. > > > So is this a problem? I don't grasp all of OTP (e.g. I know nothing > about Corba). Does that make OTP a bad thing? Oh well. With OTP *I* mean modules such as application, supervisor, gen_server, gen_fsm, supervisor_bridge, gen_event, error_logger, sys, appup, relup, release_handler, sasl, systools and some more. I should probably call this set of modules something else to stop confusing you all with the OTP acronym. Suggestions? > How many people > understand (or even know) everything in libc, and they still use it. See above. >>We should probably not burden the erlang-questions lists with further >>discussions about this. > > All right; in your office... :) Come on; Liston. :-) /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From jocke@REDACTED Fri Jan 31 14:08:47 2003 From: jocke@REDACTED (Joakim G.) Date: Fri, 31 Jan 2003 14:08:47 +0100 Subject: OTP vs. non-OTP References: <3E3A381C.4050502@bluetail.com> <20030131.105401.70223322.mbj@bluetail.com> <3E3A6879.3060303@bluetail.com> <20030131.134401.28392865.mbj@bluetail.com> <3E3A7377.70501@bluetail.com> Message-ID: <3E3A755F.9050102@bluetail.com> Joakim G. wrote: > Martin Bjorklund wrote: >> "Joakim G." wrote: >> >>> 2) Only a handful of people seems to be able to grasp all what OTP has >>> to offer. >> >> So is this a problem? I don't grasp all of OTP (e.g. I know nothing >> about Corba). Does that make OTP a bad thing? > > Oh well. With OTP *I* mean modules such as application, supervisor, > gen_server, gen_fsm, supervisor_bridge, gen_event, error_logger, > sys, appup, relup, release_handler, sasl, systools and some more. > > I should probably call this set of modules something else to stop > confusing you all with the OTP acronym. Suggestions? All of these used to be in the sasl application in the beginning. If I remember correctly. They should have stayed there. /Jocke -- If you think the pen is mightier than the sword, the next time someone pulls out a sword I'd like to see you get up there with your Bic. From vances@REDACTED Fri Jan 31 17:51:52 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 31 Jan 2003 11:51:52 -0500 Subject: OTP vs. non-OTP In-Reply-To: <005001c2c9d8$c03e1c10$1e00a8c0@design> References: <005001c2c9d8$c03e1c10$1e00a8c0@design> Message-ID: <20030131165152.GJ28236@frogman.motivity.ca> On Sat, Feb 01, 2003 at 11:00:27AM +0100, Eduardo Figoli wrote: } } Should I invest time to learn OTP (patterns)? By all means. As has been said here before the sequence of events should be like this: 1) write small example programs using just Erlang 2) write real applications using generic behaviours and if appropriate supervision, application, OAM, etc. 3) spend years being happily productive 4) become purist and write/rewrite your own frameworks ... and this isn't a telecom specific answer. If you're writing a filter or file parser or tax calculator then keep it simple and just write some Erlang. If you're writing an application which is going to be turned on and run for a while like an SMTP daemon, web server, instant messaging server, directory server, etc. then use the design principles and package and run it as an embedded system (*). -Vance (*) until you have reached 4 in above From etxuwig@REDACTED Fri Jan 31 17:11:27 2003 From: etxuwig@REDACTED (Ulf Wiger) Date: Fri, 31 Jan 2003 17:11:27 +0100 (MET) Subject: warn_unused_vars Message-ID: Can someone explain this? 1> c(leader). {ok,leader} 2> leader:module_info(compile). [{options,[v3,warn_unused_vars]}, {version,"4.1.1"}, {time,{2003,1,31,16,5,57}}] 3> c(leader,[warn_unused_vars]). ./leader.erl:126: Warning: variable 'From' is unused {ok,leader} 4> leader:module_info(compile). [{options,[v3,warn_unused_vars,warn_unused_vars]}, {version,"4.1.1"}, {time,{2003,1,31,16,6,16}}] That is, I've added '-compile(warn_unused_vars)' in the source code, but the linter seems to ignore that. With module_info, I can see that the compile option is there. I don't get any warning unless I add 'warn_unused_vars' as an explicit option to compile, though. I looked briefly at compile.erl, but I'd rather that someone who knows the code take a look. It's not the simplest module in the OTP distribution. This is compiler-4.1.1 (OTP R9B) /Uffe -- Ulf Wiger, Senior Specialist, / / / Architecture & Design of Carrier-Class Software / / / Strategic Product & System Management / / / Ericsson Telecom AB, ATM Multiservice Networks From enano@REDACTED Fri Jan 31 13:14:10 2003 From: enano@REDACTED (Miguel Barreiro Paz) Date: Fri, 31 Jan 2003 13:14:10 +0100 (CET) Subject: non-telecom in erlang In-Reply-To: References: Message-ID: Daniel, > We just completed a full banking system using erlang - so Open > Transaction / Transacting Platform is also applicable. (BTW - the > system is a full billing system as well - all nicely integrated in an > OTP fashion. Could you provide more info on your system? It looks like a very interesting "look, erlang works for this" showcase. There is people around here working on a Risk Management System in erlang. Regards, Miguel From daniel.neri@REDACTED Fri Jan 31 13:48:38 2003 From: daniel.neri@REDACTED (Daniel =?iso-8859-1?q?N=E9ri?=) Date: 31 Jan 2003 12:48:38 +0000 Subject: Other things I don't get (WAS: Re: A Joeish Erlang distributi on (long)) References: Message-ID: Chandrashekhar Mullaparthi writes: > I think it(XML) was formulated by people who couldn't debug their > application when implementing a protocol exchanging messages in > binary format. A Tag,Length,Value form of encoding is all we need. Agreed. For a nice and simple example, see: http://www.twistedmatrix.com/documents/specifications/banana.html It's what I implemented the last time I had to invent a protocol over TCP. Regards, -- Daniel N?ri, Sigicom AB, Sweden From Marc.Vanwoerkom@REDACTED Fri Jan 31 23:24:01 2003 From: Marc.Vanwoerkom@REDACTED (Marc Ernst Eddy van Woerkom) Date: Fri, 31 Jan 2003 23:24:01 +0100 (MET) Subject: OTP vs. non-OTP In-Reply-To: <20030131165152.GJ28236@frogman.motivity.ca> (message from Vance Shipley on Fri, 31 Jan 2003 11:51:52 -0500) Message-ID: <200301312224.h0VMO1411082@bonsai.fernuni-hagen.de> > 2) write real applications using generic behaviours and if > appropriate supervision, application, OAM, etc. Is it possible to study this from the public available documentation? What would I have to read? Regards, Marc From klacke@REDACTED Fri Jan 31 23:47:19 2003 From: klacke@REDACTED (Klacke) Date: Fri, 31 Jan 2003 23:47:19 +0100 Subject: OTP vs. non-OTP (was: A Joeish Erlang distribution (long)) In-Reply-To: <20030131.105401.70223322.mbj@bluetail.com>; from mbj@bluetail.com on Fri, Jan 31, 2003 at 10:54:01AM +0100 References: <3E37A400.8040809@erlang-consulting.com> <20030129111836.C27679@bluetail.com> <3E3A381C.4050502@bluetail.com> <20030131.105401.70223322.mbj@bluetail.com> Message-ID: <20030131234719.A18813@bluetail.com> On Fri, Jan 31, 2003 at 10:54:01AM +0100, Martin Bjorklund wrote: > Klacke wrote: > > > >>You would not divide the processes into behaviors? > > > > > > > > > Nope > > Oh yes you would and you even do that. > Actually I don't even know what a behavior is. If I do indeed " divide the processes into behaviors" it is entirely by accident. So, what is an OTP behaviour ? /klacke -- Claes Wikstrom -- Caps lock is nowhere and Alteon WebSystems -- everything is under control http://www.bluetail.com/~klacke cellphone: +46 70 2097763 From vances@REDACTED Fri Jan 31 23:47:24 2003 From: vances@REDACTED (Vance Shipley) Date: Fri, 31 Jan 2003 17:47:24 -0500 Subject: OTP vs. non-OTP In-Reply-To: <200301312224.h0VMO1411082@bonsai.fernuni-hagen.de> References: <20030131165152.GJ28236@frogman.motivity.ca> <200301312224.h0VMO1411082@bonsai.fernuni-hagen.de> Message-ID: <20030131224724.GA227@frogman.motivity.ca> Marc, The opensource distribution or Erlang/OTP contains all of the OTP applications and documentation. From the top of the documentation tree you will find "System Documentation". There, at the bottom of the page, you will find a section titled "Working with OTP": System Principles How to create, start, restart and stop an OTP target system. Design Principles Structure your programs with applications, supervisors and generic behaviors (gen_server, gen_event and gen_fsm). Also use the built in error logger. OAM Principles OTP Operation and Management Principles The URLs are: http://www.erlang.org/doc/r9b/doc/system_principles/part_frame.html http://www.erlang.org/doc/r9b/doc/design_principles/part_frame.html http://www.erlang.org/doc/r9b/doc/oam/part_frame.html On Fri, Jan 31, 2003 at 11:24:01PM +0100, Marc Ernst Eddy van Woerkom wrote: } > 2) write real applications using generic behaviours and if } > appropriate supervision, application, OAM, etc. } } Is it possible to study this from the public available documentation? } What would I have to read? } } Regards, } Marc From shrogers@REDACTED Fri Jan 31 19:01:56 2003 From: shrogers@REDACTED (steve@shrogers.com) Date: Sat, 1 Feb 2003 02:01:56 0800 (UTC) Subject: {error,sticky_directory} Message-ID: <1542252.1044083064231.JavaMail.nobody@wamui04.slb.atl.earthlink.net> Vance: It was obvious to me that the the error message should mean something, but that I needed a magic decoder ring. Is there such a thing? I couldn't find much in the rather extensive documentation available for download. I suspect that the error messages are crystal clear to those who really understand Erlang. The rest of us need that magic decoder ring. Rgds, Steve -------Original Message------- From: Vance Shipley Sent: 01/31/03 03:19 PM To: steve@REDACTED Subject: Re: Re: {error,sticky_directory} > > Steve, Too many people did as you did and compiled a test program which clobbered the stdlib and which was needed for the correct operation of the system causing it to crash. This caused much confusion. The trouble I have/had with Erlang is in the error messages not being all that enlightening. At first it seems down right meaningless until you get into it more. -Vance On Fri, Jan 31, 2003 at 06:30:27PM -0800, steve@REDACTED wrote: } My thanks to Vance and Bengt. Erlang is interesting, but does have its share of quirks. } } Steve > From shrogers@REDACTED Fri Jan 31 19:54:07 2003 From: shrogers@REDACTED (steve@shrogers.com) Date: Sat, 1 Feb 2003 02:54:07 0800 (UTC) Subject: {error,sticky_directory} Message-ID: <6056970.1044086198983.JavaMail.nobody@wamui04.slb.atl.earthlink.net> Vance: Searchable documentation would help a lot. I did grep the source and found some hints, but I didn't quite "get it". Steve -------Original Message------- From: Vance Shipley Sent: 02/01/03 03:22 PM To: steve@REDACTED Subject: Re: Re: Re: {error,sticky_directory} > > Searchable documentation would help a lot. I use the source as well. -Vance On Sat, Feb 01, 2003 at 02:01:56AM +0000, steve@REDACTED wrote: } Vance: } } It was obvious to me that the the error message should mean something, but that I needed a magic decoder ring. Is there such a thing? I couldn't find much in the rather extensive documentation available for download. } } I suspect that the error messages are crystal clear to those who really understand Erlang. The rest of us need that magic decoder ring. } } Rgds, } Steve >