From per@REDACTED Sat May 1 21:51:27 1999 From: per@REDACTED (Per Hedeland) Date: Sat, 1 May 1999 21:51:27 +0200 (MET DST) Subject: public key cryptography Message-ID: <199905011951.VAA18342@super.du.etx.ericsson.se> Artur Grabowski wrote: > >lyn writes: > >> Could I distribute that library along with my application (I am a US >> citizen in the US)? > >You can distribute it as much as you want in the US and Canada. But nowhere >else. Well, I'm not a lawyer (either:-), and I think that Lyn should perhaps contact one (or at least tap into the considerable sources of information on these matters available on the net in general) before proceeding - but I believe there are at least two issues relevant to the question (which isn't Erlang-specific, of curse) that Artur didn't mention: 1) I think the US export laws are somewhat more forthcoming in cases where the crypto technology is used solely for authentication, and not for actual encryption of the data transported. You probably still need to apply for and get permission though, which may make the difference academic for a "free" application. 2) Probably more important, as we're talking about public-key technology: RSA, Inc has a patent in the US that covers the RSA algorithms, in fact I believe they claim it covers all public-key technology. This probably means that you can't distribute software that uses such technology even *inside* the US without an agreement with them. I think there is one specific implementation (RSAREF), provided by RSA, that is excluded from the requirement of per-application agreement, but probably has other restrictions on allowable use - I don't know anything about the details of this, though. --Per Hedeland per@REDACTED From Response@REDACTED Fri May 7 20:46:31 1999 From: Response@REDACTED (Response@REDACTED) Date: Fri, 07 May 1999 10:46:31 -0800 Subject: Breakthrough in Swedish Translation ! Message-ID: <199905071744.TAA00615@hades.cslab.ericsson.net> Swedish UTStarGate What the World Has been Waiting For ! Communicate in Swedish, on Web Sites, E-Mail, and documents as easily as English! Full Bi-Directional Translation English to Swedish is as easy and complete as Swedish to English. Complete Grammar support Even complex sentences are translated properly, insuring you the best in global communication! Transparent Web Page Translation Web pages transform from Swedish to English before your eyes, with all formatting and graphics preserved! Multi-Lingual Voice Chat The included IBM ViaVoice Dictation System allows you to dictate in English, directly into a Swedish Chat Room, then they see the Swedish text !! When they type in Swedish, you hear the response in English! Document & E-mail Translation Simply type English into your E-mail, Word Processing, Spreadsheet, or any other document that needs to be translated. With a push of a button, you will have the Swedish! This is truly the world's most advanced package! Special Introductory CD-ROM Offer ! ONLY $189 ! CALL NOW ! 888-837-8887 TOLL FREE ! FREE BONUS PACK ! (While they last) * FREE Voice Dictation Headset (a $39 Value) * FREE IBM ViaVoice Module * FREE E-Mail for Life * FREE Web Page Hosting * FREE Global Instant Messaging * FREE UTStarGate World Net TV * FREE UTStarGate Jukebox W/ MP3 * FREE UTStargate World Radio Player * Full Internet Explorer 5 Functionality * Interchangable 'Skins' to customize your browser * Powered by Universal Translator Level II Special Introductory CD-ROM Offer ! ONLY $189 ! CALL NOW ! 888-837-8887 TOLL FREE ! ---------------------------------------------------------------------- Message Sent Using Aureate Group Mail Free Edition http://www.group-mail.com/ From per@REDACTED Fri May 7 20:25:09 1999 From: per@REDACTED (Per Hedeland) Date: Fri, 7 May 1999 20:25:09 +0200 (MET DST) Subject: Breakthrough in Swedish Translation ! Message-ID: <199905071825.UAA07195@super.du.etx.ericsson.se> Sorry about the spam... - erlang-questions is currently an "open" list, i.e. anyone can send messages to it. It's possible to change this of course, and allow only list members to post, but in my experience it is better to avoid this if possible, as it causes a lot of hassle when people want to send from some address that isn't the one they subscribed with, or want to subscribe a local alias. Of course, if we've managed to get included in some circulated spammer address list we'll have no choice but to implement that restriction - but I suggest that we wait a while and see whether this is a one-time (more or less) thing. --Per Hedeland per@REDACTED From knotwell@REDACTED Sat May 8 01:32:04 1999 From: knotwell@REDACTED (knotwell@REDACTED) Date: Fri, 7 May 1999 16:32:04 -0700 (PDT) Subject: ftp:close and garbage collection In-Reply-To: <371D7E6B.F793F8EF@etxb.ericsson.se> References: <14109.2787.415640.35461@knotwell.f5.com> <371D7E6B.F793F8EF@etxb.ericsson.se> Message-ID: <14131.30708.796049.452659@knotwell.f5.com> Hello all-- A question. . .I wrote a small ftphammer program. When testing the program, I noticed that it ran reasonably well at first but after a short time the performance degraded to unacceptably. Anyhow, using the process monitor, I noticed that ftp connections appeared to stay around after leaving the following function: getData(Host,InFile,OutFile) -> FP = element(2,ftp:open(Host)), ftp:user(FP,"anonymous","knotwell@REDACTED"), case catch ftp:recv(FP,InFile,OutFile) of ok -> ok; Other -> error end. It turned out I needed to do the following (in order to get everything to cleanup okay): getData(Host,InFile,OutFile) -> FP = element(2,ftp:open(Host)), ftp:user(FP,"anonymous","knotwell@REDACTED"), case catch ftp:recv(FP,InFile,OutFile) of ok -> ftp:close(FP), ok; Other -> error end. Assuming that I'm correct in thinking that ftp connections are not finalized automatically, is this: 1) related to Erlang's inability to garbage collect atoms 2) enforcing good practice--making the programmer reclaim allocated resources 3) a bug A small aside: it isn't really clear to me why there should be separate open and user functions. I suppose if your first username/password didn't work and you wanted to try again without forcing the server to spawn another ftpd. Thanks. --Brad From cesarini@REDACTED Sun May 9 23:50:54 1999 From: cesarini@REDACTED (F. Cesarini) Date: Sun, 09 May 1999 23:50:54 +0200 Subject: ftp:close and garbage collection References: <14109.2787.415640.35461@knotwell.f5.com> <371D7E6B.F793F8EF@etxb.ericsson.se> <14131.30708.796049.452659@knotwell.f5.com> Message-ID: <3736033E.9FB35051@csd.uu.se> When you FTP a file from the shell, you have to type bye to end the session. The same probably applies with the module provided. I haven't seen the code, but a process is usually spawned for applications with a similar behavior. By executing MODULE:close/1, you usually terminate the process. MODULE:open or MODULE:start/1 spawns the process. It is probably more efficient to allow the user to use the same process to handle several requests than to spawn a process for every new request. Many users (Processes) could concurrently, if given access to the same FD, use the same process. As you are not using any atoms, that is clearly not the problem. Two comments on your code, if you don't mind. (I am somewhat brain washed from my job, and react whenever I see room for improvement.. :)... {ok, FP} = ftp:open(Host) is much clearer, and will terminate immediately if there was an error in opening a connection to the host. Had {error, Reason} been returned, you would have opened a user session with Reason as a FP, probably causing a crash in the ftp module. The error would thus be harder to detect. I would call ftp:close/1 even if ftp:recv/3 fails should the process still be alive. If a request fails, the resources are probably still allocated. Hope this helps, Francesco > It turned out I needed to do the following (in order to get everything > to cleanup okay): > > getData(Host,InFile,OutFile) -> > FP = element(2,ftp:open(Host)), > ftp:user(FP,"anonymous","knotwell@REDACTED"), > case catch ftp:recv(FP,InFile,OutFile) of > ok -> > ftp:close(FP), > ok; > Other -> error > end. > > Assuming that I'm correct in thinking that ftp connections are not > finalized automatically, is this: > > 1) related to Erlang's inability to garbage collect atoms > 2) enforcing good practice--making the programmer reclaim allocated > resources > 3) a bug > > A small aside: it isn't really clear to me why there should be > separate open and user functions. I suppose if your first > username/password didn't work and you wanted to try again without > forcing the server to spawn another ftpd. > > Thanks. > > --Brad From bjarne@REDACTED Mon May 10 13:49:39 1999 From: bjarne@REDACTED (Bjarne =?iso-8859-1?Q?D=E4cker?=) Date: Mon, 10 May 1999 13:49:39 +0200 Subject: ASTEC Telecom Seminar Message-ID: <3736C7D3.458CBBB3@erix.ericsson.se> Hello The following seminar in Stockholm on May 20 might be of interest: http://www.ericsson.se/cslab/~thomas/conference/ Best regards Bjarne D?cker From markn@REDACTED Fri May 14 07:41:17 1999 From: markn@REDACTED (Mark NG) Date: Fri, 14 May 1999 15:41:17 +1000 Subject: dynamic code replacement Message-ID: <19990514154117.J31221@murlibobo.cs.mu.OZ.AU> G'day ! I was wondering if there are currently any know problems or issues or gotchas with dynamic code replacement under Erlang. thanks, mark From tobbe@REDACTED Fri May 14 08:06:25 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Fri, 14 May 1999 16:06:25 +1000 Subject: dynamic code replacement In-Reply-To: <19990514154117.J31221@murlibobo.cs.mu.OZ.AU> References: <19990514154117.J31221@murlibobo.cs.mu.OZ.AU> Message-ID: <199905140606.QAA01692@universe.serc.rmit.edu.au> > I was wondering if there are currently any know problems or > issues or gotchas with dynamic code replacement under Erlang. No... Well, in the case where you are running a server. Make sure that you make a module prefixed recursive call to the top loop. Example: loop(Data) -> receive X -> NewData = do_stuff(Data,X), ?MODULE:loop(NewData) end. You also have to export (in this case) the loop/1 function. /Tobbe From ulf.wiger@REDACTED Fri May 14 10:21:03 1999 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 14 May 1999 10:21:03 +0200 Subject: dynamic code replacement References: <19990514154117.J31221@murlibobo.cs.mu.OZ.AU> Message-ID: <373BDCEF.515585C4@etxb.ericsson.se> Mark NG wrote: > > G'day ! > > I was wondering if there are currently any know problems or issues or gotchas > with dynamic code replacement under Erlang. > > thanks, > mark Not really any issues in the sense that it wouldn't work Dynamic code replacement can be about as easy or complex as you want/need to make it. The easiest part is simply loading the module. For library code, this is all that's needed. Torbjorn Tornkvist wrote: > Well, in the case where you are running a server. Make sure that > you make a module prefixed recursive call to the top loop. > Example: > > loop(Data) -> > receive > X -> > NewData = do_stuff(Data,X), > ?MODULE:loop(NewData) > end. If your new version has a different representation of Data, this will not work. For this eventuality, OTP provides a framework for performing synchronized code change with hooks for transformation of internal state. A couple of pointers: - If you want to learn about OTP's system messages http://www.erlang.org/doc/doc/index.html (Click on "Design Principles") - If you want to learn about OTP's release handling: http://www.erlang.org/doc/doc/lib/sasl-1.6.3/doc/index.html (see the User's Guide.) /Uffe -- Ulf Wiger, Chief Designer AXD 301 Ericsson Telecom AB tfn: +46 8 719 81 95 Varuv?gen 9, ?lvsj? mob: +46 70 519 81 95 S-126 25 Stockholm, Sweden fax: +46 8 719 43 44 From dineshv@REDACTED Tue May 18 00:31:17 1999 From: dineshv@REDACTED (Dinesh Vadhia) Date: Mon, 17 May 1999 23:31:17 +0100 Subject: Erlang and XML ... Message-ID: <003001bea0b5$f760e600$204995c1@thinkpad> Is there any work being in the XML area by the Erlang folks? ... Thanks ... Dinesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From dineshv@REDACTED Tue May 18 00:30:32 1999 From: dineshv@REDACTED (Dinesh Vadhia) Date: Mon, 17 May 1999 23:30:32 +0100 Subject: Telco and Comco ... Message-ID: <002f01bea0b5$f52f6000$204995c1@thinkpad> Erlang was developed to support telco-based systems ... In the new scheme of things where voice is but another 'data type' in an IP-everything world how does Erlang's philosophy fit into this commco view? ... Dinesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From dineshv@REDACTED Tue May 18 00:26:23 1999 From: dineshv@REDACTED (Dinesh Vadhia) Date: Mon, 17 May 1999 23:26:23 +0100 Subject: Mnesia Questions ... Message-ID: <002e01bea0b5$f3be1cc0$204995c1@thinkpad> I'm from an Oracle background and find Mnesia facinating ... Some questions: ... i How much memory does Mnesia take? ii I realise that the query language is based on List Comprehensions et al ... But how would an Mnesia DBMS application interface with, say, an Oracle database ... ie. SQL interface, ODBC? Dinesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobbe@REDACTED Tue May 18 13:03:49 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Tue, 18 May 1999 21:03:49 +1000 Subject: Telco and Comco ... In-Reply-To: <002f01bea0b5$f52f6000$204995c1@thinkpad> References: <002f01bea0b5$f52f6000$204995c1@thinkpad> Message-ID: <199905181103.VAA18824@universe.serc.rmit.edu.au> > Erlang was developed to support telco-based systems ... In the new = > scheme of things where voice is but another 'data type' in an = > IP-everything world how does Erlang's philosophy fit into this commco = > view? ... Erlang is used to control complex (real-time) systems. So it doesn't really matter what kind of system it is. For example the Ericsson AXD301 ATM switch is controlled by Erlang software. > Is there any work being in the XML area by the Erlang folks? ... Thanks = I think Joe Armstrong has written an XML parser in Erlang. Try, http://www.ericsson.se/cslab/~joe ,or mail Joe directly at: joe@REDACTED I can't answer your question about memory usage for Mnesia (I simply don't know). However, I know there exist a SQL/ODBC interface, perhaps at the User Contrib area of http://www.erlang.org Cheers /Tobbe From klacke@REDACTED Tue May 18 23:42:51 1999 From: klacke@REDACTED (Claes Wikstrom) Date: Tue, 18 May 1999 23:42:51 +0200 Subject: Mnesia Questions ... In-Reply-To: <002e01bea0b5$f3be1cc0$204995c1@thinkpad> (dineshv@email.msn.com) References: <002e01bea0b5$f3be1cc0$204995c1@thinkpad> Message-ID: <199905182142.XAA00961@kaja.bluetail.com> > I'm from an Oracle background and find Mnesia facinating ... Some = > questions: ... > > i How much memory does Mnesia take? It's cool isn't it. Anyway, the memory consumption of mnesia is easily measured, just creat a bunch of tables, populate them, use the info functions in mnesia to see. The only situation where mnesia sucks from a memory consumption perspective is the area of very large transactions. That is a transaction that writes very large amounts of data, particularly if the target tables are replicated. Apart from that, the memory requirement of mnesia are very low. Cheers /klacke From dineshv@REDACTED Tue May 18 07:17:04 1999 From: dineshv@REDACTED (Dinesh Vadhia) Date: Tue, 18 May 1999 06:17:04 +0100 Subject: Symbian ... Message-ID: <000001bea118$b90433e0$995595c1@thinkpad> Do you know if Erlang is being used on the Symbian (Ericsson, Nokia, Psion, Motorola) project? ... Dinesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike@REDACTED Wed May 19 08:52:15 1999 From: mike@REDACTED (Michael C Williams) Date: Wed, 19 May 1999 08:52:15 +0200 (MET DST) Subject: Symbian ... In-Reply-To: <000001bea118$b90433e0$995595c1@thinkpad> Message-ID: No, it isn't being used there. /Mike On Tue, 18 May 1999, Dinesh Vadhia wrote: > Do you know if Erlang is being used on the Symbian (Ericsson, Nokia, Psion, Motorola) project? ... > > Dinesh > > From joe@REDACTED Wed May 19 10:24:19 1999 From: joe@REDACTED (Joe Armstrong) Date: Wed, 19 May 1999 10:24:19 +0200 Subject: Erlang and XML ... References: <003001bea0b5$f760e600$204995c1@thinkpad> Message-ID: <37427533.866B2D01@bluetail.com> Dinesh Vadhia wrote: > Is there any work being in the XML area by the Erlang folks? ... > Thanks ... Dinesh I wrote a little XML parser http://www.ericsson.se/cslab/~joe/xml/xml.html This is actually a verifying parser (1378 lines of code!) - It doesn't do unicode or handle the ANY tag. To make a real XML parser I think the correct way to go would be to use expat as a front end (to do the lexical stuff) and then add the parrsing and sunsequent verification in Erlang - volunteers? /Joe From luke@REDACTED Wed May 19 10:47:31 1999 From: luke@REDACTED (Luke Gorrie) Date: 19 May 1999 18:47:31 +1000 Subject: Erlang and XML ... In-Reply-To: Joe Armstrong's message of "Wed, 19 May 1999 10:24:19 +0200" References: <003001bea0b5$f760e600$204995c1@thinkpad> <37427533.866B2D01@bluetail.com> Message-ID: Joe Armstrong writes: > This is actually a verifying parser (1378 lines of code!) - It doesn't > do unicode or > handle the ANY tag. To make a real XML parser I think the correct way to > > go would be to use expat as a front end (to do the lexical stuff) and > then > add the parrsing and sunsequent verification in Erlang - volunteers? Speaking of lexical stuff, I've seen references to a lexer called "leex" around, but I haven't found the actual software. Is it around and usable somewhere? -- "The Commando Pattern is used to get in and out quick, and get the job done. This pattern can break any encapsulation to accomplish its mission. It takes no prisoners." - Michael Duell ("Resign Patterns") From jhague@REDACTED Thu May 20 18:33:42 1999 From: jhague@REDACTED (James Hague) Date: Thu, 20 May 1999 11:33:42 -0500 (CDT) Subject: Can messages be sent to processes interactively? Message-ID: I've been doing a lot of sequential programming in Erlang, but have just started getting into concurrency. It seems very obvious and straightforward. I wrote a quickie test process so I can start it up and send messages to it interactively, just so I know that all is well: -module(sample). -export([start/0]). start() -> spawn(sample, server, []). server() -> receive stop -> ok; Msg -> io:fwrite("message received: ~w\n", [Msg]), server(N) end. This compiles just fine, and I can start the process from the Erlang prompt with P = sample:start(), which results in a valid pid. "P ! 1." from the command line, though, doesn't result in any fwrite output, though. process_info(P) returns an atom of 'undefined'. Is it not possible to do this sort of thing interactively? I've only tried this using JAM under Windows. I haven't tried it with BEAM on my Linux box yet. James From jhague@REDACTED Thu May 20 19:06:31 1999 From: jhague@REDACTED (James Hague) Date: Thu, 20 May 1999 12:06:31 -0500 (CDT) Subject: Can messages be sent to processes interactively? In-Reply-To: Message-ID: > server(N) ^ Dumb typo when I simplified the code for posting. That doesn't have any effect on my question. James From crd@REDACTED Thu May 20 20:11:21 1999 From: crd@REDACTED (Craig Dickson) Date: Thu, 20 May 1999 11:11:21 -0700 Subject: Can messages be sent to processes interactively? References: Message-ID: <017701bea2ec$2cd9b7c0$6e02a8c0@int2.inversenet.com> James Hague wrote: > I wrote a quickie test process so I can start it up and send messages to > it interactively, just so I know that all is well: > > -module(sample). > -export([start/0]). > > start() -> spawn(sample, server, []). > > server() -> > receive > stop -> ok; > Msg -> > io:fwrite("message received: ~w\n", [Msg]), > server(N) > end. > > This compiles just fine No, it doesn't. Variable N is unbound, and no function server/1 is defined. Furthermore, since you didn't export server/0, you can't spawn it. If you really want to be sure (interactively) that your process has started, have it output something when it starts up. This ought to compile and work as you expect: --- cut here --- -module(sample). -export([start/0, server/0]). start() -> spawn(?MODULE, server, []). server() -> io:fwrite("server started\n"), receive stop -> io:fwrite("server stopping\n"), ok; Msg -> io:fwrite("message received: ~w\n", [Msg]) end. --- cut here --- You should find that you can send messages to this server from the Erlang shell. Craig From crd@REDACTED Thu May 20 20:25:38 1999 From: crd@REDACTED (Craig Dickson) Date: Thu, 20 May 1999 11:25:38 -0700 Subject: Can messages be sent to processes interactively? References: Message-ID: <019001bea2ee$2be50ca0$6e02a8c0@int2.inversenet.com> James Hague wrote: > > server(N) > ^ > Dumb typo when I simplified the code for posting. That doesn't have any > effect on my question. Well, it does, in a way, since it means the code won't even compile, much less work. Most readers will probably stop at that point, and fail to notice the more subtle problem that you didn't export server/0, which I think is what caused your original code (pre-simplification) to not work. (Unless that's another thing that got messed up in your "simplification", in which case you probably left out the real problem altogether, since the simplified code behaves as expected once the export and the server(N) are corrected.) Moral: always test your simplified example before mailing it out! Craig From jhague@REDACTED Thu May 20 20:47:38 1999 From: jhague@REDACTED (James Hague) Date: Thu, 20 May 1999 13:47:38 -0500 (CDT) Subject: Can messages be sent to processes interactively? In-Reply-To: <019001bea2ee$2be50ca0$6e02a8c0@int2.inversenet.com> Message-ID: Craig Dickson wrote: > >Well, it does, in a way, since it means the code won't even compile, much >less work. Most readers will probably stop at that point, and fail to notice >the more subtle problem that you didn't export server/0, which I think is >what caused your original code (pre-simplification) to not work. (Unless >that's another thing that got messed up in your "simplification", in which >case you probably left out the real problem altogether, I agree, I should have made sure my code still compiled after deleting that one parameter. And I knew, as soon as I sent the mail, that I'd get a response like this. Ten years of Usenet makes one good at predicting human nature :) Yes, I did not realize that server functions always need to be exported. I see now that spawm() always returns a pid even when the arguments are nonsensical: spawn(mud, mud, []). But everything works fine now and I'm happily writing concurrent code. All the best, James From crd@REDACTED Thu May 20 22:34:56 1999 From: crd@REDACTED (Craig Dickson) Date: Thu, 20 May 1999 13:34:56 -0700 Subject: Can messages be sent to processes interactively? References: Message-ID: <01ab01bea300$3c490b20$6e02a8c0@int2.inversenet.com> James Hague wrote: > And I knew, as soon as I sent the mail, that I'd get > a response like this. Ten years of Usenet makes one good at predicting > human nature :) I'm not quite sure what you mean. From my own ten years or so of Usenet, I expect almost any public online discussion to be periodically interrupted by mad flamers, so your statement leads me to wonder if you interpreted something in my reply as being of that nature. If so, then I apologize; it wasn't meant harshly. Craig From jhague@REDACTED Thu May 20 22:40:14 1999 From: jhague@REDACTED (James Hague) Date: Thu, 20 May 1999 15:40:14 -0500 (CDT) Subject: Can messages be sent to processes interactively? In-Reply-To: <01ab01bea300$3c490b20$6e02a8c0@int2.inversenet.com> Message-ID: Craig Dickson wrote: > > I'm not quite sure what you mean. From my own ten years or so of Usenet, I > expect almost any public online discussion to be periodically interrupted by > mad flamers, so your statement leads me to wonder if you interpreted > something in my reply as being of that nature. If so, then I apologize; it > wasn't meant harshly. No, no, no, I didn't interpret it as harsh. I'm just sensitive to what I see as "predictable" reactions. If someone posted "I'm writing a spreadsheet in Pascal for xwindows and I'm looking GUI library recommendations," you just *know* somebody is going to respond with "You should use C, not Pascal!" And so on. I was very hesitant to post any code, because I expected to get flak for indentation style or lack of comments or variable naming conventions, or a dumb typo. I made the latter, unfortunately! Being able to see through such "mistakes" is a good thing. But, as I'll freely admit, my typo did muddle the question somewhat. Thanks for the help. Erlang is the most (programming-related) fun I've had in a long while. And if the "Concurrent Programming in Erlang" authors are reading this--great job! It's a great read (and thankfully, not as oversized as most language introductions). James From tobbe@REDACTED Fri May 21 02:06:00 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Fri, 21 May 1999 10:06:00 +1000 Subject: Can messages be sent to processes interactively? In-Reply-To: References: Message-ID: <199905210006.KAA18477@universe.serc.rmit.edu.au> > Yes, I did not realize that server functions always need to be exported. I > see now that spawm() always returns a pid even when the arguments are > nonsensical: spawn(mud, mud, []). But everything works fine now and I'm > happily writing concurrent code. A little helpful comment here: Think of spawn/3 as: 1. Create a new (empty) erlang process. 2. Perform an apply/3 in the new process. To be able to do the apply/3 you have to export the M:F/A. Another little comment: It is very instructive to make use of the debugger, especially when you write concurrent code. To use it do the following from your erlang shell prompt; 1> ii(YOUR-MUDULE-NAME). 2> iaa(init). 3> YOUR-MODULE-NAME:foo(....). A window will now pop-up the first time you execute the debugged (interpreted) code. From here: singe-step, inspect variables, etc... Another useful command is: im(). It will bring up a monitor window displaying all processes currently being debugged. Attach yourself to a process by double-click on one of the lines (in the displayed matrix) representing the process. Finally: ib(YOUR-MODULE-NAME, LINE-NO). Sets a break point in a module. By using: iaa(break) the window will now pop-up when you hit the break point. All of this can of course be done from the menues of the monitor window, but the command interface I have showed here is much faster and easier to use (IMHO... ;-). /Tobbe From joe@REDACTED Fri May 21 10:15:36 1999 From: joe@REDACTED (Joe Armstrong) Date: Fri, 21 May 1999 10:15:36 +0200 Subject: Can messages be sent to processes interactively? References: <017701bea2ec$2cd9b7c0$6e02a8c0@int2.inversenet.com> Message-ID: <37451628.C112EB4B@bluetail.com> Craig Dickson wrote: > James Hague wrote: > > > I wrote a quickie test process so I can start it up and send messages to > > it interactively, just so I know that all is well: > > > > -module(sample). > > -export([start/0]). > > > > start() -> spawn(sample, server, []). > > > > server() -> > > receive > > stop -> ok; > > Msg -> > > io:fwrite("message received: ~w\n", [Msg]), > > server(N) > > end. > > > > This compiles just fine > > No, it doesn't. Variable N is unbound, and no function server/1 is defined. > Furthermore, since you didn't export server/0, you can't spawn it. > > If you really want to be sure (interactively) that your process has started, > have it output something when it starts up. > > This ought to compile and work as you expect: > > --- cut here --- > -module(sample). > > -export([start/0, server/0]). > > start() -> spawn(?MODULE, server, []). > > server() -> > io:fwrite("server started\n"), > receive > stop -> io:fwrite("server stopping\n"), ok; > Msg -> io:fwrite("message received: ~w\n", [Msg]) > end. > --- cut here --- > > You should find that you can send messages to this server from the Erlang > shell. > > Craig Right - but I think I should not point out the difference between spawn and spawn_link Suppose I write the following: -module(sample). -export([start/0, server/0]). start() -> spawn_link(sample, server, []). server() -> receive stop -> ok; Msg -> 1 = 2, server() end. This contains a deliberate error but it won't be reported 1> P=sample:start(). <0.30.0> 2> P!a 2> . a 3> P!2. 2 The process died but we saw nothing. P is still a process reference but it point to crap. P!2 etc. succeeds. (X!Y has send and pray semantics :-) Now change spawn to spawn_link. "spawn_link" says spawn the process and link to it for error handling purposes. Deliver an exit message if something goes wrong. so ... 1> P=sample:start(). <0.30.0> 2> P!1. 1 =ERROR REPORT==== 21-May-1999::10:09:00 === <0.30.0> error: {badmatch,2} in sample:server/0 ** exited: {{badmatch,2},{sample,server,0}} ** 3> P!2. 2 4> process_info(P). undefined 5> Line 1> caused the spawned process to be linked to the shell process. Line 2> Sends a message to P. The process crashes with a badmatch error (i.e. 1 cannot be 2) Because it is linked to the shell an exit message is sent to the shell. The shell has a handler which prints the value of the exit signal. Line 3> succeeds. P is still a reference to a proceess but the process is not dead so P ! 2 succeeds Line 4> you can inspect the "state" of P - it is of course, dead. It's often a good idea to use spawn_link and lot and spawn sparingly if you're a beginner That way you get the default error handling mechanisms - gurus would probably use spawn a lot and spawn_link sparingly and make their own error handling mechanisms. /Joe From hakan@REDACTED Fri May 21 14:26:27 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 21 May 1999 14:26:27 +0200 (MET DST) Subject: Mnesia Questions ... In-Reply-To: <199905182142.XAA00961@kaja.bluetail.com> Message-ID: On Tue, 18 May 1999, Claes Wikstrom wrote: klacke>It's cool isn't it. Anyway, the memory consumption klacke>of mnesia is easily measured, just creat a bunch of tables, populate klacke>them, use the info functions in mnesia to see. The info functions in Mnesia does not give the whole picture. Currently you will only get the memory consumption of the main tables and not the size of Mnesia's internal processes, indecies, snmp-structures, checkpoints etc. Of course it is possible to measure the total memory consumption of Mnesia, but it is a little bit complicated. Measuring the size of thethe entire Erlang emulator process is a rough method but it easy to perform it. klacke>The only situation where mnesia sucks from a memory consumption klacke>perspective is the area of very large transactions. klacke> klacke>That is a transaction that writes very large amounts of data, particularly klacke>if the target tables are replicated. One thing that may be worth to point out, is that many users relies on Mnesia's ability to automatically acquire locks. This works well in most cases, but if you in one transaction are accessing lots of records in the same table both performance and memory consumption will benifit a lot by explicit acquisition of table locks. If the transcation is nested the benefit will even be greater. /H?kan From hakan@REDACTED Fri May 21 15:31:48 1999 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 21 May 1999 15:31:48 +0200 (MET DST) Subject: Telco and Comco ... In-Reply-To: <199905181103.VAA18824@universe.serc.rmit.edu.au> Message-ID: On Tue, 18 May 1999, Torbjorn Tornkvist wrote: tobbe>I can't answer your question about memory usage for Mnesia tobbe>(I simply don't know). However, I know there exist a SQL/ODBC tobbe>interface, perhaps at the User Contrib area of http://www.erlang.org I assume that Tobbe refers to one of the earlier Master thesis works that has been done. One implemented an Erlang binding to Oracle and another implemented a SQL frontend for Mnesia. But none of these has reached product quality. Perhaps, there are some volunteers out there that want to finish the SQL frontend for Mnesia? Anyway, in OTP R5, an Erlang binding for ODBC was released in the commercial variant of Erlang/OTP. This new ODBC binding enables Erlang applications to access a wide range of SQL databases. I think that the intention is to release it as Open Source, but I do not know how soon that it will be done. /H?kan From crd@REDACTED Fri May 21 15:34:29 1999 From: crd@REDACTED (Craig Dickson) Date: Fri, 21 May 1999 06:34:29 -0700 Subject: Can messages be sent to processes interactively? References: <017701bea2ec$2cd9b7c0$6e02a8c0@int2.inversenet.com> <37451628.C112EB4B@bluetail.com> Message-ID: <01cc01bea38e$a9bef460$6e02a8c0@int2.inversenet.com> Joe Armstrong wrote: > It's often a good idea to use spawn_link and lot and spawn sparingly if > you're a beginner > That way you get the default error handling mechanisms - gurus would > probably use spawn a lot and spawn_link sparingly and make their own error > handling mechanisms. I thought spawn_link together with exit trapping was pretty much the best way to deal with failures in worker processes. Would a real Erlang guru do something different? If so, what? Craig From jhague@REDACTED Fri May 21 15:48:53 1999 From: jhague@REDACTED (James Hague) Date: Fri, 21 May 1999 08:48:53 -0500 (CDT) Subject: Relative efficiency of external interfacing methods In-Reply-To: <01cc01bea38e$a9bef460$6e02a8c0@int2.inversenet.com> Message-ID: I'm writing some external C routines to be called from Erlang. I'll be calling these routines a good many times per second. Each call will only contain a small amount of data--three or four integers. Is there any significant performance difference between using ports and the newer, more direct method? James From mbjk@REDACTED Fri May 21 21:11:18 1999 From: mbjk@REDACTED (Martin Bjorklund) Date: Fri, 21 May 1999 15:11:18 -0400 Subject: Can messages be sent to processes interactively? In-Reply-To: Your message of "Fri, 21 May 1999 06:34:29 -0700" <01cc01bea38e$a9bef460$6e02a8c0@int2.inversenet.com> References: <01cc01bea38e$a9bef460$6e02a8c0@int2.inversenet.com> Message-ID: <19990521151118K.mbjk@eecs.umich.edu> "Craig Dickson" wrote: > > I thought spawn_link together with exit trapping was pretty much the best > way to deal with failures in worker processes. Would a real Erlang guru do > something different? If so, what? Take a look at the functions in the module proc_lib. The functions proc_lib:spawn and spawn_link are as the BIFs, but creates a crash report, should the new process crash. There are also two functions start & start_link, which are synchronous - they return when the new process has been started and initialized. All system processes use these functions (most of them use proc_lib:start_link indirectly via gen_server:start_link). To see the crash reports, statr erlang as: erl -boot start_sasl -sasl errlog_type error (see sasl(6) for details about errlog_type) /martin From klacke@REDACTED Fri May 21 22:32:35 1999 From: klacke@REDACTED (Claes Wikstrom) Date: Fri, 21 May 1999 22:32:35 +0200 Subject: Can messages be sent to processes interactively? In-Reply-To: (message from James Hague on Thu, 20 May 1999 11:33:42 -0500 (CDT)) References: Message-ID: <199905212032.WAA03336@kaja.bluetail.com> > start() -> spawn(sample, server, []). > > server() -> > receive > stop -> ok; > Msg -> > io:fwrite("message received: ~w\n", [Msg]), > server(N) > end. > > This compiles just fine, and I can start the process from the Erlang > prompt with P = sample:start(), which results in a valid pid. "P ! 1." > from the command line, though, doesn't result in any fwrite output, > though. process_info(P) returns an atom of 'undefined'. > One little error there, the call > server(N) calls a function (called "server") with 1 (one) argument in the local module. Nu such function exists, thus the process will exit. Since the process has no links to any other processes it will silently exit, thus the > process_info(P) returns an atom of 'undefined'. So, change > server(N) to server() and you'll be on your way Cheers /klacke From klacke@REDACTED Fri May 21 22:53:24 1999 From: klacke@REDACTED (Claes Wikstrom) Date: Fri, 21 May 1999 22:53:24 +0200 Subject: Can messages be sent to processes interactively? In-Reply-To: (message from James Hague on Thu, 20 May 1999 11:33:42 -0500 (CDT)) References: Message-ID: <199905212053.WAA03807@kaja.bluetail.com> > > I've been doing a lot of sequential programming in Erlang, but have just > started getting into concurrency. It seems very obvious and > straightforward. > > I wrote a quickie test process so I can start it up and send messages to > it interactively, just so I know that all is well: > > -module(sample). > -export([start/0]). > > start() -> spawn(sample, server, []). > > server() -> > receive > stop -> ok; > Msg -> > io:fwrite("message received: ~w\n", [Msg]), > server(N) > end. > And yet another little error, there is no function called sample:server/0 nor sample:server/1 *exported* from the module. It might seem pretty idiotic that any function that is spawned need to be exported but that is the way it is. (applies to apply/3 too !!!) So, change > -export([start/0]). to -export([start/0, server/0]). Personally I like the -compile(export_all) switch while I'm developing, this way I need not bother about that at that stage. Cheers /klacke PS. There's a bit of one of my favourite topics in here -- namely software archeology. Why is it like this. The obvious thing would be to spawn a fun instead of a tripple M:F/A start() -> spawn(fun() -> server() end). ???? From klacke@REDACTED Sat May 22 00:21:33 1999 From: klacke@REDACTED (Claes Wikstrom) Date: Sat, 22 May 1999 00:21:33 +0200 Subject: Relative efficiency of external interfacing methods In-Reply-To: (message from James Hague on Fri, 21 May 1999 08:48:53 -0500 (CDT)) References: Message-ID: <199905212221.AAA05918@kaja.bluetail.com> > > Is there any significant performance difference between using ports > and the newer, more direct method? > What do you mean by "newer, more direct method" ?? /klacke From markn@REDACTED Sat May 22 03:12:22 1999 From: markn@REDACTED (Mark NG) Date: Sat, 22 May 1999 11:12:22 +1000 Subject: Relative efficiency of external interfacing methods In-Reply-To: <199905212221.AAA05918@kaja.bluetail.com>; from Claes Wikstrom on Sat, May 22, 1999 at 12:21:33AM +0200 References: <199905212221.AAA05918@kaja.bluetail.com> Message-ID: <19990522111221.C2621@murlibobo.cs.mu.OZ.AU> On Sat, May 22, 1999 at 12:21:33AM +0200, Claes Wikstrom wrote: > > > > > Is there any significant performance difference between using ports > > and the newer, more direct method? > > > > > What do you mean by "newer, more direct method" ?? > he probally meant the dynamic share library version, a linked in driver. :) Speaking of the C interface, what are the plans for IG ? At the moment it seems to rather limited, no handling of preprocessor directives like #ifdef, #include.. forward typedefs etc.. but it is very niffy for simpler Erlang to C calls. :) mark From ulf.wiger@REDACTED Sat May 22 18:55:00 1999 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sat, 22 May 1999 18:55:00 +0200 Subject: Mnesia Questions ... References: Message-ID: <3746E164.D7D5F209@etxb.ericsson.se> Hakan Mattsson wrote: > > Measuring the size of > thethe entire Erlang emulator process is a rough method but it easy to > perform it. Ah, but remember that what you will get then is roughly the all-time high, at least on Solaris. On Solaris, you will never see the Erlang emulator shrink, and the reported memory consumption will most likely reflect how much was needed during some transient work. Here's one way to get a feeling for how much memory is actually being used: 1> io:format("~s~n", [binary_to_list(erlang:info(info))]). -------------------------------------------------- Hash Table(atom_tab), size(2411), used(1720), objs(2974), depth(7) Index Table(atom_tab), size(3000), limit(65536), used(2974), rate(100) Atom space 27736/32772 Hash Table(module_code), size(47), used(37), objs(64), depth(4) Index Table(module_code), size(70), limit(65536), used(64), rate(10) Hash Table(export_list), size(1201), used(862), objs(1474), depth(6) Index Table(export_list), size(1500), limit(65536), used(1474), rate(100) Hash Table(process_reg), size(23), used(14), objs(18), depth(3) Allocated binary 108361 Allocated by process_desc 11200 Allocated by proc_bin_desc 400 Allocated by table_desc 1120 Allocated by link_desc 2000 Allocated by atom_desc 59600 Allocated by export_desc 53280 Allocated by module_desc 2560 Allocated by preg_desc 320 -------------------------------------------------- /Uffe -- Ulf Wiger, Chief Designer AXD 301 Ericsson Telecom AB tfn: +46 8 719 81 95 Varuv?gen 9, ?lvsj? mob: +46 70 519 81 95 S-126 25 Stockholm, Sweden fax: +46 8 719 43 44 From klacke@REDACTED Sat May 22 20:44:08 1999 From: klacke@REDACTED (Claes Wikstrom) Date: Sat, 22 May 1999 20:44:08 +0200 Subject: Relative efficiency of external interfacing methods In-Reply-To: <19990522111221.C2621@murlibobo.cs.mu.OZ.AU> (message from Mark NG on Sat, 22 May 1999 11:12:22 +1000) References: <199905212221.AAA05918@kaja.bluetail.com> <19990522111221.C2621@murlibobo.cs.mu.OZ.AU> Message-ID: <199905221844.UAA00486@kaja.bluetail.com> > > On Sat, May 22, 1999 at 12:21:33AM +0200, Claes Wikstrom wrote: > > > > > > > > Is there any significant performance difference between using ports > > > and the newer, more direct method? > > > > > > > > > What do you mean by "newer, more direct method" ?? > > > > he probally meant the dynamic share library version, a linked in driver. :) > In that case the difference in performance between calling a c-func in a linked driver versus calling a c-func in another os process is enormous. It of cource depends on the underlying OS, but on unix'es it's high and on win32 it's extremely++ high. The advantage of a linked-in driver is speed, the disadvantages are the difficulties that are associated with running together with the erlang runtime system. No blocking syscalls etc. > > Speaking of the C interface, what are the plans for IG ? Yes, I'd like to know too ?? /klacke From tobbe@REDACTED Sun May 23 01:41:20 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Sun, 23 May 1999 09:41:20 +1000 Subject: IG (was: Re: Relative efficiency of external interfacing methods ) In-Reply-To: <19990522111221.C2621@murlibobo.cs.mu.OZ.AU> References: <199905212221.AAA05918@kaja.bluetail.com> <19990522111221.C2621@murlibobo.cs.mu.OZ.AU> Message-ID: <199905222341.JAA23201@universe.serc.rmit.edu.au> > Speaking of the C interface, what are the plans for IG ? > At the moment it seems to rather limited, no handling of > preprocessor directives like #ifdef, #include.. forward > typedefs etc.. but it is very niffy for simpler > Erlang to C calls. :) IG is obsoleted and replaced by IC. However, I'm maintaining it unofficially, and added a little enhancement recently (see the GDC example in the User Contrib area). I've also put the original documentation at: http://www.serc.rmit.edu.au/~tobbe/ig.html NB: The syntax has changed a bit since then. Also this doc. was written before SASL existed. However, it contains much more examples than the current doc. If someone want to improve IG then feel free to do so. /Tobbe From jhague@REDACTED Mon May 24 04:11:55 1999 From: jhague@REDACTED (James Hague) Date: Sun, 23 May 99 21:11:55 -0500 Subject: Relative efficiency of external interfacing methods Message-ID: <199905240114.UAA22988@babba.advancenet.net> > > What do you mean by "newer, more direct method" ?? > > > > he probally meant the dynamic share library version, a linked in driver. :) Actually, I was under the mistaken assumption that IG used a different method than ports, but I now see that they are exactly the same thing. >The advantage of a linked-in driver is speed, the disadvantages are >the difficulties that are associated with running together with >the erlang runtime system. No blocking syscalls etc. I've been considering trying this, because I think it would be interesting. Are there any good examples? (There's probably at least one in the documentation, but I haven't come across it yet :) From tobbe@REDACTED Mon May 24 05:07:53 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Mon, 24 May 1999 13:07:53 +1000 Subject: Relative efficiency of external interfacing methods In-Reply-To: <199905240114.UAA22988@babba.advancenet.net> References: <199905240114.UAA22988@babba.advancenet.net> Message-ID: <199905240307.NAA24569@universe.serc.rmit.edu.au> > I've been considering trying this, because I think it would be > interesting. Are there any good examples? (There's probably at least > one in the documentation, but I haven't come across it yet :) There is a very simple example in the User Contrib area named: byteorder-1.0 Also: check out the device driver Appendix in the book. /Tobbe From jhague@REDACTED Tue May 25 15:49:30 1999 From: jhague@REDACTED (James Hague) Date: Tue, 25 May 1999 08:49:30 -0500 (CDT) Subject: Erlang status questions Message-ID: A couple of status questions: 1. When is the next Open Source Erlang release planned for? It would be nice to have the system be generally more re-compilable. It also seems that the Open Source version is a couple of revisions behind what Ericsson uses internally. 2. How have the native code generation groups been progessing? The HIPE page (not maintained by Ericsson, I realize) is getting a bit stale. With native code generation, Erlang would be completely unstoppable, IMO :) James From gandalf@REDACTED Tue May 25 22:57:01 1999 From: gandalf@REDACTED (Vladimir Ulogov) Date: Tue, 25 May 1999 16:57:01 -0400 (EDT) Subject: How to send and receive messages using ERTS. Message-ID: Hello, I'm having questions related with some ERTS issues: 1) Where I can find a sample, how to handle ErlMessage and receive information from them. As sample, if I'm expecting to receive something like {pid, atom, number, sting}, how to extract pid, atom, number and string from the ErlMessage. 2) At the time, as I wants to create pid using SELF(sockfd) macros (from the 1.2 Erl_Interface library). What is sockfd? Which socket file descriptor I should use if I wants to send messages like {sender pid, atom, number, string} from C program. 3) How to return messages to C program, which invokes erl_receive_msg. Which operations I should perform before erl_receive_msg ? Thank you for assistance . ======================================================= Vladimir I. Ulogov (gandalf@REDACTED) tel: 973-236-6464 or 6463 fax: 973-236-2090 "Where lands meets water. Where earth meets air. Where body meets mind. Where space meets time. We like to be on one side, and look at the other." D.Adams "Mostly harmless" From tobbe@REDACTED Wed May 26 05:00:35 1999 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Wed, 26 May 1999 13:00:35 +1000 Subject: How to send and receive messages using ERTS. In-Reply-To: References: Message-ID: <199905260300.NAA14156@universe.serc.rmit.edu.au> Hi ! I assume you have read the erl_interface User's Manual (and the Reference Manuals) ? If not, here are some examples: > 1) Where I can find a sample, how to handle ErlMessage and receive > information from them. As sample, if I'm expecting to receive something > like {pid, atom, number, sting}, how to extract pid, atom, number and > string from the ErlMessage. ETERM *arr[2], *msg; int sockfd,rc; char buf[BUFSIZE]; ErlMessage emsg; ....stuff here.... if ((rc = erl_receive_msg(sockfd , buf, BUFSIZE, &emsg)) == ERL_MSG) { ETERM *pid,*atom,*number,*string; msg = erl_decode_buf(bufp); if (ERL_IS_TUPLE(msg) & (ERL_TUPLE_SIZE(msg) == 4)) { /* NOTE!!! This is 0-based!! (first item is number 0) * Note too that element/2 (in Erlang) and * erl_element() are both 1-based. */ pid = ERL_TUPLE_ELEMENT(msg, 0); atom = ERL_TUPLE_ELEMENT(msg, 1); number = ERL_TUPLE_ELEMENT(msg, 2); string = ERL_TUPLE_ELEMENT(msg, 3); ....etc..... } ....etc.... } (NB: ERL_TUPLE_ELEMENT(x, i) doesn't seem to be documented. You'll find it in the erl_eterm.h header file though...) > 2) At the time, as I wants to create pid using SELF(sockfd) macros (from > the 1.2 Erl_Interface library). What is sockfd? Which socket file > descriptor I should use if I wants to send messages like {sender pid, > atom, number, string} from C program. 'sockfd' is the filedescriptor you get from erl_connect() Example: int sockfd; char *nodename="xyz@REDACTED"; /* An example */ if ((sockfd = erl_connect(nodename)) < 0) erl_err_quit("ERROR: erl_connect failed"); > 3) How to return messages to C program, which invokes erl_receive_msg. You mean from Erlang ? In your C program you create your own Pid using the SELF() macro. This Pid, has to be included in the message you send to Erlang. The Erlang side can then use it to return a message. It may be easier to use erl_rpc() instead. See for example, how erl_rpc() is used in erl_call.c . > Which operations I should perform before erl_receive_msg ? See the User's Manual. Basically you need to call erl_init() and erl_connect() before you can receive anything, but again to receive something asynchronous on your C-side, Erlang needs to know the Pid (NB: C-nodes doesn't show up in the result from the nodes/0 BIF), so you probably need to send (at least) your Pid to Erlang (using erl_send() ) before you can expect to receive anything on the C-side. Good luck ! /Tobbe From "mickael_remond"@REDACTED Wed May 26 14:59:19 1999 From: "mickael_remond"@REDACTED ("mickael_remond"@REDACTED) Date: Wed, 26 May 1999 14:59:19 +0200 Subject: Socket libraries question. Message-ID: I am trying to create a socket application working both on Linux and Windows. I found that the way of receving packet is not the same under Linux or under Windows. I am using the {packet, 0} option. Under Linux, the program seems to be waiting for a carriage return before receiving. Under Windows, the program is receiving and answer after each key pressed. What am I missing ? Is there a standard socket comportement for receiving the packets only on carriage return (for example, each time the enter key is pressed under telnet). Thanks in advance. Mickael Remond From per@REDACTED Wed May 26 15:49:27 1999 From: per@REDACTED (Per Hedeland) Date: Wed, 26 May 1999 15:49:27 +0200 (MET DST) Subject: Socket libraries question. Message-ID: <199905261349.PAA24522@aalborg.du.etx.ericsson.se> Mickael Remond wrote: >I am trying to create a socket application working both on Linux and >Windows. > >I found that the way of receving packet is not the same under Linux or >under Windows. I am using the {packet, 0} option. > >Under Linux, the program seems to be waiting for a carriage return before >receiving. Under Windows, the program is receiving and answer after each >key pressed. > >What am I missing ? Well, what *I* am missing is a description of how the characters get from your keyboard to the socket.:-) Sockets don't generally care about carriage returns and such things, ttys do. >Is there a standard socket comportement for receiving the packets only on >carriage return (for example, each time the enter key is pressed under >telnet). OK, I assume that you've written a TCP server in Erlang, that is accepting connections on some port, and then connect to it using the standard 'telnet' client of the respective OS - in that case, the difference you're seeing is entirely due to the different behaviour of the respective telnet clients. The telnet protocol allows for a variety of different characteristics for the client/server communication, in particular "character mode" vs "line mode" - in the former case, the client sends character-by-character to the server, which is responsible for echo, line editing etc, whereas in the latter the client does the echo/editing, and sends only complete lines to the server. If the client connects to an actual telnet server (i.e. something that speaks the telnet protocol), these things are negotiated, usually ending up with "character mode" being chosen, as that is most useful with respect to the actual applications being run "behind" the telnet server. If the client connects to something that isn't a telnet server, there can be no such negotiation of course, and the client has to make an "intelligent" choice of its own - and of course the Unix telnet client is more intelligent than the Windows one:-), chosing line mode rather than character mode in this case, since this makes it much easier to "talk" to whatever strange thing is at the other end (e.g. an SMTP server, or an Erlang program:-) - you see what you type, can use delete/backspace to correct typing errors etc. That being said, most telnet clients allow you to change these modes manually - with the typical Unix client, you type the escape character (normally ctrl-]), and can then tell the client to change mode with something like 'mode character' or 'mode line'. I assume (perhaps optimistically:-) that you can do this with the standard Windows client too, but I wouldn't know how - in any case it can't be fixed by the Erlang program at the other end, unless it actually speaks the telnet protocol (which is probably not what you wanted it to do:-). Bottom line: Your Erlang server will get the data from the socket in whatever batches the client decides to send them (more or less - depending on timing, data volume etc e.g. multiple packets may be received as one chunk of data - TCP doesn't preserve packet boundaries). --Per Hedeland per@REDACTED From john@REDACTED Thu May 27 20:55:17 1999 From: john@REDACTED (John Totten) Date: Thu, 27 May 1999 10:55:17 -0800 Subject: IVR Message-ID: <374D9515.89F0AD96@totten.com> Has anyone ever done IVR with Erlang? John Totten From seb@REDACTED Mon May 31 01:14:40 1999 From: seb@REDACTED (Sebastian Strollo) Date: 31 May 1999 01:14:40 +0200 Subject: Erlang status questions In-Reply-To: James Hague's message of "Tue, 25 May 1999 08:49:30 -0500 (CDT)" References: Message-ID: James Hague writes: > > 1. When is the next Open Source Erlang release planned for? It > would be I hope to have one out by the end of this week... > nice to have the system be generally more re-compilable. It also > seems ...although it will not help you there, sorry. It will be a minor release consisting of a bunch of patches and a newer version of mnesia. > that the Open Source version is a couple of revisions behind what Ericsson > uses internally. Yes, this is true. The *only* reason for this right now is that we had to make a branch from the main production source when we went ahead and released the open source release. At the same time development proceeded in the main production branch. Right now we are working hard to make sure that in the future we will make the main release the same as the open source release. The aim right now is to make the next major product release (beginning of November) this new unified source release. This is an exciting project from an open source perspective, a lot more so than say e.g. Netscape, which IMO made a mistake by spawning of the open source version as a separate project. I think we will be in a much better position to make an impact when we have a unified source code. I also hope all of you will bare with us until we are there, unfortunately there are not many people working on the current open source release (everyone is busy with the exciting work for what's coming :-) > 2. How have the native code generation groups been progessing? The HIPE > page (not maintained by Ericsson, I realize) is getting a bit stale. With > native code generation, Erlang would be completely unstoppable, IMO > :) Sorry I don't know anything about how HIPE is doing. Anyone else? -- Sebastian