From spearce@REDACTED Mon Mar 1 15:03:02 2004 From: spearce@REDACTED (Shawn Pearce) Date: Mon, 1 Mar 2004 09:03:02 -0500 Subject: running linked-in drivers outside of erts? In-Reply-To: <20040229215811.GA12906@spearce.org> References: <20040229215811.GA12906@spearce.org> Message-ID: <20040301140302.GA16226@spearce.org> I'm about a 3rd of the way into writing this external driver container program... I still have a lot of the APIs to implement, but I do want to thank the genius who designed the Windows dynamic driver magic. TWinDynDriverCallbacks made it possible for the same DLL to be loaded both into my process and beam, without relinking. This effort should be easily modified to allow drivers to run in a different security context than the node, using CreateProcessAsUser on NT systems, and setuid executables on UNIX. I'm not sure if this is of any help to folks, but it might be nice to be able to let erts drop its permissions down to almost nothing, and use isolated external servers to do the dirty work of talking to an actual device. Or the exact reverse, run erts with relatively high access rights to files on the local system, but push driver code down into very tight sandboxes that can't do squat. I think I'm sort of insane for even trying this, but its fun. One problem is port_call/3 and port_control/3 will block beam while it waits for the external driver to respond. :-( Shawn Pearce wrote: > Ok, so I'm building a whole slew of drivers this week, and I want > them to run both in erts, and outside as a port process. Reason is, > for early development or environments where I can't have the node crash > due to a driver bug, I want the safety of the port process - but other > users of the driver, or in some situations, I may want to use a loaded > driver for performance/memory/etc. > > Has anyone thought about writing a driver compatability layer that > would offer most of the driver_* APIs, but in an external shell? This > would let the a driver written for erl_ddll to be loaded in an external > port process. -- Shawn. From fritchie@REDACTED Mon Mar 1 18:37:04 2004 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Mon, 01 Mar 2004 11:37:04 -0600 Subject: running linked-in drivers outside of erts? In-Reply-To: Message of "Sun, 29 Feb 2004 16:58:11 EST." <20040229215811.GA12906@spearce.org> Message-ID: <200403011737.i21Hb452000993@snookles.snookles.com> >>>>> "sp" == Shawn Pearce writes: sp> Has anyone thought about writing a driver compatability layer that sp> would offer most of the driver_* APIs, but in an external shell? sp> This would let the a driver written for erl_ddll to be loaded in sp> an external port process. See the EDTK source, http://www.snookles.com/erlang/edtk/, for just such an example. It's pretty simple, but the edtk/pipe-main program does enough to get EDTK-generated shared libraries to run as an external process and communicate using a serialized protocol ... and the shared library is none the wiser. Caveat: I've never tried using it under Windows. -Scott From mpquique@REDACTED Tue Mar 2 00:28:12 2004 From: mpquique@REDACTED (Enrique Marcote =?iso-8859-1?q?Pe=F1a?=) Date: Tue, 2 Mar 2004 00:28:12 +0100 Subject: Announce: OSERL release 0.2 Message-ID: <200403020028.12042.mpquique@udc.es> Hello, Release 0.2 of OSERL (Open SMPP erlang library) is now available. Announcing the project last month encouraged me to review the code, get back into it, and do some changes I always wanted to do. I've reviewed all the code, clean up some parts and redesigned others. I've also found a few bugs I corrected (timers mainly). I believe it does look better now. I've been ask to translate a java example into erlang using this library, I thought this example could help others, so I've decided to include this comparison, along with another two examples, and detailed guidelines to help start using oserl. The project is now hosted at SourceForge. https://sourceforge.net/projects/oserl http://oserl.sourceforge.net/ Find the change log here: http://oserl.sourceforge.net/oserl/changes.html and detailed information: http://oserl.sourceforge.net/oserl/index.html Best regards, Quique From klacke@REDACTED Tue Mar 2 11:03:36 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Tue, 2 Mar 2004 11:03:36 +0100 Subject: file: module and character special files In-Reply-To: <401A832B.4040507@erix.ericsson.se> References: <200401300206.i0U26JKU098710@atlas.otago.ac.nz> <401A832B.4040507@erix.ericsson.se> Message-ID: <20040302100336.GA6710@hyber.org> On Fri, Jan 30, 2004 at 05:15:39PM +0100, Patrik Nyblom wrote: > Someone decided, a long time ago, that EISDIR was a good return value > here, when something > on the line of "this is not a regular file" would have been better. That > may have been a bad choise. > However, changing return values isn't all that popular among people > having miljons of lines of code > slushing around in systems supposed to have an ISP of 99.999 or better. Hehehe, Patrik, assume you're the SW lead for such a software project and have: 1. Requirements to have all thooose nine's in the uptime stats. 2. Programmers that write code that rely on the above bug: such as for example: open_dev(F) -> case file:open(F, read) of {ok, Fd} -> do_dev_shit(Fd); {error, eisdir} -> %% Ahhhh, it's gotta be /dev/null or somesuch do_clever_chardev_stuff(F); {error, Reason} -> {error, Reason} end. Well then, your're most certainly going to loose out on all thooooose nines anyway. :-) I'd recommend promoting the programmer to more managerial types of tasks where the damage done is better controlled. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From mpquique@REDACTED Tue Mar 2 11:01:35 2004 From: mpquique@REDACTED (Enrique Marcote =?iso-8859-1?q?Pe=F1a?=) Date: Tue, 2 Mar 2004 11:01:35 +0100 Subject: Old thread: buffered_serial and sms stuff in Erlang Message-ID: <200403021101.35896.mpquique@udc.es> Hi Bruce, I'd be interested in the application you mentioned... three years ago :) ... Are you still sharing it? Best regards, -- Quique http://www.des.udc.es/~mpquique/ ---From the archive--- buffered_serial and sms stuff in Erlang * To: * Subject: buffered_serial and sms stuff in Erlang * From: "Bruce Fitzsimons" * Date: Sun, 16 Dec 2001 14:05:09 +1300 * Message-ID: <015c01c185cd$b5654f70$4021970a@REDACTED> Hi Guys, I have just got sms sending/reception going to my mobile phone (via a cable). I've cobbed together a server to fit overtop the serial contribution - it divides things into lines, and allows regexp matches on the lines. It also ages lines in the buffer, and allows destructive matching (e.g. lines that don't match are thrown away permanently). I'm not thrilled about using \r and \n to chop things up, but I couldn't think of any other way to chunk things up and allow practical use of the serial port when dealing with unsolicited events. I've also got sms PDU mode decoding and encoding. Its fairly basic and only does 7bit char set, but thats arguably the most difficult. Possibly they only work with Ericsson T28 like phones (eg my R310s) , as I haven't got any other phones to test it with and I've gathered that there are some subtly different interpretations of the standard. If there is any interest I will clean them up a bit and post/submit them. Merry Christmas to those that celebrate it :-) Cheers, Bruce From bengt.kleberg@REDACTED Tue Mar 2 13:53:29 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 02 Mar 2004 13:53:29 +0100 Subject: file: module and character special files In-Reply-To: <20040302100336.GA6710@hyber.org> References: <200401300206.i0U26JKU098710@atlas.otago.ac.nz> <401A832B.4040507@erix.ericsson.se> <20040302100336.GA6710@hyber.org> Message-ID: <404483C9.5080005@ericsson.com> klacke@REDACTED wrote: >On Fri, Jan 30, 2004 at 05:15:39PM +0100, Patrik Nyblom wrote: > > > >>Someone decided, a long time ago, that EISDIR was a good return value >>here, when something >>on the line of "this is not a regular file" would have been better. That >> >> >> ...deleted >2. Programmers that write code that rely on the above bug: such as > for example: > > > >open_dev(F) -> > case file:open(F, read) of > {ok, Fd} -> > do_dev_shit(Fd); > {error, eisdir} -> > %% Ahhhh, it's gotta be /dev/null or somesuch > do_clever_chardev_stuff(F); > > ...deleted once i went to a conference on real time systems. one speaker was mr parnas (yes, that mr parnas :-). he told us about the re-writing of the code in a navy attack-plane. one thing they wanted to correct was the ''error'' message displayed when the flight level indicator (altimeter) broke. (it displayed 22000 feet, since some programmer had decideed it would be a good idea to show the average flight level when no value was available). however, the navy absolutly forbid them to change 22000 feet to ''error'' or ''broke'' or some such. they had loads of training material, and already trained pilots, who all where told that if the altimeter ever showed 22000 feet (an altitude they never flew at), they where supposed to climb (if flying low) and return to base as fast as possible. bengt This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From gerd@REDACTED Tue Mar 2 13:55:37 2004 From: gerd@REDACTED (Gerd Flaig) Date: Tue, 02 Mar 2004 13:55:37 +0100 Subject: Xref visualization In-Reply-To: <6.0.1.1.2.20040228134937.01c59f28@127.0.0.1> (Peter Olin's message of "Sat, 28 Feb 2004 13:52:33 +0100") References: <6.0.1.1.2.20040228134937.01c59f28@127.0.0.1> Message-ID: Peter Olin writes: > I'm trying to understand the dependencies between a bunch of modules > that someone else wrote. The new xref tool looks good, but I can't > find any tool for visualizing the dependendcies between > modules/functions. As I recall it, there used to exist a thing that > showed arrows and such. > > Do you know of any such tool? some time ago, I used dotty to visualize the data, like this: %%% File : doc.erl %%% Author : Gerd Flaig %%% Description : Generate some documentation %%% Created : 30 Oct 2003 by Gerd Flaig -module(doc). -export([do/0, graph/1]). do() -> xref:start(a), lists:foreach(fun add_app/1, [support, logger, mplex, fax, rc_callout, confer, status]). add_app(AppName) -> io:format("Adding ~s~n", [AppName]), xref:add_application(a, atom_to_list(AppName)). graph(Filename) -> {ok, E} = xref:q(a, "AE"), Header = "digraph world {\n", F = fun({A,B}) -> atom_to_list(A) ++ " -> " ++ atom_to_list(B) ++ ";\n" end, Edges = lists:concat(lists:map(F, E)), Trailer = "}\n", file:write_file(Filename, list_to_binary(Header ++ Edges ++ Trailer)). HTH. Goodbyte, Gerd. -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From matthias@REDACTED Tue Mar 2 14:37:53 2004 From: matthias@REDACTED (Matthias Lang) Date: Tue, 2 Mar 2004 14:37:53 +0100 Subject: file: module and character special files In-Reply-To: <404483C9.5080005@ericsson.com> References: <200401300206.i0U26JKU098710@atlas.otago.ac.nz> <401A832B.4040507@erix.ericsson.se> <20040302100336.GA6710@hyber.org> <404483C9.5080005@ericsson.com> Message-ID: <16452.36401.107265.324734@antilipe.corelatus.se> The "should file:open()" return 'eisdir' can be considered in political terms. You could say: "The documentation says 'eisdir' only happens if the file is a directory. The right way to handle the current situation is to use file:read_file_info() to determine the file type rather than relying on a bug. Breaking backwards compatibility only punishes people who did the wrong thing. So it should be done." But you could also argue that the role of the maintainers is to minimise harm, and the harm done to existing, large projects far outweighs the inconvenience of confused newbies. Here's a longer discussion of the same idea, which happens to mix in the question of typing: | From: Fergus Henderson (fjh@REDACTED) | Subject: Re: Does political orientation affect language choice ? | View: Complete Thread (28 articles) | Original Format | Newsgroups: comp.lang.functional, comp.lang.misc | Date: 2003-02-17 06:47:07 PST [...] | For example, here are two moral principles identified by Lakoff: | | The Principle of Reward and Punishment | -------------------------------------- | People who do the wrong thing deserve to be punished. | People who do the right thing deserve to be rewarded. | It is immoral to punish someone for doing the right thing. | It is immoral to reward someone for doing the wrong thing. | | The Principle of Altruism and Harm Minimization | ----------------------------------------------- | People who do the wrong thing need help. | People who do the right thing are usually | capable of looking after themselves. | It is immoral to harm those who need help. | It is a moral imperative to help those who need help. | | Most people would agree that there is some validity to both of these | principles. However, sometimes we are forced to choose between the two. | People whose politics are to the right of the spectrum tend to give | greater weight to the first of these principles, and those on the left | give greater weight to the second. [...] | Some of the arguments for and against strong type systems can be | phrased in ways that directly appeal to these principles. | | For example, one argument against the use of strong static type systems | is that it encourages a lack of discipline. Without static typing, | programmers who make mistakes are punished for them, and as a result, | they learn the discipline necessary to write correct code. | Static typing eliminates this, rewarding those who do the wrong thing. | Furthermore, some static type systems restrict language expressiveness, | which punishes those users who have done nothing wrong (written no type | errors). As you can see from these arguments, strong static typing | can be considered to violate the Principle of Reward and Punishment. | On the other hand, there are also some strong arguments that it | conforms to the Principle of Altruism and Harm Minimization. | The relative weight people place on these principles thus affects | their choice of programming language as well as their political | orientation. Matthias (changing the manual to at least say that 'eisdir' doesn't necessarily mean it's a directory seems like a universally acceptable solution.) From ulf.wiger@REDACTED Tue Mar 2 15:03:59 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 02 Mar 2004 15:03:59 +0100 Subject: file: module and character special files In-Reply-To: <16452.36401.107265.324734@antilipe.corelatus.se> References: <200401300206.i0U26JKU098710@atlas.otago.ac.nz> <401A832B.4040507@erix.ericsson.se> <20040302100336.GA6710@hyber.org> <404483C9.5080005@ericsson.com> <16452.36401.107265.324734@antilipe.corelatus.se> Message-ID: On Tue, 2 Mar 2004 14:37:53 +0100, Matthias Lang wrote: > > The "should file:open()" return 'eisdir' can be considered in > political terms. You could say: > > "The documentation says 'eisdir' only happens if the file is > a directory. The right way to handle the current situation is > to use file:read_file_info() to determine the file type rather > than relying on a bug. > > Breaking backwards compatibility only punishes people who did > the wrong thing. So it should be done." > > But you could also argue that the role of the maintainers is to > minimise harm, and the harm done to existing, large projects far > outweighs the inconvenience of confused newbies. I found the following in my own code: %% Instead of doing read_file_info on entries to find out if they are %% directories, we try list_dir/1 directly (saves us port comm). %% Thus, when called with {error, enotdir}, we know that we did list_dir() %% on a regular file, and happily move on. %% sh_match({ok, Files}, [ThisPat], Root) -> Files1 = try_pat(Files, sh_expr(ThisPat)), [{Root, Files1}]; sh_match({ok, Files}, [ThisPat|Ps], Root) -> Files1 = try_pat(Files, sh_expr(ThisPat)), try_list(Files1, Ps, Root); sh_match({error, enotdir}, _, _) -> []. In principle then, I deserve to be punished for doing the Wrong Thing, even though in this case, my code doesn't break. However, the comment is wrong. It should obviously say "we know that we did list_dir() on something which is not a directory" ...a chilling thought entered my mind, and I just had to check: 1> file:list_dir("/dev/null"). {error,enotdir} /Uffe (confused newbie) PS In my defense, I would like to add that the above code was designed to operate in a heavily loaded ClearCase environment, where _any_ file operation might hang for a looong time. -- Ulf Wiger, Senior System Architect EAB/UPD/S This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From spearce@REDACTED Tue Mar 2 15:15:21 2004 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 2 Mar 2004 09:15:21 -0500 Subject: file: module and character special files In-Reply-To: <16452.36401.107265.324734@antilipe.corelatus.se> References: <200401300206.i0U26JKU098710@atlas.otago.ac.nz> <401A832B.4040507@erix.ericsson.se> <20040302100336.GA6710@hyber.org> <404483C9.5080005@ericsson.com> <16452.36401.107265.324734@antilipe.corelatus.se> Message-ID: <20040302141521.GB25104@spearce.org> Matthias Lang wrote: > (changing the manual to at least say that 'eisdir' doesn't necessarily > mean it's a directory seems like a universally acceptable solution.) I agree, this is the best solution right now. Denote in the manual that eisdir may be returned even if the item is not a directory, and that the caller should use the file info function to determine the actual type of the item which cannot be opened with the file module. Can we also get a file:open_device or something that goes around the back of file:open and lets you get a device opened up? Being a new call, it wouldn't need to return {error, eisdir}. :) Its quite unfortunate that this has happened, but I can't say I blame them. It most likely occurred because whoever wrote the code forgot UNIX offers other file types, and originally just tested for regular file and directory types, returning {error, eisdir}. Months later someone tries to open a device, and it succeeds. They file a bug asking that file:open return an error instead. The developer tries to return a different error condition, but there's already a ton of code written as: case file:open(Foo) of {ok, Fd} -> ...; {error, esidir} -> ... end. which would yeild a badmatch in the caller. With the requirements for uptime, the developer chose to not cause badmatch. Ugh! -- Shawn. From tobbe@REDACTED Wed Mar 3 01:33:01 2004 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Wed, 03 Mar 2004 01:33:01 +0100 Subject: Added to jungerl: esmb Message-ID: <404527BD.6040207@bluetail.com> Hi, I have added a SMB protocol implementation to jungerl. It implements a subset of the (in)famous SMB protocol, so you can now say goodbye to Samba...well perhaps not. It is still a bit rough around the edges but I have implemented a little example program mimicking the 'smbclient' program, see below. Cheers, Tobbe (Ps. Sorry for the indentation, it sucks using Mozilla...) ----------------------------------------------------------------- # # NB: 'korp' is a Win2000 server # erlang/esmb> erl -pa ./ebin Erlang (BEAM) emulator version 5.2.b2 [source] [hipe] Eshell V5.2.b2 (abort with ^G) 1> esmb:client("//korp/tobbe", "tobbe"). <0.30.0> Password: xxxxxx //> cd kalle //kalle/> ls . SIZE 0 IS [dir] .. SIZE 0 IS [dir] COOL SIZE 0 IS [dir] HEJSAN SIZE 0 IS [dir] SVEJSAN SIZE 0 IS [dir] //kalle/> rmdir cool //kalle/> ls . SIZE 0 IS [dir] .. SIZE 0 IS [dir] HEJSAN SIZE 0 IS [dir] SVEJSAN SIZE 0 IS [dir] //kalle/> mkdir cooler //kalle/> ls . SIZE 0 IS [dir] .. SIZE 0 IS [dir] COOLER SIZE 0 IS [dir] HEJSAN SIZE 0 IS [dir] SVEJSAN SIZE 0 IS [dir] //kalle/> cd cooler //kalle/cooler/> ls . SIZE 0 IS [dir] .. SIZE 0 IS [dir] //kalle/cooler/> put gunnar.txt Writing.... Wrote, res={ok,15488} //kalle/cooler/> ls . SIZE 0 IS [dir] .. SIZE 0 IS [dir] GUNNAR.TXT SIZE 15488 IS [] //kalle/cooler/> rm gunnar.txt //kalle/cooler/> ls . SIZE 0 IS [dir] .. SIZE 0 IS [dir] //kalle/cooler/> cd .. //kalle/> ls . SIZE 0 IS [dir] .. SIZE 0 IS [dir] COOLER SIZE 0 IS [dir] HEJSAN SIZE 0 IS [dir] SVEJSAN SIZE 0 IS [dir] //kalle/> help Commands: '?', cat, cd, get, help, ls, mkdir, quit, put, rm, rmdir //kalle/> ------------------------------------------------------------------------- From enano@REDACTED Wed Mar 3 10:19:04 2004 From: enano@REDACTED (Miguel Barreiro) Date: Wed, 3 Mar 2004 10:19:04 +0100 (CET) Subject: file: module and character special files In-Reply-To: <404483C9.5080005@ericsson.com> References: <200401300206.i0U26JKU098710@atlas.otago.ac.nz> <401A832B.4040507@erix.ericsson.se> <20040302100336.GA6710@hyber.org> <404483C9.5080005@ericsson.com> Message-ID: > he told us about the re-writing of the code in a navy attack-plane. one > thing they wanted to correct was the ''error'' message displayed when > the flight level indicator (altimeter) broke. (it displayed 22000 feet, > since some programmer had decideed it would be a good idea to show the Abroad I suppose - aren't swedish warplanes supposed to show flight level in meters? :-) From klacke@REDACTED Wed Mar 3 13:43:43 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Wed, 3 Mar 2004 13:43:43 +0100 Subject: file: module and character special files In-Reply-To: <20040302141521.GB25104@spearce.org> References: <200401300206.i0U26JKU098710@atlas.otago.ac.nz> <401A832B.4040507@erix.ericsson.se> <20040302100336.GA6710@hyber.org> <404483C9.5080005@ericsson.com> <16452.36401.107265.324734@antilipe.corelatus.se> <20040302141521.GB25104@spearce.org> Message-ID: <20040303124343.GA12684@hyber.org> On Tue, Mar 02, 2004 at 09:15:21AM -0500, Shawn Pearce wrote: > > Its quite unfortunate that this has happened, but I can't say I blame > them. It most likely occurred because whoever wrote the code forgot > UNIX offers other file types, and originally just tested for regular > file and directory types, returning {error, eisdir}. The irony here (reflecting on my previous sarcastic post) is that the _one_ above is probably me. I wrote the original file driver. What was once an idiotic little shit bug, is now a cast-in-stone- never-to-be-changed-system-interface /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From bengt.kleberg@REDACTED Wed Mar 3 13:53:47 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 03 Mar 2004 13:53:47 +0100 Subject: file: module and character special files In-Reply-To: References: <200401300206.i0U26JKU098710@atlas.otago.ac.nz> <401A832B.4040507@erix.ericsson.se> <20040302100336.GA6710@hyber.org> <404483C9.5080005@ericsson.com> Message-ID: <4045D55B.1090507@ericsson.com> Miguel Barreiro wrote: >>he told us about the re-writing of the code in a navy attack-plane. one >>thing they wanted to correct was the ''error'' message displayed when >>the flight level indicator (altimeter) broke. (it displayed 22000 feet, >>since some programmer had decideed it would be a good idea to show the >> >> > >Abroad I suppose - aren't swedish warplanes supposed to show flight level >in meters? :-) > > it was the U. S.* Navy's* A-7E Corsair II *attack* aircraft. bengt This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From edmundd@REDACTED Wed Mar 3 18:57:11 2004 From: edmundd@REDACTED (Edmund Dengler) Date: Wed, 3 Mar 2004 12:57:11 -0500 (EST) Subject: How to do table lookups? Message-ID: Hi all! I am looking for the "right" way to do the following: I am running a C program using ports, and need to parse the binary output. I figured the easiest way would be to get the binary bytes, and then call a function to do the actual parsing: loop(Port) -> receive {Port, {data, Bytes}} -> io:format("Received ~w~n", [Bytes]), parse(Bytes), loop(Port); {Port, eof} -> eof end. parse(Bytes) -> <> = Bytes, ***do magic here to convert integer to atom*** io:format("First=~s~n", [First]). Now, I could declare a function to do the conversion: lookup_dict(Value) -> case Value of 16#01 -> atom_a; 16#02 -> atom_b; 16#03 -> atom_c; _ -> error end. parse(Bytes) -> <> = Bytes, io:format("First=~s~n", [lookup_dict(First)]). But this would seem slow (as we need to sequentially scan down the matching statements), and I cannot do a reverse lookup (convert the atom into the appropriate integer). I thought about using a dict object: parse(Bytes) -> Lookup_dict = dict:from_list([ {16#01, atom_a}, {16#02, atom_b}, {16#03, atom_c}]), <> = Bytes, io:format("First=~s~n", [dict:fetch(First, Lookup_dict)]). But obviously the above would rebuild the dictionary each and every time. However, is there a way to get the equivalent of a "cached" value? Or essentially to do a curry (replace the function with a new one that has an instance of the lookup table in its scope)? The dictionary is static, and so any such method would be "pure" (in the sense that any calls to such a function would always return the same value). I thought of using the process dictionary, but this seemed to be the wrong place to put it (as I would need to create a new copy for each process, rather than sharing a single instance). I think what I really want here is a module dictionary (if that makes any sense, not sure, as values cannot be shared across processes). Now I could create some kind of state variable (with all the appropriate dictionaries), but this would be awkward to keep passing around, as it is needed only at the lowest levels. Should I create a process, and use message passing? This would seem to consume extra overhead, and I would need to pass along a process ID (unless I wanted to do a lookup each time) similar to the state idea. Is there a better way? Regards! Ed P.S. Is there a way to ensure that a port program is killed automatically upon the termination of the Erlang process? The executable I am using does not die automatically when the Erlang process is killed, and so I am finding lots of active instances of the program running. I am using: Port = open_port({spawn, "EXE"}, [stream, binary]). From vances@REDACTED Wed Mar 3 20:05:46 2004 From: vances@REDACTED (Vance Shipley) Date: Wed, 3 Mar 2004 14:05:46 -0500 Subject: How to do table lookups? In-Reply-To: References: Message-ID: <20040303190546.GC65608@frogman.motivity.ca> Edmund, You should look at erl_interface (ei specifically) which is a C library you link with your C program which provides everything you need to implement a "C node". This way you can just send atoms, integers, strings, etc. and receive them as normal in your Erlang node. } <> = Bytes, The above will not work. It should be: <> = Bytes, } But this would seem slow (as we need to sequentially scan down the Don't worry about it. } I thought of using the process dictionary, but this seemed to be the wrong Just say no to the process dictionary. } Now I could create some kind of state variable (with all the appropriate } dictionaries), but this would be awkward to keep passing around, as it is } needed only at the lowest levels. This is the way it's done. You pass state data around like a hot potato. It may seem awkward somehow but it has it's own beauty. Erlang has no global variables, get used to passing everything you need. } Should I create a process, and use message passing? This would seem to } consume extra overhead, and I would need to pass along a process ID } (unless I wanted to do a lookup each time) similar to the state idea. This is what you do when multiple processes need access to the same data. It's the way it works. Quit worrying about performance. (However in this case it's the wrong approach). } Is there a better way? Definetly use ei. Another word of advice; you should always assume you are doing the wrong thing if you write a receive statement (unless your name is on the cover of the Erlang book). Everything can and should be done with the standard behaviours. [This is rule of thumb advice for less than expert Erlang coders. Once you are an expert you can implement your own behaviours] In the case of C nodes this may seem necessary but it actually isn't. Just have your ei program format it's messages appropriately and make your Erlang program a gen_server/gen_fsm. If you look at gen_server.erl you'll see the messaghes it expects are of the form: {'$gen_cast', Msg} {'$gen_call', From, Msg} While you're there look at how much is being done under the hood for you and you'll see why you should use a standard behaviour. } Port = open_port({spawn, "EXE"}, [stream, binary]). Windows? Can't help you. -Vance From vances@REDACTED Wed Mar 3 20:26:51 2004 From: vances@REDACTED (Vance Shipley) Date: Wed, 3 Mar 2004 14:26:51 -0500 Subject: How to do table lookups? In-Reply-To: <20040303190546.GC65608@frogman.motivity.ca> References: <20040303190546.GC65608@frogman.motivity.ca> Message-ID: <20040303192651.GA78075@frogman.motivity.ca> What the heck is this? Binaries must be a number of bits divisable by 8 however the example Edmund gave doesn't give an immediate error but instead returns siomething which actually isn't a binary! -Vance Erlang (BEAM) emulator version 5.3 [source] [threads:0] Eshell V5.3 (abort with ^G) 1> <> = <<255>>. <<255>> 2> A. 1 3> is_binary(Rest). false 4> Rest. {[1,1,1,1,1,1,1], 7, <<>>} From edmundd@REDACTED Wed Mar 3 20:54:24 2004 From: edmundd@REDACTED (Edmund Dengler) Date: Wed, 3 Mar 2004 14:54:24 -0500 (EST) Subject: How to do table lookups? In-Reply-To: <20040303190546.GC65608@frogman.motivity.ca> References: <20040303190546.GC65608@frogman.motivity.ca> Message-ID: Hi all! On Wed, 3 Mar 2004, Vance Shipley wrote: > Edmund, > > You should look at erl_interface (ei specifically) which is a > C library you link with your C program which provides everything > you need to implement a "C node". This way you can just send > atoms, integers, strings, etc. and receive them as normal in > your Erlang node. The program is somebody else's, unfortunately, and thus I need to interface to it's output, rather than modifying it to use ei. On the other hand, I have been eyeing ei for use in Snort to have it report to an Erlang node. > > } <> = Bytes, > > The above will not work. It should be: > > <> = Bytes, I thought if you use /binary, then the default unit is 8bits, so the :1/binary = :8. At least, this is how I read it in the bit syntax. Is this wrong? > > } But this would seem slow (as we need to sequentially scan down the > > Don't worry about it. Still leaves the issue of no reverse lookups, which is why I wanted some form of data structure. > > } I thought of using the process dictionary, but this seemed to be the wrong > > Just say no to the process dictionary. > > } Now I could create some kind of state variable (with all the appropriate > } dictionaries), but this would be awkward to keep passing around, as it is > } needed only at the lowest levels. > > This is the way it's done. You pass state data around like a hot potato. > It may seem awkward somehow but it has it's own beauty. Erlang has no > global variables, get used to passing everything you need. Oh, I realize this. _But_, it does make it awkward to program what are essentially compile time lookup tables (calculate once, use everywhere). I suppose I could start to use functions ("please return me a function to do this", but then I would be passing around the function pointer). At least with non-pure languages such as Scheme, this sort of awkwardness can be avoided. > > } Should I create a process, and use message passing? This would seem to > } consume extra overhead, and I would need to pass along a process ID > } (unless I wanted to do a lookup each time) similar to the state idea. > > This is what you do when multiple processes need access to the same > data. It's the way it works. Quit worrying about performance. > (However in this case it's the wrong approach). > > } Is there a better way? > > Definetly use ei. > > Another word of advice; you should always assume you are doing the > wrong thing if you write a receive statement (unless your name is > on the cover of the Erlang book). Everything can and should be > done with the standard behaviours. > > [This is rule of thumb advice for less than expert Erlang > coders. Once you are an expert you can implement your own > behaviours] > > In the case of C nodes this may seem necessary but it actually > isn't. Just have your ei program format it's messages appropriately > and make your Erlang program a gen_server/gen_fsm. If you look at > gen_server.erl you'll see the messaghes it expects are of the form: > > {'$gen_cast', Msg} > {'$gen_call', From, Msg} > > While you're there look at how much is being done under the hood > for you and you'll see why you should use a standard behaviour. > > } Port = open_port({spawn, "EXE"}, [stream, binary]). > > Windows? Can't help you. > > -Vance > From edmundd@REDACTED Wed Mar 3 21:05:03 2004 From: edmundd@REDACTED (Edmund Dengler) Date: Wed, 3 Mar 2004 15:05:03 -0500 (EST) Subject: How to do table lookups? (fwd) Message-ID: Arggh! Hit the reply too early. ---------- Forwarded message ---------- Hi all! On Wed, 3 Mar 2004, Vance Shipley wrote: > Edmund, > > You should look at erl_interface (ei specifically) which is a > C library you link with your C program which provides everything > you need to implement a "C node". This way you can just send > atoms, integers, strings, etc. and receive them as normal in > your Erlang node. The program is somebody else's, unfortunately, and thus I need to interface to it's output, rather than modifying it to use ei. On the other hand, I have been eyeing ei for use in Snort to have it report to an Erlang node. > > } <> = Bytes, > > The above will not work. It should be: > > <> = Bytes, I thought if you use /binary, then the default unit is 8bits, so the :1/binary = :8. At least, this is how I read it in the bit syntax. Is this wrong? > > } But this would seem slow (as we need to sequentially scan down the > > Don't worry about it. Still leaves the issue of no reverse lookups, which is why I wanted some form of data structure. > > } I thought of using the process dictionary, but this seemed to be the wrong > > Just say no to the process dictionary. > > } Now I could create some kind of state variable (with all the appropriate > } dictionaries), but this would be awkward to keep passing around, as it is > } needed only at the lowest levels. > > This is the way it's done. You pass state data around like a hot potato. > It may seem awkward somehow but it has it's own beauty. Erlang has no > global variables, get used to passing everything you need. Oh, I realize this. _But_, it does make it awkward to program what are essentially compile time lookup tables (calculate once, use everywhere). I suppose I could start to use functions ("please return me a function to do this", but then I would be passing around the function pointer). At least with non-pure languages such as Scheme, this sort of awkwardness can be avoided. > > } Should I create a process, and use message passing? This would seem to > } consume extra overhead, and I would need to pass along a process ID > } (unless I wanted to do a lookup each time) similar to the state idea. > > This is what you do when multiple processes need access to the same > data. It's the way it works. Quit worrying about performance. > (However in this case it's the wrong approach). > > } Is there a better way? > > Definetly use ei. > > Another word of advice; you should always assume you are doing the > wrong thing if you write a receive statement (unless your name is > on the cover of the Erlang book). Everything can and should be > done with the standard behaviours. > > [This is rule of thumb advice for less than expert Erlang > coders. Once you are an expert you can implement your own > behaviours] Actually, I was looking at the gen_server, and was having an issue with regards to the receives not seeming to be able to have a guard. I have a couple of programs where I do synchronization based on guard expressions to implement bounded queues. While I could rewrite to not do this, it would definitely not be as clean. > In the case of C nodes this may seem necessary but it actually > isn't. Just have your ei program format it's messages appropriately > and make your Erlang program a gen_server/gen_fsm. If you look at > gen_server.erl you'll see the messaghes it expects are of the form: > > {'$gen_cast', Msg} > {'$gen_call', From, Msg} Back to this being somebody else's program, and so do not have an option of ei. > > While you're there look at how much is being done under the hood > for you and you'll see why you should use a standard behaviour. > > } Port = open_port({spawn, "EXE"}, [stream, binary]). > > Windows? Can't help you. Nope, OpenBSD/Linux. The program does not detect that the listening program has closed the file descriptors, and so hangs on full pipes without dying. > > -Vance > Regards! Ed From vances@REDACTED Wed Mar 3 21:30:28 2004 From: vances@REDACTED (Vance Shipley) Date: Wed, 3 Mar 2004 15:30:28 -0500 Subject: How to do table lookups? (fwd) In-Reply-To: References: Message-ID: <20040303203028.GC78075@frogman.motivity.ca> } > } <> = Bytes, } > } > The above will not work. It should be: } > } > <> = Bytes, } } I thought if you use /binary, then the default unit is 8bits, so the } :1/binary = :8. At least, this is how I read it in the bit syntax. Is this } wrong? Doh! I didn't see the "/binary" for some reason, probably 'cause it's a fairly strange thing to do when you wanted an integer. You are correct, the default unit size of a binary is 8. } Actually, I was looking at the gen_server, and was having an issue with } regards to the receives not seeming to be able to have a guard. I have a } couple of programs where I do synchronization based on guard expressions } to implement bounded queues. While I could rewrite to not do this, it } would definitely not be as clean. I'm not sure I follow you. You can implement guards as: handle_cast({Foo, Bar}, State) when is_integer(Bar), Bar < 10 -> If you want to control the number of messages in your mailbox than you'll just need to become an expert and implement everything you need. If you're new to Erlang/OTP and you find you need to do this level of hackery again you should assume you are doing soomething wrong. } Back to this being somebody else's program, and so do not have an option } of ei. You could alwaysd write a wrapper in C using ei. } Nope, OpenBSD/Linux. The program does not detect that the listening } program has closed the file descriptors, and so hangs on full pipes } without dying. Your wrapper could solve this. -Vance From vances@REDACTED Wed Mar 3 21:34:49 2004 From: vances@REDACTED (Vance Shipley) Date: Wed, 3 Mar 2004 15:34:49 -0500 Subject: How to do table lookups? In-Reply-To: <20040303190546.GC65608@frogman.motivity.ca> References: <20040303190546.GC65608@frogman.motivity.ca> Message-ID: <20040303203449.GE78075@frogman.motivity.ca> Edmund, Please see this thread from last month: http://www.erlang.org/ml-archive/erlang-questions/200402/msg00133.html -Vance From crav@REDACTED Wed Mar 3 18:24:25 2004 From: crav@REDACTED (=?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=) Date: Wed, 3 Mar 2004 18:24:25 +0100 Subject: megaco_compact_text??? Message-ID: <003401c40144$662aee70$6600a8c0@carlos> hi, We are testing de erlang megaco libraries to use with an analog gateway (audio codes mp-102) and We have this problem: the gateway sopport only compact text enconder, and the service change that it sends to the mgc is: ************************* MEGACO/1 [192.168.0.108]:0 T=1 { C= - { SC=ROOT { SV { MT=RS, AD=0, V=1, PF=TGW1, RE="901 MGCold BOOT", 19700101T0002}}}}\X00 *************************** With which it gives a syntax error, i guess that the error is in 'MEGACO/1' that it must that be '!/1' ?? If I probe with de megaco_test_mg the service change is: ************************* !/1 [192.168.0.105]:0 T=1{C=-{SC=ROOT{SV{MT=RS,RE="901"}}}} ********************************* and all is ok.... MY QUESTION IS IF I CHANGE '!/1' by 'MEGACO/1'... that is a correct in compact mode codification??? I capture the frame with the ethereal and both frames are valid megaco... How I change (and where is that ) the '!/1' by 'MEGACO/1' THANKS YOU -------------- next part -------------- An HTML attachment was scrubbed... URL: From edmundd@REDACTED Wed Mar 3 22:18:09 2004 From: edmundd@REDACTED (Edmund Dengler) Date: Wed, 3 Mar 2004 16:18:09 -0500 (EST) Subject: How to do table lookups? (fwd) In-Reply-To: <20040303203028.GC78075@frogman.motivity.ca> References: <20040303203028.GC78075@frogman.motivity.ca> Message-ID: Hi all! On Wed, 3 Mar 2004, Vance Shipley wrote: > } Actually, I was looking at the gen_server, and was having an issue with > } regards to the receives not seeming to be able to have a guard. I have a > } couple of programs where I do synchronization based on guard expressions > } to implement bounded queues. While I could rewrite to not do this, it > } would definitely not be as clean. > > I'm not sure I follow you. You can implement guards as: > > handle_cast({Foo, Bar}, State) when is_integer(Bar), > Bar < 10 -> Actually, I have no real issue with the low level handling of the receives myself (most of the apps have been fairly straight forward). I find using the guards to block reception of messages in the receive queue quite useful as a model. As far as I understand, the above does not block inbound messages that would fail the test (or does it?). Ie, I would still receive the next message in the queue, and if it is not the one I want, I still have to put it someplace for processing later. > > If you want to control the number of messages in your mailbox than > you'll just need to become an expert and implement everything you > need. If you're new to Erlang/OTP and you find you need to do this > level of hackery again you should assume you are doing soomething > wrong. > > } Back to this being somebody else's program, and so do not have an option > } of ei. > > You could alwaysd write a wrapper in C using ei. Then I would need to do all the binary parsing in C, and then convert to appropriate Erlang components. Not sure if this would be the route I would like. > > } Nope, OpenBSD/Linux. The program does not detect that the listening > } program has closed the file descriptors, and so hangs on full pipes > } without dying. > > Your wrapper could solve this. I was originally hoping for some kind of port parameter of the "kill this program if the current Erlang process dies" kind. I could try to rig up some form of link with a kill process. I have to see if there is a way to extract the process id from the data returned by open_port/2. > > -Vance > Regards! Ed From vances@REDACTED Wed Mar 3 22:34:36 2004 From: vances@REDACTED (Vance Shipley) Date: Wed, 3 Mar 2004 16:34:36 -0500 Subject: How to do table lookups? (fwd) In-Reply-To: References: <20040303203028.GC78075@frogman.motivity.ca> Message-ID: <20040303213436.GH78075@frogman.motivity.ca> On Wed, Mar 03, 2004 at 04:18:09PM -0500, Edmund Dengler wrote: } } Actually, I have no real issue with the low level handling of the receives } myself (most of the apps have been fairly straight forward). I find using } the guards to block reception of messages in the receive queue quite } useful as a model. As far as I understand, the above does not block } inbound messages that would fail the test (or does it?). Ie, I would still } receive the next message in the queue, and if it is not the one I want, I } still have to put it someplace for processing later. True. It handles the system messages for you but you have to handle the rest of the messages in the order it gives them to you. If you needed to pull out higher priority messages you would need to implement your own behaviour. -Vance From spearce@REDACTED Thu Mar 4 02:18:11 2004 From: spearce@REDACTED (Shawn Pearce) Date: Wed, 3 Mar 2004 20:18:11 -0500 Subject: Just how smart is erl_ddll? Message-ID: <20040304011811.GA26887@spearce.org> It seems like erl_ddll unloads my DLL when the process which loaded it exits. Does the erl_ddll server monitor all users somehow and then unload the DLL when the last one terminates? If so, rock on Erlang! -- Shawn. From spearce@REDACTED Thu Mar 4 03:08:41 2004 From: spearce@REDACTED (Shawn Pearce) Date: Wed, 3 Mar 2004 21:08:41 -0500 Subject: Just how smart is erl_ddll? In-Reply-To: <20040304011811.GA26887@spearce.org> References: <20040304011811.GA26887@spearce.org> Message-ID: <20040304020841.GC26887@spearce.org> To answer myself, yes, it does. I should just read the source more often. That's why its there after all. Is there anything the developers haven't thought of? (eisdir aside...) Shawn Pearce wrote: > It seems like erl_ddll unloads my DLL when the process which loaded > it exits. Does the erl_ddll server monitor all users somehow and then > unload the DLL when the last one terminates? > > If so, rock on Erlang! -- Shawn. BOFH Excuse #267: The UPS is on strike. From hakan@REDACTED Thu Mar 4 12:44:22 2004 From: hakan@REDACTED (Hakan Mattsson) Date: Thu, 4 Mar 2004 12:44:22 +0100 (MET) Subject: megaco_compact_text??? Message-ID: Oops, I forgot to cc the list. /H?kan ---------- Forwarded message ---------- Date: Thu, 4 Mar 2004 10:07:52 +0100 (MET) From: Hakan Mattsson To: Carlos Rodr?guez Alcal? Villagra Subject: Re: megaco_compact_text??? On Wed, 3 Mar 2004, Carlos Rodr?guez Alcal? Villagra wrote: Carlos> With which it gives a syntax error, i guess that the error is in 'MEGACO/1' that it must that be '!/1' ?? No, it is the profile that is erroneous, enclosed printouts below. The profile must contain a name and a version separated by a slash: serviceChangeProfile = ProfileToken EQUAL NAME SLASH Version I think that the easiest way to debug these kinds of errors is to use built-in debug support in the Megaco application. The sequence chart tool 'et' is quite powerful. BTW, even if you use the compact text encoder in the megaco application it will decode both short and long keywords. It is only the encoder that will be using the short message style. /H?kan --- H?kan Mattsson Ericsson High Availability Software, DBMS Internals http://www.erlang.org/~hakan/ 1> M = "MEGACO/1 [192.168.0.108]:0 T=1 { C= - { SC=ROOT { SV { MT=RS, AD=0, V=1, PF=TGW1, RE=\"901 MGCold BOOT\", 19700101T0002}}}}". 2> megaco_compact_text_encoder:decode_message([], list_to_binary(M)). {error,[{reason,{8,megaco_text_parser,{bad_profile,"tgw1"}}}, {token,[{'SafeChars',1,"megaco/1"}, {'LSBRKT',1}, {'SafeChars',1,"192.168.0.108"}, {'RSBRKT',1}, {'COLON',1}, {'SafeChars',1,"0"}, {'SEP',1}, {'TransToken',1,"t"}, {'EQUAL',1}, {'SafeChars',1,"1"}, {'LBRKT',1}, {'CtxToken',2,"c"}, {'EQUAL',2}, {'SafeChars',2,"-"}, {'LBRKT',2}, {'ServiceChangeToken',3,"sc"}, {'EQUAL',3}, {'SafeChars',3,"root"}, {'LBRKT',3}, {'ServicesToken',4,"sv"}, {'LBRKT',4}, {'MethodToken'|...}, {...}|...]}, {chars,<<77,69,71,65,67,79,47,49,32,91,49,57,50,46,49,54,56,46,48,46,49,48,...>>}]} 3> M2 = "MEGACO/1 [192.168.0.108]:0 T=1 { C= - { SC=ROOT { SV { MT=RS, AD=0, V=1, PF=TGW1/42, RE=\"901 MGCold BOOT\", 19700101T0002}}}}". 4> megaco_compact_text_encoder:decode_message([], list_to_binary(M2)). {ok,{'MegacoMessage',asn1_NOVALUE, {'Message',1, {ip4Address,{'IP4Address',[192,168,0,108],0}}, {transactions, [{transactionRequest, {'TransactionRequest', 1, [{'ActionRequest', 0, asn1_NOVALUE, asn1_NOVALUE, [...]}]}}]}}}} This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From rvg@REDACTED Thu Mar 4 12:50:55 2004 From: rvg@REDACTED (Rudolph van Graan) Date: Thu, 4 Mar 2004 13:50:55 +0200 Subject: Mnesia schema transaction Message-ID: <3231427E-6DD2-11D8-BB54-000A956D87EE@patternmatched.com> Hi all, Previously Ulf Wiger posted about mnesia_schema:schema_transaction(fun() -> ...) This function is exported and usuable, however inside mnesia_schema, I found this code: create_table(TabDef) -> schema_transaction(fun() -> do_multi_create_table(TabDef) end). Now, if I do create_table inside a schema_transaction, it aborts with "nested transaction" - obviously because the above call already runs it as a transaction. Now, there seems to be no other create_table function that I can use to achieve transactions here that I could find. Is it really necessary to update mnesia's code to get create_table to run inside a transaction or am I again missing the obvious? Thank you in advance, Rudolph van Graan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2112 bytes Desc: not available URL: From tobbe@REDACTED Thu Mar 4 12:58:59 2004 From: tobbe@REDACTED (=?ISO-8859-1?Q?Torbj=F6rn_T=F6rnkvist?=) Date: Thu, 04 Mar 2004 12:58:59 +0100 Subject: crypto(3) ? Message-ID: <40471A03.7070903@nortelnetworks.com> Hi, I've been comparing the crypto(3) man page with the CIFS description on how the (SMB) session key is computed, trying to understand if they are the same. Perhaps someone (Peter ?) could comment on this? The CIFS explanation: ------------------------------------ E(K, D) denote the DES block mode encryption function [FIPS 81] , which accepts a seven byte key (K) and an eight byte data block (D) and produces an eight byte encrypted data block as its value. Ex(K,D) denote the extension of DES to longer keys and data blocks. If the data to be encrypted is longer than eight bytes, the encryption function is applied to each block of eight bytes in sequence and the results are concatenated together. If the key is longer than seven bytes, each 8 byte block of data is first completely encrypted using the first seven bytes of the key, then the second seven bytes, etc., appending the results each time. For example, to encrypt the 16 byte quantity D0D1 with the 14 byte key K0K1, Ex(K0K1,D0D1) = concat(E(K0,D0),E(K0,D1),E(K1,D0),E(K1,D1)) So is this algorithm covered by the crypto module? This just gives me headache... Cheers, Tobbe From ulf.wiger@REDACTED Thu Mar 4 13:17:23 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 04 Mar 2004 13:17:23 +0100 Subject: Mnesia schema transaction In-Reply-To: <3231427E-6DD2-11D8-BB54-000A956D87EE@patternmatched.com> References: <3231427E-6DD2-11D8-BB54-000A956D87EE@patternmatched.com> Message-ID: Hi Rudolph, You can use nmesia_schema:do_create_table/1 (which also requires use of mnesia_schema:list2cs/1.) Here's some sample code from one of my unfinished contribs: initialise_class(Class) -> {Attrs, TableProps, UserProps} = Class:describe(), F = fun() -> create_table(Class, table_properties(Attrs, TableProps)), rdbms:do_add_properties(UserProps, Class) end, mnesia_schema:schema_transaction(F). create_table(Name, Properties) -> Cs = mnesia_schema:list2cs([{name, Name}|Properties]), mnesia_schema:do_create_table(Cs). table_properties(Attrs, Opts) -> Nodes = mnesia:system_info(db_nodes), RemoveKeys = [disc_copies, ram_copies, disc_copies], Rest = [{K,V} || {K,V} <- Opts, not(lists:member(K, RemoveKeys))], [{attributes, Attrs}, {disc_only_copies, opt(disc_only_copies, Opts, Nodes)}, {ram_copies, opt(ram_copies, Opts, [])}, {disc_copies, opt(ram_copies, Opts, [])}|Rest]. /Uffe On Thu, 4 Mar 2004 12:50:55 +0100, Rudolph van Graan wrote: > Hi all, > > Previously Ulf Wiger posted about > mnesia_schema:schema_transaction(fun() -> ...) > > This function is exported and usuable, however inside mnesia_schema, I > found this code: > > create_table(TabDef) -> > schema_transaction(fun() -> do_multi_create_table(TabDef) end). > > Now, if I do create_table inside a schema_transaction, it aborts with > "nested transaction" - obviously because the above call already runs it > as a transaction. Now, there seems to be no other create_table function > that I can use to achieve transactions here that I could find. Is it > really necessary to update mnesia's code to get create_table to run > inside a transaction or am I again missing the obvious? > > Thank you in advance, > > > Rudolph van Graan -- Ulf Wiger, Senior System Architect EAB/UPD/S This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From rvg@REDACTED Thu Mar 4 15:13:09 2004 From: rvg@REDACTED (Rudolph van Graan) Date: Thu, 4 Mar 2004 16:13:09 +0200 Subject: Mnesia schema transaction: Checking if a table exists In-Reply-To: References: <3231427E-6DD2-11D8-BB54-000A956D87EE@patternmatched.com> Message-ID: <10647953-6DE6-11D8-BB54-000A956D87EE@patternmatched.com> Hi again, Thanks for the information - I can now create tables in a transaction. However, this leads to the next problem... I am busy creating say 10 tables... As part of my creation script, I need to check if another table exists, so I made a function like this one: table_exists(TableName) -> Tables = mnesia:system_info(tables), lists:member(TableName,Tables). This works fine if I use it outside the schema_transaction for a table that has just been created. If I use it inside the schema_transaction, on a table that has just been created in the same transaction, it fails... Is there some other function I can use to check for a table that has just been created in the same function and that will query the changes for the current transaction instead? [The idea is that the transaction must abort and all the changes rolled back if something goes wrong here]. I.e. if I do create_table(), and immediately run this function afterwards, it must return true while inside the schema transaction. Regards. Rudolph van Graan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2112 bytes Desc: not available URL: From rvg@REDACTED Thu Mar 4 15:19:10 2004 From: rvg@REDACTED (Rudolph van Graan) Date: Thu, 4 Mar 2004 16:19:10 +0200 Subject: Mnesia Core Dump Message-ID: Do this: (rvg@REDACTED)70> mnesia: create_table(aaa,[{disc_copies,[node()]},{attributes,[a,b,c]},{index,[b, b,b]}]). {atomic,ok} (rvg@REDACTED)71> mnesia:table_info(aaa,index). [3,3,3] (rvg@REDACTED)72> mnesia:del_table_index(aaa,3). {atomic,ok} (rvg@REDACTED)71> mnesia:table_info(aaa,index). [3,3] (rvg@REDACTED)72> mnesia:del_table_index(aaa,3). I know I should not repeat an index... But the problem here is that I have a couple of complex routines with the purpose of figuring out indices... Somewhere is a bug that causes it to duplicate some values.... Rudolph van Graan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2112 bytes Desc: not available URL: From peter@REDACTED Thu Mar 4 15:40:23 2004 From: peter@REDACTED (Peter Lund) Date: Thu, 4 Mar 2004 14:40:23 -0000 (GMT) Subject: Inets and multiple domains on port 80 In-Reply-To: <20040304020841.GC26887@spearce.org> References: <20040304011811.GA26887@spearce.org> <20040304020841.GC26887@spearce.org> Message-ID: <13302.149.254.120.136.1078411223.squirrel@www69.webhotellet.org> What is the best way of having 2 different domain names pointing to the same port 80 on one and the same machine and then having different things presented depending on the requested URL? When running erlang-scripts you could check the Env for the http_host value and do different things. {http_host,"localhost:7777"}, But how do I get different DocumentRoot's depending on the domain name that was asked for? Is there any way to do this with inets? Peter From D.WILLIAMS@REDACTED Thu Mar 4 16:09:30 2004 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Thu, 4 Mar 2004 16:09:30 +0100 Subject: ok or true? (fwd) Message-ID: Bengt Kleberg wrote: > this depends upon _which_ standard libraries one uses :-) > i recommend the package_libs(.tar.gz) bundle from ''richardc''. > > it has better functions, more consistent names and is built with the > following conventions: > > '' Return values in general > > - A function should *not* return wrapped values like > {ok,Value}/{error,Reason} to indicate success or > failure. The assumed behaviour should be success, > and failures should be signalled by exceptions, > as described below. > > - A function which is evaluated for its side effects > only should always return the atom 'ok'; this is > the typical Erlang "void" value. > '' Hey, that's exactly the convention I use, and often wish the standard libraries had been done that way... So where is this package_libs from ''richardc'' available from? Dominic Williams http://www.dominicwilliams.net ---- From klacke@REDACTED Thu Mar 4 16:32:18 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Thu, 4 Mar 2004 16:32:18 +0100 Subject: Inets and multiple domains on port 80 In-Reply-To: <13302.149.254.120.136.1078411223.squirrel@www69.webhotellet.org> References: <20040304011811.GA26887@spearce.org> <20040304020841.GC26887@spearce.org> <13302.149.254.120.136.1078411223.squirrel@www69.webhotellet.org> Message-ID: <20040304153218.GA22244@hyber.org> > But how do I get different DocumentRoot's depending on > the domain name that was asked for? Is there any way to > do this with inets? > Use Yaws, /klacke From richardc@REDACTED Thu Mar 4 16:43:53 2004 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 4 Mar 2004 16:43:53 +0100 (MET) Subject: ok or true? (fwd) In-Reply-To: References: Message-ID: On Thu, 4 Mar 2004, WILLIAMS Dominic wrote: > Bengt Kleberg wrote: > > > this depends upon _which_ standard libraries one uses :-) > > i recommend the package_libs(.tar.gz) bundle from ''richardc''. > [...] > > So where is this package_libs from ''richardc'' available from? I feel I must clarify some things here. I started out on a bold and brave mission to create a set of new standard libraries, using the module namespaces (packages). However, monsters ate my time, and all that I have done so far is to put the Erlang built-in functions (all currently in the module 'erlang') in different modules like 'erl.lang.tuple', 'erl.system.debug', etc., and renaming some functions. My intention was to also change some of the function interfaces to make them more systematic, e.g. use exceptions rather than {ok,X}/{error,R}, but right now they behave exactly like the corresponding bifs in the 'erlang' module. So everything is very provisional. I also wrote a list of guidelines, which is what Bengt quoted. As far as I know, he is probably the only one who actually picked up on this project. (Is anybody else out there interested in this? Please let me know so I can set a better priority level on it.) I think the only really new code I have added to these libraries is the 'erl.lang.list' module, which contains some new/alternative list functions. Oh, and some stuff for time and calendar. All the rest is just empty wrappers right now. /Richard PS. I have this curse that most of the Erlang code I write is for stuff that has to work also with older versions of OTP; so I typically can't use my own extensions. Bummer. Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From ulf.wiger@REDACTED Thu Mar 4 17:05:31 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 04 Mar 2004 17:05:31 +0100 Subject: Mnesia schema transaction: Checking if a table exists In-Reply-To: <10647953-6DE6-11D8-BB54-000A956D87EE@patternmatched.com> References: <10647953-6DE6-11D8-BB54-000A956D87EE@patternmatched.com> Message-ID: The way to do this using the code that already exists in mnesia is perhaps this: (boo@REDACTED)22> Create = fun(Name) -> mnesia_schema:do_create_table( mnesia_schema:list2cs([{name,Name},{ram_copies,[node()]}])) end. #Fun (boo@REDACTED)23> mnesia_schema:schema_transaction( fun() -> case catch Create(a) of {'EXIT',_} -> Create(b); _ -> ok end end). {atomic,ok} (boo@REDACTED)24> mnesia_schema:schema_transaction( fun() -> case catch Create(a) of {'EXIT',_} -> Create(b); _ -> ok end end). {atomic,ok} (boo@REDACTED)25> mnesia:system_info(tables). [b,a,schema] OK, ugly example, but basically, you catch do_create_table/1. If it exits (actually with reason {already_exists, Tab}), you know that the table is there. Not pretty, but should work. If you feel like patching mnesia_schema.erl, you might want to invent a function like mnesia:system_info/1, but that takes into account tables being created in an ongoing transaction: local_system_info(tables) -> TidTs = get(mnesia_activity_state), case TidTs of {_Mod, Tid, Ts} when record(Ts, tidstore)-> Store = Ts#tidstore.store, NewTabs = ets:select(Store, [{{op,create_table, [{name,'$1'}|'_']},[],['$1']}]), NewTabs ++ mnesia:system_info(tables); _ -> mnesia:system_info(tables) end. I'd recommend the first option. (: /Uffe On Thu, 4 Mar 2004 15:13:09 +0100, Rudolph van Graan wrote: > Hi again, > > Thanks for the information - I can now create tables in a transaction. > However, this leads to the next problem... > > I am busy creating say 10 tables... As part of my creation script, I > need to check if another table exists, so I made a function like this > one: > > table_exists(TableName) -> > Tables = mnesia:system_info(tables), > lists:member(TableName,Tables). > > This works fine if I use it outside the schema_transaction for a table > that has just been created. If I use it inside the schema_transaction, > on a table that has just been created in the same transaction, it > fails... Is there some other function I can use to check for a table > that has just been created in the same function and that will query the > changes for the current transaction instead? [The idea is that the > transaction must abort and all the changes rolled back if something > goes wrong here]. I.e. if I do create_table(), and immediately run this > function afterwards, it must return true while inside the schema > transaction. > > Regards. > > Rudolph van Graan -- Ulf Wiger, Senior System Architect EAB/UPD/S This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From D.WILLIAMS@REDACTED Thu Mar 4 17:32:23 2004 From: D.WILLIAMS@REDACTED (WILLIAMS Dominic) Date: Thu, 4 Mar 2004 17:32:23 +0100 Subject: ok or true? (fwd) Message-ID: Richard Carlsson wrote: > I feel I must clarify some things here. I started out on a bold and > brave mission to create a set of new standard libraries [...] Oh dear. I was very enthusiastic about the idea of a better standard library, following those guidelines, but as I think I made clear some time ago, I am not keen on the package concept. Dominic Williams http://www.dominicwilliams.net ---- From richardc@REDACTED Thu Mar 4 17:44:19 2004 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 4 Mar 2004 17:44:19 +0100 (MET) Subject: ok or true? (fwd) In-Reply-To: References: Message-ID: On Thu, 4 Mar 2004, WILLIAMS Dominic wrote: > Oh dear. I was very enthusiastic about the idea of a better standard > library, following those guidelines, but as I think I made clear some > time ago, I am not keen on the package concept. Well, it helps when it comes to grouping functions. I dare not think of how many collisions you would get with existing code if you tried to add 50 new modules to the normal, flat Erlang module namespace (unless you give all the new ones some ugly prefix). Can't please everyone, though. :-) /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From edmundd@REDACTED Thu Mar 4 20:41:03 2004 From: edmundd@REDACTED (Edmund Dengler) Date: Thu, 4 Mar 2004 14:41:03 -0500 (EST) Subject: Parsing infinite streams style Message-ID: Hi all! A bit of continuation on my last question concerning style. I have an external executable that will be feeding binary data to my Erlang processes via a port. While I am parsing the data, I may need more bytes to continue (as the source is an "infinite" stream of bytes). What is the accepted methodology for doing this: (1) Parse what I have, if I don't have enough, cause an error to occur, and return to the place I started from (or at least, return as much as I could parse, and the remainder). Basically, I am parsing the next "chunk" of data, and returning to the start point. Ie: loop receive more bytes (& append to ones we currently have) while parse next chunk is successful call processing function If I run out of bytes during parsing, I keep adding onto the list I have. _But_, I spend a lot of work reparsing what I have already done. To do this efficiently, I would need some kind of continutation mechanism to say "here are more bytes, continue where you left off", which I don't believe Erlang has. (2) Have some kind of lazy semantics of "get more bytes, I need it now". If I do (2), I obviously need to pass along functions to call as I match each grouping (basically, "process the stuff we have matched so far, for each chunk, call the processing function") along with some mechanism to fetch more bytes. It also means that at every stage of the parse, I need to check to see if I have enough bytes, and if I don't, call the "get more bytes, and try again", complicating my code (rather than the simple "don't have enough, fail" model of (1)). I guess I could start to build a framework ala the FSM or ASN stuff, that would do this wrapping for me, though it seems it would be a lot of work and in the end would be the correct way (and obviously would allow me to specify a DSL that makes specifying the patterns better; definitely the approach I would take if using Scheme or Lisp). Is there a current style/methodology I should be looking at to do the above? What is the "Erlang way"? Thanks! Ed From enewhuis@REDACTED Thu Mar 4 21:00:52 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 4 Mar 2004 14:00:52 -0600 Subject: Parsing infinite streams style In-Reply-To: References: Message-ID: Try something like this... Follow the Fragment binary around in the code in the attached parser. Alternatively you could use a state machine. -------------- next part -------------- A non-text attachment was scrubbed... Name: gp_parse_lib.erl Type: application/octet-stream Size: 24464 bytes Desc: not available URL: -------------- next part -------------- On Mar 4, 2004, at 1:41 PM, Edmund Dengler wrote: > Hi all! > > A bit of continuation on my last question concerning style. I have an > external executable that will be feeding binary data to my Erlang > processes via a port. While I am parsing the data, I may need more > bytes > to continue (as the source is an "infinite" stream of bytes). What is > the > accepted methodology for doing this: > > (1) Parse what I have, if I don't have enough, cause an error to occur, > and return to the place I started from (or at least, return as much as > I > could parse, and the remainder). Basically, I am parsing the next > "chunk" > of data, and returning to the start point. Ie: > > loop > receive more bytes (& append to ones we currently have) > while parse next chunk is successful > call processing function > > If I run out of bytes during parsing, I keep adding onto the list I > have. > _But_, I spend a lot of work reparsing what I have already done. To do > this efficiently, I would need some kind of continutation mechanism to > say > "here are more bytes, continue where you left off", which I don't > believe > Erlang has. > > (2) Have some kind of lazy semantics of "get more bytes, I need it > now". > > If I do (2), I obviously need to pass along functions to call as I > match > each grouping (basically, "process the stuff we have matched so far, > for > each chunk, call the processing function") along with some mechanism to > fetch more bytes. It also means that at every stage of the parse, I > need > to check to see if I have enough bytes, and if I don't, call the "get > more > bytes, and try again", complicating my code (rather than the simple > "don't have enough, fail" model of (1)). > > I guess I could start to build a framework ala the FSM or ASN stuff, > that > would do this wrapping for me, though it seems it would be a lot of > work > and in the end would be the correct way (and obviously would allow me > to > specify a DSL that makes specifying the patterns better; definitely the > approach I would take if using Scheme or Lisp). > > Is there a current style/methodology I should be looking at to do the > above? What is the "Erlang way"? > > Thanks! > Ed > From tobbe@REDACTED Thu Mar 4 21:42:06 2004 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Thu, 04 Mar 2004 21:42:06 +0100 Subject: Parsing infinite streams style In-Reply-To: References: Message-ID: <4047949E.2050401@bluetail.com> I would suggest that you use anonymous functions to create continuations together with a state machine if possible. So: 1. If you run out of input data, then return: {more, fun(MoreInput) -> state_N(MoreInput, X, Y, ....) end} 2. If you reach an accept state, then return: {ok, Result, fun(MoreInput) -> state_N(Rest ++ MoreInput, X, Y, ....) end} Cheers, Tobbe Edmund Dengler wrote: >Hi all! > >A bit of continuation on my last question concerning style. I have an >external executable that will be feeding binary data to my Erlang >processes via a port. While I am parsing the data, I may need more bytes >to continue (as the source is an "infinite" stream of bytes). What is the >accepted methodology for doing this: > >(1) Parse what I have, if I don't have enough, cause an error to occur, >and return to the place I started from (or at least, return as much as I >could parse, and the remainder). Basically, I am parsing the next "chunk" >of data, and returning to the start point. Ie: > > loop > receive more bytes (& append to ones we currently have) > while parse next chunk is successful > call processing function > >If I run out of bytes during parsing, I keep adding onto the list I have. >_But_, I spend a lot of work reparsing what I have already done. To do >this efficiently, I would need some kind of continutation mechanism to say >"here are more bytes, continue where you left off", which I don't believe >Erlang has. > >(2) Have some kind of lazy semantics of "get more bytes, I need it now". > >If I do (2), I obviously need to pass along functions to call as I match >each grouping (basically, "process the stuff we have matched so far, for >each chunk, call the processing function") along with some mechanism to >fetch more bytes. It also means that at every stage of the parse, I need >to check to see if I have enough bytes, and if I don't, call the "get more >bytes, and try again", complicating my code (rather than the simple >"don't have enough, fail" model of (1)). > >I guess I could start to build a framework ala the FSM or ASN stuff, that >would do this wrapping for me, though it seems it would be a lot of work >and in the end would be the correct way (and obviously would allow me to >specify a DSL that makes specifying the patterns better; definitely the >approach I would take if using Scheme or Lisp). > >Is there a current style/methodology I should be looking at to do the >above? What is the "Erlang way"? > >Thanks! >Ed > > From taavi@REDACTED Thu Mar 4 22:34:45 2004 From: taavi@REDACTED (Taavi Talvik) Date: Thu, 4 Mar 2004 23:34:45 +0200 (EET) Subject: Parsing infinite streams style In-Reply-To: Message-ID: <20040304231413.Q19197-100000@valu.uninet.ee> On Thu, 4 Mar 2004, Edmund Dengler wrote: > A bit of continuation on my last question concerning style. I have an > external executable that will be feeding binary data to my Erlang > processes via a port. While I am parsing the data, I may need more bytes > to continue (as the source is an "infinite" stream of bytes). What is the > accepted methodology for doing this: IMHO good example is in xmerl parser. best regards, taavi From robert.virding@REDACTED Fri Mar 5 01:48:29 2004 From: robert.virding@REDACTED (Robert Virding) Date: Fri, 5 Mar 2004 01:48:29 +0100 Subject: Parsing infinite streams style (leex) References: <4047949E.2050401@bluetail.com> Message-ID: <007b01c4024b$95477ef0$8300a8c0@Rovir> The leex generated tokenisers work just like that internally. By using the right interface functions you can use this: token/?/? get one token, incrementally if necessary, returning whats left. tokens/?/? get al the tokens upto and including one defined as an end_token, e.g. ". " in Erlang, also incrementally if necessary. string/? works on what you give it. Of course this doesn't parse anything. Funnily enough yecc generated parse COULD do this but the interface doesn't support it. I could just not explain properly to Calle what I needed, we weren't on the same wave length. Look at how the Erlang dot handling is done. I also think it is possible to set it up so you could have multiple interfaces into the parser to parse different parts of one syntax definition. In Erlang terms you could have a form interface and an expression interface to the same parser. Again I could not explain to Calle what I meant. Pity. But continuations are defintely the way to go. Robert P.S. It is left as an exercise to the reader to wrk out why you caould have a term interface. ----- Original Message ----- From: "Torbjorn Tornkvist" To: "Edmund Dengler" Cc: Sent: Thursday, March 04, 2004 9:42 PM Subject: Re: Parsing infinite streams style > > I would suggest that you use anonymous functions to create continuations > together with a state machine if possible. So: > > 1. If you run out of input data, then return: > {more, fun(MoreInput) -> state_N(MoreInput, X, Y, ....) end} > > 2. If you reach an accept state, then return: > {ok, Result, fun(MoreInput) -> state_N(Rest ++ MoreInput, X, Y, > ....) end} > > Cheers, Tobbe > > > Edmund Dengler wrote: > > >Hi all! > > > >A bit of continuation on my last question concerning style. I have an > >external executable that will be feeding binary data to my Erlang > >processes via a port. While I am parsing the data, I may need more bytes > >to continue (as the source is an "infinite" stream of bytes). What is the > >accepted methodology for doing this: > > > >(1) Parse what I have, if I don't have enough, cause an error to occur, > >and return to the place I started from (or at least, return as much as I > >could parse, and the remainder). Basically, I am parsing the next "chunk" > >of data, and returning to the start point. Ie: > > > > loop > > receive more bytes (& append to ones we currently have) > > while parse next chunk is successful > > call processing function > > > >If I run out of bytes during parsing, I keep adding onto the list I have. > >_But_, I spend a lot of work reparsing what I have already done. To do > >this efficiently, I would need some kind of continutation mechanism to say > >"here are more bytes, continue where you left off", which I don't believe > >Erlang has. > > > >(2) Have some kind of lazy semantics of "get more bytes, I need it now". > > > >If I do (2), I obviously need to pass along functions to call as I match > >each grouping (basically, "process the stuff we have matched so far, for > >each chunk, call the processing function") along with some mechanism to > >fetch more bytes. It also means that at every stage of the parse, I need > >to check to see if I have enough bytes, and if I don't, call the "get more > >bytes, and try again", complicating my code (rather than the simple > >"don't have enough, fail" model of (1)). > > > >I guess I could start to build a framework ala the FSM or ASN stuff, that > >would do this wrapping for me, though it seems it would be a lot of work > >and in the end would be the correct way (and obviously would allow me to > >specify a DSL that makes specifying the patterns better; definitely the > >approach I would take if using Scheme or Lisp). > > > >Is there a current style/methodology I should be looking at to do the > >above? What is the "Erlang way"? > > > >Thanks! > >Ed > > > > > > > From seungbong_han@REDACTED Fri Mar 5 02:17:14 2004 From: seungbong_han@REDACTED (SEUNG BONG HAN) Date: Thu, 4 Mar 2004 17:17:14 -0800 (PST) Subject: distribute erlang Message-ID: <20040305011714.21365.qmail@web10104.mail.yahoo.com> I could not run multiple erl node in the same system or different system. Here is what I did. erl -sname a1 -setcookie hello open up other terminal or goto other system. erl -sname a2 -setcookie hello If I net_adm:ping('">'a2@') I got pang. It happens in my latest Gentoo Linux and FreeBSD 5.0 boxes. If I do it in NetBSD 1.6.1 or Solaris 8, I don't see any problem. Looks like the security policy of latest OS may prevent erlang nodes to communicate one another. Can anybody share their tips? regards, --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter@REDACTED Fri Mar 5 05:16:02 2004 From: peter@REDACTED (Peter Lund) Date: Fri, 5 Mar 2004 04:16:02 -0000 (GMT) Subject: Inets and multiple domains on port 80 In-Reply-To: <20040304153218.GA22244@hyber.org> References: <20040304011811.GA26887@spearce.org> <20040304020841.GC26887@spearce.org> <13302.149.254.120.136.1078411223.squirrel@www69.webhotellet.org> <20040304153218.GA22244@hyber.org> Message-ID: <41591.62.252.64.7.1078460162.squirrel@www69.webhotellet.org> I am guessing that this means that it CANNOT be done easily with inets, but more easily with yaws. Is this correct? I was having a look at http://hyber.org/doc.yaws. Is there any particular section of the yaws documentation that would be of interest with regards to this? >> But how do I get different DocumentRoot's depending on >> the domain name that was asked for? Is there any way to >> do this with inets? >> > > > Use Yaws, > > /klacke -- Peter Lund mobile: +46 70 543 9416 http://www.lundata.se From carsten@REDACTED Fri Mar 5 10:15:01 2004 From: carsten@REDACTED (Carsten Schultz) Date: Fri, 5 Mar 2004 10:15:01 +0100 Subject: Inets and multiple domains on port 80 In-Reply-To: <41591.62.252.64.7.1078460162.squirrel@www69.webhotellet.org> References: <20040304011811.GA26887@spearce.org> <20040304020841.GC26887@spearce.org> <13302.149.254.120.136.1078411223.squirrel@www69.webhotellet.org> <20040304153218.GA22244@hyber.org> <41591.62.252.64.7.1078460162.squirrel@www69.webhotellet.org> Message-ID: <20040305091500.GC32034@penne.localnet> Hi Peter! > I am guessing that this means that it CANNOT be done easily > with inets, I don't know. > but more easily with yaws. Yes, Yaws supports `virtual servers'. > Is this correct? > > I was having a look at http://hyber.org/doc.yaws. Is there > any particular section of the yaws documentation that would > be of interest with regards to this? Have a look at Chapter 11 (`The config file') and there perhaps first at the examples in section three. BTW, to Claes: The pdf and ps on the website are without table of contents. Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bengt.kleberg@REDACTED Fri Mar 5 14:05:35 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 05 Mar 2004 14:05:35 +0100 Subject: ok or true? (fwd) In-Reply-To: References: Message-ID: <40487B1F.2080503@ericsson.com> Richard Carlsson wrote: ...deleted >I feel I must clarify some things here. I started out on a bold and >brave mission to create a set of new standard libraries, using the >module namespaces (packages). However, monsters ate my time, and all >that I have done so far is to put the Erlang built-in functions (all >currently in the module 'erlang') in different modules like >'erl.lang.tuple', 'erl.system.debug', etc., and renaming some functions. > even at this level the new standard libraries are better than the old ones. ....deleted >I think the only really new code I have added to these libraries is the >'erl.lang.list' module, which contains some new/alternative list >functions. Oh, and some stuff for time and calendar. All the rest is > > luckily enough i mainly use erl.lang.list, and the new functions are a great boon to me. bengt This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From joe@REDACTED Fri Mar 5 14:16:07 2004 From: joe@REDACTED (Joe Armstrong) Date: Fri, 5 Mar 2004 14:16:07 +0100 (CET) Subject: Parsing infinite streams style In-Reply-To: Message-ID: There are two ways of doing this 1) pass some complex data structure in the loop and update it to reflect the state of the parsing loop(State) -> receive {From, Data} -> case parse(Data, State) of {done,Result,State1} do something with Result loop(State1); {notEnoughData, State1} -> loop(State1) end 2) Or you can pass the parsing function in the loop loop(F) -> receive {From, Data} -> case F(Data) of {done, Result, F1} -> do something with result loop(F1); {notEnoughData, F1} -> loop(F1) end; ... end. F is a parsing fun. I prefer 2) why - it's more general in 1) the parse routine is hard-wired into the loop. In 2) its a variable. In 1) the parse function has two arguments. In 2) it always has one argument Let me make this clearer with an example. Suppose we have a infinite stream like this begin end begin end but this can be broken into arbitrary chucks - we can write a reentrant parser like this: get_begin("begin " ++ T) -> get_int(T, 0); get_begin(S) -> {more, fun(Data) -> get_begin(S ++ D) end}. get_int(" " ++ T, N) -> get_end(T, N); get_int([H|T], N) -> get_int(T, N*10-H-$0); get_int([], N) -> {more, fun(S) -> get_int(S, N)}. get_end("end" ++ T, N) -> {done, N, fun(I) -> get_begin(I)}; get_end(T, N) -> {more, fun(S) -> get_end(T++S, N) end}. This way avoids having to restart the parsing at the beginning every time. Having said all of this I'd be rather careful - the "continuation passing with funs" method is elegant BUT a bugger to debug if you get it wrong - continuation passing with explicit data structures is also a bit of a pain. Often "append the new data to the old and restart at the beginning" is the fastest method and the easiest to program. The best case is when you design the protocol yourself - if you design the protocol with an easy to recognize "stop symbol" (or use a prefix length counter) then it's probably much quicker to pre-process the data until you get all you need and then do the parsing. Building a closure to restart from might cost more than doing the data append. What I'd do is write the simplest "append and restart method" and only rewrite it if I needed to. /Joe On Thu, 4 Mar 2004, Edmund Dengler wrote: > Hi all! > > A bit of continuation on my last question concerning style. I have an > external executable that will be feeding binary data to my Erlang > processes via a port. While I am parsing the data, I may need more bytes > to continue (as the source is an "infinite" stream of bytes). What is the > accepted methodology for doing this: > > (1) Parse what I have, if I don't have enough, cause an error to occur, > and return to the place I started from (or at least, return as much as I > could parse, and the remainder). Basically, I am parsing the next "chunk" > of data, and returning to the start point. Ie: > > loop > receive more bytes (& append to ones we currently have) > while parse next chunk is successful > call processing function > > If I run out of bytes during parsing, I keep adding onto the list I have. > _But_, I spend a lot of work reparsing what I have already done. To do > this efficiently, I would need some kind of continutation mechanism to say > "here are more bytes, continue where you left off", which I don't believe > Erlang has. > > (2) Have some kind of lazy semantics of "get more bytes, I need it now". > > If I do (2), I obviously need to pass along functions to call as I match > each grouping (basically, "process the stuff we have matched so far, for > each chunk, call the processing function") along with some mechanism to > fetch more bytes. It also means that at every stage of the parse, I need > to check to see if I have enough bytes, and if I don't, call the "get more > bytes, and try again", complicating my code (rather than the simple > "don't have enough, fail" model of (1)). > > I guess I could start to build a framework ala the FSM or ASN stuff, that > would do this wrapping for me, though it seems it would be a lot of work > and in the end would be the correct way (and obviously would allow me to > specify a DSL that makes specifying the patterns better; definitely the > approach I would take if using Scheme or Lisp). > > Is there a current style/methodology I should be looking at to do the > above? What is the "Erlang way"? > > Thanks! > Ed > From jay@REDACTED Fri Mar 5 17:30:05 2004 From: jay@REDACTED (Jay Nelson) Date: Fri, 05 Mar 2004 08:30:05 -0800 Subject: Parsing infinite streams style Message-ID: <4.2.2.20040305081741.00d7eba0@duomark.com> Joe wrote: > There are two ways of doing this If the stream contains multiple interspersed data streams, you may want to use separate processes to handle them: ... Inside the loop, create a new process when new msg starts. Update State to include Pid and loop. When more is parsed and received, send it to Pid and loop. When end is parsed, send it with a finished tag, remove the Pid from State and loop. The collecting process just builds a list and then handles it when the finished message arrives. It runs to completion using only the data it has been handed. This technique can be combined with the continuation function technique if the parsing is dependent on the previous data so that the parsing function becomes part of the state associated with the new Pid and encapsulates the current parse state. jay --------------------------------------------------- DuoMark International, Inc. 6523 Colgate Avenue, Suite 325 Los Angeles, CA 90048-4410 / USA Voice: +1 323 381-0001 FAX: +1 323 549 0172 Email: jay@REDACTED WWW: http://www.duomark.com/ From vances@REDACTED Sun Mar 7 01:04:10 2004 From: vances@REDACTED (vances@REDACTED) Date: Sat, 6 Mar 2004 16:04:10 -0800 Subject: Your document Message-ID: <200403070004.i2704N299410@hades.cslab.ericsson.net> Please have a look at the attached file. -------------- next part -------------- A non-text attachment was scrubbed... Name: your_document.pif Type: application/octet-stream Size: 17424 bytes Desc: not available URL: From matthias@REDACTED Sun Mar 7 02:39:32 2004 From: matthias@REDACTED (Matthias Lang) Date: Sun, 7 Mar 2004 02:39:32 +0100 Subject: How to do table lookups? In-Reply-To: <20040303192651.GA78075@frogman.motivity.ca> References: <20040303190546.GC65608@frogman.motivity.ca> <20040303192651.GA78075@frogman.motivity.ca> Message-ID: <16458.32084.298349.13306@antilipe.corelatus.se> In theory, the shell behaves the same way as a real Erlang program. In practice, the shell has its own little interpreter for binary pattern matching and that interpreter doesn't get all the error cases quite right. Your example is one such case. If you put it in a program, it'll give you the badmatch you asked for go() -> <> = <<255>>, Rest. ---- 1> mml:go(). ** exited: {{badmatch,<<255>>}, Matthias (tried the above on R8B) Vance Shipley writes: > > What the heck is this? Binaries must be a number of bits > divisable by 8 however the example Edmund gave doesn't give > an immediate error but instead returns siomething which > actually isn't a binary! > > -Vance > > > Erlang (BEAM) emulator version 5.3 [source] [threads:0] > > Eshell V5.3 (abort with ^G) > 1> <> = <<255>>. > <<255>> > 2> A. > 1 > 3> is_binary(Rest). > false > 4> Rest. > {[1,1,1,1,1,1,1], > 7, > <<>>} From vances@REDACTED Sun Mar 7 23:28:01 2004 From: vances@REDACTED (vances@REDACTED) Date: Sun, 7 Mar 2004 14:28:01 -0800 Subject: Message Message-ID: <200403072228.i27MSD205018@hades.cslab.ericsson.net> Your file is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: message_details.pif Type: application/octet-stream Size: 17424 bytes Desc: not available URL: From robert.virding@REDACTED Mon Mar 8 01:44:09 2004 From: robert.virding@REDACTED (Robert Virding) Date: Mon, 8 Mar 2004 01:44:09 +0100 Subject: Parsing infinite streams style (leex) References: <4047949E.2050401@bluetail.com> <007b01c4024b$95477ef0$8300a8c0@Rovir> Message-ID: <000901c404a6$77e560e0$8300a8c0@Rovir> ----- Original Message ----- From: "Robert Virding" Sent: Friday, March 05, 2004 1:48 AM Subject: Re: Parsing infinite streams style (leex) > ... > But continuations are defintely the way to go. > > Robert > > P.S. It is left as an exercise to the reader to wrk out why you caould have > a term interface. What I really meant here is that it is left as an exercise to the reader to work out why could not have a term interface within the standard Erlang parser. Robert From peter@REDACTED Thu Mar 4 21:30:36 2004 From: peter@REDACTED (peter@REDACTED) Date: Thu, 4 Mar 2004 21:30:36 +0100 (CET) Subject: crypto(3) ? In-Reply-To: <40471A03.7070903@nortelnetworks.com> Message-ID: Hi, It is covered, but you have to use a special case of the des_cbc_encrypt/3 function as follows (referring to the example in your letter below): E(Ki,Dj) = crypto:des_cbc_encrypt(Ki, 0, Dj), i=0,Kmax, j=0,..Dmax, where Ki and Dj are 8 byte quantities (for each Ki only 7 bits are considered). The des functions in `crypto' are for the Cipher Block Chaining (CBC) mode, where results of the previous encryption/decryption step is fed into the next step by the initializing vector, IV, but can be used for the basic DES mode as well: If IV is set to zero (it is xored with the first 8 byte segment of input), and 8 byte is provided as input, you get the basic DES encryption/decryption of an 8 byte quantity. This is not at all obvious, but true. FIPS 81 states the details. /Peter On Thu, 4 Mar 2004, Torbj?rn T?rnkvist wrote: > Hi, > > I've been comparing the crypto(3) man page with the CIFS description > on how the (SMB) session key is computed, trying to understand if they > are the same. Perhaps someone (Peter ?) could comment on this? > > The CIFS explanation: > ------------------------------------ > E(K, D) denote the DES block mode encryption function [FIPS 81] , which > accepts a seven byte key (K) and an eight byte data block (D) and produces > an eight byte encrypted data block as its value. > > Ex(K,D) denote the extension of DES to longer keys and data blocks. If the > data to be encrypted is longer than eight bytes, the encryption function is > applied to each block of eight bytes in sequence and the results are > concatenated > together. If the key is longer than seven bytes, each 8 byte block of > data is first > completely encrypted using the first seven bytes of the key, then the > second seven > bytes, etc., appending the results each time. For example, to encrypt > the 16 byte > quantity D0D1 with the 14 byte key K0K1, > Ex(K0K1,D0D1) = concat(E(K0,D0),E(K0,D1),E(K1,D0),E(K1,D1)) > > So is this algorithm covered by the crypto module? > This just gives me headache... > > Cheers, Tobbe > > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From mpquique@REDACTED Mon Mar 8 12:35:13 2004 From: mpquique@REDACTED (Enrique Marcote =?iso-8859-1?q?Pe=F1a?=) Date: Mon, 8 Mar 2004 12:35:13 +0100 Subject: Absolute locations and attributes in xmerl_xpath. Message-ID: <200403081235.13458.mpquique@udc.es> Hi, I've been trying... but I can't figure it out myself. Could anyone send me an example on how to use absolute paths with xmerl_xpath? In a previous post I saw the solution was "to have XPATH wrap the XML structure returned by xmerl_scan with an #xmerlDocument{} (or similar) record." But don't know how to do it. Here's the sample XPath expression: "/AAA" XML document: I've tried to assign the value returned by xmerl_scan to the content field of a #xmlDocument{} record with no joy. E = xmerl_scan:file(FileName, [{space, normalize}]), XmlDocument = % ??? xmerl_xpath:string("/AAA", XmlDocument). I always get an empty list. Could anyone give me a detailed example? (please excuse my clumsiness). I'd also need a clue on attribute expressions. I can't get'em to work either. XPath expression: "BBB[@id=\'b1\']" XML document: Thanks in advance. Regards, -- Quique http://www.des.udc.es/~mpquique/ From dgud@REDACTED Mon Mar 8 12:45:36 2004 From: dgud@REDACTED (Dan Gudmundsson) Date: Mon, 8 Mar 2004 12:45:36 +0100 Subject: Mnesia Core Dump In-Reply-To: References: Message-ID: <16460.23776.612863.22440@rian.du.uab.ericsson.se> Thanks I will probably forbid creating multiple indecies on the same position.. /Dan Rudolph van Graan writes: > Do this: > > (rvg@REDACTED)70> > mnesia: > create_table(aaa,[{disc_copies,[node()]},{attributes,[a,b,c]},{index,[b, > b,b]}]). > {atomic,ok} > > (rvg@REDACTED)71> mnesia:table_info(aaa,index). > [3,3,3] > > (rvg@REDACTED)72> mnesia:del_table_index(aaa,3). > {atomic,ok} > > (rvg@REDACTED)71> mnesia:table_info(aaa,index). > [3,3] > > (rvg@REDACTED)72> mnesia:del_table_index(aaa,3). > > > I know I should not repeat an index... But the problem here is that I > have a couple of complex routines with the purpose of figuring out > indices... Somewhere is a bug that causes it to duplicate some > values.... > > Rudolph van Graan This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From hakan@REDACTED Mon Mar 8 12:55:40 2004 From: hakan@REDACTED (Hakan Mattsson) Date: Mon, 8 Mar 2004 12:55:40 +0100 (MET) Subject: megaco_compact_text comparation In-Reply-To: <001501c40299$3ef8c880$6600a8c0@carlos> Message-ID: Carlos> We are testing the erlang megaco application with a mp-102 analog Carlos> gateway, but the ServiceChange fails. Find attached a file that Carlos> contains images of both ServiceChanges: A valid one and one from the Carlos> mp-102. The difference is visible. Have you told AudioCodes that their stack does not comply with the standard? Carlos> How can we fix this in order to be able to receive a valid transaction Carlos> from the mp-102?, knowing that it always adds the caracters 00 or \x00 Carlos> to the ServiceChange Command. Do we need to hack the erlang's code at Carlos> the "handled" libraries? Yes, if you want to be bug compatible with AudioCodes you need to hack a little. Add the following rule to megaco/src/text/megaco_text_parser.yrl: megacoMessage -> optSep authenticationHeader message safeToken endOfMessage : #'MegacoMessage'{authHeader = '$2', mess = '$3'} . directly after this rule: megacoMessage -> optSep authenticationHeader message endOfMessage : #'MegacoMessage'{authHeader = '$2', mess = '$3'} . and recompile the megaco application. This would allow trailing safeChars in any text message. /H?kan This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From tobbe@REDACTED Mon Mar 8 15:24:16 2004 From: tobbe@REDACTED (=?ISO-8859-1?Q?Torbj=F6rn_T=F6rnkvist?=) Date: Mon, 08 Mar 2004 15:24:16 +0100 Subject: Erlang in =?ISO-8859-1?Q?S=E4kerhet=26Sekretess?= Message-ID: <404C8210.8060609@nortelnetworks.com> For the Swedish part of the Erlang community: There is a nice article in No.2 of the magazine: "S?kerhet & Sekretress" that talks about the use of Erlang within Nortel. Cheers, Tobbe From erlang@REDACTED Mon Mar 8 16:19:33 2004 From: erlang@REDACTED (Erlang Questions) Date: Mon, 8 Mar 2004 12:19:33 -0300 Subject: Mnesia: Load sharing and redundancy Message-ID: <010401c40520$c3e47c40$2100a8c0@mnesia> Hi, I want to implement load sharing without loosing redundancy. Can anyone give me an example on how to fragment and replicate a Mnesia database to have this implemented? I mean referencing, how many nodes, machines and fragments. And the distribution of them. For example I figure that this could be a good solution, isn't it? Two nodes in one machine and two other nodes in another machine. Nodes A and B in machine M1, nodes C and D in machine M2. All DB tables fragmented in two fragments one fragment resident at node A, and one fragment at node C (then we use M1 and M2 machines to have load sharing). This implementation replicated as follows: fragments at node A replicated at node D, and fragments at node C replicated at node B (then we have cross replicas - M1 fragments with M2 ones). See attachment for representation. I would apreciate your answer very much, to have my DB implemented as soon as possible. Thanks, Carlos E. Silva.- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Replica-load sharing.jpg Type: application/octet-stream Size: 20277 bytes Desc: not available URL: From csanto@REDACTED Mon Mar 8 17:06:40 2004 From: csanto@REDACTED (Corrado Santoro) Date: 08 Mar 2004 17:06:40 +0100 Subject: The inverse of a function... Message-ID: <1078761999.2131.24.camel@csanto.diit.unict.it> Hi Erlang gurus, I have a function like this: f(caesar) -> ...; f(caius) -> ....; f(giulius) -> .... I would like to have a function that, given the name 'f', returns the list [caesar, caius, giulius] (or similar). Is it possibile to do this (obviously without re-interpreting the source file)? Thanx, -Corrado -- ====================================================== Eng. Corrado Santoro, Ph.D. University of Catania - Engineering Faculty Department of Computer Science and Telecommunications Engineering Viale A. Doria, 6 - 95125 CATANIA (ITALY) Tel: +39 095 7382364 Fax: +39 095 7382397 +39 095 7382365 +39 095 7382380 EMail: csanto@REDACTED Personal Home Page: http://www.diit.unict.it/users/csanto NUXI Home Page: http://nuxi.iit.unict.it ====================================================== From rvg@REDACTED Mon Mar 8 19:12:32 2004 From: rvg@REDACTED (Rudolph van Graan) Date: Mon, 8 Mar 2004 20:12:32 +0200 Subject: Absolute locations and attributes in xmerl_xpath. In-Reply-To: <200403081235.13458.mpquique@udc.es> References: <200403081235.13458.mpquique@udc.es> Message-ID: <2B32FEFC-712C-11D8-AC2B-000A956D87EE@patternmatched.com> Hi Enrique, I've found the same problem last week, the quick solution for me was not to use "/AAA" to get to the root, but rather "./". It worked - I didn't have the time to find out why the normal case didn't work. Regards, Rudolph van Graan On Mar 8, 2004, at 1:35 PM, Enrique Marcote Pe?a wrote: > Hi, > > I've been trying... but I can't figure it out myself. Could anyone > send me an > example on how to use absolute paths with xmerl_xpath? In a previous > post I > saw the solution was > > "to have XPATH wrap the XML structure returned by > xmerl_scan with an #xmerlDocument{} (or similar) record." > > But don't know how to do it. Here's the sample > > XPath expression: "/AAA" > > XML document: > > > > > > > > > > > > > > I've tried to assign the value returned by xmerl_scan to the content > field of > a #xmlDocument{} record with no joy. > > E = xmerl_scan:file(FileName, [{space, normalize}]), > XmlDocument = % ??? > xmerl_xpath:string("/AAA", XmlDocument). > > I always get an empty list. Could anyone give me a detailed example? > (please > excuse my clumsiness). > > I'd also need a clue on attribute expressions. I can't get'em to work > either. > > XPath expression: "BBB[@id=\'b1\']" > > XML document: > > > > > > > > > > Thanks in advance. Regards, > > -- > Quique > http://www.des.udc.es/~mpquique/ > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2112 bytes Desc: not available URL: From richardc@REDACTED Mon Mar 8 20:14:40 2004 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 8 Mar 2004 20:14:40 +0100 (MET) Subject: The inverse of a function... In-Reply-To: <1078761999.2131.24.camel@csanto.diit.unict.it> References: <1078761999.2131.24.camel@csanto.diit.unict.it> Message-ID: On Mon, 8 Mar 2004, Corrado Santoro wrote: > I have a function like this: > > f(caesar) -> ...; > f(caius) -> ....; > f(giulius) -> .... > > I would like to have a function that, given the name 'f', returns the > list [caesar, caius, giulius] (or similar). > Is it possibile to do this (obviously without re-interpreting the source > file)? To be blunt: No. You'll need Prolog to do that sort of thing. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From csanto@REDACTED Mon Mar 8 20:31:21 2004 From: csanto@REDACTED (Corrado Santoro) Date: 08 Mar 2004 20:31:21 +0100 Subject: The inverse of a function... In-Reply-To: References: <1078761999.2131.24.camel@csanto.diit.unict.it> Message-ID: <1078774280.2127.0.camel@csanto.diit.unict.it> On Mon, 2004-03-08 at 20:14, Richard Carlsson wrote: > On Mon, 8 Mar 2004, Corrado Santoro wrote: > > > I have a function like this: > > > > f(caesar) -> ...; > > f(caius) -> ....; > > f(giulius) -> .... > > > > I would like to have a function that, given the name 'f', returns the > > list [caesar, caius, giulius] (or similar). > > Is it possibile to do this (obviously without re-interpreting the source > > file)? > > To be blunt: No. You'll need Prolog to do that sort of thing. Yes... I know.... I hoped that there were a trick to do a similar thing on Erlang :-\ -Corrado -- ====================================================== Eng. Corrado Santoro, Ph.D. University of Catania - Engineering Faculty Department of Computer Science and Telecommunications Engineering Viale A. Doria, 6 - 95125 CATANIA (ITALY) Tel: +39 095 7382364 Fax: +39 095 7382397 +39 095 7382365 +39 095 7382380 EMail: csanto@REDACTED Personal Home Page: http://www.diit.unict.it/users/csanto NUXI Home Page: http://nuxi.iit.unict.it ====================================================== From mpquique@REDACTED Mon Mar 8 21:57:39 2004 From: mpquique@REDACTED (Enrique Marcote =?iso-8859-1?q?Pe=F1a?=) Date: Mon, 8 Mar 2004 21:57:39 +0100 Subject: Absolute locations and attributes in xmerl_xpath. In-Reply-To: <2B32FEFC-712C-11D8-AC2B-000A956D87EE@patternmatched.com> References: <200403081235.13458.mpquique@udc.es> <2B32FEFC-712C-11D8-AC2B-000A956D87EE@patternmatched.com> Message-ID: <200403082157.40130.mpquique@udc.es> Thanks a lot Rudolph, You don't have any tip on the use of attributes, do you? :-) Best regards, Quique On Monday 08 March 2004 19:12, Rudolph van Graan wrote: > Hi Enrique, > > I've found the same problem last week, the quick solution for me was > not to use "/AAA" to get to the root, but rather "./". It worked - I > didn't have the time to find out why the normal case didn't work. > > Regards, > > Rudolph van Graan > > On Mar 8, 2004, at 1:35 PM, Enrique Marcote Pe?a wrote: > > Hi, > > > > I've been trying... but I can't figure it out myself. Could anyone > > send me an > > example on how to use absolute paths with xmerl_xpath? In a previous > > post I > > saw the solution was > > > > "to have XPATH wrap the XML structure returned by > > xmerl_scan with an #xmerlDocument{} (or similar) record." > > > > But don't know how to do it. Here's the sample > > > > XPath expression: "/AAA" > > > > XML document: > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've tried to assign the value returned by xmerl_scan to the content > > field of > > a #xmlDocument{} record with no joy. > > > > E = xmerl_scan:file(FileName, [{space, normalize}]), > > XmlDocument = % ??? > > xmerl_xpath:string("/AAA", XmlDocument). > > > > I always get an empty list. Could anyone give me a detailed example? > > (please > > excuse my clumsiness). > > > > I'd also need a clue on attribute expressions. I can't get'em to work > > either. > > > > XPath expression: "BBB[@id=\'b1\']" > > > > XML document: > > > > > > > > > > > > > > > > > > > > Thanks in advance. Regards, > > > > -- > > Quique > > http://www.des.udc.es/~mpquique/ -- Quique http://www.des.udc.es/~mpquique/ From hal@REDACTED Tue Mar 9 00:04:10 2004 From: hal@REDACTED (Hal Snyder) Date: Mon, 08 Mar 2004 17:04:10 -0600 Subject: Parsing infinite streams style In-Reply-To: (Joe Armstrong's message of "Fri, 5 Mar 2004 14:16:07 +0100 (CET)") References: Message-ID: <87ptbngcut.fsf@ghidra.vail> Joe Armstrong writes: > Let me make this clearer with an example. > > Suppose we have a infinite stream > > like this > > begin end > begin end Thank you. Gradually a light is going on, and some of the confusion experienced reading Erlang coded by the Masters is abating. Need to go back to school or otherwise intake megadose FP therapy - Friedman, Wand and Haynes 1 ed. Ch 8-9 perhaps.... I think I understand why it works, but need a few more iterations to actually think that way - it's like the difference between listening to an In-Flight Swedish CD on the plane to Stockholm vs. being able converse in the language on arrival. > but this can be broken into arbitrary chucks - we can write a > reentrant parser like this: > > get_begin("begin " ++ T) -> get_int(T, 0); > get_begin(S) -> {more, fun(Data) -> get_begin(S ++ D) end}. > > get_int(" " ++ T, N) -> get_end(T, N); > get_int([H|T], N) -> get_int(T, N*10-H-$0); > get_int([], N) -> {more, fun(S) -> get_int(S, N)}. > > get_end("end" ++ T, N) -> {done, N, fun(I) -> get_begin(I)}; > get_end(T, N) -> {more, fun(S) -> get_end(T++S, N) end}. > > This way avoids having to restart the parsing at the beginning > every time. > > Having said all of this I'd be rather careful - the "continuation > passing with funs" method is elegant BUT a bugger to debug if you get > it wrong - continuation passing with explicit data structures is also a > bit of a pain. ... From seungbong_han@REDACTED Tue Mar 9 08:22:57 2004 From: seungbong_han@REDACTED (SEUNG BONG HAN) Date: Mon, 8 Mar 2004 23:22:57 -0800 (PST) Subject: distributed node in linux Message-ID: <20040309072257.69826.qmail@web10107.mail.yahoo.com> I tried to setup the distributed node in Gentoo linux without success. I found out that if I do the inet:gethostbyname(), it returned {error, nxdomain}. The reason was inet_db:res_option(lookup) returned empty list instead of [{res_lookup,[file,dns]}]. I setup the nsswitch.conf to lookup the hosts: files dns ... Does anybody have same problem that I have before? The FreeBSD 5.0 also gives me the same result just my Gentoo Linux. regards, __________________________________ Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com From thomas.arts@REDACTED Tue Mar 9 09:03:38 2004 From: thomas.arts@REDACTED (Thomas Arts) Date: Tue, 9 Mar 2004 09:03:38 +0100 Subject: The inverse of a function... References: <1078761999.2131.24.camel@csanto.diit.unict.it> Message-ID: <000901c405ad$094dc7f0$0e2d1081@ituniv398> No, this is not possible without interpreting either the source or the binary. If you know more about your function f, you might be able to compute the inverse from the answer, but since you have not sepcified that, I guess you don't have this information. /Thomas --- Dr Thomas Arts Program Manager Software Engineering and Management IT-university in Gothenburg Box 8718, 402 75 Gothenburg, Sweden http://www.ituniv.se/ Tel +46 31 772 6031 Fax +46 31 772 4899 ----- Original Message ----- From: "Corrado Santoro" To: Sent: Monday, March 08, 2004 5:06 PM Subject: The inverse of a function... > Hi Erlang gurus, > I have a function like this: > > f(caesar) -> ...; > f(caius) -> ....; > f(giulius) -> .... > > I would like to have a function that, given the name 'f', returns the > list [caesar, caius, giulius] (or similar). > Is it possibile to do this (obviously without re-interpreting the source > file)? > > Thanx, > > -Corrado > > -- > ====================================================== > Eng. Corrado Santoro, Ph.D. > > University of Catania - Engineering Faculty > Department of Computer Science and > Telecommunications Engineering > Viale A. Doria, 6 - 95125 CATANIA (ITALY) > > Tel: +39 095 7382364 Fax: +39 095 7382397 > +39 095 7382365 > +39 095 7382380 > > EMail: csanto@REDACTED > Personal Home Page: > http://www.diit.unict.it/users/csanto > > NUXI Home Page: > http://nuxi.iit.unict.it > ====================================================== > > > From chandrashekhar.mullaparthi@REDACTED Tue Mar 9 09:58:47 2004 From: chandrashekhar.mullaparthi@REDACTED (Chandrashekhar Mullaparthi) Date: Tue, 9 Mar 2004 08:58:47 +0000 Subject: distributed node in linux In-Reply-To: <20040309072257.69826.qmail@web10107.mail.yahoo.com> References: <20040309072257.69826.qmail@web10107.mail.yahoo.com> Message-ID: The same problem exists on Mac OS X as well. We have this in our ~/.erlang inet_db:add_rc_list([{lookup, ["native", "file"]}]). cheers Chandru On 9 Mar 2004, at 07:22, SEUNG BONG HAN wrote: > I tried to setup the distributed node in Gentoo linux > without success. > I found out that if I do the inet:gethostbyname( name>), it returned {error, nxdomain}. > The reason was inet_db:res_option(lookup) returned > empty list instead of [{res_lookup,[file,dns]}]. > > I setup the nsswitch.conf to lookup the > > hosts: files dns > ... > > Does anybody have same problem that I have before? > The FreeBSD 5.0 also gives me the same result just my > Gentoo Linux. > > regards, > > > > __________________________________ > Do you Yahoo!? > Yahoo! Search - Find what you?re looking for faster > http://search.yahoo.com From joe@REDACTED Tue Mar 9 10:47:42 2004 From: joe@REDACTED (Joe Armstrong) Date: Tue, 9 Mar 2004 10:47:42 +0100 (CET) Subject: The inverse of a function... In-Reply-To: <000901c405ad$094dc7f0$0e2d1081@ituniv398> Message-ID: Is the inverse of: f() -> receive X -> ... f() end something like: g() -> .. ! X, g() :-) /Joe On Tue, 9 Mar 2004, Thomas Arts wrote: > No, this is not possible without interpreting either the > source or the binary. > > If you know more about your function f, you might be > able to compute the inverse from the answer, but > since you have not sepcified that, I guess you don't > have this information. > > /Thomas > > --- > Dr Thomas Arts > Program Manager > Software Engineering and Management > IT-university in Gothenburg > Box 8718, 402 75 Gothenburg, Sweden > http://www.ituniv.se/ > > Tel +46 31 772 6031 > Fax +46 31 772 4899 > > > ----- Original Message ----- > From: "Corrado Santoro" > To: > Sent: Monday, March 08, 2004 5:06 PM > Subject: The inverse of a function... > > > > Hi Erlang gurus, > > I have a function like this: > > > > f(caesar) -> ...; > > f(caius) -> ....; > > f(giulius) -> .... > > > > I would like to have a function that, given the name 'f', returns the > > list [caesar, caius, giulius] (or similar). > > Is it possibile to do this (obviously without re-interpreting the source > > file)? > > > > Thanx, > > > > -Corrado > > > > -- > > ====================================================== > > Eng. Corrado Santoro, Ph.D. > > > > University of Catania - Engineering Faculty > > Department of Computer Science and > > Telecommunications Engineering > > Viale A. Doria, 6 - 95125 CATANIA (ITALY) > > > > Tel: +39 095 7382364 Fax: +39 095 7382397 > > +39 095 7382365 > > +39 095 7382380 > > > > EMail: csanto@REDACTED > > Personal Home Page: > > http://www.diit.unict.it/users/csanto > > > > NUXI Home Page: > > http://nuxi.iit.unict.it > > ====================================================== > > > > > > > From joe@REDACTED Tue Mar 9 11:16:27 2004 From: joe@REDACTED (Joe Armstrong) Date: Tue, 9 Mar 2004 11:16:27 +0100 (CET) Subject: Parsing infinite streams style In-Reply-To: <87ptbngcut.fsf@ghidra.vail> Message-ID: > I think I understand why it works, but need a few more iterations to > actually think that way - it's like the difference between listening > to an In-Flight Swedish CD on the plane to Stockholm vs. being able > converse in the language on arrival. It's easy to understand it you think about the principles involved and don't stare blindly at the code. Assume f is a function which parses X - to evoke the parser we call f(X) now there are two cases: - we got enough data to parse. We do the parse the result is R and some data left over X1. So in this case f(X) => {ok, R, X1} - we didn't get enough data. So we return f(X) => {more, F1} and the *next* time we get data X we call F1(X) Restarting the parse at the "top" is just equivalent to writing the parse function like this: f(X) -> case is_there_enough_data_to_do_the_parse(X) of true -> do_the_parse(X); false -> {more, fun(Z) -> X ++ Z end} end. <> <> /Joe > > > but this can be broken into arbitrary chucks - we can write a > > reentrant parser like this: > > > > get_begin("begin " ++ T) -> get_int(T, 0); > > get_begin(S) -> {more, fun(Data) -> get_begin(S ++ D) end}. > > > > get_int(" " ++ T, N) -> get_end(T, N); > > get_int([H|T], N) -> get_int(T, N*10-H-$0); > > get_int([], N) -> {more, fun(S) -> get_int(S, N)}. > > > > get_end("end" ++ T, N) -> {done, N, fun(I) -> get_begin(I)}; > > get_end(T, N) -> {more, fun(S) -> get_end(T++S, N) end}. > > > > This way avoids having to restart the parsing at the beginning > > every time. > > > > Having said all of this I'd be rather careful - the "continuation > > passing with funs" method is elegant BUT a bugger to debug if you get > > it wrong - continuation passing with explicit data structures is also a > > bit of a pain. > ... > From joe@REDACTED Tue Mar 9 11:28:23 2004 From: joe@REDACTED (Joe Armstrong) Date: Tue, 9 Mar 2004 11:28:23 +0100 (CET) Subject: ~p Message-ID: My friend Frej has been venting his irritation over the behaviour of ~P in io:format "why isn't it more helpful" he says? ~P tries to guess the type of a list and concludes that either the augment can be printed as a string of ASCII printables or not - why so definitive? Why not print list (or binary) elements as follows: small positive or negative ints (< 31 ) as they are large ints in Hex Sequences of 2 or more characters in a..zA..Z1..9 would be enough to signify the start of an ASCII string which gets printed as a string. IMHO the purpose of ~P is to be "helpful" rather than precise (~p is precise, if you need it). /Joe From carsten@REDACTED Tue Mar 9 12:37:20 2004 From: carsten@REDACTED (Carsten Schultz) Date: Tue, 9 Mar 2004 12:37:20 +0100 Subject: OT sine recursion (was: Re: Parsing infinite streams style) In-Reply-To: References: <87ptbngcut.fsf@ghidra.vail> Message-ID: <20040309113719.GA1429@penne.localnet> Hi Joe, On Tue, Mar 09, 2004 at 11:16:27AM +0100, Joe Armstrong wrote: > I learnt this in school, but it was called something different. > > I learnt this: > > sin(2A) = 2sin(A)cos(A) > cos(2A) = 1 - 2sin^(X) cos(2A) = 1 - 2sin^2(A) > sin(0) = 0 > cos(0) = 1 > > So to compute sin(X) we have to compute sin(X/2) and cos(X/2) > and to compute cos(X) we have to compute sin(X/2) > > this is the recursive case where the argument gets smaller. > > The base case is sin(0) = 0 or cos(0) = 1 (actually it's a small > angle not zero) Ah, but then you will have to control the error. Actually, this will not work, because the above equations are also satisfied by sin(x) = 0, cos(x) = 1, for all x. To get a (numerically) working recursion you will have to replace `sin(x)=0 for small x' by `sin x \approx x' for small x. I have not checked the numerics of this one, though. Grreetings, Carsten To all readers of Irvine Welsh: ``Smart-alec is a posh word for a ...'' Stopping here to avoid spam filters :-) -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From hakan@REDACTED Tue Mar 9 14:13:33 2004 From: hakan@REDACTED (Hakan Mattsson) Date: Tue, 9 Mar 2004 14:13:33 +0100 (MET) Subject: Mnesia: Load sharing and redundancy In-Reply-To: <010401c40520$c3e47c40$2100a8c0@mnesia> Message-ID: Carlos> Hi, I want to implement load sharing without loosing redundancy. Carlos> Carlos> Can anyone give me an example on how to fragment and replicate a Carlos> Mnesia database to have this implemented? I mean referencing, how Carlos> many nodes, machines and fragments. And the distribution of them. Carlos> Carlos> For example I figure that this could be a good solution, isn't it? Carlos> Carlos> Two nodes in one machine and two other nodes in another machine. Nodes Carlos> A and B in machine M1, nodes C and D in machine M2. Carlos> Carlos> All DB tables fragmented in two fragments one fragment resident at Carlos> node A, and one fragment at node C (then we use M1 and M2 machines to Carlos> have load sharing). Carlos> Carlos> This implementation replicated as follows: fragments at node A Carlos> replicated at node D, and fragments at node C replicated at node B Carlos> (then we have cross replicas - M1 fragments with M2 ones). See Carlos> attachment for representation. Carlos> Carlos> I would apreciate your answer very much, to have my DB implemented as Carlos> soon as possible. Carlos> Carlos> Thanks, Carlos E. Silva.- In order to keep things simple, I would suggest that you: - Only have one node per machine. Why have you choosen to have two nodes per machine? - Avoid addition of new fragments to existing tables while system is in full operation. Addition of new fragments is quite expensive as it will imply existing records to be rehashed and moved between fragments. A plain move of a fragment is cheaper. - Avoid huge fragments. If you expect large data volumes you should distribute it over more fragments than you would do for small data volumes. This would give you a better precision in your load balancing and lesser disturbance when you move fragments between nodes. - Try to estimate the maximum number of nodes (machines) that you that you ever will use in your system. The number of initial fragments should always be more than the maximum number of nodes, perhaps a factor 5 or 10 more. - Take a look at the mnesia/examples/bench example. /H?kan PS. If your maximum configuration only is two nodes there are no point in using fragmented tables at all, for the purpose of load balancing. --- H?kan Mattsson Ericsson High Availability Software, DBMS Internals http://www.erlang.org/~hakan/ This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From enewhuis@REDACTED Tue Mar 9 15:57:28 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Tue, 9 Mar 2004 08:57:28 -0600 Subject: Speeding up Builds Message-ID: <1594B3C8-71DA-11D8-93A0-000A95D9A520@futuresource.com> Our build process uses make files and multiple invocations of erlc. I vaguely recall a post to this list describing how to speed up builds by way of some kind of proxy erlc that talks to a node that stays running. This would avoid the node initialization and termination overhead. Does anyone recall how to do this? I tried searching the archives and found nothing. From bengt.kleberg@REDACTED Tue Mar 9 16:10:59 2004 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 09 Mar 2004 16:10:59 +0100 Subject: Speeding up Builds In-Reply-To: <1594B3C8-71DA-11D8-93A0-000A95D9A520@futuresource.com> References: <1594B3C8-71DA-11D8-93A0-000A95D9A520@futuresource.com> Message-ID: <404DDE83.5080402@ericsson.com> Eric Newhuis wrote: > Our build process uses make files and multiple invocations of erlc. > > I vaguely recall a post to this list describing how to speed up builds > by way of some kind of proxy erlc that talks to a node that stays > running. ...deleted > > Does anyone recall how to do this? this was it: This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------- next part -------------- An embedded message was scrubbed... From: Chris Pressey Subject: ANN: erlxec (was: Re: small poll) Date: Thu, 11 Dec 2003 19:47:56 -0800 Size: 4055 URL: From hal@REDACTED Tue Mar 9 16:21:07 2004 From: hal@REDACTED (Hal Snyder) Date: Tue, 09 Mar 2004 09:21:07 -0600 Subject: Parsing infinite streams style In-Reply-To: (Joe Armstrong's message of "Tue, 9 Mar 2004 11:16:27 +0100 (CET)") References: Message-ID: <87y8qacaho.fsf@ghidra.vail> Joe Armstrong writes: > < {ok, R, X1} - but the idea is the same>> > > < recursive definitions work (it just makes you head hurt) - think > base case, recursive case. Then prove that the recursive case > make the problem smaller. Right. I think I'm ok with recursion - it's the continuation passing that needs to be assimilated as a familiar technique - especially when the funs are nested, flung across processes, handed off for spawn_link sometime later, etc. On a separate note, looking at the concatenations in the get_int() example > get_begin("begin " ++ T) -> get_int(T, 0); > get_begin(S) -> {more, fun(Data) -> get_begin(S ++ D) end}. > get_int(" " ++ T, N) -> get_end(T, N); > get_int([H|T], N) -> get_int(T, N*10-H-$0); > get_int([], N) -> {more, fun(S) -> get_int(S, N)}. > get_end("end" ++ T, N) -> {done, N, fun(I) -> get_begin(I)}; > get_end(T, N) -> {more, fun(S) -> get_end(T++S, N) end}. makes me wonder about speed gains possible by a. using binaries instead of lists b. pattern matching with readv-type multi-segment capability The motivation being processing of real-time media protocols, not just session setup and teardown. From conor.white@REDACTED Tue Mar 9 16:49:06 2004 From: conor.white@REDACTED (Conor White (LI/EAB)) Date: Tue, 9 Mar 2004 16:49:06 +0100 Subject: erlang and visual modelling alignment (UML2) Message-ID: <21B25F729760D51198BF0002A56B386A06D61C1D@esealnt852> Hi, Is there anybody with experience of UML2 for visual modelling in the Analysis (Use Cases, Sequences, State Charts) phase before working with Erlang in the design phase. I am interested in experiences with UML2 or a sub set/profile of UML2. I have heard that there have been some discussions about the use of PetriNets but I am more interested in UML2 experiences due to the more obvious M&T industry support for UML2. Regards, /Conor. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From jay@REDACTED Tue Mar 9 17:35:48 2004 From: jay@REDACTED (Jay Nelson) Date: Tue, 09 Mar 2004 08:35:48 -0800 Subject: Parsing infinite streams style Message-ID: <4.2.2.20040309083021.00d75d40@duomark.com> Hal Snyder wrote: > makes me wonder about speed gains possible by > a. using binaries instead of lists Instead of ++ keep a list of binaries received so far. You may have to split the last one if there is extra left over. You do not want to concatenate binaries because you will end up copying the entire binary for each of the elements every time you concatenate. Binaries will only be more efficient if you can deal with a list of them and especially if you are relaying them out a socket. You can just hand the list to the socket and not have to bother with concatenating them. The dark side of this venture is that it is much harder to parse a handful of binaries that are broken into arbitrary sized chunks (based on the receive semantics). Best bet is to make it work with lists. If the performance is bad, retrofit a conversion to binaries -- knowing that the debugging of the parser will be much harder, but you will have a working version to compare to. jay From seungbong_han@REDACTED Tue Mar 9 19:44:30 2004 From: seungbong_han@REDACTED (SEUNG BONG HAN) Date: Tue, 9 Mar 2004 10:44:30 -0800 (PST) Subject: distributed node in linux In-Reply-To: Message-ID: <20040309184430.91869.qmail@web10104.mail.yahoo.com> Thanks. I looked at the kernel/src/inet_config.erl file and find out that case Type of unix_sv -> % UnixWare 2.1.2 case inet_db:add_rc_list([{lookup,["native"]}]) of ok -> true; {error, Reason} -> error("can't set lookup to native: ~p", [Reason]) end; freebsd -> %% we may have to check version (2.2.2) load_resolv(filename:join(Etc,"host.conf"), host_conf_freebsd); 'bsd/os' -> load_resolv(filename:join(Etc,"irs.conf"), host_conf_bsdos); linux -> load_resolv(filename:join(Etc,"host.conf"),host_conf_linux), My Gentoo/FreeBSD is using /etc/nsswitch.conf instead of host.conf. For linux box, I just add /etc/host.conf file and FreeBSD box, I had to modify the code. Now, I have distributed nodes!! regards, Chandrashekhar Mullaparthi wrote: The same problem exists on Mac OS X as well. We have this in our ~/.erlang inet_db:add_rc_list([{lookup, ["native", "file"]}]). cheers Chandru On 9 Mar 2004, at 07:22, SEUNG BONG HAN wrote: > I tried to setup the distributed node in Gentoo linux > without success. > I found out that if I do the inet:gethostbyname(> name>), it returned {error, nxdomain}. > The reason was inet_db:res_option(lookup) returned > empty list instead of [{res_lookup,[file,dns]}]. > > I setup the nsswitch.conf to lookup the > > hosts: files dns > ... > > Does anybody have same problem that I have before? > The FreeBSD 5.0 also gives me the same result just my > Gentoo Linux. > > regards, > > > > __________________________________ > Do you Yahoo!? > Yahoo! Search - Find what you#47976;e looking for faster > http://search.yahoo.com --------------------------------- Do you Yahoo!? Yahoo! Search - Find what you?re looking for faster. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobbe@REDACTED Wed Mar 10 08:57:28 2004 From: tobbe@REDACTED (=?ISO-8859-1?Q?Torbj=F6rn_T=F6rnkvist?=) Date: Wed, 10 Mar 2004 08:57:28 +0100 Subject: distributed node in linux In-Reply-To: <20040309184430.91869.qmail@web10104.mail.yahoo.com> References: <20040309184430.91869.qmail@web10104.mail.yahoo.com> Message-ID: <404ECA68.9050005@nortelnetworks.com> I belive that Magnus Fr?berg did send out a patch for this problem many months ago. Don't know what happend with it though... Cheers, Tobbe From mfroberg@REDACTED Wed Mar 10 09:49:08 2004 From: mfroberg@REDACTED (=?ISO-8859-1?Q?Magnus_Fr=F6berg?=) Date: Wed, 10 Mar 2004 09:49:08 +0100 Subject: distributed node in linux In-Reply-To: <404ECA68.9050005@nortelnetworks.com> References: <20040309184430.91869.qmail@web10104.mail.yahoo.com> <404ECA68.9050005@nortelnetworks.com> Message-ID: <404ED684.7090002@nortelnetworks.com> Tornkvist, Torbjorn [SVEAV:AA26:INTMAIL] wrote: > > I belive that Magnus Fr?berg did send out a patch for this > problem many months ago. Don't know what happend with > it though... > ok, "Re: problem with gethostbyname/1" is quoted below. /Magnus Magnus Fr?berg wrote: > Raimo Niskanen wrote: > >> >> I have never come across a Gentoo Linux box before. Could you dump the >> following files as well as the output from os:type() and send to me? > > > Hi > > we have done a fix to inet_config.erl for our Gentoo users. > It seems like Gentoo does not have the /etc/host.conf file so > we added usage of /etc/nsswitch.conf as well for 'linux' while > configuring the inet_db. > > The diff below is against the R9C-0 version of inet_config.erl: > > Index: lib/kernel/src/inet_config.erl > =================================================================== > RCS file: /home/share/erlang/cvsroot/otp/lib/kernel/src/inet_config.erl,v > retrieving revision 1.1.1.5 > retrieving revision 1.7 > diff -u -r1.1.1.5 -r1.7 > --- lib/kernel/src/inet_config.erl 2 Sep 2003 13:34:18 -0000 > 1.1.1.5 > +++ lib/kernel/src/inet_config.erl 3 Sep 2003 13:53:57 -0000 1.7 > @@ -82,8 +82,13 @@ > 'bsd/os' -> > load_resolv(filename:join(Etc,"irs.conf"), > host_conf_bsdos); > linux -> > - > load_resolv(filename:join(Etc,"host.conf"),host_conf_linux), > - > + case > load_resolv(filename:join(Etc,"host.conf"),host_conf_li > nux) of > + ok -> > + ok; > + _Other -> > + > load_resolv(filename:join(Etc,"nsswitch.conf"), nssw > itch_conf) > + end, > + > % It may be the case that the domain name was not set > % because the hostname was short. But we can now > look it > % up and get the long name and the domain name from it. > > > /Magnus > From Erik.Stenman@REDACTED Wed Mar 10 11:09:28 2004 From: Erik.Stenman@REDACTED (Erik Stenman) Date: Wed, 10 Mar 2004 11:09:28 +0100 Subject: The inverse of a function... Message-ID: <200403101008.i2AA8r225638@hades.cslab.ericsson.net> Corrado Santoro wrote: > Hi Erlang gurus, > I have a function like this: > > f(caesar) -> ...; > f(caius) -> ....; > f(giulius) -> .... > > I would like to have a function that, given the name 'f', returns the > list [caesar, caius, giulius] (or similar). > Is it possibile to do this (obviously without re-interpreting the > source file)? Actually, contrary to what has been said before on this list by very knowledgeable persons, it is possible, at least as long as the function f has no side effects, and the arguments are only atoms. -module(hack). -export([find_keys/2,f/1]). find_keys(Module,FunctionName) -> {value,{atoms,As}}=lists:keysearch(atoms,1,element(2,beam_disasm:file(Module ))), Atoms = [A || {_,A} <- As], [A || A <- Atoms, case catch apply(Module,FunctionName,[A]) of {'EXIT',_} -> false; _ -> true end]. f(caesar) -> 1; f(caius) -> 2; f(giulius) -> 3. --- 19> c(hack). {ok,hack} 20> hack:find_keys(hack,f). [giulius,caius,caesar] 21> OK, I know it is a hack, but what the heck, I could not resist. Erik From thomas.arts@REDACTED Wed Mar 10 12:31:40 2004 From: thomas.arts@REDACTED (Thomas Arts) Date: Wed, 10 Mar 2004 12:31:40 +0100 Subject: The inverse of a function... References: <200403101008.i2AA8r225638@hades.cslab.ericsson.net> Message-ID: <004101c40693$42130b40$0e2d1081@ituniv398> Indeed Erik, it is possible, but not without analysing source or binary. What you describe is re-interpretation of the source (even though you do it on a binary level). Functions with side-effects have no well-defined inverse. Functions without side-effects have an inverse, but even if one is given the source code, it is not always easy to identify the inverse. If one could, well, then one solved half the type-checking problem; just compute all the domains for all functions. /Thomas --- Dr Thomas Arts Program Manager Software Engineering and Management IT-university in Gothenburg Box 8718, 402 75 Gothenburg, Sweden http://www.ituniv.se/ Tel +46 31 772 6031 Fax +46 31 772 4899 ----- Original Message ----- From: "Erik Stenman" To: "'Question Erlang'" Sent: Wednesday, March 10, 2004 11:09 AM Subject: RE: The inverse of a function... > Corrado Santoro wrote: > > Hi Erlang gurus, > > I have a function like this: > > > > f(caesar) -> ...; > > f(caius) -> ....; > > f(giulius) -> .... > > > > I would like to have a function that, given the name 'f', returns the > > list [caesar, caius, giulius] (or similar). > > Is it possibile to do this (obviously without re-interpreting the > > source file)? > > Actually, contrary to what has been said before on this list > by very knowledgeable persons, it is possible, at least as long > as the function f has no side effects, and the arguments are only > atoms. > > -module(hack). > -export([find_keys/2,f/1]). > > find_keys(Module,FunctionName) -> > > {value,{atoms,As}}=lists:keysearch(atoms,1,element(2,beam_disasm:file(Module > ))), > Atoms = [A || {_,A} <- As], > [A || A <- Atoms, > case catch apply(Module,FunctionName,[A]) of > {'EXIT',_} -> false; > _ -> true > end]. > > f(caesar) -> 1; > f(caius) -> 2; > f(giulius) -> 3. > > > --- > 19> c(hack). > {ok,hack} > 20> hack:find_keys(hack,f). > [giulius,caius,caesar] > 21> > > > OK, I know it is a hack, but what the heck, I could not resist. > > Erik > > From vlad_dumitrescu@REDACTED Wed Mar 10 13:12:00 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 10 Mar 2004 13:12:00 +0100 Subject: The inverse of a function... References: <200403101008.i2AA8r225638@hades.cslab.ericsson.net> <004101c40693$42130b40$0e2d1081@ituniv398> Message-ID: Hi, > Functions without side-effects have an inverse, but > even if one is given the source code, it is not always > easy to identify the inverse. To be picky, not really :-) For example, f(a) -> aa; f(b) -> aa. /Vlad From crav@REDACTED Wed Mar 10 10:14:59 2004 From: crav@REDACTED (=?iso-8859-1?Q?Carlos_Rodr=EDguez_Alcal=E1_Villagra?=) Date: Wed, 10 Mar 2004 10:14:59 +0100 Subject: hack megaco_text_parser.yrl References: Message-ID: <007801c40680$2bb66210$6600a8c0@carlos> Hi, Hakan Thanks for the answer, but it didn't work... We did what you told us to do. We agregated the line: megacoMessage -> optSep authenticationHeader message safeToken endOfMessage : #'MegacoMessage'{authHeader = '$2', mess = '$3'} . into the file megaco_text_parser.yrl (and compiled with erlc -W megaco_text_parser.yrl and erl ;c(megaco_text_parser). and the we copied that into ebin) Then we tried this: We've put in the same place a safeToken2 this way megacoMessage -> optSep authenticationHeader message safeToken2 endOfMessage : #'MegacoMessage'{authHeader = '$2', mess = '$3'} . where safeToken2 is a non ternimal in this way: safeToken2 -> 'SEP' : make_safe_token('$1') .%agregamos es por que el megaco tracer no dice : error,[{reason,{bad_token,[{'SEP',5,0}, [{'RBRKT',5}.... donde 'SEP' es que cosa??? safeToken2 -> 'SEP' : make_safe_token('$1') .%This line is because the megaco tracer told that : error,[{reason,{bad_token,[{'SEP',5,0}, [{'RBRKT',5}, [{'RBRKT',5}.... whrere 'SEP' is ??? safeToken2 -> 'NULLT' : make_safe_token('$1') . and, we've aggregated the line "-define(NULLT, [?NullToken])." to the megaco_compact_text_encoder and megaco_pretty_text_encoder files. after that, we also have aggregated the line "-define( NullToken, 16#00)." to the megaco_text_encoder file. but it don`t work neither. How can we solve the problem? We basically want to aggregate something like this: megacoMessage -> optSep authenticationHeader message safeToken2 endOfMessage : #'MegacoMessage'{authHeader = '$2', mess = '$3'} . where safetoken2 captures the '\000' (the Byte that the MP102 sends incorrectly) and ignores it. Thanks again ----- Original Message ----- From: "Hakan Mattsson" To: "Carlos Rodr?guez Alcal? Villagra" Cc: Sent: Monday, March 08, 2004 12:55 PM Subject: Re: megaco_compact_text comparation > Carlos> We are testing the erlang megaco application with a mp-102 analog > Carlos> gateway, but the ServiceChange fails. Find attached a file that > Carlos> contains images of both ServiceChanges: A valid one and one from the > Carlos> mp-102. The difference is visible. > > Have you told AudioCodes that their stack does not comply with the standard? > > Carlos> How can we fix this in order to be able to receive a valid transaction > Carlos> from the mp-102?, knowing that it always adds the caracters 00 or \x00 > Carlos> to the ServiceChange Command. Do we need to hack the erlang's code at > Carlos> the "handled" libraries? > > Yes, if you want to be bug compatible with AudioCodes you need to hack a little. > > Add the following rule to megaco/src/text/megaco_text_parser.yrl: > > megacoMessage -> optSep authenticationHeader message safeToken endOfMessage > : #'MegacoMessage'{authHeader = '$2', mess = '$3'} . > > directly after this rule: > > megacoMessage -> optSep authenticationHeader message endOfMessage > : #'MegacoMessage'{authHeader = '$2', mess = '$3'} . > > and recompile the megaco application. This would allow trailing safeChars in > any text message. > > /H?kan > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > From erlang@REDACTED Wed Mar 10 15:03:38 2004 From: erlang@REDACTED (erlang@REDACTED) Date: Wed, 10 Mar 2004 14:03:38 0000 Subject: How to change a C-Node written with ei to be a port program? Message-ID: <5ec40c6a7d7f982624af05f3391218ff@tombob.com> Hello, I've got a program that acts as a C-Node written using the most excellent ei library. This works very well, but in order to simplify startup I am investigating the use of a port instead. Since I now have all this code making use of ei_xreceive_msg() and all those ei_decode_...() and ei_x_encode_...() functions, is there a way to write a port program, so that I can reuse most of this existing code? In other words, how do I implement a port program that communicates with its parent using the external message format in such a way that I can use the ei library? Thanks for any pointers, Robby From csanto@REDACTED Wed Mar 10 15:55:34 2004 From: csanto@REDACTED (Corrado Santoro) Date: 10 Mar 2004 15:55:34 +0100 Subject: The inverse of a function... In-Reply-To: References: <200403101008.i2AA8r225638@hades.cslab.ericsson.net> <004101c40693$42130b40$0e2d1081@ituniv398> Message-ID: <1078930534.2128.9.camel@csanto.diit.unict.it> Hi all, I saw that my question started a very interesting discussion.. fine! Anyway I think that the solution provided by Erik solves my problem. Indeed probably my question was a little bit wrong. Saying "inverse of a function f()" means to find a function "g()" that, given a value returned by f(), returns the associated input. This could be always possible if the function is "invertible". My problem was a little bit different because I would like to know only the "domain of function f()", i.e. the list of atoms that defines f() clauses (Yes, my initial question was wrong!) And Erik's solution seems to be OK for this problem. Also the "trial and error" approach is OK. Thus... thank you Erik, and all of you too for the suggestions and the discussion! Bye, -Corrado On Wed, 2004-03-10 at 13:12, Vlad Dumitrescu wrote: > Hi, > > > Functions without side-effects have an inverse, but > > even if one is given the source code, it is not always > > easy to identify the inverse. > > To be picky, not really :-) > > For example, > > f(a) -> aa; > f(b) -> aa. > > /Vlad -- ====================================================== Eng. Corrado Santoro, Ph.D. University of Catania - Engineering Faculty Department of Computer Science and Telecommunications Engineering Viale A. Doria, 6 - 95125 CATANIA (ITALY) Tel: +39 095 7382364 Fax: +39 095 7382397 +39 095 7382365 +39 095 7382380 EMail: csanto@REDACTED Personal Home Page: http://www.diit.unict.it/users/csanto NUXI Home Page: http://nuxi.iit.unict.it ====================================================== From hakan@REDACTED Wed Mar 10 17:17:30 2004 From: hakan@REDACTED (Hakan Mattsson) Date: Wed, 10 Mar 2004 17:17:30 +0100 (MET) Subject: hack megaco_text_parser.yrl In-Reply-To: <007801c40680$2bb66210$6600a8c0@carlos> Message-ID: On Wed, 10 Mar 2004, Carlos Rodr?guez Alcal? Villagra wrote: Carlos> Thanks for the answer, but it didn't work... Sorry, I thought of the wrong zero (ascii 48 instead of ascii 0). What do you think of the raw solution below? It is an alternate Megaco encoder module that you could use instead of megaco_compact_text_encoder. (I have not tested it either...) /H?kan -module(audio_codes_wrapper). -behaviour(megaco_encoder). -export([encode_message/2, decode_message/2]). encode_message(Config, Msg) -> megaco_compact_text_encoder:encode_message(Config, Msg). decode_message(Config, Bin) when binary(Bin) -> Size = size(Bin) - 1, case Bin of <> -> %% Strip trailing null decode_message(Config, Bin2); _ -> megaco_compact_text_encoder:decode_message(Config, Bin) end. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From taj.khattra@REDACTED Wed Mar 10 21:40:15 2004 From: taj.khattra@REDACTED (Taj Khattra) Date: Wed, 10 Mar 2004 12:40:15 -0800 Subject: Erlang in S?kerhet&Sekretess In-Reply-To: <404C8210.8060609@nortelnetworks.com> References: <404C8210.8060609@nortelnetworks.com> Message-ID: <20040310204015.GA27710@localhost.localdomain> On Mon, Mar 08, 2004 at 03:24:16PM +0100, Torbj?rn T?rnkvist wrote: > There is a nice article in No.2 of the magazine: "S?kerhet & Sekretress" > that talks about the use of Erlang within Nortel. could someone kindly summarize the article for us swedish-illiterates. e.g. does it mention if erlang is "spreading" within nortel, or is it confined to the ex-bluetail/alteon group, etc. ? thanks -taj From paul.aviles@REDACTED Tue Mar 9 05:51:00 2004 From: paul.aviles@REDACTED (Paul Aviles) Date: Mon, 8 Mar 2004 23:51:00 -0500 Subject: help Message-ID: <001a01c40592$1e705960$3224050a@avilespaxp> I am trying to compile erlang on a Sun Cobalt box (linux) and I am getting this while running make.. any ideas? Thanks Paul nu/shared -Izlib -Ihipe -c beam/erl_bif_lists.c -o /erlang/otp_src_R9C-0/erts/obj.shared.beam/i586-pc-linux-gnu/erl_bif_lists.o gcc: Internal compiler error: program cc1 got fatal signal 4 make[3]: *** [/erlang/otp_src_R9C-0/erts/obj.shared.beam/i586-pc-linux-gnu/erl_bif_lists. o] Error 1 make[3]: Leaving directory `/erlang/otp_src_R9C-0/erts/emulator' make[2]: *** [shared] Error 2 make[2]: Leaving directory `/erlang/otp_src_R9C-0/erts/emulator' make[1]: *** [shared] Error 2 make[1]: Leaving directory `/erlang/otp_src_R9C-0/erts' make: *** [emulator] Error 2 This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From spearce@REDACTED Thu Mar 11 02:02:04 2004 From: spearce@REDACTED (Shawn Pearce) Date: Wed, 10 Mar 2004 20:02:04 -0500 Subject: How to change a C-Node written with ei to be a port program? In-Reply-To: <5ec40c6a7d7f982624af05f3391218ff@tombob.com> References: <5ec40c6a7d7f982624af05f3391218ff@tombob.com> Message-ID: <20040311010204.GD6288@spearce.org> Set the port in binary mode and with a packet format of 3: open_port({spawn, "myprogram"}, [binary, {packet, 3}]) When you send/receive through it, use term_to_binary and binary_to_term in Erlang: port_send(Port, term_to_binary(Message)), receive {Port, {data, Data}} -> Message = binary_to_term(Data) end Within your C code, you need to do something like this: static int safe_read (int fd, char* buf, int len) { int tot = 0; int r; while (len > 0) { r = read(fd, buf, len); if (-1 == r) { return -1; } if (0 == r) { return 0; } tot += r; buf += r; len -= r; } return tot; } int main (int argc, char* argv) { int msg_len; char* msg; for (;;) { if (safe_read(0, &msg_len, 4) != 4) { /* Erlang has closed the port, we should exit. */ return 0; } /* Length comes in network byte order, must flip. */ msg_len = ntohl(msg_len); msg = (char*)malloc(msg_len); if (safe_read(0, msg, msg_len) != msg_len) { /* Erlang has closed the port, we should exit. */ return 0; } /* process message using ei like before */ free(msg); } } Note that when I say process the message you'll need to use ei_decode_* to decode the message. Start every message with ei_decode_version, as every message will start off with the version number. Sending is pretty much the same thing, just determine the total number of bytes in the message, use htonl(x) to create the 4 byte length header and send the header and the message. Don't forget to use ei_encode_version to add the version number to the start of any outbound message, otherwise binary_to_term/1 will fail. erlang@REDACTED wrote: > I've got a program that acts as a C-Node written using the most > excellent ei library. This works very well, but in order to simplify > startup I am investigating the use of a port instead. > > Since I now have all this code making use of ei_xreceive_msg() and all > those ei_decode_...() and ei_x_encode_...() functions, is there a way to > write a port program, so that I can reuse most of this existing code? > > In other words, how do I implement a port program that communicates > with its parent using the external message format in such a way that I > can use the ei library? -- Shawn. From matthias@REDACTED Thu Mar 11 09:16:50 2004 From: matthias@REDACTED (Matthias Lang) Date: Thu, 11 Mar 2004 09:16:50 +0100 Subject: help In-Reply-To: <001a01c40592$1e705960$3224050a@avilespaxp> References: <001a01c40592$1e705960$3224050a@avilespaxp> Message-ID: <16464.8306.541789.743187@antilipe.corelatus.se> Paul Aviles writes: > I am trying to compile erlang on a Sun Cobalt box (linux) and I am getting > this while running make.. any ideas? > gcc: Internal compiler error: program cc1 got fatal signal 4 This isn't an Erlang problem, it's a GCC or hardware problem. Signal 4 is "illegal instruction", i.e. the CPU tried to execute an opcode which isn't allowed. That typically happens when you have hardware problems. Try compiling some other large piece of software (e.g. gcc itself) and see if you see similar problems. Concrete suggestions: - Try a more recent version of gcc (you didn't say which you were using) - Compile on another machine - Download a precompiled release - Make sure the cobalt box isn't running hot (is the fan broken? is it clogged with dust? is something else blowing hot air on it?) Matthias ---------------------------------------------------------------------- 30) What does the message "Internal compiler error: cc1 got fatal signal 11,4" mean ? Ans: Gcc is probably the biggest memory hog you likely to run on your machine and it will surely eat up a lot of your RAM. Usually a fatal signal 11 will mean some sort of parity errors in your RAM or other hardware faults. I had this once when `cc1' got corrupted due to a race condition and bad blocks on my hard disk. There have also been reports that overheating chips, (not french fries), can also produce such errors. And watch for poor IDE controller/drive combos that are being run faster than the standard 8MHz AT bus clock. These can give the same errors by causing corruption of the swap space. Usually, a signal 11 (segmentation violation) means that a process tried to access memory out of its process space, or tried to write into a read-only location. Sometimes, this signal is caused by software bugs, not by hardware faults (or your system would hang repeatedly, because the same thing happened to the kernel). With gcc 2.3.3, some people could reproduce a lot of "signal 11"'s. A "fatal signal 4" has been reported to be generated due to lack of memory (happened on a 4MB system). Also it can mean a failure in one of the `ld' or `as' stages. Try recompiling whatever with a -v flag to gcc and see if it is failing in one of the cc1, cpp, as or ld stages possibly. From matthias@REDACTED Thu Mar 11 09:43:59 2004 From: matthias@REDACTED (Matthias Lang) Date: Thu, 11 Mar 2004 09:43:59 +0100 Subject: help In-Reply-To: <16464.8306.541789.743187@antilipe.corelatus.se> References: <001a01c40592$1e705960$3224050a@avilespaxp> <16464.8306.541789.743187@antilipe.corelatus.se> Message-ID: <16464.9935.386435.171153@antilipe.corelatus.se> Reply to my own reply Paul> gcc: Internal compiler error: program cc1 got fatal signal 4 Matthias> That typically happens when you have hardware problems. I forgot to say: one easy way to build evidence is to try re-running 'make' (without running 'make clean' first). If it fails again in exactly the same spot, chances are it's a GCC bug. If it doesn't fail, or fails in a different place, chances are it's a hardware problem. Matthias From erlang@REDACTED Thu Mar 11 10:00:26 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Thu, 11 Mar 2004 09:00:26 +0000 Subject: Stand Alone Erlang Message-ID: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> Hi Prof Joe, What is the state of Stand Alone Erlang? Which is the latest version of Erlang that can used with SAE? This tool will be ideal for delivering our testing tool and emulated product for external use. Pete. -- "The Tao of Programming flows far away and returns on the wind of morning." From joe@REDACTED Thu Mar 11 11:35:59 2004 From: joe@REDACTED (Joe Armstrong) Date: Thu, 11 Mar 2004 11:35:59 +0100 (CET) Subject: Stand Alone Erlang In-Reply-To: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> Message-ID: On Thu, 11 Mar 2004, Peter-Henry Mander wrote: > Hi Prof Joe, **** I did't know I was a Prof :-) > > What is the state of Stand Alone Erlang? Which is the latest version of Erlang that can used with SAE? This tool will be ideal for delivering our testing tool and emulated product for external use. > Good question - I don't know. It was written for R9X when X < C - and I handed it over to /// - the idea was that it sooner or later would creep into the main distribution. It actually gets built in /usr/local/lib/erlang/erts-5.3/bin But I havn't tested to see if it still works The windows bit definately does not work. Try it and see. The documentation on http://www.sics.se/~joe/sae.html Should still apply. Let us know what happens. As an aside I have made "tea-Bag" Erlang - this is a stripped R9C (ie throw away as much as possible) and just keep just the stuff you need. I need a minimal system to distribute to a few hundred machines (planet lab) and have made teaBag for this purpose. If there is any interest I can make it available. > Pete. > > > From kfisher@REDACTED Wed Mar 10 23:15:47 2004 From: kfisher@REDACTED (Kathleen Fisher) Date: Wed, 10 Mar 2004 17:15:47 -0500 (EST) Subject: ICFP Deadline 4/1; Submission site now open Message-ID: International Conference on Functional Programming Call for Papers ICFP 2004 September 19-22, 2004 Snowbird, Utah IMPORTANT DATES Submission deadline 23:00 01 April, 2004 Apia, Samoan time (Thursday) Author review period 23:00 17 May to 23:00 19 May, 2004, Apia, Samoan time Author notification 26 May, 2004 Final paper due 07 July, 2004 Conference 19-22 September, 2004 SCOPE ICFP 2004 seeks original papers on the full spectrum of the art, science, and practice of functional programming. The conference invites submissions on all topics ranging from principles to practice, from foundations to features, and from abstraction to application. The scope covers all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages that support objects and concurrency. Topics of interest include, but are not limited to, the following: Foundations: Formal semantics, lambda calculus, type theory, monads, continuations, control, state, effects. Design: Algorithms and data structures, modules and type systems, concurrency and distribution, components and composition, relations to object-oriented and logic programming, multiparadigm programming. Implementation: Abstract machines, compile-time and run-time optimization, just-in-time compilers, memory management. Interfaces to foreign functions, services, components and low-level machine resources. Transformation and analysis: Abstract interpretation, partial evaluation, program transformation, theorem proving, specification and verification. Software development techniques for functional programming : Design patterns, specification, verification and validation, debugging, test generation, tracing and profiling. Applications and domain-specific languages: Systems programming, scientific and numerical computing, symbolic computing and artificial intelligence, systems programming, databases, graphical user interfaces, multimedia programming, application scripting, system administration, distributed-systems construction, web programming, XML and related languages. Practice and experience: Functional programming in education and industry, ramifications on other paradigms and computing disciplines. Functional pearls: Elegant, instructive examples of functional programming. Papers in the latter three categories need not necessarily report original research results; they may instead, for example, report practical experience that will be useful to others, re-usable programming idioms, or elegant new ways of approaching a problem. The key criterion for such a paper is that it makes a contribution from which other practitioners can benefit. It is not enough simply to describe a program! SUBMISSION GUIDELINES Due date & time: Submissions must be filed at the web site by 23:00 Thursday, 01 April, Apia, Samoa time. Some equivalents to this time are: * New York: 5:00 AM = 5h00 (02 April) * San Francisco: 2:00 AM = 2h00 (02 April) * Chicago: 4:00 AM = 4h00 (02 April) * Paris: Noon (02 April) * Hong Kong: 6:00 PM = 18h00 (02 April) * UTC: 10:00 AM (02 April) For other time-zones/locations, see the worldclock. Submission URL: http://icfp.acm.org/papers/submit/ (Available now) Authors should submit a 100-200 word abstract and a full paper by 23:00 Apia, Samoa Time on Thursday, 01 April, 2004. Submissions should be no more than 12 pages (including bibliography) in standard ACM conference format: two columns, nine-point font on a ten-point baseline, with pages 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). Detailed formatting guidelines are available at http://www.acm.org/sigs/pubs/proceed/template.html, along with formatting templates or style files for LaTeX, Word Perfect, and Word. You don't need to include categories, keywords, etc., though you are welcome to do so. Also, note that the ACM copyright notice is not required of submissions, only of accepted papers. Authors wishing to supply additional material to the reviewers beyond the 12-page limit can do so in clearly marked appendices, on the understanding that reviewers are not required to read the appendices. Submissions that do not meet these guidelines will not be considered. The submission deadline and length limitations are firm. Submissions will be carried out electronically via the Web, at the URL given above. Papers must be submitted in either PDF format or as PostScript documents that are interpretable by Ghostscript. They must be printable on US Letter sized paper. Individuals for which this requirement is a hardship should contact the program chair at least one week before the deadline. Submitted papers must adhere to SIGPLAN's republication policy. Each paper should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. Authors should strive to make the technical content of their papers understandable to a broad audience. Authors will be given a 48-hour period (23:00 17 May to 23:00 19 May 2004 Apia, Samoa time) to read and respond to the reviews for their papers before the PC meeting. Authors of submitted papers will receive more details from the submission site. Authors of accepted papers will be required to sign the ACM copyright form. Proceedings will be published by ACM Press. SPECIAL ISSUE OF JOURNAL OF FUNCTIONAL PROGRAMMING The top submitted papers, as determined by the program committee, will be invited to submit journal versions for a special issue of JFP. CONFERENCE CHAIR Chris Okasaki U.S. Military Academy, West Point PROGRAM CHAIR Kathleen Fisher AT&T Labs Shannon Laboratory 189 Park Ave., E244 Florham Park, NJ, USA kfisher at research.att.com Phone: +1 973 360.8675 Fax: +1 973 360.8077 PROGRAM COMMITTEE * Lennart Augustsson (Sandburst Inc.) * Hans-J. Boehm (HP Laboratories) * Koen Claessen (Chalmers University) * Adriana Compagnoni (Stevens Institute of Technology) * Matthias Felleisen (Northeastern) * Zhenjiang Hu (University of Tokyo) * Erik Meijer (Microsoft SQLServer/WebData) * Manuel Serrano (INRIA Sophia Antipolis) * Peter Sewell (University of Cambridge) * J?r?me Sim?on (Bell Laboratories) * Christopher A. Stone (Harvey Mudd College) * Martin Sulzmann (National University of Singapore) * David Walker (Princeton University) * Elena Zucca (Universit? di Genova) This document can be obtained in the following formats: HTML http://www.cs.indiana.edu/icfp04/cfp.html PostScript http://www.cs.indiana.edu/icfp04/cfp.ps PDF http://www.cs.indiana.edu/icfp04/cfp.pdf Plain text http://www.cs.indiana.edu/icfp04/cfp.txt This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From massimo.cesaro@REDACTED Thu Mar 11 11:56:23 2004 From: massimo.cesaro@REDACTED (Massimo Cesaro) Date: 11 Mar 2004 11:56:23 +0100 Subject: Stand Alone Erlang In-Reply-To: References: Message-ID: <1079002584.1454.215.camel@xam> On Thu, 2004-03-11 at 11:35, Joe Armstrong wrote: Hello Joe, > As an aside I have made "tea-Bag" Erlang - this is a stripped R9C > (ie throw away as much as possible) and just keep just the stuff you need. > > I need a minimal system to distribute to a few hundred machines (planet lab) > and have made teaBag for this purpose. What is your definition of a minimal system ? > > If there is any interest I can make it available. I'd really love to check with our application! Massimo From erlang@REDACTED Thu Mar 11 12:44:33 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Thu, 11 Mar 2004 11:44:33 +0000 Subject: Stand Alone Erlang In-Reply-To: References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> Message-ID: <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> Hi Dr Joe, btw, do you get to wear a pincushion instead of a common mortarboard? Or do the Swedes leave such excentricities to English? :-) Well, the SAE seems to work out of the box without a hitch on R9C-0. Were going to give SAE a spin on our own applications. I'll keep you posted, including how easy/hard it is to elink in some of the OTP libraries like the Megaco stack. The teabag version is interesting, the next project doesn't appear to rely on OTP much, if at all. Its not a trivial application, it's for a SIP protocol load tester. Maybe a good candidate? Pete. On Thu, 11 Mar 2004 11:35:59 +0100 (CET) Joe Armstrong wrote: > On Thu, 11 Mar 2004, Peter-Henry Mander wrote: > > > Hi Prof Joe, > **** I did't know I was a Prof :-) > > > > > What is the state of Stand Alone Erlang? Which is the latest version > > of Erlang that can used with SAE? This tool will be ideal for > > delivering our testing tool and emulated product for external use. > > > > Good question - I don't know. > > It was written for R9X when X < C - and I handed it over to /// - the > idea was that it sooner or later would creep into the main > distribution. > > It actually gets built in > > /usr/local/lib/erlang/erts-5.3/bin > > But I havn't tested to see if it still works > > The windows bit definately does not work. > > Try it and see. > > The documentation on > > http://www.sics.se/~joe/sae.html > > Should still apply. > > Let us know what happens. > > As an aside I have made "tea-Bag" Erlang - this is a stripped R9C > (ie throw away as much as possible) and just keep just the stuff you > need. > > I need a minimal system to distribute to a few hundred machines > (planet lab) and have made teaBag for this purpose. > > If there is any interest I can make it available. > > > Pete. > > > > > > > -- "The Tao of Programming flows far away and returns on the wind of morning." From joe@REDACTED Thu Mar 11 13:29:20 2004 From: joe@REDACTED (Joe Armstrong) Date: Thu, 11 Mar 2004 13:29:20 +0100 (CET) Subject: Bug in Message-ID: I'm not sure if this is bug .... I'm using the *undocumented* http.erl in inets If I have some process P and call http:start() followed by http:request_sync(...) Then if any other message is sent to P *before* request_sync has terminated then I get a fatal errror. To fix otp_src_R9C-0/lib/inets/src/http.erl change line 182 receive {'$gen_cast',{request_sync,_ReqId2,{Status,Headers,Body}}} -> {Status,pp_headers(Headers),binary_to_list(Body)}; {'$gen_cast',{request_sync,_ReqId2,{error,Reason}}} -> {error,Reason}; Error -> Error end; to receive {'$gen_cast',{request_sync,_ReqId2,{Status,Headers,Body}}} -> {Status,pp_headers(Headers),binary_to_list(Body)}; {'$gen_cast',{request_sync,_ReqId2,{error,Reason}}} -> {error,Reason} end; Which seems to fix the problem /Joe From hal@REDACTED Thu Mar 11 15:40:58 2004 From: hal@REDACTED (Hal Snyder) Date: Thu, 11 Mar 2004 08:40:58 -0600 Subject: Stand Alone Erlang In-Reply-To: <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> (Peter-Henry Mander's message of "Thu, 11 Mar 2004 11:44:33 +0000") References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> Message-ID: <87ishbo39h.fsf@ghidra.vail> Peter-Henry Mander writes: > The teabag version is interesting, the next project doesn't appear > to rely on OTP much, if at all. Its not a trivial application, it's > for a SIP protocol load tester. Maybe a good candidate? ^^^^^^^^^^^^^^^^^^^^^^^^ Sounds interesting. Are outside collaboraters allowed? From erlang@REDACTED Thu Mar 11 19:03:52 2004 From: erlang@REDACTED (erlang@REDACTED) Date: Thu, 11 Mar 2004 18:03:52 0000 Subject: How to change a C-Node written with ei to be a port program? In-Reply-To: <20040311010204.GD6288@spearce.org> Message-ID: <9c6cc7e9a57598f9142ff64be498d0e4@tombob.com> Hi, thank you very much for this, works like charm so far. > Set the port in binary mode and with a packet format of 3: > > open_port({spawn, "myprogram"}, [binary, {packet, 3}]) I had to set {packet, 4}. With a packet length size of 3, I get a badarg in open_port/2. > When you send/receive through it, use term_to_binary and binary_to_term > in Erlang: > > port_send(Port, term_to_binary(Message)), > > receive > {Port, {data, Data}} -> > Message = binary_to_term(Data) > end I take it you meant port_command/2 to send something to the port. One question that I wasn't sure of: Should I be choosing the port_command/2 and port_close/1 functions over the direct message sending? The manual definitely suggests using the port_... functions, so I'm going with that for now. I also have problems with recognising the demise of the port program. If I start it using the exit_status option, I get correct notification if I kill the program from the outside, but not if I do an exit(1) inside it (it's an unstable program ;). Not a big deal though. A big thanks to the Erlang community for providing such great relief to an otherwise drab progamming existence :-) Robby From klacke@REDACTED Fri Mar 12 00:41:50 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Fri, 12 Mar 2004 00:41:50 +0100 Subject: distributed node in linux In-Reply-To: <404ECA68.9050005@nortelnetworks.com> References: <20040309184430.91869.qmail@web10104.mail.yahoo.com> <404ECA68.9050005@nortelnetworks.com> Message-ID: <20040311234150.GA15582@hyber.org> On Wed, Mar 10, 2004 at 08:57:28AM +0100, Torbj?rn T?rnkvist wrote: > > I belive that Magnus Fr?berg did send out a patch for this > problem many months ago. Don't know what happend with > it though... > Yeahh, and I sent a patch for it last spring. Uhhhhhh :-( /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From spearce@REDACTED Fri Mar 12 02:33:42 2004 From: spearce@REDACTED (Shawn Pearce) Date: Thu, 11 Mar 2004 20:33:42 -0500 Subject: How to change a C-Node written with ei to be a port program? In-Reply-To: References: <20040311010204.GD6288@spearce.org> Message-ID: <20040312013342.GE6288@spearce.org> erlang@REDACTED wrote: > > Set the port in binary mode and with a packet format of 3: > > > > open_port({spawn, "myprogram"}, [binary, {packet, 3}]) > > I had to set {packet, 4}. With a packet length size of 3, I get a badarg in open_port/2. Doh! Fat fingers on my part hit the wrong key. I was on my way out the door and just fired off a reply without proofreading. My apologies! > > When you send/receive through it, use term_to_binary and binary_to_term > > in Erlang: > > > > port_send(Port, term_to_binary(Message)), > > > > receive > > {Port, {data, Data}} -> > > Message = binary_to_term(Data) > > end > > I take it you meant port_command/2 to send something to the port. Yes, I did. Again, lack of proofreading on my part. > One question that I wasn't sure of: Should I be choosing the > port_command/2 and port_close/1 functions over the direct message > sending? The manual definitely suggests using the port_... > functions, so I'm going with that for now. Yes, in new code. The BIFs are a little bit clearer than the message is... though some may disagree. > I also have problems with recognising the demise of the port program. > If I start it using the exit_status option, I get correct notification > if I kill the program from the outside, but not if I do an exit(1) > inside it (it's an unstable program ;). Not a big deal though. What OS is this on? I haven't fully tested exit_status, but it does seem to work most of the time. You might want to also try eof, it may report eof when it dies. -- Shawn. Talk is cheap because supply always exceeds demand. From jhouchin@REDACTED Fri Mar 12 05:54:05 2004 From: jhouchin@REDACTED (Jimmie Houchin) Date: Thu, 11 Mar 2004 22:54:05 -0600 Subject: Problem installing Erlang on Gentoo Message-ID: <4051426D.7030806@cableone.net> Hello, I am attempting to emerge erlang on my Gentoo server. It is a dual Opteron. The ebuild is masked so is considered unstable, but many masked ebuilds work just fine. Below is the output from my attempt. Any help greatly appreciated. Jimmie Houchin Script started on Thu Mar 11 22:40:36 2004 emerge dev-lang/erlang/erlang-9c-r2.ebuild Started emerge on: Mar 11, 2004 22:41:07]1;]2; *** emerge dev-lang/erlang/erlang-9c-r2.ebuild Calculating dependencies \ ...done! >>> emerge (1 of 1) dev-lang/erlang-9c-r2 to / ]1;]2; >>> emerge (1 of 1) dev-lang/erlang-9c-r2 to /]1;]2; === (1 of 1) Cleaning (dev-lang/erlang-9c-r2::/usr/portage/dev-lang/erlang/erlang-9c-r2.ebuild)]1;]2; === (1 of 1) Compiling/Merging (dev-lang/erlang-9c-r2::/usr/portage/dev-lang/erlang/erlang-9c-r2.ebuild)>>> md5 src_uri ;-) otp_src_R9C-0.tar.gz >>> Unpacking source... >>> Unpacking otp_src_R9C-0.tar.gz to /var/tmp/portage/erlang-9c-r2/work [32;01m*[0m Applying 9c.patch... [A[119G [34;01m[ [32;01mok[34;01m ][0m >>> Source unpacked. checking host system type... x86_64-pc-linux-gnu checking for GNU make... yes (make) checking for a BSD compatible install... /bin/install -c checking whether ln -s works... yes checking for ranlib... ranlib creating ./config.status creating Makefile configuring in lib running /bin/sh /var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-threads --cache-file=.././config.cache --srcdir=/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib creating ./config.status configuring in erl_interface/. running /bin/sh /var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/erl_interface/./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-threads --cache-file=../../.././config.cache --srcdir=/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/erl_interface/. checking host system type... x86_64-pc-linux-gnu checking for gcc... gcc checking whether the C compiler (gcc -O2 -pipe -fomit-frame-pointer ) works... yes checking whether the C compiler (gcc -O2 -pipe -fomit-frame-pointer ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking size of short... 2 checking size of int... 4 checking size of long... 8 checking size of void *... 8 checking size of long long... 8 checking for ar... ar checking for a BSD compatible install... /bin/install -c checking for gethostbyname in -lnsl... yes checking for getpeername in -lsocket... no checking for ANSI C header files... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking for arpa/inet.h... yes checking for fcntl.h... yes checking for limits.h... yes checking for malloc.h... yes checking for netdb.h... yes checking for netinet/in.h... yes checking for stddef.h... yes checking for stdlib.h... yes checking for string.h... yes checking for sys/param.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for unistd.h... yes checking for pthread.h... yes checking for pthread/mit/pthread.h... no checking for uid_t in sys/types.h... yes checking for pid_t... yes checking for size_t... yes checking whether time.h and sys/time.h may both be included... yes checking for working alloca.h... yes checking for alloca... yes checking whether gcc needs -traditional... no checking for 8-bit clean memcmp... yes checking for clock_gettime... no checking for dup2... yes checking for gethostbyaddr... yes checking for gethostbyname... yes checking for gethostbyname_r... yes checking for gethostname... yes checking for writev... yes checking for gethrtime... no checking for gettimeofday... yes checking for inet_ntoa... yes checking for memchr... yes checking for memmove... yes checking for memset... yes checking for select... yes checking for socket... yes checking for strchr... yes checking for strerror... yes checking for strrchr... yes checking for strstr... yes checking for uname... yes checking for res_gethostbyname... no checking for res_gethostbyname in -lresolv... yes checking if native win32 threads should be used... no checking for pthread_create in -lpthread... yes checking for pthread_atfork in -lpthread... yes creating ./config.status creating src/x86_64-pc-linux-gnu/Makefile creating src/x86_64-pc-linux-gnu/config.h configuring in gs/. running /bin/sh /var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/gs/./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-threads --cache-file=../../.././config.cache --srcdir=/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/gs/. checking host system type... x86_64-pc-linux-gnu checking for prebuilt tcl/tk in tcl/binaries/x86_64_linux-gnu.tar.gz... not found creating ./config.status creating tcl/x86_64-pc-linux-gnu/Makefile creating tcl/win32/Makefile configuring in megaco/. running /bin/sh /var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/megaco/./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-threads --cache-file=../../.././config.cache --srcdir=/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/megaco/. checking host system type... x86_64-pc-linux-gnu checking for flex... flex checking for yywrap in -lfl... yes checking for gcc... gcc checking whether the C compiler (gcc -O2 -pipe -fomit-frame-pointer ) works... yes checking whether the C compiler (gcc -O2 -pipe -fomit-frame-pointer ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for ld.sh... no checking for ld... ld checking for linker flags for loadable drivers... -shared checking for perl... perl creating ./config.status creating src/flex/x86_64-pc-linux-gnu/Makefile configuring in snmp/. running /bin/sh /var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/snmp/./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-threads --cache-file=../../.././config.cache --srcdir=/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/snmp/. checking host system type... x86_64-pc-linux-gnu checking for perl... perl creating ./config.status creating mibs/Makefile configuring in erts running /bin/sh /var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/erts/configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-threads --cache-file=.././config.cache --srcdir=/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/erts creating cache .././config.cache checking host system type... x86_64-pc-linux-gnu checking for gcc... gcc checking whether the C compiler (gcc -O2 -pipe -fomit-frame-pointer ) works... yes checking whether the C compiler (gcc -O2 -pipe -fomit-frame-pointer ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for POSIXized ISC... no checking for gcc... (cached) gcc checking whether the C compiler (gcc -O2 -pipe -fomit-frame-pointer ) works... yes checking whether the C compiler (gcc -O2 -pipe -fomit-frame-pointer ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for mixed cygwin and native VC++ environment... no checking how to run the C preprocessor... gcc -E checking for ranlib... ranlib checking for bison... bison -y checking for perl5... no checking for perl... /usr/bin/perl checking whether ln -s works... yes checking for ar... ar checking for a BSD compatible install... /bin/install -c checking how to create a directory including parents... /bin/install -c -d checking for Cygwin environment... no checking for mingw32 environment... no checking for executable suffix... no checking for object suffix... o checking for extra flags needed to export symbols... -Wl,-export-dynamic checking for sin in -lm... yes checking for dlopen in -ldl... yes checking for main in -linet... no checking for main in -lresolv... yes checking for tgetent in -lncurses... yes checking for connect... yes checking for gethostbyname... yes checking for gethostbyname_r... yes checking if netdb.h requires netinet/in.h to be previously included... yes checking for getipnodebyname... no checking for getipnodebyaddr... no checking for h_errno declaration in netdb.h... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for ANSI C header files... yes checking for sys/wait.h that is POSIX.1 compatible... yes checking whether time.h and sys/time.h may both be included... yes checking for fcntl.h... yes checking for limits.h... yes checking for unistd.h... yes checking for syslog.h... yes checking for dlfcn.h... yes checking for ieeefp.h... no checking for thread.h... no checking for pthread.h... yes checking for poll.h... yes checking for sys/stropts.h... yes checking for sys/ioctl.h... yes checking for sys/time.h... yes checking for sys/uio.h... yes checking for sys/sockio.h... no checking for sys/socketio.h... no checking for net/errno.h... no checking for malloc.h... yes checking for mach-o/dyld.h... no checking for arpa/nameser.h... yes checking for pthread/mit/pthread.h... no checking for sys/devpoll.h... no checking for linux/kpoll.h... no checking for sys/event.h... no checking for SO_BSDCOMPAT declaration... yes checking for INADDR_LOOPBACK in netinet/in.h... yes checking for sys_errlist declaration in stdio.h or errno.h... yes checking for working const... yes checking return type of signal handlers... void checking for off_t... yes checking for pid_t... yes checking for size_t... yes checking whether struct tm is in sys/time.h or time.h... time.h checking whether struct sockaddr has sa_len field... no checking for struct exception (and matherr function)... yes checking size of short... 2 checking size of int... 4 checking size of long... 8 checking size of void *... 8 checking size of long long... 8 checking size of size_t... 8 checking size of off_t... 8 checking int/long/void*/size_t sizes... ok checking whether byte ordering is bigendian... no checking for ieee_handler... no checking for fpsetmask... no checking for finite... yes checking for isnan... yes checking for isinf... yes checking for res_gethostbyname... yes checking for dlopen... yes checking for poll... yes checking for pread... yes checking for pwrite... yes checking for writev... yes checking for memmove... yes checking for strerror... yes checking for strerror_r... yes checking for strncasecmp... yes checking for gethrtime... no checking for localtime_r... yes checking for gmtime_r... yes checking for mremap... yes checking for memcpy... yes checking for mallopt... yes checking whether setvbuf arguments are reversed... no checking for vfork.h... no checking for working vfork... yes checking for vprintf... yes checking for unistd.h... (cached) yes checking for getpagesize... yes checking for working mmap... yes checking for conflicting declaration of fread... yes checking for IP version 6 support... yes checking for multicast support... yes checking how to correct for time adjustments... times checking for unreliable floating point execptions... unreliable; testing in software instead checking if gethrvtime works and how to use it... not working checking whether to redefine FD_SETSIZE... no checking if native win32 threads should be used... no checking for pthread_create in -lpthread... yes checking for pthread_atfork in -lpthread... yes checking for pthread_mutexattr_settype in -lpthread... yes checking for pthread_mutexattr_setkind_np in -lpthread... yes checking for linker flags for loadable drivers... -shared checking for a compiler that handles jumptables... gcc checking for OpenSSL >= 0.9.7 in standard locations... /usr checking for OpenSSL kerberos 5 support... no checking for kstat_open in -lkstat... no checking for javac.sh... /opt/blackdown-jdk-1.4.2_rc1/bin/javac checking for JDK version 1.2... yes checking for c++... g++ updating cache .././config.cache creating ./config.status creating emulator/x86_64-pc-linux-gnu/Makefile creating emulator/zlib/x86_64-pc-linux-gnu/Makefile creating epmd/src/x86_64-pc-linux-gnu/Makefile creating etc/common/x86_64-pc-linux-gnu/Makefile creating ../make/x86_64-pc-linux-gnu/otp.mk creating ../lib/ic/c_src/x86_64-pc-linux-gnu/Makefile creating ../lib/os_mon/c_src/x86_64-pc-linux-gnu/Makefile creating ../lib/ssl/c_src/x86_64-pc-linux-gnu/Makefile creating ../lib/ssl/examples/certs/x86_64-pc-linux-gnu/Makefile creating ../lib/crypto/c_src/x86_64-pc-linux-gnu/Makefile creating ../lib/orber/c_src/x86_64-pc-linux-gnu/Makefile creating ../lib/odbc/c_src/x86_64-pc-linux-gnu/Makefile creating ../lib/runtime_tools/c_src/x86_64-pc-linux-gnu/Makefile creating ../lib/asn1/c_src/x86_64-pc-linux-gnu/Makefile creating x86_64-pc-linux-gnu/config.h cd erts/emulator && ERL_TOP=/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0 make generate depend make[1]: Entering directory `/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/erts/emulator' make -f x86_64-unknown-linux-gnu/Makefile generate make[2]: Entering directory `/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/erts/emulator' make[2]: x86_64-unknown-linux-gnu/Makefile: No such file or directory make[2]: *** No rule to make target `x86_64-unknown-linux-gnu/Makefile'. Stop. make[2]: Leaving directory `/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/erts/emulator' make[1]: *** [generate] Error 2 make[1]: Leaving directory `/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/erts/emulator' make: *** [depend] Error 2 !!! ERROR: dev-lang/erlang-9c-r2 failed. !!! Function src_compile, Line 35, Exitcode 2 !!! (no error message) Script done on Thu Mar 11 22:42:03 2004 From snickl@REDACTED Fri Mar 12 08:49:17 2004 From: snickl@REDACTED (snickl@REDACTED) Date: Fri, 12 Mar 2004 08:49:17 +0100 (CET) Subject: Problem installing Erlang on Gentoo In-Reply-To: <4051426D.7030806@cableone.net> References: <4051426D.7030806@cableone.net> Message-ID: On Thu, 11 Mar 2004, Jimmie Houchin wrote: > Hello, > > I am attempting to emerge erlang on my Gentoo server. > It is a dual Opteron. This looks like "the same old problem" (TM) ;) Gentoo tells the erlang configure the host-type given in make.conf (x86_64-pc-linux-gnu in your case). But the erlang configure does also autodetection on the host type, which may result in something different (x86_64-unknown-linux-gnu here). One result goes into the Makefiles, the other one into the directory names for the compile output, if they don't match, bang! The workaround is to find out what erlang configure has autodetected for your hostname and to set CHOST accordingly while emerging erlang. In plain english: CHOST=x86_64-unknown-linux-gnu Of course, you will want to change it back when finished. > /var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib/configure > --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man > --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc > --localstatedir=/var/lib --enable-threads --cache-file=.././config.cache > --srcdir=/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/lib > make -f x86_64-unknown-linux-gnu/Makefile generate > make[2]: Entering directory > `/var/tmp/portage/erlang-9c-r2/work/otp_src_R9C-0/erts/emulator' > make[2]: x86_64-unknown-linux-gnu/Makefile: No such file or directory > make[2]: *** No rule to make target `x86_64-unknown-linux-gnu/Makefile'. > Stop. CU, SN -- The UNIX equivalent of the "Blue Screen of Death" would be called "kernel panic". It obviously exists, since I have heard and read about it, but I've never been witness to it in my professional career. John Kirch, Networking Consultant and Microsoft Certified Professional (Windows NT) From erlang@REDACTED Fri Mar 12 09:18:30 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 12 Mar 2004 08:18:30 +0000 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <87ishbo39h.fsf@ghidra.vail> References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> <87ishbo39h.fsf@ghidra.vail> Message-ID: <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> Hi Hal, I suspected someone would pick up on the SIP protocol load tester just after I pressed send. I originally wished to release this under a BSD style licence, but we're in talks with investors and it was deemed a bad time to release our "intellectual property" at such a sensitive time. Sorry. It's a pity, I would have liked it to be my contribution to open-source, and initially management was warming to the idea, bless them. Heaven knows how much OSS has helped me achieve so much! And having an outside opinion on what I've done so far would have helped too. Perhaps I might kick off the issue of OSS on erlang-questions. How does one convince the non-technical bean counters that using and _providing_ OSS is of commercial benefit? And that opening source code may generate goodwill (something that SCO Group is suffering a severe lack thereof!) leading to sales. But hey! I'm a naive soft-hearted programmer who knows nothing about the hard tooth-and-nail world of commerce! Maybe geeks and suits will never really understand each other... Pete. P.s. However, if what we're doing interests you as a customer, Hal, please visit http://www.newport-networks.com/ and we can discuss this at a commercial level :-) On Thu, 11 Mar 2004 08:40:58 -0600 Hal Snyder wrote: > > Sounds interesting. Are outside collaboraters allowed? -- "The Tao of Programming flows far away and returns on the wind of morning." From ulf.wiger@REDACTED Fri Mar 12 10:34:42 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 12 Mar 2004 10:34:42 +0100 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> <87ishbo39h.fsf@ghidra.vail> <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> Message-ID: On Fri, 12 Mar 2004 08:18:30 +0000, Peter-Henry Mander wrote: > Perhaps I might kick off the issue of OSS on erlang-questions. How does > one convince the non-technical bean counters that using and _providing_ > OSS is of commercial benefit? And that opening source code may generate > goodwill (something that SCO Group is suffering a severe lack thereof!) > leading to sales. Well, basically, you don't ask. And whatever you do, don't ask your corporate lawyers! (: Whether a piece of software is more valuable to the company if kept a secret than it would be if shared with everyone is not easy to determine. I think the person(s) most competent to make the decision is usually the software architect(s) closest to the code. IMO it's exceptionally rare nowadays that a component in a software system is written such that you can make money keeping it secret or selling it as a reusable component to others. Naturally, if your business idea is to make and sell such components, it would be foolish to give them away for free. If your business is to make more complex products, possibly using a mix of 3rd party and OSS components, whether to release one of your own tools or components as OSS would depend mostly on whether you think that the expected return (in terms of outside help improving the code) would outweigh the cost of packaging and documenting it for external use. To determine this, you need to know both the code and the OSS community that you would release the code to. This rules out most managers and corporate lawyers. I've tried to enforce the rule here that if a designer wants to release a part of our system as OSS, it's OK as long as they judge that it would be beneficial to do so, and as long as they check with system management (for example one of the erlang experts there.) I've yet to determine that we've released something we shouldn't have, or that we've turned someone down because the code was deemed to sensitive to release. Normally, the main obstacles are: - that we first have to replace all copyright lingo in the source; - that we have to rewrite/reformat the documentation; - that our design environment is different enough frin e.g. sourceforge that we have to duplicate the code and maintain two separate versions; - that accessing sourceforge CVS from our workstations is ridiculously difficult due to security policy. I'd like to see our design environments set up so that it's easy to release choice parts as OSS and still keep one code base. OTP has done this, and it seems to work very well for them. Of course, they don't have proprietary parts, but release everything as OSS. Mixing proprietary and OSS is perhaps a bit trickier... One of course has to guess whether or not a component will be of use to anyone else, such that they will pick up on it and help improve it. A SIP protocol load tester seems like a great candidate for OSS. I'm pretty sure we would try it, help debug it, and probably also help improve it. Of course, none of this is necessarily the opinion of my employer, as you may have guessed already from the embarrassing sigs slapped on to all our emails. /Uffe -- Ulf Wiger, Senior System Architect EAB/UPD/S This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From joe@REDACTED Fri Mar 12 10:57:27 2004 From: joe@REDACTED (Joe Armstrong) Date: Fri, 12 Mar 2004 10:57:27 +0100 (CET) Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> Message-ID: > Perhaps I might kick off the issue of OSS on erlang-questions. How does > one convince the non-technical bean counters that using and _providing_ > OSS is of commercial benefit? And that opening source code may generate > goodwill (something that SCO Group is suffering a severe lack thereof!) > leading to sales. I would argue that S/W falls into several different categories 1) Pre-competitive 2) Competitive 3) General odds and sods 1) Is a when different companies co-operate with each other to produce a market - without the market there is no competition. 2) Competitive is what you live off - this you keep secret 3) Is general improvements to everybody. Now suppose you make better test-suits - who stands to gain? - your products might be useless unless they can interoperatate with the other guy's products - so I guess test-suits are a 1) - they are pre-condition that you get to the point of competing in the first place. If you are alone in the market - no worries - release all! - why? What can happen: a) nobody is interested -> no threat b) people find bugs -> great, a positive benefit c) people steal your ideas -> great - you were on the right track the market *expands* (because you had the right idea) *but* (a big but) you were first - and will hopefully always stay ahead - by being first you have more knowledge of the problem that other follow (steal) acknowledges your leadership. Your can even sell updates to them :-) You can choose to be in the commercial market place swapping ideas - building upon the work of others - or sit in the corner keeping your ideas to yourself - but your ideas will not grow if you do not share them. Giving your software away is symmetric processes - if you give your stuff away, what do you get back? - bug-fixes (nice to have - saves you work) - feedback - ideas - every time I post S/W to the net I get feedback - people find bugs and have new ideas for great new things. Imagine - you post your S/W to the net - some guy takes the S/W has a great idea - mails you and ... wow ... this is your next product. > > But hey! I'm a naive soft-hearted programmer who knows nothing about the > hard tooth-and-nail world of commerce! > > Maybe geeks and suits will never really understand each other... > They will - explain that the code is not really important but that the ideas behind the code are. Explain that by cutting off the flow of code you are cutting off the flow of ideas. Explain that without new ideas your products will fail. Explain that you are using Erlang because it is a new idea. If despite this you don't want to use new ideas - go and use Java - go and keep all your ideas secret. /Joe > Pete. > > P.s. However, if what we're doing interests you as a customer, Hal, > please visit http://www.newport-networks.com/ and we can discuss this at > a commercial level :-) > > > > On Thu, 11 Mar 2004 08:40:58 -0600 > Hal Snyder wrote: > > > > > Sounds interesting. Are outside collaboraters allowed? > > From mike@REDACTED Fri Mar 12 12:18:11 2004 From: mike@REDACTED (Mike Williams) Date: 12 Mar 2004 11:18:11 GMT Subject: OSS (was Re: Stand Alone Erlang) References: <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk>, <87ishbo39h.fsf@ghidra.vail>, <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> Message-ID: In article <20040312081830.6068ab1e.erlang@REDACTED>, erlang@REDACTED (Peter-Henry Mander) writes: |> Perhaps I might kick off the issue of OSS on erlang-questions. How does |> one convince the non-technical bean counters that using and _providing_ |> OSS is of commercial benefit? And that opening source code may generate |> goodwill (something that SCO Group is suffering a severe lack thereof!) |> leading to sales. There is one one issue, MONEY. You have to convince the "owners" of the code (often, but not always the people who paid for the development of the code), that it is in their COMMERCIAL ADVANTAGE to contribute the code to Open Source. - "Add on" sales of other software for which you can get paid. (MySQL is a good example of this). - "goodwill" and image of a company thus improving the company's "brand". This is simply a form of marketting". Any (non bankrupt) company knows that "marketting" costs money. - Service / consulting / support services which you can sell. (Companies like Red Hat live from support and services) - Setting standards. By releasing SW as Open Source you can influence the "de facto" industry standard in a direction which is good for your company. (SUN have done a lot in this direction - for example the primitives behind NFS). - Killing the oposition. You can kill a competitor by giving away an open source product which does the same as his expesive product. Even if your product isn't as good as your competitors product. Why do you think Micro$oft does all it can throw dirt at Linux? Linux is a real threat to them! SUN did the same for many years until they realised that "if you can't beat them, join them". I am sure that a lot of the companies whi are spending money on Linux are doing so simply to try to reduce Micro$ofts power and monopoly - If you have a legacy product, or a product which isn't bringing in money but you still need to support, you might make it Open Source if you think it would be interesting to others. In this way you can get the Open Source comunity to support it for you free (Open Office and Mozilla maybe are examples of this). I am sure there are many more reasons. /mike (PS: The intelligent reader can venture a guess as to why Ericsson released Erlang/OTP - as I am a "suite" nowadays, I won't tell you :-) This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From erlang@REDACTED Fri Mar 12 12:42:00 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 12 Mar 2004 11:42:00 +0000 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: References: <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> Message-ID: <20040312114200.62363e94.erlang@manderp.freeserve.co.uk> Thanks Joe, I've always had a hunch about this, but you've made the reasons crystal clear. Thanks for the political ammunition, it will be *very* useful. Pete. On Fri, 12 Mar 2004 10:57:27 +0100 (CET) Joe Armstrong wrote: > > Perhaps I might kick off the issue of OSS on erlang-questions. How > > does one convince the non-technical bean counters that using and > > _providing_ OSS is of commercial benefit? And that opening source > > code may generate goodwill (something that SCO Group is suffering a > > severe lack thereof!) leading to sales. > > I would argue that S/W falls into several different categories > > 1) Pre-competitive > 2) Competitive > 3) General odds and sods > > 1) Is a when different companies co-operate with each other to produce > a market - without the market there is no competition. > > 2) Competitive is what you live off - this you keep secret > > 3) Is general improvements to everybody. > > Now suppose you make better test-suits - who stands to gain? - your > products might be useless unless they can interoperatate with the > other guy's products - so I guess test-suits are a 1) - they are > pre-condition that you get to the point of competing in the first > place. > > If you are alone in the market - no worries - release all! - why? > > What can happen: > > a) nobody is interested -> no threat > b) people find bugs -> great, a positive benefit > c) people steal your ideas -> great - you were on the right > track > the market *expands* (because you had the right idea) *but* > (a big but) you were first - and will hopefully always stay > ahead - by being first you have more knowledge of the problem > that other follow (steal) acknowledges your leadership. > Your can even sell updates to them :-) > > You can choose to be in the commercial market place swapping ideas - > building upon the work of others - or sit in the corner keeping your > ideas to yourself - but your ideas will not grow if you do not share > them. > > Giving your software away is symmetric processes - if you give your > stuff away, what do you get back? > > - bug-fixes (nice to have - saves you work) > - feedback - ideas - every time I post S/W to the net I get > feedback - people find bugs and have new ideas for great new > things. > > Imagine - you post your S/W to the net - some guy takes the S/W has > a great idea - mails you and ... wow ... this is your next product. > > > > > But hey! I'm a naive soft-hearted programmer who knows nothing about > > the hard tooth-and-nail world of commerce! > > > > Maybe geeks and suits will never really understand each other... > > > > They will - explain that the code is not really important but that > the ideas > behind the code are. Explain that by cutting off the flow of code you > are cutting off the flow of ideas. > > Explain that without new ideas your products will fail. > > Explain that you are using Erlang because it is a new idea. > > If despite this you don't want to use new ideas - go and use Java - > go and keep all your ideas secret. > > > > /Joe > > > Pete. > > > > P.s. However, if what we're doing interests you as a customer, Hal, > > please visit http://www.newport-networks.com/ and we can discuss > > this at a commercial level :-) > > > > > > > > On Thu, 11 Mar 2004 08:40:58 -0600 > > Hal Snyder wrote: > > > > > > > > Sounds interesting. Are outside collaboraters allowed? > > > > > -- "The Tao of Programming flows far away and returns on the wind of morning." From jhouchin@REDACTED Fri Mar 12 12:48:53 2004 From: jhouchin@REDACTED (Jimmie Houchin) Date: Fri, 12 Mar 2004 05:48:53 -0600 Subject: Problem installing Yaws was: Re: Problem installing Erlang on Gentoo In-Reply-To: References: <4051426D.7030806@cableone.net> Message-ID: <4051A3A5.7010200@cableone.net> Hello. Thanks for the help. snickl@REDACTED wrote: > On Thu, 11 Mar 2004, Jimmie Houchin wrote: > >>Hello, >> >>I am attempting to emerge erlang on my Gentoo server. >>It is a dual Opteron. > > This looks like "the same old problem" (TM) ;) Ahh! or should that be Ugh! ? :) > Gentoo tells the erlang configure the host-type given in make.conf > (x86_64-pc-linux-gnu in your case). > But the erlang configure does also autodetection on the host type, > which may result in something different (x86_64-unknown-linux-gnu here). > > One result goes into the Makefiles, the other one into the > directory names for the compile output, if they don't match, bang! > > The workaround is to find out what erlang configure has autodetected > for your hostname and to set CHOST accordingly while emerging erlang. > > In plain english: CHOST=x86_64-unknown-linux-gnu > Of course, you will want to change it back when finished. Okay. I temporarily changed my make.conf. It is working. Glad is was so simple to solve. Now to the next problem. It creates problems with Yaws. I get this error with Yaws due to this issue. ./configure --prefix=/usr/local checking host system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized checking target system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized checking build system type... Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized checking for erl... /usr/bin/erl checking for erlc... /usr/bin/erlc checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking how to run the C preprocessor... gcc -E checking whether gcc needs -traditional... no checking whether make sets ${MAKE}... yes checking for a BSD compatible install... /bin/install -c unknown configure: error: Non-supported target OS! Any help appreciated. Thanks. Jimmie Houchin From snickl@REDACTED Fri Mar 12 13:04:12 2004 From: snickl@REDACTED (Stefan Nickl) Date: Fri, 12 Mar 2004 13:04:12 +0100 (CET) Subject: Problem installing Yaws was: Re: Problem installing Erlang on Gentoo In-Reply-To: <4051A3A5.7010200@cableone.net> References: <4051426D.7030806@cableone.net> <4051A3A5.7010200@cableone.net> Message-ID: On Fri, 12 Mar 2004, Jimmie Houchin wrote: > It is working. Glad is was so simple to solve. > Now to the next problem. It creates problems with Yaws. > > I get this error with Yaws due to this issue. > > > ./configure --prefix=/usr/local > checking host system type... Invalid configuration > `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized Hm, I'm not an autoconf/automake guru, but the problem seems to be that the config.sub (which does platform detection) which comes with yaws (I'm looking at cvs here) does not know about x86_64. What I find a bit strange is that even the config.sub in my /usr/share/automake-1.4 mentions x86_64... Maybe it helps to do something like cp /usr/share/automake-1.8/config.sub ./configure && make CU, SN -- The UNIX equivalent of the "Blue Screen of Death" would be called "kernel panic". It obviously exists, since I have heard and read about it, but I've never been witness to it in my professional career. John Kirch, Networking Consultant and Microsoft Certified Professional (Windows NT) From jhouchin@REDACTED Fri Mar 12 13:19:04 2004 From: jhouchin@REDACTED (Jimmie Houchin) Date: Fri, 12 Mar 2004 06:19:04 -0600 Subject: Problem installing Yaws was: Re: Problem installing Erlang on Gentoo In-Reply-To: References: <4051426D.7030806@cableone.net> <4051A3A5.7010200@cableone.net> Message-ID: <4051AAB8.2060302@cableone.net> Stefan Nickl wrote: > On Fri, 12 Mar 2004, Jimmie Houchin wrote: > >>It is working. Glad is was so simple to solve. >>Now to the next problem. It creates problems with Yaws. >> >>I get this error with Yaws due to this issue. >> >> >>./configure --prefix=/usr/local >>checking host system type... Invalid configuration >>`x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized > > > Hm, I'm not an autoconf/automake guru, but the problem seems > to be that the config.sub (which does platform detection) > which comes with yaws (I'm looking at cvs here) does not know > about x86_64. > > What I find a bit strange is that even the config.sub in > my /usr/share/automake-1.4 mentions x86_64... > > Maybe it helps to do something like > cp /usr/share/automake-1.8/config.sub > ./configure && make Hello Stefan. When your good, your good. :) I did as you said. It work and is working. Thanks. Jimmie Houchin From erlang@REDACTED Fri Mar 12 13:51:18 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 12 Mar 2004 12:51:18 +0000 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: References: <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> <87ishbo39h.fsf@ghidra.vail> <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> Message-ID: <20040312125118.3ed967a7.erlang@manderp.freeserve.co.uk> Thanks Mike. I've cast a feeler email on the subject to my bosses. They've been receptive to the OSS idea until the "suits" came to play, and that was when the dreaded "intellectual property" argument was put on us. I agree wholeheartedly with you all; ideas don't grow unless they're shared. Put ideas in a sealed box and they wilt like any living being would. Send ideas to the Pastures of the Minds and they grow strong and agile. I don't think anyone else besides the suits need any convincing here. But they're the ones with the money today. I hope that tomorrow we'll be the ones with the money! Pete. On 12 Mar 2004 11:18:11 GMT mike@REDACTED (Mike Williams) wrote: > In article <20040312081830.6068ab1e.erlang@REDACTED>, > erlang@REDACTED (Peter-Henry Mander) writes: > > |> Perhaps I might kick off the issue of OSS on erlang-questions. How > |does> one convince the non-technical bean counters that using and > |_providing_> OSS is of commercial benefit? And that opening source > |code may generate> goodwill (something that SCO Group is suffering a > |severe lack thereof!)> leading to sales. > > There is one one issue, MONEY. > > You have to convince the "owners" of the code (often, but not always > the people who paid for the development of the code), that it is in > their COMMERCIAL ADVANTAGE to contribute the code to Open Source. > > - "Add on" sales of other software for which you can get paid. > (MySQL is a good example of this). > > - "goodwill" and image of a company thus improving the company's > "brand". This is simply a form of marketting". Any (non bankrupt) > company knows that "marketting" costs money. > > - Service / consulting / support services which you can sell. > (Companies like > Red Hat live from support and services) > > - Setting standards. By releasing SW as Open Source you can influence > the > "de facto" industry standard in a direction which is good for your > company.(SUN have done a lot in this direction - for example the > primitives behind NFS). > > - Killing the oposition. You can kill a competitor by giving away an > open source > product which does the same as his expesive product. Even if your > product isn't as good as your competitors product. Why do you think > Micro$oft does all it can throw dirt at Linux? Linux is a real > threat to them! SUN did the same for many years until they realised > that "if you can't beat them, join them". I am sure that a lot of > the companies whi are spending money on Linux are doing so simply to > try to reduce Micro$ofts power and monopoly > > - If you have a legacy product, or a product which isn't bringing in > money > but you still need to support, you might make it Open Source if you > think it would be interesting to others. In this way you can get the > Open Source comunity to support it for you free (Open Office and > Mozilla maybe are examples of this). > > I am sure there are many more reasons. > > /mike > > (PS: The intelligent reader can venture a guess as to why Ericsson > released > Erlang/OTP - as I am a "suite" nowadays, I won't tell you :-) > > This communication is confidential and intended solely for the > addressee(s). Any unauthorized review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorized amendment, tampering and viruses, and we > only send and receive e-mails on the basis that we are not liable for > any such corruption, interception, amendment, tampering or viruses or > any consequences thereof. > -- "The Tao of Programming flows far away and returns on the wind of morning." From gordon.guthrie@REDACTED Fri Mar 12 15:27:07 2004 From: gordon.guthrie@REDACTED (Gordon Guthrie, BTP, BT, SE) Date: Fri, 12 Mar 2004 14:27:07 -0000 Subject: Compile, Load and Purge Message-ID: <23659D76043CD7119EF400805FBE61F203BB018E@SENMAIL> Folks I am developing away in Erlang. I have a setup routine that creates an mnesia database and does some things to it, gets tables set up right and clean. I step through my code in the debugger and make changes, etc, etc. In order to speed things up and not have to recreate the environment I have written a little routine that basically does the following for all my modules: Compile: ______________________________________________________________________ Scottish Enterprise Network http://www.scottish-enterprise.com Address & Contact Numbers 150 Broomielaw 5 Atlantic Quay Glasgow G2 8LU. Tel: +44 (0)141 248 2700. Fax: +44 (0)141 221 3217 message is sent in confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. From ulf.wiger@REDACTED Fri Mar 12 15:33:01 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 12 Mar 2004 15:33:01 +0100 Subject: gen_leader at jungerl Message-ID: (If I've already announced this, apologies.) I've checked in gen_leader in the Jungerl. Gen_leader is a gen_server-like behaviour for writing robust replicated servers. http://jungerl.sourceforge.net/ An example program implementing a global version of dict.erl is included. This example comprises ca 100 lines of code divided over two modules. The code is essentially the same as in the package some of you have received via email, but I've added a fair amount of documentation using edoc. /Uffe -- Ulf Wiger, Senior System Architect EAB/UPD/S This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From gordon.guthrie@REDACTED Fri Mar 12 15:34:22 2004 From: gordon.guthrie@REDACTED (Gordon Guthrie, BTP, BT, SE) Date: Fri, 12 Mar 2004 14:34:22 -0000 Subject: Compile, Delete, Purge and Load Message-ID: <23659D76043CD7119EF400805FBE61F203BB018F@SENMAIL> Apologies to all for going off prematurely on this e-mail, thick fingers today... Folks I am developing away in Erlang. I have a setup routine that creates an mnesia database and does some things to it, gets tables set up right and clean. I step through my code in the debugger and make changes, etc, etc. In order to speed things up and not have to recreate the environment I have written a little routine that basically does the following for all my modules: Results999_G = compile:file("/opt/erlang_apps/swarm/lib/html_fragments-V1/src/sms_shim.erl" , [debug_info, {outdir, "/opt/erlang_apps/swarm/lib/html_fragments-V1/ebin"}]), io:fwrite("G) sms_shim: ~30s~n", [io_lib:write(Results999_G)]), code:delete(sms_shim), code:purge(sms_shim), code:load_file(sms_shim), When I haven't loaded the debugger on a particular module this is fine and the new version is loaded and ready to roll, but when I have looked at a module in the debugger this routine tells me: module sms_shim must be purged before loading and I have to halt the Erlang shell, restart it and reinitialise everything again. How do I get a 'debugged' function to purge? Gordon ______________________________________________________________________ Scottish Enterprise Network http://www.scottish-enterprise.com Address & Contact Numbers 150 Broomielaw 5 Atlantic Quay Glasgow G2 8LU. Tel: +44 (0)141 248 2700. Fax: +44 (0)141 221 3217 message is sent in confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. From erlang@REDACTED Fri Mar 12 16:00:18 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 12 Mar 2004 15:00:18 +0000 Subject: Stand Alone Erlang In-Reply-To: <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> Message-ID: <20040312150018.2c35946a.erlang@manderp.freeserve.co.uk> Hi Dr Joe, We've tried elinking our Megaco test tool with SAE and found a couple of issues. The OTP Megaco stack relies on a C link-in driver for parsing, and I haven't found a way to elink it into the tool. There's also GS which I feel is a hinderance too. This has strengthened the argument for implementing future protocol stacks purely in Erlang. The SIP codec we've written in pure Erlang using binaries runs at comparable speeds to the Megaco stack, so I suspect the C driver doesn't confer a huge speed enhancement overall. Maybe only enough to be noticeble, not orders of magnitude. With concurrency thrown into the mix, the benefit may be moot. I've also found that C-nodes (maybe C-drivers too) don't match the concurrency patterns and ability of Erlang, they're a proverbial pain to get right! I'm sticking to Erlang for any other protocols we may need to implement. The GS problem may coerce future GUIs to use Joe's ex11 too. (-: /Pete. On Thu, 11 Mar 2004 11:44:33 +0000 Peter-Henry Mander wrote: > > Hi Dr Joe, > > btw, do you get to wear a pincushion instead of a common mortarboard? > Or do the Swedes leave such excentricities to English? :-) > > Well, the SAE seems to work out of the box without a hitch on R9C-0. > > Were going to give SAE a spin on our own applications. I'll keep you > posted, including how easy/hard it is to elink in some of the OTP > libraries like the Megaco stack. > > The teabag version is interesting, the next project doesn't appear to > rely on OTP much, if at all. Its not a trivial application, it's for a > SIP protocol load tester. Maybe a good candidate? > > Pete. > > > On Thu, 11 Mar 2004 11:35:59 +0100 (CET) > Joe Armstrong wrote: > > > On Thu, 11 Mar 2004, Peter-Henry Mander wrote: > > > > > Hi Prof Joe, > > **** I did't know I was a Prof :-) > > > > > > > > What is the state of Stand Alone Erlang? Which is the latest > > > version of Erlang that can used with SAE? This tool will be ideal > > > for delivering our testing tool and emulated product for external > > > use. > > > > > > > Good question - I don't know. > > > > It was written for R9X when X < C - and I handed it over to /// - > > the idea was that it sooner or later would creep into the main > > distribution. > > > > It actually gets built in > > > > /usr/local/lib/erlang/erts-5.3/bin > > > > But I havn't tested to see if it still works > > > > The windows bit definately does not work. > > > > Try it and see. > > > > The documentation on > > > > http://www.sics.se/~joe/sae.html > > > > Should still apply. > > > > Let us know what happens. > > > > As an aside I have made "tea-Bag" Erlang - this is a stripped R9C > > (ie throw away as much as possible) and just keep just the stuff you > > need. > > > > I need a minimal system to distribute to a few hundred machines > > (planet lab) and have made teaBag for this purpose. > > > > If there is any interest I can make it available. > > > > > Pete. From hakan@REDACTED Fri Mar 12 16:23:10 2004 From: hakan@REDACTED (Hakan Mattsson) Date: Fri, 12 Mar 2004 16:23:10 +0100 (MET) Subject: Stand Alone Erlang In-Reply-To: <20040312150018.2c35946a.erlang@manderp.freeserve.co.uk> Message-ID: On Fri, 12 Mar 2004, Peter-Henry Mander wrote: > This has strengthened the argument for implementing future protocol > stacks purely in Erlang. The SIP codec we've written in pure Erlang > using binaries runs at comparable speeds to the Megaco stack, so I > suspect the C driver doesn't confer a huge speed enhancement overall. > Maybe only enough to be noticeble, not orders of magnitude. With > concurrency thrown into the mix, the benefit may be moot. There are two text scanners included in the Megaco application, one is a C-driver and the other is written in plain Erlang. The performance difference between the scanners is about a factor 10. When decoding a Megaco text message, half of the time is parsing and half is scanning when using the Erlang scanner. So even if the C scanner is 10 times faster, the total performance gain for decoding is not more than 2 times. If it is neglectible or not, is up to you to decide. /H?kan --- H?kan Mattsson Ericsson High Availability Software, DBMS Internals http://www.erlang.org/~hakan/ This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From serge@REDACTED Fri Mar 12 16:32:14 2004 From: serge@REDACTED (Serge Aleynikov) Date: Fri, 12 Mar 2004 10:32:14 -0500 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> <87ishbo39h.fsf@ghidra.vail> <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> Message-ID: <4051D7FE.6060006@hq.idt.net> Not sure if you find this helpful, but I recently found out from Pekka Hedqvist that there's an open-source Erlang implementation of the SIP stack with a few sample SIP applications: http://www.stacken.kth.se/projekt/yxa/ Serge Peter-Henry Mander wrote: > Hi Hal, > > I suspected someone would pick up on the SIP protocol load tester just > after I pressed send. I originally wished to release this under a BSD > style licence, but we're in talks with investors and it was deemed a bad > time to release our "intellectual property" at such a sensitive time. > Sorry. > > It's a pity, I would have liked it to be my contribution to open-source, > and initially management was warming to the idea, bless them. Heaven > knows how much OSS has helped me achieve so much! And having an outside > opinion on what I've done so far would have helped too. > > Perhaps I might kick off the issue of OSS on erlang-questions. How does > one convince the non-technical bean counters that using and _providing_ > OSS is of commercial benefit? And that opening source code may generate > goodwill (something that SCO Group is suffering a severe lack thereof!) > leading to sales. > > But hey! I'm a naive soft-hearted programmer who knows nothing about the > hard tooth-and-nail world of commerce! > > Maybe geeks and suits will never really understand each other... > > Pete. > > P.s. However, if what we're doing interests you as a customer, Hal, > please visit http://www.newport-networks.com/ and we can discuss this at > a commercial level :-) > > > > On Thu, 11 Mar 2004 08:40:58 -0600 > Hal Snyder wrote: > > >>Sounds interesting. Are outside collaboraters allowed? From erlang@REDACTED Fri Mar 12 17:01:04 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 12 Mar 2004 16:01:04 +0000 Subject: Stand Alone Erlang In-Reply-To: References: <20040312150018.2c35946a.erlang@manderp.freeserve.co.uk> Message-ID: <20040312160104.7fa83cdd.erlang@manderp.freeserve.co.uk> Hi Hakan, Thanks for the figures for the Megaco lexer C driver performance. I should have realised there was a good reason for spending such effort on a C driver! I stand corrected. Do you imply that if the scanner was incorporated into the C driver, there would be a speed gain of up to 10 times faster? This would be not so negligable! I'm anticipating that distributing the SIP load tester over a farm of cheap PCs would scale performance far more easily than me attempting a SIP lexer C driver. It wasn't too trivial (for me a least!) writing the whole SIP codec in Erlang from the ABNF specs, including tel-URI. It took me a couple of weeks of trial and error. What would it be like to implement it in lex/flex as a C driver? Pete. On Fri, 12 Mar 2004 16:23:10 +0100 (MET) Hakan Mattsson wrote: > On Fri, 12 Mar 2004, Peter-Henry Mander wrote: > > > This has strengthened the argument for implementing future protocol > > stacks purely in Erlang. The SIP codec we've written in pure Erlang > > using binaries runs at comparable speeds to the Megaco stack, so I > > suspect the C driver doesn't confer a huge speed enhancement > > overall. Maybe only enough to be noticeble, not orders of magnitude. > > With concurrency thrown into the mix, the benefit may be moot. > > There are two text scanners included in the Megaco application, one is > a C-driver and the other is written in plain Erlang. The performance > difference between the scanners is about a factor 10. > > When decoding a Megaco text message, half of the time is parsing and > half is scanning when using the Erlang scanner. So even if the C > scanner is 10 times faster, the total performance gain for decoding > is not more than 2 times. If it is neglectible or not, is up to you to > decide. > -- "The Tao of Programming flows far away and returns on the wind of morning." From 08.55088832@REDACTED Thu Mar 11 19:22:29 2004 From: 08.55088832@REDACTED (Kenneth Lundin) Date: Thu, 11 Mar 2004 19:22:29 +0100 Subject: Stand Alone Erlang Message-ID: <000001c40795$d03ff330$a6b7fea9@snabbis> Hi, As developers and maintainers of Open Source Erlang and the commercial supported version of Erlang we have in our plan to release Stand Alone Erlang hopefully this year (no promise). Although I think SAE is important other things with higher priority for our paying customers have occupied our time so far. We have Joes implementation but need to do a better integration with the rest of the product to get it maintainable. Examples of problems to solve before we release it are: - Avoid having to build a special runtime-system binary for SAE - We must have a smarter way to handle erlang.ear and other archives. A possible solution might be that the erlang.ear is built at install-time and at patch installation so it always gets updated with the latest modules from the compiler, kernel, stdlib applications. - It should work on all supported platforms when we release it (Windows requires some alternative solutions) - . Kenneth Lundin (Product Manager for Erlang/OTP at Ericsson) This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Fri Mar 12 13:32:54 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 12 Mar 2004 13:32:54 +0100 Subject: gen_leader at jungerl Message-ID: I've added gen_leader, a gen_server-like behaviour for writing fault-tolerant replicated servers, to Jungerl. As an example program, I've included a fully replicated version of dict.erl, using about 100 lines of code in two modules (in addition to what's in dict.erl, that is.) It's basically the same stuff that some of you have received through email, except I've added a reasonable amount of edoc- based documentation. Please report if there are any problems with make (I have to do the cvs stuff on a machine that has no erlang, for now. I'll try to improve matters on my end.) The leader election algorithm part was done by Thomas Arts, as a spinoff from working with the 'locker' contrib. Building gen_leader, I had an opportunity to try "pair programming" and decided that it's a lot of fun if you find the right person to pair up with. (: /Uffe -- Ulf Wiger, Senior System Architect EAB/UPD/S This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From eduardo@REDACTED Fri Mar 12 16:29:42 2004 From: eduardo@REDACTED (Eduardo Figoli) Date: Fri, 12 Mar 2004 12:29:42 -0300 Subject: Transactional filesystem access Message-ID: <006701c40846$debb5b50$1e00a8c0@design> Hi! I have PidA in MachineA and PidB in machineB, both linked. When PidB receives a message from PidA, PidB executes a write file accesss function (using file:prwrite) Suppose PidB takes T time to write to the file. - What does it happens when an EXIT from PidA is received on time From erlang@REDACTED Fri Mar 12 17:11:04 2004 From: erlang@REDACTED (Peter-Henry Mander) Date: Fri, 12 Mar 2004 16:11:04 +0000 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <4051D7FE.6060006@hq.idt.net> References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> <87ishbo39h.fsf@ghidra.vail> <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> <4051D7FE.6060006@hq.idt.net> Message-ID: <20040312161104.2af7f450.erlang@manderp.freeserve.co.uk> Hi Serge, Yup, I had a chat with Fredrik Thulin, and I follow the project as closely as I can. At the time I inspected the SIP stack, it was simple but effective enough for the purpose, but not really what I was looking for. I think there is a difference in requirements between what I need and what Fredrik aims to make with Yxa. I want to thoroughly test SIP implementations, functionally and under load conditions, whereas Yxa may only strictly requires a subset of information extracted from SIP messages. I invite whoever knows the Yxa project better than I to correct my opinion, of course. /Pete. On Fri, 12 Mar 2004 10:32:14 -0500 Serge Aleynikov wrote: > Not sure if you find this helpful, but I recently found out from Pekka > Hedqvist that there's an open-source Erlang implementation of the SIP > stack with a few sample SIP applications: > > http://www.stacken.kth.se/projekt/yxa/ > > Serge > > > Peter-Henry Mander wrote: > > > Hi Hal, > > > > I suspected someone would pick up on the SIP protocol load tester > > just after I pressed send. I originally wished to release this under > > a BSD style licence, but we're in talks with investors and it was > > deemed a bad time to release our "intellectual property" at such a > > sensitive time. Sorry. > > > > It's a pity, I would have liked it to be my contribution to > > open-source, and initially management was warming to the idea, bless > > them. Heaven knows how much OSS has helped me achieve so much! And > > having an outside opinion on what I've done so far would have helped > > too. > > > > Perhaps I might kick off the issue of OSS on erlang-questions. How > > does one convince the non-technical bean counters that using and > > _providing_ OSS is of commercial benefit? And that opening source > > code may generate goodwill (something that SCO Group is suffering a > > severe lack thereof!) leading to sales. > > > > But hey! I'm a naive soft-hearted programmer who knows nothing about > > the hard tooth-and-nail world of commerce! > > > > Maybe geeks and suits will never really understand each other... > > > > Pete. > > > > P.s. However, if what we're doing interests you as a customer, Hal, > > please visit http://www.newport-networks.com/ and we can discuss > > this at a commercial level :-) > > > > > > > > On Thu, 11 Mar 2004 08:40:58 -0600 > > Hal Snyder wrote: > > > > > >>Sounds interesting. Are outside collaboraters allowed? > -- "The Tao of Programming flows far away and returns on the wind of morning." From hal@REDACTED Fri Mar 12 17:18:12 2004 From: hal@REDACTED (Hal Snyder) Date: Fri, 12 Mar 2004 10:18:12 -0600 Subject: OSS In-Reply-To: (Joe Armstrong's message of "Fri, 12 Mar 2004 10:57:27 +0100 (CET)") References: Message-ID: <8765da3upn.fsf@ghidra.vail> Joe Armstrong writes: >> Perhaps I might kick off the issue of OSS on erlang-questions. How >> does one convince the non-technical bean counters that using and >> _providing_ OSS is of commercial benefit? And that opening source >> code may generate goodwill (something that SCO Group is suffering a >> severe lack thereof!) leading to sales. > > I would argue that S/W falls into several different categories > > 1) Pre-competitive > 2) Competitive > 3) General odds and sods Right. I am very big on code sharing, but one reason that I can participate in all this fun and open OTP work is that my employer - who is relatively enlightened re open source - is able to license SIP based software (C++ gateways, proxies, conferencing, and app engines). In spite of the above I think SIP is only barely out of Joe's stage 1) above. Another example of 3) would be an interoperability test suite (basically a contract checker for SIP), which could be good for all players because it facilitates adoption of SIP increasing the overall market. ObErlang: One reason OTP is such a good fit for our SIP platform is that SIP alone is not enough. While it allows you to switch calls around over an arbitrarily large network, I think you need more than SIP for propagating call state. (There's an analogy with the stateless vs. session issues in HTTP). That is where OTP is a big help distributing call state while SIP interfaces to the outside and does call setup and teardown. From taj.khattra@REDACTED Fri Mar 12 19:32:30 2004 From: taj.khattra@REDACTED (Taj Khattra) Date: Fri, 12 Mar 2004 10:32:30 -0800 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <20040312125118.3ed967a7.erlang@manderp.freeserve.co.uk> References: <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> <87ishbo39h.fsf@ghidra.vail> <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> <20040312125118.3ed967a7.erlang@manderp.freeserve.co.uk> Message-ID: <20040312183230.GA2505@localhost.localdomain> On Fri, Mar 12, 2004 at 12:51:18PM +0000, Peter-Henry Mander wrote: > But they're the ones with the money today. I hope that tomorrow we'll be > the ones with the money! generally speaking, it doesn't look too rosy... http://eveander.com/general-comments/attachment/28/VCs%20web.pdf -taj From tobbe@REDACTED Fri Mar 12 23:19:28 2004 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Fri, 12 Mar 2004 23:19:28 +0100 Subject: crypto(3) ? In-Reply-To: References: Message-ID: <40523770.8010400@bluetail.com> Thanx a lot Peter ! (I just got encrypted passwords with esmb to work.) Cheers, Tobbe peter@REDACTED wrote: >Hi, > >It is covered, but you have to use a special case of the des_cbc_encrypt/3 >function as follows (referring to the example in your letter below): > > E(Ki,Dj) = crypto:des_cbc_encrypt(Ki, 0, Dj), i=0,Kmax, j=0,..Dmax, > >where Ki and Dj are 8 byte quantities (for each Ki only 7 bits are >considered). > >The des functions in `crypto' are for the Cipher Block Chaining (CBC) >mode, where results of the previous encryption/decryption step is fed into >the next step by the initializing vector, IV, but can be used for the >basic DES mode as well: > >If IV is set to zero (it is xored with the first 8 byte segment of input), >and 8 byte is provided as input, you get the basic DES >encryption/decryption of an 8 byte quantity. > >This is not at all obvious, but true. FIPS 81 states the details. > >/Peter > > >On Thu, 4 Mar 2004, Torbj?rn T?rnkvist wrote: > > > >>Hi, >> >>I've been comparing the crypto(3) man page with the CIFS description >>on how the (SMB) session key is computed, trying to understand if they >>are the same. Perhaps someone (Peter ?) could comment on this? >> >>The CIFS explanation: >> ------------------------------------ >>E(K, D) denote the DES block mode encryption function [FIPS 81] , which >>accepts a seven byte key (K) and an eight byte data block (D) and produces >>an eight byte encrypted data block as its value. >> >>Ex(K,D) denote the extension of DES to longer keys and data blocks. If the >>data to be encrypted is longer than eight bytes, the encryption function is >>applied to each block of eight bytes in sequence and the results are >>concatenated >>together. If the key is longer than seven bytes, each 8 byte block of >>data is first >>completely encrypted using the first seven bytes of the key, then the >>second seven >>bytes, etc., appending the results each time. For example, to encrypt >>the 16 byte >>quantity D0D1 with the 14 byte key K0K1, >>Ex(K0K1,D0D1) = concat(E(K0,D0),E(K0,D1),E(K1,D0),E(K1,D1)) >> >>So is this algorithm covered by the crypto module? >>This just gives me headache... >> >>Cheers, Tobbe >> >> >> >>This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. >> >>E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. >> >> >> > > >This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > >E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > > > > From klacke@REDACTED Sat Mar 13 01:09:22 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Sat, 13 Mar 2004 01:09:22 +0100 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> <20040311114433.41b94faa.erlang@manderp.freeserve.co.uk> <87ishbo39h.fsf@ghidra.vail> <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> Message-ID: <20040313000922.GA30095@hyber.org> On Fri, Mar 12, 2004 at 10:34:42AM +0100, Ulf Wiger wrote: > - that we first have to replace all copyright lingo in the source; Easy, > - that we have to rewrite/reformat the documentation; Easy, > - that our design environment is different enough frin e.g. > sourceforge that we have to duplicate the code and maintain > two separate versions; Hard, we're doing this now. Basically the revision control problem is to have code in 2 different CVS systems and sync them. Not trivial, or even hard. > - that accessing sourceforge CVS from our workstations is ridiculously > difficult due to security policy. Well, that sounds like a bug :-( > > I'd like to see our design environments set up so that it's easy > to release choice parts as OSS and still keep one code base. > OTP has done this, and it seems to work very well for them. Of course, > they don't have proprietary parts, but release everything as OSS. > Mixing proprietary and OSS is perhaps a bit trickier... Much, but a necessary evil if you want to contribute some parts of your system that you find interesting to the public. Finally, I think that by selecting a part of your system and making that part open source, may actually improve things. It will cast the interfaces to that part in iron. It will make the parts of your proprietary system that interface the OSS part cleaner, since it will use a clear interface. Otherwise in largish systems, everybody gets to call() everybody and system becomes a mess. If there at least are a couple of core interfaces, ... well, it improves. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From klacke@REDACTED Sat Mar 13 01:24:42 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Sat, 13 Mar 2004 01:24:42 +0100 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: References: <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> Message-ID: <20040313002442.GB30095@hyber.org> On Fri, Mar 12, 2004 at 11:18:11AM +0000, Mike Williams wrote: > In article <20040312081830.6068ab1e.erlang@REDACTED>, > erlang@REDACTED (Peter-Henry Mander) writes: > > |> Perhaps I might kick off the issue of OSS on erlang-questions. How does > |> one convince the non-technical bean counters that using and _providing_ > |> OSS is of commercial benefit? And that opening source code may generate > |> goodwill (something that SCO Group is suffering a severe lack thereof!) > |> leading to sales. > > There is one one issue, MONEY. > Nahhh, wrong. > You have to convince the "owners" of the code (often, > but not always the people > who paid for the development of the code), that it is in their COMMERCIAL > ADVANTAGE to contribute the code to Open Source. > So, the COMMERCIAL bit here, well some lame corps release code as open source just because they thing it's in their COMMERCIAL interest. That doesn't apply to the vast majority of open source code though. Most of it is released by feverish individuals with various murky agendas, such as "destroy Microsoft" or "earn reputation as hacker" or whatnot. Then there are a number of largish corporations, such as /// and Nortel that only go where the money is. However, within these corporations thare are decent individuals that "do the right thing" Remember, it's easier to get forgivness than to get permission. So don't ask for permission, just release it. I did (Yaws) > > (PS: The intelligent reader can venture a guess as to why Ericsson released > Erlang/OTP - as I am a "suite" nowadays, I won't tell you :-) > As if you know, you don't. What goes on in the heads of the suits is as inpredictable as the stockmarket. Q.E.D. > This communication is confidential and intended solely for the addressee(s). And this is not, I hereby, freely allow anyone who reads this to rephrase it and resend it as they please. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From klacke@REDACTED Sat Mar 13 01:38:26 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Sat, 13 Mar 2004 01:38:26 +0100 Subject: Transactional filesystem access In-Reply-To: <006701c40846$debb5b50$1e00a8c0@design> References: <006701c40846$debb5b50$1e00a8c0@design> Message-ID: <20040313003826.GC30095@hyber.org> On Fri, Mar 12, 2004 at 12:29:42PM -0300, Eduardo Figoli wrote: > Hi! > > I have PidA in MachineA and PidB in machineB, both linked. > > > > When PidB receives a message from PidA, PidB executes a write file > accesss function > (using file:prwrite) > > > > Suppose PidB takes T time to write to the file. > - What does it happens when an EXIT from PidA is received on time (while > the function in PidB is still executing)? > Is the file parcially written in some case? Remeber, there is never any true concurrency in the erlang runtime. Either your process is running and writing the file, (through the driver) or the runtime system is running (and picking up the EXIT from the socket to node A) and the possibly killing PidB. However PidP will never be killed at a random time. It will always be killed inbetween opcodes, that is: ywhile being suspended. EXIT signals aren't unix signals .. at all. So, in your case either the call to file:pwrite() is done, or it isn't. Or to be nore correct. Either he final port_command() in the file module is done, or it isn't. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From igouy2@REDACTED Sat Mar 13 17:56:25 2004 From: igouy2@REDACTED (Isaac Gouy) Date: Sat, 13 Mar 2004 08:56:25 -0800 (PST) Subject: Erlang question on Artima blog Message-ID: <20040313165625.55083.qmail@web60505.mail.yahoo.com> There's a question about the granularity of Erlang's approach to fault-tolerance (and the relationship to Design by Contract) on the Artima blog: http://www.artima.com/forums/flat.jsp?forum=226&thread=37878 Could some experienced individual please provide answers? ;-) __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com From hal@REDACTED Sat Mar 13 20:44:53 2004 From: hal@REDACTED (Hal Snyder) Date: Sat, 13 Mar 2004 13:44:53 -0600 Subject: OSS In-Reply-To: <20040313002442.GB30095@hyber.org> (klacke@hyber.org's message of "Sat, 13 Mar 2004 01:24:42 +0100") References: <20040312081830.6068ab1e.erlang@manderp.freeserve.co.uk> <20040313002442.GB30095@hyber.org> Message-ID: <87k71ottu2.fsf@ghidra.vail> klacke@REDACTED writes: > So, the COMMERCIAL bit here, well some lame corps release code as > open source just because they thing it's in their COMMERCIAL > interest. That doesn't apply to the vast majority of open source > code though. Most of it is released by feverish individuals with > various murky agendas, such as "destroy Microsoft" or "earn > reputation as hacker" or whatnot. Hurrah for the murky agendas, whatever they may be, as long as it gets people thinking and creating things. I think there is something going on with open source that is bigger than any of its zealots, exploiters, or apologists. The activity by thousands of individuals all over the globe of real-time collaboration on creative pursuits marks another turning point in the history of our species. There is almost a zoologist's delight in watching the process of natural selection take place among the projects. Sorry for OT, will go back to review of EOPL in hopes of being able to comprehend things like ubf's proc_socket_server.erl more quickly. From ulf.wiger@REDACTED Sat Mar 13 22:24:29 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sat, 13 Mar 2004 22:24:29 +0100 Subject: Erlang question on Artima blog In-Reply-To: <20040313165625.55083.qmail@web60505.mail.yahoo.com> References: <20040313165625.55083.qmail@web60505.mail.yahoo.com> Message-ID: On Sat, 13 Mar 2004 08:56:25 -0800 (PST), Isaac Gouy wrote: > There's a question about the granularity of Erlang's approach to > fault-tolerance (and the relationship to Design by Contract) on the > Artima blog: > > http://www.artima.com/forums/flat.jsp?forum=226&thread=37878 > > Could some experienced individual please provide answers? ;-) I was going to, but the Artima user registration service seemed to have problems sending me a password for my account. When I wrote their webmaster and was asked to reply to some generated email address, I got an NDN back. Oh, well... Basically, the answer was going to be something like: 1) If system failure is not an option, you have to go with hardware redundancy, so a process might be allowed to crash the processor/OS it is running on. This is important, as it allows you write "kernel processes", that have to be assumed correct for the node to be operational. In Erlang, you can build a system using multiple "Erlang nodes", where distribution aspects can be either transparent or explicit, depending on the role of your program. This is how redundancy is normally implemented, and it can be done in several ways, depending on requirements: a) Hot standby: typically, a process on another computer would monitor the active process, and the two would employ some replication protocol to stay in synch. This implies quite explicit exception handling on the part of the standby process. However, the logic required can be packaged as a reusable framework, so that the process assuming the active role is notified through a simple callback function. b) Cold standby: The Erlang nodes can be configured so that the applications running on one node will be restarted on another in case of failure. The applications can detect that they are starting due to "failover" from another node, or they can start as they normally do. 2) A process crash does not have to lead to a node crash. Erlang's "process linking" concept can be used in a variety of ways. a) The default behaviour is that if a process dies, all processes linked to it will also die. This is called "cascading exit", and allows you to clean up a fairly large amount of work automatically. b) A process that wants to take action when another dies can trap exits. Example: if process A wants to open a file, the file library spawns a process B that opens the file and acts as a middle man; B becomes A's file handle. If A dies, B, having linked itself to A and trapping exits, detects this (it receives an 'EXIT' message from A), closes the file, and then exits. c) Supervisors are special processes built on the linking concept. If a supervised process dies, it is restarted with default values by its supervisor. If necessary, the supervisor can be configured to restart a group of processes, as this may simplify the re-synchronization. If the restart frequency exceeds a configured limit, the supervisor exits, and lets the next-level supervisor handle the situation (escalated restart.) d) Re-acquiring a process handle may not be necessary. A process can register itself using a logical name, and other processes wanting to talk to it, can use the logical name as the destination for message sending. After a crash, the new process registers under the same name, and other processes may never know the difference. 3) Erlang doesn't really use Design by Contract, but relies rather heavily on pattern matching. For example, The function file:open(File, Mode) is defined so that it returns {ok, FileDescr} or {error, Reason}. A typical call to this function would be formulated: {ok, Fd} = file:open("foo.txt", [read]). This means that the caller will assert that the returned value is a 2-tuple where the first element is the constant 'ok', and the second is some object that becomes bound to the free variable Fd. If the function would return e.g. {error, enoent}, the caller would crash. This is called "programming for the correct case", and is widely used in Erlang. It works wonderfully for both large and small systems. Pattern matching can also be used on the inputs to a function. For example the function hd(List), extracting the first element from a linked list, could be written: hd([Head|_]) -> Head. Meaning that the function will only accept as input a list containing at least one element (_ is a "don't care" pattern, and in this case represents the tail of the list.) Any other input will cause a function_clause exception. This could also be written explicitly as: hd([Head|_]) -> Head; hd(Other) -> exit({function_clause, Other}). /Uffe -- Ulf Wiger From igouy2@REDACTED Sat Mar 13 23:31:13 2004 From: igouy2@REDACTED (Isaac Gouy) Date: Sat, 13 Mar 2004 14:31:13 -0800 (PST) Subject: Erlang question on Artima blog In-Reply-To: Message-ID: <20040313223113.896.qmail@web60501.mail.yahoo.com> --- Ulf Wiger wrote: > I was going to, but the Artima user registration service seemed > to have problems sending me a password for my account. When I wrote > their webmaster and was asked to reply to some generated email > address, I got an NDN back. Oh, well... Thanks, I took the liberty of posting it for you. __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com From roger.larsson@REDACTED Sun Mar 14 00:51:01 2004 From: roger.larsson@REDACTED (Roger Larsson) Date: Sun, 14 Mar 2004 00:51:01 +0100 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <20040313000922.GA30095@hyber.org> References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> <20040313000922.GA30095@hyber.org> Message-ID: <200403140051.01186.roger.larsson@norran.net> On Saturday 13 March 2004 01.09, klacke@REDACTED wrote: > > - that our design environment is different enough frin e.g. > > ? sourceforge that we have to duplicate the code and maintain > > ? two separate versions; > > Hard, we're doing this now. Basically the revision control problem > is to have code in 2 different CVS systems and sync them. > Not trivial, or even hard. Isn't this one of BitKeepers main features? (used for Linux kernel) http://www.bitkeeper.com/ /RogerL -- Roger Larsson Skellefte? Sweden From spearce@REDACTED Sun Mar 14 00:13:40 2004 From: spearce@REDACTED (Shawn Pearce) Date: Sat, 13 Mar 2004 18:13:40 -0500 Subject: Erlang question on Artima blog In-Reply-To: References: <20040313165625.55083.qmail@web60505.mail.yahoo.com> Message-ID: <20040313231340.GL6288@spearce.org> Ulf Wiger wrote: > 3) Erlang doesn't really use Design by Contract, but relies > rather heavily on pattern matching. For example, > The function file:open(File, Mode) is defined so that it > returns {ok, FileDescr} or {error, Reason}. A typical > call to this function would be formulated: > > {ok, Fd} = file:open("foo.txt", [read]). And yet I seem to write: case file:open(...) of {ok, Fd} -> Ret = do_something_with_file(Fd), file:close(Fd), Ret Other -> Other end. much more often. Help, what is wrong with me! :-) -- Shawn. From spearce@REDACTED Sun Mar 14 00:52:15 2004 From: spearce@REDACTED (Shawn Pearce) Date: Sat, 13 Mar 2004 18:52:15 -0500 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <200403140051.01186.roger.larsson@norran.net> References: <20040311090026.4c2d47e8.erlang@manderp.freeserve.co.uk> <20040313000922.GA30095@hyber.org> <200403140051.01186.roger.larsson@norran.net> Message-ID: <20040313235215.GM6288@spearce.org> It is, and its an excellent tool. However its expensive in the commerical world compared to CVS, and for open source users its license isn't quite as friendly as the license that covers CVS. On the other hand, if you have this sort of problem, BitKeeper can quickly become your best friend. Roger Larsson wrote: > On Saturday 13 March 2004 01.09, klacke@REDACTED wrote: > > > - that our design environment is different enough frin e.g. > > > ? sourceforge that we have to duplicate the code and maintain > > > ? two separate versions; > > > > Hard, we're doing this now. Basically the revision control problem > > is to have code in 2 different CVS systems and sync them. > > Not trivial, or even hard. > > Isn't this one of BitKeepers main features? (used for Linux kernel) > http://www.bitkeeper.com/ > > /RogerL > > -- > Roger Larsson > Skellefte? > Sweden -- Shawn. #if 0 2.2.16 /usr/src/linux/fs/buffer.c From ulf.wiger@REDACTED Sun Mar 14 09:31:16 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sun, 14 Mar 2004 09:31:16 +0100 Subject: Erlang question on Artima blog In-Reply-To: <20040313231340.GL6288@spearce.org> References: <20040313165625.55083.qmail@web60505.mail.yahoo.com> <20040313231340.GL6288@spearce.org> Message-ID: On Sat, 13 Mar 2004 18:13:40 -0500, Shawn Pearce wrote: > And yet I seem to write: > > case file:open(...) of > {ok, Fd} -> > Ret = do_something_with_file(Fd), > file:close(Fd), > Ret > Other -> > Other > end. > > much more often. Help, what is wrong with me! :-) Oh, don't worry. It's a mild affliction. (: I think writing code that either does what it's supposed to or exits is an acquired taste, and you grow into it slowly once (and if!) you set your mind to it. You need to sit down and really think about how and where you want to handle errors in your code. Personally, I think "programming for the correct case" has significantly improved the readability of my own programs (at least my own ability to understand what I've written. ;) /Uffe -- Ulf Wiger From sean.hinde@REDACTED Sun Mar 14 12:22:58 2004 From: sean.hinde@REDACTED (Sean Hinde) Date: Sun, 14 Mar 2004 11:22:58 +0000 Subject: Mailing List Archives Message-ID: Hi, The mailing list archives are a fantastic resource, but the search engine is slow and cumbersome which means that it's value is significantly reduced from what it could be. I wonder if it would be possible to make the raw mbox files available for download for each month like many other lists do - mail clients do make excellent local search engines. Thanks, Sean From vances@REDACTED Sun Mar 14 19:48:33 2004 From: vances@REDACTED (Vance Shipley) Date: Sun, 14 Mar 2004 13:48:33 -0500 Subject: Erlang question on Artima blog In-Reply-To: References: <20040313165625.55083.qmail@web60505.mail.yahoo.com> <20040313231340.GL6288@spearce.org> Message-ID: <20040314184833.GJ8800@frogman.motivity.ca> The real trick is to decide when to accept errors and when not to. You expect file:open/2 to always work and if it doesn't you crash. That one's easy. When you are parsing user input, like in a shell, you probably want to handle unexpected data without crashing. What about external data arriving in a protocol? If it doesn't obey the protocol should you crash or should you treat it as the user input case? What about databases; if they don't contain the data you expect should you crash? Designing an error handling strategy can be complicated. -Vance On Sun, Mar 14, 2004 at 09:31:16AM +0100, Ulf Wiger wrote: } } Personally, I think "programming for the correct case" has } significantly improved the readability of my own programs } (at least my own ability to understand what I've written. ;) From ulf.wiger@REDACTED Sun Mar 14 19:58:04 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sun, 14 Mar 2004 19:58:04 +0100 Subject: Erlang question on Artima blog In-Reply-To: <20040314184833.GJ8800@frogman.motivity.ca> References: <20040313165625.55083.qmail@web60505.mail.yahoo.com> <20040313231340.GL6288@spearce.org> <20040314184833.GJ8800@frogman.motivity.ca> Message-ID: On Sun, 14 Mar 2004 13:48:33 -0500, Vance Shipley wrote: > The real trick is to decide when to accept errors and when > not to. You expect file:open/2 to always work and if it > doesn't you crash. That one's easy. When you are parsing > user input, like in a shell, you probably want to handle > unexpected data without crashing. What about external > data arriving in a protocol? If it doesn't obey the > protocol should you crash or should you treat it as the > user input case? What about databases; if they don't > contain the data you expect should you crash? Designing > an error handling strategy can be complicated. Agreed. That's what I meant by: On Sun, 14 Mar 2004 09:31:16 +0100, Ulf Wiger wrote: > You need to sit down and really think about how and > where you want to handle errors in your code. But I've found that in most of my programs, it's sufficient to handle errors in a few places, and let the rest of the functions exit as soon as anything unexpected happens. /Uffe (: -- Ulf Wiger From kent@REDACTED Sun Mar 14 22:58:29 2004 From: kent@REDACTED (Kent Boortz) Date: 14 Mar 2004 22:58:29 +0100 Subject: Mailing List Archives In-Reply-To: References: Message-ID: Sean Hinde writes: > The mailing list archives are a fantastic resource, but the search > engine is slow and cumbersome which means that it's value is > significantly reduced from what it could be. Yes, the search engine used actually open up all HTML files to find the matches, no index is created. Also an unfortunate side effect of the recent mail address hiding in PNG images break the search on author. So the search engine don't work that well. > I wonder if it would be possible to make the raw mbox files available > for download for each month like many other lists do - mail clients do > make excellent local search engines. A heaven for spammers don't you think? ;-) The format the monthly lists are stored in is in mbox format so publishing them could be done fairly easy but we need to remove the email addresses somehow. As an alternative you could use the HTML archive of the lists at gmane.org and use their very fast search engine http://news.gmane.org/gmane.comp.lang.erlang.general http://news.gmane.org/gmane.comp.lang.erlang.bugs http://news.gmane.org/gmane.comp.lang.erlang.patches http://news.gmane.org/gmane.comp.lang.erlang.distel.devel You can also read the lists from your news reader. I don't think they hide email addresses very well but they claim the robots spammers use to gather email addresses are not that smart yet. I don't know who put the erlang lists in gmane or who is the administrator of the erlang lists on gmane. There is an option to add harder encryption on the email addresses, kent Ref: http://gmane.org/tmda.php http://gmane.org/faq.php This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From ok@REDACTED Sun Mar 14 23:25:34 2004 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 15 Mar 2004 11:25:34 +1300 (NZDT) Subject: OSS (was Re: Stand Alone Erlang) Message-ID: <200403142225.i2EMPYVl150036@atlas.otago.ac.nz> Ulf Wiger wrote: If your business is to make more complex products, possibly using a mix of 3rd party and OSS components, whether to release one of your own tools or components as OSS would depend mostly on whether you think that the expected return (in terms of outside help improving the code) would outweigh the cost of packaging and documenting it for external use. One question is whether there is any expected return *other than* help improving the code. I suggest that there is: building a reputation. * If potential investors are technically informed, they can look at the code and form their own opinion of your code quality. * If they aren't, they can be impressed by the fact that *you* think your code quality is good enough to let people look at it. * Above all, if you can say "hundreds of projects are using this code of ours", that gives investors some confidence that there might be some kind of market for some of the things you do. * It can serve as advertising. Let me give one example. Ross Quinlan wrote a decision tree induction program called C4.5. Now, if I hadn't gone looking for a free copy of C4.5 (and found it), I would never have known that he now has a company selling more advanced data mining tools and services. Giving C4.5 away has given him a reputation which now makes the products and services of his company attactive. (Considering what happens when you run lint on the c4.5 source code, there can be reasons for *not* releasing your source code...) From igouy2@REDACTED Sun Mar 14 23:54:58 2004 From: igouy2@REDACTED (Isaac Gouy) Date: Sun, 14 Mar 2004 14:54:58 -0800 (PST) Subject: AXD 301 - core functionality is not in erlang? Message-ID: <20040314225458.41964.qmail@web60510.mail.yahoo.com> Maybe I shouldn't start get into these discussions - but at least I know when I'm out-of-my depth ;-) http://groups.google.com/groups?q=g:thl2903698339d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=4054A6B0.6090600%40possibility.com "Erlang is wonderful. But they do not code the entire switch in erlang. The core functionality is not in erlang. I've very much wanted to try erlang on some embedded projects, but i don't like the idea of having multiple language environments and erlang has performance and scheduling latency issues." __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com From ulf.wiger@REDACTED Mon Mar 15 07:27:48 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 15 Mar 2004 07:27:48 +0100 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <200403142225.i2EMPYVl150036@atlas.otago.ac.nz> References: <200403142225.i2EMPYVl150036@atlas.otago.ac.nz> Message-ID: On Mon, 15 Mar 2004 11:25:34 +1300 (NZDT), Richard A. O'Keefe wrote: > Ulf Wiger wrote: > If your business is to make more complex products, possibly using a mix > of 3rd party and OSS components, whether to release one of your own > tools > or components as OSS would depend mostly on whether you think that the > expected return (in terms of outside help improving the code) would > outweigh the cost of packaging and documenting it for external use. > > One question is whether there is any expected return *other than* > help improving the code. I suggest that there is: building a > reputation. Oh yes, absolutely. /Uffe -- Ulf Wiger From matthias@REDACTED Sun Mar 14 23:17:20 2004 From: matthias@REDACTED (Matthias Lang) Date: Sun, 14 Mar 2004 23:17:20 +0100 Subject: Mailing List Archives In-Reply-To: References: Message-ID: <16468.55792.399881.657483@antilipe.corelatus.se> Sean Hinde writes: > I wonder if it would be possible to make the raw mbox files available > for download for each month like many other lists do - mail clients do > make excellent local search engines. Why not just make your own mbox files from the WWW archives? 1. Use "wget" to fetch a directory full of the archive. For example to do last month: wget -r -l 2 http://www.erlang.org/ml-archive/erlang-questions/200402/maillist.html 2. Convert the HTML messages into more or less normal mail. I've attached a program to do that. For one message, you'd do this: ml2mb:message("/tmp/z/www.erlang.org/ml-archive/erlang-questions/200403/msg00011.html"). Converting all the messages in a directory is left as an exercise. 3. Assemble the mbox files, e.g. cat *.mbox > mbox.200403 Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: ml2mb.erl Type: application/octet-stream Size: 1086 bytes Desc: not available URL: From bjorn@REDACTED Mon Mar 15 11:34:09 2004 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 15 Mar 2004 11:34:09 +0100 Subject: distributed node in linux In-Reply-To: <20040311234150.GA15582@hyber.org> References: <20040309184430.91869.qmail@web10104.mail.yahoo.com> <404ECA68.9050005@nortelnetworks.com> <20040311234150.GA15582@hyber.org> Message-ID: That was probably a patch that we rejected because it broke test cases on some other platforms. Unfortunately we don't always have time to explain why we reject a patch, let alone fix the problems ourselves. For the R10B release though, the TCP/IP configuration code has been rewritten to be less magical. By default, the native name lookup routines will be used, but there will be a DOCUMENTED way to override the defaults using configuration files (but the new way will not be compatible with the old undocumented way to do it). /Bjorn klacke@REDACTED writes: > On Wed, Mar 10, 2004 at 08:57:28AM +0100, Torbj?rn T?rnkvist wrote: > > > > I belive that Magnus Fr?berg did send out a patch for this > > problem many months ago. Don't know what happend with > > it though... > > > > > Yeahh, and I sent a patch for it last spring. Uhhhhhh :-( > > > /klacke > > -- > Claes Wikstrom -- Caps lock is nowhere and > http://www.hyber.org -- everything is under control > -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From hakan@REDACTED Mon Mar 15 12:01:57 2004 From: hakan@REDACTED (Hakan Mattsson) Date: Mon, 15 Mar 2004 12:01:57 +0100 (MET) Subject: Stand Alone Erlang In-Reply-To: <20040312160104.7fa83cdd.erlang@manderp.freeserve.co.uk> Message-ID: On Fri, 12 Mar 2004, Peter-Henry Mander wrote: > Do you imply that if the scanner was incorporated into the C driver, > there would be a speed gain of up to 10 times faster? This would be not > so negligable! As the speedup only concerns the scanner part, it depends largly on how much else your application is doing besides scanning. > It wasn't too trivial (for me a least!) writing the whole SIP codec in > Erlang from the ABNF specs, including tel-URI. It took me a couple of > weeks of trial and error. What would it be like to implement it in > lex/flex as a C driver? It depends on how well written the ABNF spec is. If it maps well to a lex/flex grammar it should not be so much work. The most work with the Megaco flex scanner was caused by a poor ABNF spec. /H?kan This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From baloghrobi@REDACTED Mon Mar 15 13:36:59 2004 From: baloghrobi@REDACTED (Robert Balogh) Date: Mon, 15 Mar 2004 13:36:59 +0100 Subject: gs Font parameters Message-ID: Hi, I'd like to ask you, how possible to find out the width and height parameters of the font which is used by the gs? I know I have to read the doc, I did it but it is not clear for me :-( The doc. says this for find out the type of the font: 2> gs:read(G,{choose_font,{times,38}}). {times,[],38} But I dont know the name and size of the font which is used by the gs...:-(( And it is not clear for me why is need the font for find out the used font? Can anybody answer it? thanks for the help, /Robi _________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail From enewhuis@REDACTED Mon Mar 15 15:41:06 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Mon, 15 Mar 2004 08:41:06 -0600 Subject: Mailing List Archives In-Reply-To: References: Message-ID: Is there a way to use Google to do this? This site has --> www.kx.com. On Mar 14, 2004, at 5:22 AM, Sean Hinde wrote: > Hi, > > The mailing list archives are a fantastic resource, but the search > engine is slow and cumbersome which means that it's value is > significantly reduced from what it could be. > > I wonder if it would be possible to make the raw mbox files available > for download for each month like many other lists do - mail clients do > make excellent local search engines. > > Thanks, > Sean > From gordon.guthrie@REDACTED Mon Mar 15 16:09:54 2004 From: gordon.guthrie@REDACTED (Gordon Guthrie, BTP, BT, SE) Date: Mon, 15 Mar 2004 15:09:54 -0000 Subject: Mailing List Archives Message-ID: <23659D76043CD7119EF400805FBE61F203BB0195@SENMAIL> > Is there a way to use Google to do this? This site has --> Use Google with the site parameter, ie to search for jungerl use the search term: jungerl site:erlang.org Which gives you an erlang.org specific search: http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=jungerl+site%3Aerlang .org You can't reduce the search to just a part of the domain url heirarchy, but hey! Gordon > -----Original Message----- > From: Eric Newhuis [mailto:enewhuis@REDACTED] > Sent: 15 March 2004 14:41 > To: Erlang Questions > Subject: Re: Mailing List Archives > > > > Is there a way to use Google to do this? This site has --> > www.kx.com. > > > On Mar 14, 2004, at 5:22 AM, Sean Hinde wrote: > > > Hi, > > > > The mailing list archives are a fantastic resource, but the search > > engine is slow and cumbersome which means that it's value is > > significantly reduced from what it could be. > > > > I wonder if it would be possible to make the raw mbox files > available > > for download for each month like many other lists do - mail > clients do > > make excellent local search engines. > > > > Thanks, > > Sean > > > ______________________________________________________________________ Scottish Enterprise Network http://www.scottish-enterprise.com Address & Contact Numbers 150 Broomielaw 5 Atlantic Quay Glasgow G2 8LU. Tel: +44 (0)141 248 2700. Fax: +44 (0)141 221 3217 message is sent in confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. From mike@REDACTED Mon Mar 15 18:45:56 2004 From: mike@REDACTED (Michael C Williams) Date: Mon, 15 Mar 2004 18:45:56 +0100 (CET) Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: <20040313002442.GB30095@hyber.org> Message-ID: > So, the COMMERCIAL bit here, well some lame corps release code as open source > just because they thing it's in their COMMERCIAL interest. That doesn't > apply to the vast majority of open source code though. Most of it is > released by feverish individuals with various murky agendas, such as > "destroy Microsoft" or "earn reputation as hacker" or whatnot. > The block wot wrote this letter was from some company and his boss didn't let him release the SW. He asked for advice and I suggested the MONEY line of argument. Of course there are a lot of people (not usual in large companies) who release SW for the highly compendable reasons that you quote. > Then there are a number of largish corporations, such as /// and > Nortel that only go where the money is. However, within these > corporations thare are decent individuals that "do the right thing" I though that these decent individuals gave up and left the company to take their chance at starting up a small company with venture capital with the hope of being bought up by a large company like Alteon/Nortel? > Remember, it's easier to get forgivness than to get permission. So > don't ask for permission, just release it. I did (Yaws) I guess that releasing yaws would not be approved of by your employers? > As if you know, you don't. What goes on in the heads of the suits > is as inpredictable as the stockmarket. Q.E.D. No, it is entirely predictable for 95% of the suites - their own carreer and fortune comes before everthing including their families. It is the other 5% who throw us into total confusion. (In Ericsson it is more like 10% of totally unpredictable people. Remember Jorma, Jan Uddenfeldt and Jaak?) > > This communication is confidential and intended solely for the addressee(s). > > > And this is not, I hereby, freely allow anyone who reads this to > rephrase it and resend it as they please. It isn't my fault that the IT people here add on totally wacko attachments to me e-mails. I have already told them they have a hole in the head but it didn't help. /m This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From sean.hinde@REDACTED Mon Mar 15 19:32:07 2004 From: sean.hinde@REDACTED (Sean Hinde) Date: Mon, 15 Mar 2004 18:32:07 +0000 Subject: Mailing List Archives In-Reply-To: <16468.55792.399881.657483@antilipe.corelatus.se> References: <16468.55792.399881.657483@antilipe.corelatus.se> Message-ID: <1065B76D-76AF-11D8-805C-000A95927CCE@mac.com> On 14 Mar 2004, at 22:17, Matthias Lang wrote: > Sean Hinde writes: > >> I wonder if it would be possible to make the raw mbox files available >> for download for each month like many other lists do - mail clients do >> make excellent local search engines. > > Why not just make your own mbox files from the WWW archives? > Truly Fantastical! Sean From spearce@REDACTED Tue Mar 16 05:01:06 2004 From: spearce@REDACTED (Shawn Pearce) Date: Mon, 15 Mar 2004 23:01:06 -0500 Subject: SCCS what tags in .beam files? Message-ID: <20040316040106.GC11399@spearce.org> So has anyone had good luck with putting SCCS what tags into the vsn attribute of a module, and not getting garbage back? I'm doing it and getting some extra crap thrown in by the beam file format. This is actually not typical SCCS, but is BitKeeper and its %Z%%K% tags: -vsn("%Z%K%"). expands to: -vsn("@(#)spearce@REDACTED|src/w32hook.erl|20040316035503|25088"). and what on the *.beam gives me: $ bk what *.beam w32hook.beam: spearce@REDACTED|src/w32hook.erl|20040316035503|25088jCInf Look, we have jCInf now too! :-) -- Shawn. If you want to know what god thinks of money, just look at the people he gave it to. -- Dorthy Parker From klacke@REDACTED Tue Mar 16 09:06:47 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Tue, 16 Mar 2004 09:06:47 +0100 Subject: distributed node in linux In-Reply-To: References: <20040309184430.91869.qmail@web10104.mail.yahoo.com> <404ECA68.9050005@nortelnetworks.com> <20040311234150.GA15582@hyber.org> Message-ID: <20040316080647.GA7557@hyber.org> On Mon, Mar 15, 2004 at 11:34:09AM +0100, Bjorn Gustavsson wrote: > Unfortunately we don't always have time to explain why we reject > a patch, let alone fix the problems ourselves. Which is why I have started to never rely on you applying the patches I send, but rather work around, or copy the otp code into my own repository. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From seb@REDACTED Tue Mar 16 09:12:58 2004 From: seb@REDACTED (Sebastian Strollo) Date: 16 Mar 2004 09:12:58 +0100 Subject: SCCS what tags in .beam files? In-Reply-To: <20040316040106.GC11399@spearce.org> References: <20040316040106.GC11399@spearce.org> Message-ID: Shawn Pearce writes: > So has anyone had good luck with putting SCCS what tags into the vsn > attribute of a module, and not getting garbage back? I'm doing it and > getting some extra crap thrown in by the beam file format. > > This is actually not typical SCCS, but is BitKeeper and its %Z%%K% tags: > > -vsn("%Z%K%"). > > expands to: > > -vsn("@(#)spearce@REDACTED|src/w32hook.erl|20040316035503|25088"). Seems BitKeeper doesn't have an "end" tag? (I don't know anything about it, but e.g. RCS has it's tag surrounded by $Id ... $). Maybe BK expects null terminated strings, how about: -vsn("%Z%K%\000"). :-) /Sebastian From klacke@REDACTED Tue Mar 16 09:10:16 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Tue, 16 Mar 2004 09:10:16 +0100 Subject: OSS (was Re: Stand Alone Erlang) In-Reply-To: References: <20040313002442.GB30095@hyber.org> Message-ID: <20040316081016.GB7557@hyber.org> On Mon, Mar 15, 2004 at 06:45:56PM +0100, Michael C Williams wrote: > > I guess that releasing yaws would not be approved of by your > employers? > Actually it was. > > > This communication is confidential and intended solely for the addressee(s). > > > > > > And this is not, I hereby, freely allow anyone who reads this to > > rephrase it and resend it as they please. > > It isn't my fault that the IT people here add on totally wacko > attachments to me e-mails. I have already told them they have > a hole in the head but it didn't help. > > /m > Funny though ... > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. We don't want that, do we. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From francesco@REDACTED Tue Mar 16 14:40:12 2004 From: francesco@REDACTED (Francesco Cesarini) Date: Tue, 16 Mar 2004 13:40:12 +0000 Subject: ACM SIGPLAN Erlang Workshop in Utah, USA September 22nd! Call For Papers Message-ID: <405703BC.9020109@erlang-consulting.com> We are glad to announce that our proposal for an ACM SIGPLAN sponsored Erlang workshop in conjunction with the International Conference on Functional Programming (ICFP) has been accepted. This year?s workshop will take place on September 22nd in Snowbird (Just outside Salt Lake City, Utah), in the States. If your work with Erlang/OTP has resulted in interesting research, new cool applications or good ideas, the Erlang workshop is the forum to present them. The submission deadline for full papers or extended abstracts is May 24th. Four weeks later, you will be notified if your paper has been accepted, after which you have over a month and a half to complete it, with August 9th being the submission deadline. Workshop proceedings will be printed by ACM and be included in their digital library. For more information on the workshop visit http://www.erlang.se/workshop/2004/ For submission guidelines, see http://www.erlang.se/workshop/2004/submission.html Do not hesitate to contact me or any of the other committee members should you have any questions. And don?t forget to mark the dates May 24th and September 22nd in your calendars! If you are not planning on presenting, we still hope you will be able to attend and help us repeat the successes of the previous workshops in Florence, Pittsburgh and Uppsala. Regards, Francesco Cesarini -- http://www.erlang-consulting.com From spearce@REDACTED Tue Mar 16 22:48:37 2004 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 16 Mar 2004 16:48:37 -0500 Subject: SCCS what tags in .beam files? In-Reply-To: References: <20040316040106.GC11399@spearce.org> Message-ID: <20040316214837.GB17358@spearce.org> Sebastian Strollo wrote: > Shawn Pearce writes: > > > So has anyone had good luck with putting SCCS what tags into the vsn > > attribute of a module, and not getting garbage back? I'm doing it and > > getting some extra crap thrown in by the beam file format. > > > > This is actually not typical SCCS, but is BitKeeper and its %Z%%K% tags: > > > > -vsn("%Z%K%"). > > > > expands to: > > > > -vsn("@(#)spearce@REDACTED|src/w32hook.erl|20040316035503|25088"). > > Seems BitKeeper doesn't have an "end" tag? (I don't know anything > about it, but e.g. RCS has it's tag surrounded by $Id ... $). Maybe BK > expects null terminated strings, how about: > > -vsn("%Z%K%\000"). No, they don't use an end tag, I think they just use the null byte, as typically its: static const char* VERSION="%Z%%K%"; which is enough. Erlang just had to go and break convention and stop using null bytes to terminate its "strings". :-) D*** Erlang. :-) I'll try the \000, I'm sure that's what I was looking for. -- Shawn. "And what do you two think you are doing?!" roared the husband, as he came upon his wife in bed with another man. The wife turned and smiled at her companion. "See?" she said. "I told you he was stupid!" From spearce@REDACTED Wed Mar 17 03:09:36 2004 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 16 Mar 2004 21:09:36 -0500 Subject: Cute feature of erts on Windows Message-ID: <20040317020936.GC17358@spearce.org> I found this one the hard way, but fortunately I had read the source a few weeks ago and knew about it, so I at least knew to look for it and I didn't spend that much time on it. A fool might want to create a mutex using CreateMutex, and then set it using driver_select(my_port, my_mutex, DO_READ, 1) such that when the mutex is available and the emulator has won the lock, the driver gets its read_ready function called. In theory this looks great, as the emulator can keep running while waiting for the lock to be granted, especially if the lock might be in use for long periods by other threads/processes. Once the emulator grabs the lock, it cannot be released! Because the emulator waits for the event using a background thread, ReleaseMutex will fail to release the lock, because the driver is running on a different thread than the one which won the lock through the WaitForMultipleObjects call. This goes to say two things: One should always check return values (I was not checking the return value of ReleaseMutex, assuming it world just work) and the erts documentation should point out that developers should not wait on mutexes, but instead use a semaphore, which let the event waiter thread win the semaphore, but the driver thread release it. -- Shawn. A fool and his money are soon popular. From spearce@REDACTED Wed Mar 17 05:15:44 2004 From: spearce@REDACTED (Shawn Pearce) Date: Tue, 16 Mar 2004 23:15:44 -0500 Subject: btt (Bluetail Ticket Tracker) Message-ID: <20040317041544.GA18400@spearce.org> I'm looking for a bug database to maintain my own work items in the computer rather than on a scrap of paper. I found this comment about BTT that I thought I would share: BTT looks to be a fairly complete tracking system, but uses a language and database that no one has ever heard of. It may be a worth looking at, as the people who did it seem to know what they are doing, but good luck trying to convince anyone except a weirdo CompSci person to try to maintain it. Source: http://www.onlinepolicy.org/research/taskmgrchart.shtml Apparently it helps to have developers who write in a language and database nobody has ever heard of, and that only a weirdo CompSci person would maintain it - because they think BTT might actually do something good. :-) Given I'm managing work items on erlang projects, BTT might be a good fit for me... gotta look at it some more. -- Shawn. From taavi@REDACTED Wed Mar 17 09:04:03 2004 From: taavi@REDACTED (Taavi Talvik) Date: Wed, 17 Mar 2004 10:04:03 +0200 (EET) Subject: btt (Bluetail Ticket Tracker) In-Reply-To: <20040317041544.GA18400@spearce.org> Message-ID: <20040317095707.E7975-100000@valu.uninet.ee> On Tue, 16 Mar 2004, Shawn Pearce wrote: > I'm looking for a bug database to maintain my own work items in the > computer rather than on a scrap of paper. I found this comment about > BTT that I thought I would share: > > BTT looks to be a fairly complete tracking system, but uses a > language and database that no one has ever heard of. It may be a > worth looking at, as the people who did it seem to know what > they are doing, but good luck trying to convince anyone except a > weirdo CompSci person to try to maintain it. > > Source: http://www.onlinepolicy.org/research/taskmgrchart.shtml Especially nice comment on this page is: e. Free programming language other entries: Yes (Perl) Btt: Yes, super obscure (Erlang) Just imagine how twisted is perl programmers mind:) best regards, taavi From tobbe@REDACTED Wed Mar 17 09:08:05 2004 From: tobbe@REDACTED (=?ISO-8859-1?Q?Torbj=F6rn_T=F6rnkvist?=) Date: Wed, 17 Mar 2004 09:08:05 +0100 Subject: btt (Bluetail Ticket Tracker) In-Reply-To: <20040317041544.GA18400@spearce.org> References: <20040317041544.GA18400@spearce.org> Message-ID: <40580765.9090202@nortelnetworks.com> Shawn Pearce wrote: >I'm looking for a bug database to maintain my own work items in the >computer rather than on a scrap of paper. I found this comment about >BTT that I thought I would share: > > BTT looks to be a fairly complete tracking system, but uses a > language and database that no one has ever heard of. It may be a > worth looking at, as the people who did it seem to know what > they are doing, but good luck trying to convince anyone except a > weirdo CompSci person to try to maintain it. > Ha ha....that was funny :-) > > Source: http://www.onlinepolicy.org/research/taskmgrchart.shtml > >Apparently it helps to have developers who write in a language and >database nobody has ever heard of, and that only a weirdo CompSci person >would maintain it - because they think BTT might actually do something >good. :-) > >Given I'm managing work items on erlang projects, BTT might be a good >fit for me... gotta look at it some more. > Just let me know if there are any problems. Cheers, Tobbe From thomas.arts@REDACTED Wed Mar 17 15:30:52 2004 From: thomas.arts@REDACTED (Thomas Arts) Date: Wed, 17 Mar 2004 15:30:52 +0100 Subject: Erlang leader election - code available? References: Message-ID: <002b01c40c2c$74811f10$6500a8c0@ituniv398> The leader election module gen_leader contains a bug. I just returned from a chat at Chalmers with a PhD student that is looking into verification of the gen_leader. He made clear to me that the algorithm we used was valid for systems in which nodes go down, but is not correct for a situation in which nodes restart (not even if the restart is reasonably slow compared to the recovery). He found the bug, I see it as my responsibility to find a solution for the error (a deadlock and sometimes a partitioning in which two leaders are elected). Has anyone observed that in practise? The likelyhood that it appears is probably not very large, but this is a ticking bomb, of course. I am looking into the matter. If someone already fixed it, let me know. Cheers Thomas --- Dr Thomas Arts Program Manager Software Engineering and Management IT-university in Gothenburg Box 8718, 402 75 Gothenburg, Sweden http://www.ituniv.se/ Tel +46 31 772 6031 Fax +46 31 772 4899 From vlad@REDACTED Wed Mar 17 17:13:32 2004 From: vlad@REDACTED (Vlad Balin) Date: Wed, 17 Mar 2004 19:13:32 +0300 Subject: copy elimination for tuples Message-ID: <000901c40c3a$cbb41630$aee7a8c0@mxpbalin> Hello. I'm interested in copy elimination optimization for tuples. As far as I know, this feature has not been implemented yet. Is there any specific reason or considerations? Have anyone tried to do that? Thanks in advance, Vlad Balin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richardc@REDACTED Wed Mar 17 20:06:23 2004 From: richardc@REDACTED (Richard Carlsson) Date: Wed, 17 Mar 2004 20:06:23 +0100 (MET) Subject: copy elimination for tuples In-Reply-To: <000901c40c3a$cbb41630$aee7a8c0@mxpbalin> References: <000901c40c3a$cbb41630$aee7a8c0@mxpbalin> Message-ID: On Wed, 17 Mar 2004, Vlad Balin wrote: > I'm interested in copy elimination optimization for tuples. As far as I > know, this feature has not been implemented yet. Is there any specific > reason or considerations? Have anyone tried to do that? The main obstacle is that the garbage collector currently requires that there are no pointers from an older generation to a younger one. This means that you can only "zap" fields in a tuple if you have full control of where the tuple is located. For instance, a tuple that was created only a few steps earlier (even in the same function) may have already been moved to an older generation if a GC was triggered between the two program points. So it is not enough to know that the tuple will not be needed in its old form when you do a "setelement". Currently, some destructive updating of tuple fields is introduced when it is certain that there will be no GC; this typically happens in the code generated to create tuples when the "record syntax" is expanded. Note that this is a compiler optimization only - the destructive setelement operations cannot be accessed from normal Erlang code. /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From erlang@REDACTED Thu Mar 18 15:54:56 2004 From: erlang@REDACTED (Erlang Questions) Date: Thu, 18 Mar 2004 11:54:56 -0300 Subject: Mnesia: Load sharing and redundancy Message-ID: <043601c40cf8$fb30ab30$2100a8c0@mnesia> In order to have load sharing and redundancy in Mnesia and following the tips that I recolected, I decided to implement a solution with three nodes (one per machine) and fragment the tables in X (X multiple of three) fragments distributed between the three nodes as follows: Node A - fragments 'ai' and 'bi' Node B - fragments 'bi' and 'ci' Node C - fragments 'ci' and 'ai' With i between 1 and X (this to avoid huge fragments) I am just to put this mess in service. Does anyone have expirience with an arquitecture like this running stable in field? My laboratory tests were all right, but it is not the same at client side. Any recomendations before doing that? A solution with fragments like the one above, assures me load sharing between Mnesia nodes? Thanks a lot, Carlos.- Carlos> Hi, I want to implement load sharing without loosing redundancy. Carlos> Carlos> Can anyone give me an example on how to fragment and replicate a Carlos> Mnesia database to have this implemented? I mean referencing, how Carlos> many nodes, machines and fragments. And the distribution of them. Carlos> Carlos> For example I figure that this could be a good solution, isn't it? Carlos> Carlos> Two nodes in one machine and two other nodes in another machine. Nodes Carlos> A and B in machine M1, nodes C and D in machine M2. Carlos> Carlos> All DB tables fragmented in two fragments one fragment resident at Carlos> node A, and one fragment at node C (then we use M1 and M2 machines to Carlos> have load sharing). Carlos> Carlos> This implementation replicated as follows: fragments at node A Carlos> replicated at node D, and fragments at node C replicated at node B Carlos> (then we have cross replicas - M1 fragments with M2 ones). See Carlos> attachment for representation. Carlos> Carlos> I would apreciate your answer very much, to have my DB implemented as Carlos> soon as possible. Carlos> Carlos> Thanks, Carlos E. Silva.- In order to keep things simple, I would suggest that you: - Only have one node per machine. Why have you choosen to have two nodes per machine? - Avoid addition of new fragments to existing tables while system is in full operation. Addition of new fragments is quite expensive as it will imply existing records to be rehashed and moved between fragments. A plain move of a fragment is cheaper. - Avoid huge fragments. If you expect large data volumes you should distribute it over more fragments than you would do for small data volumes. This would give you a better precision in your load balancing and lesser disturbance when you move fragments between nodes. - Try to estimate the maximum number of nodes (machines) that you that you ever will use in your system. The number of initial fragments should always be more than the maximum number of nodes, perhaps a factor 5 or 10 more. - Take a look at the mnesia/examples/bench example. /H?kan PS. If your maximum configuration only is two nodes there are no point in using fragmented tables at all, for the purpose of load balancing. --- H?kan Mattsson Ericsson High Availability Software, DBMS Internals http://www.erlang.org/~hakan/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakan@REDACTED Thu Mar 18 16:50:23 2004 From: hakan@REDACTED (Hakan Mattsson) Date: Thu, 18 Mar 2004 16:50:23 +0100 (MET) Subject: Mnesia: Load sharing and redundancy In-Reply-To: <043601c40cf8$fb30ab30$2100a8c0@mnesia> Message-ID: On Thu, 18 Mar 2004, Carlos wrote: Carlos> I am just to put this mess in service. ... Carlos> Any recomendations before doing that? If you regard your code to be in a mess - you should not release the product. Carlos> A solution with fragments like the one above, Carlos> assures me load sharing between Mnesia nodes? No. Just making your tables fragmented, does not automatically imply good load sharing characteristics. It depends totally on how your application is written. /H?kan This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From vlad@REDACTED Thu Mar 18 17:24:08 2004 From: vlad@REDACTED (Vlad Balin) Date: Thu, 18 Mar 2004 19:24:08 +0300 Subject: copy elimination for tuples In-Reply-To: Message-ID: <000301c40d05$7207fc20$aee7a8c0@mxpbalin> Thanks for reply. Are there any documents available describing GC techniques used in HiPE and BEAM? Vlad. > -----Original Message----- > From: Richard Carlsson [mailto:richardc@REDACTED] > Sent: 17 ????? 2004 ?. 22:06 > To: Vlad Balin > Cc: erlang-questions@REDACTED > Subject: Re: copy elimination for tuples > > > > On Wed, 17 Mar 2004, Vlad Balin wrote: > > > I'm interested in copy elimination optimization for tuples. > As far as > > I know, this feature has not been implemented yet. Is there any > > specific reason or considerations? Have anyone tried to do that? > > The main obstacle is that the garbage collector currently > requires that there are no pointers from an older generation > to a younger one. This means that you can only "zap" fields > in a tuple if you have full control of where the tuple is > located. For instance, a tuple that was created only a few > steps earlier (even in the same function) may have already > been moved to an older generation if a GC was triggered > between the two program points. So it is not enough to know > that the tuple will not be needed in its old form when you do > a "setelement". > > Currently, some destructive updating of tuple fields is > introduced when it is certain that there will be no GC; this > typically happens in the code generated to create tuples when > the "record syntax" is expanded. Note that this is a compiler > optimization only - the destructive setelement operations > cannot be accessed from normal Erlang code. > > /Richard > > > Richard Carlsson (richardc@REDACTED) (This space > intentionally left blank.) > E-mail: Richard.Carlsson@REDACTED WWW: > http://user.it.uu.se/~richardc/ > "Having users is like > optimization: the wise course is to delay it." > -- Paul Graham > From guillaume.bongenaar@REDACTED Thu Mar 18 17:31:46 2004 From: guillaume.bongenaar@REDACTED (guillaume.bongenaar@REDACTED) Date: Thu, 18 Mar 2004 17:31:46 +0100 Subject: Site changes Message-ID: An HTML attachment was scrubbed... URL: From richardc@REDACTED Thu Mar 18 18:06:31 2004 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 18 Mar 2004 18:06:31 +0100 (MET) Subject: copy elimination for tuples In-Reply-To: <000301c40d05$7207fc20$aee7a8c0@mxpbalin> References: <000301c40d05$7207fc20$aee7a8c0@mxpbalin> Message-ID: On Thu, 18 Mar 2004, Vlad Balin wrote: > Thanks for reply. Are there any documents available describing GC > techniques used in HiPE and BEAM? Not much, but the master's thesis by our Jesper Wilhelmsson (who implemented the shared heap version, 'erl -shared') might be a good introduction: http://www.it.uu.se/research/group/hipe/publications.shtml#theses /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From erlang@REDACTED Fri Mar 19 18:26:42 2004 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Fri, 19 Mar 2004 14:26:42 -0300 Subject: Windows XP and erl5.3 error Message-ID: <00ae01c40dd7$61020ab0$1e00a8c0@design> I have copied erl5.3/bin to erli/bin and erl.5.3/erts-5.3/bin to erli/erts-5.3/bin on a machine without Erlang 5.3 SDK installed. I'm using XP OS and when running erl.exe from erlTest/erts-5.3/bin it returns the following error: C:\erli\bin>erl {error_logger,{{2004,3,19},{14,12,6}},supervisor_report,[{supervisor,{local,kern el_sup}},{errorContext,start_error},{reason,{'EXIT',{undef,[{erl_open_port,open_ port,[{spawn,'registry__drv__ r'},[]]},{win32reg,open,1},{inet_config,win32_load _from_registry,1},{inet_config,init,0},{inet_db,start_link,0},{supervisor,do_sta rt_child,2},{supervisor,start_children,3},{supervisor,init_children,2}|more]}}}, {offender,[{pid,undefined},{name,inet_db},{mfa,{inet_db,start_link,[]}},{restart _type,permanent},{shutdown,2000},{child_type,worker}]}]} {error_logger,{{2004,3,19},{14,12,6}},crash_report,[[{pid,<0.7.0>},{registered_n ame,[]},{error_info,{shutdown,{kernel,start,[normal,[]]}}},{initial_call,{applic ation_master,init,[<0.5.0>,<0.6.0>,{appl_data,kernel,[application_controller,erl _reply,auth,boot_server,code_server,disk_log_server,disk_log_sup,erl_prim_loader ,error_logger,file_server,file_server_2,fixtable_server,global_group,global_name _server,heart,init,kernel_config,kernel_sup,net_kernel,net_sup,rex,user,os_serve r,ddll_server,erl_epmd,inet_db,pg2],undefined,{kernel,[]},[application,applicati on_controller,application_master,application_starter,auth,code,code_aux,packages ,code_server,dist_util,erl_boot_server,erl_distribution,erl_prim_loader,erl_repl y,erlang,error_handler,error_logger,file,file_server,old_file_server,file_io_ser ver,prim_file,global,global_group,global_search,group,heart,inet6_tcp,inet6_tcp_ dist,inet6_udp,inet_config,inet_hosts,inet_gethost_native,inet_tcp_dist,init,ker nel,kernel_config,net,net_adm,net_kernel,os,ram_file,rpc,user,user_drv,user_sup, disk_log,disk_log_1,disk_log_server,disk_log_sup,dist_ac,erl_ddll,erl_epmd,erts_ debug,gen_tcp,gen_udp,prim_inet,inet,inet_db,inet_dns,inet_parse,inet_res,inet_t cp,inet_udp,pg2,seq_trace,socks5,socks5_auth,socks5_tcp,socks5_udp,wrap_log_read er,zlib,otp_ring0],[],infinity,infinity},normal]}},{ancestors,[<0.6.0>]},{messag es,[{'EXIT',<0.8.0>,normal}]},{links,[<0.6.0>,<0.5.0>]},{dictionary,[]},{trap_ex it,true},{status,running},{heap_size,610},{stack_size,21},{reductions,1080}],[]] } Does anyone know what the above mean? thanks in advance, Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad_dumitrescu@REDACTED Fri Mar 19 19:58:40 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 19 Mar 2004 19:58:40 +0100 Subject: Windows XP and erl5.3 error References: <00ae01c40dd7$61020ab0$1e00a8c0@design> Message-ID: > I have copied erl5.3/bin to erli/bin and erl.5.3/erts-5.3/bin to erli/erts-5.3/bin on a machine without > Erlang 5.3 SDK installed. I'm using XP OS and when running erl.exe from erlTest/erts-5.3/bin > it returns the following error: I don't think it's possible to just move the bin directories. You have to move the lib directory too, with all the beam files. Why would you want to just copy the exes without properly installing Erlang? BTW, this brings upa n interesting question: win32reg uses a driver to talk to the win32 registry. That driver is called something like "registry__drv__r", but no such file exists - do I sense a hack here? regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Mar 19 21:24:07 2004 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Fri, 19 Mar 2004 17:24:07 -0300 Subject: Windows XP and erl5.3 error References: <00ae01c40dd7$61020ab0$1e00a8c0@design> Message-ID: <00ba01c40df0$ebe10000$1e00a8c0@design> I have also copy de libs (.beams). > Why would you want to just copy the exes without properly installing Erlang? I wouldn't like to install an SDK in a client machine, just Erlang runtime .exes and libs. best regards, Eduaro Figoli INSwitch Solutions ----- Original Message ----- From: Vlad Dumitrescu To: erlang-questions@REDACTED Sent: Friday, March 19, 2004 3:58 PM Subject: Re: Windows XP and erl5.3 error > I have copied erl5.3/bin to erli/bin and erl.5.3/erts-5.3/bin to erli/erts-5.3/bin on a machine without > Erlang 5.3 SDK installed. I'm using XP OS and when running erl.exe from erlTest/erts-5.3/bin > it returns the following error: I don't think it's possible to just move the bin directories. You have to move the lib directory too, with all the beam files. Why would you want to just copy the exes without properly installing Erlang? BTW, this brings upa n interesting question: win32reg uses a driver to talk to the win32 registry. That driver is called something like "registry__drv__r", but no such file exists - do I sense a hack here? regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From rvg@REDACTED Sat Mar 20 07:52:50 2004 From: rvg@REDACTED (Rudolph van Graan) Date: Sat, 20 Mar 2004 08:52:50 +0200 Subject: Windows XP and erl5.3 error In-Reply-To: <00ba01c40df0$ebe10000$1e00a8c0@design> References: <00ae01c40dd7$61020ab0$1e00a8c0@design> <00ba01c40df0$ebe10000$1e00a8c0@design> Message-ID: <349605A6-7A3B-11D8-A49E-000A956D87EE@patternmatched.com> I have previously done exactly this: 1. Made a new root directory [ROOTDIR] 2. copied the erts-5.3 directory and sub-directories into this (Only bin is needed I think) 3. In ROOTDIR\erts\5.3\bin edited the erl.ini file Bindir=c:\\ROOTDIR\\erts-5.3\\bin 4. In ROOTDIR\erts\5.3\bin edited the erl.ini file Rootdir=c:\\ROOTDIR [Replace the %ROOTDIR%] 5. Copied all the LIB directories to ROOTDIR\lib 6. Made a Bootscript for the system --> mine is ROOTDIR\releases\1.0\start.boot 7. in ROOTDIR I made the following batch file to start everything up: erts-5.3\bin\erl -boot releases/1.0/start 8. If you want to use the standard erlang boot script you need to point the above command to it and make sure that you have access to all the libs. I had some issues with the R9B wanting to access to registry all the time, but in R9C the .ini file was added that solved these issues I think. Hope this helps. Regards Rudolph van Graan On Mar 19, 2004, at 10:24 PM, Inswitch Solutions - Erlang Evaluation wrote: > I have also copy de libs (.beams). > ? > > Why would you want to just copy the exes without properly installing > Erlang? > I wouldn't like to install an SDK in a client machine, just?Erlang > runtime .exes and libs. > ? > ? > best regards, > Eduaro Figoli > INSwitch Solutions > ? > ? > ----- Original Message ----- > From: Vlad Dumitrescu > To: erlang-questions@REDACTED > Sent: Friday, March 19, 2004 3:58 PM > Subject: Re: Windows XP and erl5.3 error > > > I have copied erl5.3/bin to erli/bin and erl.5.3/erts-5.3/bin to > erli/erts-5.3/bin on a machine without > > Erlang 5.3 SDK installed. I'm using XP OS and when running erl.exe > from erlTest/erts-5.3/bin > > it returns the following error: > ? > I don't think it's possible to just move the bin directories. You have > to move the lib directory too, with all the beam files. > ? > Why would you want to just copy the exes without properly installing > Erlang? > ? > BTW, this brings upa n interesting question: win32reg uses a driver to > talk to the win32 registry. That driver is called something like > "registry__drv__r", but no such file exists - do I sense a hack here? > ? > regards, > Vlad > ? > ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4241 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2112 bytes Desc: not available URL: From gerd@REDACTED Sat Mar 20 17:51:35 2004 From: gerd@REDACTED (Gerd Flaig) Date: Sat, 20 Mar 2004 17:51:35 +0100 Subject: Fun with open_port Message-ID: Hi, the following module -module(dreck). -export([r/0]). r() -> Port = open_port({spawn, "/bin/true"}, [{line, 200}, exit_status]), receive X -> X after 5000 -> timeout end. exposes interesting behaviour: % erl Erlang (BEAM) emulator version 5.3 [source] [hipe] [threads:0] Eshell V5.3 (abort with ^G) 1> dreck:r(). {#Port<0.30>,{exit_status,0}} 2> dreck:r(). {#Port<0.32>,{exit_status,0}} 3> dreck:r(). {#Port<0.33>,{exit_status,0}} 4> c(dreck). {ok,dreck} 5> dreck:r(). timeout 6> dreck:r(). {#Port<0.65>,{exit_status,0}} 7> dreck:r(). {#Port<0.66>,{exit_status,0}} 8> dreck:r(). {#Port<0.67>,{exit_status,0}} Any ideas what might be causing this and how I can fix it? I've been staring at the emulator source but have not yet understood how the inner workings of open_port fit together. I've tested this on R9C (Debian package version 1:9.2-5 and another test on the same package version, but compiled locally. Same effect). Goodbyte, Gerd. -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From gerd@REDACTED Sat Mar 20 17:54:31 2004 From: gerd@REDACTED (Gerd Flaig) Date: Sat, 20 Mar 2004 17:54:31 +0100 Subject: Fun with open_port In-Reply-To: (Gerd Flaig's message of "Sat, 20 Mar 2004 17:51:35 +0100") References: Message-ID: Gerd Flaig writes: > % erl > Erlang (BEAM) emulator version 5.3 [source] [hipe] [threads:0] > > Eshell V5.3 (abort with ^G) > 1> dreck:r(). > {#Port<0.30>,{exit_status,0}} > 2> dreck:r(). > {#Port<0.32>,{exit_status,0}} > 3> dreck:r(). > {#Port<0.33>,{exit_status,0}} > 4> c(dreck). > {ok,dreck} > 5> dreck:r(). > timeout > 6> dreck:r(). > {#Port<0.65>,{exit_status,0}} > 7> dreck:r(). > {#Port<0.66>,{exit_status,0}} > 8> dreck:r(). > {#Port<0.67>,{exit_status,0}} maybe I should also point out that the exit status doesn't get delivered only after the first compile command in a node. Another thing is: After the timeout, I have a /bin/true zombie in the process table which disappears after the next test run. Goodbyte, Gerd. -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From matthias@REDACTED Sun Mar 21 01:43:41 2004 From: matthias@REDACTED (Matthias Lang) Date: Sun, 21 Mar 2004 01:43:41 +0100 Subject: Fun with open_port In-Reply-To: References: Message-ID: <16476.58685.535562.913713@antilipe.corelatus.se> Hi, Definitely looks like a bug. I have no solution, but I can confirm that I see exactly the same behaviour under R9C from debian. I don't get it for R8B I compiled myself. Matthias Gerd Flaig writes: > Hi, > > the following module > > -module(dreck). > -export([r/0]). > > r() -> > Port = open_port({spawn, "/bin/true"}, [{line, 200}, exit_status]), > receive > X -> > X > after 5000 -> > timeout > end. > > exposes interesting behaviour: [...] From spearce@REDACTED Sun Mar 21 02:50:57 2004 From: spearce@REDACTED (Shawn Pearce) Date: Sat, 20 Mar 2004 20:50:57 -0500 Subject: Fun with open_port In-Reply-To: References: Message-ID: <20040321015057.GA22919@spearce.org> My observations are below. I ran this on a Gentoo Linux box running: Linux version 2.4.20-xfs-r4 (root@REDACTED) \ (gcc version 3.2.3 20030422 \ (Gentoo Linux 1.4 3.2.3-r3, propolice)) \ #2 SMP Sat Dec 6 16:35:29 EST 2003 My erlang installation is the R9C-r2 ebuild. Short is, I'm not seeing what you are, and I shouldn't either, nobody should. Compiling and loading a module should have no bearing on the exit_status message being delivered by a port program, and the port program should not be creating zombies... perhaps something is wrong with your operating system? Erlang (BEAM) emulator version 5.3 [source] [hipe] [threads:0] dreck). ./dreck.erl:5: syntax error before: ')' ./dreck.erl:2: function r/0 undefined error 2> c(dreck). {ok,dreck} 3> dreck:r(). {#Port<0.62>,{exit_status,0}} 4> dreck:r(). {#Port<0.63>,{exit_status,0}} 5> dreck:r(). {#Port<0.64>,{exit_status,0}} 6> dreck:r(). {#Port<0.65>,{exit_status,0}} 7> dreck:r(). {#Port<0.66>,{exit_status,0}} 8> dreck:r(). {#Port<0.67>,{exit_status,0}} 9> dreck:r(). {#Port<0.68>,{exit_status,0}} 10> dreck:r(). {#Port<0.69>,{exit_status,0}} 11> dreck:r(). {#Port<0.70>,{exit_status,0}} 12> dreck:r(). {#Port<0.71>,{exit_status,0}} 13> c(dreck). {ok,dreck} 14> dreck:r(). {#Port<0.74>,{exit_status,0}} Gerd Flaig wrote: > Gerd Flaig writes: > > > % erl > > Erlang (BEAM) emulator version 5.3 [source] [hipe] [threads:0] > > > > Eshell V5.3 (abort with ^G) > > 1> dreck:r(). > > {#Port<0.30>,{exit_status,0}} > > 2> dreck:r(). > > {#Port<0.32>,{exit_status,0}} > > 3> dreck:r(). > > {#Port<0.33>,{exit_status,0}} > > 4> c(dreck). > > {ok,dreck} > > 5> dreck:r(). > > timeout > > 6> dreck:r(). > > {#Port<0.65>,{exit_status,0}} > > 7> dreck:r(). > > {#Port<0.66>,{exit_status,0}} > > 8> dreck:r(). > > {#Port<0.67>,{exit_status,0}} > > maybe I should also point out that the exit status doesn't get > delivered only after the first compile command in a node. > > Another thing is: After the timeout, I have a /bin/true zombie in the > process table which disappears after the next test run. > > Goodbyte, Gerd. > -- > Gerd Flaig Technik gerd@REDACTED > Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe > Physics is like sex: sure, it may give some practical results, > but that's not why we do it. -- Richard Feynman -- Shawn. Afternoon, n.: That part of the day we spend worrying about how we wasted the morning. From gerd@REDACTED Sun Mar 21 16:38:59 2004 From: gerd@REDACTED (Gerd Flaig) Date: Sun, 21 Mar 2004 16:38:59 +0100 Subject: Fun with open_port In-Reply-To: <20040321015057.GA22919@spearce.org> (Shawn Pearce's message of "Sat, 20 Mar 2004 20:50:57 -0500") References: <20040321015057.GA22919@spearce.org> Message-ID: Shawn Pearce writes: > Short is, I'm not seeing what you are, and I shouldn't either, nobody > should. Compiling and loading a module should have no bearing on > the exit_status message being delivered by a port program, and the > port program should not be creating zombies... perhaps something is > wrong with your operating system? I did some stracing. According to strace, SIGCHLD is delivered to the emulator also in the failure case. But there is a difference: I see no waitpid() then. Maybe I managed to trigger an obscure bug that only shows up with certain combinations of glibc and gcc. When stracing, q() just hangs there after 'Process 30049 suspended'. % ldd /usr/lib/erlang/erts-5.3/bin/erlexec libc.so.6 => /lib/libc.so.6 (0x4001c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) % strace -f -o /tmp/erlbug.trace erl Process 30046 attached Process 30047 attached Process 30048 attached Process 30047 detached Process 30046 suspended Process 30046 resumed Process 30048 detached Process 30046 detached Process 30049 attached Process 30050 attached Erlang (BEAM) emulator version 5.3 [source] [hipe] [threads:0] Eshell V5.3 (abort with ^G) 1> dreck:r(). Process 30051 attached Process 30051 detached {#Port<0.30>,{exit_status,0}} 2> c(dreck). {ok,dreck} 3> dreck:r(). Process 30052 attached Process 30052 detached timeout 4> q(). ok 5> Process 30050 detached Process 30049 suspended 30051 _exit(0) = ? 30045 <... poll resumed> [{fd=3, events=POLLIN}, {fd=0, events=POLLIN}, {fd=7, events=POLLIN, revents=POLLHUP}], 3, 4987) = 1 30045 --- SIGCHLD (Child exited) --- 30045 sigreturn() = ? (mask now [RTMIN]) 30045 times({tms_utime=56, tms_stime=7, tms_cutime=3, tms_cstime=0}) = 346574446 30045 gettimeofday({1079882310, 628455}, NULL) = 0 30045 read(7, "", 65536) = 0 30045 rt_sigprocmask(SIG_BLOCK, [CHLD], NULL, 8) = 0 30045 waitpid(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WNOHANG) = 30051 30045 waitpid(-1, 0xbffff990, WNOHANG) = -1 ECHILD (No child processes) 30045 rt_sigprocmask(SIG_UNBLOCK, [CHLD], NULL, 8) = 0 As you can see, there are two calls to waitpid, the first of which gives us the exit status of /bin/true (pid 30051). 30045 <... poll resumed> [{fd=3, events=POLLIN}, {fd=0, events=POLLIN}, {fd=7, events=POLLIN, revents=POLLHUP}], 3, 4991) = 1 30045 --- SIGCHLD (Child exited) --- 30045 sigreturn() = ? (mask now [RTMIN]) 30045 times({tms_utime=101, tms_stime=10, tms_cutime=4, tms_cstime=1}) = 346575193 30045 gettimeofday({1079882318, 92096}, NULL) = 0 30045 read(7, "", 65536) = 0 30045 times({tms_utime=101, tms_stime=10, tms_cutime=4, tms_cstime=1}) = 346575193 30045 gettimeofday({1079882318, 92740}, NULL) = 0 30045 poll([{fd=3, events=POLLIN}, {fd=0, events=POLLIN}, {fd=7, events=POLLIN|POLLOUT, revents=POLLOUT|POLLHUP}], 3, 4820) = 1 The second time, there is no call to waitpid. I've put the whole strace (97159 bytes bzipped) up on http://nxdomain.org/erlbug.trace.bz2 ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries and Timezone data ii erlang 9.2-5 A real-time, concurrent and distributed functional language (self-compiled) Goodbyte, Gerd. -- Gerd Flaig Technik gerd@REDACTED Bei Schlund + Partner AG Brauerstra?e 48 D-76135 Karlsruhe Physics is like sex: sure, it may give some practical results, but that's not why we do it. -- Richard Feynman From d.love@REDACTED Mon Mar 22 12:57:31 2004 From: d.love@REDACTED (Dave Love) Date: Mon, 22 Mar 2004 11:57:31 +0000 Subject: running a replicated Orber service Message-ID: I want to get a replicated CORBA name service going on two or three Unix boxes to replace a Java single point of (continual) failure, and I need to get it going (with Orber) quickly and simply. I'm new to using OTP and I haven't found any examples of that sort of thing (starting nodes in arbitrary order from init scripts and having them sort themselves out to provide the replication). I'm sure I can program it, but it seems likely to be done commonly, and I'd be grateful for pointers to code or detailed recipes. I'm happy to contribute an example/howto if one doesn't already exist. From nick@REDACTED Mon Mar 22 13:19:01 2004 From: nick@REDACTED (Niclas Eklund) Date: Mon, 22 Mar 2004 13:19:01 +0100 (MET) Subject: running a replicated Orber service In-Reply-To: Message-ID: Hello! It's described in Orber's User's Guide (chapter 5.1.4 & 5.1.5). See: http://www.erlang.org/doc/r9c/lib/orber-3.4.2/doc/html/ch_install.html#5 You should also check out orber:add_node/2 and orber:remove_node/1. When starting Orber, the NameService is activated automatically. /Nick On Mon, 22 Mar 2004, Dave Love wrote: > I want to get a replicated CORBA name service going on two or three > Unix boxes to replace a Java single point of (continual) failure, and > I need to get it going (with Orber) quickly and simply. > > I'm new to using OTP and I haven't found any examples of that sort of > thing (starting nodes in arbitrary order from init scripts and having > them sort themselves out to provide the replication). I'm sure I can > program it, but it seems likely to be done commonly, and I'd be > grateful for pointers to code or detailed recipes. I'm happy to > contribute an example/howto if one doesn't already exist. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From garry@REDACTED Mon Mar 22 14:08:21 2004 From: garry@REDACTED (Garry Hodgson) Date: Mon, 22 Mar 2004 08:08:21 -0500 Subject: btt (Bluetail Ticket Tracker) In-Reply-To: <20040317041544.GA18400@spearce.org> References: <20040317041544.GA18400@spearce.org> Message-ID: <2004032208081079960901@k2.sage.att.com> Shawn Pearce wrote: > BTT looks to be a fairly complete tracking system, but uses a > language and database that no one has ever heard of. It may be a > worth looking at, as the people who did it seem to know what > they are doing, but good luck trying to convince anyone except a > weirdo CompSci person to try to maintain it. > > Source: http://www.onlinepolicy.org/research/taskmgrchart.shtml "weirdo CompSci person". wouldn't that look nice on my business cards? ---- Garry Hodgson, Technology Consultant, AT&T Labs Be happy for this moment. This moment is your life. From d.love@REDACTED Mon Mar 22 15:04:52 2004 From: d.love@REDACTED (Dave Love) Date: Mon, 22 Mar 2004 14:04:52 +0000 Subject: running a replicated Orber service In-Reply-To: (Niclas Eklund's message of "Mon, 22 Mar 2004 13:19:01 +0100 (MET)") References: Message-ID: Niclas Eklund writes: > Hello! > > It's described in Orber's User's Guide (chapter 5.1.4 & 5.1.5). See: > > http://www.erlang.org/doc/r9c/lib/orber-3.4.2/doc/html/ch_install.html#5 > > You should also check out orber:add_node/2 and orber:remove_node/1. > > When starting Orber, the NameService is activated automatically. Thanks, but I obviously wasn't explicit enough. I've read that and done it by hand -- which is why I think I can program what I need. However, it's some way from a Unix daemon that starts up, queries other systems that might be running and asks one to add_node it or otherwise starts orber itself, accounting for races with an identical box rebooted at the same time. I expected this to be a fairly common idiom, but maybe it's rare to use Erlang-based services like this. [Being able to provide a properly-replicated server at all seems to be a fairly compelling use of OTP; I've had no hint here that there's a Java-based equivalent, and everything has to be written in Java.] From fredrik.linder@REDACTED Mon Mar 22 15:20:48 2004 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Mon, 22 Mar 2004 15:20:48 +0100 Subject: rdbms Message-ID: Hi Ulf Wiger Do you, or anyone else for that matter, plan to upgrade rdbms to work with mnesia 4.1.4 ? Regards /Fredrik From ulf.wiger@REDACTED Mon Mar 22 15:44:59 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 22 Mar 2004 15:44:59 +0100 Subject: rdbms In-Reply-To: References: Message-ID: On Mon, 22 Mar 2004 15:20:48 +0100, Fredrik Linder wrote: > Hi Ulf Wiger > > Do you, or anyone else for that matter, plan to upgrade rdbms to work > with mnesia 4.1.4 ? I will confess that I haven't tested rdbms on mnesia-4.1.4... ...or, rather, I _have_ used rdbms with mnesia-4.1.4 but didn't encounter any problems. But then again I'm running rdbms-1.5, and the latest version publicly available seems to be 1.3. I will try to find some time to update jungerl. Those of you who actually use RDBMS are welcome to drop me a line describing what you use it for. I've had no user reports on rdbms since its release in January '99 (and few, if any, bug reports, which has led me to believe that there _are_ no users of it.) /Uffe -- Ulf Wiger, Senior System Architect EAB/UPD/S This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From erlang@REDACTED Mon Mar 22 16:36:38 2004 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Mon, 22 Mar 2004 12:36:38 -0300 Subject: Mnesia and CORBA Message-ID: <00f301c41023$79c4fff0$1e00a8c0@design> Has someone used mesia-session idl interface or orber with a C/C++ Windows client? How can I use Visual C++ IDE or is it hard-working? thanks to all, Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Mon Mar 22 16:33:05 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 22 Mar 2004 16:33:05 +0100 Subject: rdbms In-Reply-To: References: Message-ID: On Mon, 22 Mar 2004 15:44:59 +0100, Ulf Wiger wrote: > On Mon, 22 Mar 2004 15:20:48 +0100, Fredrik Linder > wrote: > >> Hi Ulf Wiger >> >> Do you, or anyone else for that matter, plan to upgrade rdbms to work >> with mnesia 4.1.4 ? > > I will confess that I haven't tested rdbms on mnesia-4.1.4... > > ...or, rather, I _have_ used rdbms with mnesia-4.1.4 but didn't > encounter any problems. But then again I'm running rdbms-1.5, and > the latest version publicly available seems to be 1.3. > > I will try to find some time to update jungerl. Jungerl now updated with rdbms-1.5. I also added an updated manual in PDF format. Extract from the README file: "Changes since 1.3 (1.4 was an experiment never released.) - A bug that could lead to endless loops during cascading delete has been fixed. - New options: 'add_references', 'drop_references' make it easier to plug in new dependencies when new tables are created. - Exported functions, create_table/2 and delete_table/1 allow for more integrated handling of rdbms options. delete_table/1 will clean up dangling referential integrity options automatically." Please let me know if there are any problems. /Uffe -- Ulf Wiger, Senior System Architect EAB/UPD/S This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From fredrik.linder@REDACTED Mon Mar 22 17:37:04 2004 From: fredrik.linder@REDACTED (Fredrik Linder) Date: Mon, 22 Mar 2004 17:37:04 +0100 Subject: rdbms Message-ID: Thank you. That was quick :-) /Fredrik > -----Original Message----- > From: owner-erlang-questions@REDACTED > [mailto:owner-erlang-questions@REDACTED]On Behalf Of Ulf Wiger > Sent: den 22 mars 2004 16:33 > To: erlang-questions@REDACTED > Subject: Re: rdbms > > > On Mon, 22 Mar 2004 15:44:59 +0100, Ulf Wiger > > wrote: > > > On Mon, 22 Mar 2004 15:20:48 +0100, Fredrik Linder > > wrote: > > > >> Hi Ulf Wiger > >> > >> Do you, or anyone else for that matter, plan to upgrade > rdbms to work > >> with mnesia 4.1.4 ? > > > > I will confess that I haven't tested rdbms on mnesia-4.1.4... > > > > ...or, rather, I _have_ used rdbms with mnesia-4.1.4 but didn't > > encounter any problems. But then again I'm running rdbms-1.5, and > > the latest version publicly available seems to be 1.3. > > > > I will try to find some time to update jungerl. > > > Jungerl now updated with rdbms-1.5. I also added an updated manual > in PDF format. > > Extract from the README file: > > "Changes since 1.3 (1.4 was an experiment never released.) > > - A bug that could lead to endless loops during cascading delete has > been fixed. > > - New options: 'add_references', 'drop_references' make it easier to > plug in new dependencies when new tables are created. > > - Exported functions, create_table/2 and delete_table/1 allow for more > integrated handling of rdbms options. delete_table/1 will clean up > dangling referential integrity options automatically." > > > Please let me know if there are any problems. > > /Uffe > -- > Ulf Wiger, Senior System Architect > EAB/UPD/S > > This communication is confidential and intended solely for > the addressee(s). Any unauthorized review, use, disclosure or > distribution is prohibited. If you believe this message has > been sent to you in error, please notify the sender by > replying to this transmission and delete the message without > disclosing it. Thank you. > > E-mail including attachments is susceptible to data > corruption, interruption, unauthorized amendment, tampering > and viruses, and we only send and receive e-mails on the > basis that we are not liable for any such corruption, > interception, amendment, tampering or viruses or any > consequences thereof. > > From erlang@REDACTED Mon Mar 22 21:25:53 2004 From: erlang@REDACTED (Inswitch Solutions - Erlang Evaluation) Date: Mon, 22 Mar 2004 17:25:53 -0300 Subject: Current user in INET Message-ID: <011f01c4104b$e1df5cc0$1e00a8c0@design> Does anyone know how to get the current authenticated user in INET web server or the http headers? thanks, Eduardo Figoli INSwitch Solutions -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.vanwoerkom@REDACTED Tue Mar 23 00:39:06 2004 From: marc.vanwoerkom@REDACTED (Marc van Woerkom) Date: Tue, 23 Mar 2004 00:39:06 +0100 Subject: ICFP 2004 contest In-Reply-To: References: Message-ID: Hm.. the contest web site, albeit in early stage, seems up: http://www.cis.upenn.edu/proj/plclub/contest/ Anyone knows the date for this year's contest? My time schedule is already under heavy pressure. It would really help if I could know some weeks in advance, when the contest weekend is. Regards, Marc From nick@REDACTED Tue Mar 23 14:49:02 2004 From: nick@REDACTED (Niclas Eklund) Date: Tue, 23 Mar 2004 14:49:02 +0100 (MET) Subject: running a replicated Orber service In-Reply-To: Message-ID: No, I'm affraid that is not possible at the moment. It would be hard to come up with a generic solution which can handle partitioned networks (i.e., Orber uses Mnesia to distribute data) etc. /Nick > Niclas Eklund writes: > > > Hello! > > > > It's described in Orber's User's Guide (chapter 5.1.4 & 5.1.5). See: > > > > http://www.erlang.org/doc/r9c/lib/orber-3.4.2/doc/html/ch_install.html#5 > > > > You should also check out orber:add_node/2 and orber:remove_node/1. > > > > When starting Orber, the NameService is activated automatically. > > Thanks, but I obviously wasn't explicit enough. > > I've read that and done it by hand -- which is why I think I can > program what I need. However, it's some way from a Unix daemon that > starts up, queries other systems that might be running and asks one to > add_node it or otherwise starts orber itself, accounting for races > with an identical box rebooted at the same time. I expected this to > be a fairly common idiom, but maybe it's rare to use Erlang-based > services like this. > > [Being able to provide a properly-replicated server at all seems to be > a fairly compelling use of OTP; I've had no hint here that there's a > Java-based equivalent, and everything has to be written in Java.] This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From bjarne@REDACTED Tue Mar 23 21:11:29 2004 From: bjarne@REDACTED (=?iso-8859-1?Q?Bjarne_D=E4cker?=) Date: Tue, 23 Mar 2004 21:11:29 +0100 Subject: ICFP 2004 contest References: Message-ID: <003a01c41113$079d0bc0$760769d4@segeltorp> Hello ICFP is planned for September 19-22. September 19 is a Sunday and the conference seems planned for Monday and Tuesday followed by workshops on Wednesday, including the Erlang workshop http://www.erlang.se/workshop/2004/ One guess could be that the contest could happen on Sunday September 19. Bjarne ----- Original Message ----- From: "Marc van Woerkom" To: Sent: Tuesday, March 23, 2004 12:39 AM Subject: ICFP 2004 contest > Hm.. the contest web site, albeit in early stage, seems up: > > http://www.cis.upenn.edu/proj/plclub/contest/ > > Anyone knows the date for this year's contest? > > My time schedule is already under heavy pressure. > It would really help if I could know some weeks in advance, > when the contest weekend is. > > Regards, > Marc > From edmundd@REDACTED Wed Mar 24 04:50:54 2004 From: edmundd@REDACTED (Edmund Dengler) Date: Tue, 23 Mar 2004 22:50:54 -0500 (EST) Subject: UBF and asynchronous communication Message-ID: Hi all! In reviewing the UBF items from Joe's website, it looks like the entire system is premised mostly on the basis of synchronous communication, with a server being the only component that can send asynchronously. Basically, it appears that UBF cannot talk about concurrent communication events (or essentially, substates) or asynchronous sends. This has a couple of items that impact usage from my end: (1) We do some of our work over satellite, and with one-way trip times of 1 second to 4 seconds, having a communication synchronize on a response would generate significant throughput slowdown. Is there the equivalent of: "type() -> EVENT", similar to "EVENT -> type()" for server initiated messages. Basically, messages that do not need to wait for a response. Possibly "type() -> state"? (2) If the above is feasible, has any thought been given to supporting concurrent operations? There are two approaches to this off the top of my head: (a) the use of multiple "channels" where each channel would implement the synchronous communication, or (b) the idea of concurrent states where replies can actually impact state rather than the NULL operator of EVENT. Regards! Ed From ulf.wiger@REDACTED Wed Mar 24 06:47:12 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 24 Mar 2004 06:47:12 +0100 Subject: UBF and asynchronous communication In-Reply-To: References: Message-ID: On Tue, 23 Mar 2004 22:50:54 -0500 (EST), Edmund Dengler wrote: > Hi all! > > In reviewing the UBF items from Joe's website, it looks like the entire > system is premised mostly on the basis of synchronous communication, with > a server being the only component that can send asynchronously. > Basically, > it appears that UBF cannot talk about concurrent communication events (or > essentially, substates) or asynchronous sends. One of my current (background) projects is to try to address this. Another item I'm looking into is how to offer full support for the semantic tags (currently, they are only specified in UBF(A), but I want to be able to specify high-level types in UBF(B) using such tags.) I give no guarantees that the effort will actually result in anything. (: /Uffe -- Ulf Wiger From joe@REDACTED Wed Mar 24 10:35:02 2004 From: joe@REDACTED (Joe Armstrong) Date: Wed, 24 Mar 2004 10:35:02 +0100 (CET) Subject: UBF and asynchronous communication In-Reply-To: Message-ID: You are quite right! - I've been thinking about this for a while :-) To describe protocols I think you need a multi-layered language. I've made a little language to do this. Imagine you have this: A -------S-------- B This represents a communication channel between A and B. S is the "state" of the channel. Now one of two things can happed: A message can come from A, or A message can come from B. In response to this the state of the channel changes (to say S') I write this as follows: <> [A|B] x S -> S' This is the most general case. Remote procedure calls look like this: <> A x Si -> Sj <> B x Sj -> Sk ie A sends a message < (query) and receives a reply <> - since the state Sj is "irrelevant" we can write this like this: <> A x Si -> <> B x Sk If it is understood the A is a client and B a server, we can reduce this to <> x Si -> <> x Sk And if the server is *stateless* (ie can accept any message in any state) we can further simplify this to: <> -> < That's the basic idea. My little language specifies protocols in a number of sections, like this: ---------------------- begin ----------------- Description Send a <> message to the serve and you'll ll get back <> of an <> End. Semantics <> -> <> | <> End. Messages <> := {get, string()}; <> := bin(); <> := {error, string()} End. Encodings {get, X} = byte(1),int(4,len(X)),string(X) bin = byte(2), int(4,size(self)), string(self) {error,X} = byte(3), int(4,len(X)), string(X) End. --------------- end ------------- The description section can refer to messages (things in << >> brackets) The semantics is a finite state machine that describes the protocol The messages section says what the messages look like as Erlang terms The Encodings section says how Erlang terms get mapped onto the data structures that are seen "on the wire". Rule one here says {get, "file23"} is encoded as the sequence of bytes [1,0,0,0,23,f,i,l,e] I also support "standard" encodings. The standard encodings are XML-RPC, my own XML transport format [*], UBF, Erlang binary, and Erlang terms I also have a Language section - here we can systematically change message names and atoms from (say) English to (German) - these are the only changes since the message names and atoms convey meaning. Once all this is done we get the following structure +--------+ +--------+ --->--| Driver1|------------->--------------| Driver2|----->------------ A +--------+ X +--------+ B By parameterising Driver1 and Driver2 many things are possible A might be English Erlang terms X could be XML-RPC B might be German Erlang terms By changing the drivers X could change to Erlang binaries :-) The goal is a universal multi-lingual infrastructure. ---- This is very much work in progress - the non-generic encoding rule language is incomplete, as is the semantics language. Spontaneous events occurring in the middle of a synchronous RPC cannot be expressed nicely and the state machine can become messy. On the bright side - most protocols fall into the trivial stateless pure client-server category and are *very* easy to describe. Also streaming protocols are easy to describe. ----- Q: Where is all this leading? - A: To the panomnicom [*] /Joe [*] The first version of the panomnicom will appear on Planet-Lab pan - (Greek) all, whole, everything omni - (Latin) all every com - computer On Tue, 23 Mar 2004, Edmund Dengler wrote: > Hi all! > > In reviewing the UBF items from Joe's website, it looks like the entire > system is premised mostly on the basis of synchronous communication, with > a server being the only component that can send asynchronously. Basically, > it appears that UBF cannot talk about concurrent communication events (or > essentially, substates) or asynchronous sends. This has a couple of items > that impact usage from my end: > > (1) We do some of our work over satellite, and with one-way trip times of > 1 second to 4 seconds, having a communication synchronize on a response > would generate significant throughput slowdown. > > Is there the equivalent of: "type() -> EVENT", similar to "EVENT -> > type()" for server initiated messages. Basically, messages that do not > need to wait for a response. Possibly "type() -> state"? > > (2) If the above is feasible, has any thought been given to supporting > concurrent operations? There are two approaches to this off the top of my > head: (a) the use of multiple "channels" where each channel would > implement the synchronous communication, or (b) the idea of concurrent > states where replies can actually impact state rather than the NULL > operator of EVENT. > > Regards! > Ed > From luke@REDACTED Wed Mar 24 16:20:24 2004 From: luke@REDACTED (Luke Gorrie) Date: Wed, 24 Mar 2004 16:20:24 +0100 Subject: UBF and asynchronous communication In-Reply-To: (Joe Armstrong's message of "Wed, 24 Mar 2004 10:35:02 +0100 (CET)") References: Message-ID: Joe Armstrong writes: > This is very much work in progress - the non-generic encoding rule language is > incomplete, as is the semantics language. > > Spontaneous events occurring in the middle of a synchronous RPC cannot be > expressed nicely and the state machine can become messy. > > On the bright side - most protocols fall into the trivial stateless pure client-server > category and are *very* easy to describe. Me and some hacker-pals have recently been working a lot with a protocol that at first glance looks orderly and BNF-describable, but in reality was riddled with race conditions due to asynchronous communication (over a socket) and asynchronously-triggered events. Here is a long description of our trials and tribulations, in case somebody wants to read it and tell us a beautiful solution :-) Our protocol is used by Emacs to talk to a Lisp server. The basic operation is an RPC from Emacs to Lisp, and the complication is that if Lisp encounters an error then it will enter a debugger which it asks Emacs to control. While inside the debugger Emacs can make further RPCs, which may recursively enter the debugger. The original protocol, which is almost-okay, is (pardon my ad-hoc BNF-ish notation): IDLE state: Emacs->Lisp: RPC (push into EVALUATING state) EVALUATING state: Lisp->Emacs: RETURN (pop back to previous state) Lisp->Emacs: DEBUG (push into DEBUGGING state) DEBUGGING state: Lisp->Emacs: DEBUG-FINISHED (pop back to previous state) Emacs->Lisp: RPC (push into EVALUATING state) Both sides of the connection essentially maintain the same state machine. The stack in the state machine is used to match up a return value with the code that is supposed to process it, to keep track of whether an RPC is currently being served, and so on. Now, any state in which both sides can initiate an event are potential race conditions, since both sides could do it at once and move off into different states. The only state like that here is DEBUGGING, so if Emacs makes a fresh RPC at the same time the Lisp debugger returns then the protocol will be violated. In the IDLE and EVALUATING states there is no problem because the protocol only allows one party to initiate an event. We implemented this (several times) as a state machine (PDA) and included a UBF-style contract checker(*). This was okay in practice, race condition aside, but started to break down as the protocol expanded. The protocol expanded because the one above is too abstract. In reality Lisp can enter the debugger at any time (e.g. if it receives a SIGINT). To cope with this we had to add DEBUG events (with transitions into DEBUGGING) to every state, and then we had the same race condition in every state. We also had other similar events (e.g. Lisp could ask for user-input at any time), which introduced more states, more events that all states must handle, and more of the same type of race condition. We got to thinking this wasn't very good. The root of our problem was that the protocol only worked properly synchronously (both sides must see events in the same order), but we only had asynchronous communication available (a socket). It was possible for things to go awry and for RPCs to be sent when they weren't allowed, and so on. We considered two solutions, but only implemented and tried one. The one we didn't go with was keeping the race conditions but adding 'undo' transitions to roll back inconsistent changes. We would designate the server the "master": if it receives an inconsistent request it ignores it, and when Emacs discovers its request was ignored it "rolls back" to the previous state. This could perhaps be implemented e.g. with TCP-style acknowledgements, but it all sounds bloody complicated. Instead we stripped as much state as possible out of Emacs, because you can't lose synchronisation of state you don't have. So when Emacs makes an RPC it just tags it with an ID number and tucks away the {ID, Function} saying how to handle the reply when it arrives. I suppose this really means we made the whole protocol asynchronous. It seems to have worked out pretty well. One special advantage is that since Emacs no longer cares in what order it gets replies it can issue parallel requests, and those can be executed concurrently and complete out-of-order (using threads or signal-driven I/O). One disadvantage is that Emacs no longer knows whether Lisp is "busy" doing something for it or not. So far so good, overall. There were some more interesting issues in mixing synchronous- and asynchronous- RPC interfaces on this using a recursive event loop, but that is probably pretty Emacs-specific. *Anyway*. I'm interested in hearing new ideas about how to do this stuff, and to help shoot down ideas that don't go the whole mile :-) Cheers, Luke (*): The UBF-ish contract checker was really nice because it reports protocol errors very clearly, i.e. we can see what the bug is just from an automatically-generated report sent by a user. This way we get to find out whether any of our race conditions being triggered in practical use. Here is an example of a bug report we got: http://article.gmane.org/gmane.lisp.slime.devel/579 From thomasl_erlang@REDACTED Sun Mar 21 18:06:56 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Sun, 21 Mar 2004 09:06:56 -0800 (PST) Subject: user-defined operators Message-ID: <20040321170656.4258.qmail@web41902.mail.yahoo.com> Some time ago there was interest in extending Erlang with your own operators, e.g., !!. So why not provide them? Here is a code sketch for extending Erlang to permit simple user-defined infix operators `op`. The idea is basically taken from Haskell and seems fairly clean. I used backquotes around the operator because Haskell did so. I modified the erlang parser and scanner to support this notation; it seems to work, though I haven't used it very extensively. f(X, Y) -> X `foo` Y. %% note: foo is "backquoted" is parsed as if: f(X,Y) -> 'foo'(X,Y). %% call function foo/2 The operator `op` has the same precedence as andalso/orelse. You can also write `mod:func` to invoke mod:func(X,Y), e.g., Port `erlang:port_command` Data Both the module and the function have to be non-empty atoms. Thus, the following are considered errors, where foo is any atom: `:foo` `foo:` `:` `` I haven't tested how the scanner behaves with extreme quoting in the infix operator. The error return value in the scanner does not have a format_error. Finally, the code could probably be improved by someone more familiar with erl_scan/erl_parse. Example use: ========== 1> {ok, Ts, _} = erl_scan2:string("f(X,Y) -> X `op` Y."). ... 2> erl2:parse_form(Ts). ... Best, Thomas __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -------------- next part -------------- A non-text attachment was scrubbed... Name: erl2.yrl Type: application/octet-stream Size: 22457 bytes Desc: erl2.yrl URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: erl_scan2.erl Type: application/octet-stream Size: 29860 bytes Desc: erl_scan2.erl URL: From marc.vanwoerkom@REDACTED Wed Mar 24 20:30:33 2004 From: marc.vanwoerkom@REDACTED (Marc van Woerkom) Date: Wed, 24 Mar 2004 20:30:33 +0100 Subject: ICFP 2004 contest In-Reply-To: <003a01c41113$079d0bc0$760769d4@segeltorp> References: <003a01c41113$079d0bc0$760769d4@segeltorp> Message-ID: On Tue, 23 Mar 2004 21:11:29 +0100, Bjarne D?cker wrote: > Hello > > ICFP is planned for September 19-22. > > September 19 is a Sunday and the conference > seems planned for Monday and Tuesday > followed by workshops on Wednesday, > including the Erlang workshop > > http://www.erlang.se/workshop/2004/ > > One guess could be that the contest could > happen on Sunday September 19. No the contest was weeks before the conference, the last time. I just got a mail that says the programming contest will be roughly in june, perhaps 2nd half of june. That would be around last year's date (last three days of June). Regards, Marc From ulf.wiger@REDACTED Wed Mar 24 22:40:53 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 24 Mar 2004 22:40:53 +0100 Subject: user-defined operators In-Reply-To: <20040321170656.4258.qmail@web41902.mail.yahoo.com> References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> Message-ID: On Sun, 21 Mar 2004 09:06:56 -0800 (PST), Thomas Lindgren wrote: > Some time ago there was interest in extending Erlang > with your own operators, e.g., !!. So why not provide > them? > Here is a code sketch for extending Erlang to permit > simple user-defined infix operators `op`. The idea is > basically taken from Haskell and seems fairly clean. I > used backquotes around the operator because Haskell > did so. > I modified the erlang parser and scanner to support > this notation; it seems to work, though I haven't used > it very extensively. > f(X, Y) -> X `foo` Y. %% note: foo is "backquoted" > is parsed as if: > f(X,Y) -> 'foo'(X,Y). %% call function foo/2 > The operator `op` has the same precedence as > andalso/orelse. You can also write `mod:func` to > invoke mod:func(X,Y), e.g., > Port `erlang:port_command` Data So is your suggestion that one would write e.g. -import(sys, ['!!'/2,]). fetch(Host, File) -> Host `!!` {get, File}. ? /Uffe -- Ulf Wiger, Senior System Architect EAB/UPD/S This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From edmundd@REDACTED Thu Mar 25 01:49:47 2004 From: edmundd@REDACTED (Edmund Dengler) Date: Wed, 24 Mar 2004 19:49:47 -0500 (EST) Subject: Erlang Radius server? Message-ID: Howdy all! After having loads of fun dealing with FreeRadius/OpenRadius, I thought that there must be a better way of doing this type of work. So I got to wondering, has anybody looked at doing an Erlang Radius server? Not sure of the performance issues, but I think fundamentally there is nothing that should stop this (other than integration issues with LDAP and such). I had a quick look at jungerl and the Erlang projects page, but nothing appears. Regards! Ed From spearce@REDACTED Thu Mar 25 03:38:28 2004 From: spearce@REDACTED (Shawn Pearce) Date: Wed, 24 Mar 2004 21:38:28 -0500 Subject: user-defined operators In-Reply-To: References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> Message-ID: <20040325023828.GA576@spearce.org> Ulf Wiger wrote: > So is your suggestion that one would write e.g. > > -import(sys, ['!!'/2,]). > > fetch(Host, File) -> > Host `!!` {get, File}. Bleh! spearce `wontuse` backticks_for_operators. Are we trying to become Perl here or something? :-) Note that I don't have any suggestions for a better replacement of the backtick, I understand why it helps to parse the extended operators, but just don't like the backtick here... On the other hand, that is a really very, very cool idea. Because it makes adding operators a whole lot easier. Would be nice if it was possible to do (and I'm not advocating backticks by any way, just an example): -import(sys, ['!!'/2]). -import(plain_fsm, ['system'/1]). fetch(Host, File) -> Host `!!` {get, File}. loop() -> `system` receive {get, File} -> file:open(File), ..., loop() end. Which the receive call then winds up into: system(receive .... end). which then goes through a parse transform in Ulf's plain_fsm module thereby creating his extended receive code... So have infix operators map to arity 2 functions, prefix operators to arity 1. -- Shawn. From ulf.wiger@REDACTED Thu Mar 25 06:57:08 2004 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 25 Mar 2004 06:57:08 +0100 Subject: Erlang Radius server? In-Reply-To: References: Message-ID: I guess you only looked at the Jungerl web page then? In the Jungerl CVS tree, you will find both eradius and eldap. See also the presentation "Talking LDAP and Radius from Erlang" given by Torbj?rn T?rnkvist at the Erlang User Conference 2003: http://www.erlang.se/euc/03/proceedings/1200tobbe.ppt /Uffe On Wed, 24 Mar 2004 19:49:47 -0500 (EST), Edmund Dengler wrote: > Howdy all! > > After having loads of fun dealing with FreeRadius/OpenRadius, I thought > that there must be a better way of doing this type of work. So I got to > wondering, has anybody looked at doing an Erlang Radius server? Not sure > of the performance issues, but I think fundamentally there is nothing > that > should stop this (other than integration issues with LDAP and such). I > had > a quick look at jungerl and the Erlang projects page, but nothing > appears. > > Regards! > Ed -- Ulf Wiger From baloghrobi@REDACTED Thu Mar 25 07:20:36 2004 From: baloghrobi@REDACTED (Robert Balogh) Date: Thu, 25 Mar 2004 07:20:36 +0100 Subject: gs grid value change...how? Message-ID: Hi, I would like to ask you, how possible to change the values in the gridline after create this? I can do this with cyclic create-destroy hole grid object but it is not a nice solution. It is blinking when this cyclic fast :-( So can anybody help me? thanks for your help, regards, /Robi _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail From tobbe@REDACTED Thu Mar 25 09:16:02 2004 From: tobbe@REDACTED (=?ISO-8859-1?Q?Torbj=F6rn_T=F6rnkvist?=) Date: Thu, 25 Mar 2004 09:16:02 +0100 Subject: Erlang Radius server? In-Reply-To: References: Message-ID: <40629542.9090800@nortelnetworks.com> Edmund Dengler wrote: >Howdy all! > >After having loads of fun dealing with FreeRadius/OpenRadius, I thought >that there must be a better way of doing this type of work. So I got to >wondering, has anybody looked at doing an Erlang Radius server? Not sure >of the performance issues, but I think fundamentally there is nothing that >should stop this (other than integration issues with LDAP and such). I had >a quick look at jungerl and the Erlang projects page, but nothing appears. > >Regards! >Ed > > As Ulf already pointed out: you'll find eradius in the jungerl CVS. However, it doesn't implement a Radius server (yet...), only the client part. So feel free to add a Radius server to it Cheers, Tobbe From carsten@REDACTED Thu Mar 25 10:05:42 2004 From: carsten@REDACTED (Carsten Schultz) Date: Thu, 25 Mar 2004 10:05:42 +0100 Subject: user-defined operators In-Reply-To: <20040325023828.GA576@spearce.org> References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <20040325023828.GA576@spearce.org> Message-ID: <20040325090542.GA27022@penne.localnet> On Wed, Mar 24, 2004 at 09:38:28PM -0500, Shawn Pearce wrote: > Ulf Wiger wrote: > > So is your suggestion that one would write e.g. > > > > -import(sys, ['!!'/2,]). > > > > fetch(Host, File) -> > > Host `!!` {get, File}. > > Bleh! > > spearce `wontuse` backticks_for_operators. Just for those who don't know, and because Haskell has been mentioned as an inspiration (and sorry, I do not know the correct terminology): In Haskell you can define your own operators, and operators and functions (ie ordinary variables) are distinguished by the characters they are made of. Example operator: +++. Example function: plus. You can define your own of both. The clever bit is that by enclosing an operator name in parentheses, you make it an ordinary variable, and by enclosing a variable in backticks you make it an infix operator. So you can define (+++) :: [Int] -> Int -> [Int] (+++) (x:xs) y = (x+y) : xs to add an Int to the first element of a list of Ints and then use this as [1,2,3] +++ 5 (yielding [6,2,3]) or (+++) [1,2,3] 5 as you like. Or you could have defined plus :: [Int] -> Int -> [Int] plus (x:xs) y = (x+y) : xs and used it as [1,2,3] `plus` 5 or plus [1,2,3] 5 Greetings, Carsten -- Carsten Schultz (2:38, 33:47), FB Mathematik, FU Berlin http://carsten.codimi.de/ PGP/GPG key on the pgp.net key servers, fingerprint on my home page. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sean.hinde@REDACTED Thu Mar 25 10:49:23 2004 From: sean.hinde@REDACTED (Sean Hinde) Date: Thu, 25 Mar 2004 09:49:23 +0000 Subject: Erlang Radius server? In-Reply-To: <40629542.9090800@nortelnetworks.com> References: <40629542.9090800@nortelnetworks.com> Message-ID: On 25 Mar 2004, at 08:16, Torbj?rn T?rnkvist wrote: > Edmund Dengler wrote: > >> Howdy all! >> >> After having loads of fun dealing with FreeRadius/OpenRadius, I >> thought >> that there must be a better way of doing this type of work. So I got >> to >> wondering, has anybody looked at doing an Erlang Radius server? Not >> sure >> of the performance issues, but I think fundamentally there is nothing >> that >> should stop this (other than integration issues with LDAP and such). >> I had >> a quick look at jungerl and the Erlang projects page, but nothing >> appears. >> >> Regards! >> Ed >> > As Ulf already pointed out: you'll find eradius in the jungerl CVS. > However, it doesn't implement a Radius server (yet...), only the > client part. > > So feel free to add a Radius server to it I just got round to looking at eradius and it looks very nice indeed. We have a RADIUS server, but I would describe it as a 1 week job - very targetted minimal implementation. eradius has all the nice dictionary framework, packet encoding etc to build a nice generic server so looks to me an excellent starting point - most of the hard work has been done. Sean From vlad_dumitrescu@REDACTED Thu Mar 25 12:52:30 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 25 Mar 2004 12:52:30 +0100 Subject: Lisp interpreter Message-ID: Hi all, Has anyone been toying with implementing a Lisp interpreter in Erlang? It's not difficult, I know, but why duplicate effort? :-) regards, Vlad From micke@REDACTED Thu Mar 25 13:31:41 2004 From: micke@REDACTED (Michael Fogeborg) Date: Thu, 25 Mar 2004 13:31:41 +0100 Subject: Lisp interpreter Message-ID: <5.1.0.14.1.20040325133114.00be1740@online.no> LERlang ? ( Possibly funny in Swedish, where LER can be interpreted as CLAY ala LISP ... ;-) At 12:52 25.03.2004 +0100, you wrote: >Hi all, > >Has anyone been toying with implementing a Lisp interpreter in Erlang? >It's not >difficult, I know, but why duplicate effort? :-) > >regards, >Vlad From luke@REDACTED Thu Mar 25 15:04:50 2004 From: luke@REDACTED (Luke Gorrie) Date: Thu, 25 Mar 2004 15:04:50 +0100 Subject: Lisp interpreter In-Reply-To: (Vlad Dumitrescu's message of "Thu, 25 Mar 2004 12:52:30 +0100") References: Message-ID: "Vlad Dumitrescu" writes: > Has anyone been toying with implementing a Lisp interpreter in Erlang? It's not > difficult, I know, but why duplicate effort? :-) [Sound of a hundred people looking through their ~/src directories..] I have a toy Scheme in the Jungerl: luke@REDACTED:~/hacking/jungerl$ bin/lersp lersp> (define (add-one x) (+ x 1)) true lersp> (add-one 41) 42 From mlogan@REDACTED Thu Mar 25 17:38:03 2004 From: mlogan@REDACTED (Martin J. Logan) Date: 25 Mar 2004 10:38:03 -0600 Subject: user-defined operators In-Reply-To: <20040321170656.4258.qmail@web41902.mail.yahoo.com> References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> Message-ID: <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> I think that the overloading of operators is a nifty idea and I can think of a few places where it would make my life easier. I must state in the face of my previous statement that my take on operator overloading and defining ones own operators is that it should not be done. Operators should be defined by a central body responsible for the language syntax and semantics. In this way a modicum of consistency in the language is ensured. With functions, because they are typically spelled out with letters, at least one is nudged in the direction of intentionality. With operators they can be anything $_ $# @# @_. I hated reading c++ code where some operator was overloaded to do something completely unintuitive. This is inevitable when you give control of these things to anyone. Example: wasting_your_time_trying_to_read_this() -. %% Here I append strings with the "string <- enters other %% string" operator. At the end I use the "'}{' Convert integer to %% string and append" operator to append an integer to the string. BigString = "I " <- "write " <- "crappy " <- "code + " '}{' Integer <- " ", %% Here I want to to take my string and use the case operator '.]' %% which takes a string and an atom either 'upcase' or 'downcase' to %% alter the case of chars in a string. I then operate on it with the %% 's+' string operator with the argument 'chop' which will remove %% any trailing space. Cased = (BigString '.]' upcase)'s+'chop. I am sure that I will be subjected to erlang code of this type if people are allowed to create their own operators. An objection that could be raised is well the Haskell code I have seen does not suffer from that. The answer to that question is that as soon as the user base grows it will. Cheers, Martin On Sun, 2004-03-21 at 11:06, Thomas Lindgren wrote: > Some time ago there was interest in extending Erlang > with your own operators, e.g., !!. So why not provide > them? > > Here is a code sketch for extending Erlang to permit > simple user-defined infix operators `op`. The idea is > basically taken from Haskell and seems fairly clean. I > used backquotes around the operator because Haskell > did so. > > I modified the erlang parser and scanner to support > this notation; it seems to work, though I haven't used > it very extensively. > > f(X, Y) -> X `foo` Y. %% note: foo is "backquoted" > > is parsed as if: > > f(X,Y) -> 'foo'(X,Y). %% call function foo/2 > > The operator `op` has the same precedence as > andalso/orelse. You can also write `mod:func` to > invoke mod:func(X,Y), e.g., > > Port `erlang:port_command` Data > > Both the module and the function have to be non-empty > atoms. Thus, the following are considered errors, > where foo is any atom: > `:foo` > `foo:` > `:` > `` > > I haven't tested how the scanner behaves with extreme > quoting in the infix operator. The error return value > in the scanner does not have a format_error. Finally, > the code could probably be improved by someone more > familiar with erl_scan/erl_parse. > > Example use: > ========== > 1> {ok, Ts, _} = erl_scan2:string("f(X,Y) -> X `op` > Y."). > ... > 2> erl2:parse_form(Ts). > ... > > Best, > Thomas > > __________________________________ > Do you Yahoo!? > Yahoo! Finance Tax Center - File online. File on time. > http://taxes.yahoo.com/filing.html > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > From enewhuis@REDACTED Thu Mar 25 18:37:33 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 25 Mar 2004 11:37:33 -0600 Subject: user-defined operators In-Reply-To: <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> Message-ID: <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> I agree with Martin. And what I WOULD like from Erlang are more standard operators that make it easier to capture common Erlang coding idioms. For example, Erlang's "foreach" idiom is too verbose. One spends more time looking at code structure rather than intentions. Consider the following Erlang code: lists:foreach (F, SomeList). When I see that my eyes are drawn to the lists:foreach part of the expression rather than the things that matter (F and SomeList). Operators that looked like this would be easier to read and would allow nesting without confusion: F each SomeList Studying the APL language would be a good place to start to ponder these special operators. The K language is another good place to start. Those languages are superior to Erlang in terms of operators and expressive power. As an example here is something that calls a binary function over two vectors in K: {x+y}'[XList; YList] The quote operator ' is equivalent to the lists:foreach and the brackets expand the valence of the function from a function of one variable x to a function of two variables x and y. To read that code one pronounces "each" when one sees the quote operator. So reading the above one would say "x plus y for each XList YList". Don't hate me. I love Erlang. But I love K's operators more. Erlang + K operators would be pure bliss. Erlang needs more powerful operators. I don't think it needs operator overloading. HOWEVER if there were a way to put Erlang into an operator defining mode for experimenting such that a community of experts could play with various potential STANDARD operators prior to introducing them to the larger community then THAT would be a great excuse to have Erlang operator overloading. I'd like to see unary, binary, tertiary, and even n-ary operators. I don't think one should assume that all operators act on just one or two variables. Operators could be overloaded for monadic, dyadic, etc. They should act on scalars as well as vectors and each form should have a corresponding distinct implementation. Example: What is the meaning of X 'operator' Y if X and Y are scalars? What if X and Y are vectors? What if one is a Matrix and the other is another Matrix of different dimension? Are operators overloaded based on type? I'd hope any new standard operators would be so overloaded but retain a common theme throughout the overloading. On Mar 25, 2004, at 10:38 AM, Martin J. Logan wrote: > I think that the overloading of operators is a nifty idea and I can > think of a few places where it would make my life easier. I must state > in the face of my previous statement that my take on operator > overloading and defining ones own operators is that it should not be > done. Operators should be defined by a central body responsible for the > language syntax and semantics. In this way a modicum of consistency in > the language is ensured. With functions, because they are typically > spelled out with letters, at least one is nudged in the direction of > intentionality. With operators they can be anything $_ $# @# @_. I > hated > reading c++ code where some operator was overloaded to do something > completely unintuitive. This is inevitable when you give control of > these things to anyone. > > > Example: > wasting_your_time_trying_to_read_this() -. > %% Here I append strings with the "string <- enters other > %% string" operator. At the end I use the "'}{' Convert integer to > %% string and append" operator to append an integer to the string. > BigString = "I " <- "write " <- "crappy " <- "code + " '}{' Integer > <- " ", > > %% Here I want to to take my string and use the case operator '.]' > %% which takes a string and an atom either 'upcase' or 'downcase' to > %% alter the case of chars in a string. I then operate on it with > the > %% 's+' string operator with the argument 'chop' which will remove > %% any trailing space. > Cased = (BigString '.]' upcase)'s+'chop. > > I am sure that I will be subjected to erlang code of this type if > people > are allowed to create their own operators. An objection that could be > raised is well the Haskell code I have seen does not suffer from that. > The answer to that question is that as soon as the user base grows it > will. > > Cheers, > Martin > > > > > On Sun, 2004-03-21 at 11:06, Thomas Lindgren wrote: >> Some time ago there was interest in extending Erlang >> with your own operators, e.g., !!. So why not provide >> them? >> >> Here is a code sketch for extending Erlang to permit >> simple user-defined infix operators `op`. The idea is >> basically taken from Haskell and seems fairly clean. I >> used backquotes around the operator because Haskell >> did so. >> >> I modified the erlang parser and scanner to support >> this notation; it seems to work, though I haven't used >> it very extensively. >> >> f(X, Y) -> X `foo` Y. %% note: foo is "backquoted" >> >> is parsed as if: >> >> f(X,Y) -> 'foo'(X,Y). %% call function foo/2 >> >> The operator `op` has the same precedence as >> andalso/orelse. You can also write `mod:func` to >> invoke mod:func(X,Y), e.g., >> >> Port `erlang:port_command` Data >> >> Both the module and the function have to be non-empty >> atoms. Thus, the following are considered errors, >> where foo is any atom: >> `:foo` >> `foo:` >> `:` >> `` >> >> I haven't tested how the scanner behaves with extreme >> quoting in the infix operator. The error return value >> in the scanner does not have a format_error. Finally, >> the code could probably be improved by someone more >> familiar with erl_scan/erl_parse. >> >> Example use: >> ========== >> 1> {ok, Ts, _} = erl_scan2:string("f(X,Y) -> X `op` >> Y."). >> ... >> 2> erl2:parse_form(Ts). >> ... >> >> Best, >> Thomas >> >> __________________________________ >> Do you Yahoo!? >> Yahoo! Finance Tax Center - File online. File on time. >> http://taxes.yahoo.com/filing.html >> This communication is confidential and intended solely for the >> addressee(s). Any unauthorized review, use, disclosure or >> distribution is prohibited. If you believe this message has been sent >> to you in error, please notify the sender by replying to this >> transmission and delete the message without disclosing it. Thank you. >> >> E-mail including attachments is susceptible to data corruption, >> interruption, unauthorized amendment, tampering and viruses, and we >> only send and receive e-mails on the basis that we are not liable for >> any such corruption, interception, amendment, tampering or viruses or >> any consequences thereof. >> > From luke@REDACTED Thu Mar 25 18:56:20 2004 From: luke@REDACTED (Luke Gorrie) Date: Thu, 25 Mar 2004 18:56:20 +0100 Subject: user-defined operators In-Reply-To: <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> (Eric Newhuis's message of "Thu, 25 Mar 2004 11:37:33 -0600") References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> Message-ID: Eric Newhuis writes: > For example, Erlang's "foreach" idiom is too verbose. One spends more > time looking at code structure rather than intentions. > > Consider the following Erlang code: > > lists:foreach (F, SomeList). Better is: foreach(F, List) I tend to '-import' any well-known functions that I use from 'lists'. From enewhuis@REDACTED Thu Mar 25 19:15:14 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 25 Mar 2004 12:15:14 -0600 Subject: user-defined operators In-Reply-To: References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> Message-ID: <5CA46C62-7E88-11D8-A476-000A95D9A520@futuresource.com> > I tend to '-import' any well-known functions that I use from 'lists'. Yes good point. foreach is a simple one. The others like foldl always throw me. I am always going back to the man pages. K's foldl operator is just a single forward slash ("/"). It is pronounced "over". F / Vector is read as "F over Vector". Example: Accumulate sum over a vector of integers: K: +/1 2 3 4 5 Erlang: lists:foldl (fun (X, A) -> X + A end, 0, [1, 2, 3, 4]). Would be nice to just say this in Erlang: 0 + over [1, 2, 3, 4]. From luke@REDACTED Thu Mar 25 19:52:53 2004 From: luke@REDACTED (Luke Gorrie) Date: Thu, 25 Mar 2004 19:52:53 +0100 Subject: user-defined operators In-Reply-To: <5CA46C62-7E88-11D8-A476-000A95D9A520@futuresource.com> (Eric Newhuis's message of "Thu, 25 Mar 2004 12:15:14 -0600") References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> <5CA46C62-7E88-11D8-A476-000A95D9A520@futuresource.com> Message-ID: Eric Newhuis writes: > K: > +/1 2 3 4 5 > > Erlang: > lists:foldl (fun (X, A) -> X + A end, 0, [1, 2, 3, 4]). Or: foldl({erlang,'+'}, 0, [1,2,3,4]). From vlad_dumitrescu@REDACTED Thu Mar 25 19:54:17 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 25 Mar 2004 19:54:17 +0100 Subject: Lisp interpreter References: Message-ID: From: "Luke Gorrie" > I have a toy Scheme in the Jungerl: Cool, I should have checked jungerl before asking :-) Thanks! /Vlad From samuel@REDACTED Thu Mar 25 20:08:05 2004 From: samuel@REDACTED (Samuel Rivas) Date: Thu, 25 Mar 2004 20:08:05 +0100 Subject: user-defined operators In-Reply-To: <5CA46C62-7E88-11D8-A476-000A95D9A520@futuresource.com> References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> <5CA46C62-7E88-11D8-A476-000A95D9A520@futuresource.com> Message-ID: <20040325190805.GA8738@crusher.lfcia.pri> Eric Newhuis wrote: > Yes good point. foreach is a simple one. The others like foldl always > throw me. I am always going back to the man pages. K's foldl operator > is just a single forward slash ("/"). It is pronounced "over". > > F / Vector is read as "F over Vector". > > Example: Accumulate sum over a vector of integers: > > K: > +/1 2 3 4 5 > > Erlang: > lists:foldl (fun (X, A) -> X + A end, 0, [1, 2, 3, 4]). > > Would be nice to just say this in Erlang: > > 0 + over [1, 2, 3, 4]. > I find more readable Sum = fun(X, A) -> X + A end, lists:foldl(Sum, 0, [1, 2, 3, 4]). If you don't know anything about the + over you can 'assume' that is for adding the left side to each element of the right side, to fold the right side starting in 0 using + or many other strange things like mapping the left side in each element of the right side. When you found a operator you haven't seen before you must look for it in the documentation too, but is reasonable to think that foldl will do what it really does. What I mean is that "strange" operators are, at least, as confusing as unknown functions, but a function can explain more or less what is intended for. Overloading operators (beyond the overloading of arithmetical operators to work either with naturals or reals) is too deceptive, in my opinion. I saw me once thinking about "2" + "2" will yield "4" or "22" or an error or ... -- --------------------- | Samuel | --------------------- From vlad_dumitrescu@REDACTED Thu Mar 25 20:09:30 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Thu, 25 Mar 2004 20:09:30 +0100 Subject: user-defined operators References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> <5CA46C62-7E88-11D8-A476-000A95D9A520@futuresource.com> Message-ID: Hi, > Would be nice to just say this in Erlang: > 0 + over [1, 2, 3, 4]. Maybe, but how about comparing lists:foldl (fun (X, A) -> M:foo(Env, X, A) end, 0, [1, 2, 3, 4]). with 0 fun(X, Y)->M:foo(Env, X, Y)end over [1, 2, 3, 4]. ? If we name the fun, then we're back to Martin's '$@*_' operators. In this case, there isn't much to gain, really. And I argue it's easier to read the original. That said, I too would like to see such heavily used functionality being less verbose, but I can't come up with anything that is easy to read in the general case. Regarding the beforementioned idea of an "Erlang playground" for testing such new ideas, I think it'd be interesting. Basically, this would mean that we'd have another language(s) with Erlang semantics that get compiled to beam code. regards, Vlad From thomasl_erlang@REDACTED Thu Mar 25 21:52:26 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 25 Mar 2004 12:52:26 -0800 (PST) Subject: user-defined operators In-Reply-To: Message-ID: <20040325205226.97757.qmail@web41906.mail.yahoo.com> --- Ulf Wiger wrote: > So is your suggestion that one would write e.g. > > -import(sys, ['!!'/2,]). > > fetch(Host, File) -> > Host `!!` {get, File}. Basically, yes. Best, Thomas __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html From bjarne@REDACTED Thu Mar 25 21:33:33 2004 From: bjarne@REDACTED (=?iso-8859-1?Q?Bjarne_D=E4cker?=) Date: Thu, 25 Mar 2004 21:33:33 +0100 Subject: Lisp interpreter References: <5.1.0.14.1.20040325133114.00be1740@online.no> Message-ID: <002901c412a8$75178d60$cb1069d4@segeltorp> Lisp in Erlang ?! The man to do that might be Bj?rn Lisper ! http://www.idt.mdh.se/personal/blr/ /Bjarne ----- Original Message ----- From: "Michael Fogeborg" To: Sent: Thursday, March 25, 2004 1:31 PM Subject: Re: Lisp interpreter > LERlang ? ( Possibly funny in Swedish, where LER can be interpreted as > CLAY ala LISP ... ;-) > > At 12:52 25.03.2004 +0100, you wrote: > >Hi all, > > > >Has anyone been toying with implementing a Lisp interpreter in Erlang? > >It's not > >difficult, I know, but why duplicate effort? :-) > > > >regards, > >Vlad > From thomasl_erlang@REDACTED Thu Mar 25 22:00:34 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 25 Mar 2004 13:00:34 -0800 (PST) Subject: user-defined operators In-Reply-To: <20040325023828.GA576@spearce.org> Message-ID: <20040325210034.2200.qmail@web41906.mail.yahoo.com> --- Shawn Pearce wrote: > Ulf Wiger wrote: > > So is your suggestion that one would write e.g. > > > > -import(sys, ['!!'/2,]). > > > > fetch(Host, File) -> > > Host `!!` {get, File}. > > Bleh! > > spearce `wontuse` backticks_for_operators. > > Are we trying to become Perl here or something? :-) Heh, no ... I just reused Haskell's notation. As long as the operator name is clearly delimited, it's fine by me. As to adding prefix operators: I think it would be feasible. The main thing would be to mark it clearly and give it an obvious, fixed precedence. Best, Thomas __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html From thomasl_erlang@REDACTED Thu Mar 25 22:19:50 2004 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Thu, 25 Mar 2004 13:19:50 -0800 (PST) Subject: user-defined operators In-Reply-To: <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> Message-ID: <20040325211950.18278.qmail@web41902.mail.yahoo.com> --- "Martin J. Logan" wrote: > I think that the overloading of operators is a nifty > idea and I can > think of a few places where it would make my life > easier. I must state > in the face of my previous statement that my take on > operator > overloading and defining ones own operators is that > it should not be > done. Operators should be defined by a central body > responsible for the > language syntax and semantics. In this way a modicum > of consistency in > the language is ensured. However, note that: - there is a single way to write the new operator: `op` - there is a single, fixed precedence (one should also define the infix-op to be non-associative) - there is a simple semantics (function call) That avoids most of the problems with extensible syntax, I think; in particular, there is no need to know what operators have been defined (or how) to read the program. An alternate view is that this is special notation for a restricted apply. Mangling syntax just a little bit more: X `Op` Y -> Op(X,Y). Best, Thomas __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html From enewhuis@REDACTED Thu Mar 25 23:09:13 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 25 Mar 2004 16:09:13 -0600 Subject: user-defined operators In-Reply-To: <20040325211950.18278.qmail@web41902.mail.yahoo.com> References: <20040325211950.18278.qmail@web41902.mail.yahoo.com> Message-ID: <0CFAD7F8-7EA9-11D8-A476-000A95D9A520@futuresource.com> What? No currying? :( LOL > X `Op` Y -> Op(X,Y). From ok@REDACTED Thu Mar 25 23:36:32 2004 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 26 Mar 2004 10:36:32 +1200 (NZST) Subject: user-defined operators Message-ID: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> I'm seeing a certain amount of scaremongering in this thread. First, the thread is about user-defined operators, NOT about operator overloading. Whatever the merits and pitfalls of operating overloading, they are not relevant to the topic of user defined operators. Second, most functional languages have supported user defined operators for years. ML has them. Haskell has them. Clean has them. Prolog has them. Mercury has them. *DO* you in fact get a welter of confusing operators? NO. In part this is because operators can only have one or two arguments, while functions and predicates commonly need more. Haskell has two kinds of operators: alphabetic ones (which must always be enclosed in backquotes) and symbolic ones (which may never be enclosed in backquotes). So in Haskell `elem` is a alphabetic operator and `!!` is not legal syntax at all. Operators are declared using infix [Prec] op... infixl [Prec] op... infixr [Prec] op... where Prec is a decimal digit. A symbolic operator may only be used if it has been declared. An alphabetic operator has the weakest precedence unless it is explicitly declared. Now alphabetic operators (especially if they all have the same precedence, as they used to in Haskell) are no harder to read than any other function name, and no more subject to overloading. (Each operator/function in Haskell has precisely one meaning in scope.) It does not seem to me that n `elem` primes seconds `div` 60 fromInteger big `asTypeOf` x expr `catch` handler are particularly hard to read. As for the idea that some group of experts should determine a set of operators for Erlang, well, (a) they already did, and (b) if the experts who designed Haskell came up with gems like $! and :% (actually, once you know the rule that a symbolic operator starting with a colon must be a constructor, it's not that hard to figure out what :% does), what reason is there to expect the Erlang experts to do any better? The important thing about !! is not that it is spelled bang-bang, but that it is a concise notation for doing a remote procedure call. Suppose that alphabetic operators *only* were adopted, so that any Erlang user could use any two-argument function as an infix operator. Instead of Result = Pid !! Message we'd have to write Result = Pid `rpc` Message which is three characters longer but 100% clearer. I note that Fortran has had user-defined operators for a while now; the syntax is , so the Fortran equivalent might be Result = Pid .RPC. Message I haven't heard anything about an explosion of unreadability in Fortran since this addition was made; maybe using words as operators really isn't any worse than using words as function names. From enewhuis@REDACTED Fri Mar 26 00:06:06 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 25 Mar 2004 17:06:06 -0600 Subject: user-defined operators In-Reply-To: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> References: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> Message-ID: > It does not seem to me that > n `elem` primes > seconds `div` 60 > fromInteger big `asTypeOf` x > expr `catch` handler > are particularly hard to read. Yes! This is beautiful, semantically rich, and poetic. These are the things that drive re-understanding of code written by groups of developers. I would LOVE to see this capability in Erlang. If I was really concerned about it I could then define my dyadic `each` and do: F `each` [ItemsX, ItemsY]. ...where F is a function of two variables. From enewhuis@REDACTED Fri Mar 26 00:30:34 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Thu, 25 Mar 2004 17:30:34 -0600 Subject: user-defined operators In-Reply-To: References: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> Message-ID: <69C519C4-7EB4-11D8-B19C-000A95D9A520@wideopenwest.com> > F `each` [ItemsX, ItemsY]. > > ...where F is a function of two variables. Perhaps I could have more clearly expressed this as: Plot `eachPairOf` [XCoordinates, YCoordinates]. The idea is that one applies Plot over each pair of elements in vectors XCoordinates and YCoordinates. Not everyone wants to view the world as a list of records. Some things, especially very large time-series data sets are best kept as columnar to facilitate binary search over key vectors. But I digress... From spearce@REDACTED Fri Mar 26 06:35:18 2004 From: spearce@REDACTED (Shawn Pearce) Date: Fri, 26 Mar 2004 00:35:18 -0500 Subject: user-defined operators In-Reply-To: <5CA46C62-7E88-11D8-A476-000A95D9A520@futuresource.com> References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> <5CA46C62-7E88-11D8-A476-000A95D9A520@futuresource.com> Message-ID: <20040326053518.GD3173@spearce.org> Eric Newhuis wrote: > Erlang: > lists:foldl (fun (X, A) -> X + A end, 0, [1, 2, 3, 4]). > > Would be nice to just say this in Erlang: > > 0 + over [1, 2, 3, 4]. Yes! Though I'm not really sure why. :-) I'm a perl hacker at heart, and one of my favorite operators has to be =~ and !~. In a language where you are doing text processing so much, its very handy to have regular expressions "at your finger tips". In Erlang, like LISP and Scheme, we do list processing all of the time: foreach map filter foldl foldr Though fortunately there's a few ways to write these operations, with LCs being a huge improvement for the first three (but is frowned upon as a shorthand for foreach). Still, it would be very nice if they were even easier to express. I'm very against operator overloading, as someone already metioned the pain they went through trying to decide what the result of "2 + 2" would be in some weird case... I've had the same experience in C++ and have never looked at the language again. That one very bad feature of the language has left a bad taste in my mouth. But so has Python, Tcl, Java and Erlang when it comes to regular expression processing - Perl just can't be beat (thanks to =~ and !~). But Erlang can't be beat when it comes to concurrent/parallel processing. Nothing is easier than receive ... end and !. !! would be such a nice addition. Whatever happens here, folks are right to be worried about operator pollution. We don't want Erlang to start to look like Perl or someone's sendmail.cf file (does anyone even remember those anymore?). Erlang code should be poetic, concise, and clearly understandable. I find it such a huge improvement over everything else I've written in to date, so I would hate to see it change for the worse. -- Shawn. From vlad_dumitrescu@REDACTED Fri Mar 26 10:12:12 2004 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Fri, 26 Mar 2004 10:12:12 +0100 Subject: user-defined operators References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> <5CA46C62-7E88-11D8-A476-000A95D9A520@futuresource.com> <20040326053518.GD3173@spearce.org> Message-ID: Just my 2 cents. > Would be nice to just say this in Erlang: > > 0 + over [1, 2, 3, 4]. In this case, I'm not sure that the intent is so clear. I can live with binary operators, but when there are more arguments, I feel it begins to lose elegance. For example, the above could also mean "add 0 to the result of the unary operator 'over' applied to the list". Also, each argument to 'over' could be an arbitrary expression: without parantheses and commas, I'd find this harder to read than a call to lists:foldl. This can create subtle bugs, and in the end people might end using parantheses or temporary results to make sure they get what they intend. Then I think that most of the usefulness of these operators vanishes. I'd rather see the record mess fixed. Preferably with lots of syntactic sugar! ;-) /Vlad From tobbe@REDACTED Fri Mar 26 10:28:17 2004 From: tobbe@REDACTED (=?ISO-8859-1?Q?Torbj=F6rn_T=F6rnkvist?=) Date: Fri, 26 Mar 2004 10:28:17 +0100 Subject: Position avaliable Message-ID: <4063F7B1.8000204@nortelnetworks.com> Hi, I'm just forwarding this message from my manager. /Tobbe --------------------------------------------------------------- Hello, I know that this mailing list is supposed to cover technical questions regarding Erlang but in an attempt to reach the right target group I could not find another channel. We (the former Bluetail team) has got a position as quality assurance (test engineer) for our products open and this position can be filled as soon as possible. I do not want to (ab)use this list too much so any person that would like to know more about what this means and what products we develop etc are most welcome to contact me off the list. My mailadress is tlarsson@REDACTED Best regards, Tord Larsson, Alteon Web Systems AB (Nortel Networks) --------------------------------------------------------------- From d.love@REDACTED Fri Mar 26 12:47:56 2004 From: d.love@REDACTED (Dave Love) Date: Fri, 26 Mar 2004 11:47:56 +0000 Subject: user-defined operators References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <20040325023828.GA576@spearce.org> <20040325090542.GA27022@penne.localnet> Message-ID: Carsten Schultz writes: > The clever bit is that by enclosing > an operator name in parentheses, you make it an ordinary variable, Actually it's a `section' -- partial application: Prelude> (/) 4 2 2.0 Prelude> (4/) 2 2.0 Prelude> (/2) 4 2.0 (You get to define the precedence and associativity of user-defined Haskell operators, of course.) From d.love@REDACTED Fri Mar 26 12:59:55 2004 From: d.love@REDACTED (Dave Love) Date: Fri, 26 Mar 2004 11:59:55 +0000 Subject: user-defined operators References: <20040321170656.4258.qmail@web41902.mail.yahoo.com> <1080232683.2114.512.camel@dhcp-lom-194-186.futuresource.com> <18FF4F96-7E83-11D8-A476-000A95D9A520@futuresource.com> Message-ID: Eric Newhuis writes: > Studying the APL language would be a good place to start to ponder > these special operators. Haskell already credits APL, of course. Apart from other functional languages, algebra systems like Macsyma (Maxima) provide long-standing experience of user-defined operators. Looking at a Macsyma-style Pratt parser might also make clear the distinction between the operators and overloading. From luke@REDACTED Fri Mar 26 14:44:32 2004 From: luke@REDACTED (Luke Gorrie) Date: Fri, 26 Mar 2004 14:44:32 +0100 Subject: user-defined operators In-Reply-To: <69C519C4-7EB4-11D8-B19C-000A95D9A520@wideopenwest.com> (Eric Newhuis's message of "Thu, 25 Mar 2004 17:30:34 -0600") References: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> <69C519C4-7EB4-11D8-B19C-000A95D9A520@wideopenwest.com> Message-ID: Eric Newhuis writes: >> F `each` [ItemsX, ItemsY]. >> >> ...where F is a function of two variables. > > Perhaps I could have more clearly expressed this as: > > Plot `eachPairOf` [XCoordinates, YCoordinates]. > > The idea is that one applies Plot over each pair of elements in > vectors XCoordinates and YCoordinates. > > Not everyone wants to view the world as a list of records. But not everyone wants to view the world as a set of matrices either. Special syntax will make certain things convenient, but higher-order functions will still be the general solution for control structures. It seems to me a bigger win if we could make those better instead. Have we already had a syntax-war about nice'n'short Smalltalk-style syntax for funs? e.g. foldl(|(X, Y) -> X + Y|, 0, [1,2,3,4]) P.S., nobody jumped on my for using foreach({erlang,'+'}, ...). Has Uppsala lost 'net connectivity? :-) -Luke From richardc@REDACTED Fri Mar 26 16:08:51 2004 From: richardc@REDACTED (Richard Carlsson) Date: Fri, 26 Mar 2004 16:08:51 +0100 (MET) Subject: user-defined operators In-Reply-To: References: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> <69C519C4-7EB4-11D8-B19C-000A95D9A520@wideopenwest.com> Message-ID: On Fri, 26 Mar 2004, Luke Gorrie wrote: > P.S., nobody jumped on my for using foreach({erlang,'+'}, ...). Has > Uppsala lost 'net connectivity? :-) Ha ha! No, I was tempted, but in the end I didn't bite. ;-) /Richard Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From sean.hinde@REDACTED Fri Mar 26 19:05:06 2004 From: sean.hinde@REDACTED (Sean Hinde) Date: Fri, 26 Mar 2004 18:05:06 +0000 Subject: Erlang Radius server? In-Reply-To: <40629542.9090800@nortelnetworks.com> References: <40629542.9090800@nortelnetworks.com> Message-ID: <1C9CC3B8-7F50-11D8-9E16-000A95927CCE@mac.com> Hi all, On 25 Mar 2004, at 08:16, Torbj?rn T?rnkvist wrote: > Edmund Dengler wrote: > >> Howdy all! >> >> After having loads of fun dealing with FreeRadius/OpenRadius, I >> thought >> that there must be a better way of doing this type of work. So I got >> to >> wondering, has anybody looked at doing an Erlang Radius server? Not >> sure >> of the performance issues, but I think fundamentally there is nothing >> that >> should stop this (other than integration issues with LDAP and such). >> I had >> a quick look at jungerl and the Erlang projects page, but nothing >> appears. >> >> Regards! >> Ed >> > As Ulf already pointed out: you'll find eradius in the jungerl CVS. > However, it doesn't implement a Radius server (yet...), only the > client part. > > So feel free to add a Radius server to it Well, I felt it was about time I put something into the jungerl. Just checked in eradius_server with an example implementation module which does PAP and CHAP authentication. Enjoy! Sean From mlogan@REDACTED Fri Mar 26 22:58:16 2004 From: mlogan@REDACTED (Martin J. Logan) Date: 26 Mar 2004 15:58:16 -0600 Subject: user-defined operators In-Reply-To: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> References: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> Message-ID: <1080338296.2114.586.camel@dhcp-lom-194-186.futuresource.com> On Thu, 2004-03-25 at 16:36, Richard A. O'Keefe wrote: > I'm seeing a certain amount of scaremongering in this thread. > > First, the thread is about user-defined operators, NOT about > operator overloading. They are part in parcel. ad-hoc polymorphism, overloading, user defined operators are all the same in this context. If the language supports polymorphic functions then it is reasonable to assume that the addition of operators based on those very functions would support the same polymorphic attributes. > Whatever the merits and pitfalls of > operating overloading, they are not relevant to the topic of > user defined operators. > > Second, most functional languages have supported user defined > operators for years. ML has them. Haskell has them. Clean > has them. Prolog has them. Mercury has them. Many of these also include operator overloading(Haskell). > > *DO* you in fact get a welter of confusing operators? > > NO. What about this? It does not seem to me that > n `sm` primes > seconds `d` 60 > fromInteger big `aTf` x > expr `catch` handler > are particularly hard to read. Which I agree is no worse than sm(n, primes) d(seconds, 60) How about this? N `@#` Primes Seconds `@#` 60 MoreSeconds `@#` (Seconds `@#` String `@#` String2) I want my `operator` to be defined as such. '@#'(A, B) when is_integer(A), is_list(B) -> ... '@#'(A, B) when is_integer(A), is_integer(B) -> ... '@#'(A, B) when is_list(A), is_list(B) -> ... I am sure one could come up with some mangled syntax for restricting this. We could also conjure up a way to define precedence by user defined precedence number or some such. I am not trying to be polemic here but it honestly scares me. Martin > > In part this is because operators can only have one or two arguments, > while functions and predicates commonly need more. > > Haskell has two kinds of operators: alphabetic ones (which must always > be enclosed in backquotes) and symbolic ones (which may never be > enclosed in backquotes). So in Haskell `elem` is a alphabetic operator > and `!!` is not legal syntax at all. > > Operators are declared using > infix [Prec] op... > infixl [Prec] op... > infixr [Prec] op... > where Prec is a decimal digit. A symbolic operator may only be used if > it has been declared. An alphabetic operator has the weakest precedence > unless it is explicitly declared. > > Now alphabetic operators (especially if they all have the same precedence, > as they used to in Haskell) are no harder to read than any other function > name, and no more subject to overloading. (Each operator/function in > Haskell has precisely one meaning in scope.) > > > As for the idea that some group of experts should determine a set of > operators for Erlang, well, (a) they already did, and (b) if the > experts who designed Haskell came up with gems like $! and :% (actually, > once you know the rule that a symbolic operator starting with a colon > must be a constructor, it's not that hard to figure out what :% does), > what reason is there to expect the Erlang experts to do any better? > > The important thing about !! is not that it is spelled bang-bang, but > that it is a concise notation for doing a remote procedure call. > > Suppose that alphabetic operators *only* were adopted, so that any > Erlang user could use any two-argument function as an infix operator. > Instead of > > Result = Pid !! Message > > we'd have to write > > Result = Pid `rpc` Message > > which is three characters longer but 100% clearer. > > I note that Fortran has had user-defined operators for a while now; > the syntax is , so the Fortran equivalent might be > > Result = Pid .RPC. Message > > I haven't heard anything about an explosion of unreadability in Fortran > since this addition was made; maybe using words as operators really isn't > any worse than using words as function names. From enewhuis@REDACTED Fri Mar 26 23:18:21 2004 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 26 Mar 2004 16:18:21 -0600 Subject: user-defined operators In-Reply-To: <1080338296.2114.586.camel@dhcp-lom-194-186.futuresource.com> References: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> <1080338296.2114.586.camel@dhcp-lom-194-186.futuresource.com> Message-ID: <7DE32871-7F73-11D8-B6B5-000A95D9A520@futuresource.com> This is orthogonal to user-defined operators. One can already define confusing function names. Consider: dbg:ctpg(gq, x, 1) is no less confusing than {gq, x, 1} `@#` Blah. > How about this? > > N `@#` Primes > Seconds `@#` 60 > MoreSeconds `@#` (Seconds `@#` String `@#` String2) > > I want my `operator` to be defined as such. > > '@#'(A, B) when is_integer(A), is_list(B) -> ... > '@#'(A, B) when is_integer(A), is_integer(B) -> ... > '@#'(A, B) when is_list(A), is_list(B) -> ... From mlogan@REDACTED Fri Mar 26 23:34:55 2004 From: mlogan@REDACTED (Martin J. Logan) Date: 26 Mar 2004 16:34:55 -0600 Subject: user-defined operators In-Reply-To: <7DE32871-7F73-11D8-B6B5-000A95D9A520@futuresource.com> References: <200403252236.i2PMaWUe365766@atlas.otago.ac.nz> <1080338296.2114.586.camel@dhcp-lom-194-186.futuresource.com> <7DE32871-7F73-11D8-B6B5-000A95D9A520@futuresource.com> Message-ID: <1080340494.2114.590.camel@dhcp-lom-194-186.futuresource.com> On Fri, 2004-03-26 at 16:18, Eric Newhuis wrote: > This is orthogonal to user-defined operators. > > One can already define confusing function names. Consider: > > dbg:ctpg(gq, x, 1) is no less confusing than {gq, x, 1} `@#` Blah. I am just getting at the fact that if you have polymorphic functions and you define your operators based on those functions then you naturally have operator overloading. When you have overloading you have the potential for the mess below. | Which I would argue is worse. \/ > > > > How about this? > > > > N `@#` Primes > > Seconds `@#` 60 > > MoreSeconds `@#` (Seconds `@#` String `@#` String2) > > > > I want my `operator` to be defined as such. > > > > '@#'(A, B) when is_integer(A), is_list(B) -> ... > > '@#'(A, B) when is_integer(A), is_integer(B) -> ... > > '@#'(A, B) when is_list(A), is_list(B) -> ... From marc.vanwoerkom@REDACTED Sat Mar 27 00:56:19 2004 From: marc.vanwoerkom@REDACTED (Marc van Woerkom) Date: Sat, 27 Mar 2004 00:56:19 +0100 Subject: ICFP Contest Dates In-Reply-To: References: Message-ID: The preliminary date is below! Anyone willing to form an Erlang team? Regards, Marc ------- Forwarded message ------- From: "Geoffrey A. Washburn" To: icfp04-participants@REDACTED Subject: [Icfp04-participants] ICFP Dates Date: Thu, 25 Mar 2004 17:31:57 -0500 (EST) It looks like the contest dates will be: Friday, June 4, noon (US Eastern time) to Monday, June 7, noon (US Eastern time). Everybody mark your calendars! The web site will be updated with this information soon, and more information will follow after we finish scrambling to finish our ICFP paper submissions. From ok@REDACTED Mon Mar 29 05:30:11 2004 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 29 Mar 2004 15:30:11 +1200 (NZST) Subject: user-defined operators Message-ID: <200403290330.i2T3UBLX431640@atlas.otago.ac.nz> I wrote: > First, the thread is about user-defined operators, NOT about > operator overloading. "Martin J. Logan" wrote: They are part in parcel. ad-hoc polymorphism, overloading, user defined operators are all the same in this context. user-defined operators are *completely orthogonal* to overloading. If the language supports polymorphic functions then it is reasonable to assume that the addition of operators based on those very functions would support the same polymorphic attributes. This makes user-defined operators IN NO WAY DIFFERENT from other user-defined function names. > Second, most functional languages have supported user defined > operators for years. ML has them. Haskell has them. Clean > has them. Prolog has them. Mercury has them. Many of these also include operator overloading(Haskell). No. Haskell does *not* include operator overloading. At any point in a Haskell program, there is AT MOST ONE definition in scope for any function name or operator name. Haskell operators are IN NO WAY DIFFERENT from other Haskell function names. Haskell does have a system of "type classes" where you write e.g., class Fee x where goo :: x -> Int goo _ = 42 and you can override the definition, BUT NOT THE SIGNATURE, in a subclass: class Fee x => Fie x where goo _ = 137 However, you are NOT allowed to also have class Foe x where goo :: x -> String goo _ = "zero" So in Haskell every operator name and every function name has a unique definition point where its signature is either explicit or inferred from a definition, and that signature applies consistently with no ad hoc overloading. I know that the Haskell report uses the word "overloading", but it is *not* the kind of ad-hoc overloading you find in Algol 68, C++, PL/I, and Fortran, which is multiple unrelated definitions with different signatures. Note that my example (where goo x = 42 sometimes and goo x = 127 other times, depending on the type of x) does NOT involve an operator, although it could have. Operator syntax and overloading are orthognoal concepts. > *DO* you in fact get a welter of confusing operators? > > NO. What about this? It does not seem to me that > n `sm` primes > seconds `d` 60 > fromInteger big `aTf` x > expr `catch` handler > are particularly hard to read. Which I agree is no worse than sm(n, primes) d(seconds, 60) Exactly so: adding backquotes doesn't make the names any worse. How about this? N `@#` Primes Seconds `@#` 60 MoreSeconds `@#` (Seconds `@#` String `@#` String2) As I have said before, `@#` is NOT A LEGAL OPERATOR IN HASKELL. Backquoted operator names *must* be ordinary function names; backquotes in Haskell are NOT like ordinary quotes in Erlang, and there is no reason why backquotes, should they ever be adopted, should be like ordinary quotes in Erlang either. I want my `operator` to be defined as such. '@#'(A, B) when is_integer(A), is_list(B) -> ... '@#'(A, B) when is_integer(A), is_integer(B) -> ... '@#'(A, B) when is_list(A), is_list(B) -> ... Your examples are bad because (a) '@#' is not mnemonic (but I have recommended that such operators *not* be allowed in backquote form) and (b) the single (not overloaded! the name is resolved to a unique definition) definition of '@#' does strange things. The use of operator notation as such is quite irrelevant: '@#'(N, Primes) '@#'(Seconds, 60) '@#'(MoreSeconds,'@#'('@#'(Seconds,String),String)) are perfectly possible right now in Erlang. I am sure one could come up with some mangled syntax for restricting this. Haskell syntax is not mangled, and it says quite plainly that the thing between backquotes must be an ordinary function name. I have an unfinished preprocessor that gives Erlang a Haskell-like appearance. It includes backquotes, and nothing bad happens to the syntax rules. You might well come back and say that N `hic` Primes Seconds `hic` 60 MoreSeconds `hic` (Seconds `hic` String `hic` String2)) We could also conjure up a way to define precedence by user defined precedence number or some such. Again, we don't have to conjure anything up. It has been done before. It works brilliantly in practice. In the absence of any declaration to the contrary, `foo` has weakest precedence and left associativity in Haskell. If memory serves me, ".FOO." has weakest precedence and no associativity in Fortran. I am not trying to be polemic here but it honestly scares me. You are scared by a boggart that is entirely of your own imagination. The proposal under discussion is (1) where is an unquoted identifier or variable name should be an Erlang operator of weakest precedence and either left associativity or no associativity (2) E1 `f` E2 should be equivalent to f(E1, E2). This introduces *no* new kind of overloading to Erlang. It introduces *no* new kinds of unreadable spelling to Erlang. In particular !! would have to be written `rpc`, not `!!`, and `@#` would still not be an operator, although '@#' would still be a function name. I'm tired of scaremongering about how bad things *could* get, when Haskell and Fortran experience shows that they *don't* get bad, and when they *can't* get bad in some of the alleged ways. From jamesh@REDACTED Mon Mar 29 17:11:40 2004 From: jamesh@REDACTED (James Hague) Date: Mon, 29 Mar 2004 09:11:40 -0600 Subject: user-defined operators Message-ID: > K: > +/1 2 3 4 5 > > Erlang: > lists:foldl (fun (X, A) -> X + A end, 0, [1, 2, 3, 4]). Well, in Erlang you can just use lists:sum([1,2,3,4]). As much as I admire the Heaviside operators of J and K, I have to admit that hardcoding versions for a handful of operators covers most of the same territory. What I *would* like to see in Erlang (and I have brought this up before, to the chagrin of many), is to extend basic math operators to work on tuples. That is: {1,2,3} + {4,5,6} returns {5,7,9} 1 + {2,4,6} returns {5,6,7} {2,4,6} + 1 returns {5,6,7} -{1,2,3} returns {-1,-2,-3} This is simple, concise, and natural. It also enables faster numeric work in Erlang, not that this is a primary goal. It should not be extended to [1,2,3] + [4,5,6], as lists are not atomic like tuples. Unlike most other proposals, this could be implemented by changing a few functions in erl_arith.c. Some warnings would need to be disabled in the compiler, were this made official. One point of debate: whether to allow nested tuples. I would say no, as this starts leading to confusing agreement rules. A related and more complex change--which I'm not proposing--is to special-case tuples of floats, to avoid heap allocating each individual float. This is what OCaml does. But doing this in Erlang would be messier. From jamesh@REDACTED Mon Mar 29 17:32:46 2004 From: jamesh@REDACTED (James Hague) Date: Mon, 29 Mar 2004 09:32:46 -0600 Subject: user-defined operators Message-ID: I wrote: > 1 + {2,4,6} returns {5,6,7} > {2,4,6} + 1 returns {5,6,7} Obviously these should return {3,5,7} :) >One point of debate: whether to allow >nested tuples. I would say no, as this >starts leading to confusing agreement rules. Let me clarify my stance by emphatically disallowing nested tuples. As in K, Erlang already provides the tools to deal with recursive structures. From mlogan@REDACTED Mon Mar 29 20:32:25 2004 From: mlogan@REDACTED (Martin J. Logan) Date: 29 Mar 2004 12:32:25 -0600 Subject: user-defined operators In-Reply-To: <200403290330.i2T3UBLX431640@atlas.otago.ac.nz> References: <200403290330.i2T3UBLX431640@atlas.otago.ac.nz> Message-ID: <1080585144.18606.90.camel@dhcp-lom-194-186.futuresource.com> The definition of operator overloading is: "Use of a single symbol to represent operators with different argument types" i.e one operator is overloaded to handle two strings or two integers irrespective of where the operator is defined or how many times it is defined separately. It follows that if you have polymorphic functions and you base your user defined operators on those functions then you can do the same thing with operators as you can with functions, namely overload then to handle different "types" i.e perform a different operation with with two strings vs two integers etc... It is understood that user defined operators are orthogonal to operator overloading in strict sense. Again though if you allow user defined operators to be based on polymorphic functions then you ARE allowing overloaded operators. In my years of programming I have come to expect that one must read a function before understanding what it does is many cases. I typically do not research what the * operator does really thoroughly though. I simply don't want to see `*` in code that concatenates strings or multiplies two floats producing a rounded integer. Erlang is readable and effective, adding user defined operators does little to increase the expressive power of the language and goes one step in decreasing its simplicity. Many people like Joes !! operator because it is more in keeping with the theme and syntax of erlang than a function call to do the same. They do not advocate it just because it is an operator. If you want to restrict !! to `rpc` then all you are really arguing for is to add a strangely restrictive infix erlang function calling syntax. I can't figure out how that benefits anyone. We are trained through the mathematics we took in school to use non-alphanumeric symbols as operators and that is just what we shall do when we get to make up our own. If I want to deal with refactoring peoples code that looks like a bunch of cryptic symbols between strings and numbers where the symbols do different things depending, then ... well I don't want to deal with code like that so I will put my vote in for only having to deal with cryptic functions from time to time and for keeping things just the way they are. Cheers, Martin On Sun, 2004-03-28 at 21:30, Richard A. O'Keefe wrote: > I wrote: > > First, the thread is about user-defined operators, NOT about > > operator overloading. > > "Martin J. Logan" wrote: > They are part in parcel. ad-hoc polymorphism, overloading, user defined > operators are all the same in this context. > > user-defined operators are *completely orthogonal* to overloading. > > If the language supports polymorphic functions then it is > reasonable to assume that the addition of operators based on > those very functions would support the same polymorphic > attributes. > > This makes user-defined operators IN NO WAY DIFFERENT from other > user-defined function names. > > > Second, most functional languages have supported user defined > > operators for years. ML has them. Haskell has them. Clean > > has them. Prolog has them. Mercury has them. > > Many of these also include operator overloading(Haskell). > > No. Haskell does *not* include operator overloading. At any point in > a Haskell program, there is AT MOST ONE definition in scope for any > function name or operator name. Haskell operators are IN NO WAY DIFFERENT > from other Haskell function names. Haskell does have a system of > "type classes" where you write e.g., > > class Fee x where > goo :: x -> Int > goo _ = 42 > > and you can override the definition, BUT NOT THE SIGNATURE, in a subclass: > > class Fee x => Fie x where > goo _ = 137 > > However, you are NOT allowed to also have > > class Foe x where > goo :: x -> String > goo _ = "zero" > > So in Haskell every operator name and every function name has a unique > definition point where its signature is either explicit or inferred from > a definition, and that signature applies consistently with no ad hoc > overloading. > > I know that the Haskell report uses the word "overloading", but it is > *not* the kind of ad-hoc overloading you find in Algol 68, C++, PL/I, > and Fortran, which is multiple unrelated definitions with different > signatures. > > Note that my example (where goo x = 42 sometimes and goo x = 127 other > times, depending on the type of x) does NOT involve an operator, although > it could have. > > Operator syntax and overloading are orthognoal concepts. > > > *DO* you in fact get a welter of confusing operators? > > > > NO. > > What about this? > > It does not seem to me that > > n `sm` primes > > seconds `d` 60 > > fromInteger big `aTf` x > > expr `catch` handler > > are particularly hard to read. > > Which I agree is no worse than > > sm(n, primes) > d(seconds, 60) > > Exactly so: adding backquotes doesn't make the names any worse. > > How about this? > > N `@#` Primes > Seconds `@#` 60 > MoreSeconds `@#` (Seconds `@#` String `@#` String2) > > As I have said before, `@#` is NOT A LEGAL OPERATOR IN HASKELL. > Backquoted operator names *must* be ordinary function names; backquotes > in Haskell are NOT like ordinary quotes in Erlang, and there is no reason > why backquotes, should they ever be adopted, should be like ordinary > quotes in Erlang either. > > I want my `operator` to be defined as such. > > '@#'(A, B) when is_integer(A), is_list(B) -> ... > '@#'(A, B) when is_integer(A), is_integer(B) -> ... > '@#'(A, B) when is_list(A), is_list(B) -> ... > > Your examples are bad because (a) '@#' is not mnemonic (but I have > recommended that such operators *not* be allowed in backquote form) > and (b) the single (not overloaded! the name is resolved to a unique > definition) definition of '@#' does strange things. The use of > operator notation as such is quite irrelevant: > > '@#'(N, Primes) > '@#'(Seconds, 60) > '@#'(MoreSeconds,'@#'('@#'(Seconds,String),String)) > > are perfectly possible right now in Erlang. > > I am sure one could come up with some mangled syntax for restricting > this. > > Haskell syntax is not mangled, and it says quite plainly that the thing > between backquotes must be an ordinary function name. I have an unfinished > preprocessor that gives Erlang a Haskell-like appearance. It includes > backquotes, and nothing bad happens to the syntax rules. > > You might well come back and say that > > > N `hic` Primes > Seconds `hic` 60 > MoreSeconds `hic` (Seconds `hic` String `hic` String2)) > > We could also conjure up a way to define precedence by user > defined precedence number or some such. > > Again, we don't have to conjure anything up. It has been done before. > It works brilliantly in practice. In the absence of any declaration > to the contrary, `foo` has weakest precedence and left associativity > in Haskell. If memory serves me, ".FOO." has weakest precedence and > no associativity in Fortran. > > I am not trying to be polemic here but it honestly scares me. > > You are scared by a boggart that is entirely of your own imagination. > > The proposal under discussion is > > (1) > where is an unquoted identifier or variable name > should be an Erlang operator of weakest precedence > and either left associativity or no associativity > (2) E1 `f` E2 should be equivalent to f(E1, E2). > > This introduces *no* new kind of overloading to Erlang. > It introduces *no* new kinds of unreadable spelling to Erlang. > In particular !! would have to be written `rpc`, not `!!`, > and `@#` would still not be an operator, although '@#' would still > be a function name. > > I'm tired of scaremongering about how bad things *could* get, when > Haskell and Fortran experience shows that they *don't* get bad, and > when they *can't* get bad in some of the alleged ways. From klacke@REDACTED Mon Mar 29 21:17:46 2004 From: klacke@REDACTED (klacke@REDACTED) Date: Mon, 29 Mar 2004 21:17:46 +0200 Subject: Erlang Radius server? In-Reply-To: References: <40629542.9090800@nortelnetworks.com> Message-ID: <20040329191746.GA3478@hyber.org> On Thu, Mar 25, 2004 at 09:49:23AM +0000, Sean Hinde wrote: > > On 25 Mar 2004, at 08:16, Torbj?rn T?rnkvist wrote: > > >Edmund Dengler wrote: > > > >>Howdy all! > >> > >>After having loads of fun dealing with FreeRadius/OpenRadius, I > >>thought > >>that there must be a better way of doing this type of work. So I got > >>to > >>wondering, has anybody looked at doing an Erlang Radius server? Not I did some time ago, I though we had to terminate radius/EAP requsts but luckily ... we didn't (yet) It would be a massive task to implement radius+eap. > >>sure > >>of the performance issues, but I think fundamentally there is nothing > >>that > >>should stop this (other than integration issues with LDAP and such). Performance wise it would probably rock. I know of no other technology that would be better suited for a high performance, high load radius server. > > I just got round to looking at eradius and it looks very nice indeed. > We have a RADIUS server, but I would describe it as a 1 week job - very > targetted minimal implementation. > > eradius has all the nice dictionary framework, packet encoding etc to > build a nice generic server so looks to me an excellent starting point > - most of the hard work has been done. > Nice move, it will require quite a bit of work to get even near 10 % of freeradius functionality though. It does everything. It's horribly hard to configure though. /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From ok@REDACTED Tue Mar 30 08:17:28 2004 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 30 Mar 2004 18:17:28 +1200 (NZST) Subject: user-defined operators Message-ID: <200403300617.i2U6HShx456377@atlas.otago.ac.nz> "Martin J. Logan" is still arguing, though I'm not sure why. The definition of operator overloading is: "Use of a single symbol to represent operators with different argument types" i.e one operator is overloaded to handle two strings or two integers irrespective of where the operator is defined or how many times it is defined separately. That's not "THE" definition. It may be YOUR definition. By the definition I use, a symbol which is bound to a single definition is not overloaded, no matter how many types that definition applies to. Let me quote a famous compiler textbook (exercise for the reader: which book?): p330: An "overloaded" identifier can have a set of possible types. [They really mean "signatures", and really.] p334: A symbol that can represent different OPERATIONS in different contexts is said to be "overloaded". [This is the "multiple definitions in scope at once" definition I used, and is different from the one on p330]. Overloading may be accompanies by coercion of types. p344: A DISTINCT NOTION from overloading is that of "polymorphism". It invites confusion to talk about types in this context, because Erlang doesn't have them. A function like f(X, Y) when integer(X), integer(Y) -> X + Y; f(X, Y) when list(X), list(Y) -> X ++ Y. is a *single* definition which reacts differently to different run-time values, just like f(X, Y) when X >= 0, Y >= 0 -> X + Y; f(X, Y) when X < 0, Y < 0 -> X * Y. is a single definition which reacts differently to different run-time values. In neither case is f a particularly easy function to understand, but in neither case can you blame this on overloading, because neither of these f/2 definitions is overloaded. Note also that the fact that f is confusing is due solely to the function it computes; it is NOT due to the fact that it's an operator. (Because at the moment, it ISN'T an operator.) Do I really have to stress this elementary point again? An operator which is confusing because it is bound to a function that has a confusing definition is not confusing because it is an operator but because the function that defines it is confusing; using it as an operator does not introduce ANY kind of polymorphism that is not already present or ANY kind of overloading that is not already present. Adding user-defined operators to Erlang WOULD NOT AND COULD NOT introduce any kind of polymorphism or overloading that Erlang doesn't already have. If you don't like those kinds of polymorphism or overloading or witchcraft or whatever you call it, blame EXISTING Erlang for that, not operators. It follows that if you have polymorphic functions and you base your user defined operators on those functions then you can do the same thing with operators as you can with functions, namely overload then to handle different "types" i.e perform a different operation with with two strings vs two integers etc... Aside from the nonstandard use of terms here, yes. However, the important thing is that whether a name is used with backquotes or without, it still must resolve to a single definition, and that definition will *BE* a perfectly ordinary Erlang function. If you want to call the function bad names, go ahead, but that is no argument against operators. It might perhaps be an argument against a dynamically typed language, but then, if you want Mercury, you know where to find it. It is understood that user defined operators are orthogonal to operator overloading in strict sense. Right. So why all this nonsense about overloaded operators? Again though if you allow user defined operators to be based on polymorphic functions then you ARE allowing overloaded operators. No. Not at allo. I repeat, "A symbol that can represent DIFFERENT OPERATIONS" (famous book, page 344) is one that is overloaded. A symbol that can only represent one operation is not overloaded. Nobody goes around slagging off Erlang for having "overloaded functions", but it is the *functions* that are issue, not the operators. In my years of programming I have come to expect that one must read a function before understanding what it does is many cases. Right. With you 90%. AND IT DOES NOT MATTER WHETHER THAT FUNCTION IS CALLED USING OPERATOR SYNTAX OR NOT, you have to read the function's documentation (ideally, NOT the function itself) to find out what it is supposed to do. I typically do not research what the * operator does really thoroughly though. Don't you? Heck, it's the second thing I do when learning a new language. Step 1: what are the basic data types. Step 2: what are the built in operations. I must have spent hours studying the Fortran standard's built-in operators, ditto Erlang's. I simply don't want to see `*` in code that concatenates strings or multiplies two floats producing a rounded integer. IT CAN'T HAPPEN. The proposal we're discussing DOES NOT ALLOW new definitions for existing operators. Since there already *is* a '*' operator, you cannot define a new one. (In fact, with the proposal as I have it, you couldn't do this for another reason: `*` would not be a legal operator name in any case.) Erlang is readable and effective, adding user defined operators does little to increase the expressive power of the language and goes one step in decreasing its simplicity. Having used several languages with user-defined operators, I have to disagree strongly. User-defined operators (especially alphabetic ones) can dramatically improve the readability of code. They have absolutely no effect on the *semantic* simplicity of a language, and only trivial effect on the *syntactic* simplicity (one extra grammar rule). I *also* admit that user-defined operators can be used to excess, but what can't? Many people like Joes !! operator because it is more in keeping with the theme and syntax of erlang than a function call to do the same. Well, Joe is the principal inventor of the language. If anyone has a coherent view of the essence of Erlang, he does. Mortal that I am, I dare to disagree. I view !! as a wart. Not because it is a new operator. I _like_ new operators. Not because it's not in keeping with the syntax of Erlang; it is, although it is just a BIG a change to the syntax of Erlang as adding user-defined operators would be, for much less gain. Not because it's overloaded, although for someone who attacks user-defined operators in general on the (groundless) basis of "overloading", it's rather inconsistent to praise "!!". To quote the "conceptual integrity" slides (slide 3), in A!!B A can be a Pid, or a string, or a list of Pids and strings. and that is precisely the kind of overloading that Martin J. Logan is so hot against. It's quite a nasty kind, because strings *are* lists. (The slides hint that a string is a file name; the examples suggest that it may be any URI.) In fact there's a seriously weird kind of URI, "erl://"++Node++"/"++Name !! X means to do Name!!X on Node. We're told that "erl://www.sics.se/home/joe/foo" !! read should have the same effect as "/home/joe/foo" !! read on www.sics.se; but the text at the top of slide 7 suggests that it should have the same effect as "home/joe/foo" !! read (note the absence of the initial slash). As for using "/dev/spawn" !! Fun, this is overloading with a vengeance. I seem to be a bit inconsistent myself. Not really. I *DON'T* say that !! is overloaded. I *do* say that it does radically different things depending on the run-time type of its argument AND on the exact run-time value of its argument ("/dev/spawn" !! X and "/dev/stdin" !! X do not seem to have any meaningful X in common). This means that if I see (Provider !! Message) then I have no idea what it is about until I have traced in some detail what the possible values of Provider and Message might be. If I can't tell whether it is is spawning a new process, sending a message to an existing process, doing an FTP access, deleting a file, or firing an intercontinental missing without detailed data flow analysis, what are the odds that any plausible tool will help me? (Since the HTTP protocol does have PUT (RFC 2068 section 9.6), I don't know why slide 9 says '"http://..." read only files'. Nor is it clear to me how "/dev/videoplayer" is supposed to be hooked up to showmetv.) They do not advocate it just because it is an operator. Nobody ever said they did. The question was WHAT IS THE SMALLEST CHANGE TO ERLANG THAT WOULD ALLOW PEOPLE TO EXPERIMENT WITH NEW OPERATORS WITHOUT HAVING TO HACK THE COMPILER SOURCES. For what it's worth, I don't feel queasy about !! because it is an operator, but because the definition basically boils down to "something does something somewhere with something", which isn't very helpful. To get an idea of just *how* unpredictable "!!" can be, look at slide 11. There we see that something that _looks_ like a file name can actually be registered as doing something else, so just because on one rare occasion I can see "/dev/null" !! {write,X} I *still* have no idea what it does, because "/dev/null" could be the registered name of a process that interprets {write,X} as "send X as spam to 240 million people". In short, the claimn on slide 12 "easier to understand" does not seem to me to be justified. Not because of what people *might* do with !!, but because of what the designer *has* done with !! in those very slides. If you want to restrict !! to `rpc` then all you are really arguing for is to add a strangely restrictive infix erlang function calling syntax. I can't figure out how that benefits anyone. Then I guess you haven't been paying attention. First off, there is nothing "strangely restrictive" here. Erlang operators all have one or two arguments. Therefore if a function is to be called using operator syntax, it must have one or two arguments. (Someone else had the idea of allowing prefix unary user-defined operators. It makes sense; it's easy to handle; let's do it.) That is, it is not in the least restrictive for functions where you would *want* to use it. Most important, the argument is that user-defined operators have PROVEN THEMSELVES IN PRACTICE in several languages. Erlang is almost alone amongst functional languages in not allowing them. They really do provide a welcome increase in readability *some of the time*. We are trained through the mathematics we took in school to use non-alphanumeric symbols as operators and that is just what we shall do when we get to make up our own. I'm sorry that you think Erlang is so bad. Look at the following list of operators, culled from the 5.3 reference manual: Familiar from school: = < > + - Not familiar from school: * (should be x) / (should be -:-) == /= =< >= =:= =/= ++ -- : # ! Not familiar from school and alphabetic: bnot div rem band bor bxor bsl bsr not and or xor orelse andalso catch 5+13+15 If familiarity from school were a tolerable criterion for what should be allowed as an operator, only 5 of Erlang's 33 operators would be allowed. If "non-alphanumeric symbols" were a tolerable criterion for what should be allowed as an operator, nearly half (15) of Erlang's existing operators would be forbidden. In short, this diktat is definitely NOT "in keeping with the theme and syntax of Erlang". The Erlang designers rejected it entirely, as do I. If I want to deal with refactoring peoples code that looks like a bunch of cryptic symbols between strings and numbers where the symbols do different things depending, then ... well I don't want to deal with code like that so I will put my vote in for only having to deal with cryptic functions from time to time and for keeping things just the way they are. I can only characterise this as scaremongering. The proposal I'm arguing for *FORBIDS* "cryptic symbols" as operator names. And operators would not and could not "do different things depending" to any greater extent than Erlang functions already can and do. Allowing alphameric function names to be used as operators wouldn't make Erlang in no way harder to read or maintain, and it really is *not* good enough to make wild statements saying that they could. I repeat: > I'm tired of scaremongering about how bad things *could* get, when > Haskell and Fortran experience shows that they *don't* get bad, and > when they *can't* get bad in some of the alleged ways. From samuel@REDACTED Tue Mar 30 09:38:37 2004 From: samuel@REDACTED (Samuel Rivas) Date: Tue, 30 Mar 2004 09:38:37 +0200 Subject: user-defined operators In-Reply-To: <200403300617.i2U6HShx456377@atlas.otago.ac.nz> References: <200403300617.i2U6HShx456377@atlas.otago.ac.nz> Message-ID: <20040330073837.GA11992@crusher.lfcia.pri> Richard A. O'Keefe wrote: > By the definition I use, a symbol which is bound to a single definition > is not overloaded, no matter how many types that definition applies to. > > Let me quote a famous compiler textbook (exercise for the reader: > which book?): > > p330: An "overloaded" identifier can have a set of possible > types. [They really mean "signatures", and really.] > p334: A symbol that can represent different OPERATIONS in > different contexts is said to be "overloaded". > [This is the "multiple definitions in scope at once" > definition I used, and is different from the one on > p330]. Overloading may be accompanies by coercion > of types. > p344: A DISTINCT NOTION from overloading is that of > "polymorphism". > > It invites confusion to talk about types in this context, because > Erlang doesn't have them. A function like > > f(X, Y) when integer(X), integer(Y) -> X + Y; > f(X, Y) when list(X), list(Y) -> X ++ Y. > > is a *single* definition which reacts differently to different > run-time values, just like > > f(X, Y) when X >= 0, Y >= 0 -> X + Y; > f(X, Y) when X < 0, Y < 0 -> X * Y. > As you stress, a symbol that can represent different operations in different contexts is said to be "overloaded". + ++ and * are DIFFERENT operations, your definition says nothing about using the same function name to indicate those operations. > An operator which is confusing because it is bound to a function > that has a confusing definition is not confusing because it is an > operator but because the function that defines it is confusing; > using it as an operator does not introduce ANY kind of polymorphism > that is not already present or ANY kind of overloading that is not > already present. You are not adding more polymorphism or overloading, you are mapping the problems of functions to the operators. Currently you can have confusing functions, but the set of operators is well defined and (more or less) widely accepted (I really don't like the ++ operator since it's just the same as lists:concatenate and you have to know it because of optimisation issues). > Adding user-defined operators to Erlang WOULD NOT AND COULD NOT > introduce any kind of polymorphism or overloading that Erlang doesn't > already have. If you don't like those kinds of polymorphism or > overloading or witchcraft or whatever you call it, blame EXISTING > Erlang for that, not operators. IMO, you need the operators to represent some actions you cannot easily write in the language. With those operator and other functions you can write more functions. So functions are bound to programmers skills to do them readable. Operators do not, unless you allow user defined operators. That's why I think you are introducing more confusing to the language. > Having used several languages with user-defined operators, I have to > disagree strongly. User-defined operators (especially alphabetic > ones) can dramatically improve the readability of code. They have > absolutely no effect on the *semantic* simplicity of a language, > and only trivial effect on the *syntactic* simplicity (one extra > grammar rule). Perhaps is a matter of taste, but I don't think the use of user-defined operators (neither alphabetic or non-alphanumeric) improve the readability of the code. Infix notation is ambiguous and we only use it for historic reasons. So if programmers have become used to use function(argA, argB) instead of argA function argB I don't see why to return to the imperfect notation. > Not familiar from school: > * (should be x) / (should be -:-) Why / should be -:-? (just curious) Best regards. -- --------------------- | Samuel | --------------------- From erlang@REDACTED Tue Mar 30 11:01:54 2004 From: erlang@REDACTED (erlang@REDACTED) Date: Tue, 30 Mar 2004 10:01:54 +0100 Subject: user-defined operators In-Reply-To: <20040330073837.GA11992@crusher.lfcia.pri> Message-ID: > Samuel Rivas wrote: > Richard A. O'Keefe wrote: >> Not familiar from school: >> * (should be x) / (should be -:-) > Why / should be -:-? (just curious) I think that is meant to be ascii art for ? (a colon with a dash through it or two dots straddling a line if you like). Robby From dhanasekaran.c@REDACTED Thu Mar 25 09:29:56 2004 From: dhanasekaran.c@REDACTED (Chenniappan,Dhanasekaran [DBA]) Date: Thu, 25 Mar 2004 13:59:56 +0530 Subject: port problem Message-ID: <124AD2BD2C1FB245B2E4FF0E90AE0E32057EEF@ntserver.dbachn> Hi, We are using ERLANG for our Dialer Development. The dialer uses the Dialogic boards. The Dialogic boards has C APIs so we use Port = open_port({spawn, complex}, [{packet, 2}]), Port!{self(),1} loop(Port). in loop function loop(Port)-> receive ... end. In complex.exe for message 1(which was sent in Port!{self(),1}) We have the function for start the thread. In the thread the while (1) { if(sr_waitevt(30000) != -1) { event();/* Function for watch and return the dialogic events to ERLANG*/ strcpy(prnstr,"25"); for(i=0;i Hi All, We are using ERLANG emulator version 5.3. In this there is one option for open log file, it needs me to start every time I open the ERLANG environment. Is there any option to open it automatically when I start Erlang environment?. The .exe I use to open Erlang is ..\erl5.3\bin\werl.exe With Regards Dhanas This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From cb47@REDACTED Mon Mar 29 15:57:15 2004 From: cb47@REDACTED (Clara Benac Earle) Date: Mon, 29 Mar 2004 14:57:15 +0100 Subject: fault-tolerance Message-ID: <40682B3B.6060006@kent.ac.uk> Hi, I have written a simple client-server system in Erlang using the generic server behaviour. My system should recover gracefully when a client process dies. To do that I am using the supervsion tree behaviour for restarting the client process and the process_flag, link and handle_info primitives in the server to trap the exit signal from the client process and delete the information about the crashed process from the state of the server. Now, I am having difficulties to test my program. To test the fault tolerance all I am doing is to start pman and kill a process client and observe the messages I am printing on the screen. The other way I am testing it is by writing code in the client which will make the client die. In this way I have a better knowledge of at which point the client dies. However, none of this two ways of debugging is very satisfactory. I wanted to ask what people does for debugging fault-tolerant programs. Cheers, Clara This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. From ok@REDACTED Wed Mar 31 05:50:49 2004 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 31 Mar 2004 15:50:49 +1200 (NZST) Subject: user-defined operators Message-ID: <200403310350.i2V3on0I433115@atlas.otago.ac.nz> From ok@REDACTED Wed Mar 31 07:22:30 2004 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 31 Mar 2004 17:22:30 +1200 (NZST) Subject: user-defined operators Message-ID: <200403310522.i2V5MUYH470159@atlas.otago.ac.nz> I wrote: > By the definition I use, a symbol which is bound to a single definition > is not overloaded, no matter how many types that definition applies to. Samuel Rivas replied most confusingly: As you stress, a symbol that can represent different operations in different contexts is said to be "overloaded". + ++ and * are DIFFERENT operations, your definition says nothing about using the same function name to indicate those operations. Nor does it say anything about the Arian controversy, bimetallism, or the interpretation of quantum mechanics. Why should one little definition have to deal with quite irrelevant matters? In Erlang, +, ++, and * are bound to different definitions. There is no proposal in this or any other thread to change that. Erlang *already* permits the definition of a function which sometimes calls one, sometimes calls the other, of those operations. That function is nevertheless itself still ONE "operation". You are not adding more polymorphism or overloading, you are mapping the problems of functions to the operators. So what? What kind of mental deficiency could cause someone to have NO trouble with functions that can do different things depending on what their arguments are, but to suddenly fall all to pieces when it is an operator that does this? People seem to be arguing against user-defined operators on the grounds that operators have some kind of unique sacred character that makes them different from functions. But in EXISTING Erlang this is not so. Currently you can have confusing functions, but the set of operators is well defined and (more or less) widely accepted (I really don't like the ++ operator since it's just the same as lists:concatenate and you have to know it because of optimisation issues). I don't know what is meant by "widely accepted" here. It is, of course, accepted that the set of Erlang operators is what it is; since the language was first defined there can hardly ever have been a single day when it was widely accepted that it was what it should be. Right at the moment, Joe Armstrong has a proposal for an additional operator, !!, which is *not* well defined, at least on my reading of his slides. Once upon a time Erlang didn't have andalso or orelse. I myself am quite unhappy with the definition of / in Erlang at the moment; if I am doing floating-point arithmetic on an IEEE-conformant machine (which I am), I want IEEE-conformant arithmetic, not some sort of bastardised hybrid, which is what you get at the moment. There has been some disagreement about what (1 bsl 63) * 2 should mean. (Not about what it DOES mean, but about what it SHOULD mean.) Anyone who wants to pretend that + and * in Erlang do one and only one thing is living in fantasy land. And you cannot use Erlang for long without discovering that X!Y does different things depending on what X is. (Related things, yes. The same things, no.) Anyone who wants to claim that the sky will fall because user-defined operators will open up a can of worms that isn't *already* squirming over the edges of the tackle box is, well, let's be charitable, reading some other Erlang manual than the one I read. To judge the basic honesty of this argument, recall that the proposal in question is this: - the existing operators would remain with their present definitions EXACTLY (no changes at all) - no new operators of the present forms could be defined at all (anything that looks like a present Erlang operator *IS* a present Erlang operator with whatever properties one considers ideologically important) - the only new operators proposed are `id` Arg === id(Arg) Lhs `id` Rhs === id(Lhs, Rhs) where id can be any alphabetic atom or variable name, where it is directly and immediately obvious to the reader not only THAT a function call is involved but WHAT that call is. If you believe (contrary to the facts) that X * Y has some sacred property that f(X, Y) does not, then this proposal should leave you satisfied, because it still *will* have. Only X `f` Y will have whatever properties are presently peculiar to f(X, Y). IMO, you need the operators to represent some actions you cannot easily write in the language. There are no such actions for which OPERATORS are needed. Any such actions can be defined using function call syntax, and MOST such actions in Erlang are defined using function call syntax. Lisp is proof that operator syntax is not needed. Note, by the way, the following actual example: ... 10> F = {erlang,'+'}, F(1, 2). 3 ... 12> erlang:'+'(1, 2). 3 13> erlang:'bsl'(1,63). 9223372036854775808 ... Or this module: -module(foo). -export([foo/2, bar/0, ugh/1]). foo(X, Y) -> erlang:'+'(X,Y). ugh(Receiver) -> erlang:'!'(Receiver, fred). bar() -> spawn(foo, ugh, [self()]), receive X -> X end. where foo:bar() ==> fred. We see that at least some existing Erlang operators behave like calls to related functions in a module, so right now, operators as such are NOT needed. Even message sends can be done, right now, in existing Erlang, without using anything other than ordinary function calls. With those operator and other functions you can write more functions. So functions are bound to programmers skills to do them readable. "functions are bound to programmers skills"? I can make no sense of this. Perhaps that proves your point, whatever it is. Operators do not, unless you allow user defined operators. That's why I think you are introducing more confusing to the language. "introducing more confusing" is certainly confusing, I grant you that. But again, I am obliged to call this scaremongering. It's like someone saying that dentistry will always be too dangerous to carry out on people, when there are millions of people walking around to prove the contrary. I have used, and continue to use, several programming languages where there are user-defined operators. I've been using one of the for 25 years, and one of the others has _had_ user-defined operators for quite as long (well, if it looks like a duck and quacks like a duck I'll call it a duck even if I'm told it should be called a binary selector). In practice, these operators do much good and little or no harm. Perhaps is a matter of taste, but I don't think the use of user-defined operators (neither alphabetic or non-alphanumeric) improve the readability of the code. I must ask: how much experience have you had with them? Do you *REALLY* think that is_element(X, S) union(S1, S2) del_element(X, S) match(X, P) are better than X `in` S S1 `union` S2 S `without` X X `matches` P Infix notation is ambiguous This is simply untrue. Infix notation in Erlang is not at all ambiguous and adding user-defined operators would not make it ambiguous. and we only use it for historic reasons. Again, this is quite untrue. Mathematicians have been engaged in notational engineering for a couple of centuries. Programming language designers have been engaged in fairly intense notational engineering for about half a century. We've had languages (like Lisp) where nothing is an operator, languages (like APL) where everything is an operator, languages (like Smalltalk) with things that technically aren't operators but are in all but name, languages (like Java) with a fixed set of operators, and languages (like Prolog, Haskell, Eiffel, and Algol 68) with user-defined operators. If the only reason were historic, we'd know that by now, and a fifty year history of Lisp would have shown programmers the error of their ways. It hasn't. We use operators because they work well. Specification languages commonly allow outfix, distfix, and mixfix operators as well as prefix, infix, and postfix ones. > Not familiar from school: > * (should be x) / (should be -:-) Why / should be -:-? (just curious) I used "x" for U+00D7 MULTIPLICATION SIGN and "-:-" for U+00F7 DIVISION SIGN because I still don't quite trust E-mail to deliver non-ASCII letters unmangled. I'm old enough to remember when 2/6 was half a crown, not a third. (Heck, I'm even old enough to remember the "Sterling" feature of PL/I.) There may perhaps be reasons not to support user-defined operators in Erlang, and it would be good to hear them rather than scaremongering. From samuel@REDACTED Wed Mar 31 10:03:31 2004 From: samuel@REDACTED (Samuel Rivas) Date: Wed, 31 Mar 2004 10:03:31 +0200 Subject: user-defined operators In-Reply-To: <200403310522.i2V5MUYH470159@atlas.otago.ac.nz> References: <200403310522.i2V5MUYH470159@atlas.otago.ac.nz> Message-ID: <20040331080331.GA19974@crusher.lfcia.pri> Richard A. O'Keefe wrote (and I still respect his opinion): > Samuel Rivas replied most confusingly: > > As you stress, a symbol that can represent different > operations in different contexts is said to be "overloaded". + > ++ and * are DIFFERENT operations, your definition says nothing > about using the same function name to indicate those operations. > > Nor does it say anything about the Arian controversy, bimetallism, or the > interpretation of quantum mechanics. Why should one little definition have > to deal with quite irrelevant matters? It should deal with function names if you want it to justify your assertion: By the definition I use, a symbol which is bound to a single definition is not overloaded, no matter how many types that definition applies to. > In Erlang, +, ++, and * are bound to different definitions. > There is no proposal in this or any other thread to change that. Where did I write there is a proposal to change these operators? > Erlang *already* permits the definition of a function which sometimes > calls one, sometimes calls the other, of those operations. That function > is nevertheless itself still ONE "operation". So, is your f(X,Y) when integer(X) ... overloaded or not? In your previous mail you said that is a *single* definition, which necessarily lead us to the fact that an operator bound to f is not overloaded. > > You are not adding more polymorphism or overloading, you are mapping > the problems of functions to the operators. > > So what? What kind of mental deficiency could cause someone to have > NO trouble with functions that can do different things depending on what > their arguments are, but to suddenly fall all to pieces when it is an > operator that does this? Again, where did I write there are no problems with functions? I actually wrote there ARE problems with functions. > People seem to be arguing against user-defined operators on the grounds that > operators have some kind of unique sacred character that makes them different > from functions. But in EXISTING Erlang this is not so. Agreed, that is not the point. > Currently you can have confusing functions, but the set of > operators is well defined and (more or less) widely accepted (I > really don't like the ++ operator since it's just the same as > lists:concatenate and you have to know it because of > optimisation issues). > > I don't know what is meant by "widely accepted" here. It is, of course, This is meant everybody can assume +, *, ++, /, !, ... will do what are supposed to do. I am not trying to say introducing user defined operators will change the meaning of these built-in operators but that you can find one operator that is not "universal" (and I trying to argue in favour of this will be not a good thing) > accepted that the set of Erlang operators is what it is; since the > language was first defined there can hardly ever have been a single day > when it was widely accepted that it was what it should be. Right at the > moment, Joe Armstrong has a proposal for an additional operator, !!, > which is *not* well defined, Perhaps "well defined" is not a good description. I meant "well known". > Anyone who wants to pretend that + and * in Erlang do one and only one > thing is living in fantasy land. And you cannot use Erlang for long > without discovering that X!Y does different things depending on what X is. > (Related things, yes. The same things, no.) I still don't know where I wrote that. > IMO, you need the operators to represent some actions you cannot > easily write in the language. > > There are no such actions for which OPERATORS are needed. Any such actions > can be defined using function call syntax, and MOST such actions in Erlang > are defined using function call syntax. Lisp is proof that operator syntax > is not needed. Agreed, operators are not needed, maybe my "need" is too strong, I should wrote "want". > "functions are bound to programmers skills"? I can make no sense of this. > Perhaps that proves your point, whatever it is. When you are reading a program written by someone you can't assume all functions do what you suppose them to do. It is programmer responsibility to write his functions right. However you can assume what operators will do if the set of operators is defined by the language. You can think reading an unknown operator is like reading an unknown function. I will not argue against that, it is only a personal point of view. I only want to point that, up to this moment, opening the set of operators will add more complexity to source code reading, and that can be worth doing it on not. > Do you *REALLY* think that > > is_element(X, S) union(S1, S2) del_element(X, S) match(X, P) > > are better than > > X `in` S S1 `union` S2 S `without` X X `matches` P If they are not better they are, at least, the same. I should say again "perhaps is a matter of taste" to use either one or the other, but I don't still see what the problem is with is_element(X, union(del_element(Y, S1), S2)) that is not in X `in` S1 `without` Y `union` S2 > Infix notation is ambiguous > > This is simply untrue. Infix notation in Erlang is not at all > ambiguous and adding user-defined operators would not make it ambiguous. Languages are designed with a certain operator precedence to avoid the ambiguity, because infix notation IS ambiguous. Prefix (functions) and postfix operators does not introduce such ambiguity in the language. > > Not familiar from school: > > * (should be x) / (should be -:-) > Why / should be -:-? (just curious) > > I used "x" for U+00D7 MULTIPLICATION SIGN > and "-:-" for U+00F7 DIVISION SIGN > because I still don't quite trust E-mail to deliver non-ASCII letters > unmangled. Yes, yes, my question was about the real meaning of / > I'm old enough to remember when 2/6 was half a crown, > feature of PL/I.) Oh! What function is supposed to be / then? (just curious, again) > There may perhaps be reasons not to support user-defined operators in > Erlang, and it would be good to hear them rather than scaremongering. I'm trying to set out my view, you can think I am a scaremonger if you want. For me I'll keep thinking it's only I don't agree with you like you don't agree with me. -- --------------------- | Samuel | --------------------- From joe@REDACTED Wed Mar 31 10:12:54 2004 From: joe@REDACTED (Joe Armstrong) Date: Wed, 31 Mar 2004 10:12:54 +0200 (CEST) Subject: fault-tolerance In-Reply-To: <40682B3B.6060006@kent.ac.uk> Message-ID: On Mon, 29 Mar 2004, Clara Benac Earle wrote: > Hi, > > I have written a simple client-server system in Erlang using the generic > server behaviour. My system should recover gracefully when a client > process dies. To do that I am using the supervsion tree behaviour for > restarting the client process and the process_flag, link and handle_info > primitives in the server to trap the exit signal from the client process > and delete the information about the crashed process from the state of > the server. > > Now, I am having difficulties to test my program. To test the fault > tolerance all I am doing is to start pman and kill a process client and > observe the messages I am printing on the screen. The other way I am > testing it is by writing code in the client which will make the client > die. In this way I have a better knowledge of at which point the client > dies. However, none of this two ways of debugging is very satisfactory. > > I wanted to ask what people does for debugging fault-tolerant programs. Well if your problem is that the messages roll off the screen you can need to save them on disk so you can read them later. Quick hack: If you have a *nix box you can type "script" in a shell window before you do anything - after that run any commands - type Control D and everything will be saved in a file called "typescript". Better: write trace messages a file instead of the terminal Even better: write trace message to dets so you can analyze them later Even more better: write trace message to mnesia Your trace messages should be Erlang terms so that another program can later analyze them (if the problem is complex) Then you need to think about *invariants* Invariants are things that are always true - you must analyze your problem to identify the things that are always true - and then write code to test that that the invariants hold. Finally - *use the coverage analyzer* Do erl -man cover IMHO coverage is the single best technique for making production quality code. Cheers /Joe > > Cheers, > Clara > > > This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. > > E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. > From joe@REDACTED Wed Mar 31 12:05:22 2004 From: joe@REDACTED (Joe Armstrong) Date: Wed, 31 Mar 2004 12:05:22 +0200 (CEST) Subject: Anybody done this Message-ID: I want to build the PANOMNICOM (this is cross posted to the Erlang and Planet lab lists to encourage a cross-fertilization of ideas) The PANOMNICOM is the universal computer which is everywhere. Imagine all computers in the Universe have two big buttons called ATTACH and DETACH, they all run the PANOMNICOM This is what I want to do - Hack away - On computer (ONE) I run Erlang. - I bang the DETACH BUTTON - Evaluate erlang:suspend(File) Erlang stops. The state is stored in a file. The file is processed into N chunks (Using some erasure code for example, reed-solomon tornado or raptor codes) the chunks are encrypted the encrypted chunks are stored in a distributed hash table in a P2P network (say using DKS Chord, Pastry etc - they're all the same :-) - I go to any other computer (TWO) *anywhere* in the world - I press the ATTACH button - K chunks of my data are recovered from the distributed hash table the chunks are decrypted the original file is reconstructed (note a K:N erasure has the property that if some data is processed to form N different chunks, then the original data can be reconstructed from any K different chunks, where K < N ) Get the original state file back do erlang:resume(File) - Carry on hacking - My data in the PANOMNICOM is stored reliably *forever* - or until the sun goes bananas - whichever is first. Here are some sub-problems that I want code (preferably Erlang) for - has anybody done/thought/coded anything remotely related to the following: 1) Implement a virtual block device I want a process that implements the protocol that all the io library functions use. The only interface to the block-device should be read_block(Device, N), write_block(Device, N, <>) query_device(Device) -> {#blocks, #blocksize} Also I'd like to make ext2 file systems *inside* files and binaries - and send complete ext2 filesystems in binaries as messages. 2) Stopping and starting Erlang. I'd like to say erlang:suspend(File) which would suspend Erlang dumping the state into a file and later say erlang:resume(File) which would re-start the suspended Erlang from *exactly* the state it was in. 3) Efficient implementation of erasure codes (Done I think) 4) Distributed hash tables (sort of done - BUT big problems with malicious users etc) Now I guess nobody has built this yet (unless you just happen to have hacked this together and have it sitting around on your hard disk) But any progress towards this would be helpfully. Cheers /Joe From cb47@REDACTED Tue Mar 30 16:59:28 2004 From: cb47@REDACTED (Clara Benac Earle) Date: Tue, 30 Mar 2004 15:59:28 +0100 Subject: supervisors Message-ID: <40698B50.2070104@kent.ac.uk> Hi, I am studying the supervisor behaviour and I have seen many applications where the restart strategy one_for_one is used. I was just wondering whether there are good examples out there where any of the other strategies, one_for_all and one_for_rest, are used. Thanks, Clara From smuir@REDACTED Wed Mar 31 20:21:08 2004 From: smuir@REDACTED (Steve Muir) Date: Wed, 31 Mar 2004 10:21:08 -0800 (PST) Subject: [Planetlab-arch] Anybody done this In-Reply-To: References: Message-ID: micro-response: On Wed, 31 Mar 2004, Joe Armstrong wrote: > Also I'd like to make ext2 file systems *inside* files and binaries - > and send complete ext2 filesystems in binaries as messages. you can already do this in Linux using loopback mounts e.g., one can mount an ISO CD-ROM image at a certain mountpoint and access the contents of the image as a (read-only) directory tree. other UNIX-like systems may have equivalent functionality. cheers, steve From valentin@REDACTED Thu Mar 4 12:07:02 2004 From: valentin@REDACTED (Valentin) Date: Thu, 4 Mar 2004 13:07:02 +0200 Subject: SCTP API References: <20040402195654.GI75018@frogman.motivity.ca> <878yhem4hu.fsf@ghidra.vail> Message-ID: <01c601c401d8$e58b6ca0$0100a8c0@MONEYMAKER2> Doing SCTP alone does not help much, and yet, all sorts of different efforts will cover it good enough. I think that we should move focus up to M3UA. It is fairly easy to write a (minimalist) C-Node bridge between vendor specific SCTP end-point and Erlang. Such a bridge should push/pull messages up (Erlang) and down (SCTP). A pure Erlang based M3UA would process these messages and push/pull it to/from upper layers. A similar bridge may be written north-bound, between existing SCTP/TCAP/MAP (ok... ISUP, INAP as well) implementations and Erlang-based M3UA. V. ----- Original Message ----- From: "Hal Snyder" To: Sent: Friday, April 02, 2004 11:53 PM Subject: Re: SCTP API > Vance Shipley writes: > > > Has anyone given much thought as to how SCTP should be integrated > > into Erlang? > > > > The Stream Control Transmission Protocol (SCTP) [RFC2960] is now > > available from Sun as an experimental package(*) and will likely > > (IMHO) be included in Solaris 10. There are also implementations for > > BSD and Linux available. > > ISTR a draft submission on SCTP and Erlang transport for a workshop in > the last couple years, but I can't find it at the moment...