From rory Sat Mar 1 00:17:51 2008 From: rory (Rory Byrne) Date: Sat, 1 Mar 2008 00:17:51 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: Message-ID: <20080229231751.GA7573@almeida.jinsky.com> On Sat, Mar 01, 2008 at 09:34:57AM +1100, Anthony Kong wrote: > > For some testing purpose, I have written some erlang code in a file c.erl. > Unlucky! There's a module called c in stdlib. See here: http://www.erlang.org/doc/apps/stdlib/index.html Cheers, Rory From hokan.stenholm Sat Mar 1 00:59:33 2008 From: hokan.stenholm (=?ISO-8859-1?Q?H=E5kan_Stenholm?=) Date: Sat, 01 Mar 2008 00:59:33 +0100 Subject: [erlang-questions] newbie: how to ignore the rest in a variable length tuple? In-Reply-To: References: Message-ID: <47C89C65.1080905@bredband.net> Anthony Kong wrote: > Hi, all, > > What I want to achieve is this: > > In the case I received a tuple like {x, B, C, D} I want to perform > some action using B, C, D. > > But if I received a tuple like {y, ...} I just don't care the rest of > data in the tuple. > > So, I tried a syntax {y, _}, but this led to a function_clause > exception. It is because erl applies this to a tuple of 2 elements, > not "tuple of any length with first element == y". > > Is there any alternative to "{y, _, _, _} " ? > Sorry, there isn't any special syntax for checking "tuple starts with", but there are several alternate approaches: * Restructure your data to conform to something like {Type, PayLoad}, so that {y, A, B} becomes {y, {A, B}}. All "y" tuples are then of the same length, so that you can use a single pattern {y, _}. * check individual tuple fields, like this: case element(1, Tuple) of x -> ... y -> ... end * convert the tuple to a list, and match using the list: case tuple_to_list(Tuple) of [x| ...] -> ... [y| ...] -> ... end * Specifying a new clause for each valid pattern, is useful to ensure that only valid inputs are accepted. If the input should be ignored you could simply drop it. f({x, B, C, D) -> .... ; % do stuff f(_) -> ok. % ignore non-x tuple or x tuples of length /= 4 or only keep the first clause and crash on unexpected input: f({x, B, C, D) -> .... . % do stuff > Because of the way I construct the messages, it can be a tuple of 4 or > 5 elements. That means If I have to define a clause for {y, _, _, _} > then I have to also define another one for {y, _, _, _, _}. I am > looking for a leaner expression. > > > Cheers, Anthony > > ==================================== > > -module(c1). > > -export([test/0]). > test() -> > R = c1({x, b, c, d}), > io:format("~p~n", [R]), > R1 = c1({y, b, c, d}), > io:format("~p~n", [R1]). > > > c1({x, B, C, D}) -> > io:format("~p ~p ~p~n", [B, C, D]), > {ok, get_x}; > > c1({y, _}) -> > {ok, get_y}. %% throw function_clause exception > > ==================================== > > > > From pfisher Sat Mar 1 01:27:07 2008 From: pfisher (Paul Fisher) Date: Fri, 29 Feb 2008 18:27:07 -0600 Subject: [erlang-questions] newbie: how to ignore the rest in a variable length tuple? In-Reply-To: References: Message-ID: <1204331227.6159.74.camel@pfisher-laptop> On Sat, 2008-03-01 at 09:53 +1100, Anthony Kong wrote: > Hi, all, > > What I want to achieve is this: > > In the case I received a tuple like {x, B, C, D} I want to perform > some action using B, C, D. > > But if I received a tuple like {y, ...} I just don't care the rest of > data in the tuple. > > So, I tried a syntax {y, _}, but this led to a function_clause > exception. It is because erl applies this to a tuple of 2 elements, > not "tuple of any length with first element == y". > > Is there any alternative to "{y, _, _, _} " ? Use guards: c1( {x, B, C, D} ) -> ok; c1( Y ) when is_tuple(Y), element(1, Y) =:= y -> ok. if you want to restrict Y to 4 or 5 elements only, then add: length(Y) >= 4, length(Y) =< 5 to the list of guards. -- paul From vlm Sat Mar 1 01:53:35 2008 From: vlm (Lev Walkin) Date: Fri, 29 Feb 2008 16:53:35 -0800 Subject: [erlang-questions] newbie: how to ignore the rest in a variable length tuple? In-Reply-To: <1204331227.6159.74.camel@pfisher-laptop> References: <1204331227.6159.74.camel@pfisher-laptop> Message-ID: <47C8A90F.8060801@lionet.info> Paul Fisher wrote: > c1( {x, B, C, D} ) -> ok; > c1( Y ) when is_tuple(Y), element(1, Y) =:= y -> ok. > > if you want to restrict Y to 4 or 5 elements only, then add: > > length(Y) >= 4, length(Y) =< 5 > > to the list of guards. tuple_size, perhaps -- vlm From pfisher Sat Mar 1 02:03:36 2008 From: pfisher (Paul Fisher) Date: Fri, 29 Feb 2008 19:03:36 -0600 Subject: [erlang-questions] newbie: how to ignore the rest in a variable length tuple? In-Reply-To: <47C8A90F.8060801@lionet.info> References: <1204331227.6159.74.camel@pfisher-laptop> <47C8A90F.8060801@lionet.info> Message-ID: <1204333416.6159.77.camel@pfisher-laptop> On Fri, 2008-02-29 at 16:53 -0800, Lev Walkin wrote: > Paul Fisher wrote: > > c1( {x, B, C, D} ) -> ok; > > c1( Y ) when is_tuple(Y), element(1, Y) =:= y -> ok. > > > > if you want to restrict Y to 4 or 5 elements only, then add: > > > > length(Y) >= 4, length(Y) =< 5 > > > > to the list of guards. > > > tuple_size, perhaps Of course, thanks for catching that. -- paul From toby Sat Mar 1 02:44:39 2008 From: toby (Toby Thain) Date: Fri, 29 Feb 2008 19:44:39 -0600 Subject: [erlang-questions] Use of makefiles In-Reply-To: References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> Message-ID: <1C34D197-3444-4D89-8F8E-F30549A63A83@telegraphics.com.au> On 29-Feb-08, at 2:41 PM, Brian Cully wrote: > On 29-Feb-2008, at 14:56, Toby Thain wrote: >>> Makefiles are declarative, so in theory they should be really >>> neat and >>> the Erlang world should love them. There are two flies in the >>> ointment. One is that the syntax is batshit crazy. >> >> i.e. Nobody reads the manual. > > Having a manual doesn't make make's syntax any less batshit crazy. It never struck me as crazy. I guess it's subjective. > >> >>> The other is that >>> people tend to force large doses of imperativeness into Makefiles, >>> which defeats half the point. One widespread example is recursive >>> makefiles. >> >> i.e. Nobody learns how to use it properly. > > Or: make isn't suitable for large classes of useful work and > thinking, I see no evidence of that. It's used for plenty of real work - and not just by me. --Toby > but given its predominance it is forced into these roles by hook > and crook. > > -bjc From roger.larsson Sat Mar 1 03:00:03 2008 From: roger.larsson (Roger Larsson) Date: Sat, 1 Mar 2008 03:00:03 +0100 Subject: [erlang-questions] PS3 and Erlang (Re: Google Summer of Code 2008) In-Reply-To: <47C79A70.1040108@ghostgun.com> References: <510A206C-8ACA-4C62-86E7-1E807BEA7581@telegraphics.com.au> <47C79A70.1040108@ghostgun.com> Message-ID: <200803010300.03522.roger.larsson@e-gatan.se> On fredag 29 februari 2008, jm wrote: > Toby Thain wrote: > >> * Organise a list of project ideas that we'd like students to work > >> on. > > > > One perennial topic is porting Erlang to embedded/tiny systems, and > > how small the runtime can feasibly be. > > Should I mention PS3 and the Cell. I have a PS3 myself (with Linux installed). I have been thinking about how much a PS3 resembles a telephone exchange... And we all know what language to use for programming those! You have the SPEs (and Altivec) connected via an exchange and you would like to make the best use of the resources. Avoid moving executions from one SPE to another (keep the code in SPE memory) - but on the same time the work might require being split to several SPEs to meet deadlines (real time games). [IBM has a real time ray tracer that dynamically how big part of the image is computed by what SPE] Move the data to the right SPE, but there are rules about how to do this most efficient using the built in exchange. If data can remain on a SPE keep it there. An outline: * building the work scheduler in Erlang * data, binary arrays (required by the SPEs and PowerPC Altivec) * executables, in form of binary objects (SPE, Altivec, or PowerPC executable) * work descriptors, connecting executables with data * building simulation in Erlang, create work descriptors depending on events. Wouldn't that make an interesting summer project! /RogerL From xushiweizh Sat Mar 1 05:59:49 2008 From: xushiweizh (shiwei xu) Date: Sat, 1 Mar 2008 12:59:49 +0800 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: Message-ID: I think flat module namespaces is a defect of erlang design. For example, I write a foo.erl, It works well. But maybe in a late erlang version (eg. R13B) also write such module named foo.erl. Then, you can see my application goes wrong. How to avoid things like this? Let's see the following ways: 1. Adjust module searching paths, and let user path (which contains my foo.erl) take precedence over erlang stdlib/otp path. But, this way can't always work well. If some other stdlib/otp modules use system foo.erl (not my foo.erl), Things goes wrong. 2. Write erlang modules always named with a prefix (a fake namespace. For example, projectname_foo.erl or organization_projectname_foo.erl). This way really can solve the problem. But, It seems ugly. Is there a way let's user still can call foo:func (not call foo.erl provied by stdlib/otp, but my projectname_foo.erl)? I have a suggestion: Can erlang provide a 'module name alias'? That is, I can rename a module's name temporarily in a module? For example: -module(a_module_that_call_my_foo). -alias(foo, organization_projectname_foo). %% alias some_func_call_foo() -> foo:func(). %% same as: organization_projectname_foo:func() Currently I can do this by using the 'define' keyword. For example: -module(a_module_that_call_my_foo). -define(FOO, organization_projectname_foo). %% alias some_func_call_foo() -> ?FOO:func(). It works well, but a bit ugly. On Sat, Mar 1, 2008 at 6:51 AM, Matt Stancliff wrote: > > On Feb 29, 2008, at 14:34, Anthony Kong wrote: > > > If I rename c.erl to something else, the problem goes away. > > > > What is special about "-module(c)" ? > > Welcome to the world of flat module namespaces. > > The code module is your friend in these circumstances. > Look into code:clash() and code:which(module). > > code:which(c) should return "/lib/erlang/lib/stdlib- > /ebin/c.beam" > > > -Matt > -- > Matt Stancliff sysop > AIM: seijimr iPhone: 678-591-9337 > "The best way to predict the future is to invent it." --Alan Kay > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080301/0d25918c/attachment-0001.html From vinoski Sat Mar 1 07:50:13 2008 From: vinoski (Steve Vinoski) Date: Sat, 1 Mar 2008 01:50:13 -0500 Subject: [erlang-questions] hipe binary matching problem with R12B-1? Message-ID: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> Just out of curiosity I've been going back through some Wide Finder code to see how it fares under R12B-1, given the improvements in binaries in this new release. Generally I'm seeing some pretty good performance improvements with no code changes. Unfortunately I think I'm also seeing a bug. Below find the results of compiling and running the example code at the bottom of this message. Using "c" to compile gives the right answer; using "hipe:c" gives the wrong answer. This is on Redhat Linux ES 4, with erlang R12B-1 built with smp, threads, hipe, and kernel poll enabled. Within the code, on the second instance of function check/2 you'll find a commented-out guard. If you uncomment the guard, then the code works correctly with both "c" and "hipe:c". Note that if you want to try it for yourself, make sure there's a space at the end of the string within the binary you pass to wrong_result:get/1, as shown in shell prompts 2 and 4 below. --steve $ erl Erlang (BEAM) emulator version 5.6.1 [source] [smp:8] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.6.1 (abort with ^G) 1> c(wrong_result). {ok,wrong_result} 2> wrong_result:get(<<"200x/2006/10/02/Linux-Journal ">>). {ok,<<"2006/10/02/Linux-Journal">>} 3> hipe:c(wrong_result). {ok,wrong_result} 4> wrong_result:get(<<"200x/2006/10/02/Linux-Journal ">>). wrong_answer ======== -module(wrong_result). -export([get/1]). check(Bin) -> check(Bin, 0). check(<<$ , _/binary>>, 0) -> {nomatch, 0}; check(Bin, Len) -> %when Len < size(Bin) -> case Bin of <> -> {ok, Front}; <<_:Len/binary, $., _/binary>> -> {nomatch, Len}; _ -> check(Bin, Len+1) end. get(<<>>) -> nomatch; get(Bin) -> <> = Bin, case Front of <<_:3/binary,"x/",Y:4/binary,$/,M:2/binary,$/,D:2/binary,$/>> -> case check(Tail) of {ok, Match} -> {ok, <>}; {nomatch, Skip} -> {skip, Skip+size(Front)}; _ -> wrong_answer end; _ -> nomatch end. From kostis Sat Mar 1 10:00:38 2008 From: kostis (Kostis Sagonas) Date: Sat, 01 Mar 2008 11:00:38 +0200 Subject: [erlang-questions] hipe binary matching problem with R12B-1? In-Reply-To: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> References: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> Message-ID: <47C91B36.90601@cs.ntua.gr> Steve Vinoski wrote: > Just out of curiosity I've been going back through some Wide Finder > code to see how it fares under R12B-1, given the improvements in > binaries in this new release. Generally I'm seeing some pretty good > performance improvements with no code changes. Unfortunately I think > I'm also seeing a bug. > > Below find the results of compiling and running the example code at > the bottom of this message. Using "c" to compile gives the right > answer; using "hipe:c" gives the wrong answer. This is on Redhat Linux > ES 4, with erlang R12B-1 built with smp, threads, hipe, and kernel > poll enabled. > > Within the code, on the second instance of function check/2 you'll > find a commented-out guard. If you uncomment the guard, then the code > works correctly with both "c" and "hipe:c". Yes, this is a bug. We will fix it. In the meantime, you can bypass it by compiling in either of the two ways below: hipe:c(wrong_result, [no_concurrent_comp]). hipe:c(wrong_result, [core]). Thanks for reporting this. Kostis From anthony.hw.kong Sat Mar 1 12:04:02 2008 From: anthony.hw.kong (Anthony Kong) Date: Sat, 1 Mar 2008 22:04:02 +1100 Subject: [erlang-questions] newbie: how to ignore the rest in a variable length tuple? In-Reply-To: <1204333416.6159.77.camel@pfisher-laptop> References: <1204331227.6159.74.camel@pfisher-laptop> <47C8A90F.8060801@lionet.info> <1204333416.6159.77.camel@pfisher-laptop> Message-ID: Thanks a lot for your responses! Cheers From thomasl_erlang Sat Mar 1 14:38:20 2008 From: thomasl_erlang (Thomas Lindgren) Date: Sat, 1 Mar 2008 05:38:20 -0800 (PST) Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: Message-ID: <77016.67694.qm@web38812.mail.mud.yahoo.com> --- shiwei xu wrote: > I think flat module namespaces is a defect of erlang > design. Richard Carlsson proposed java-like packages some years ago, and the code for them might still be provided in OTP. (I thought they had some flaws, but they might be what you want.) http://citeseer.ist.psu.edu/398052.html The usual approach to handling name clashes without packages is to use your 'approach 2', prefixing the modules with their owner application. Best, Thomas ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From kostis Sat Mar 1 15:53:02 2008 From: kostis (Kostis Sagonas) Date: Sat, 01 Mar 2008 16:53:02 +0200 Subject: [erlang-questions] hipe binary matching problem with R12B-1? In-Reply-To: <02af01c87b91$613f9390$6401a8c0@moneymaker2> References: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> <47C91B36.90601@cs.ntua.gr> <02af01c87b91$613f9390$6401a8c0@moneymaker2> Message-ID: <47C96DCE.7070600@cs.ntua.gr> Valentin Micic wrote: > From: "Kostis Sagonas" > >> Yes, this is a bug. We will fix it > > May I ask if this bug is limited to Linux, or it is unversal to all > supported platforms (e.g. Solaris). Yes. This is generic. It happens on all platforms I've tested. > Would it be safe to assume that R11 is still the safest bet for Linux? I've no idea what you have in mind. As far as the HiPE compiler is concerned, this is the first bug I recall in a long while. In fact, this particular one aside, there are no outstanding bugs I know of -- which of course does not preclude the existence of bugs I know nothing about. In any case, to answer your question, I am not aware of any good reasons for somebody to prefer R11 over R12 as far as HiPE is concerned. I'm willing to bet the situation is similar for BEAM: most (if not all) R11 compiler bugs have been fixed in R12 and the Erlang/OTP team has been *very* responsive in correcting and publishing patches for all R12 compiler problems that have been reported in this list. Kostis From pat.mcnally Sat Mar 1 18:22:59 2008 From: pat.mcnally (Pat McNally) Date: Sat, 1 Mar 2008 11:22:59 -0600 Subject: [erlang-questions] QLC Join Question for Mnesia Message-ID: <873d9df60803010922i50fb517ds4fe6effd4a7d7b14@mail.gmail.com> I'm new to the world of Erlang and just starting to play around with Mnesia. Lets say I have those two records. I want to compose a query that will pull a basket out of the database and fill it with a list of all the apples that have their basket_id set to the same id as the basket. -record(basket, {id, apples = []}). -record(apple, {id, brand, basket_id}). I can do something like this: (where Id is the id of the basket I'm looking for) qlc:q([B#basket{apples = A} || B <- mnesia:table(basket), B#basket.id =:= Id, A <- mnesia:table(apple), A#apple.basket_id =:= B#basket.id]). However when I run that query it only returns a single apple in the basket, as opposed to a list of apples. Is it possible to do this in a single query? From gleber.p Sat Mar 1 19:54:30 2008 From: gleber.p (Gleb Peregud) Date: Sat, 1 Mar 2008 19:54:30 +0100 Subject: [erlang-questions] Reading fixed structures from file Message-ID: <14f0e3620803011054h1cba297ep2b3ed6d100222853@mail.gmail.com> Hello. I have one simple question regarding reading a fixed structure from files. Let say i have a binary file filled with sequence of fixed length structures. Each structure is of the form: struct { int32 key, int64 adr, char type }; File was written at x86 platform, hence it is little-endian. I use R12B Is the following way the best way to read whole file to the list: scan_file(Binary) -> scan_file(0, Binary, []). scan_file(N, <<>>, List) -> list:reverse(List); scan_file(N, Binary, List) -> << Key:4/little-integer-unit:8, Adr:8/little-integer-unit:8, Type:1/little-integer-unit:8, Rest/binary >> = Binary, Obj = {N, Type, Adr, Key}, scan_file(N+1, Rest, [Obj | List]). Code was not tested. I have doubts if i understand notion of "size" and "unit" in binary matching... Do i understand it correctly? -- Gleb Peregud http://gleber.pl/ "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein From dizzyd Sat Mar 1 20:31:15 2008 From: dizzyd (Dave Smith) Date: Sat, 1 Mar 2008 12:31:15 -0700 Subject: [erlang-questions] Reading fixed structures from file In-Reply-To: <14f0e3620803011054h1cba297ep2b3ed6d100222853@mail.gmail.com> References: <14f0e3620803011054h1cba297ep2b3ed6d100222853@mail.gmail.com> Message-ID: On Sat, Mar 1, 2008 at 11:54 AM, Gleb Peregud wrote: > Hello. > > I have one simple question regarding reading a fixed structure from files. > > Let say i have a binary file filled with sequence of fixed length > structures. Each structure is of the form: > > struct { > int32 key, > int64 adr, > char type > }; > > File was written at x86 platform, hence it is little-endian. I use R12B > > Is the following way the best way to read whole file to the list: > > scan_file(Binary) -> > scan_file(0, Binary, []). > scan_file(N, <<>>, List) -> > list:reverse(List); > scan_file(N, Binary, List) -> > << > Key:4/little-integer-unit:8, > Adr:8/little-integer-unit:8, > Type:1/little-integer-unit:8, > Rest/binary > >> = Binary, > Obj = {N, Type, Adr, Key}, > scan_file(N+1, Rest, [Obj | List]). > > Code was not tested. I'm pretty sure you code would be fine that way. Personally, I would do something like: scan_file(N, <<>>, List) -> lists:reverse(List); scan_file(N, <>, List) -> scan_file(N+1, Rest, [{N, Type, Addr, Key} | List]). I personally feel that reads a little clearer since it's in bits and you don't have to do clever adjustments in your head when reading the code. My $0.02 (and with the dollar declining, worth less every day!) :) D. From klacke Sat Mar 1 21:10:33 2008 From: klacke (Claes Wikstrom) Date: Sat, 01 Mar 2008 21:10:33 +0100 Subject: [erlang-questions] Strings as Lists In-Reply-To: References: <84fb38e30802120819q17f79420xc5d33f3c83a599f9@mail.gmail.com> <2F5E96D5-CF7A-42AC-B04E-CB8183F7AB7D@masklinn.net> <3dbc6d1c0802121413o7480d2abtc913801ceae67e8e@mail.gmail.com> <14EEE3D7-56F1-470A-BCE5-C5B534A6EF88@scaldeferri.com> <972E01DC-2A4D-4EB8-B483-CFD98AB6E87F@cs.otago.ac.nz> <1202974658.4369.24.camel@piko.site> <518CB40F-9028-4068-B6F7-C612253B6FDE@scaldeferri.com> Message-ID: <47C9B839.2050506@hyber.org> Richard A.O'Keefe wrote: > so it's easy for an Erlang program to build a string cheaply in > either left > to right or right to left order using lists, but wouldn't be using > binaries. > > iolists are great for cheaply constructing data that is about to go out on port soon. iolists suck when some code later on has to traverse/manipulate it. The ports will just automatically flatten the iolist in O(n) and that (n) is negligible because the port code anyway has to copy the data to an output buffer which is _also_ O(n) One of the original goals with the binary() datatype was that appending to the right should be as cheap as it is for an iolist and it is. List2 = [List1 | More] or List2 = [List1 , More] doesn't really matter as long as More indeed is a list Anyway, Bin2 = <> is equally efficent as the iolist construction. It's just pointer manipulations. O(1) /klacke From klacke Sat Mar 1 21:20:09 2008 From: klacke (Claes Wikstrom) Date: Sat, 01 Mar 2008 21:20:09 +0100 Subject: [erlang-questions] Strings as Lists In-Reply-To: <47B1D0AE.5030803@it.uu.se> References: <84fb38e30802120819q17f79420xc5d33f3c83a599f9@mail.gmail.com> <47B1D0AE.5030803@it.uu.se> Message-ID: <47C9BA79.1030801@hyber.org> Richard Carlsson wrote: Binaries let you do this in Erlang, but they were > a later addition to the language, and the syntax for constructing and > decomposing binaries came even later. > Archaeological rear view mirror coming up. The binary() datatype was introduced by me when Per Hedeland an I ages ago ripped out all explicit UNIX syscalls from the emulator proper. Especially the file calls to load code. That's also when we introduced the driver concept. A driver (C code) which from erlang looks like a Port reads the actual file and sends it back up to erlang. All the code loading BIFs that used to take a filename as parameter was changed to take a binary() as param instead. Those were the days .... 1994 ?? /klacke From klacke Sat Mar 1 21:30:05 2008 From: klacke (Claes Wikstrom) Date: Sat, 01 Mar 2008 21:30:05 +0100 Subject: [erlang-questions] asn1 and the new ssl module In-Reply-To: <47B94DF6.6070308@erix.ericsson.se> References: <47B94DF6.6070308@erix.ericsson.se> Message-ID: <47C9BCCD.3030209@hyber.org> > (Probably also the currently > undocumented http-packet type.) > That code is 10 years old by now. It's also in production use all over the world. Maybe it's time to stop referring to it as undocumented and maybe also write some docs for it. ?? /klacke From klacke Sat Mar 1 21:39:42 2008 From: klacke (Claes Wikstrom) Date: Sat, 01 Mar 2008 21:39:42 +0100 Subject: [erlang-questions] blocking vs non-blocking gen_tcp:accept() In-Reply-To: <18357.63950.182578.119672@antilipe.corelatus.se> References: <18357.63950.182578.119672@antilipe.corelatus.se> Message-ID: <47C9BF0E.5040809@hyber.org> Matthias Lang wrote: > Robin writes: > > Does gen_tcp:accept() block the entire OS thread or just the calling > > erlang process? > > Just the erlang process. (verifying this yourself is straightforward) > Having accept() as function that receives a message as opposed to hanging would make a lot of sense though. I know that it's possible to use the lowlevel libs to accomplish this but it should be exposed to user level (and documented) in a manner similar to the {tcp, Sock, Data} message we get from an active socket. Maybe we should have a list similar to the http://brainstorm.ubuntu.com/ list where people get to tell the core developers what they should do :-) /klacke From gleber.p Sat Mar 1 22:37:35 2008 From: gleber.p (Gleb Peregud) Date: Sat, 1 Mar 2008 22:37:35 +0100 Subject: [erlang-questions] Reading fixed structures from file In-Reply-To: References: <14f0e3620803011054h1cba297ep2b3ed6d100222853@mail.gmail.com> Message-ID: <14f0e3620803011337l3453d81ew230f2d32a7a0d6f5@mail.gmail.com> Thanks a lot. imho my code is more readable :) But it's matter of taste. Nevertheless, to avoid confusion, i'll ask explicitly: Key:4/little-integer-unit:8 matches four integers each having 8 bits, right? On 3/1/08, Dave Smith wrote: > On Sat, Mar 1, 2008 at 11:54 AM, Gleb Peregud wrote: > > Hello. > > > > I have one simple question regarding reading a fixed structure from > files. > > > > Let say i have a binary file filled with sequence of fixed length > > structures. Each structure is of the form: > > > > struct { > > int32 key, > > int64 adr, > > char type > > }; > > > > File was written at x86 platform, hence it is little-endian. I use R12B > > > > Is the following way the best way to read whole file to the list: > > > > scan_file(Binary) -> > > scan_file(0, Binary, []). > > scan_file(N, <<>>, List) -> > > list:reverse(List); > > scan_file(N, Binary, List) -> > > << > > Key:4/little-integer-unit:8, > > Adr:8/little-integer-unit:8, > > Type:1/little-integer-unit:8, > > Rest/binary > > >> = Binary, > > Obj = {N, Type, Adr, Key}, > > scan_file(N+1, Rest, [Obj | List]). > > > > Code was not tested. > > I'm pretty sure you code would be fine that way. Personally, I would > do something like: > > scan_file(N, <<>>, List) -> > lists:reverse(List); > scan_file(N, < Type:8/little-integer, Rest/binary>>, List) -> > scan_file(N+1, Rest, [{N, Type, Addr, Key} | List]). > > I personally feel that reads a little clearer since it's in bits and > you don't have to do clever adjustments in your head when reading the > code. > > My $0.02 (and with the dollar declining, worth less every day!) :) > > D. > -- Gleb Peregud http://gleber.pl/ "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein From matthew Sat Mar 1 23:24:04 2008 From: matthew (Matthew Dempsky) Date: Sat, 1 Mar 2008 14:24:04 -0800 Subject: [erlang-questions] Reading fixed structures from file In-Reply-To: <14f0e3620803011337l3453d81ew230f2d32a7a0d6f5@mail.gmail.com> References: <14f0e3620803011054h1cba297ep2b3ed6d100222853@mail.gmail.com> <14f0e3620803011337l3453d81ew230f2d32a7a0d6f5@mail.gmail.com> Message-ID: On 3/1/08, Gleb Peregud wrote: > Nevertheless, to avoid confusion, i'll ask explicitly: > > Key:4/little-integer-unit:8 > > matches four integers each having 8 bits, right? No, and this is trivial to verify at the shell: 1> <> = <<1,2,3,4>>. <<1,2,3,4>> 2> A. 67305985 From matthew Sat Mar 1 23:28:32 2008 From: matthew (Matthew Dempsky) Date: Sat, 1 Mar 2008 14:28:32 -0800 Subject: [erlang-questions] blocking vs non-blocking gen_tcp:accept() In-Reply-To: <47C9BF0E.5040809@hyber.org> References: <18357.63950.182578.119672@antilipe.corelatus.se> <47C9BF0E.5040809@hyber.org> Message-ID: On 3/1/08, Claes Wikstrom wrote: > Having accept() as function that receives a message as opposed > to hanging would make a lot of sense though. I don't think anyone disagrees. Just no one seems to care enough to submit a patch or suggest an interface. > Maybe we should have a list similar to the > http://brainstorm.ubuntu.com/ list where people > get to tell the core developers what they should > do :-) What's wrong with erlang-{questions,bugs,patches}? :-p From rvirding Sun Mar 2 02:00:06 2008 From: rvirding (Robert Virding) Date: Sun, 2 Mar 2008 02:00:06 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released Message-ID: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> I have finally released LFE, Lisp Flavoured Erlang, which is a lisp syntax front-end to the Erlang compiler. Code produced with it is compatible with "normal" Erlang code. The is an LFE-mode for Emacs and the lfe-mode.el file is include in the distribution. Most things seem to work but some things have not been done yet: - The interpreter does handle recursive letrecs, binaries, receive or try. - There is no lisp shell. - Documentation! Yet. The system will be updated as new features are added. This is the 1st release so there is much left to do. I have include the existing documentation lfe_guide.txt in this mail. There are a number of LFE test files and a version of the LFE interpreter written in LFE as examples of code. There are also a number of issues which need to be decided for the next version and I have included a file lfe_issues.txt which describe them in this mail. Both files are in the distribution. Note that while this this lisp has been inspired by Scheme (one of the issues) it is a NOT Scheme, it is Erlang with a lisp syntax and many nice lisp features. Not for that matter is it Common Lisp. In fact features of the Erlang engine mean that it is actually impossible to implement full Scheme of CL. No, they shouldn't be changed or added. It was quite writing Erlang code in lisp and I could easily consider using a lisp syntax for Erlang. I suppose it depends where your preferences lye. It was also easy to get into the traditional lisp habit of using long names for everything which I personally think is not a Good Thing. Perhaps we should do AFE, Arc Flavoured Erlang, instead? Although I think they have gone too far and missed what makes programs easy to read. Macros are very nice, and it is easy to generate LFE code, which is one of the benefits of lisp syntax. LFE also shows that it would probably be possible to write other front-ends inspired by other languages, though why anyone should want to I don't know. Perhaps back to a real Prolog syntax again. The system can be found in the "User Contributions" section at trapexit.org, http://forum.trapexit.org/viewtopic.php?p=40268#40268. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/a31b5106/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lfe_guide.txt Url: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/a31b5106/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lfe_issues.txt Url: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/a31b5106/attachment-0001.txt From toby Sun Mar 2 03:12:41 2008 From: toby (Toby Thain) Date: Sat, 1 Mar 2008 20:12:41 -0600 Subject: [erlang-questions] Use of makefiles In-Reply-To: <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> Message-ID: On 29-Feb-08, at 3:17 PM, Joe Armstrong wrote: > Perhaps I should explain why I use make and why I added a section on > Makefiles in the Erlang book. > > To start with I use makefiles for *all* project irrespective of the > language. > > No matter how small a project is, if I suspend the project and start > working on it months or > years later I will have forgotten how to build the project. > ... > > The few hours spent learning some basic makefile syntax is well worth > the investment - you can amortorise > the investment in time over the next twenty years - so it's well > worth doing. > > Well written makefiles a part of good programming practice. > > To me a project is not complete until there is beautiful code, > beautiful makefiles and beautiful documentation. > ... AMEN! --Toby > > /Joe Armstrong From vinoski Sun Mar 2 03:41:40 2008 From: vinoski (Steve Vinoski) Date: Sat, 1 Mar 2008 21:41:40 -0500 Subject: [erlang-questions] Use of makefiles In-Reply-To: <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> Message-ID: <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> On 2/29/08, Joe Armstrong wrote: > In general I try to use *generic* tools for all programing tasks, for > me this means that > make, emacs, bash, and xterm are constants for all projects. The only > bit that varies is the choice > of programming language. > > When I learn a new language all I have to do is learn the language - > all the other tools say the same - > in the long term this is far better than learning specific tools for > each language - it allows me to concentrate > on the important details (learning the new language) and not get > bogged down in the details of the support > system. (This is also why I *hate* visual environments - each one is > *different*, text tools stay the same > across machine and time boundaries). I can (and do) run makefiles that > are 15 years old - the same cannot be said for visual build > environments. Hi Joe, I agree with you 100%. Give me emacs (with its vast emacs-lisp extensibility), bash (or ksh), and various UNIX command-line tools, which I can combine as I wish using pipes, and keep the visual tools out of my way (and out of my RAM). Here's a very insightful explanation of the differences between those of us who look to languages for productivity, and others who instead look to tools and IDEs for productivity: --steve From saleyn Sun Mar 2 04:57:41 2008 From: saleyn (Serge Aleynikov) Date: Sat, 01 Mar 2008 22:57:41 -0500 Subject: [erlang-questions] blocking vs non-blocking gen_tcp:accept() In-Reply-To: <47C9BF0E.5040809@hyber.org> References: <18357.63950.182578.119672@antilipe.corelatus.se> <47C9BF0E.5040809@hyber.org> Message-ID: <47CA25B5.5070306@gmail.com> Indeed! Moreover, a gen_tcp_server behavior would be a very useful addition to the OTP that would generalize a common acceptor/connector pattern. Serge Claes Wikstrom wrote: > Matthias Lang wrote: >> Robin writes: >> > Does gen_tcp:accept() block the entire OS thread or just the calling >> > erlang process? >> >> Just the erlang process. (verifying this yourself is straightforward) >> > > Having accept() as function that receives a message as opposed > to hanging would make a lot of sense though. > > I know that it's possible to use the lowlevel libs to accomplish > this but it should be exposed to user level (and documented) in > a manner similar to the {tcp, Sock, Data} message we get from an > active socket. > > Maybe we should have a list similar to the > http://brainstorm.ubuntu.com/ list where people > get to tell the core developers what they should > do :-) > > > > /klacke > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From saleyn Sun Mar 2 05:07:48 2008 From: saleyn (Serge Aleynikov) Date: Sat, 01 Mar 2008 23:07:48 -0500 Subject: [erlang-questions] mnesia bug? Message-ID: <47CA2814.7010604@gmail.com> I recently ran into this behavior of mnesia that seemed odd. 1. Mnesia is running on node A and node B, and node B has extra_db_nodes environment set to [A]. 2. Node A has a disc_copies table T. 3. Node B has no replica of table T and accesses it remotely. 4. Node A and node B start up and B calls mnesia:wait_for_tables([T], Timeout). 5. A some point later either network access between nodes A and B lost and restored (e.g. via calls to net_kernel:disconnect/1, net_kernel:connect_node/1). 6. Mnesia on node A reports a *partitioned network* event. This seems strange as node B has no ram or disk copies of any table and node A should not be reporting this event as its tables are still consistent. Can anyone comment on whether it's a bug or intended design? Serge From Raymond.Xiong Sun Mar 2 06:27:34 2008 From: Raymond.Xiong (Raymond Xiong) Date: Sun, 02 Mar 2008 13:27:34 +0800 Subject: [erlang-questions] what does the "B" in R12B means? Message-ID: <20080302052734.GA26505@Sun.Com> I am creating a package for Erlang. I wonder which is a better directory name to install it, /usr/erlang/R12, or /usr/erlang/R12B? I had thought "B" in R12B was minor release number so I perfed to use /usr/erlang/R12, but is there ever a R12A or R12 release? I googled them but didn't find. -- Regards, Raymond From ttmrichter Sun Mar 2 07:56:37 2008 From: ttmrichter (Michael T. Richter) Date: Sun, 02 Mar 2008 14:56:37 +0800 Subject: [erlang-questions] asn1 and the new ssl module In-Reply-To: <47C9BCCD.3030209@hyber.org> References: <47B94DF6.6070308@erix.ericsson.se> <47C9BCCD.3030209@hyber.org> Message-ID: <1204440997.804.3.camel@isolde> > Maybe it's time to stop referring to it as undocumented > and maybe also write some docs for it. Stupid question from the sidelines time: how exactly would one go about volunteering to work on Erlang/OTP with things like documentation and the like? -- Michael T. Richter (GoogleTalk: ttmrichter) We should sell bloat credits, the way the government sells pollution credits. Everybody's assigned a certain amount of bloat, and if they go over, they have to purchase bloat credits from some other group that's been more careful. (Bent Hagemark) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/faebeff2/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/faebeff2/attachment.bin From ttmrichter Sun Mar 2 07:57:32 2008 From: ttmrichter (Michael T. Richter) Date: Sun, 02 Mar 2008 14:57:32 +0800 Subject: [erlang-questions] what does the "B" in R12B means? In-Reply-To: <20080302052734.GA26505@Sun.Com> References: <20080302052734.GA26505@Sun.Com> Message-ID: <1204441052.804.4.camel@isolde> > I am creating a package for Erlang. I wonder which is a better > directory name to install it, /usr/erlang/R12, or /usr/erlang/R12B? > I had thought "B" in R12B was minor release number so I perfed > to use /usr/erlang/R12, but is there ever a R12A or R12 release? > I googled them but didn't find. I'm guessing "R12B1" means "Revision 12, Build 1" or the like. -- Michael T. Richter (GoogleTalk: ttmrichter) Experts in advanced countries underestimate by a factor of two to four the ability of people in underdeveloped countries to do anything technical. (Charles P Issawi) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/9373f356/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/9373f356/attachment.bin From elharaty Sun Mar 2 08:10:41 2008 From: elharaty (Emad El-Haraty) Date: Sat, 1 Mar 2008 23:10:41 -0800 Subject: [erlang-questions] crypto:rand_bytes/3 Message-ID: Hi, Browsing through crypto.erl, I noticed the exported but undocumented function crypto:rand_bytes/3. The three parameters it takes are: Bytes, Topmask, Bottommask Bytes is the number of random bytes you would like generated Topmask is the value that will be used in performing a bitwise or on the final byte (of the bytes generated) Bottommask is the value the will be used in performing a bitwise or on the first byte. RAND_pseudo_bytes(bin->orig_bytes,rlen); or_mask = ((unsigned char*)buf)[4]; bin->orig_bytes[rlen-1] |= or_mask; /* topmask */ or_mask = ((unsigned char*)buf)[5]; bin->orig_bytes[0] |= or_mask; /* bottommask */ Just out of curiosity, what use would someone have for this ability to mask only the first or final bytes of a randomly generated set of bytes? -- Emad El-Haraty "I sure wish there was a way to transform c source into some sort of machine code" From Raymond.Xiong Sun Mar 2 08:33:28 2008 From: Raymond.Xiong (Raymond Xiong) Date: Sun, 02 Mar 2008 15:33:28 +0800 Subject: [erlang-questions] what does the "B" in R12B means? In-Reply-To: <1204441052.804.4.camel@isolde> References: <20080302052734.GA26505@Sun.Com> <1204441052.804.4.camel@isolde> Message-ID: <20080302073327.GA27269@Sun.Com> On 03/02/08, Michael T. Richter wrote: > > I am creating a package for Erlang. I wonder which is a better > > directory name to install it, /usr/erlang/R12, or /usr/erlang/R12B? > > > > > I had thought "B" in R12B was minor release number so I perfed > > to use /usr/erlang/R12, but is there ever a R12A or R12 release? > > I googled them but didn't find. > > > > I'm guessing "R12B1" means "Revision 12, Build 1" or the like. > No, I don't think so. Below is from Erlang FAQ: R11B-4: Release 11B, patchlevel 4 But I am not sure what "B" means. Can I interpret "R11B" as "Release 11 Revision B"? -- Regards, Raymond From matthias Sun Mar 2 08:53:17 2008 From: matthias (Matthias Lang) Date: Sun, 2 Mar 2008 08:53:17 +0100 Subject: [erlang-questions] what does the "B" in R12B means? In-Reply-To: <20080302073327.GA27269@Sun.Com> References: <20080302052734.GA26505@Sun.Com> <1204441052.804.4.camel@isolde> <20080302073327.GA27269@Sun.Com> Message-ID: <18378.23789.892220.991598@antilipe.corelatus.se> > > > I had thought "B" in R12B was minor release number so I perfed > > > to use /usr/erlang/R12, but is there ever a R12A or R12 release? > > > I googled them but didn't find. > But I am not sure what "B" means. Can I interpret "R11B" as > "Release 11 Revision B"? Yeah, pretty much. R means release. 11 or 12 is the major release number A B C is the minor 'number' Sometimes the 'patchlevel' is added as a suffix, i.e. -0 then -1 then -2. By tradition, the A release is so dangerous that only a select few developers with full safety gear are allowed to test it in a special closed facility south of Stockholm. The B release is the first one everyone gets to see. Sometimes, the B release is followed by a C release, for instance R9C was around for quite some time (you can still find it on the downloads page). Matt From Raymond.Xiong Sun Mar 2 09:19:00 2008 From: Raymond.Xiong (Raymond Xiong) Date: Sun, 02 Mar 2008 16:19:00 +0800 Subject: [erlang-questions] what does the "B" in R12B means? In-Reply-To: <18378.23789.892220.991598@antilipe.corelatus.se> References: <20080302052734.GA26505@Sun.Com> <1204441052.804.4.camel@isolde> <20080302073327.GA27269@Sun.Com> <18378.23789.892220.991598@antilipe.corelatus.se> Message-ID: <20080302081859.GA27532@Sun.Com> On 03/02/08, Matthias Lang wrote: > > R means release. > 11 or 12 is the major release number > A B C is the minor 'number' > > Sometimes the 'patchlevel' is added as a suffix, i.e. -0 then -1 then -2. > > By tradition, the A release is so dangerous that only a select few > developers with full safety gear are allowed to test it in a special > closed facility south of Stockholm. The B release is the first one > everyone gets to see. Sometimes, the B release is followed by a C > release, for instance R9C was around for quite some time (you can > still find it on the downloads page). Thanks, it is clear now. The first time I saw the name, I thought "B" was "Beta". :) -- Regards, Raymond From torben.lehoff Sun Mar 2 09:36:07 2008 From: torben.lehoff (Torben Hoffmann) Date: Sun, 2 Mar 2008 09:36:07 +0100 Subject: [erlang-questions] PS3 and Erlang (Re: Google Summer of Code 2008) In-Reply-To: <200803010300.03522.roger.larsson@e-gatan.se> References: <510A206C-8ACA-4C62-86E7-1E807BEA7581@telegraphics.com.au> <47C79A70.1040108@ghostgun.com> <200803010300.03522.roger.larsson@e-gatan.se> Message-ID: On Sat, Mar 1, 2008 at 3:00 AM, Roger Larsson wrote: > On fredag 29 februari 2008, jm wrote: > > Toby Thain wrote: > > >> * Organise a list of project ideas that we'd like students to work > > >> on. > > > > > > One perennial topic is porting Erlang to embedded/tiny systems, and > > > how small the runtime can feasibly be. > > > > Should I mention PS3 and the Cell. > > I have a PS3 myself (with Linux installed). I have been thinking about > how much a PS3 resembles a telephone exchange... And we all know what > language to use for programming those! > > You have the SPEs (and Altivec) connected via an exchange and you would > like to make the best use of the resources. > > Avoid moving executions from one SPE to another (keep the code in > SPE memory) - but on the same time the work might require being split > to several SPEs to meet deadlines (real time games). > [IBM has a real time ray tracer that dynamically how big part of the > image is computed by what SPE] > > Move the data to the right SPE, but there are rules about how to do this > most efficient using the built in exchange. If data can remain on a SPE > keep it there. > > An outline: > * building the work scheduler in Erlang > * data, binary arrays (required by the SPEs and PowerPC Altivec) > * executables, in form of binary objects (SPE, Altivec, or PowerPC > executable) > * work descriptors, connecting executables with data > * building simulation in Erlang, create work descriptors depending on > events. > > Wouldn't that make an interesting summer project! > > /RogerL Depending on the direction of the projects I offer myself as a mentor (need co-mentor(s) since I will be off-line for some time during the summer). I have worked with Erlang/OTP for almost 2 years now - the last year full time on a project which creates a telephone exchange where we have dealt with encoding and decoding of Q.SIG (PSS1) plus the Q.SIG protocol stack itself as well as an interface to layer 2 with a C-port. If those experiences can be used contact me. Cheers, Torben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/4a1005d8/attachment-0001.html From twoggle Sun Mar 2 10:46:16 2008 From: twoggle (Tim Fletcher) Date: Sun, 2 Mar 2008 09:46:16 +0000 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: > I have finally released LFE, Lisp Flavoured Erlang, which is a lisp syntax > front-end to the Erlang compiler. Does it require a particular version of Erlang? From richardc Sun Mar 2 13:15:31 2008 From: richardc (Richard Carlsson) Date: Sun, 02 Mar 2008 13:15:31 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: <47CA9A63.6030904@it.uu.se> Robert Virding wrote: > Function bindings > ----------------- > > Core Erlang (and Erlang and the BEAM) separate variable and function > bindings. A function binding has a name and an arity, this is a result > of allowing different functions to have the same name but different > number of arguments. Also there is no concept of a function reference > built into the Core and BEAM. It is therefore impossible to get a > reference to a function and pass it around, creating a fun which calls > this function is not the same thing. So code like: > > In CL: (funcall #'cons a b) > In Scheme: (let ((my-cons cons)) (my-cons a b)) > > CANNOT work in Erlang. I think you can relax, Robert. This is not a problem. In plain Erlang, you'd write MyCons = fun cons/2, MyCons(A,B) In Core Erlang, you write it like this: let MyCons = 'cons'/2 in apply MyCons(A, B) Neither of these things mean that you'll necessarily get another closure that will delegate the call - that's an old implementation detail, which is not universally valid anymore. (E.g., with inlining enabled, this will reduce to a direct call "cons(A, B)".) And in particular, there is just a single variable namespace. You're right that Core Erlang has no special notation ("fun f/N") for referring to a function (as opposed to defining it) - that's because the keyword "fun" is not needed. Core Erlang has two flavours of variables: normal Erlang-style variables, and 'atom'/integer function names. (We could actually have used only the first form, but then the Core Erlang code would be harder to understand, and the export section would have to look something like "export [ F17 as 'foo'/2, F32 as 'bar'/1, ... ]".) You can only define function-name variables in letrec-expressions, not in let-expressions, but this is no limitation in general, since you can easily bind a plain variable to a function-name variable, as above. The main point here is: when you see some expression "'f'/3" in Core Erlang or "fun f/3" in Erlang, think of it as just a name, a variable. Forget about how "fun f/3" was originally implemented. This is one of the big things about Core Erlang: except for when you need to create names of exported functions, that will be visible outside the module, a variable is just a reference to some value, functional or not, and it does not matter whether it was defined in a letrec or a let. This makes it much easier to do transformations like inlining on the Core language level. /Richard PS. I know that it's not easy to grok the full consequences of the Core Erlang specification; one has to sort of clear one's mind and start from scratch - if the spec doesn't prohibit something, then it should just work (assuming that the compiler doesn't have a bug or is incomplete). [http://www.it.uu.se/research/group/hipe/cerl/doc/core_erlang-1.0.3.pdf] If you need human assistance to interpret some detail, just mail me. From erlang Sun Mar 2 16:16:45 2008 From: erlang (Joe Armstrong) Date: Sun, 2 Mar 2008 16:16:45 +0100 Subject: [erlang-questions] Use of makefiles In-Reply-To: <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> Message-ID: <9b08084c0803020716h1481a11ne08ab712878ae901@mail.gmail.com> On a slightly different track - I was thinking the other that one of the problems we face to today is a totally bewildering amount of choice. When I started program I could choose between FORTRAN and well ummmm .... FORTRAN - so I chose FORTRAN - for *everything* there were no scripting languages and only a line editor (not even full screen) and not even a hierarchical file system (max ten letters for the file name and three for the extension) This meant there was no wasted time in choosing tools - there were no tools - If you wanted a tool you'd write it yourself - (so I "invented" email and text formatting languages and loads of other little tools all for myself). Now we have a bewildering amount of choice between large numbers of tools that "almost" solve our problems - The trouble is that fixing them to do "exactly" what we want (and not almost) can be almost impossibly difficult. Take a look at this talk http://www.ted.com/index.php/talks/view/id/93 His thesis is "too much choice ..." ... "equals paralysis" and makes us less satisfied with the results. I had no expectation that FORTRAN would be good for everything - it was not. The secret to programming bliss is low expectations - all tools are terrible (at least compared to our brains) and no tool will radically change this. Emacs and make are less bad than many of the alternatives ... /Joe On Sun, Mar 2, 2008 at 3:41 AM, Steve Vinoski wrote: > On 2/29/08, Joe Armstrong wrote: > > In general I try to use *generic* tools for all programing tasks, for > > me this means that > > make, emacs, bash, and xterm are constants for all projects. The only > > bit that varies is the choice > > of programming language. > > > > When I learn a new language all I have to do is learn the language - > > all the other tools say the same - > > in the long term this is far better than learning specific tools for > > each language - it allows me to concentrate > > on the important details (learning the new language) and not get > > bogged down in the details of the support > > system. (This is also why I *hate* visual environments - each one is > > *different*, text tools stay the same > > across machine and time boundaries). I can (and do) run makefiles that > > are 15 years old - the same cannot be said for visual build > > environments. > > Hi Joe, I agree with you 100%. Give me emacs (with its vast emacs-lisp > extensibility), bash (or ksh), and various UNIX command-line tools, > which I can combine as I wish using pipes, and keep the visual tools > out of my way (and out of my RAM). > > Here's a very insightful explanation of the differences between those > of us who look to languages for productivity, and others who instead > look to tools and IDEs for productivity: > > > > --steve > From masterofquestions Sun Mar 2 18:54:15 2008 From: masterofquestions (db) Date: Sun, 2 Mar 2008 12:54:15 -0500 Subject: [erlang-questions] gen_cron question Message-ID: <1218d6a50803020954y6f12529eo9ed08d517a879b48@mail.gmail.com> I need to purge 10 mnesia tables on day/hourly interval. I am looking at http://code.google.com/p/gencron/ to accomplish this. Documentation says gen_cron pretty much like gen_server. I am not an expert in gen_server. I want to create 1 process for each table to perform purging. Do I create 10 process intially and have them sleep on the interval or gen_cron starts these 10 process on interval? Any sample gen_cron example out there? Gen_cron seems to consider a task as a module. What if I want to run two different modules, do I start two different gen_cron with two different name? -- rk That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. -Ralph Waldo Emerson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/3c8e2125/attachment.html From pablosan Sun Mar 2 19:30:40 2008 From: pablosan (Paul Nelson) Date: Sun, 2 Mar 2008 12:30:40 -0600 Subject: [erlang-questions] Use of makefiles In-Reply-To: <9b08084c0803020716h1481a11ne08ab712878ae901@mail.gmail.com> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <9b08084c0803020716h1481a11ne08ab712878ae901@mail.gmail.com> Message-ID: So, Fortran is your one pair of terrible fitting jeans before there were so many options. My question is "is it possible to become more satisfied by artificially limiting our choices?" For builds, if I force myself to only use make, even though I know there are so many more possibilities, will I be more satisfied with the results? To answer my own question, I think once you've opened Pandora's box you can never go back. I also think that, once opened, artificially limiting the choices a particular Pandora's box provided is better than no limits. On Sun, Mar 2, 2008 at 9:16 AM, Joe Armstrong wrote: > On a slightly different track - I was thinking the other that one of > the problems we face to today is > a totally bewildering amount of choice. > > When I started program I could choose between FORTRAN and > well ummmm .... FORTRAN - so I chose FORTRAN - for *everything* there > were no scripting languages > and only a line editor (not even full screen) and not even a > hierarchical file system (max ten letters for the file name and > three for the extension) > > This meant there was no wasted time in choosing tools - there were no > tools - If you wanted a tool you'd write it > yourself - (so I "invented" email and text formatting languages and > loads of other little tools all for myself). > > Now we have a bewildering amount of choice between large numbers of > tools that "almost" solve our problems - > The trouble is that fixing them to do "exactly" what we want (and not > almost) can be almost impossibly difficult. > > Take a look at this talk > > http://www.ted.com/index.php/talks/view/id/93 > > His thesis is "too much choice ..." ... "equals paralysis" and makes > us less satisfied with the results. > > I had no expectation that FORTRAN would be good for everything - it > was not. The secret > to programming bliss is low expectations - all tools are terrible (at > least compared to our > brains) and no tool will radically change this. Emacs and make are > less bad than many of the > alternatives ... > > /Joe > > > > > > On Sun, Mar 2, 2008 at 3:41 AM, Steve Vinoski wrote: > > On 2/29/08, Joe Armstrong wrote: > > > In general I try to use *generic* tools for all programing tasks, > for > > > me this means that > > > make, emacs, bash, and xterm are constants for all projects. The > only > > > bit that varies is the choice > > > of programming language. > > > > > > When I learn a new language all I have to do is learn the language - > > > all the other tools say the same - > > > in the long term this is far better than learning specific tools for > > > each language - it allows me to concentrate > > > on the important details (learning the new language) and not get > > > bogged down in the details of the support > > > system. (This is also why I *hate* visual environments - each one is > > > *different*, text tools stay the same > > > across machine and time boundaries). I can (and do) run makefiles > that > > > are 15 years old - the same cannot be said for visual build > > > environments. > > > > Hi Joe, I agree with you 100%. Give me emacs (with its vast emacs-lisp > > extensibility), bash (or ksh), and various UNIX command-line tools, > > which I can combine as I wish using pipes, and keep the visual tools > > out of my way (and out of my RAM). > > > > Here's a very insightful explanation of the differences between those > > of us who look to languages for productivity, and others who instead > > look to tools and IDEs for productivity: > > > > > > > > --steve > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Salient Blue. It's NOT people. My blog: http://blog.salientblue.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/047df24d/attachment.html From kevin Sun Mar 2 21:19:27 2008 From: kevin (Kevin A. Smith) Date: Sun, 2 Mar 2008 15:19:27 -0500 Subject: [erlang-questions] Library lookup path Message-ID: <327832CD-BC05-41F1-AEE9-1FDBF886BD8C@hypotheticalabs.com> How do I tell Erlang to look in additional places for libraries? I've got a build script which builds a set of libraries and puts them in a directory named build. Each library gets its own subdirectory like so: build/foo-0.1, build/bar-0.1, etc. Right now, I'm symlinking these directories into $ROOT/lib so that Erlang can find them at runtime. What I'd really like to be able to do is pass erl a flag, like -pa/- pz, and tell it where to find these libs. Does something like this exist? Thanks, Kevin From rsaccon Sun Mar 2 21:22:58 2008 From: rsaccon (Roberto Saccon) Date: Sun, 2 Mar 2008 17:22:58 -0300 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <47CA9A63.6030904@it.uu.se> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <47CA9A63.6030904@it.uu.se> Message-ID: Amazing ! Thanks for sharing. I have a little question about an implementaiton detail: Is there a particular reason for setting the linenumber to 6666 in annotations where there is no associated Lisp source code ? Roberto On Sun, Mar 2, 2008 at 9:15 AM, Richard Carlsson wrote: > Robert Virding wrote: > > Function bindings > > ----------------- > > > > Core Erlang (and Erlang and the BEAM) separate variable and function > > bindings. A function binding has a name and an arity, this is a result > > of allowing different functions to have the same name but different > > number of arguments. Also there is no concept of a function reference > > built into the Core and BEAM. It is therefore impossible to get a > > reference to a function and pass it around, creating a fun which calls > > this function is not the same thing. So code like: > > > > In CL: (funcall #'cons a b) > > In Scheme: (let ((my-cons cons)) (my-cons a b)) > > > > CANNOT work in Erlang. > > I think you can relax, Robert. This is not a problem. > > In plain Erlang, you'd write > > MyCons = fun cons/2, > MyCons(A,B) > > In Core Erlang, you write it like this: > > let MyCons = 'cons'/2 in apply MyCons(A, B) > > Neither of these things mean that you'll necessarily get another > closure that will delegate the call - that's an old implementation > detail, which is not universally valid anymore. (E.g., with inlining > enabled, this will reduce to a direct call "cons(A, B)".) And in > particular, there is just a single variable namespace. > > You're right that Core Erlang has no special notation ("fun f/N") for > referring to a function (as opposed to defining it) - that's because the > keyword "fun" is not needed. Core Erlang has two flavours of variables: > normal Erlang-style variables, and 'atom'/integer function names. (We > could actually have used only the first form, but then the Core Erlang > code would be harder to understand, and the export section would have to > look something like "export [ F17 as 'foo'/2, F32 as 'bar'/1, ... ]".) > You can only define function-name variables in letrec-expressions, not > in let-expressions, but this is no limitation in general, since you can > easily bind a plain variable to a function-name variable, as above. > > The main point here is: when you see some expression "'f'/3" in Core > Erlang or "fun f/3" in Erlang, think of it as just a name, a variable. > Forget about how "fun f/3" was originally implemented. This is one of > the big things about Core Erlang: except for when you need to create > names of exported functions, that will be visible outside the module, > a variable is just a reference to some value, functional or not, and > it does not matter whether it was defined in a letrec or a let. This > makes it much easier to do transformations like inlining on the Core > language level. > > /Richard > > PS. I know that it's not easy to grok the full consequences of the Core > Erlang specification; one has to sort of clear one's mind and start from > scratch - if the spec doesn't prohibit something, then it should just > work (assuming that the compiler doesn't have a bug or is incomplete). > > [http://www.it.uu.se/research/group/hipe/cerl/doc/core_erlang-1.0.3.pdf] > > If you need human assistance to interpret some detail, just mail me. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Roberto Saccon http://rsaccon.com From hasan.veldstra Sun Mar 2 21:45:05 2008 From: hasan.veldstra (Hasan Veldstra) Date: Sun, 2 Mar 2008 20:45:05 +0000 Subject: [erlang-questions] Library lookup path In-Reply-To: <327832CD-BC05-41F1-AEE9-1FDBF886BD8C@hypotheticalabs.com> References: <327832CD-BC05-41F1-AEE9-1FDBF886BD8C@hypotheticalabs.com> Message-ID: > How do I tell Erlang to look in additional places for libraries? I've > got a build script which builds a set of libraries and puts them in a > directory named build. Each library gets its own subdirectory like so: > build/foo-0.1, build/bar-0.1, etc. Right now, I'm symlinking these > directories into $ROOT/lib so that Erlang can find them at runtime. > What I'd really like to be able to do is pass erl a flag, like -pa/- > pz, and tell it where to find these libs. Does something like this > exist? You can use code:add_path()/add_patha(), in ~/.erlang for example. From alpar Sun Mar 2 22:56:50 2008 From: alpar (=?ISO-8859-1?Q?Alp=E1r_J=FCttner?=) Date: Sun, 02 Mar 2008 21:56:50 +0000 Subject: [erlang-questions] Use of makefiles In-Reply-To: <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> Message-ID: <1204495010.6990.95.camel@piko.site> Really can't understand this ``using emacs vs. some kind of IDE'' debate. I have been using emacs for a very long time for almost everything (see my comment below). I really love it, it fits my needs far more than anything else. But emacs _is_ an IDE (Integrated Development Environment), as well. It does syntax highlighting, I can compile my code from it, I can jump to the line caused the syntax error. It can also execute or debug the compiled code. Its gdb-based debugger is not behind any other IDE's source code debugger. It also supports project based working by its Makefile and autotool support and also by supporting virtually all version control systems (cvs, svn, git, hg, bzr etc.). It even provides a conventional menu and toolbar today. In fact, it _integrates_ even more development tools than any other IDE. For example it has nice integrated shell, e-mail support, file manager etc. The real difference is that while Visual Studio or Eclipse want to be as easy-to-learn as possible, emacs assumes that you are willing to learn something new and unusual in order to achieve higher productivity. I think the same applies to 'make' and also to the autotools. Regards, Alpar P.S. My biggest problem with emacs is the lack of built-in concurrency. For example I used to use its e-mail client RMAIL and I was quite satisfied with it. But I had to change, because around 2002 my company (Ericsson) changed to another mail server which answered very slowly to POP3 requests and thus it blocked my emacs for a long time at each mailbox refreshing. The same problem arises at other places like in emacs/w3 and it often makes the design of emacs tools very complex (e.g. emacs-gdb). Now - as I now a little bit about erlang - I wish emacs had been written in this great language instead. On Sat, 2008-03-01 at 21:41 -0500, Steve Vinoski wrote: > On 2/29/08, Joe Armstrong wrote: > > In general I try to use *generic* tools for all programing tasks, for > > me this means that > > make, emacs, bash, and xterm are constants for all projects. The only > > bit that varies is the choice > > of programming language. > > > > When I learn a new language all I have to do is learn the language - > > all the other tools say the same - > > in the long term this is far better than learning specific tools for > > each language - it allows me to concentrate > > on the important details (learning the new language) and not get > > bogged down in the details of the support > > system. (This is also why I *hate* visual environments - each one is > > *different*, text tools stay the same > > across machine and time boundaries). I can (and do) run makefiles that > > are 15 years old - the same cannot be said for visual build > > environments. > > Hi Joe, I agree with you 100%. Give me emacs (with its vast emacs-lisp > extensibility), bash (or ksh), and various UNIX command-line tools, > which I can combine as I wish using pipes, and keep the visual tools > out of my way (and out of my RAM). > > Here's a very insightful explanation of the differences between those > of us who look to languages for productivity, and others who instead > look to tools and IDEs for productivity: > > > > --steve > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From rvirding Sun Mar 2 23:10:12 2008 From: rvirding (Robert Virding) Date: Sun, 2 Mar 2008 23:10:12 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: <3dbc6d1c0803021410j3cb1ea53s935c0669d82efd4b@mail.gmail.com> OK, some points I forgot to mention: - Of course, the interpreter does *NOT* handle recursive letrecs, binaries, receive or try. Yet. - The token syntax is specified in leex but I have included a copy of a generated erlang file. - The compiler is "sensitive" to some errors and will occasionally crash, though it should only generate correct code. - The line numbers used in error messages are the line of the beginning of the form in which the error occurs. As the forms are truly raw data this was the best way I could get line numbers in. The answer to Roberto's question about line number 6666 is just I wanted a big number which was guaranteed not to clash with users code. And 666 seemed to small. :-) - I have been thinking about a way to load a module into the shell (when it exists) and I think I have worked out a way to do it. With a little bit of luck it should also support macros. You might actually be able to save a module from the shell as well but I have not thought this through properly yet. Please report bugs and other mis-features and I will fix them as soon as I can. Unfortunately I am using a toy computer so sending out patches will be difficult. Robert On 02/03/2008, Robert Virding wrote: > > I have finally released LFE, Lisp Flavoured Erlang, which is a lisp syntax > front-end to the Erlang compiler. Code produced with it is compatible with > "normal" Erlang code. The is an LFE-mode for Emacs and the lfe-mode.elfile is include in the distribution. Most things seem to work but some > things have not been done yet: > > - The interpreter does handle recursive letrecs, binaries, receive or try. > > - There is no lisp shell. > - Documentation! > > Yet. The system will be updated as new features are added. This is the 1st > release so there is much left to do. > > I have include the existing documentation lfe_guide.txt in this mail. > There are a number of LFE test files and a version of the LFE interpreter > written in LFE as examples of code. There are also a number of issues which > need to be decided for the next version and I have included a file > lfe_issues.txt which describe them in this mail. Both files are in the > distribution. > > Note that while this this lisp has been inspired by Scheme (one of the > issues) it is a NOT Scheme, it is Erlang with a lisp syntax and many nice > lisp features. Not for that matter is it Common Lisp. In fact features of > the Erlang engine mean that it is actually impossible to implement full > Scheme of CL. No, they shouldn't be changed or added. > > It was quite writing Erlang code in lisp and I could easily consider using > a lisp syntax for Erlang. I suppose it depends where your preferences lye. > It was also easy to get into the traditional lisp habit of using long names > for everything which I personally think is not a Good Thing. Perhaps we > should do AFE, Arc Flavoured Erlang, instead? Although I think they have > gone too far and missed what makes programs easy to read. > > Macros are very nice, and it is easy to generate LFE code, which is one of > the benefits of lisp syntax. > > LFE also shows that it would probably be possible to write other > front-ends inspired by other languages, though why anyone should want to I > don't know. Perhaps back to a real Prolog syntax again. > > The system can be found in the "User Contributions" section at > trapexit.org, http://forum.trapexit.org/viewtopic.php?p=40268#40268. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/8eb9e11e/attachment.html From rvirding Sun Mar 2 23:15:11 2008 From: rvirding (Robert Virding) Date: Sun, 2 Mar 2008 23:15:11 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: <3dbc6d1c0803021415x563ca421l19b6e15b4c1bb42d@mail.gmail.com> On 02/03/2008, Tim Fletcher wrote: > > > I have finally released LFE, Lisp Flavoured Erlang, which is a lisp > syntax > > front-end to the Erlang compiler. > > > Does it require a particular version of Erlang? It was developed on R12B-0 but I don't think there should be any trouble on running it on R11B. I don't think that Core has changed very much, at least at the level I am using it. Let me know if you detect anything strange. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080302/068717ce/attachment.html From valentin Sat Mar 1 16:35:54 2008 From: valentin (Valentin Micic) Date: Sat, 1 Mar 2008 17:35:54 +0200 Subject: [erlang-questions] hipe binary matching problem with R12B-1? References: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> <47C91B36.90601@cs.ntua.gr> <02af01c87b91$613f9390$6401a8c0@moneymaker2> <47C96DCE.7070600@cs.ntua.gr> Message-ID: <06b601c87bb1$f3b93c10$6401a8c0@moneymaker2> Errr... I've made a mistake -- been using wrong e-mail to ask the question. There was a similar thread "Binary pattern matching inconsistencies with R12B", which described situations causing segmentation faults due to, as you've put it -- GC issues in BEAM. That particular correspondence makes a reference to Linux, and I've been trying to ask if anybody noticed similar problems (segmentation fault) on Solaris. By the same token, I've been asking if R11 is still safer (considering GC problems you've been mentioning) choice for Linux. Mind you, I think that compiler bugs are just a matter of inconvenience -- BEAM bugs, on the other hand, are matter of survival ;-). Once again my apologies. Did not mean to criticize HiPE -- in fact, I've never used it, so how could I? Hoping you'll find this a reasonable explanation: could you, or anyone from development team answer these two questions, now put in a proper context? V. ----- Original Message ----- From: "Kostis Sagonas" To: "Erlang" Cc: "Valentin Micic" Sent: Saturday, March 01, 2008 4:53 PM Subject: Re: [erlang-questions] hipe binary matching problem with R12B-1? > Valentin Micic wrote: >> From: "Kostis Sagonas" >> >>> Yes, this is a bug. We will fix it >> >> May I ask if this bug is limited to Linux, or it is unversal to all >> supported platforms (e.g. Solaris). > > Yes. This is generic. It happens on all platforms I've tested. > >> Would it be safe to assume that R11 is still the safest bet for Linux? > > I've no idea what you have in mind. As far as the HiPE compiler is > concerned, this is the first bug I recall in a long while. In fact, this > particular one aside, there are no outstanding bugs I know of -- which of > course does not preclude the existence of bugs I know nothing about. > > In any case, to answer your question, I am not aware of any good reasons > for somebody to prefer R11 over R12 as far as HiPE is concerned. > > I'm willing to bet the situation is similar for BEAM: most (if not all) > R11 compiler bugs have been fixed in R12 and the Erlang/OTP team has been > *very* responsive in correcting and publishing patches for all R12 > compiler problems that have been reported in this list. > > Kostis From armando Sun Mar 2 23:30:17 2008 From: armando (Armando Di Cianno) Date: Sun, 02 Mar 2008 17:30:17 -0500 Subject: [erlang-questions] Use of makefiles In-Reply-To: <1204495010.6990.95.camel@piko.site> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <1204495010.6990.95.camel@piko.site> Message-ID: <1204497017.8978.18.camel@localhost> Humor me as I complete taking this thread off-topic ... On Sun, 2008-03-02 at 21:56 +0000, Alp?r J?ttner wrote: > The real difference is that while Visual Studio or Eclipse want to be > as > easy-to-learn as possible, emacs assumes that you are willing to learn > something new and unusual in order to achieve higher productivity. I think the difference may be as simple as the naming -- an IDE, by definiton is an Integrated Development Environment. For example, you aren't going to be doing Ruby development in Visual C++ IDE. The point is that by it's /integration/ into your language/s of choice, it removes "distractions" of things you would never use outside the scope of the language you're writing in. However, then as scope broadens, you suddenly need to learn a new tool, or at least a new component. Emacs, though *incredibly* obtuse at first glance, is -- as far as I can tell, and have surmised -- an "Extensible Development Environment". Because it's /extensible/, development itself isn't necessarily stuck to only the programming variety -- you can have a Latex edit-render cycle going, you can be running a "Getting Things Done"-style personal manager -- you can replace /sbin/init with emacs if you really want to. Emacs isn't necessarily difficult to learn either. I spent 13 years using Vi/M, and was happy as a camper. Erlang, and it's wonderful support in Emacs, changed that for me -- it gave me the drive and desire to learn Emacs, finally. Emacs does have it's blemishes. In just under 6 months of emacs use, I can't wrap my head around why people are still debating such things as wheither Emacs Undo/Redo is superior or not -- to me, if it's not obvious to everyone, it's then by definition, *not obvious*. ;-) Just my 2?, -- Armando Di Cianno http://dicianno.org/blog armando armando From kostis Sun Mar 2 23:49:10 2008 From: kostis (Kostis Sagonas) Date: Mon, 03 Mar 2008 00:49:10 +0200 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803021410j3cb1ea53s935c0669d82efd4b@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <3dbc6d1c0803021410j3cb1ea53s935c0669d82efd4b@mail.gmail.com> Message-ID: <47CB2EE6.2090506@cs.ntua.gr> Robert Virding wrote: > > Please report bugs and other mis-features and I will fix them as soon as > I can. Well, since you asked for it, at a click of a button dialyzer reports the following: lfe_scan.erl:215: The pattern can never match the type <_,_,'error' | 'skip_token' | {'error',[32 | 97 | 99 | 101 | 103 | 104 | 105 | 108 | 114 | 116,...]},_> lfe_scan.erl:164: The pattern can never match the type <_,_,'error' | 'skip_token' | {'error',[32 | 97 | 99 | 101 | 103 | 104 | 105 | 108 | 114 | 116,...]}> lfe_scan.erl:118: The pattern can never match the type <_,_,'error' | 'skip_token' | {'error',[32 | 97 | 99 | 101 | 103 | 104 | 105 | 108 | 114 | 116,...]},[{atom(),_} | {'number',_,_} | {'string',_,[any()]} | {'symbol',_,atom()}]> lfe_scan.erl:255: The pattern can never match the type <_,_,'error' | 'skip_token' | {'error',[32 | 97 | 99 | 101 | 103 | 104 | 105 | 108 | 114 | 116,...]},_> lfe_macro.erl:490: The pattern {'yes', _} can never match the type 'error' | {'ok',_} lfe_macro.erl:489: The pattern {'yes', _} can never match the type 'error' | {'ok',_} The first set is just dead clauses. The second set, is a mismatch of the return value of a function. Dialyzer also reports some more additional warnings which are also reported by the BEAM compiler, so I am suppressing these. Cheers, Kostis From rvirding Mon Mar 3 00:04:22 2008 From: rvirding (Robert Virding) Date: Mon, 3 Mar 2008 00:04:22 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <47CB2EE6.2090506@cs.ntua.gr> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <3dbc6d1c0803021410j3cb1ea53s935c0669d82efd4b@mail.gmail.com> <47CB2EE6.2090506@cs.ntua.gr> Message-ID: <3dbc6d1c0803021504va35fcb3u1250ae3a9e7d8674@mail.gmail.com> On 02/03/2008, Kostis Sagonas wrote: > > Robert Virding wrote: > > > > Please report bugs and other mis-features and I will fix them as soon as > > I can. > > > Well, since you asked for it, at a click of a button dialyzer reports > the following: > > lfe_scan.erl:215: The pattern can > never match the type <_,_,'error' | 'skip_token' | {'error',[32 | 97 | > 99 | 101 | 103 | 104 | 105 | 108 | 114 | 116,...]},_> > lfe_scan.erl:164: The pattern can never > match the type <_,_,'error' | 'skip_token' | {'error',[32 | 97 | 99 | > 101 | 103 | 104 | 105 | 108 | 114 | 116,...]}> > lfe_scan.erl:118: The pattern can > never match the type <_,_,'error' | 'skip_token' | {'error',[32 | 97 | > 99 | 101 | 103 | 104 | 105 | 108 | 114 | 116,...]},[{atom(),_} | > {'number',_,_} | {'string',_,[any()]} | {'symbol',_,atom()}]> > lfe_scan.erl:255: The pattern can > never match the type <_,_,'error' | 'skip_token' | {'error',[32 | 97 | > 99 | 101 | 103 | 104 | 105 | 108 | 114 | 116,...]},_> > > lfe_macro.erl:490: The pattern {'yes', _} can never match the type > 'error' | {'ok',_} > lfe_macro.erl:489: The pattern {'yes', _} can never match the type > 'error' | {'ok',_} > > > The first set is just dead clauses. The second set, is a mismatch of the > return value of a function. The first lot from lfe_scan are just handling a possible legal case which can be used in leex but which I don't use here. You can return a token {end_token,Token} which means that if you use the tokens/2/3 call then it will read tokens up to and including an {end_token,...}. Perfect for Erlang '. '. The second one was a bug, now fixed, thank you. Dialyzer also reports some more additional warnings which are also > reported by the BEAM compiler, so I am suppressing these. None of the compiler warnings are interesting so I ignore them. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/2046d0d4/attachment.html From per Mon Mar 3 01:08:47 2008 From: per (Per Hedeland) Date: Mon, 3 Mar 2008 01:08:47 +0100 (CET) Subject: [erlang-questions] blocking vs non-blocking gen_tcp:accept() In-Reply-To: <47C9BF0E.5040809@hyber.org> Message-ID: <200803030008.m2308lJU082702@pluto.hedeland.org> Claes Wikstrom wrote: > >Matthias Lang wrote: >> Robin writes: >> > Does gen_tcp:accept() block the entire OS thread or just the calling >> > erlang process? >> >> Just the erlang process. (verifying this yourself is straightforward) >> > >Having accept() as function that receives a message as opposed >to hanging would make a lot of sense though. One possibility might be to have gen_tcp:listen() actually obey the {active, X} option with respect to the listen socket. I.e. the current behaviour, which would remain the default, would correspond to {active, false}, and you have to call accept() to get anything to happen. But if you passed {active, once} or {active, true} you wouldn't call accept() at all, but instead get a message e.g. {tcp_accept, ListenSocket, AcceptSocket} when a connection was accepted. (And in the case of {active, once} you'd then have to set the option again before another accept can happen.) One problem with that is that it isn't backwards-compatible though - currently you can give {active, Whatever} to gen_tcp:listen() and it doesn't affect the accept behaviour, but gets "inherited" by the AcceptSocket. If someone uses that functionality for {active, once} or {active, true}, they'd be in for a surprise - but maybe no-one does?:-) ({active, false} is probably common but wouldn't be a problem, and {active, true} would seem pointless since it's the default for the AcceptSocket anyway - which leaves {active, once} as the problem case.) --Per Hedeland From yarivsadan Mon Mar 3 02:44:42 2008 From: yarivsadan (Yariv Sadan) Date: Sun, 2 Mar 2008 17:44:42 -0800 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: <17244f480803021744q582d5e5ek958d82e6264ee425@mail.gmail.com> Robert, this is very cool. I already started playing with LFE and it's great. Thanks a lot for sharing it. I have a couple of suggestions: - it would be nice to have a preprocessor/parse transform that converts the form (foo:bar baz ..) to (: foo bar baz ...) I find the former much more readable. - It would like to have an Erlang-style '=' operator for binding instead of (let). The main difference is in the number of parentheses and the scoping rules. So, instead of (let ((a 1) (b 2)) (+ a b)) you could write (= (a 1) (b 2)) (+ a b) - String literals should be interpreted as literal lists rather than sexps. It seems redundant to write a single quote before a string literal. - It would be great to have syntax for multi-line strings and binaries. - Distributing LFE under a standard open source license would encourage its adoption and foster community contributions. lfe_scan.erl has this license notice: %%% (C)Robert Virding. This stuff is mine, distributed without %%% warranty "as is" and may not be used commercially without letting %%% me know. This wording is ambiguous. Is the only requirement to using LFE commercially to let you know, or it it required to buy a license for commercial use? What happens to user contributions? Etc. Regards, Yariv 2008/3/1 Robert Virding : > I have finally released LFE, Lisp Flavoured Erlang, which is a lisp syntax > front-end to the Erlang compiler. Code produced with it is compatible with > "normal" Erlang code. The is an LFE-mode for Emacs and the lfe-mode.el file > is include in the distribution. Most things seem to work but some things > have not been done yet: > > - The interpreter does handle recursive letrecs, binaries, receive or try. > - There is no lisp shell. > - Documentation! > > Yet. The system will be updated as new features are added. This is the 1st > release so there is much left to do. > > I have include the existing documentation lfe_guide.txt in this mail. There > are a number of LFE test files and a version of the LFE interpreter written > in LFE as examples of code. There are also a number of issues which need to > be decided for the next version and I have included a file lfe_issues.txt > which describe them in this mail. Both files are in the distribution. > > Note that while this this lisp has been inspired by Scheme (one of the > issues) it is a NOT Scheme, it is Erlang with a lisp syntax and many nice > lisp features. Not for that matter is it Common Lisp. In fact features of > the Erlang engine mean that it is actually impossible to implement full > Scheme of CL. No, they shouldn't be changed or added. > > It was quite writing Erlang code in lisp and I could easily consider using a > lisp syntax for Erlang. I suppose it depends where your preferences lye. It > was also easy to get into the traditional lisp habit of using long names for > everything which I personally think is not a Good Thing. Perhaps we should > do AFE, Arc Flavoured Erlang, instead? Although I think they have gone too > far and missed what makes programs easy to read. > > Macros are very nice, and it is easy to generate LFE code, which is one of > the benefits of lisp syntax. > > LFE also shows that it would probably be possible to write other front-ends > inspired by other languages, though why anyone should want to I don't know. > Perhaps back to a real Prolog syntax again. > > The system can be found in the "User Contributions" section at trapexit.org, > http://forum.trapexit.org/viewtopic.php?p=40268#40268. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From wenewboy Mon Mar 3 07:29:08 2008 From: wenewboy (wenew zhang) Date: Mon, 3 Mar 2008 14:29:08 +0800 Subject: [erlang-questions] howto run debugger:start() or pman in ubuntu Message-ID: <4eaa09eb0803022229n72acae8fy6905bd1376961afd@mail.gmail.com> Dear All: i'm setup R12B-1 on ubuntu8.04 and compile it with --with-ssl --with-gd, i run below instructions: /opt/erlang/bin/erlc fsmkvo.erl -debuginfo /opt/erlang/bin/erl debugger:start(). and then,the screen is hold on,no pop main window or other output infos, i test is on gnome and xfce, what can i do? best regards wenew zhang From ulf Mon Mar 3 08:03:47 2008 From: ulf (Ulf Eliasson) Date: Mon, 3 Mar 2008 07:03:47 -0000 (UTC) Subject: [erlang-questions] howto run debugger:start() or pman in ubuntu In-Reply-To: <4eaa09eb0803022229n72acae8fy6905bd1376961afd@mail.gmail.com> References: <4eaa09eb0803022229n72acae8fy6905bd1376961afd@mail.gmail.com> Message-ID: <57003.85.195.15.121.1204527827.squirrel@webmail.erlangsystems.com> Hi, Make sure that you have tcl as well as tk installed, otherwise it will just do nothing when you try to start them. I think it would be better to return an error or something, you can try and do just gs:init(); If that fail it's likely because you don't have TCL and/or TK. Regards, Ulf Eliasson On Mon, March 3, 2008 06:29, wenew zhang wrote: > Dear All: > i'm setup R12B-1 on ubuntu8.04 and compile it with --with-ssl > --with-gd, > i run below instructions: > /opt/erlang/bin/erlc fsmkvo.erl -debuginfo > /opt/erlang/bin/erl > debugger:start(). > > and then,the screen is hold on,no pop main window or other output infos, > i test is on gnome and xfce, > what can i do? > > > best regards > > wenew zhang > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Ulf Eliasson, ulf Erlang Training and Consulting http://www.erlang-consulting.com/ From paul-trapexit Mon Mar 3 08:44:43 2008 From: paul-trapexit (Paul Mineiro) Date: Sun, 2 Mar 2008 23:44:43 -0800 (PST) Subject: [erlang-questions] gen_cron question In-Reply-To: <1218d6a50803020954y6f12529eo9ed08d517a879b48@mail.gmail.com> References: <1218d6a50803020954y6f12529eo9ed08d517a879b48@mail.gmail.com> Message-ID: Hey db, Each gen_cron instance is a single something that needs to run periodically and without overlap. Like gen_server, implementation is split between a container and a callback module. You define the callback module; it's the gen_server interface re-exported with an extra method called handle_tick (which is the "thing-to-do-periodically"). In the tests you can see an example of a gen_cron being started up (http://code.google.com/p/gencron/source/browse/trunk/src/gen_cron.erl#241) and the callback module lives in the tests/ directory (http://code.google.com/p/gencron/source/browse/trunk/tests/gen_cron_test.erl). You pretty much want to define something like gen_cron_test.erl, which takes an mnesia table name as an arguement to init/1, and which does mnesia purging stuff in handle_tick/2. Interestingly purging mnesia tables is the task we made gen_cron for internally. In fact we have this thing called gen_expire built lying around the office that I haven't had a chance to open source yet, which is probably doing something close to what you want. I'm attaching the key files from that, hopefully they are pedagogical. -- p On Sun, 2 Mar 2008, db wrote: > I need to purge 10 mnesia tables on day/hourly interval. I am looking at > http://code.google.com/p/gencron/ to accomplish this. Documentation says > gen_cron pretty much like gen_server. I am not an expert in gen_server. I > want to create 1 process for each table to perform purging. > > Do I create 10 process intially and have them sleep on the interval or > gen_cron starts these 10 process on interval? > > Any sample gen_cron example out there? > > Gen_cron seems to consider a task as a module. What if I want to run two > different modules, do I start two different gen_cron with two different > name? > > > -- > rk > > That which we persist in doing becomes easier for us to do; not that the > nature of the thing itself is changed, but that our power to do is > increased. > -Ralph Waldo Emerson > Optimism is an essential ingredient of innovation. How else can the individual favor change over security? -- Robert Noyce -------------- next part -------------- -module (gen_expire_test). -export ([ start_link/3, stop/1 ]). -behaviour (gen_expire). -export ([ activity_context/2, first/2, next/3, delete/3, finish/1, init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3 ]). -record (mega, { expect }). -include ("../src/gen_expire.hrl"). %-=====================================================================- %- Public - %-=====================================================================- start_link (Interval, Limit, Tab) -> gen_expire:start_link (?MODULE, Interval, [ Limit, Tab ], []). stop (ServerRef) -> gen_server:cast (ServerRef, stop). %-=====================================================================- %- gen_expire callbacks - %-=====================================================================- activity_context (_Table, State = #mega{ expect = Expect }) when (Expect =:= activity_context) orelse (Expect =:= finish) orelse (is_tuple (Expect) andalso element (1, Expect) =:= next) -> { sync_dirty, State#mega{ expect = first } }. first (Table, State = #mega{ expect = first }) -> case mnesia:first (Table) of '$end_of_table' -> { end_of_table, State#mega{ expect = finish } }; Key -> { ok, Key, State#mega{ expect = { next, Table, Key } } } end. next (Table, Key, State = #mega{ expect = { next, Table, Key } }) -> case mnesia:next (Table, Key) of '$end_of_table' -> { end_of_table, State#mega{ expect = { delete, Table, Key } } }; Next -> { ok, Next, State#mega{ expect = { delete, Table, Key } } } end. delete (Table, Key, State = #mega{ expect = { delete, Table, Key } }) -> Expect = case mnesia:next (Table, Key) of '$end_of_table' -> finish; Next -> { next, Table, Next } end, mnesia:delete (Table, Key, write), mnesia:delete (list_to_atom (atom_to_list (Table) ++ "_dup"), Key, write), { ok, State#mega{ expect = Expect } }. finish (#mega{ expect = Expect }) when Expect =:= finish orelse (is_tuple (Expect) andalso element (1, Expect) =:= next) -> timer:sleep (10). init ([ Limit, Tab ]) -> { ok, [ #expirespec{ table = Tab, max_bytes_per_box = Limit } ], #mega{ expect = activity_context } }. handle_call (_Request, _From, State) -> { noreply, State }. handle_cast (stop, State) -> { stop, normal, State }; handle_cast (_Request, State) -> { noreply, State }. handle_info (_Msg, State) -> { noreply, State }. terminate (_Reason, _State) -> ok. code_change (_OldVsn, State, _Extra) -> { ok, State }. -------------- next part -------------- -module (gen_expire). -export ([ force_run/1, start/4, start/5, start_link/4, start_link/5 ]). %-behaviour (behaviour). -export ([ behaviour_info/1 ]). -behaviour (gen_cron). -export ([ init/1, handle_call/3, handle_cast/2, handle_info/2, terminate/2, code_change/3, handle_tick/2 ]). %-behaviour (gen_expire). -export ([ activity_context/2, first/2, next/3, delete/3, finish/1 ]). -include_lib ("flasscheck/include/quickcheck.hrl"). -include_lib ("eunit/include/eunit.hrl"). -include ("gen_expire.hrl"). -define (is_timeout (X), (((X) =:= infinity) orelse (is_integer (X) andalso (X) > 0))). -record (genexpire, { module, speclist, state }). %% @type expirespec() = { expirespec, Table::atom (), MaxBytesPerBox::integer () }. This is the record type #expirespec{ table, max_bytes_per_box }. %-=====================================================================- %- Public - %-=====================================================================- %% @hidden behaviour_info (callbacks) -> [ { activity_context, 2 }, { first, 2 }, { next, 3 }, { delete, 3 }, { finish, 1 }, { init, 1 }, { handle_call, 3 }, { handle_cast, 2 }, { handle_info, 2 }, { terminate, 2 }, { code_change, 3 } ]; behaviour_info (_Other) -> undefined. %% @spec force_run (ServerRef) -> { ok, Pid } | { underway, Pid } %% @doc Schedule an immediate expiration. If the process is already %% executing then { underway, Pid } is returned. %% @end force_run (ServerRef) -> gen_cron:force_run (ServerRef). %% @spec start (Module, Interval::integer (), Args, Options) -> Result %% @doc The analog to gen_server:start/3. Takes an extra argument %% Interval which is the periodic expiration interval in milliseconds. %% @end start (Module, Interval, Args, Options) when ?is_timeout (Interval) -> gen_cron:start (?MODULE, Interval, [ Module | Args ], Options). %% @spec start (ServerName, Module, Interval::integer (), Args, Options) -> Result %% @doc The analog to gen_server:start/4. Takes an extra argument %% Interval which is the periodic expiration interval in milliseconds. %% @end start (ServerName, Module, Interval, Args, Options) when ?is_timeout (Interval) -> gen_cron:start (ServerName, ?MODULE, Interval, [ Module | Args ], Options). %% @spec start_link (Module, Interval::integer (), Args, Options) -> Result %% @doc The analog to gen_server:start_link/3. Takes an extra argument %% Interval which is the periodic expiration interval in milliseconds. %% @end start_link (Module, Interval, Args, Options) when ?is_timeout (Interval) -> gen_cron:start_link (?MODULE, Interval, [ Module | Args ], Options). %% @spec start_link (ServerName, Module, Interval::integer (), Args, Options) -> Result %% @doc The analog to gen_server:start_link/4. Takes an extra argument %% Interval which is the periodic expiration interval in milliseconds. %% @end start_link (ServerName, Module, Interval, Args, Options) when ?is_timeout (Interval) -> gen_cron:start_link (ServerName, ?MODULE, Interval, [ Module | Args ], Options). %-=====================================================================- %- gen_expire callbacks - %-=====================================================================- %% @spec activity_context (atom (), state ()) -> { async_dirty | sync_dirty | transaction | sync_transaction | ets, NewState::state () } %% @doc Indicate what activity context to use for expiring table Table. Note %% that gen_expire holds a global lock on Table which precludes %% other gen_expire instances from expiring the table simultaneously. %% @end activity_context (_Table, _State) -> erlang:throw (not_implemented). %% @spec first (atom (), state ()) -> { ok, Key::any (), NewState::state () } | { end_of_table, NewState::state () } %% @doc Retrieve the first key from the table (fragment). "First" here means %% "in order of desired expiration". %% @end first (_Table, _State) -> erlang:throw (not_implemented). %% @spec next (atom (), any (), state ()) -> { ok, NextKey::any (), NewState::state () } | { end_of_table, NewState::state () } %% @doc Retrieve the next key from the table (fragment). "Next" here means %% "in order of desired expiration". %% @end next (_Table, _Key, _State) -> erlang:throw (not_implemented). %% @spec delete (atom (), any (), state ()) -> { ok, NewState::state () } %% @doc Delete the specified key from the table (fragment). %% @end delete (_Table, _Key, _State) -> erlang:throw (not_implemented). %% @spec finish (state ()) -> void %% @doc Called when gen_expire has finished an expiration run. %% Note that while the state is threaded through %% a complete expiration run, state changes at the end of the expiration %% run are discarded because the expiration occurs in seperate process. %% Therefore this is the opportunity to record any interesting state %% changes, e.g., log statistics. %% @end finish (_State) -> erlang:throw (not_implemented). %-=====================================================================- %- gen_cron callbacks - %-=====================================================================- %% @spec init (Args) -> result () %% result () = { ok, Tabs::list (#expirespec{}), State::any () } | %% { ok, Tabs::list (#expirespec{}), State::any (), Timeout::integer () } | %% { stop, Reason::any () } | %% ignore %% @doc Initialization routine. Like Module:init/1 for gen_server, except %% that a list of #expirespec{} is returned to control expiration behavior. %% @end init ([ Module | Args ]) -> case Module:init (Args) of { ok, Speclist, State } -> { ok, #genexpire{ module = Module, speclist = Speclist, state = State } }; { ok, Speclist, State, Timeout } -> { ok, #genexpire{ module = Module, speclist = Speclist, state = State }, Timeout }; R -> R end. %% @spec handle_call (Request, From, State) -> Result %% @doc Just like the gen_server version. %% @end handle_call (Request, From, State) -> wrap ((State#genexpire.module):handle_call (Request, From, State#genexpire.state), State). %% @spec handle_cast (Request, State) -> Result %% @doc Just like the gen_server version. %% @end handle_cast (Request, State) -> wrap ((State#genexpire.module):handle_cast (Request, State#genexpire.state), State). %% @spec handle_info (Msg, State) -> Result %% @doc Just like the gen_server version. %% @end handle_info (Msg, State) -> wrap ((State#genexpire.module):handle_info (Msg, State#genexpire.state), State). %% @spec code_change (OldVsn, State, Extra) -> Result %% @doc Just like the gen_server version. %% @end code_change (OldVsn, State, Extra) -> { ok, NewState } = (State#genexpire.module):code_change (OldVsn, State#genexpire.state, Extra), { ok, State#genexpire{ state = NewState } }. %% @spec terminate (Result, State) -> Result %% @doc Just like the gen_server version, except that %% if a process is running, we wait for it to terminate %% (prior to calling the module's terminate). %% @end terminate (Reason, State) -> (State#genexpire.module):terminate (Reason, State#genexpire.state). %% @hidden handle_tick (_Reason, State) -> FinalState = lists:foldl (fun (#expirespec{ table = Table, max_bytes_per_box = MaxBytes }, State2) -> LocalFragments = local_fragments (Table), case LocalFragments of [] -> State2; _ -> MaxFragBytes = MaxBytes div length (LocalFragments), lists:foldl (fun (F, State3) -> expire_frag (F, MaxFragBytes, State3) end, State2, LocalFragments) end end, State, State#genexpire.speclist), (FinalState#genexpire.module):finish (FinalState#genexpire.state). %-=====================================================================- %- Private - %-=====================================================================- expire_frag (Table, MaxFragBytes, State) -> LockId = { { ?MODULE, Table }, self () }, global:set_lock (LockId), try { Context, NewState } = (State#genexpire.module):activity_context (Table, State#genexpire.state), mnesia:activity (Context, fun () -> First = (State#genexpire.module):first (Table, NewState), case First of { end_of_table, NewState2 } -> State#genexpire{ state = NewState2 }; { ok, _, NewState2 } -> expire_frag (Table, MaxFragBytes, State#genexpire{ state = NewState2 }, First) end end) after global:del_lock (LockId) end. expire_frag (_Table, _MaxFragBytes, State, { end_of_table, _ }) -> State; expire_frag (Table, MaxFragBytes, State, { ok, Key, _ }) -> case mnesia:table_info (Table, memory) of N when N > MaxFragBytes -> Next = (State#genexpire.module):next (Table, Key, State#genexpire.state), NewState = case Next of { end_of_table, X } -> X; { ok, _, X } -> X end, { ok, NewState2 } = (State#genexpire.module):delete (Table, Key, NewState), expire_frag (Table, MaxFragBytes, State#genexpire{ state = NewState2 }, Next); _ -> State end. frag_table_name (Tab, 1) -> Tab; frag_table_name (Tab, N) -> list_to_atom (atom_to_list (Tab) ++ "_frag" ++ integer_to_list (N)). is_local (TableName) -> lists:member (node (), mnesia:table_info (TableName, disc_copies)) orelse lists:member (node (), mnesia:table_info (TableName, disc_only_copies)) orelse lists:member (node (), mnesia:table_info (TableName, ram_copies)). local_fragments (TableName) -> [ F || N <- lists:seq (1, num_fragments (TableName)), F <- [ frag_table_name (TableName, N) ], is_local (F) ]. num_fragments (Tablename) -> { value, { n_fragments, N } } = lists:keysearch (n_fragments, 1, mnesia:table_info (Tablename, frag_properties)), N. wrap ({ reply, Reply, NewState }, State) -> { reply, Reply, State#genexpire{ state = NewState } }; wrap ({ reply, Reply, NewState, Timeout }, State) -> { reply, Reply, State#genexpire{ state = NewState }, Timeout }; wrap ({ noreply, NewState }, State) -> { noreply, State#genexpire{ state = NewState } }; wrap ({ noreply, NewState, Timeout }, State) -> { noreply, State#genexpire{ state = NewState }, Timeout }; wrap ({ stop, Reason, Reply, NewState }, State) -> { stop, Reason, Reply, State#genexpire{ state = NewState } }; wrap ({ stop, Reason, NewState }, State) -> { stop, Reason, State#genexpire{ state = NewState } }. -ifdef (EUNIT). random_atom (Size) -> list_to_atom (random_string (Size)). random_string (Size) -> [ $a + random:uniform ($z - $a) - 1 || _ <- lists:seq (1, Size) ]. %-=====================================================================- %- Tests - %-=====================================================================- expire_test_ () -> F = fun () -> T = ?FORALL (X, fun (Size) -> { random_atom (Size), random:uniform (Size), random:uniform (8) =:= 1, case random:uniform (8) of 1 -> all; 2 -> none; _ -> random:uniform (Size) end, [ { N, random_string (Size) } || N <- lists:seq (1, Size) ] } end, (fun ({ Tab, Frags, Empty, Keep, Terms }) -> TabDup = list_to_atom (atom_to_list (Tab) ++ "_dup"), { atomic, ok } = mnesia:create_table (Tab, [ { frag_properties, [ { n_fragments, Frags } ] } ]), { atomic, ok } = mnesia:create_table (TabDup, [ { record_name, Tab }, { frag_properties, [ { n_fragments, Frags } ] } ]), InitSize = mnesia:table_info (Tab, memory), if Empty -> Sizes = []; true -> Sizes = [ begin mnesia:dirty_write (Tab, { Tab, Key, Value }), mnesia:dirty_write (TabDup, { Tab, Key, Value }), mnesia:table_info (Tab, memory) end || { Key, Value } <- Terms ] end, { ok, Pid } = gen_expire_test:start_link (1000, case { Keep, Empty } of { _, true } -> Frags * InitSize; { all, false } -> Frags * lists:last (Sizes); { none, false } -> Frags * InitSize; { _, false } -> Frags * lists:nth (Keep, Sizes) end, Tab), { ok, ExpPid } = gen_expire:force_run (Pid), { underway, ExpPid } = gen_expire:force_run (Pid), MRef = erlang:monitor (process, ExpPid), receive { 'DOWN', MRef, _, _, _ } -> ok end, ?assert (mnesia:table_info (Tab, memory) =:= case { Keep, Empty } of { _, true } -> InitSize; { all, false } -> lists:last (Sizes); { none, false } -> InitSize; { _, false } -> lists:nth (Keep, Sizes) end), ?assert (mnesia:table_info (TabDup, memory) =:= mnesia:table_info (Tab, memory)), gen_expire_test:stop (Pid), MRef2 = erlang:monitor (process, Pid), receive { 'DOWN', MRef2, _, _, _ } -> ok end, mnesia:delete_table (Tab), mnesia:delete_table (TabDup), true end) (X)), ok = fc:flasscheck (200, 10, T) end, { setup, fun () -> os:cmd ("rm -rf Mnesia*"), mnesia:start () end, fun (_) -> mnesia:stop (), os:cmd ("rm -rf Mnesia*") end, { timeout, 60, F } }. -endif. -------------- next part -------------- -ifndef (GENEXPIRE_HRL). -define (GENEXPIRE_HRL, true). -record (expirespec, { table, max_bytes_per_box }). -endif. From bengt.kleberg Mon Mar 3 08:53:30 2008 From: bengt.kleberg (Bengt Kleberg) Date: Mon, 03 Mar 2008 08:53:30 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: Message-ID: <1204530810.24311.31.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, In the book "Object Oriented Software Construction" Bertrand Meyer argues (successfully in my opinion) that you need to have the ability to rename (alias) modules. He also shows that this ability must be outside of the language/modules themselves. Otherwise you are just hoping that your code will never be successfully shared by many people. bengt On Sat, 2008-03-01 at 12:59 +0800, shiwei xu wrote: > I think flat module namespaces is a defect of erlang design. > > For example, I write a foo.erl, It works well. But maybe in a late > erlang version (eg. R13B) also write such module named foo.erl. > Then, you can see my application goes wrong. > > How to avoid things like this? Let's see the following ways: > > 1. Adjust module searching paths, and let user path (which contains my > foo.erl) take precedence over erlang stdlib/otp path. But, this way > can't always work well. If some other stdlib/otp modules use system > foo.erl (not my foo.erl), Things goes wrong. > > 2. Write erlang modules always named with a prefix (a fake namespace. > For example, projectname_foo.erl or organization_projectname_foo > .erl). This way really can solve the problem. But, It seems ugly. > > Is there a way let's user still can call foo:func (not call foo.erl > provied by stdlib/otp, but my projectname_foo.erl)? I have a > suggestion: > > Can erlang provide a 'module name alias'? That is, I can rename a > module's name temporarily in a module? For example: > > -module(a_module_that_call_my_foo). > -alias(foo, organization_projectname_foo). %% alias > > some_func_call_foo() -> > foo:func(). %% same as: organization_projectname_foo:func() > > Currently I can do this by using the 'define' keyword. For example: > > -module(a_module_that_call_my_foo). > -define(FOO, organization_projectname_foo). %% alias > > some_func_call_foo() -> > ?FOO:func(). > > It works well, but a bit ugly. > > > On Sat, Mar 1, 2008 at 6:51 AM, Matt Stancliff > wrote: > > On Feb 29, 2008, at 14:34, Anthony Kong wrote: > > > If I rename c.erl to something else, the problem goes away. > > > > What is special about "-module(c)" ? > > > Welcome to the world of flat module namespaces. > > The code module is your friend in these circumstances. > Look into code:clash() and code:which(module). > > code:which(c) should return " path>/lib/erlang/lib/stdlib- > /ebin/c.beam" > > > -Matt > -- > Matt Stancliff sysop > AIM: seijimr iPhone: 678-591-9337 > "The best way to predict the future is to invent it." --Alan > Kay > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From mikpe Mon Mar 3 09:25:56 2008 From: mikpe (Mikael Pettersson) Date: Mon, 3 Mar 2008 09:25:56 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <17244f480803021744q582d5e5ek958d82e6264ee425@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <17244f480803021744q582d5e5ek958d82e6264ee425@mail.gmail.com> Message-ID: <18379.46612.857699.349729@harpo.it.uu.se> Yariv Sadan writes: > Robert, this is very cool. I already started playing with LFE and it's > great. Thanks a lot for sharing it. > > I have a couple of suggestions: > > - it would be nice to have a preprocessor/parse transform that converts the form > > (foo:bar baz ..) > > to > > (: foo bar baz ...) > > I find the former much more readable. This I can agree with, as long as we're only talking about literal module and function names, not general expressions. > - It would like to have an Erlang-style '=' operator for binding > instead of (let). The main difference is in the number of parentheses > and the scoping rules. So, instead of > > (let ((a 1) (b 2)) (+ a b)) > > you could write > > (= (a 1) (b 2)) > (+ a b) NO! Absolutely no fricking way. The way Erlang (ab)uses the '=' sign to do bindings is IMNSHO one of the ugliest flaws in the language, in part because it isn't structurally lexical scoped (bindings flow /out/ of expressions, not just into them). The point of Lisp/Scheme-like S-expression syntax is not just using parenthesis for grouping, but also using the structure to express scoping. LET-expressions do that, your '=' abuse would not. From dgud Mon Mar 3 10:05:27 2008 From: dgud (Dan Gudmundsson) Date: Mon, 03 Mar 2008 10:05:27 +0100 Subject: [erlang-questions] mnesia bug? In-Reply-To: <47CA2814.7010604@gmail.com> References: <47CA2814.7010604@gmail.com> Message-ID: <47CBBF57.9010102@erix.ericsson.se> Intentional (but harmless in your case), the schema table is still shared between the nodes. The partitioned network means the two or more nodes have been up when the network link between some of them them have been down, it doesn't check or care which tables resides where. /Dan Serge Aleynikov wrote: > I recently ran into this behavior of mnesia that seemed odd. > > 1. Mnesia is running on node A and node B, and node B has extra_db_nodes > environment set to [A]. > 2. Node A has a disc_copies table T. > 3. Node B has no replica of table T and accesses it remotely. > 4. Node A and node B start up and B calls > mnesia:wait_for_tables([T], Timeout). > 5. A some point later either network access between nodes A and B lost > and restored (e.g. via calls to net_kernel:disconnect/1, > net_kernel:connect_node/1). > > 6. Mnesia on node A reports a *partitioned network* event. > > This seems strange as node B has no ram or disk copies of any table and > node A should not be reporting this event as its tables are still > consistent. > > Can anyone comment on whether it's a bug or intended design? > > Serge > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From bsayanthan Mon Mar 3 10:20:52 2008 From: bsayanthan (Balathasan Sayanthan) Date: Mon, 3 Mar 2008 14:50:52 +0530 Subject: [erlang-questions] splitting Message-ID: <9b2076080803030120t7bda4c1cl8107222c96bfbefa@mail.gmail.com> Hi , I am trying to write a decoding logic to decode a list which has a predefined separator ( eg. tab). But the distance at which the separator will occur from the start of the list is unknown. I want to extract all the values before the separator into one list and the rest of the list into another, what would be the best way of doing this in Erlang? for example if the program is given a list like [ 23, 34, 9, 34, 78, 90, 9, 10, 34 ] I want this to be split into [23, 34] , [ 34, 78, 90, 9, 10, 34] using 9 as the separator(the point at which will occur is a variable and aslo there might be multiple occurances of it). Am I supposed to use the string:tokens(*string*, *substring*), but is there a more efficient way of doing it in Erlang? -- Sayanthan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/eac0ecf2/attachment.html From chsu79 Mon Mar 3 10:34:57 2008 From: chsu79 (Christian S) Date: Mon, 3 Mar 2008 10:34:57 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <1204530810.24311.31.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <1204530810.24311.31.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: On Mon, Mar 3, 2008 at 8:53 AM, Bengt Kleberg wrote: > In the book "Object Oriented Software Construction" Bertrand Meyer > argues (successfully in my opinion) that you need to have the ability to > rename (alias) modules. He also shows that this ability must be outside > of the language/modules themselves. Providing my own aliases for other modules that I use is something I have been wishing for. Not having read the book, what does he mean with the ability must be outside of the language? From chandrashekhar.mullaparthi Mon Mar 3 10:51:05 2008 From: chandrashekhar.mullaparthi (Chandru) Date: Mon, 3 Mar 2008 09:51:05 +0000 Subject: [erlang-questions] splitting In-Reply-To: <9b2076080803030120t7bda4c1cl8107222c96bfbefa@mail.gmail.com> References: <9b2076080803030120t7bda4c1cl8107222c96bfbefa@mail.gmail.com> Message-ID: On 03/03/2008, Balathasan Sayanthan wrote: > Hi , > > I am trying to write a decoding logic to decode a list which has a > predefined separator ( eg. tab). But the distance at which the separator > will occur from the start of the list is unknown. I want to extract all the > values before the separator into one list and the rest of the list into > another, what would be the best way of doing this in Erlang? > > for example if the program is given a list like [ 23, 34, 9, 34, 78, 90, 9, > 10, 34 ] > > I want this to be split into [23, 34] , [ 34, 78, 90, 9, 10, 34] using 9 as > the separator(the point at which will occur is a variable and aslo there > might be multiple occurances of it). > > Am I supposed to use the string:tokens(string, substring), but is there a > more efficient way of doing it in Erlang? > You can quite easily write a function to do this. split_at(List, Split_char) -> split_at(List, Split_char, []). split_at([Split_char | T], Split_char, Acc) -> {lists:reverse(Acc), T}; split_at([H | T], Split_char, Acc) -> split_at(T, Split_char, [H | Acc]); split_at([], _, Acc) -> {lists:reverse(Acc), []}. Alternatively, have a look at lists:splitwith/2 cheers Chandru From wenewboy Mon Mar 3 11:39:38 2008 From: wenewboy (wenew zhang) Date: Mon, 3 Mar 2008 18:39:38 +0800 Subject: [erlang-questions] erlang-questions Digest, Vol 10, Issue 9 In-Reply-To: References: Message-ID: <4eaa09eb0803030239k38eeff09na3c4f802f4b33f6@mail.gmail.com> Thanks a lot, you replay was very fast and i very appreciate it, i install tk4 and then fix that problem! ubuntu 8.04: apt-get install tk8.5 best regards wenew zhang > Date: Mon, 3 Mar 2008 07:03:47 -0000 (UTC) > From: "Ulf Eliasson" > Subject: Re: [erlang-questions] howto run debugger:start() or pman in > ubuntu > To: erlang-questions > Cc: wenew zhang > Message-ID: > <57003.85.195.15.121.1204527827.squirrel> > Content-Type: text/plain;charset=iso-8859-1 > > Hi, > > Make sure that you have tcl as well as tk installed, otherwise it will just > do nothing when you try to start them. I think it would be better to return > an error or something, you can try and do just gs:init(); If that fail it's > likely because you don't have TCL and/or TK. > > Regards, > Ulf Eliasson > > On Mon, March 3, 2008 06:29, wenew zhang wrote: > > Dear All: > > i'm setup R12B-1 on ubuntu8.04 and compile it with --with-ssl > > --with-gd, > > i run below instructions: > > /opt/erlang/bin/erlc fsmkvo.erl -debuginfo > > /opt/erlang/bin/erl > > debugger:start(). > > > > and then,the screen is hold on,no pop main window or other output infos, > > i test is on gnome and xfce, > > what can i do? > > > > > > best regards > > > > wenew zhang > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions From kostis Mon Mar 3 13:28:50 2008 From: kostis (Kostis Sagonas) Date: Mon, 03 Mar 2008 14:28:50 +0200 Subject: [erlang-questions] hipe binary matching problem with R12B-1? In-Reply-To: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> References: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> Message-ID: <47CBEF02.4090500@cs.ntua.gr> Steve Vinoski wrote: > Just out of curiosity I've been going back through some Wide Finder > code to see how it fares under R12B-1, given the improvements in > binaries in this new release. Generally I'm seeing some pretty good > performance improvements with no code changes. Unfortunately I think > I'm also seeing a bug. > > Below find the results of compiling and running the example code at > the bottom of this message. Using "c" to compile gives the right > answer; using "hipe:c" gives the wrong answer. Once again, thanks for reporting this. The bug can be corrected by applying the patch which appears below and re-making the libraries. The same fix will be included in R12B-2. Kostis =================================================================== Index: lib/hipe/icode/hipe_icode_primops.erl =================================================================== --- lib/hipe/icode/hipe_icode_primops.erl 14 Nov 2007 23:53:42 -0000 1.73 +++ lib/hipe/icode/hipe_icode_primops.erl 3 Mar 2008 12:00:42 -0000 1.74 @@ -533,7 +533,7 @@ erl_types:t_sup( erl_types:t_subtract(Type,erl_types:t_matchstate()), erl_types:t_matchstate_slot( - erl_types:t_inf(Type,erl_types:t_matchstate()),1)); + erl_types:t_inf(Type,erl_types:t_matchstate()),0)); {hipe_bs_primop, {bs_match_string,_,Bytes}} -> [MatchState] = Args, BinType = erl_types:t_matchstate_present(MatchState), From eranga.erl Mon Mar 3 13:31:40 2008 From: eranga.erl (Eranga Udesh) Date: Mon, 3 Mar 2008 18:01:40 +0530 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection Message-ID: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> Hi, I am experiencing a high message passing delay between 2 Erlang nodes, after an abnormal network disconnection. Those 2 nodes are in a WAN and there are multiple Hubs, Switches, Routes, etc., in between them. If the message receiving Erlang node stopped gracefully, the delay doesn't arise. Doing net_adm:ping/1 to that node results no delay "pang". However gen_event:notify/2, gen_server:cast/2, etc. are waiting for about 10 seconds to return. What's the issue and how this can be avoided? Thanks, - Eranga -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/aadab6f4/attachment.html From bjorn Mon Mar 3 13:29:21 2008 From: bjorn (Bjorn Gustavsson) Date: 03 Mar 2008 13:29:21 +0100 Subject: [erlang-questions] Binary pattern matching inconsistencies with R12B In-Reply-To: <20080229174344.GA2361@almeida.jinsky.com> References: <20080229174344.GA2361@almeida.jinsky.com> Message-ID: Rory Byrne writes: > The following code won't make real sense. The full scanner > makes sense but this is only a mutated 10% of that. Sorry > the code is so unintelligible - but on the bright side > it fails more frequently and predictably than the full > scanner does. Thanks for the bug report. I was able to reproduce the crash by running the scanner module. I'll start investigating it. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From francesco Mon Mar 3 14:17:43 2008 From: francesco (Francesco Cesarini) Date: Mon, 03 Mar 2008 13:17:43 +0000 Subject: [erlang-questions] Throughput on Yaws 1.68 / OTP R11B-3 / Suse Linux 10.2? Message-ID: <47CBFA77.9040206@erlang-consulting.com> We've been running some stress tests on a system receiving http posts from a load tool. No matter how hard we push the system, and no matter how many instances of the load tool we install, we can not increase the throughput. We are hitting each web server node with 8,000 simultaneous inets http client connections (ibrowse, at those levels generates huge message queues and runs @ 100% cpu), sending messages as quickly as they can. The load machines are running at 10 - 15% system CPU. Once the requests have passed through the inets driver and the yaws layer, we are unable to handle more than 1000 sustained hits per second. The hardware is running at about 50% System CPU. K-poll is enabled, as are 255 io threads. Hitting the system in the API used by Yaws, we have managed to achieve a sustained throughput in excess of 3,000 requests per second. We are in the process of replacing Yaws with a light weight web server, but our gut feeling is that the bottle neck is in the inets driver. Benchmarks using the pico server a few years back (on much more modest hardware) resulted in excess of 3,000 requests per second. While we are doing it, it would be useful to hear if others have experienced similar bottlenecks in similar architectures? Thanks, Francesco -- http://www.erlang-consulting.com From chandrashekhar.mullaparthi Mon Mar 3 14:21:55 2008 From: chandrashekhar.mullaparthi (Chandru) Date: Mon, 3 Mar 2008 13:21:55 +0000 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> References: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> Message-ID: On 03/03/2008, Eranga Udesh wrote: > Hi, > > I am experiencing a high message passing delay between 2 Erlang nodes, after > an abnormal network disconnection. Those 2 nodes are in a WAN and there are > multiple Hubs, Switches, Routes, etc., in between them. If the message > receiving Erlang node stopped gracefully, the delay doesn't arise. Doing > net_adm:ping/1 to that node results no delay "pang". However > gen_event:notify/2, gen_server:cast/2, etc. are waiting for about 10 seconds > to return. > > What's the issue and how this can be avoided? Have you tried putting a snoop to see whether the delay is on the sending/receiving side? This might be useful: http://www.erlang.org/contrib/erlsnoop-1.0.tgz cheers Chandru From alexvazquezfente Mon Mar 3 14:23:35 2008 From: alexvazquezfente (Alex Vazquez) Date: Mon, 3 Mar 2008 14:23:35 +0100 Subject: [erlang-questions] Wrong doc for erl_encode Message-ID: <21e305470803030523u52abfaf0p58a42f0a7e7d6900@mail.gmail.com> Please, someone could clarify what erl_encode(ETERM *term, uint8_t *buffer) returns? Documentation(erl_interface.pdf and man pages) says it returns 0 if succeed or 1 in case of error, but my tests seem to say that it returns the number of bytes written on the buffer. Is this correct? In that case, could someone correct the docs? Regards, -- Alejandro Vazquez Fente -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/d2e0b542/attachment.html From saleyn Mon Mar 3 14:00:14 2008 From: saleyn (Serge Aleynikov) Date: Mon, 03 Mar 2008 08:00:14 -0500 Subject: [erlang-questions] mnesia bug? In-Reply-To: <47CBBF57.9010102@erix.ericsson.se> References: <47CA2814.7010604@gmail.com> <47CBBF57.9010102@erix.ericsson.se> Message-ID: <47CBF65E.90908@gmail.com> It is harmless in this case indeed, however, in my setup I actually had two connected nodes (NodeA and NodeC) with disc_copies tables, and NodeB happened to be connected through an unreliable link with mnesia having a single ram_copies table (different from tables on NodeA and NodeC). The end-result of a partitioned network between NodeA&NodeB and NodeC is that mnesia reports an error and stops replicating tables between NodeA and NodeB, even though node NodeC had nothing to do with NodeA and NodeB except for sharing the schema. This requires restart of all nodes NodeA, NodeB and NodeC (or restart of mnesia application on all nodes), which is not a desirable property as NodeA and NodeB shouldn't have been impacted by an unreliable network link to NodeC. Perhaps before reporting a network partition condition, the database could check if the schema is different on all nodes? The only solution is to follow a variation of Uffe's advise (*) on recovering mnesia from a partitioned network - run the NodeC node with {dist_auto_connect, once} and upon detecting a nodedown event on NodeC enabling user-level heartbeat, and upon receiving a response from NodeA or NodeB restart NodeC. This actually becomes even more complex if NodeC is behind a firewall that only allows connections to NodeC from NodeA or NodeB but not the reverse. In this case NodeC has to be running with {dist_auto_connect, never}, and upon receiving a nodedown event has to shut down mnesia and turn on a UDP/TCP listener that would echo user-level pings coming from NodeA/NodeB. When an echoed ping reaches back NodeA or NodeB, those nodes would do net_kernel:connect(NodeC). The firewall would allow this connection through and NodeC would detect nodeup event and would start mnesia application. This sounds a bit more complicated than one would desire for running clusters of nodes with in depended mnesia tables. Serge (*) search the list for "mnesia", "partitioned network". Dan Gudmundsson wrote: > Intentional (but harmless in your case), the schema table is still > shared between the nodes. > > The partitioned network means the two or more nodes have been up > when the network link between some of them them have been down, it > doesn't check or care which tables resides where. > > /Dan > > Serge Aleynikov wrote: >> I recently ran into this behavior of mnesia that seemed odd. >> >> 1. Mnesia is running on node A and node B, and node B has >> extra_db_nodes environment set to [A]. >> 2. Node A has a disc_copies table T. >> 3. Node B has no replica of table T and accesses it remotely. >> 4. Node A and node B start up and B calls >> mnesia:wait_for_tables([T], Timeout). >> 5. A some point later either network access between nodes A and B lost >> and restored (e.g. via calls to net_kernel:disconnect/1, >> net_kernel:connect_node/1). >> >> 6. Mnesia on node A reports a *partitioned network* event. >> >> This seems strange as node B has no ram or disk copies of any table >> and node A should not be reporting this event as its tables are still >> consistent. >> >> Can anyone comment on whether it's a bug or intended design? >> >> Serge >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions >> http://www.erlang.org/mailman/listinfo/erlang-questions >> > From tobbe Mon Mar 3 15:44:05 2008 From: tobbe (Torbjorn Tornkvist) Date: Mon, 03 Mar 2008 15:44:05 +0100 Subject: [erlang-questions] Throughput on Yaws 1.68 / OTP R11B-3 / Suse Linux 10.2? In-Reply-To: <47CBFA77.9040206@erlang-consulting.com> References: <47CBFA77.9040206@erlang-consulting.com> Message-ID: You could perhaps try the iserve-server provided by Sean Hinde: http://www.tornkvist.org/gitweb?p=iserve.git;a=summary This way you get the minimal turnaround in Erlang, just to get an idea if the bottleneck is in Yaws or somewhere else. --Tobbe Francesco Cesarini wrote: > We've been running some stress tests on a system receiving http posts > from a load tool. No matter how hard we push the system, and no matter > how many instances of the load tool we install, we can not increase the > throughput. > > We are hitting each web server node with 8,000 simultaneous inets http > client connections (ibrowse, at those levels generates huge message > queues and runs @ 100% cpu), sending messages as quickly as they can. > The load machines are running at 10 - 15% system CPU. Once the requests > have passed through the inets driver and the yaws layer, we are unable > to handle more than 1000 sustained hits per second. The hardware is > running at about 50% System CPU. K-poll is enabled, as are 255 io > threads. Hitting the system in the API used by Yaws, we have managed to > achieve a sustained throughput in excess of 3,000 requests per second. > > We are in the process of replacing Yaws with a light weight web server, > but our gut feeling is that the bottle neck is in the inets driver. > Benchmarks using the pico server a few years back (on much more modest > hardware) resulted in excess of 3,000 requests per second. While we are > doing it, it would be useful to hear if others have experienced similar > bottlenecks in similar architectures? > > Thanks, > Francesco > -- > http://www.erlang-consulting.com From icfp.publicity Mon Mar 3 16:04:08 2008 From: icfp.publicity (Matthew Fluet (ICFP Publicity Chair)) Date: Mon, 3 Mar 2008 09:04:08 -0600 Subject: [erlang-questions] ICFP08 Final CFP Message-ID: <53ff55480803030704u33c08954n5a4cba79ffb9f959@mail.gmail.com> Final Call for Papers ICFP 2008: International Conference on Functional Programming Victoria, BC, Canada, 22-24 September 2008 http://www.icfpconference.org/icfp2008 Submission deadline: 2 April 2008 ICFP 2008 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects and concurrency. Particular topics of interest include * Applications and Domain-Specific Languages * Foundations * Design * Implementation * Transformation and Analysis * Software-development Techniques * Functional Pearls * Practice and Experience Important Dates (at 09:00 Apia time, UTC-11) ~~~~~~~~~~~~~~~ Submission: 2 April 2008 Author response: 21 May 2008 Notification: 16 June 2008 Final papers due: 7 July 2008 Call for Papers (full text) ~~~~~~~~~~~~~~~ http://www.icfpconference.org/icfp2008/cfp/cfp.html The submission URL will be available from the above page shortly. Program Chair ~~~~~~~~~~~~~ Peter Thiemann Albert-Ludwigs-Universit?t Georges-K?hler-Allee 079 79110 Freiburg, Germany Email: icfp08 Phone: +49 761 203 8051 Fax: +49 761 203 8052 Mail sent to the address above is filtered for spam. If you send mail and do not receive a prompt response, particularly if the deadline is looming, feel free to telephone and reverse the charges. From francesco Mon Mar 3 16:13:11 2008 From: francesco (Francesco Cesarini) Date: Mon, 03 Mar 2008 15:13:11 +0000 Subject: [erlang-questions] Throughput on Yaws 1.68 / OTP R11B-3 / Suse Linux 10.2? In-Reply-To: References: <47CBFA77.9040206@erlang-consulting.com> Message-ID: <47CC1587.3090704@erlang-consulting.com> Just the one I had in mind when mentioning benchmarks from a few years ago.. Francesco -- http://www.erlang-consulting.com Torbjorn Tornkvist wrote: > You could perhaps try the iserve-server provided by Sean Hinde: > > http://www.tornkvist.org/gitweb?p=iserve.git;a=summary > > This way you get the minimal turnaround in Erlang, just to > get an idea if the bottleneck is in Yaws or somewhere else. > > --Tobbe > > Francesco Cesarini wrote: > >> We've been running some stress tests on a system receiving http posts >> from a load tool. No matter how hard we push the system, and no matter >> how many instances of the load tool we install, we can not increase the >> throughput. >> >> We are hitting each web server node with 8,000 simultaneous inets http >> client connections (ibrowse, at those levels generates huge message >> queues and runs @ 100% cpu), sending messages as quickly as they can. >> The load machines are running at 10 - 15% system CPU. Once the requests >> have passed through the inets driver and the yaws layer, we are unable >> to handle more than 1000 sustained hits per second. The hardware is >> running at about 50% System CPU. K-poll is enabled, as are 255 io >> threads. Hitting the system in the API used by Yaws, we have managed to >> achieve a sustained throughput in excess of 3,000 requests per second. >> >> We are in the process of replacing Yaws with a light weight web server, >> but our gut feeling is that the bottle neck is in the inets driver. >> Benchmarks using the pico server a few years back (on much more modest >> hardware) resulted in excess of 3,000 requests per second. While we are >> doing it, it would be useful to hear if others have experienced similar >> bottlenecks in similar architectures? >> >> Thanks, >> Francesco >> -- >> http://www.erlang-consulting.com >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > From kenneth.lundin Mon Mar 3 16:18:39 2008 From: kenneth.lundin (Kenneth Lundin) Date: Mon, 3 Mar 2008 16:18:39 +0100 Subject: [erlang-questions] Wrong doc for erl_encode In-Reply-To: <21e305470803030523u52abfaf0p58a42f0a7e7d6900@mail.gmail.com> References: <21e305470803030523u52abfaf0p58a42f0a7e7d6900@mail.gmail.com> Message-ID: Hi, Thanks for reporting this documentation bug. Will be corrected in R12B-2 The functions erl_encode and erl_encode_buf returns the number of bytes written (on success) and 0 otherwise. /Regards Kenneth Erlang/OTP team Ericsson On 3/3/08, Alex Vazquez wrote: > Please, someone could clarify what erl_encode(ETERM *term, uint8_t *buffer) > returns? > > Documentation(erl_interface.pdf and man pages) says it returns 0 if succeed > or 1 in case of error, but my tests seem to say that it returns the number > of bytes written on the buffer. Is this correct? In that case, could someone > correct the docs? > > Regards, > > -- > Alejandro Vazquez Fente > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From bjorn Mon Mar 3 16:42:24 2008 From: bjorn (Bjorn Gustavsson) Date: 03 Mar 2008 16:42:24 +0100 Subject: [erlang-questions] Binary pattern matching inconsistencies with R12B In-Reply-To: <20080229174344.GA2361@almeida.jinsky.com> References: <20080229174344.GA2361@almeida.jinsky.com> Message-ID: Rory Byrne writes: > The following code won't make real sense. The full scanner > makes sense but this is only a mutated 10% of that. Sorry > the code is so unintelligible - but on the bright side > it fails more frequently and predictably than the full > scanner does. Again thanks for your bug report. I have extended our test suites and corrected the bug. The correction will be included in R12B-2. Here is the correction: *** erts/emulator/beam/beam_emu.c@@/OTP_R12B-1 Tue Feb 5 14:37:01 2008 --- erts/emulator/beam/beam_emu.c Mon Mar 3 16:21:22 2008 *************** *** 3471,3476 **** --- 3471,3477 ---- ms = (ErlBinMatchState *) boxed_val(tmp_arg1); dst = (ErlBinMatchState *) HTOP; *dst = *ms; + *HTOP = HEADER_BIN_MATCHSTATE(slots); HTOP += wordsneeded; StoreResult(make_matchstate(dst), Arg(3)); } /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From dizzyd Mon Mar 3 17:21:24 2008 From: dizzyd (Dave Smith) Date: Mon, 3 Mar 2008 09:21:24 -0700 Subject: [erlang-questions] Reading fixed structures from file In-Reply-To: <14f0e3620803011337l3453d81ew230f2d32a7a0d6f5@mail.gmail.com> References: <14f0e3620803011054h1cba297ep2b3ed6d100222853@mail.gmail.com> <14f0e3620803011337l3453d81ew230f2d32a7a0d6f5@mail.gmail.com> Message-ID: On Sat, Mar 1, 2008 at 2:37 PM, Gleb Peregud wrote: > Thanks a lot. > > imho my code is more readable :) But it's matter of taste. > > Nevertheless, to avoid confusion, i'll ask explicitly: > > > Key:4/little-integer-unit:8 > > matches four integers each having 8 bits, right? No. You could read that line as: "Key" is a 4-unit little-endian integer, where each unit has 8 bits. You could also write: Key:16/little-integer:2 or Key:8/little-integer-unit:4 or ..... Hope that helps. D. From gleber.p Mon Mar 3 20:03:18 2008 From: gleber.p (Gleb Peregud) Date: Mon, 3 Mar 2008 20:03:18 +0100 Subject: [erlang-questions] Reading fixed structures from file In-Reply-To: References: <14f0e3620803011054h1cba297ep2b3ed6d100222853@mail.gmail.com> <14f0e3620803011337l3453d81ew230f2d32a7a0d6f5@mail.gmail.com> Message-ID: <14f0e3620803031103r4177f0c8ibef73e30a81b80ae@mail.gmail.com> Thanks a lot for clarifying this! On 3/3/08, Dave Smith wrote: > On Sat, Mar 1, 2008 at 2:37 PM, Gleb Peregud wrote: > > Thanks a lot. > > > > imho my code is more readable :) But it's matter of taste. > > > > Nevertheless, to avoid confusion, i'll ask explicitly: > > > > > > Key:4/little-integer-unit:8 > > > > matches four integers each having 8 bits, right? > > No. You could read that line as: > > "Key" is a 4-unit little-endian integer, where each unit has 8 bits. > > You could also write: > > Key:16/little-integer:2 or Key:8/little-integer-unit:4 or ..... > > Hope that helps. > > D. > -- Gleb Peregud http://gleber.pl/ "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." -- Albert Einstein From klacke Mon Mar 3 20:35:14 2008 From: klacke (Claes Wikstrom) Date: Mon, 03 Mar 2008 20:35:14 +0100 Subject: [erlang-questions] Throughput on Yaws 1.68 / OTP R11B-3 / Suse Linux 10.2? In-Reply-To: References: <47CBFA77.9040206@erlang-consulting.com> Message-ID: <47CC52F2.3050108@hyber.org> Torbjorn Tornkvist wrote: > You could perhaps try the iserve-server provided by Sean Hinde: > > http://www.tornkvist.org/gitweb?p=iserve.git;a=summary > > This way you get the minimal turnaround in Erlang, just to > get an idea if the bottleneck is in Yaws or somewhere else. > If you find that the bottleneck is Yaws - I want to know. /klacke From kostis Mon Mar 3 20:56:10 2008 From: kostis (Kostis Sagonas) Date: Mon, 03 Mar 2008 21:56:10 +0200 Subject: [erlang-questions] R12B-1 dialyzer 'Unsupported primop' error In-Reply-To: References: Message-ID: <47CC57DA.7050209@cs.ntua.gr> John Webb wrote: > In R12B-1 the following seemingly correct (if not so useful) program > yields the error {'Unsupported primop', bs_context_to_binary} when > dialyzer runs with the "Old Style" analysis option. > > -module(test). > -compile(export_all). > start(<<>>) -> ok. > > The compiler seems to emit the primop when the function arguments > contain a binary match and there is no final catch-all clause. My code > runs as expected so I am assuming this is a dialyzer issue? Yes. The issue is that "old_style" has not been updated to support all primops that the current compiler generates. Come to think of it, why should it? We see little reason for a user to want "old_style" and at the same time generating .beam files by using the current compiler... Unrelated to your mail, last week we decided to discontinue support for the "old_style" option and today we actually took it out all that code. The current development version of Dialyzer spits out this error: Option --old_style is no longer supported Sorry, but there will not be a fix for your problem. The new Dialyzer is much much better and we see little reason to continue generating warnings without line information (as --old_style does). Kostis From francesco Mon Mar 3 21:17:01 2008 From: francesco (Francesco Cesarini) Date: Mon, 03 Mar 2008 20:17:01 +0000 Subject: [erlang-questions] Throughput on Yaws 1.68 / OTP R11B-3 / Suse Linux 10.2? In-Reply-To: <47CC52F2.3050108@hyber.org> References: <47CBFA77.9040206@erlang-consulting.com> <47CC52F2.3050108@hyber.org> Message-ID: <47CC5CBD.3010207@erlang-consulting.com> No, not surprisingly, the bottle neck is not Yaws. We got a slight improvement, which is understandable, but the system still stalls at a ridiculously low rate and a degradation of service the more we increase the load. It is still a few thousand hits per second, so most people would probably not have noticed unless they've run proper stress tests. I guess we will have to start digging in the inets driver. Francesco -- http://www.erlang-consulting.com Claes Wikstrom wrote: > Torbjorn Tornkvist wrote: > >> You could perhaps try the iserve-server provided by Sean Hinde: >> >> http://www.tornkvist.org/gitweb?p=iserve.git;a=summary >> >> This way you get the minimal turnaround in Erlang, just to >> get an idea if the bottleneck is in Yaws or somewhere else. >> >> > > If you find that the bottleneck is Yaws - I want to know. > > /klacke > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > From rvirding Mon Mar 3 21:20:30 2008 From: rvirding (Robert Virding) Date: Mon, 3 Mar 2008 21:20:30 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <17244f480803021744q582d5e5ek958d82e6264ee425@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <17244f480803021744q582d5e5ek958d82e6264ee425@mail.gmail.com> Message-ID: <3dbc6d1c0803031220h118f96ddr9bb4ca0f1430f756@mail.gmail.com> On 03/03/2008, Yariv Sadan wrote: > > Robert, this is very cool. I already started playing with LFE and it's > great. Thanks a lot for sharing it. > > I have a couple of suggestions: > > - it would be nice to have a preprocessor/parse transform that converts > the form > > (foo:bar baz ..) > > to > > (: foo bar baz ...) > > I find the former much more readable. Yes, it is easier to read but as yet I don't have any infix operators, and : is just a normal symbol character so foo:bar is a normal symbol. I have so far tried to avoid making any characters but the bare minimum needed for sexps as "special", it keeps the parsing easier. It would be possible to fix this in the macro expander if enough people complain. :-) I have not really planned to add an explicit parse transform operation as in vanilla Erlang as it is "so easy" (TM) to do it yourself. - It would like to have an Erlang-style '=' operator for binding > instead of (let). The main difference is in the number of parentheses > and the scoping rules. So, instead of > > (let ((a 1) (b 2)) (+ a b)) > > you could write > > (= (a 1) (b 2)) > (+ a b) No, one thing I definitely want is variable scoping. I think that was a definite mistake in vanilla Erlang. 20/20 hindsight. - String literals should be interpreted as literal lists rather than > sexps. It seems redundant to write a single quote before a string > literal. The problem is that string literals are parsed into lists, strings don't exist. Seeing their is no abstract syntax I can't tag these as any different from other literal lists as is done in vanilla and the compiler/interpreter just sees lists. So they have to be quoted. I agree though that it is not beautiful. Perhaps all integers in the function position could just be a function which evaluates to a list of itself and all the arguments. I am probably joking. - It would be great to have syntax for multi-line strings and binaries. Same problem here with string literals within binaries. The syntax can be modified later when requests stabilise. - Distributing LFE under a standard open source license would > encourage its adoption and foster community contributions. > lfe_scan.erl has this license notice: > > %%% (C)Robert Virding. This stuff is mine, distributed without > %%% warranty "as is" and may not be used commercially without letting > %%% me know. > > This wording is ambiguous. Is the only requirement to using LFE > commercially to let you know, or it it required to buy a license for > commercial use? What happens to user contributions? Etc. That only applies to Leex and I know I have to do something with Leex. What I mean is that I am just interested in knowing who is using it and for what and have no intention of selling licenses, except of course if I find that it is wildly popular and I could make a fortune on it and retire to the south seas. I.e. no licenses, you can quote that. As for LFE I am giving it away. If somebody has a nice, short license notice expressing this then let me know. I would, however, become disappointed if someone else started selling it. :-) Regards, > Yariv Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/b8d9dbac/attachment-0001.html From kettlgruber Mon Mar 3 21:21:16 2008 From: kettlgruber (Gerald Kettlgruber) Date: Mon, 3 Mar 2008 21:21:16 +0100 Subject: [erlang-questions] Python interface Message-ID: <4fd059680803031221n51364b51w34ec2e64d36aa58f@mail.gmail.com> Hello, is there something like the jinterface for python, which is up to date? I'm asking, because the way via ports is to circuitous for my purpose. Thanks for help Gerald Kettlgruber -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/495ce53c/attachment.html From hasan.veldstra Mon Mar 3 21:40:23 2008 From: hasan.veldstra (Hasan Veldstra) Date: Mon, 3 Mar 2008 20:40:23 +0000 Subject: [erlang-questions] Python interface In-Reply-To: <4fd059680803031221n51364b51w34ec2e64d36aa58f@mail.gmail.com> References: <4fd059680803031221n51364b51w34ec2e64d36aa58f@mail.gmail.com> Message-ID: <0126B040-F888-4488-B1B0-9E1E64EEA1E7@gmail.com> > is there something like the jinterface for python, which is up to > date? > I'm asking, because the way via ports is to circuitous for my purpose. Nope, unless you want to try it with Jython perhaps. Ports are straightforward. I wrote one in C, with a very limited knowledge of C. There's a port tutorial on trapexit somewhere that uses Python. There's also one on ASPN Python. From rory Mon Mar 3 22:01:49 2008 From: rory (Rory Byrne) Date: Mon, 3 Mar 2008 22:01:49 +0100 Subject: [erlang-questions] Binary pattern matching inconsistencies with R12B In-Reply-To: References: <20080229174344.GA2361@almeida.jinsky.com> Message-ID: <20080303210149.GA12400@almeida.jinsky.com> On Mon, Mar 03, 2008 at 04:42:24PM +0100, Bjorn Gustavsson wrote: > > I have extended our test suites and corrected the bug. The correction will > be included in R12B-2. > Just applied the patch and everything works great now. Many thanks Bjorn! Rory From tobbe Mon Mar 3 21:48:49 2008 From: tobbe (Torbjorn Tornkvist) Date: Mon, 03 Mar 2008 21:48:49 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803031220h118f96ddr9bb4ca0f1430f756@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <17244f480803021744q582d5e5ek958d82e6264ee425@mail.gmail.com> <3dbc6d1c0803031220h118f96ddr9bb4ca0f1430f756@mail.gmail.com> Message-ID: Robert Virding wrote: > > As for LFE I am giving it away. If somebody has a nice, short license > notice expressing this then let me know. I would, however, become > disappointed if someone else started selling it. :-) Then why not simply put it at code.google.com with a GPL license attached to it? --Tobbe From vances Mon Mar 3 22:06:22 2008 From: vances (Vance Shipley) Date: Mon, 3 Mar 2008 16:06:22 -0500 Subject: [erlang-questions] LAPD Message-ID: <20080303210622.GC63012@h216-235-12-172.host.egate.net> On Sun Mar 2 09:36:07 CET 2008 Torben Hoffmann wrote: } I have worked with Erlang/OTP for almost 2 years now - the last } year full time on a project which creates a telephone exchange } where we have dealt with encoding and decoding of Q.SIG (PSS1) } plus the Q.SIG protocol stack itself as well as an interface to } layer 2 with a C-port. You could have used my native Erlang Layer 2 (LAPD)! http://lapderl.ggoglecode.com -Vance From ellisonbg.net Mon Mar 3 22:32:26 2008 From: ellisonbg.net (Brian Granger) Date: Mon, 3 Mar 2008 15:32:26 -0600 Subject: [erlang-questions] Python interface In-Reply-To: <4fd059680803031221n51364b51w34ec2e64d36aa58f@mail.gmail.com> References: <4fd059680803031221n51364b51w34ec2e64d36aa58f@mail.gmail.com> Message-ID: <6ce0ac130803031332h75360656k77f343f863404b82@mail.gmail.com> One way to get python talking with erlang is through twisted. I am not sure of the status of this, but it looks promising: http://twistedmatrix.com/trac/browser/sandbox/therve/erlang.xhtml?format=raw. Brian 2008/3/3 Gerald Kettlgruber : > Hello, > > is there something like the jinterface for python, which is up to date? > I'm asking, because the way via ports is to circuitous for my purpose. > > Thanks for help > Gerald Kettlgruber > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From rvirding Mon Mar 3 22:40:51 2008 From: rvirding (Robert Virding) Date: Mon, 3 Mar 2008 22:40:51 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <47CA9A63.6030904@it.uu.se> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <47CA9A63.6030904@it.uu.se> Message-ID: <3dbc6d1c0803031340m673989b8k46417e947d78222c@mail.gmail.com> Yes Richard I remember most of this from the bad old days. :-) What I was getting at was that there is no really no way to return a true function pointer in the way that Scheme or CL can do. This is not a Core problem but an Erlang implementation property. Even if doing let MyCons = 'cons'/2 in apply MyCons(A, B) is legal in Core as is generally using name/arity as data then unless these are optimised away as you mentioned then a later pass in the compiler, v3_kernel, actually converts them to a fun. In the Erlang implementation you cannot directly reference functions as data. I personally think that it was a Good Thing that name/arity function names were kept in Core as it is a (mis)feature of Erlang and trying to hide this would have led to strangeness. That is why I have kept in the distinction in LFE and may even make it more noticeable. I am not yet decided either way. Anyway letrec in LFE maps directly to letrec in Core, which works on name/arity function names, so the following LFE code is perfectly legal and works as expected: (letrec ((f (lambda (x) (+ x n))) (f (lambda (x y) (+ x (+ y n))))) (list (f n) (f n 10))) Though it might be hard explaining to people that it is legal. :-) At least until they see it as Erlang and not as lisp. I don't really want to try and hide properties of the underlying implementation, especially when you can't really avoid seeing them. I mean I can define functions with the same name with different arities so I will never be able to refer to a function by just its name. The Core Erlang spec, together with the record definitions, were a great help in generating code. That together with writing Erlang code and seeing what it resulted in. Robert On 02/03/2008, Richard Carlsson wrote: > > Robert Virding wrote: > > Function bindings > > ----------------- > > > > Core Erlang (and Erlang and the BEAM) separate variable and function > > bindings. A function binding has a name and an arity, this is a result > > of allowing different functions to have the same name but different > > number of arguments. Also there is no concept of a function reference > > built into the Core and BEAM. It is therefore impossible to get a > > reference to a function and pass it around, creating a fun which calls > > this function is not the same thing. So code like: > > > > In CL: (funcall #'cons a b) > > In Scheme: (let ((my-cons cons)) (my-cons a b)) > > > > CANNOT work in Erlang. > > I think you can relax, Robert. This is not a problem. > > In plain Erlang, you'd write > > MyCons = fun cons/2, > MyCons(A,B) > > In Core Erlang, you write it like this: > > let MyCons = 'cons'/2 in apply MyCons(A, B) > > Neither of these things mean that you'll necessarily get another > closure that will delegate the call - that's an old implementation > detail, which is not universally valid anymore. (E.g., with inlining > enabled, this will reduce to a direct call "cons(A, B)".) And in > particular, there is just a single variable namespace. > > You're right that Core Erlang has no special notation ("fun f/N") for > referring to a function (as opposed to defining it) - that's because the > keyword "fun" is not needed. Core Erlang has two flavours of variables: > normal Erlang-style variables, and 'atom'/integer function names. (We > could actually have used only the first form, but then the Core Erlang > code would be harder to understand, and the export section would have to > look something like "export [ F17 as 'foo'/2, F32 as 'bar'/1, ... ]".) > You can only define function-name variables in letrec-expressions, not > in let-expressions, but this is no limitation in general, since you can > easily bind a plain variable to a function-name variable, as above. > > The main point here is: when you see some expression "'f'/3" in Core > Erlang or "fun f/3" in Erlang, think of it as just a name, a variable. > Forget about how "fun f/3" was originally implemented. This is one of > the big things about Core Erlang: except for when you need to create > names of exported functions, that will be visible outside the module, > a variable is just a reference to some value, functional or not, and > it does not matter whether it was defined in a letrec or a let. This > makes it much easier to do transformations like inlining on the Core > language level. > > /Richard > > PS. I know that it's not easy to grok the full consequences of the Core > Erlang specification; one has to sort of clear one's mind and start from > scratch - if the spec doesn't prohibit something, then it should just > work (assuming that the compiler doesn't have a bug or is incomplete). > > [http://www.it.uu.se/research/group/hipe/cerl/doc/core_erlang-1.0.3.pdf] > > If you need human assistance to interpret some detail, just mail me. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/a8f051ec/attachment.html From torben.lehoff Mon Mar 3 22:59:40 2008 From: torben.lehoff (Torben Hoffmann) Date: Mon, 3 Mar 2008 22:59:40 +0100 Subject: [erlang-questions] LAPD In-Reply-To: <20080303210622.GC63012@h216-235-12-172.host.egate.net> References: <20080303210622.GC63012@h216-235-12-172.host.egate.net> Message-ID: On Mon, Mar 3, 2008 at 10:06 PM, Vance Shipley wrote: > On Sun Mar 2 09:36:07 CET 2008 Torben Hoffmann wrote: > } I have worked with Erlang/OTP for almost 2 years now - the last > } year full time on a project which creates a telephone exchange > } where we have dealt with encoding and decoding of Q.SIG (PSS1) > } plus the Q.SIG protocol stack itself as well as an interface to > } layer 2 with a C-port. > > You could have used my native Erlang Layer 2 (LAPD)! > > http://lapderl.ggoglecode.com > > -Vance > Argh, that almost hurts, but only almost... ;-) I didn't find any links apart from the old Motivity url's when I searched last summer so I decided to be a man about it and write a C-port to the E1 card that we were mandated to use - it was enough that we got fancy on the software side, so no room for changing the hardware as well!! Anyway, the experience of interfacing to something that has a C-API has not killed me, but made me stronger plus it also allowed me to show that Erlang can interact with legacy code when that is needed and that is a good selling point. Once the deadline pressure on my project is over I will look into the possibility of releasing the source code for the E1 card since I have made an abstraction layer (not as abstract as I would have liked it, but you live life forwards and understand it backwards) so that I could swap out the E1 card for another relatively easy, i.e., one would only have to write a C-port that opens up to the DL primitives and then one has a functional LAPD protocol. This seems to be something that others might benefit from, but releasing code is not that straight forward when working in a big company so the exploration will have to wait until I have proven that Erlang/OTP was the right choice for the project. Luckily I do not have the surplus energy to dig into your code now so I can stay oblivious to the possibility that I might have re-invented the wheel... at least for now! Cheers, Torben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/d9ec592a/attachment-0001.html From vinoski Tue Mar 4 00:31:14 2008 From: vinoski (Steve Vinoski) Date: Mon, 3 Mar 2008 18:31:14 -0500 Subject: [erlang-questions] hipe binary matching problem with R12B-1? In-Reply-To: <47CBEF02.4090500@cs.ntua.gr> References: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> <47CBEF02.4090500@cs.ntua.gr> Message-ID: <65b2728e0803031531h2c930546u292e1bfd958fc2a2@mail.gmail.com> On 3/3/08, Kostis Sagonas wrote: > Steve Vinoski wrote: > > Just out of curiosity I've been going back through some Wide Finder > > code to see how it fares under R12B-1, given the improvements in > > binaries in this new release. Generally I'm seeing some pretty good > > performance improvements with no code changes. Unfortunately I think > > I'm also seeing a bug. > > > > Below find the results of compiling and running the example code at > > the bottom of this message. Using "c" to compile gives the right > > answer; using "hipe:c" gives the wrong answer. > > Once again, thanks for reporting this. The bug can be corrected by > applying the patch which appears below and re-making the libraries. > The same fix will be included in R12B-2. Works great, thanks! --steve From masterofquestions Tue Mar 4 00:57:19 2008 From: masterofquestions (db) Date: Mon, 3 Mar 2008 18:57:19 -0500 Subject: [erlang-questions] gen_cron question In-Reply-To: References: <1218d6a50803020954y6f12529eo9ed08d517a879b48@mail.gmail.com> Message-ID: <1218d6a50803031557l489e5de0y90756abfc4281abc@mail.gmail.com> Paul, On Mon, Mar 3, 2008 at 2:44 AM, Paul Mineiro wrote: > Hey db, > > Each gen_cron instance is a single something that needs to run > periodically and without overlap. What do you mean when you say there is no overlap? For example, I have module_mneisa_purge and module_data_summary. I need to run module_mnesia_purge on every week/day on an interval. In addition, I need to run module_data_summary on every 24hrs. Does this mean I can't run two instance of gen_cron with two different modules? Sooner or latter, both gen_cron instances will fall on exact time-slot. I know this won't be my last question on gen_cron ;) -- rk That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. -Ralph Waldo Emerson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/c47f2743/attachment.html From jeffm Tue Mar 4 00:54:23 2008 From: jeffm (jm) Date: Tue, 04 Mar 2008 10:54:23 +1100 Subject: [erlang-questions] how: perl <-> erlang Message-ID: <47CC8FAF.1070506@ghostgun.com> What is the best approach for communicating between perl and erlang? The plan is to write a custom module or a hook function to send/retrieve information between radiator ( a perl based radius server) and something written in erlang. Jeff. From valentin Sat Mar 1 12:42:45 2008 From: valentin (Valentin Micic) Date: Sat, 1 Mar 2008 13:42:45 +0200 Subject: [erlang-questions] hipe binary matching problem with R12B-1? References: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> <47C91B36.90601@cs.ntua.gr> Message-ID: <02af01c87b91$613f9390$6401a8c0@moneymaker2> From: "Kostis Sagonas" > Yes, this is a bug. We will fix it May I ask if this bug is limited to Linux, or it is unversal to all supported platforms (e.g. Solaris). Would it be safe to assume that R11 is still the safest bet for Linux? Thanks in advance. V. From vlm Tue Mar 4 03:20:32 2008 From: vlm (Lev Walkin) Date: Mon, 03 Mar 2008 18:20:32 -0800 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <17244f480803021744q582d5e5ek958d82e6264ee425@mail.gmail.com> <3dbc6d1c0803031220h118f96ddr9bb4ca0f1430f756@mail.gmail.com> Message-ID: <47CCB1F0.1020006@lionet.info> Torbjorn Tornkvist wrote: > Robert Virding wrote: >> As for LFE I am giving it away. If somebody has a nice, short license >> notice expressing this then let me know. I would, however, become >> disappointed if someone else started selling it. :-) > > Then why not simply put it at code.google.com with a GPL license > attached to it? BSD license is much shorter and nicer :) -- vlm From bjt Tue Mar 4 04:24:38 2008 From: bjt (Benjamin Tolputt) Date: Tue, 04 Mar 2008 14:24:38 +1100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <47CCB1F0.1020006@lionet.info> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <17244f480803021744q582d5e5ek958d82e6264ee425@mail.gmail.com> <3dbc6d1c0803031220h118f96ddr9bb4ca0f1430f756@mail.gmail.com> <47CCB1F0.1020006@lionet.info> Message-ID: <47CCC0F6.5020002@pmp.com.au> I usually stay out of the licensing flame-wars, and hoepfully this won't result in one. I agree that BSD, MIT, or even Apache are better licenses than GPL "for the stated purpose" (which as I understand it is simply to prevent people taking credit for the work, though Robert can correct me if I am wrong here). If LFE were made GPL, it essentially makes any distribution of Erlang using it GPL. The wxWidgets license (basically LGPL with static linkage exception) is a better fit, if GPL is a must, given that you only need to distribute the source of the library (i.e. LFE) and not the applications linked to & depending on it. Regards, B.J.Tolputt Lev Walkin wrote: > Torbjorn Tornkvist wrote: > >> Robert Virding wrote: >> >>> As for LFE I am giving it away. If somebody has a nice, short license >>> notice expressing this then let me know. I would, however, become >>> disappointed if someone else started selling it. :-) >>> >> Then why not simply put it at code.google.com with a GPL license >> attached to it? >> > > BSD license is much shorter and nicer :) > > From kevin Tue Mar 4 06:16:41 2008 From: kevin (Kevin Scaldeferri) Date: Mon, 3 Mar 2008 21:16:41 -0800 Subject: [erlang-questions] how: perl <-> erlang In-Reply-To: <47CC8FAF.1070506@ghostgun.com> References: <47CC8FAF.1070506@ghostgun.com> Message-ID: On Mar 3, 2008, at 3:54 PM, jm wrote: > What is the best approach for communicating between perl and erlang? > The > plan is to write a custom module or a hook function to send/retrieve > information between radiator ( a perl based radius server) and > something > written in erlang. The documentation is pretty limited, but this seems designed to run perl code as an Erlang port: http://search.cpan.org/~hio/Erlang-Port-0.04/lib/Erlang/Port.pm -kevin From silvester.roessner Tue Mar 4 07:47:13 2008 From: silvester.roessner (Roessner, Silvester) Date: Tue, 4 Mar 2008 07:47:13 +0100 Subject: [erlang-questions] how: perl <-> erlang In-Reply-To: <47CC8FAF.1070506@ghostgun.com> References: <47CC8FAF.1070506@ghostgun.com> Message-ID: <2CEB6DA5040AED4F946351C85FAC87B501886820@DEJENSAPP01V1.vision.zeiss.org> Hi Jeff, I have written a generic Erlang <-> Perl interface a year ago. It uses an Erlang port in binary mode. In that way I can handle all Erlang types and map them to Perl types. But that also means that Erlang has to start Perl, not vice versa. It's 80 % ready. I stopped working on it as I found an error in Erlang or Perl. If you like, Jeff, I can send you the code as is. Your posting has motivated me! I'll start to finish the interface this evening - yeah. Thank's for that! mit freundlichen Gr??en / with kind regards Silvester R??ner ------------------------------------------------------------------------------------------------------- Carl Zeiss Vision GmbH Corporate Technology Solution Architect Software Application Development S i l v e s t e r R ? ? n e r phone: +49 7361 591 831 fax: +49 7361 591 498 mailto: silvester.roessner Carl Zeiss Vision GmbH, Turnstr. 27, 73430 Aalen Gesch?ftsf?hrer: Rudolf Spiller Sitz der Gesellschaft: 73430 Aalen, Deutschland Amtsgericht Ulm, HRB 501574, USt.-IdNr.: DE 237 102 722 ------------------------------------------------------------------------------------------------------- -----Urspr?ngliche Nachricht----- Von: erlang-questions-bounces [mailto:erlang-questions-bounces] Im Auftrag von jm Gesendet: Dienstag, 4. M?rz 2008 00:54 An: erlang-questions Betreff: [erlang-questions] how: perl <-> erlang What is the best approach for communicating between perl and erlang? The plan is to write a custom module or a hook function to send/retrieve information between radiator ( a perl based radius server) and something written in erlang. Jeff. _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From eranga.erl Tue Mar 4 08:15:31 2008 From: eranga.erl (Eranga Udesh) Date: Tue, 4 Mar 2008 12:45:31 +0530 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: References: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> Message-ID: <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> The problem occurs when the network connectivity is broken (abnormally). The receiving node is not receiving messages. The sending processes are blocked, since those message delivery calls (gen_event:notify/s, etc) are waiting for about 10 secs to return. We checked the implementation of such calls and notice, the functions are waiting until the messages are delivered to the receiving node. Is there's a way (a system flag may be) to avoid such blocking and to return immediately? BRgds, - Eranga On Mon, Mar 3, 2008 at 6:51 PM, Chandru < chandrashekhar.mullaparthi> wrote: > On 03/03/2008, Eranga Udesh wrote: > > Hi, > > > > I am experiencing a high message passing delay between 2 Erlang nodes, > after > > an abnormal network disconnection. Those 2 nodes are in a WAN and there > are > > multiple Hubs, Switches, Routes, etc., in between them. If the message > > receiving Erlang node stopped gracefully, the delay doesn't arise. Doing > > net_adm:ping/1 to that node results no delay "pang". However > > gen_event:notify/2, gen_server:cast/2, etc. are waiting for about 10 > seconds > > to return. > > > > What's the issue and how this can be avoided? > > Have you tried putting a snoop to see whether the delay is on the > sending/receiving side? > > This might be useful: http://www.erlang.org/contrib/erlsnoop-1.0.tgz > > cheers > Chandru > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/05f4ee47/attachment.html From ali.yakout Tue Mar 4 08:23:46 2008 From: ali.yakout (Ali Yakout) Date: Tue, 4 Mar 2008 08:23:46 +0100 Subject: [erlang-questions] File is_open() Message-ID: Hi, I'm doing some file processing and I want to prevent opening files while it is already opened. I tried to open the files in write mode but it always succeed (I can open the file for writing many times) 1> file:open("file",[write]) . {ok, <0,35,0>} 2> file:open("file",[write]) . {ok, <0,37,0>} I tried to rename the file after opening and it also succeeds, although the documentation says "Renaming of open files is not allowed on most platforms" 3> file:open("file",[read]) . {ok, <0,35,0>} 4> file:rename("file","file2") . ok Any clues ? Thanks Regards, Ali Yakout -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/f348c914/attachment-0001.html From tatezhou Tue Mar 4 08:36:33 2008 From: tatezhou (tatezhou) Date: Tue, 4 Mar 2008 15:36:33 +0800 Subject: [erlang-questions] Does Mnesia table fragmentation still support in the furture version? References: <82780C52-C47F-44B2-95D2-80AE427C8D5E@process-one.net> Message-ID: <005501c87dca$7a3aaa70$8b01a8c0@ZHOUBO> hello: My server wrote in erlang need to handle a large set of data in mnesia database (more than 2G), i use the mnesia table fragmentation to conver it. There is a few staff on the internet and online documents about mnesia table fragmentation. does anyone give me some hits about how to get infomation this? does mnesia table fragmentation is the standard or recommanded technology for handle this situaction? Does it will support in furture verion of erlang? zhoubo -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/09ce965d/attachment.html From kenneth.lundin Tue Mar 4 08:58:35 2008 From: kenneth.lundin (Kenneth Lundin) Date: Tue, 4 Mar 2008 08:58:35 +0100 Subject: [erlang-questions] hipe binary matching problem with R12B-1? In-Reply-To: <02af01c87b91$613f9390$6401a8c0@moneymaker2> References: <65b2728e0802292250x32c31465w28ad1fdd940c7024@mail.gmail.com> <47C91B36.90601@cs.ntua.gr> <02af01c87b91$613f9390$6401a8c0@moneymaker2> Message-ID: Hi Valentin and others, It is not at all safe to assume thar R11 is the safest bet for Linux. When it comes to R11 there are a few bugs found in the runtime system for example regarding SMP and 64 bit which are corrected in R12 (but not in R11, and will not be by us). There are also lots of improvements in R12. I don't think there has been any major stability problems with R12 that should make users hesitate to use it in products. I admit that there has been a number of problems but mostly not with impact on stability. I think you are fooling yourselves if you take the defensive approach. /Kenneth Erlang/OTP team Ericsson On 3/1/08, Valentin Micic wrote: > From: "Kostis Sagonas" > > > Yes, this is a bug. We will fix it > > May I ask if this bug is limited to Linux, or it is unversal to all > supported platforms (e.g. Solaris). > Would it be safe to assume that R11 is still the safest bet for Linux? > > Thanks in advance. > > V. > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From bengt.kleberg Tue Mar 4 09:29:40 2008 From: bengt.kleberg (Bengt Kleberg) Date: Tue, 04 Mar 2008 09:29:40 +0100 Subject: [erlang-questions] File is_open() In-Reply-To: References: Message-ID: <1204619380.5690.19.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, There is no unix support for opening a file as the exclusive reader. The only time O_EXCL has any meaning is with O_CREAT, where it will make sure that the file does not exist before you create it. This will stop you from having several writers to the same file. If you want to limit the number of readers of a file I would recommend a resource handler. A process that keeps track of the number of readers. bengt On Tue, 2008-03-04 at 08:23 +0100, Ali Yakout wrote: > Hi, > > I'm doing some file processing and I want to prevent opening files > while it is already opened. > I tried to open the files in write mode but it always succeed (I can > open the file for writing many times) > > 1> file:open("file",[write]). > {ok, <0,35,0>} > 2> file:open("file",[write]). > {ok, <0,37,0>} > > I tried to rename the file after opening and it also succeeds, > although the documentation says "Renaming of open files is not allowed > on most platforms" > > 3> file:open("file",[read]). > {ok, <0,35,0>} > 4> file:rename("file","file2"). > ok > > Any clues ? > > > Thanks > > Regards, > Ali Yakout > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From ulf.wiger Tue Mar 4 09:38:31 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 04 Mar 2008 09:38:31 +0100 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> References: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> Message-ID: <47CD0A87.1040606@ericsson.com> It sounds as if the sending node is blocked in auto-connect. Try the kernel environment variable {dist_auto_connect, once}. It will ensure that any attempt to send to a disconnected node immediately fails. If one of the nodes restarts, they will automatically reconnect, as usual. You can explicitly connect the two nodes by calling net_kernel:connect(Node). BR, Ulf W Eranga Udesh skrev: > The problem occurs when the network connectivity is broken (abnormally). > The receiving node is not receiving messages. The sending processes are > blocked, since those message delivery calls (gen_event:notify/s, etc) > are waiting for about 10 secs to return. We checked the implementation > of such calls and notice, the functions are waiting until the messages > are delivered to the receiving node. Is there's a way (a system flag may > be) to avoid such blocking and to return immediately? > > BRgds, > - Eranga > > > > On Mon, Mar 3, 2008 at 6:51 PM, Chandru > > wrote: > > On 03/03/2008, Eranga Udesh > wrote: > > Hi, > > > > I am experiencing a high message passing delay between 2 Erlang > nodes, after > > an abnormal network disconnection. Those 2 nodes are in a WAN and > there are > > multiple Hubs, Switches, Routes, etc., in between them. If the > message > > receiving Erlang node stopped gracefully, the delay doesn't > arise. Doing > > net_adm:ping/1 to that node results no delay "pang". However > > gen_event:notify/2, gen_server:cast/2, etc. are waiting for about > 10 seconds > > to return. > > > > What's the issue and how this can be avoided? > > Have you tried putting a snoop to see whether the delay is on the > sending/receiving side? > > This might be useful: http://www.erlang.org/contrib/erlsnoop-1.0.tgz > > cheers > Chandru > > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From chandrashekhar.mullaparthi Tue Mar 4 10:14:20 2008 From: chandrashekhar.mullaparthi (Chandru) Date: Tue, 4 Mar 2008 09:14:20 +0000 Subject: [erlang-questions] Does Mnesia table fragmentation still support in the furture version? In-Reply-To: <005501c87dca$7a3aaa70$8b01a8c0@ZHOUBO> References: <82780C52-C47F-44B2-95D2-80AE427C8D5E@process-one.net> <005501c87dca$7a3aaa70$8b01a8c0@ZHOUBO> Message-ID: On 04/03/2008, tatezhou wrote: > > hello: > > My server wrote in erlang need to handle a large set of data in mnesia > database (more than 2G), i use the mnesia table fragmentation to conver it. > There is a few staff on the internet and online documents about mnesia table > fragmentation. does anyone give me some hits about how to get infomation > this? Have you seen this? http://www.erlang.org/doc/apps/mnesia/part_frame.html Section 5.3 explains table fragmentation. > does mnesia table fragmentation is the standard or recommanded technology > for handle this situaction? Does it will support in furture verion of > erlang? Yes - table fragmentation is recommended to handle large datasets. I'm banking on the fact that table fragmentation will be supported into the future. We use it extensively in T-Mobile UK. cheers Chandru From rapsey Tue Mar 4 10:40:34 2008 From: rapsey (Rapsey) Date: Tue, 4 Mar 2008 10:40:34 +0100 Subject: [erlang-questions] mnesia as website database Message-ID: <97619b170803040140q4452c013m82ac7db6f323edef@mail.gmail.com> What are the disadvantages of using mnesia as a website DB? It would more or less store user data, comments and articles. I have never used it for larger amounts of data, but since it makes fragmentation and transactions so easy, it seems like it would be the perfect database even for large sites. But I think most yaws sites use Postgresql/mysql right? Why? thanks Sergej -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/31d32e73/attachment.html From chandrashekhar.mullaparthi Tue Mar 4 11:14:31 2008 From: chandrashekhar.mullaparthi (Chandru) Date: Tue, 4 Mar 2008 10:14:31 +0000 Subject: [erlang-questions] Does Mnesia table fragmentation still support in the furture version? In-Reply-To: <00f901c87dde$fbe3c840$8b01a8c0@ZHOUBO> References: <82780C52-C47F-44B2-95D2-80AE427C8D5E@process-one.net> <005501c87dca$7a3aaa70$8b01a8c0@ZHOUBO> <00f901c87dde$fbe3c840$8b01a8c0@ZHOUBO> Message-ID: On 04/03/2008, tatezhou wrote: > I've checked the latest version of document , i found out that chapter about mnesia table fragmentation (chapter 5.3.1 ) is out of date. > > Acctually , mnesia module doesn't have function change_table_frag /4 which introduced in the example of how an existing Mnesia table is converted to be a fragmented table in chapter 5.3.1. I just checked the documentation and the example only invoked mnesia:change_table_frag/2, not change_table_frag/4. Are you sure you are reading it correctly? And mnesia:change_table_frag/2 does exist. It is true that change_table_frag/2 is not documented in the reference manual, but the stuff in the user manual should be enough to get the job done. > So i worried that the Mnesia Table Fragmentation technology is deprecated or lacking maintenance. Anyone have more staff about table fragmentation technology? > Just the documentation needs a bit more work. If you ask me, the best way is to fire up the shell and try out creating and using a fragmented table. There is this article which explains things a bit more: http://www.trapexit.org/Mnesia_Table_Fragmentation cheers Chandru From eranga.erl Tue Mar 4 12:03:28 2008 From: eranga.erl (Eranga Udesh) Date: Tue, 4 Mar 2008 16:33:28 +0530 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: <47CD0A87.1040606@ericsson.com> References: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> <47CD0A87.1040606@ericsson.com> Message-ID: <912a3c160803040303y68cd6a14tb3fb2c1e91a57c23@mail.gmail.com> I can regenerate the behavior by stopping the network interface in the far node (linux ifdown). That runs the connected Erlang node, which was receiving the messages. I wonder if this how the Erlang implementation is or local to this particular setup. Also I use HIPE. I'll try what you suggested below and also without HIPE. Thanks, - Eranga On Tue, Mar 4, 2008 at 2:08 PM, Ulf Wiger (TN/EAB) wrote: > > It sounds as if the sending node is blocked in auto-connect. > > Try the kernel environment variable {dist_auto_connect, once}. > It will ensure that any attempt to send to a disconnected node > immediately fails. If one of the nodes restarts, they will > automatically reconnect, as usual. You can explicitly connect > the two nodes by calling net_kernel:connect(Node). > > BR, > Ulf W > > Eranga Udesh skrev: > > The problem occurs when the network connectivity is broken (abnormally). > > The receiving node is not receiving messages. The sending processes are > > blocked, since those message delivery calls (gen_event:notify/s, etc) > > are waiting for about 10 secs to return. We checked the implementation > > of such calls and notice, the functions are waiting until the messages > > are delivered to the receiving node. Is there's a way (a system flag may > > be) to avoid such blocking and to return immediately? > > > > BRgds, > > - Eranga > > > > > > > > On Mon, Mar 3, 2008 at 6:51 PM, Chandru > > > > wrote: > > > > On 03/03/2008, Eranga Udesh > > wrote: > > > Hi, > > > > > > I am experiencing a high message passing delay between 2 Erlang > > nodes, after > > > an abnormal network disconnection. Those 2 nodes are in a WAN and > > there are > > > multiple Hubs, Switches, Routes, etc., in between them. If the > > message > > > receiving Erlang node stopped gracefully, the delay doesn't > > arise. Doing > > > net_adm:ping/1 to that node results no delay "pang". However > > > gen_event:notify/2, gen_server:cast/2, etc. are waiting for about > > 10 seconds > > > to return. > > > > > > What's the issue and how this can be avoided? > > > > Have you tried putting a snoop to see whether the delay is on the > > sending/receiving side? > > > > This might be useful: http://www.erlang.org/contrib/erlsnoop-1.0.tgz > > > > cheers > > Chandru > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/41d9fba6/attachment.html From tatezhou Tue Mar 4 14:23:39 2008 From: tatezhou (tatezhou) Date: Tue, 4 Mar 2008 21:23:39 +0800 Subject: [erlang-questions] Does Mnesia table fragmentation still support in the furture version? References: <82780C52-C47F-44B2-95D2-80AE427C8D5E@process-one.net> <005501c87dca$7a3aaa70$8b01a8c0@ZHOUBO> <00f901c87dde$fbe3c840$8b01a8c0@ZHOUBO> Message-ID: <016801c87dfa$f8191af0$8b01a8c0@ZHOUBO> For the first issue about change_table_frag/4, i made a mistake . The example only invoked change_table_frag/2 not change_table_frag/4. I've checked the document , Although function change_table_frag/2 doesn't describe in document, it exported in the source code (mnesia.erl). The article http://www.trapexit.org/Mnesia_Table_Fragmentation is a good guide to get start mnesia table fragmentation. thanks A special tips for chinese guys , http://www.trapexit.org may does not accessable in china directly , You may need a web proxy. i don't known the reason. ----- Original Message ----- From: "Chandru" To: ; "Erlang Questions" Sent: Tuesday, March 04, 2008 6:14 PM Subject: Re: [erlang-questions] Does Mnesia table fragmentation still support in the furture version? > On 04/03/2008, tatezhou wrote: >> I've checked the latest version of document , i found out that chapter about mnesia table fragmentation (chapter 5.3.1 ) is out of date. >> >> Acctually , mnesia module doesn't have function change_table_frag /4 which introduced in the example of how an existing Mnesia table is converted to be a fragmented table in chapter 5.3.1. > > I just checked the documentation and the example only invoked > mnesia:change_table_frag/2, not change_table_frag/4. Are you sure you > are reading it correctly? And mnesia:change_table_frag/2 does exist. > > It is true that change_table_frag/2 is not documented in the reference > manual, but the stuff in the user manual should be enough to get the > job done. > >> So i worried that the Mnesia Table Fragmentation technology is deprecated or lacking maintenance. Anyone have more staff about table fragmentation technology? >> > Just the documentation needs a bit more work. If you ask me, the best > way is to fire up the shell and try out creating and using a > fragmented table. > > There is this article which explains things a bit more: > http://www.trapexit.org/Mnesia_Table_Fragmentation > > cheers > Chandru From ConveyCJ Tue Mar 4 15:13:37 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Tue, 04 Mar 2008 09:13:37 -0500 Subject: [erlang-questions] Function to print a record with fieldnames? Message-ID: <1C538D67B37E5B4784128A22270DF5C30FF782EC@npri54exc20.npt.nuwc.navy.mil> I've got a record definition along the lines of: -record(myrec, {foo = undefined, bar=undefined}). To help with debugging, I'd like a function that will print out something like the following text: #record{foo = 42, bar = the_answer_to_the_question} Does such a function exist, or must I write my own version of the function for each record type? I know I can just use io:format("~p~n", [ MyRecord ]), but I'd really like the fieldnames to also be printed. Christian Convey Scientist, Naval Undersea Warfare Centers Newport, RI From toby Tue Mar 4 15:30:54 2008 From: toby (Toby Thain) Date: Tue, 4 Mar 2008 09:30:54 -0500 Subject: [erlang-questions] mnesia as website database In-Reply-To: <97619b170803040140q4452c013m82ac7db6f323edef@mail.gmail.com> References: <97619b170803040140q4452c013m82ac7db6f323edef@mail.gmail.com> Message-ID: <1555C39D-ADB9-434F-9BBD-FD962C77AD0F@telegraphics.com.au> On 4-Mar-08, at 4:40 AM, Rapsey wrote: > What are the disadvantages of using mnesia as a website DB? It > would more or less store user data, comments and articles. I have > never used it for larger amounts of data, but since it makes > fragmentation and transactions so easy, it seems like it would be > the perfect database even for large sites. > But I think most yaws sites use Postgresql/mysql right? Why? You get SQL; plus you might want to run 3rd party applications that use SQL etc, etc. --Toby > > > > thanks > Sergej > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From ulf.wiger Tue Mar 4 15:38:16 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 04 Mar 2008 15:38:16 +0100 Subject: [erlang-questions] Function to print a record with fieldnames? In-Reply-To: <1C538D67B37E5B4784128A22270DF5C30FF782EC@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C30FF782EC@npri54exc20.npt.nuwc.navy.mil> Message-ID: <47CD5ED8.9080508@ericsson.com> Convey Christian J NPRI skrev: > I've got a record definition along the lines of: -record(myrec, {foo = undefined, bar=undefined}). > > To help with debugging, I'd like a function that will print out something like the following text: > #record{foo = 42, bar = the_answer_to_the_question} > > Does such a function exist, or must I write my own version of the function for each record type? I know I can just use io:format("~p~n", [ MyRecord ]), but I'd really like the fieldnames to also be printed. There is such a function - almost (it's not documented, and may not do exactly what you want). I wrote about it a while back in my blog: http://ulf.wiger.net/weblog/2007/11/20/extending-the-erlang-shell-part-1/ BR, Ulf W From mats.cronqvist Tue Mar 4 15:53:02 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 04 Mar 2008 15:53:02 +0100 Subject: [erlang-questions] Function to print a record with fieldnames? In-Reply-To: <1C538D67B37E5B4784128A22270DF5C30FF782EC@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C30FF782EC@npri54exc20.npt.nuwc.navy.mil> Message-ID: <47CD624E.7020107@kreditor.se> Convey Christian J NPRI wrote: > I've got a record definition along the lines of: -record(myrec, {foo = undefined, bar=undefined}). > > To help with debugging, I'd like a function that will print out something like the following text: > #record{foo = 42, bar = the_answer_to_the_question} > > Does such a function exist, or must I write my own version of the function for each record type? I know I can just use io:format("~p~n", [ MyRecord ]), but I'd really like the fieldnames to also be printed. > best i've seen is variations on this theme; -module('foo'). -author('Mats Cronqvist'). -export([go/0]). -define(rec_info(T,R),lists:zip(record_info(fields,T),tl(tuple_to_list(R)))). -record(r,{bla,foo,baz,bar}). go() -> ?rec_info(r,#r{}). -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/b52b1ac8/attachment.vcf From ConveyCJ Tue Mar 4 16:07:21 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Tue, 04 Mar 2008 10:07:21 -0500 Subject: [erlang-questions] Function to print a record with fieldnames ? Message-ID: <1C538D67B37E5B4784128A22270DF5C30FF7854B@npri54exc20.npt.nuwc.navy.mil> Thanks Ulf. Perhaps my inexperience with Erlang is hindering me, but from your blog I don't see how to employ your work. Specifically, the version of the shell I'm using doesn't seem to have the extensions you defined (fa / fl / fr), and even if it did, wouldn't I still need to write a new pretty-printer extension for each tagged record type? Thanks, Christian > -----Original Message----- > From: Ulf Wiger (TN/EAB) [mailto:ulf.wiger] > Sent: Tuesday, March 04, 2008 9:38 AM > To: Convey Christian J NPRI > Cc: erlang-questions > Subject: Re: [erlang-questions] Function to print a record > with fieldnames? > > Convey Christian J NPRI skrev: > > I've got a record definition along the lines of: > -record(myrec, {foo = undefined, bar=undefined}). > > > > To help with debugging, I'd like a function that will print > out something like the following text: > > #record{foo = 42, bar = the_answer_to_the_question} > > > > Does such a function exist, or must I write my own version > of the function for each record type? I know I can just use > io:format("~p~n", [ MyRecord ]), but I'd really like the > fieldnames to also be printed. > > There is such a function - almost (it's not documented, and > may not do exactly what you want). > > I wrote about it a while back in my blog: > > http://ulf.wiger.net/weblog/2007/11/20/extending-the-erlang-sh > ell-part-1/ > > BR, > Ulf W > From jwebb Tue Mar 4 16:10:58 2008 From: jwebb (John Webb) Date: Wed, 5 Mar 2008 00:10:58 +0900 Subject: [erlang-questions] R12B-1 dialyzer 'Unsupported primop' error In-Reply-To: <47CC57DA.7050209@cs.ntua.gr> References: <47CC57DA.7050209@cs.ntua.gr> Message-ID: <9460DF84-510A-49E6-A962-D5F909697342@gol.com> Many thanks for the clarification! I was curious as to whether it was unsupported as in "overlooked" or unsupported as in "don't hold your breath". I'll ignore old_style and breath normally :) Best Regards, John On Mar 4, 2008, at 4:56 AM, Kostis Sagonas wrote: > John Webb wrote: >> In R12B-1 the following seemingly correct (if not so useful) >> program yields the error {'Unsupported primop', >> bs_context_to_binary} when dialyzer runs with the "Old Style" >> analysis option. >> -module(test). >> -compile(export_all). >> start(<<>>) -> ok. >> The compiler seems to emit the primop when the function arguments >> contain a binary match and there is no final catch-all clause. My >> code runs as expected so I am assuming this is a dialyzer issue? > > Yes. The issue is that "old_style" has not been updated to support > all primops that the current compiler generates. Come to think of > it, why should it? We see little reason for a user to want > "old_style" and at the same time generating .beam files by using the > current compiler... > > Unrelated to your mail, last week we decided to discontinue support > for the "old_style" option and today we actually took it out all > that code. > The current development version of Dialyzer spits out this error: > > Option --old_style is no longer supported > > Sorry, but there will not be a fix for your problem. The new > Dialyzer is much much better and we see little reason to continue > generating warnings without line information (as --old_style does). > > Kostis From ConveyCJ Tue Mar 4 16:14:24 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Tue, 04 Mar 2008 10:14:24 -0500 Subject: [erlang-questions] Function to print a record with fieldnames ? Message-ID: <1C538D67B37E5B4784128A22270DF5C30FF78591@npri54exc20.npt.nuwc.navy.mil> Thanks Mats, That works great for me. Could you explain something to me please? : Why must this be a macro rather than a function? It seems that if I want rec_info to be a function rather than a macro, record_info's second parameter must be a hard-coded atom; it cannot be a variable. But nothing I've read in Armstrong's book led me to think that such a restriction was possible in Erlang. Thanks, Christian > -----Original Message----- > From: Mats Cronqvist [mailto:mats.cronqvist] > Sent: Tuesday, March 04, 2008 9:53 AM > To: Convey Christian J NPRI > Cc: erlang-questions > Subject: Re: [erlang-questions] Function to print a record > with fieldnames? > > Convey Christian J NPRI wrote: > > I've got a record definition along the lines of: > -record(myrec, {foo = undefined, bar=undefined}). > > > > To help with debugging, I'd like a function that will print > out something like the following text: > > #record{foo = 42, bar = the_answer_to_the_question} > > > > Does such a function exist, or must I write my own version > of the function for each record type? I know I can just use > io:format("~p~n", [ MyRecord ]), but I'd really like the > fieldnames to also be printed. > > > best i've seen is variations on this theme; > > -module('foo'). > -author('Mats Cronqvist'). > -export([go/0]). > > -define(rec_info(T,R),lists:zip(record_info(fields,T),tl(tuple > _to_list(R)))). > -record(r,{bla,foo,baz,bar}). > > go() -> ?rec_info(r,#r{}). > > > From masterofquestions Tue Mar 4 16:21:00 2008 From: masterofquestions (db) Date: Tue, 4 Mar 2008 10:21:00 -0500 Subject: [erlang-questions] Terminating supervisor gracefully Message-ID: <1218d6a50803040721q3b6ef9e6g10d3db3a22a8f74e@mail.gmail.com> q1) I have several task that need to be called by crone. One of them is supervisor, which creates child process that perform the task. Once the child processes have completed their task, I would like to terminate supervisor gracefully. I looked at the supervisor.erl. It has terminate/2. I did some googling and came to conclusion that only graceful way to stop supervisor and the tree is via otp application. That brings up another question: if crone starts an erlang otp application, I need a way to know when to stop it. Seems like, I have to spawn a process to monitor otp_application and when supervisor's workers have finished the task, send a signal to application_monitor process, indicating it's safe to stop the otp_application. Any other workaround? q2) Would it be possible to have erlang_source viewable on the web? Google code displays outdated releases. -- rk That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. -Ralph Waldo Emerson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/4647cb09/attachment.html From kostis Tue Mar 4 16:25:17 2008 From: kostis (Kostis Sagonas) Date: Tue, 04 Mar 2008 17:25:17 +0200 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: <912a3c160803040303y68cd6a14tb3fb2c1e91a57c23@mail.gmail.com> References: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> <47CD0A87.1040606@ericsson.com> <912a3c160803040303y68cd6a14tb3fb2c1e91a57c23@mail.gmail.com> Message-ID: <47CD69DD.1010701@cs.ntua.gr> Eranga Udesh wrote: > I can regenerate the behavior by stopping the network interface in the > far node (linux ifdown). That runs the connected Erlang node, which was > receiving the messages. I wonder if this how the Erlang implementation > is or local to this particular setup. > > Also I use HIPE. I'll try what you suggested below and also without HIPE. Why would HiPE have some effect in what you are describing? Kostis From als Tue Mar 4 15:11:51 2008 From: als (Anthony Shipman) Date: Wed, 5 Mar 2008 01:11:51 +1100 Subject: [erlang-questions] strange node communication startup delay Message-ID: <200803050111.51930.als@iinet.net.au> I have several nodes running on the same computer, so inter-node communication is normally very fast. Shortly after starting the first node starts a third node which has a gen_server that immediately registers with a gen_server in the first node. There is a long round-trip delay of up to 3 seconds at this point. (The second node is idle at this time). The third node performs these steps at startup: case net_kernel:connect_node(Node) of true -> log:format("muConnector: connected to ~p", [Node]), global:sync(), monitor_node(Node, true), onUp(State); ... log:format("muConnector: MU is up"), ... log:format("fleetMgrImpl: MU connected"), regIface:rtt(), regIface:register(fleet, ID, self()), log:format("fleetMgrImpl: Fleet process registered"), regIface:rtt(), which results in these log messages on the third node: 5-Mar-2008 00:35:14.517| muConnector: connected to 'SMU_mySite' 5-Mar-2008 00:35:14.723| muConnector: MU is up 5-Mar-2008 00:35:14.723| fleetMgrImpl: MU connected 5-Mar-2008 00:35:16.174| regIface:rtt delay 1449075 us 5-Mar-2008 00:35:16.215| fleetMgrImpl: Fleet process registered 5-Mar-2008 00:35:16.215| regIface:rtt delay 842 us The first call to rtt has measured a 1.45s delay for a simple echo. I have process tracing on the first node with options: send, 'receive', procs, timestamp, running, set_on_spawn. The trace on the first node shows lots of global name registration activity around 00:35:14.721 to 00:35:14.722: 5-Mar-2008 00:35:14.721| [<0.11.0>, 'receive', {'$gen_call',{<8232.12.0>,{#Ref<8232.0.0.182>,'SMU_mySite'}}, {set_lock,{global,[<0.12.0>,<8232.12.0>]}}}] ................ 5-Mar-2008 00:35:14.722| [<0.11.0>, send, {'$gen_cast', {exchange, 'SMU_mySite', [{'mySite/registry',<0.84.0>,{global,random_exit_name}}, {'mySite/sigMgr',<0.108.0>,{global,random_exit_name}}, {'mySite/evtMgr',<0.90.0>,{global,random_exit_name}}, {'mySite\001muMgr',<0.106.0>,{global,random_exit_name}}], [], {1204,637714,517547}}}, {global_name_server,fleet_1_mySite}] ................ 5-Mar-2008 00:35:14.722| [<0.11.0>, send, {'$gen_cast',{resolved,'SMU_mySite', [], ['SPU1_mySite'], ['SPU1_mySite'], [], {1204,637714,517547}}}, {global_name_server,fleet_1_mySite}] 5-Mar-2008 00:35:14.722| [<0.11.0>, send, {cancel,fleet_1_mySite, {1204,637714,517912},#Fun}, <0.12.0>] ................ 5-Mar-2008 00:35:14.723| [<0.12.0>, send, {'$gen_call',{<0.12.0>,{#Ref<0.0.0.388>,'SPU1_mySite'}}, {del_lock,{global,[<0.12.0>,<8232.12.0>]}}}, {global_name_server,'SPU1_mySite'}] ................ 5-Mar-2008 00:35:14.761| [<0.11.0>, 'receive', {'$gen_call',{<8232.12.0>,{#Ref<8232.0.0.192>,'SMU_mySite'}}, {del_lock,{global,[<0.12.0>,<8232.12.0>]}}}] 5-Mar-2008 00:35:14.761| [<0.12.0>,out,{global,loop_the_locker,1}] Next the trace shows the arrival of the echo message with its time-stamp. The message left the third node at 00:35:14.725 but it did not arrive at the first node until 00:35:16.174. The reply was essentially immediate. 5-Mar-2008 00:35:16.174| [<0.84.0>, 'receive', {'$gen_call',{<8232.87.0>,#Ref<8232.0.0.204>}, {regEcho,{1204,637714,725844}}}] 5-Mar-2008 00:35:16.174| [<0.84.0>,in,{gen_server,loop,6}] 5-Mar-2008 00:35:16.174| [<0.84.0>,send,{#Ref<8232.0.0.204>,{ok, {1204,637714,725844}}},<8232.87.0>] According to the process trace nothing else happened on the first node between 00:35:14.761 and 00:35:16.174. So why the 1.4 second delay in communication? Can I get traces of the inter-node communication? From ulf.wiger Tue Mar 4 16:29:27 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 04 Mar 2008 16:29:27 +0100 Subject: [erlang-questions] Function to print a record with fieldnames ? In-Reply-To: <1C538D67B37E5B4784128A22270DF5C30FF7854B@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C30FF7854B@npri54exc20.npt.nuwc.navy.mil> Message-ID: <47CD6AD7.1060402@ericsson.com> Convey Christian J NPRI skrev: > Thanks Ulf. > > Perhaps my inexperience with Erlang is hindering me, but from your > blog I don't see how to employ your work. Specifically, the version of > the shell I'm using doesn't seem to have the extensions you defined (fa > / fl / fr), and even if it did, wouldn't I still need to write a new > pretty-printer extension for each tagged record type? > > Thanks, > Christian Yes, I guess that was a bit over the top, if all you wanted to do was to print some debugging output. (: http://forum.trapexit.org/viewtopic.php?p=21790#21790 Perhaps this contrib is a little bit more along the lines of Mats's good advice. BTW, he used a macro because the record_info/2 function is a "pseudo function", recognized expanded by the pre-processor. The contribution described above (following the link), a "parse transform"(*) generates real functions for reading and writing record data, including metadata such as field names. The post illustrates how to use this to write a pretty-printing function. BR, Ulf W (*) Parse transform sounds ominous, but it boils down to including a .hrl file and making sure that the exprecs.beam file is in the path when compiling. > >> -----Original Message----- >> From: Ulf Wiger (TN/EAB) [mailto:ulf.wiger] >> Sent: Tuesday, March 04, 2008 9:38 AM >> To: Convey Christian J NPRI >> Cc: erlang-questions >> Subject: Re: [erlang-questions] Function to print a record >> with fieldnames? >> >> Convey Christian J NPRI skrev: >>> I've got a record definition along the lines of: >> -record(myrec, {foo = undefined, bar=undefined}). >>> To help with debugging, I'd like a function that will print >> out something like the following text: >>> #record{foo = 42, bar = the_answer_to_the_question} >>> >>> Does such a function exist, or must I write my own version >> of the function for each record type? I know I can just use >> io:format("~p~n", [ MyRecord ]), but I'd really like the >> fieldnames to also be printed. >> >> There is such a function - almost (it's not documented, and >> may not do exactly what you want). >> >> I wrote about it a while back in my blog: >> >> http://ulf.wiger.net/weblog/2007/11/20/extending-the-erlang-sh >> ell-part-1/ >> >> BR, >> Ulf W >> > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From james.hague Tue Mar 4 17:11:22 2008 From: james.hague (James Hague) Date: Tue, 4 Mar 2008 10:11:22 -0600 Subject: [erlang-questions] Use of makefiles In-Reply-To: <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> Message-ID: On Sat, Mar 1, 2008 at 8:41 PM, Steve Vinoski wrote: > > Hi Joe, I agree with you 100%. Give me emacs (with its vast emacs-lisp > extensibility), bash (or ksh), and various UNIX command-line tools, > which I can combine as I wish using pipes, and keep the visual tools > out of my way (and out of my RAM). I think this discussion has been misinterpreted :) No one is arguing for IDE-like features over makefiles. I have found that I don't need makefiles for my Erlang projects. I either recompile the same module repeatedly or I want to rebuild everything. The former is business as usual. The latter is easily done with a shell script, Perl script, or short Erlang program. I use makefiles infrequently enough that I always forget the syntax and nuances of using them. But I can bang out a Perl program that does the same thing--even checking file modification dates and so on--in very little time. It's more flexible than using a makefile, too, and usually ends up being less "code." From Martin.Logan Tue Mar 4 17:12:31 2008 From: Martin.Logan (Logan, Martin) Date: Tue, 4 Mar 2008 10:12:31 -0600 Subject: [erlang-questions] gen_cron question In-Reply-To: <1218d6a50803020954y6f12529eo9ed08d517a879b48@mail.gmail.com> References: <1218d6a50803020954y6f12529eo9ed08d517a879b48@mail.gmail.com> Message-ID: Is there a reason you don't just use gen_server with a timeout? Init would return {ok, State, Timeout} and then you would run your task out of handle_info(timeout, State) -> ... Cheers, Martin ________________________________ From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of db Sent: Sunday, March 02, 2008 11:54 AM To: erlang-questions Subject: [erlang-questions] gen_cron question I need to purge 10 mnesia tables on day/hourly interval. I am looking at http://code.google.com/p/gencron/ to accomplish this. Documentation says gen_cron pretty much like gen_server. I am not an expert in gen_server. I want to create 1 process for each table to perform purging. Do I create 10 process intially and have them sleep on the interval or gen_cron starts these 10 process on interval? Any sample gen_cron example out there? Gen_cron seems to consider a task as a module. What if I want to run two different modules, do I start two different gen_cron with two different name? -- rk That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. -Ralph Waldo Emerson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/28beb42d/attachment-0001.html From bengt.kleberg Tue Mar 4 17:57:08 2008 From: bengt.kleberg (Bengt Kleberg) Date: Tue, 04 Mar 2008 17:57:08 +0100 Subject: [erlang-questions] Use of makefiles In-Reply-To: References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> Message-ID: <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, Is it not also the case that perl is more standard than make? I know very little of perl, but have fought at least 4 different kinds of make (files). bengt On Tue, 2008-03-04 at 10:11 -0600, James Hague wrote: > On Sat, Mar 1, 2008 at 8:41 PM, Steve Vinoski wrote: > > > > Hi Joe, I agree with you 100%. Give me emacs (with its vast emacs-lisp > > extensibility), bash (or ksh), and various UNIX command-line tools, > > which I can combine as I wish using pipes, and keep the visual tools > > out of my way (and out of my RAM). > > I think this discussion has been misinterpreted :) No one is arguing > for IDE-like features over makefiles. > > I have found that I don't need makefiles for my Erlang projects. I > either recompile the same module repeatedly or I want to rebuild > everything. The former is business as usual. The latter is easily > done with a shell script, Perl script, or short Erlang program. I use > makefiles infrequently enough that I always forget the syntax and > nuances of using them. But I can bang out a Perl program that does > the same thing--even checking file modification dates and so on--in > very little time. It's more flexible than using a makefile, too, and > usually ends up being less "code." > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From kenneth.lundin Tue Mar 4 17:58:44 2008 From: kenneth.lundin (Kenneth Lundin) Date: Tue, 4 Mar 2008 17:58:44 +0100 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> References: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> Message-ID: When connectivity is broken abnormally the sending node will detect this within 45-60 seconds as default. This can be changed with the net_tick_time environment variable in application kernel. Before the detection the sending node will try to send the message and if not possible it will be queued in the inet-driver. If the queue gets bigger than a certain max a so called "busy port" will occur which will block the sending Erlang process. This occurs when the receiving side of the distribution socket does not read what is sent to it which is the case when you have no connectivity. another scenario is that the receiving node is detected as down and an auto connect (including handshake) is performed for the first message sent after the broken connection. This will take in the order of 10 seconds before timeout. If you want to avoid this for a very crucial process (i.e avoid blocking of that particular Erlang process) you can send the message with erlang:send_nosuspend/2 or 3. Warning! these functions should be used with extreme care, Read the manual! Note that this has nothing to do with HiPE (i.e native code). An abnormal termination of the connectivity for example by unplugging the network cable will have this effect. /Kenneth Erlang/OTP team Ericsson On 3/4/08, Eranga Udesh wrote: > The problem occurs when the network connectivity is broken (abnormally). The > receiving node is not receiving messages. The sending processes are > blocked, since those message delivery calls (gen_event:notify/s, etc) are > waiting for about 10 secs to return. We checked the implementation of such > calls and notice, the functions are waiting until the messages are delivered > to the receiving node. Is there's a way (a system flag may be) to avoid such > blocking and to return immediately? > > BRgds, > - Eranga > > > > > On Mon, Mar 3, 2008 at 6:51 PM, Chandru > wrote: > > > > > > > > On 03/03/2008, Eranga Udesh wrote: > > > Hi, > > > > > > I am experiencing a high message passing delay between 2 Erlang nodes, > after > > > an abnormal network disconnection. Those 2 nodes are in a WAN and there > are > > > multiple Hubs, Switches, Routes, etc., in between them. If the message > > > receiving Erlang node stopped gracefully, the delay doesn't arise. Doing > > > net_adm:ping/1 to that node results no delay "pang". However > > > gen_event:notify/2, gen_server:cast/2, etc. are waiting for about 10 > seconds > > > to return. > > > > > > What's the issue and how this can be avoided? > > > > Have you tried putting a snoop to see whether the delay is on the > > sending/receiving side? > > > > This might be useful: > http://www.erlang.org/contrib/erlsnoop-1.0.tgz > > > > cheers > > Chandru > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From pfisher Tue Mar 4 17:52:21 2008 From: pfisher (Paul Fisher) Date: Tue, 04 Mar 2008 10:52:21 -0600 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <20080304161500.GA7329@erix.ericsson.se> References: <20080304161500.GA7329@erix.ericsson.se> Message-ID: <1204649541.6182.26.camel@pfisher-laptop> On Tue, 2008-03-04 at 17:15 +0100, Raimo Niskanen wrote: > EEP 9 is recognized by the EEP editor(s). > > http://www.erlang.org/eeps/ Overall, good show. This is progress in a very good direction. A couple of questions: 1) Can the reference implementation be made available publicly as a patch to R12B-1? (Or actually in any fashion would be great.) 2) Which algorithm was choosen for the binary:match()? For multiple keyword, Aho-Corasick would be great, especially if the interface was something like this: MatchContext = binary:match_compile( [<<"the">>, <<"big">>, <<"frog">>] ), Value = <<"when we had a frog, he was big">>, [{3, 14}, {2, 27}] = binary:match( MatchContext, Value ) Where the result tuples were keyword # and byte offset. More comments later, once I have some more time to consider the rest of the document. -- paul From fess-erlang Tue Mar 4 18:33:33 2008 From: fess-erlang (fess) Date: Tue, 4 Mar 2008 09:33:33 -0800 Subject: [erlang-questions] how: perl <-> erlang In-Reply-To: <47CC8FAF.1070506@ghostgun.com> References: <47CC8FAF.1070506@ghostgun.com> Message-ID: <3D708AD7-F56C-4FF4-849D-0CB5A6CC824A@fess.org> On Mar 3, 2008, at 3:54 PM, jm wrote: > What is the best approach for communicating between perl and > erlang? The > plan is to write a custom module or a hook function to send/retrieve > information between radiator ( a perl based radius server) and > something > written in erlang. A very simple approach is to use an erlang port. [ the stdin/stdout variety. ] basically look at erlang:open_port and erlang:port_command here's a good walkthrough talking to a python program: http://www.trapexit.org/Writing_an_Erlang_Port_using_OTP_Principles As you can tell from the other responses there are much more complicated routes you can go as well, if they suite your purpose. --fess From toby Tue Mar 4 18:42:23 2008 From: toby (Toby Thain) Date: Tue, 4 Mar 2008 12:42:23 -0500 Subject: [erlang-questions] Use of makefiles In-Reply-To: References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> Message-ID: <55CF13E8-2E25-474F-98A5-2FDB2D1DABCE@telegraphics.com.au> On 4-Mar-08, at 11:11 AM, James Hague wrote: > On Sat, Mar 1, 2008 at 8:41 PM, Steve Vinoski > wrote: >> >> Hi Joe, I agree with you 100%. Give me emacs (with its vast emacs- >> lisp >> extensibility), bash (or ksh), and various UNIX command-line tools, >> which I can combine as I wish using pipes, and keep the visual tools >> out of my way (and out of my RAM). > > I think this discussion has been misinterpreted :) No one is arguing > for IDE-like features over makefiles. > > I have found that I don't need makefiles for my Erlang projects. I > either recompile the same module repeatedly or I want to rebuild > everything. The former is business as usual. The latter is easily > done with a shell script, Perl script, or short Erlang program. I use > makefiles infrequently enough that I always forget the syntax and > nuances of using them. But I can bang out a Perl program that does > the same thing--even checking file modification dates and so on--in > very little time. It's more flexible than using a makefile, too, and > usually ends up being less "code." ORLY? I'd rather declare my deps in a Makefile than write *and debug* a Perl topological sort one-liner. --Toby > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From toby Tue Mar 4 19:09:10 2008 From: toby (Toby Thain) Date: Tue, 4 Mar 2008 13:09:10 -0500 Subject: [erlang-questions] Use of makefiles In-Reply-To: <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: <053657FB-5463-4F29-9FD1-32D83CCC3B4C@telegraphics.com.au> On 4-Mar-08, at 11:57 AM, Bengt Kleberg wrote: > Greetings, > > Is it not also the case that perl is more standard than make? Is *everyone* supposed to rewrite make in Perl every time they want to build something? > I know very little of perl, but have fought at least 4 different kinds > of make (files). The GNU make documentation is really very good. I don't know why people rarely refer to it. --T > > > bengt > > On Tue, 2008-03-04 at 10:11 -0600, James Hague wrote: >> On Sat, Mar 1, 2008 at 8:41 PM, Steve Vinoski >> wrote: >>> >>> Hi Joe, I agree with you 100%. Give me emacs (with its vast >>> emacs-lisp >>> extensibility), bash (or ksh), and various UNIX command-line tools, >>> which I can combine as I wish using pipes, and keep the visual >>> tools >>> out of my way (and out of my RAM). >> >> I think this discussion has been misinterpreted :) No one is arguing >> for IDE-like features over makefiles. >> >> I have found that I don't need makefiles for my Erlang projects. I >> either recompile the same module repeatedly or I want to rebuild >> everything. The former is business as usual. The latter is easily >> done with a shell script, Perl script, or short Erlang program. I >> use >> makefiles infrequently enough that I always forget the syntax and >> nuances of using them. But I can bang out a Perl program that does >> the same thing--even checking file modification dates and so on--in >> very little time. It's more flexible than using a makefile, too, and >> usually ends up being less "code." >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions >> http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From eranga.erl Tue Mar 4 19:30:01 2008 From: eranga.erl (Eranga Udesh) Date: Wed, 5 Mar 2008 00:00:01 +0530 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: References: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> Message-ID: <912a3c160803041030w54d931c1i5754db1d7901d150@mail.gmail.com> Thanks for the info and it makes sense. In "busy port" situation, do queued messages get discarded if the queue grows beyond a max? Is it FIFO or LIFO? Is there a way to configure this message queue size? Can one inet_drv "busy port" block all other connected (live) node communication? As I said before the net_adm:ping/1 returns "pang" immediately. Then why doesn't the message delivery function identify that the remote node is inaccessible, hence return immediately with an error? How the message delivery method implemented in Erlang? Is it to return as soon as the message is handed over to the local inet_drv or delivered to the receiving Erlang node's inet_drv and after receiving a confirmation or something? - Eranga On Tue, Mar 4, 2008 at 10:28 PM, Kenneth Lundin wrote: > When connectivity is broken abnormally the sending node will detect > this within 45-60 seconds as default. This can be changed with the > net_tick_time environment variable in application kernel. > Before the detection the sending node will try to send the message and > if not possible it will be queued in the inet-driver. If the queue > gets bigger than a certain max a so called "busy port" will occur > which will block the sending Erlang process. > This occurs when the receiving side of the distribution socket does > not read what is > sent to it which is the case when you have no connectivity. > > another scenario is that the receiving node is detected as down and > an auto connect (including handshake) is performed for the first > message sent after > the broken connection. This will take in the order of 10 seconds before > timeout. > > If you want to avoid this for a very crucial process (i.e avoid > blocking of that particular Erlang process) you can send the message > with erlang:send_nosuspend/2 or 3. Warning! these functions should be > used with extreme care, Read the manual! > > Note that this has nothing to do with HiPE (i.e native code). > An abnormal termination of the connectivity for example by unplugging > the network cable will have this effect. > > /Kenneth Erlang/OTP team Ericsson > > On 3/4/08, Eranga Udesh wrote: > > The problem occurs when the network connectivity is broken (abnormally). > The > > receiving node is not receiving messages. The sending processes are > > blocked, since those message delivery calls (gen_event:notify/s, etc) > are > > waiting for about 10 secs to return. We checked the implementation of > such > > calls and notice, the functions are waiting until the messages are > delivered > > to the receiving node. Is there's a way (a system flag may be) to avoid > such > > blocking and to return immediately? > > > > BRgds, > > - Eranga > > > > > > > > > > On Mon, Mar 3, 2008 at 6:51 PM, Chandru > > wrote: > > > > > > > > > > > > On 03/03/2008, Eranga Udesh wrote: > > > > Hi, > > > > > > > > I am experiencing a high message passing delay between 2 Erlang > nodes, > > after > > > > an abnormal network disconnection. Those 2 nodes are in a WAN and > there > > are > > > > multiple Hubs, Switches, Routes, etc., in between them. If the > message > > > > receiving Erlang node stopped gracefully, the delay doesn't arise. > Doing > > > > net_adm:ping/1 to that node results no delay "pang". However > > > > gen_event:notify/2, gen_server:cast/2, etc. are waiting for about 10 > > seconds > > > > to return. > > > > > > > > What's the issue and how this can be avoided? > > > > > > Have you tried putting a snoop to see whether the delay is on the > > > sending/receiving side? > > > > > > This might be useful: > > http://www.erlang.org/contrib/erlsnoop-1.0.tgz > > > > > > cheers > > > Chandru > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/102b9263/attachment-0001.html From eranga.erl Tue Mar 4 19:38:04 2008 From: eranga.erl (Eranga Udesh) Date: Wed, 5 Mar 2008 00:08:04 +0530 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: <47CD69DD.1010701@cs.ntua.gr> References: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> <47CD0A87.1040606@ericsson.com> <912a3c160803040303y68cd6a14tb3fb2c1e91a57c23@mail.gmail.com> <47CD69DD.1010701@cs.ntua.gr> Message-ID: <912a3c160803041038h77e9a604k99f4e59440df12d1@mail.gmail.com> It's just a guess. When compiled natively I've found some problems time to time, - garbage collection is not working well. Old heap is kept unnecessarily. I've written this to the list once before. - code loading crashes a running process more often Probably it's nothing to do with HIPE, but I thought to simulate the same without HIPE and check. - Eranga On Tue, Mar 4, 2008 at 8:55 PM, Kostis Sagonas wrote: > Eranga Udesh wrote: > > I can regenerate the behavior by stopping the network interface in the > > far node (linux ifdown). That runs the connected Erlang node, which was > > receiving the messages. I wonder if this how the Erlang implementation > > is or local to this particular setup. > > > > Also I use HIPE. I'll try what you suggested below and also without > HIPE. > > Why would HiPE have some effect in what you are describing? > > Kostis > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/cddaf22d/attachment.html From fritchie Tue Mar 4 19:51:31 2008 From: fritchie (Scott Lystig Fritchie) Date: Tue, 04 Mar 2008 12:51:31 -0600 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: Message of "Tue, 04 Mar 2008 12:45:31 +0530." <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> Message-ID: <72120.1204656691@snookles.snookles.com> Hi, everyone. I've read forward in the thread ... and am wondering if there's a simpler cause? Since the default distribution mechanism rides on top of TCP, the delay might be caused by TCP's exponential back-off when packet loss is encountered? A quick packet capture could verify this theory: there would be a big delay after the network partition is fixed (i.e. plug cable back in, "ifconfig {IFACE} up", whatever) and before the next packet (in either direction) is transmitted. -Scott From eranga.erl Tue Mar 4 20:06:58 2008 From: eranga.erl (Eranga Udesh) Date: Wed, 5 Mar 2008 00:36:58 +0530 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: <72120.1204656691@snookles.snookles.com> References: <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> <72120.1204656691@snookles.snookles.com> Message-ID: <912a3c160803041106p12b9e8c9k96359131cc124ffc@mail.gmail.com> The problem I am talking about occurs while the network is in partitioned condition. When the network connection is re-established and the Erlang node is connected with a net_adm:ping/1 the message queue drains out quickly and the nodes start working normal. As I said before, this delay occurs only after an abnormal network disconnection. If the receiving Erlang node is shutdown gracefully, the message delay doesn't occur. I doubt, this occurs only when the packets sent out are going to a black-hole and nobody responds that the destination TCP entity is unavailable. - Eranga On Wed, Mar 5, 2008 at 12:21 AM, Scott Lystig Fritchie < fritchie> wrote: > Hi, everyone. I've read forward in the thread ... and am wondering if > there's a simpler cause? Since the default distribution mechanism rides > on top of TCP, the delay might be caused by TCP's exponential back-off > when packet loss is encountered? A quick packet capture could verify > this theory: there would be a big delay after the network partition is > fixed (i.e. plug cable back in, "ifconfig {IFACE} up", whatever) and > before the next packet (in either direction) is transmitted. > > -Scott > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/0e5fde6e/attachment.html From richardc Tue Mar 4 21:59:33 2008 From: richardc (Richard Carlsson) Date: Tue, 04 Mar 2008 21:59:33 +0100 Subject: [erlang-questions] Use of makefiles In-Reply-To: References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> Message-ID: <47CDB835.2000401@it.uu.se> James Hague wrote: > I use makefiles infrequently enough that I always forget the syntax > and nuances of using them. But I can bang out a Perl program that > does the same thing--even checking file modification dates and so > on--in very little time. Well, each to his own. I use Perl infrequently enough that I always forget the syntax and nuances of it. But I can bang out a bash script or Makefile that does the same thing in very little time. /Richard From fredrik.svahn Tue Mar 4 22:02:04 2008 From: fredrik.svahn (Fredrik Svahn) Date: Tue, 4 Mar 2008 22:02:04 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> Message-ID: Thanks for the positive response both here an on the EEPs mailing list! My suggestion is that we continue the discussion regarding EEP-9 here on the erlang-questions mailing list since it has a broader audience than eeps I think it would make it a lot easier if we can keep it in this thread. For those who do not subscribe to the eeps mailing list, I would like to once again stress that this EEP does not cover improvements which requires changes to the compiler. It has been suggested to me that the smaller the EEP the faster it gets implemented so let us please keep the scope as narrow as possible. There is always room for new EEPs. A shortcut to EEP-9: http://www.erlang.org/eeps/eep-0009.html Now, to answer your questions: > 1) Can the reference implementation be made available publicly as a > patch to R12B-1? (Or actually in any fashion would be great.) The reference implementation in erlang is attached, the c part will follow in the next message as there is a maximum message size on erlang-questions. It matches the described functions minus what was added after a first round of comments from the OTP developers (the regexps for instance are probably going to have many more features after what I hear!). I may also have added one or two relatively simple functions, e.g. atom_to_binary, after the implementation was submitted. > 2) Which algorithm was choosen for the binary:match()? For multiple > keyword, Aho-Corasick would be great, especially if the interface was > something like this: In the reference implementation Aho-Corasick was indeed used for multiple keywords. Boyer-Moore was a logical choice for single keywords and there was even a brute force approach for short keywords/searchstrings. > MatchContext = binary:match_compile( [<<"the">>, <<"big">>, > <<"frog">>] ), > Value = <<"when we had a frog, he was big">>, > [{3, 14}, {2, 27}] = binary:match( MatchContext, Value ) Thanks for the comment. I think it makes a lot of sense to have a separation of the building of the trie and the actual searching as you suggest, especially if you are searching many binaries for the same keyword(s). I am not sure how easy it would be to implement it, though. I guess the returned match context would have to be some kind of reference or packed in a binary. Maybe someone from the OTP team could comment on that. I actually wanted to have the same thing for regular expressions. I note that you also want a function which returns all the matches not just the first one. Given that binary:match/3 takes indexes of the start and end position of the search it is easy to also add a function "binary:matches/2" in binary.erl which returns all the matches by repeatedly calling match/3. Having both "match/2" and "matches/2" would be similar to how it is done in the regexp module. BR /Fredrik -------------- next part -------------- A non-text attachment was scrubbed... Name: binary.erl Type: application/octet-stream Size: 4155 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/baf992ca/attachment.obj From fredrik.svahn Tue Mar 4 22:07:04 2008 From: fredrik.svahn (Fredrik Svahn) Date: Tue, 4 Mar 2008 22:07:04 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> Message-ID: The c part of the reference implementation is attached. BR /Fredrik -------------- next part -------------- A non-text attachment was scrubbed... Name: binary.c.diff Type: application/octet-stream Size: 28448 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/4dfb83ed/attachment-0001.obj From machinshin2002 Tue Mar 4 21:25:59 2008 From: machinshin2002 (Vat Raghavan) Date: Tue, 4 Mar 2008 12:25:59 -0800 (PST) Subject: [erlang-questions] [eeps] EEP 9 Message-ID: <548212.96608.qm@web31506.mail.mud.yahoo.com> I really like this eep, and i can't wait for it (or something quite similar :) ) to be part of otp. At least in part, it will mollify those who complain about erlang's string manipulation support though, i think a better name of the module would be binary_string or something along those lines. according to the eep, the reference implementation was given to the otp team along w/ the eep, it seems to me that according to the 'many eyes' theory such an implementation should also be available to all, either at the eep site (preferred) or at the author's website or what have you. as to your question paul, the eep makes some suggestions about either aho-corasick, or boyer-moore, so i think some profiling would be required before any implementation decision could be made; even still, we're more in api design phase at the moment, and whatever implementation is finally used, i don't think it's very relevant now. i do like the suggestion about binary:match,i often find when i search strings i want not only the index searched, but the string that was found -> [eep] -Maybe binary:match(<<"hello, world\n">>,[<<"xx">>,<<" ">>]) should return {Needle, Index} (i.e. {<<" ">>, 7}) instead? or perhaps {Index, NeedleLength} i.e. {7, 1}? [/eep] re: Unicode. perhaps it be better to have 2 seperate libraries for ascii vs. unicode? also, how would the module handle different encodings, utf-8/utf-16/utf-32, etc? --vat ----.signature---- Without the hope that things will get better, that our inheritors will know a world that is fuller and richer than our own, life is pointless, and evolution is vastly overrated -- Delenn ----- Original Message ---- From: Paul Fisher To: erlang-questions Sent: Tuesday, March 4, 2008 11:52:21 AM Subject: Re: [erlang-questions] [eeps] EEP 9 On Tue, 2008-03-04 at 17:15 +0100, Raimo Niskanen wrote: > EEP 9 is recognized by the EEP editor(s). > > http://www.erlang.org/eeps/ Overall, good show. This is progress in a very good direction. A couple of questions: 1) Can the reference implementation be made available publicly as a patch to R12B-1? (Or actually in any fashion would be great.) 2) Which algorithm was choosen for the binary:match()? For multiple keyword, Aho-Corasick would be great, especially if the interface was something like this: MatchContext = binary:match_compile( [<<"the">>, <<"big">>, <<"frog">>] ), Value = <<"when we had a frog, he was big">>, [{3, 14}, {2, 27}] = binary:match( MatchContext, Value ) Where the result tuples were keyword # and byte offset. More comments later, once I have some more time to consider the rest of the document. -- paul _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From kangas Tue Mar 4 22:51:09 2008 From: kangas (Matt Kangas) Date: Tue, 4 Mar 2008 16:51:09 -0500 Subject: [erlang-questions] Use of makefiles In-Reply-To: <47CDB835.2000401@it.uu.se> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <47CDB835.2000401@it.uu.se> Message-ID: <2D065D90-9DAA-49F4-9931-3744FFD95F1C@bway.net> For those who despise makefile syntax, there are plenty of newer "make replacements" out there: "rake" http://rake.rubyforge.org/ "ant" http://ant.apache.org/ "Jam" http://www.perforce.com/jam/jam.html Lesser known: "cons" (Perl), "SCons" (Python), "memoize". Google for "make replacement" to find these and more. Of course, *none* of these are as ubiquitous as "make", nor will be for a very long time. If you're shipping code for someone else to build -- e.g. Joe's book -- then "make" is the only realistic choice. --Matt, who's hoping this thread can die now :) On Mar 4, 2008, at 3:59 PM, Richard Carlsson wrote: > James Hague wrote: >> I use makefiles infrequently enough that I always forget the syntax >> and nuances of using them. But I can bang out a Perl program that >> does the same thing--even checking file modification dates and so >> on--in very little time. > > Well, each to his own. I use Perl infrequently enough that I always > forget the syntax and nuances of it. But I can bang out a bash script > or Makefile that does the same thing in very little time. > > /Richard -- Matt Kangas kangas ? www.p16blog.com From Martin.Logan Tue Mar 4 23:57:41 2008 From: Martin.Logan (Logan, Martin) Date: Tue, 4 Mar 2008 16:57:41 -0600 Subject: [erlang-questions] Use of makefiles In-Reply-To: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> Message-ID: I recommend Sinan. If that is not what you are looking for try OTP Base which is a make based build system. http://code.google.com/p/otp-base Cheers, Martin -----Original Message----- From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Alexander Lamb Sent: Thursday, February 28, 2008 5:40 AM To: erlang-questions Subject: [erlang-questions] Use of makefiles Hello list, I am starting a project in Erlang. I read Armstrong's book. He indicates he uses makefiles to manage compiling erlang modules. Now, I am wondering. Is this overkill? Slightly outdated (makefiles make me think of those sendmail config files: totally weird and impossible to understand)? What are the various strategies to manage your build / run or build / deploy cycles? Then, what is the strategy used to organize your code? I thought having a folder for a project, containing the makefile, then a subdirectory src and a subdirectory ebin Unfortunately, I didn't manage to get my makefile work with that setup. Here is my makefile: .SUFFIXES: .erl .beam .yrl .erl.beam: erlc -W $< .yrl.erl: erlc -W $< ERL = erl -boot start_clean MODS = profiles all: compile ${ERL} -s profiles start compile: ${MODS:%=%.beam} clean: rm -rf *.beam erl_crash.dump subdirs: cd src; make Now this works, but only with .erl and .beam files in the main directory. Thanks, -- Alexander Lamb Founding Associate RODANOTECH S?rl 4 ch. de la Tour de Champel 1206 Geneva Switzerland Tel: 022 347 77 37 Fax: 022 347 77 38 http://www.rodanotech.ch _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From armando Wed Mar 5 00:21:03 2008 From: armando (Armando Di Cianno) Date: Tue, 04 Mar 2008 18:21:03 -0500 Subject: [erlang-questions] Use of makefiles In-Reply-To: References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> Message-ID: <1204672863.6310.35.camel@localhost> On Tue, 2008-03-04 at 16:57 -0600, Logan, Martin wrote: > I recommend Sinan. If that is not what you are looking for try OTP Base which is a make based build system. http://code.google.com/p/otp-base Can you explain the differences between the tools/projects/names: Faxien, Sinan, Erlware, OTP Base? I asked some questionsd on #erlang a bit ago, but no one in the know was around. I downloaded faxien, but was unable to create my own bootstrap. I was also confused by its tight coupling to a specific erts version (which is why I was trying to build it myselfto begin with). Also unclear: is Erlware trying to completely replace my erlang install? I know it's not going to remove the one installed on the system, but is Erlware Erlang plus some stuff, or does Erlware work along side my system's Erlang? Finally, my goal in playing with Erlware a couple weeks ago was to write ebuilds for Gentoo. I already have a somewhat usefull eclass that checks the system for specific version of erlang libraries, but my efforts petered out when I found Erlware somewhat unapproachable. So ... please help to clarify this for me -- I'd really, *really* like to help out and support a more open Erlang library deployment system than CEAN. /me thinks he should join the erlware mailing lists > Cheers, > Martin > > -----Original Message----- > From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Alexander Lamb > Sent: Thursday, February 28, 2008 5:40 AM > To: erlang-questions > Subject: [erlang-questions] Use of makefiles > > Hello list, > > I am starting a project in Erlang. I read Armstrong's book. He > indicates he uses makefiles to manage compiling erlang modules. > > Now, I am wondering. Is this overkill? Slightly outdated (makefiles > make me think of those sendmail config files: totally weird and > impossible to understand)? > > What are the various strategies to manage your build / run or build / > deploy cycles? > > Then, what is the strategy used to organize your code? > > I thought having a folder for a project, containing the makefile, then > a subdirectory src and a subdirectory ebin > > Unfortunately, I didn't manage to get my makefile work with that > setup. Here is my makefile: > > .SUFFIXES: .erl .beam .yrl > > .erl.beam: > erlc -W $< > > .yrl.erl: > erlc -W $< > > ERL = erl -boot start_clean > > MODS = profiles > > all: compile > ${ERL} -s profiles start > > compile: ${MODS:%=%.beam} > > clean: > rm -rf *.beam erl_crash.dump > > subdirs: > cd src; make > > Now this works, but only with .erl and .beam files in the main > directory. > > Thanks, > > -- > Alexander Lamb > Founding Associate > RODANOTECH S?rl > > 4 ch. de la Tour de Champel > 1206 Geneva > Switzerland > > Tel: 022 347 77 37 > Fax: 022 347 77 38 > > http://www.rodanotech.ch > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions -- Armando Di Cianno http://dicianno.org/blog armando armando From rvirding Wed Mar 5 00:28:04 2008 From: rvirding (Robert Virding) Date: Wed, 5 Mar 2008 00:28:04 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <47CCC0F6.5020002@pmp.com.au> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <17244f480803021744q582d5e5ek958d82e6264ee425@mail.gmail.com> <3dbc6d1c0803031220h118f96ddr9bb4ca0f1430f756@mail.gmail.com> <47CCB1F0.1020006@lionet.info> <47CCC0F6.5020002@pmp.com.au> Message-ID: <3dbc6d1c0803041528p11bba104x25a1af8d7849802d@mail.gmail.com> On 04/03/2008, Benjamin Tolputt wrote: > > I usually stay out of the licensing flame-wars, and hoepfully this won't > result in one. I agree that BSD, MIT, or even Apache are better licenses > than GPL "for the stated purpose" (which as I understand it is simply to > prevent people taking credit for the work, though Robert can correct me > if I am wrong here). I am a great fan of the KISS principle, so in this case shorter is definitely better. You understood me correctly in this case I just want credit for my work. At the moment there's no rush anyway, if someone were to "steal" it I would just rewrite a better one. :-) Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/246ef981/attachment.html From lcastro Mon Mar 3 21:14:06 2008 From: lcastro (Laura M. Castro Souto) Date: Mon, 3 Mar 2008 21:14:06 +0100 Subject: [erlang-questions] ODBC driver performance Message-ID: <200803032114.09822.lcastro@udc.es> Hello all, I have recently updated from R10B-7 to R12B-0, and I found that, regardless of what was said in this list some time ago, http://www.erlang.org/pipermail/erlang-questions/2004-July/012792.html and even though there has been a change in the ODBC driver, there is still something missing for the ODBC driver performance not to be so bad under Linux. I think the key is just a line of code in function connect_to_erlang() in odbcserver.c. I've tried the attached patch and the performance increased sensibly for me, so in case it might be of help to someone else, here it is. Regards, -- Laura M. Castro MADS Group Computer Science Department University of A Coru?a -------------- next part -------------- A non-text attachment was scrubbed... Name: odbcserver.patch Type: text/x-diff Size: 632 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/ff905212/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080303/ff905212/attachment-0001.bin From saleyn Wed Mar 5 04:58:04 2008 From: saleyn (Serge Aleynikov) Date: Tue, 04 Mar 2008 22:58:04 -0500 Subject: [erlang-questions] Running mnesia across a firewall Message-ID: <47CE1A4C.3020707@gmail.com> While most of the times when using mnesia I had a fairly straight forward network setup, recently I ran into a need to be able to use remote mnesia's interface in presence of a firewall and would like to share my experience along with a net_kernel patch that adds a useful feature. The setup was as follows: two nodes (NodeA & NodeB) are inside the firewall and NodeC is outside the firewall. NodeA & NodeB can connect to NodeC, but all inbound access from NodeC is blocked. NodeA & NodeB are running mnesia with a few tables with disc_copies. NodeC uses mnesia's remote interface to access data tables on nodes inside the firewall. The diagram below shows network topology with corresponding Erlang's kernel options. NodeA ^ {dist_auto_connect, once} | | | INSIDE | OUTSIDE +----------|firewall------> NodeC | | {dist_auto_connect, never}, | {inet_dist_listen_min, X}, v {inet_dist_listen_max, Y}, NodeB {global_groups, [{outside, [NodeC]}]} {dist_auto_connect, once} Notes about NodeC kernel options: - {dist_auto_connect, never} prevents the node from attempting connections inside the firewall. - min/max listen options converge the firewall rules to a minimal reserved setup. - global_groups prevent global from connecting/synching with other nodes inside the firewall after a connection is made to some node inside the firewall. All three nodes subscribe to net_kernel:monitor_nodes/1, and when NodeA disconnects from NodeB (or vice versa) they enable UDP heartbeat and upon detecting that the peer node is responding, restart one of the nodes, which re-synchs mnesia. If network access between NodeA (or NodeB) and NodeC is lost, NodeC shuts down mnesia application and waits for {nodeup, NodeA} event, after which it starts up mnesia. Without using this approach (i.e. not shutting down mnesia on NodeC during network outage) upon healing the network and reconnecting NodeC to NodeA/B, mnesia would detect partitioned network condition and stop replicating data between NodeA and NodeB (which is quite odd because NodeC doesn't have any local tables and it's undesirable to have its visibility impact nodes inside the firewall). The main problem with this setup is that when NodeC looses connection to NodeA/NodeB, either one of these two nodes would need to periodically attempt to reconnect to NodeC. However, because {dist_auto_connect, once} option is used on NodeA/NodeB, net_kernel wouldn't let re-establishing connection to NodeC unless *both* NodeA and NodeB are bounced! The main culprit is the net_kernel's dist_auto_connect option that is an all or none setting that cannot vary depending on connecting attempt to a given node. The attached patch (for R12B-1) solves this issue by introducing an additional kernel option: {dist_auto_connect, {callback, M, F}} This option allows to register a callback function M:F/2 with signature: (Action, Node) -> Mode Action = connect | disconnect Node = node() Mode = once | never | true that will be called when a Node tries to connect (or looses connection). Modes once and never are documented in kernel(3), and 'true' means to continue connection action. This patch allows to define different connecting behavior for connecting a and b from connecting behavior of node a (or b) and c If others find this option as useful as I do, perhaps we can pursue the OTP team to merge this patch with the distribution. Regards, Serge. P.S. Here's a sample implementation of this custom function: nodeA&B.config: =============== [ {kernel, [ {dist_auto_connect, {callback, net_kernel_connector, dist_auto_connect}} ]}, {mnesia, [ {extra_db_nodes, [a, b]} ]} ]. nodeC.config: ============= [ {kernel, [ {dist_auto_connect, never}, {global_groups, [{outside, [c]}]}, {inet_dist_listen_min, 8111}, {inet_dist_listen_max, 8119} ]} {mnesia, [ {extra_db_nodes, [a, b]} ]} ]. -module(net_kernel_connector). -export([dist_auto_connect/2]). dist_auto_connect(Action, Node) -> case application:get_env(mnesia, extra_db_nodes) of {ok, Masters} -> IamMaster = lists:member(node(), Masters), NodeIsMaster = lists:member(Node, Masters), case {IamMaster, NodeIsMaster} of {true, true} -> once; {_, _} -> has_access(node(), Node) end; _ -> has_access(node(), Node) end. has_access(From, To) -> has_access2(host(From), host(To)). has_access2('hostC', _) -> never; has_access2(_, _) -> true. host(Node) -> L = atom_to_list(Node), [_, H] = string:tokens(L, "@"), list_to_atom(H). -------------- next part -------------- A non-text attachment was scrubbed... Name: R12-1.net_kernel.patch Type: application/octet-stream Size: 2722 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080304/fd702785/attachment-0001.obj From eranga.erl Wed Mar 5 05:46:25 2008 From: eranga.erl (Eranga Udesh) Date: Wed, 5 Mar 2008 10:16:25 +0530 Subject: [erlang-questions] Erlang message passing delay after abnormal network disconnection In-Reply-To: References: <912a3c160803030431h72ea5c5dyf488b735cb4ebb09@mail.gmail.com> <912a3c160803032315x56134cbeu505b86e60c46c86@mail.gmail.com> Message-ID: <912a3c160803042046ha8109daoeb3444e0397450a4@mail.gmail.com> Excellent, the net_tick_time environment variable works. Thanks for the advice. Still I appreciate if I can know the behavior of inet_drv based on the questions I asked in my previous email. Cheers, - Eranga On Tue, Mar 4, 2008 at 10:28 PM, Kenneth Lundin wrote: > When connectivity is broken abnormally the sending node will detect > this within 45-60 seconds as default. This can be changed with the > net_tick_time environment variable in application kernel. > Before the detection the sending node will try to send the message and > if not possible it will be queued in the inet-driver. If the queue > gets bigger than a certain max a so called "busy port" will occur > which will block the sending Erlang process. > This occurs when the receiving side of the distribution socket does > not read what is > sent to it which is the case when you have no connectivity. > > another scenario is that the receiving node is detected as down and > an auto connect (including handshake) is performed for the first > message sent after > the broken connection. This will take in the order of 10 seconds before > timeout. > > If you want to avoid this for a very crucial process (i.e avoid > blocking of that particular Erlang process) you can send the message > with erlang:send_nosuspend/2 or 3. Warning! these functions should be > used with extreme care, Read the manual! > > Note that this has nothing to do with HiPE (i.e native code). > An abnormal termination of the connectivity for example by unplugging > the network cable will have this effect. > > /Kenneth Erlang/OTP team Ericsson > > On 3/4/08, Eranga Udesh wrote: > > The problem occurs when the network connectivity is broken (abnormally). > The > > receiving node is not receiving messages. The sending processes are > > blocked, since those message delivery calls (gen_event:notify/s, etc) > are > > waiting for about 10 secs to return. We checked the implementation of > such > > calls and notice, the functions are waiting until the messages are > delivered > > to the receiving node. Is there's a way (a system flag may be) to avoid > such > > blocking and to return immediately? > > > > BRgds, > > - Eranga > > > > > > > > > > On Mon, Mar 3, 2008 at 6:51 PM, Chandru > > wrote: > > > > > > > > > > > > On 03/03/2008, Eranga Udesh wrote: > > > > Hi, > > > > > > > > I am experiencing a high message passing delay between 2 Erlang > nodes, > > after > > > > an abnormal network disconnection. Those 2 nodes are in a WAN and > there > > are > > > > multiple Hubs, Switches, Routes, etc., in between them. If the > message > > > > receiving Erlang node stopped gracefully, the delay doesn't arise. > Doing > > > > net_adm:ping/1 to that node results no delay "pang". However > > > > gen_event:notify/2, gen_server:cast/2, etc. are waiting for about 10 > > seconds > > > > to return. > > > > > > > > What's the issue and how this can be avoided? > > > > > > Have you tried putting a snoop to see whether the delay is on the > > > sending/receiving side? > > > > > > This might be useful: > > http://www.erlang.org/contrib/erlsnoop-1.0.tgz > > > > > > cheers > > > Chandru > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/9c18373b/attachment.html From jeffm Wed Mar 5 07:23:16 2008 From: jeffm (jm) Date: Wed, 05 Mar 2008 17:23:16 +1100 Subject: [erlang-questions] how: perl <-> erlang In-Reply-To: <2CEB6DA5040AED4F946351C85FAC87B501886820@DEJENSAPP01V1.vision.zeiss.org> References: <47CC8FAF.1070506@ghostgun.com> <2CEB6DA5040AED4F946351C85FAC87B501886820@DEJENSAPP01V1.vision.zeiss.org> Message-ID: <47CE3C54.9020203@ghostgun.com> Roessner, Silvester wrote: > Hi Jeff, > > I have written a generic Erlang <-> Perl interface a year ago. It uses an Erlang port in binary mode. In that way I can handle all Erlang types and map them to Perl types. But that also means that Erlang has to start Perl, not vice versa. > > It's 80 % ready. I stopped working on it as I found an error in Erlang or Perl. > > If you like, Jeff, I can send you the code as is. > > Your posting has motivated me! I'll start to finish the interface this evening - yeah. Thank's for that! > > mit freundlichen Gr??en / with kind regards The trouble with this approach is that Radiator is a third party product (http://www.open.com.au/radiator/) which is started via an init.d script. Making changes to this, while possible, would make it complicate for future maintenance and support. Radiator official supports the use of hook functions (controlled through the main config file) and custom auth modules. We're currently using both of these. The idea is that Radiator does the auth and acct, as it currently does, then sends a message to an erlang node to notify it that the user has logged on or off with the relevent details. The trick here is that as far as I can tell Radiator is a single threaded perl process. The AuthByGeneric module which is the parent object of all Auth modules supports forking for each request, but this would be only for that phase of the auth in chain of modules. There is already an AuthBy SOAP module and I could do the calls though that, but I was hoping for something a little lighter not to mention faster. A couple of people have suggested http://search.cpan.org/~hio/Erlang-Port-0.04/lib/Erlang/Port.pm this Someone else suggested I look at http://www.erlang.org/pipermail/erlang-questions/2001-April/003082.html which uses erl_call command. I thought this would be too slow may be I'm wrong. I'll have to investigate this further. The best approach may be to use the functions from Erlang/Port.pm to create a connection from Radiator for every request, send request, await reply, disconnect. Anyway, just something to keep in mind when your writting your own stuff. let me know if you finish your interface I'll give it a go. Jeff. From bengt.kleberg Wed Mar 5 08:58:29 2008 From: bengt.kleberg (Bengt Kleberg) Date: Wed, 05 Mar 2008 08:58:29 +0100 Subject: [erlang-questions] Use of makefiles In-Reply-To: <053657FB-5463-4F29-9FD1-32D83CCC3B4C@telegraphics.com.au> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <053657FB-5463-4F29-9FD1-32D83CCC3B4C@telegraphics.com.au> Message-ID: <1204703909.8234.14.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, It was not the intention of James Hague that everyone should rewrite make in perl (if it was I would appreciate if he corrected me). Firstly that is already done (Cons). Secondly when he wrote "I can bang out a Perl program that does the same thing", he meant a perl program replacing not make, but the makefile. The question I asked was if a perl program would be more likely to run on ''any'' machine, than a makefile. Not because the person who wrote the makefile forgot/failed to read the manual for gnu make, but because there are other make programs than gnu make out there. The 4 ones I have used where not compatible. They would not run each others makefiles. I have heard that there is only one perl, so it should be compatible. So, is the chance of finding perl on ''any'' computer bigger than the chance of finding the right make program for your makefile? bengt .On Tue, 2008-03-04 at 13:09 -0500, Toby Thain wrote: > On 4-Mar-08, at 11:57 AM, Bengt Kleberg wrote: > > > Greetings, > > > > Is it not also the case that perl is more standard than make? > > > Is *everyone* supposed to rewrite make in Perl every time they want > to build something? > > > I know very little of perl, but have fought at least 4 different kinds > > of make (files). > > The GNU make documentation is really very good. I don't know why > people rarely refer to it. > > --T > > > > > > > bengt > > > > On Tue, 2008-03-04 at 10:11 -0600, James Hague wrote: > >> On Sat, Mar 1, 2008 at 8:41 PM, Steve Vinoski > >> wrote: > >>> > >>> Hi Joe, I agree with you 100%. Give me emacs (with its vast > >>> emacs-lisp > >>> extensibility), bash (or ksh), and various UNIX command-line tools, > >>> which I can combine as I wish using pipes, and keep the visual > >>> tools > >>> out of my way (and out of my RAM). > >> > >> I think this discussion has been misinterpreted :) No one is arguing > >> for IDE-like features over makefiles. > >> > >> I have found that I don't need makefiles for my Erlang projects. I > >> either recompile the same module repeatedly or I want to rebuild > >> everything. The former is business as usual. The latter is easily > >> done with a shell script, Perl script, or short Erlang program. I > >> use > >> makefiles infrequently enough that I always forget the syntax and > >> nuances of using them. But I can bang out a Perl program that does > >> the same thing--even checking file modification dates and so on--in > >> very little time. It's more flexible than using a makefile, too, and > >> usually ends up being less "code." > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions > >> http://www.erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg Wed Mar 5 09:04:41 2008 From: bengt.kleberg (Bengt Kleberg) Date: Wed, 05 Mar 2008 09:04:41 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: <1204530810.24311.31.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: <1204704281.8234.21.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, Sorry about the delay, but the book has > 1000 pages and it was unfortunately a worst case search scenario. The explanation was not in the book. It was here: http://se.inf.ethz.ch/projects/alan_fehr/report.pdf And the part you want to read is "1.2.2 LACE" on page 2. It is only 6 lines, but I can not cut/paste so I hope you can read it. bengt On Mon, 2008-03-03 at 10:34 +0100, Christian S wrote: > On Mon, Mar 3, 2008 at 8:53 AM, Bengt Kleberg > wrote: > > In the book "Object Oriented Software Construction" Bertrand Meyer > > argues (successfully in my opinion) that you need to have the ability to > > rename (alias) modules. He also shows that this ability must be outside > > of the language/modules themselves. > > Providing my own aliases for other modules that I use is something I > have been wishing for. > > Not having read the book, what does he mean with the ability must be > outside of the language? From ulf.wiger Wed Mar 5 09:05:32 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Wed, 05 Mar 2008 09:05:32 +0100 Subject: [erlang-questions] [erlang-patches] Running mnesia across a firewall In-Reply-To: <47CE1A4C.3020707@gmail.com> References: <47CE1A4C.3020707@gmail.com> Message-ID: <47CE544C.7010700@ericsson.com> Serge Aleynikov skrev: > > The main culprit is the net_kernel's dist_auto_connect option that is an > all or none setting that cannot vary depending on connecting attempt to > a given node. The attached patch (for R12B-1) solves this issue by > introducing an additional kernel option: > > {dist_auto_connect, {callback, M, F}} Have you thought about solving it with an application that periodically tries calling net_kernel:connect(Node)? BR, Ulf W From mats.cronqvist Wed Mar 5 09:35:43 2008 From: mats.cronqvist (Mats Cronqvist) Date: Wed, 05 Mar 2008 09:35:43 +0100 Subject: [erlang-questions] Function to print a record with fieldnames ? In-Reply-To: <1C538D67B37E5B4784128A22270DF5C30FF78591@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C30FF78591@npri54exc20.npt.nuwc.navy.mil> Message-ID: <47CE5B5F.5030902@kreditor.se> Convey Christian J NPRI wrote: > Thanks Mats, > > That works great for me. > > Could you explain something to me please? : > > Why must this be a macro rather than a function? It seems that if I want rec_info to be a function rather than a macro, record_info's second parameter must be a hard-coded atom; it cannot be a variable. But nothing I've read in Armstrong's book led me to think that such a restriction was possible in Erlang. > because record_info, weirdly enough, is a (built-in) macro. to expand (haha) a bit, the compiler will automatically generate 2 functions, module_info/{0,1}, and expand some macros (?LINE, ?MODULE, record_info, perhaps others?) on the plus side, afaik record_info is the only such cleverly disguised macro. mats > Thanks, > Christian > > >> -----Original Message----- >> From: Mats Cronqvist [mailto:mats.cronqvist] >> Sent: Tuesday, March 04, 2008 9:53 AM >> To: Convey Christian J NPRI >> Cc: erlang-questions >> Subject: Re: [erlang-questions] Function to print a record >> with fieldnames? >> >> Convey Christian J NPRI wrote: >> >>> I've got a record definition along the lines of: >>> >> -record(myrec, {foo = undefined, bar=undefined}). >> >>> To help with debugging, I'd like a function that will print >>> >> out something like the following text: >> >>> #record{foo = 42, bar = the_answer_to_the_question} >>> >>> Does such a function exist, or must I write my own version >>> >> of the function for each record type? I know I can just use >> io:format("~p~n", [ MyRecord ]), but I'd really like the >> fieldnames to also be printed. >> >>> >>> >> best i've seen is variations on this theme; >> >> -module('foo'). >> -author('Mats Cronqvist'). >> -export([go/0]). >> >> -define(rec_info(T,R),lists:zip(record_info(fields,T),tl(tuple >> _to_list(R)))). >> -record(r,{bla,foo,baz,bar}). >> >> go() -> ?rec_info(r,#r{}). >> >> >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/4868e476/attachment-0001.vcf From anthony.hw.kong Wed Mar 5 10:24:59 2008 From: anthony.hw.kong (Anthony Kong) Date: Wed, 5 Mar 2008 20:24:59 +1100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <77016.67694.qm@web38812.mail.mud.yahoo.com> References: <77016.67694.qm@web38812.mail.mud.yahoo.com> Message-ID: Is it already implemented? Because I found this document: http://www.erlang.se/publications/packages.html Anyway, I was unable to get it to work according to this info. Cheers, Anthony On Sun, Mar 2, 2008 at 12:38 AM, Thomas Lindgren wrote: > > --- shiwei xu wrote: > > > I think flat module namespaces is a defect of erlang > > design. > > Richard Carlsson proposed java-like packages some > years ago, and the code for them might still be > provided in OTP. (I thought they had some flaws, but > they might be what you want.) > > http://citeseer.ist.psu.edu/398052.html > > The usual approach to handling name clashes without > packages is to use your 'approach 2', prefixing the > modules with their owner application. > > Best, > Thomas > > > > > ____________________________________________________________________________________ > Be a better friend, newshound, and > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- /*--*/ Don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit. - Linus Torvalds From anthony.hw.kong Wed Mar 5 10:47:16 2008 From: anthony.hw.kong (Anthony Kong) Date: Wed, 5 Mar 2008 20:47:16 +1100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <1204704281.8234.21.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <1204530810.24311.31.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <1204704281.8234.21.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: I think it is the 'six-liner' you are referring to: "1.2.2 LACE One of the ideas behind Eiffel is to maximize reusability. For this reason, the language doesn't provide a mechanism for assembling a system. Some external mechanism is therefore needed to specify the entry-point for a program. One of these mechanisms is a language called LACE (Language for Assembling Classes in Eiffel). Since the Eiffel knows nothing of assembling classes into systems it doesn't provide a mechanism for resolving name-clashes." In a sense, it sounds like java classloader to me. Cheers, Anthony On Wed, Mar 5, 2008 at 7:04 PM, Bengt Kleberg wrote: > Greetings, > > Sorry about the delay, but the book has > 1000 pages and it was > unfortunately a worst case search scenario. The explanation was not in > the book. > > It was here: > http://se.inf.ethz.ch/projects/alan_fehr/report.pdf > > And the part you want to read is "1.2.2 LACE" on page 2. It is only 6 > lines, but I can not cut/paste so I hope you can read it. > > > bengt > > > > On Mon, 2008-03-03 at 10:34 +0100, Christian S wrote: > > On Mon, Mar 3, 2008 at 8:53 AM, Bengt Kleberg > > wrote: > > > In the book "Object Oriented Software Construction" Bertrand Meyer > > > argues (successfully in my opinion) that you need to have the ability to > > > rename (alias) modules. He also shows that this ability must be outside > > > of the language/modules themselves. > > > > Providing my own aliases for other modules that I use is something I > > have been wishing for. > > > > Not having read the book, what does he mean with the ability must be > > outside of the language? > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- /*--*/ Don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit. - Linus Torvalds From richardc Wed Mar 5 11:02:13 2008 From: richardc (Richard Carlsson) Date: Wed, 05 Mar 2008 11:02:13 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: <77016.67694.qm@web38812.mail.mud.yahoo.com> Message-ID: <47CE6FA5.7060808@it.uu.se> It was implemented a long time ago, but there was not a lot of community enthusiasm for it, so it's not been made an official part of the language yet. Still, it should work also in R12. http://www.erlang.org/doc/man/packages.html It was originally inspired by/ripped off from Java, but in practice it's more similar to Lisp namespaces; see "The Complete Idiot?s Guide to Common Lisp Packages" for details: http://www.flownet.com/ron/packages.pdf /Richard Anthony Kong wrote: > Is it already implemented? Because I found this document: > > http://www.erlang.se/publications/packages.html > > Anyway, I was unable to get it to work according to this info. > > Cheers, Anthony > > On Sun, Mar 2, 2008 at 12:38 AM, Thomas Lindgren > wrote: >> --- shiwei xu wrote: >> >> > I think flat module namespaces is a defect of erlang >> > design. >> >> Richard Carlsson proposed java-like packages some >> years ago, and the code for them might still be >> provided in OTP. (I thought they had some flaws, but >> they might be what you want.) >> >> http://citeseer.ist.psu.edu/398052.html >> >> The usual approach to handling name clashes without >> packages is to use your 'approach 2', prefixing the >> modules with their owner application. >> >> Best, >> Thomas From anthony.hw.kong Wed Mar 5 11:03:35 2008 From: anthony.hw.kong (Anthony Kong) Date: Wed, 5 Mar 2008 21:03:35 +1100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: <77016.67694.qm@web38812.mail.mud.yahoo.com> Message-ID: Sorry for the false alarm. It (http://www.erlang.se/publications/packages.html) actually works. Let's say I have this module is "a.b.c.d", defined in d.erl which lives in directory, a/b/c, What I need to make sure is that: when I use erlc to compile this d.erl, I have to specify the -o flag in order to produce the d.beam in the directory a/b/c. Attached is my simple test setup script, which probably can explain the above better. Cheers, Anthony On Wed, Mar 5, 2008 at 8:24 PM, Anthony Kong wrote: > Is it already implemented? Because I found this document: > > http://www.erlang.se/publications/packages.html > > Anyway, I was unable to get it to work according to this info. > > Cheers, Anthony > > > > On Sun, Mar 2, 2008 at 12:38 AM, Thomas Lindgren > wrote: > > > > --- shiwei xu wrote: > > > > > I think flat module namespaces is a defect of erlang > > > design. > > > > Richard Carlsson proposed java-like packages some > > years ago, and the code for them might still be > > provided in OTP. (I thought they had some flaws, but > > they might be what you want.) > > > > http://citeseer.ist.psu.edu/398052.html > > > > The usual approach to handling name clashes without > > packages is to use your 'approach 2', prefixing the > > modules with their owner application. > > > > Best, > > Thomas > > > > > > > > > > ____________________________________________________________________________________ > > Be a better friend, newshound, and > > know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > > > > > -- > /*--*/ > Don't EVER make the mistake that you can design something better than > what you get from ruthless massively parallel trial-and-error with a > feedback cycle. That's giving your intelligence _much_ too much > credit. > > - Linus Torvalds > -- /*--*/ Don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit. - Linus Torvalds -------------- next part -------------- A non-text attachment was scrubbed... Name: build.pl Type: application/octet-stream Size: 375 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/4e477d09/attachment.obj From anthony.hw.kong Wed Mar 5 11:11:09 2008 From: anthony.hw.kong (Anthony Kong) Date: Wed, 5 Mar 2008 21:11:09 +1100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <47CE6FA5.7060808@it.uu.se> References: <77016.67694.qm@web38812.mail.mud.yahoo.com> <47CE6FA5.7060808@it.uu.se> Message-ID: Thanks, Richard, Sorry again for the false alarm. I think this "a.b.c.d" notation is a good idea. For once it allows us to structure the source code tree better. The catch are the erlc flag (which I just realised) and mandatory explicit import of other top level modules such as io and lists. Cheers, Anthony On Wed, Mar 5, 2008 at 9:02 PM, Richard Carlsson wrote: > It was implemented a long time ago, but there was not a lot of > community enthusiasm for it, so it's not been made an official > part of the language yet. Still, it should work also in R12. > > http://www.erlang.org/doc/man/packages.html > > It was originally inspired by/ripped off from Java, but in > practice it's more similar to Lisp namespaces; see "The Complete > Idiot's Guide to Common Lisp Packages" for details: > http://www.flownet.com/ron/packages.pdf > > /Richard > > > > Anthony Kong wrote: > > Is it already implemented? Because I found this document: > > > > http://www.erlang.se/publications/packages.html > > > > Anyway, I was unable to get it to work according to this info. > > > > Cheers, Anthony > > > > On Sun, Mar 2, 2008 at 12:38 AM, Thomas Lindgren > > wrote: > >> --- shiwei xu wrote: > >> > >> > I think flat module namespaces is a defect of erlang > >> > design. > >> > >> Richard Carlsson proposed java-like packages some > >> years ago, and the code for them might still be > >> provided in OTP. (I thought they had some flaws, but > >> they might be what you want.) > >> > >> http://citeseer.ist.psu.edu/398052.html > >> > >> The usual approach to handling name clashes without > >> packages is to use your 'approach 2', prefixing the > >> modules with their owner application. > >> > >> Best, > >> Thomas > > > -- /*--*/ Don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit. - Linus Torvalds From anthony.hw.kong Wed Mar 5 11:23:29 2008 From: anthony.hw.kong (Anthony Kong) Date: Wed, 5 Mar 2008 21:23:29 +1100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: Message-ID: Hi, Shiwei, I'd concur that a capability to alias an imported module sounds like an attractive idea. I personally would prefer a new directive called "import_as". ====== -module(lists). %% I want to call my module lists too. -import_as(lists, stdlib_lists). ... lists:copycat() -> stdlib_lists:reverse([a,b,c]). %% essentially calling lists:reverse([a,b,c]) ====== Just the same as your idea of "-alias". Until then, I probably have to learn to live in this namespace flatland :-) Cheers, Anthony 2008/3/1 shiwei xu : > I think flat module namespaces is a defect of erlang design. > > For example, I write a foo.erl, It works well. But maybe in a late erlang > version (eg. R13B) also write such module named foo.erl. Then, you can > see my application goes wrong. > > How to avoid things like this? Let's see the following ways: > > 1. Adjust module searching paths, and let user path (which contains my > foo.erl) take precedence over erlang stdlib/otp path. But, this way can't > always work well. If some other stdlib/otp modules use system foo.erl (not > my foo.erl), Things goes wrong. > > 2. Write erlang modules always named with a prefix (a fake namespace. For > example, projectname_foo.erl or organization_projectname_foo > .erl). This way really can solve the problem. But, It seems ugly. > > Is there a way let's user still can call foo:func (not call foo.erl provied > by stdlib/otp, but my projectname_foo.erl)? I have a suggestion: > > Can erlang provide a 'module name alias'? That is, I can rename a module's > name temporarily in a module? For example: > > -module(a_module_that_call_my_foo). > -alias(foo, organization_projectname_foo). %% alias > > some_func_call_foo() -> > foo:func(). %% same as: organization_projectname_foo:func() > > Currently I can do this by using the 'define' keyword. For example: > > -module(a_module_that_call_my_foo). > -define(FOO, organization_projectname_foo). %% alias > > some_func_call_foo() -> > ?FOO:func(). > > It works well, but a bit ugly. > > > > On Sat, Mar 1, 2008 at 6:51 AM, Matt Stancliff wrote: > > > > > > > > > > > > > On Feb 29, 2008, at 14:34, Anthony Kong wrote: > > > > > If I rename c.erl to something else, the problem goes away. > > > > > > What is special about "-module(c)" ? > > > > Welcome to the world of flat module namespaces. > > > > The code module is your friend in these circumstances. > > Look into code:clash() and code:which(module). > > > > code:which(c) should return "/lib/erlang/lib/stdlib- > > /ebin/c.beam" > > > > > > -Matt > > -- > > Matt Stancliff sysop > > AIM: seijimr iPhone: 678-591-9337 > > "The best way to predict the future is to invent it." --Alan Kay > > > > > > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- /*--*/ Don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit. - Linus Torvalds From richardc Wed Mar 5 12:29:01 2008 From: richardc (Richard Carlsson) Date: Wed, 05 Mar 2008 12:29:01 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: Message-ID: <47CE83FD.8020603@it.uu.se> Anthony Kong wrote: > I personally would prefer a new directive called "import_as". > > ====== > -module(lists). %% I want to call my module lists too. > -import_as(lists, stdlib_lists). > > ... > lists:copycat() -> > stdlib_lists:reverse([a,b,c]). %% essentially calling lists:reverse([a,b,c]) I planned to implement exactly this, but never got around to it. I'll fix it if I can find some spare time. /Richard From saleyn Wed Mar 5 13:09:21 2008 From: saleyn (Serge Aleynikov) Date: Wed, 05 Mar 2008 07:09:21 -0500 Subject: [erlang-questions] [erlang-patches] Running mnesia across a firewall In-Reply-To: <47CE544C.7010700@ericsson.com> References: <47CE1A4C.3020707@gmail.com> <47CE544C.7010700@ericsson.com> Message-ID: <47CE8D71.3090704@gmail.com> Ulf Wiger (TN/EAB) wrote: > Serge Aleynikov skrev: >> >> The main culprit is the net_kernel's dist_auto_connect option that is >> an all or none setting that cannot vary depending on connecting >> attempt to a given node. The attached patch (for R12B-1) solves this >> issue by introducing an additional kernel option: >> >> {dist_auto_connect, {callback, M, F}} > > Have you thought about solving it with an application that > periodically tries calling net_kernel:connect(Node)? On which node, though? If this is one of the "master" nodes A holding a disk copy of a table X, then the node must have {dist_auto_connect, once} set. If the firewall prohibits inbound access to this node A from some other node C that uses remote mnesia interface to access table X, then the only way to establish connection to node C is to do on node A net_kernel:connect(C). However if that connection drops, there's no way to reestablish that connection without restarting node A. Remember that in case of {dist_auto_connect, once} net_kernel checks if a connection is barred and if it is it won't allow to connect to a node that previously was connected. Serge From valentin Tue Mar 4 06:34:10 2008 From: valentin (Valentin Micic) Date: Tue, 4 Mar 2008 07:34:10 +0200 Subject: [erlang-questions] Patch downloads & delayed messages Message-ID: <002301c87db9$68e8fb20$6401a8c0@moneymaker2> Dear all, Is there a single place containing all the patches for a particular relase (available for download, of course)? Also, for some reason my messages are deleyed -- sometimes for more than two days. Anybody else with a similar experience? V. From ulf.wiger Wed Mar 5 13:26:16 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Wed, 05 Mar 2008 13:26:16 +0100 Subject: [erlang-questions] [erlang-patches] Running mnesia across a firewall In-Reply-To: <47CE8D71.3090704@gmail.com> References: <47CE1A4C.3020707@gmail.com> <47CE544C.7010700@ericsson.com> <47CE8D71.3090704@gmail.com> Message-ID: <47CE9168.5090504@ericsson.com> Serge Aleynikov skrev: > Ulf Wiger (TN/EAB) wrote: >> Serge Aleynikov skrev: >>> >>> The main culprit is the net_kernel's dist_auto_connect option that is >>> an all or none setting that cannot vary depending on connecting >>> attempt to a given node. The attached patch (for R12B-1) solves this >>> issue by introducing an additional kernel option: >>> >>> {dist_auto_connect, {callback, M, F}} >> >> Have you thought about solving it with an application that >> periodically tries calling net_kernel:connect(Node)? > > On which node, though? If this is one of the "master" nodes A holding a > disk copy of a table X, then the node must have {dist_auto_connect, > once} set. If the firewall prohibits inbound access to this node A from > some other node C that uses remote mnesia interface to access table X, > then the only way to establish connection to node C is to do on node A > net_kernel:connect(C). However if that connection drops, there's no way > to reestablish that connection without restarting node A. Remember that > in case of {dist_auto_connect, once} net_kernel checks if a connection > is barred and if it is it won't allow to connect to a node that > previously was connected. Correction 1: It's net_kernel:connect_node(Node). My bad. Correction 2: net_kernel:connect_node/1 ignores the value of dist_auto_connect What we've done is to keep a "maintenance channel" (not distr Erlang), over which we can negotiate which node should restart. BR, Ulf W From saleyn Wed Mar 5 13:51:07 2008 From: saleyn (Serge Aleynikov) Date: Wed, 05 Mar 2008 07:51:07 -0500 Subject: [erlang-questions] [erlang-patches] Running mnesia across a firewall In-Reply-To: <47CE9168.5090504@ericsson.com> References: <47CE1A4C.3020707@gmail.com> <47CE544C.7010700@ericsson.com> <47CE8D71.3090704@gmail.com> <47CE9168.5090504@ericsson.com> Message-ID: <47CE973B.50402@gmail.com> Ulf Wiger (TN/EAB) wrote: > Serge Aleynikov skrev: > Correction 1: It's net_kernel:connect_node(Node). My bad. > > Correction 2: net_kernel:connect_node/1 ignores the value of > dist_auto_connect > > What we've done is to keep a "maintenance channel" (not distr Erlang), > over which we can negotiate which node should restart. I believe that this is what I was using as the net_kernel:connect/1 was not documented, but I'll try this again some time today. Thanks. Serge From chsu79 Wed Mar 5 14:01:19 2008 From: chsu79 (Christian S) Date: Wed, 5 Mar 2008 14:01:19 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <47CE83FD.8020603@it.uu.se> References: <47CE83FD.8020603@it.uu.se> Message-ID: On Wed, Mar 5, 2008 at 12:29 PM, Richard Carlsson wrote: > I planned to implement exactly this, but never got around to it. > I'll fix it if I can find some spare time. A problem with aliases is that the expectation is that an atom will identify the same module even when it crosses boundaries into code from other modules. Scenario: I define a behaviour for creating/looking up cookie sessions in a webserver. (With the intention that one could back end it in files, mnesia or a sql rdbm.) I tell the webserver to use the module stupidly identified by the name 'session' that implements this behaviour. The webserver has a -import_as/-alias where 'session' is an alias for a module that is not the same as my module. ...problems! Or at least confusion. As I see it, there needs to be a first-class module-type to get around it. A resolved module. Something that is not an atom. "Module = module(session)" the same way there is "Fun = fun M:F/A" (rather than the old {M,F} wart). The value of module(Atom) would globally identify the module locally known by the name in Atom. Or is there some more clever way to get around the problems in module-local aliases? PS. I think this name-space-discussion has occurred two-three times the years I have been following the list. From thomasl_erlang Wed Mar 5 13:22:43 2008 From: thomasl_erlang (Thomas Lindgren) Date: Wed, 5 Mar 2008 04:22:43 -0800 (PST) Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: Message-ID: <761101.63041.qm@web38801.mail.mud.yahoo.com> --- Anthony Kong wrote: > Is it already implemented? Because I found this > document: > > http://www.erlang.se/publications/packages.html > > Anyway, I was unable to get it to work according to > this info. Sorry, I haven't tracked how this has evolved. Maybe Richard knows more? Best, Thomas ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From bengt.kleberg Wed Mar 5 14:31:11 2008 From: bengt.kleberg (Bengt Kleberg) Date: Wed, 05 Mar 2008 14:31:11 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: Message-ID: <1204723871.8234.34.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, How does the erlang run time handle 2 modules called lists? Which lists module will those other modules that have not done -import_as(lists, stdlib_lists). get? bengt On Wed, 2008-03-05 at 21:23 +1100, Anthony Kong wrote: > Hi, Shiwei, > > I'd concur that a capability to alias an imported module sounds like > an attractive idea. > > I personally would prefer a new directive called "import_as". > > ====== > -module(lists). %% I want to call my module lists too. > -import_as(lists, stdlib_lists). > > ... > lists:copycat() -> > stdlib_lists:reverse([a,b,c]). %% essentially calling lists:reverse([a,b,c]) > > ====== > > Just the same as your idea of "-alias". > > Until then, I probably have to learn to live in this namespace flatland :-) > > Cheers, Anthony > > > > 2008/3/1 shiwei xu : > > I think flat module namespaces is a defect of erlang design. > > > > For example, I write a foo.erl, It works well. But maybe in a late erlang > > version (eg. R13B) also write such module named foo.erl. Then, you can > > see my application goes wrong. > > > > How to avoid things like this? Let's see the following ways: > > > > 1. Adjust module searching paths, and let user path (which contains my > > foo.erl) take precedence over erlang stdlib/otp path. But, this way can't > > always work well. If some other stdlib/otp modules use system foo.erl (not > > my foo.erl), Things goes wrong. > > > > 2. Write erlang modules always named with a prefix (a fake namespace. For > > example, projectname_foo.erl or organization_projectname_foo > > .erl). This way really can solve the problem. But, It seems ugly. > > > > Is there a way let's user still can call foo:func (not call foo.erl provied > > by stdlib/otp, but my projectname_foo.erl)? I have a suggestion: > > > > Can erlang provide a 'module name alias'? That is, I can rename a module's > > name temporarily in a module? For example: > > > > -module(a_module_that_call_my_foo). > > -alias(foo, organization_projectname_foo). %% alias > > > > some_func_call_foo() -> > > foo:func(). %% same as: organization_projectname_foo:func() > > > > Currently I can do this by using the 'define' keyword. For example: > > > > -module(a_module_that_call_my_foo). > > -define(FOO, organization_projectname_foo). %% alias > > > > some_func_call_foo() -> > > ?FOO:func(). > > > > It works well, but a bit ugly. > > > > > > > > On Sat, Mar 1, 2008 at 6:51 AM, Matt Stancliff wrote: > > > > > > > > > > > > > > > > > > > > On Feb 29, 2008, at 14:34, Anthony Kong wrote: > > > > > > > If I rename c.erl to something else, the problem goes away. > > > > > > > > What is special about "-module(c)" ? > > > > > > Welcome to the world of flat module namespaces. > > > > > > The code module is your friend in these circumstances. > > > Look into code:clash() and code:which(module). > > > > > > code:which(c) should return "/lib/erlang/lib/stdlib- > > > /ebin/c.beam" > > > > > > > > > -Matt > > > -- > > > Matt Stancliff sysop > > > AIM: seijimr iPhone: 678-591-9337 > > > "The best way to predict the future is to invent it." --Alan Kay > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions > > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > > From richardc Wed Mar 5 15:06:57 2008 From: richardc (Richard Carlsson) Date: Wed, 05 Mar 2008 15:06:57 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: References: <47CE83FD.8020603@it.uu.se> Message-ID: <47CEA901.2080507@it.uu.se> The compiler expands all module references to their fully qualified forms, so at runtime, there is no aliasing problem. The one thing programmers have to think about, is that if you pass "just some atom" as an argument to some function, the compiler will not expand that atom, so if you are giving the name of a module (e.g., as a callback), you need to make sure to use the fully qualified form. So yes, there is an assymetry: module names used in explicit calls are expanded, but "plain atoms" are not. On the positive side: it's a rather simple approach that works pretty well and is fully compatible with existing code without adding new datatypes to the language. But since parameterized modules (which came later) require adding a first-class module data type (currently implemented as tuples), all the code which currently assumes (and checks) that module callbacks are atoms would need to be rewritten in any case, so encoding the namespace structure in the (full) module names is not the only way. But personally, I think I actually like the package system as it is. It is straightforward and works, and does not add *too* much cruft to the language. I know that some people consider it "inside out", but i think it's an advantage to have each module clearly state its full name. That provides stability and enables you to build a vocabulary of modules you know, and you don't have to look in another file to find out what the name used to access the module in the current file is supposed to be. Sure, you can define a whole sub-language for specifying how modules are composed out of other modules and how this module in that file over there is actually called Brian who is known as Brian, but there is a thing such as too much flexibility getting in the way of getting things done. On the other hand, I loathe long module names such as 'megaco_per_bin_media_gateway_control_v2' (or nasty surprises for newbies, such as 'c') , so some namespace control is definitely needed. /Richard Christian S wrote: > On Wed, Mar 5, 2008 at 12:29 PM, Richard Carlsson wrote: >> I planned to implement exactly this, but never got around to it. >> I'll fix it if I can find some spare time. > > A problem with aliases is that the expectation is that an atom will > identify the same module even when it crosses boundaries into code > from other modules. > > > Scenario: > > I define a behaviour for creating/looking up cookie sessions in a > webserver. (With the intention that one could back end it in files, > mnesia or a sql rdbm.) > > I tell the webserver to use the module stupidly identified by the name > 'session' that implements this behaviour. > > The webserver has a -import_as/-alias where 'session' is an alias for > a module that is not the same as my module. > > ...problems! Or at least confusion. > > > > > As I see it, there needs to be a first-class module-type to get around > it. A resolved module. Something that is not an atom. > > "Module = module(session)" the same way there is "Fun = fun M:F/A" > (rather than the old {M,F} wart). > > The value of module(Atom) would globally identify the module locally > known by the name in Atom. > > > > Or is there some more clever way to get around the problems in > module-local aliases? > > > PS. > I think this name-space-discussion has occurred two-three times the > years I have been following the list. From ConveyCJ Wed Mar 5 15:16:26 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Wed, 05 Mar 2008 09:16:26 -0500 Subject: [erlang-questions] LOC tool for Erlang Message-ID: <1C538D67B37E5B4784128A22270DF5C30FFE2A24@npri54exc20.npt.nuwc.navy.mil> Does anyone know of an open source tool (hopefully without output in English) that counts lines of Erlang code? Thanks, Christian Christian Convey Scientist, Naval Undersea Warfare Centers Newport, RI From richardc Wed Mar 5 15:21:23 2008 From: richardc (Richard Carlsson) Date: Wed, 05 Mar 2008 15:21:23 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <1204723871.8234.34.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <1204723871.8234.34.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: <47CEAC63.7090507@it.uu.se> Just to hammer down the point: the runtime system never sees two different modules called lists. The import_as would cause the names to be substituted at compile time. Atoms that are not necessarily module names by context would either have to be written fully qualified from start, or be wrapped in some construct that marks them for expansion, such as: -import_as(foo, my_foo) ... f() -> gen_server:start(i_am_a_module_name(foo), ...) (It would actually be a very good thing if all atoms that in fact are used to name modules, would be marked up as such, in one way or another. Dialyzer and other analyses would be much helped by this. Currently, Erlang programs are way too liberally sprinkled with random atoms which turn out to be a module name.) The basic point is: you never pass an atom that represents a module name to anyone else unless it is already fully qualified. /Richard Bengt Kleberg wrote: > Greetings, > > How does the erlang run time handle 2 modules called lists? > > Which lists module will those other modules that have not done > -import_as(lists, stdlib_lists). > get? > > > bengt > > On Wed, 2008-03-05 at 21:23 +1100, Anthony Kong wrote: >> Hi, Shiwei, >> >> I'd concur that a capability to alias an imported module sounds like >> an attractive idea. >> >> I personally would prefer a new directive called "import_as". >> >> ====== >> -module(lists). %% I want to call my module lists too. >> -import_as(lists, stdlib_lists). >> >> ... >> lists:copycat() -> >> stdlib_lists:reverse([a,b,c]). %% essentially calling lists:reverse([a,b,c]) >> >> ====== >> >> Just the same as your idea of "-alias". >> >> Until then, I probably have to learn to live in this namespace flatland :-) >> >> Cheers, Anthony >> >> >> >> 2008/3/1 shiwei xu : >>> I think flat module namespaces is a defect of erlang design. >>> >>> For example, I write a foo.erl, It works well. But maybe in a late erlang >>> version (eg. R13B) also write such module named foo.erl. Then, you can >>> see my application goes wrong. >>> >>> How to avoid things like this? Let's see the following ways: >>> >>> 1. Adjust module searching paths, and let user path (which contains my >>> foo.erl) take precedence over erlang stdlib/otp path. But, this way can't >>> always work well. If some other stdlib/otp modules use system foo.erl (not >>> my foo.erl), Things goes wrong. >>> >>> 2. Write erlang modules always named with a prefix (a fake namespace. For >>> example, projectname_foo.erl or organization_projectname_foo >>> .erl). This way really can solve the problem. But, It seems ugly. >>> >>> Is there a way let's user still can call foo:func (not call foo.erl provied >>> by stdlib/otp, but my projectname_foo.erl)? I have a suggestion: >>> >>> Can erlang provide a 'module name alias'? That is, I can rename a module's >>> name temporarily in a module? For example: >>> >>> -module(a_module_that_call_my_foo). >>> -alias(foo, organization_projectname_foo). %% alias >>> >>> some_func_call_foo() -> >>> foo:func(). %% same as: organization_projectname_foo:func() >>> >>> Currently I can do this by using the 'define' keyword. For example: >>> >>> -module(a_module_that_call_my_foo). >>> -define(FOO, organization_projectname_foo). %% alias >>> >>> some_func_call_foo() -> >>> ?FOO:func(). >>> >>> It works well, but a bit ugly. >>> >>> >>> >>> On Sat, Mar 1, 2008 at 6:51 AM, Matt Stancliff wrote: >>> >>>> >>>> >>>> >>>> >>>> On Feb 29, 2008, at 14:34, Anthony Kong wrote: >>>> >>>>> If I rename c.erl to something else, the problem goes away. >>>>> >>>>> What is special about "-module(c)" ? >>>> Welcome to the world of flat module namespaces. >>>> >>>> The code module is your friend in these circumstances. >>>> Look into code:clash() and code:which(module). >>>> >>>> code:which(c) should return "/lib/erlang/lib/stdlib- >>>> /ebin/c.beam" >>>> >>>> >>>> -Matt >>>> -- >>>> Matt Stancliff sysop >>>> AIM: seijimr iPhone: 678-591-9337 >>>> "The best way to predict the future is to invent it." --Alan Kay >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions >>>> http://www.erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions >>> http://www.erlang.org/mailman/listinfo/erlang-questions >>> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From jay Wed Mar 5 04:51:51 2008 From: jay (Jay Nelson) Date: Tue, 4 Mar 2008 19:51:51 -0800 Subject: [erlang-questions] [eeps] EEP 9 Message-ID: Taking a quick look at the erlang implementation, I noticed the following: 1) The strip_left and strip_right functions are internal, so it would be better to put the when is_integer(Sc) clause up a level to check it only once (and crash on the caller's function rather than an internal one) and maybe add an is_binary clause for the target to be stripped. 2) strip_left and strip_right should be optimized to use skip indexes into the binary rather than creating new binaries on each iteration: <<_SkipLeft:SkipSize, Sc, _Rest/binary>> = Bin then recurse with SkipSize + 1 3) The <<>> clause in strip_left is unnecessary, the pattern match for the first character will fail and you can just return the whole binary without knowing if it is empty. A similar fix is probably needed for strip_right. You should see a speed improvement with long prefix to strip on either end. 4) duplicate/2 should be a BIF, I would expect it to be used for very large binary blocks and you wouldn't want the memory to thrash on such a simple instruction. 5) If to_upper and to_lower is really wanted, a BIF will give a much faster result. Take a look at my article on binary BIFs presented at the 2005 ICFP conference for other ideas to improve performance of the library. http://www.duomark.com/erlang/index.html has a link to both the article in PDF and the code that obtained the performance numbers quoted in the article. jay From harveyd Wed Mar 5 15:25:47 2008 From: harveyd (Dale Harvey) Date: Wed, 5 Mar 2008 14:25:47 +0000 Subject: [erlang-questions] LOC tool for Erlang In-Reply-To: <1C538D67B37E5B4784128A22270DF5C30FFE2A24@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C30FFE2A24@npri54exc20.npt.nuwc.navy.mil> Message-ID: http://petdance.com/ack/ On 05/03/2008, Convey Christian J NPRI wrote: > > Does anyone know of an open source tool (hopefully without output in > English) that counts lines of Erlang code? > > Thanks, > Christian > > Christian Convey > Scientist, Naval Undersea Warfare Centers > Newport, RI > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/e0d7e909/attachment.html From ConveyCJ Wed Mar 5 15:33:12 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Wed, 05 Mar 2008 09:33:12 -0500 Subject: [erlang-questions] LOC tool for Erlang Message-ID: <1C538D67B37E5B4784128A22270DF5C30FFE2AFA@npri54exc20.npt.nuwc.navy.mil> > Does anyone know of an open source tool (hopefully without > output in English) that counts lines of Erlang code? I'd probably make fewer typos if I started drinking while I program. I meant to say, "(hopefully *with* output in English)". - Christian From ulf.wiger Wed Mar 5 15:36:03 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Wed, 05 Mar 2008 15:36:03 +0100 Subject: [erlang-questions] LOC tool for Erlang In-Reply-To: <1C538D67B37E5B4784128A22270DF5C30FFE2A24@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C30FFE2A24@npri54exc20.npt.nuwc.navy.mil> Message-ID: <47CEAFD3.3090704@ericsson.com> Convey Christian J NPRI skrev: > Does anyone know of an open source tool (hopefully without output in English) that counts lines of Erlang code? > > Thanks, > Christian I have an old module (in need of cleanup) that counts lines of code for Erlang, C and Java code, reporting lines of code excluding comments+whitespace, lines of comments and longest line. It also gives summaries per "block" (roughly, application) in a text format suitable for Excel. I've attached the source code. It uses a module called sysFs.erl, which should correlate to filesystem.erl (http://www.erlang.org/user.html#filesystem-1.0), but could, with minor rewrites, be replaced by filelib.erl in stdlib. As you can tell, it was written long ago. It's been one of those things that you just use, and keep patching if it ever breaks. It's been useful, though. BR, Ulf W -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lcount.erl Url: http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/4174c9eb/attachment-0001.ksh From luna Wed Mar 5 15:47:05 2008 From: luna (Daniel Luna) Date: Wed, 5 Mar 2008 15:47:05 +0100 (CET) Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <1204723871.8234.34.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <1204723871.8234.34.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: On Wed, 5 Mar 2008, Bengt Kleberg wrote: > Greetings, > > How does the erlang run time handle 2 modules called lists? > > Which lists module will those other modules that have not done > -import_as(lists, stdlib_lists). > get? Even more interesting: What will happen if you have two (or three...) modules all doing the below magic? What module will you really call when you do lists:reverse/1? (Or even worse; what module will you call when you do Mod:reverse(List) inside one of these modules? (Mod was an argument coming from outside the module)) Etc... /Luna > bengt > > On Wed, 2008-03-05 at 21:23 +1100, Anthony Kong wrote: >> Hi, Shiwei, >> >> I'd concur that a capability to alias an imported module sounds like >> an attractive idea. >> >> I personally would prefer a new directive called "import_as". >> >> ====== >> -module(lists). %% I want to call my module lists too. >> -import_as(lists, stdlib_lists). >> >> ... >> lists:copycat() -> >> stdlib_lists:reverse([a,b,c]). %% essentially calling lists:reverse([a,b,c]) >> >> ====== >> >> Just the same as your idea of "-alias". >> >> Until then, I probably have to learn to live in this namespace flatland :-) >> >> Cheers, Anthony >> >> >> >> 2008/3/1 shiwei xu : >>> I think flat module namespaces is a defect of erlang design. >>> >>> For example, I write a foo.erl, It works well. But maybe in a late erlang >>> version (eg. R13B) also write such module named foo.erl. Then, you can >>> see my application goes wrong. >>> >>> How to avoid things like this? Let's see the following ways: >>> >>> 1. Adjust module searching paths, and let user path (which contains my >>> foo.erl) take precedence over erlang stdlib/otp path. But, this way can't >>> always work well. If some other stdlib/otp modules use system foo.erl (not >>> my foo.erl), Things goes wrong. >>> >>> 2. Write erlang modules always named with a prefix (a fake namespace. For >>> example, projectname_foo.erl or organization_projectname_foo >>> .erl). This way really can solve the problem. But, It seems ugly. >>> >>> Is there a way let's user still can call foo:func (not call foo.erl provied >>> by stdlib/otp, but my projectname_foo.erl)? I have a suggestion: >>> >>> Can erlang provide a 'module name alias'? That is, I can rename a module's >>> name temporarily in a module? For example: >>> >>> -module(a_module_that_call_my_foo). >>> -alias(foo, organization_projectname_foo). %% alias >>> >>> some_func_call_foo() -> >>> foo:func(). %% same as: organization_projectname_foo:func() >>> >>> Currently I can do this by using the 'define' keyword. For example: >>> >>> -module(a_module_that_call_my_foo). >>> -define(FOO, organization_projectname_foo). %% alias >>> >>> some_func_call_foo() -> >>> ?FOO:func(). >>> >>> It works well, but a bit ugly. >>> >>> >>> >>> On Sat, Mar 1, 2008 at 6:51 AM, Matt Stancliff wrote: >>> >>>> >>>> >>>> >>>> >>>> >>>> On Feb 29, 2008, at 14:34, Anthony Kong wrote: >>>> >>>>> If I rename c.erl to something else, the problem goes away. >>>>> >>>>> What is special about "-module(c)" ? >>>> >>>> Welcome to the world of flat module namespaces. >>>> >>>> The code module is your friend in these circumstances. >>>> Look into code:clash() and code:which(module). >>>> >>>> code:which(c) should return "/lib/erlang/lib/stdlib- >>>> /ebin/c.beam" >>>> >>>> >>>> -Matt >>>> -- >>>> Matt Stancliff sysop >>>> AIM: seijimr iPhone: 678-591-9337 >>>> "The best way to predict the future is to invent it." --Alan Kay >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions >>>> http://www.erlang.org/mailman/listinfo/erlang-questions >>>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions >>> http://www.erlang.org/mailman/listinfo/erlang-questions >>> >> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Daniel Luna | Top reasons that I have a beard: luna | a) Laziness. http://www.update.uu.se/~luna/ | b) I can. Don't look at my homepage (it stinks).| c) I can get away with it. From ft Wed Mar 5 15:51:03 2008 From: ft (Fredrik Thulin) Date: Wed, 05 Mar 2008 15:51:03 +0100 Subject: [erlang-questions] LOC tool for Erlang In-Reply-To: <1C538D67B37E5B4784128A22270DF5C30FFE2A24@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C30FFE2A24@npri54exc20.npt.nuwc.navy.mil> Message-ID: <47CEB357.4070606@it.su.se> Convey Christian J NPRI wrote: > Does anyone know of an open source tool (hopefully without output in English) that counts lines of Erlang code? The 'cover' module in Erlang/OTP can be used for that (cover:analyse/3). For example usage, see YXA src/autotest.erl function get_module_coverage/1. /Fredrik From luna Wed Mar 5 16:03:43 2008 From: luna (Daniel Luna) Date: Wed, 5 Mar 2008 16:03:43 +0100 (CET) Subject: [erlang-questions] LOC tool for Erlang In-Reply-To: <1C538D67B37E5B4784128A22270DF5C30FFE2A24@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C30FFE2A24@npri54exc20.npt.nuwc.navy.mil> Message-ID: On Wed, 5 Mar 2008, Convey Christian J NPRI wrote: > Does anyone know of an open source tool (hopefully without output in > English) that counts lines of Erlang code? grep, wc and find are your friends. But the answer depends on what you mean with lines of Erlang code. All lines: wc -l $(find . -name "*rl") Lines that are not blank lines or comments: grep -v '^[[:space:]]*\($\|%\)' $(find . -name "*rl") | wc -l /Luna -- Daniel Luna | Top reasons that I have a beard: luna | a) Laziness. http://www.update.uu.se/~luna/ | b) I can. Don't look at my homepage (it stinks).| c) I can get away with it. From ConveyCJ Wed Mar 5 16:09:03 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Wed, 05 Mar 2008 10:09:03 -0500 Subject: [erlang-questions] LOC tool for Erlang Message-ID: <1C538D67B37E5B4784128A22270DF5C31004F11E@npri54exc20.npt.nuwc.navy.mil> Thanks. The grep idea was my fall-back plan, but I noticed that some tools count "logical" lines of code as well, which helps erase the effects of different coding linebreak styles. - Christian > -----Original Message----- > From: Daniel Luna [mailto:luna] > Sent: Wednesday, March 05, 2008 10:04 AM > To: Convey Christian J NPRI > Cc: erlang-questions > Subject: Re: [erlang-questions] LOC tool for Erlang > > On Wed, 5 Mar 2008, Convey Christian J NPRI wrote: > > Does anyone know of an open source tool (hopefully without output in > > English) that counts lines of Erlang code? > > grep, wc and find are your friends. > > But the answer depends on what you mean with lines of Erlang code. > > All lines: > > wc -l $(find . -name "*rl") > > Lines that are not blank lines or comments: > > grep -v '^[[:space:]]*\($\|%\)' $(find . -name "*rl") | wc -l > > /Luna > -- > Daniel Luna | Top reasons that I > have a beard: > luna | a) Laziness. > http://www.update.uu.se/~luna/ | b) I can. > Don't look at my homepage (it stinks).| c) I can get away with it. > From eranga.erl Wed Mar 5 16:46:55 2008 From: eranga.erl (Eranga Udesh) Date: Wed, 5 Mar 2008 21:16:55 +0530 Subject: [erlang-questions] Mnesia unstable with higher Async Threads? Message-ID: <912a3c160803050746ma926505oc8adecff1e89eed@mail.gmail.com> Hi, A busy Erlang node running only Mnesia application crashes unexpectedly without even generating an Erlang core dump, when the node started with 196 Async Threads. But when it reduced that to 64 Async Threads, the crash is not observed. There's plenty of free CPU and Memory in both the cases. Has anybody observed this before? Thanks, - Eranga -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/fa50fa05/attachment.html From kevin Wed Mar 5 18:57:00 2008 From: kevin (Kevin Scaldeferri) Date: Wed, 5 Mar 2008 09:57:00 -0800 Subject: [erlang-questions] Use of makefiles In-Reply-To: <1204703909.8234.14.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <053657FB-5463-4F29-9FD1-32D83CCC3B4C@telegraphics.com.au> <1204703909.8234.14.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: On Mar 4, 2008, at 11:58 PM, Bengt Kleberg wrote: > I have heard that there is only one perl, so it should be compatible. Well, sort of, but not entirely. Perl 5.10 was just released. It has new features which 5.8 does not support. 5.8 has features that 5.6 does not and, in fact, some outright incompatibilities. 5.8.0 has subtle but significant differences in file I/O and UTF-8 handling from the rest of the 5.8.x series. You will find all of these in the wild. If you're really unlucky, you might even find a system with an older version than 5.6. -kevin From dmercer Wed Mar 5 19:21:30 2008 From: dmercer (David Mercer) Date: Wed, 5 Mar 2008 12:21:30 -0600 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <47CE6FA5.7060808@it.uu.se> References: <77016.67694.qm@web38812.mail.mud.yahoo.com> <47CE6FA5.7060808@it.uu.se> Message-ID: <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> What am I missing from the description of Erlang packages that does not do what everyone wants: namely, namespaces? I would think if I want to create all my modules under my own "mercer" namespace, I'd just put them in a directory called "mercer" and then name my modules "mercer.M" (where M is the module name. If this is what everyone seems to want, why hasn't the package notation caught on? Cheers, David Mercer -----Original Message----- From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Richard Carlsson Sent: Wednesday, March 05, 2008 04:02 To: Anthony Kong Cc: erlang-questions Subject: Re: [erlang-questions] newbie: why c.erl is special? It was implemented a long time ago, but there was not a lot of community enthusiasm for it, so it's not been made an official part of the language yet. Still, it should work also in R12. http://www.erlang.org/doc/man/packages.html It was originally inspired by/ripped off from Java, but in practice it's more similar to Lisp namespaces; see "The Complete Idiot's Guide to Common Lisp Packages" for details: http://www.flownet.com/ron/packages.pdf /Richard Anthony Kong wrote: > Is it already implemented? Because I found this document: > > http://www.erlang.se/publications/packages.html > > Anyway, I was unable to get it to work according to this info. > > Cheers, Anthony > > On Sun, Mar 2, 2008 at 12:38 AM, Thomas Lindgren > wrote: >> --- shiwei xu wrote: >> >> > I think flat module namespaces is a defect of erlang >> > design. >> >> Richard Carlsson proposed java-like packages some >> years ago, and the code for them might still be >> provided in OTP. (I thought they had some flaws, but >> they might be what you want.) >> >> http://citeseer.ist.psu.edu/398052.html >> >> The usual approach to handling name clashes without >> packages is to use your 'approach 2', prefixing the >> modules with their owner application. >> >> Best, >> Thomas _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From masterofquestions Wed Mar 5 19:32:41 2008 From: masterofquestions (db) Date: Wed, 5 Mar 2008 13:32:41 -0500 Subject: [erlang-questions] Secondary Mnesia Table index Message-ID: <1218d6a50803051032i32ebb014ncc1919e29806f142@mail.gmail.com> Here is my problem: I have a unique field in one of the mnesia set table. Problem is that I can't query on that unique key. If I create a secondary index, based on another field which is not so unique, this secondary index will bogg down mnesia inserts. Is this also true for dirty_insert? mnesia bag table maybe an option. But in some cases, certain (key, value) pair would become bloated and unhealthy. The data wouldn't produce good uniform balanced distribution. I have created first element of mnesia set table to be a tuple, composed of unique_field and not_so_unique_field. My record looks like this: -record(Tab1, {{unique_field, not_so_unique_field},unique_field, not_so_unique_field}) mnesia set table index is on the first element: {unique_field, not_so_unique_field} Would I be able query on not_so_unique_field with an index based on tuple {unique_field, not_so_unique_field} ? This little issue tempting me to look at jungerl-rdbms. Before I spent great deal of time on rdbms, I have few questions regarding it. Does rdbms support dirty_read, dirty_insert and the above scenario? thank you, -- rk That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. -Ralph Waldo Emerson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080305/ad320a22/attachment.html From vances Wed Mar 5 20:28:08 2008 From: vances (Vance Shipley) Date: Wed, 5 Mar 2008 14:28:08 -0500 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> Message-ID: <20080305192807.GP66069@h216-235-12-172.host.egate.net> On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote: } If this is what everyone seems to want, why hasn't the package notation } caught on? A very good question. There have been very few user contributions written with packages. Package support is not official yet either. So we seem to have a chicken and egg situation. If it were supported folks would adopt it. If folks adopted it it would get supported. There were arguments against the concept however. I'll leave it to the CS types to argue that one. I found packages really useful to handle authentication plugins in a project I did several years ago. -Vance From drxyzzy Wed Mar 5 21:22:16 2008 From: drxyzzy (Hal Snyder) Date: Wed, 5 Mar 2008 14:22:16 -0600 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <20080305192807.GP66069@h216-235-12-172.host.egate.net> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> Message-ID: <8C9A7C8F-C0CB-4A59-A12A-C67B30E1F988@gmail.com> IIRC there was a problem with systools, building .boot and .script with packages in the picture. That was a few years ago, not sure what the situation is now. On Mar 5, 2008, at 1:28 PM, Vance Shipley wrote: > On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote: > } If this is what everyone seems to want, why hasn't the package > notation > } caught on? > > A very good question. There have been very few user contributions > written with packages. Package support is not official yet either. > So we seem to have a chicken and egg situation. If it were supported > folks would adopt it. If folks adopted it it would get supported. > > There were arguments against the concept however. I'll leave it > to the CS types to argue that one. I found packages really useful > to handle authentication plugins in a project I did several years ago. > > -Vance From monch1962 Wed Mar 5 21:59:05 2008 From: monch1962 (David Mitchell) Date: Thu, 6 Mar 2008 07:59:05 +1100 Subject: [erlang-questions] Newbie question: avoiding massive 'case' statement Message-ID: Hello everyone, Newbie alert... I've got a block of code that looks like: case TransactionType of "ZABC" -> zabc:process_request(Request); "Z123" -> z123:process_request(Request); "YPQX" -> ypqx:process_request(Request); ... TransactionType -> error_logger:info_msg("Unknown transaction type") end This is all fine and dandy, but I'm expecting the 'case' statement to grow to handle several hundred different values of TransactionType over time. The code is going to get unwieldy in size, and the likelihood of mistakes in cut/paste updating of the 'case' block is going to get pretty high. As an alternative to the above, is there a way to do something like try &&&TransactionType&&&:process_request(Request) catch error_logger:info_msg("Unknown transaction type") end where &&&TransactionType&&&:process_request(...) is some "magic code" that lets me call the process_request function in the module that has the name of the value of TransactionType (hopefully that's clear, if not necessarily English)? Alternately, is there some sort of refactoring I could do to avoid the massive 'case' statement? There may be some obvious solution to do this, but I haven't been able to find it... Thanks in advance Dave Mitchell From vladdu55 Wed Mar 5 22:16:19 2008 From: vladdu55 (Vlad Dumitrescu) Date: Wed, 5 Mar 2008 22:16:19 +0100 Subject: [erlang-questions] Fwd: Newbie question: avoiding massive 'case' statement In-Reply-To: <95be1d3b0803051315l1b708f56j75a6ac7ac1e9035e@mail.gmail.com> References: <95be1d3b0803051315l1b708f56j75a6ac7ac1e9035e@mail.gmail.com> Message-ID: <95be1d3b0803051316y6ddf7436q7a642a6e0434f189@mail.gmail.com> Hi! On Wed, Mar 5, 2008 at 9:59 PM, David Mitchell wrote: > I've got a block of code that looks like: > case TransactionType of > "ZABC" -> > zabc:process_request(Request); > "Z123" -> > z123:process_request(Request); > "YPQX" -> > ypqx:process_request(Request); > ... > TransactionType -> > error_logger:info_msg("Unknown transaction type") > end You could use something like get_handler("ZABC") -> zabc; get_handler("Z123") -> z123; ....... get_handler(_) -> error_logger:info_msg("Unknown transaction type"), error and in your code just call Module = get_Handler(TransactionType), case Module of error -> done; _ -> Module:process_request(Request); end, best regards, Vlad -- Some people see things that are and ask, Why? Some people dream of things that never were and ask, Why not? Some people have to go to work and don't have time for all that. --- George Carlin -- Some people see things that are and ask, Why? Some people dream of things that never were and ask, Why not? Some people have to go to work and don't have time for all that. --- George Carlin From klas.johansson Wed Mar 5 22:26:13 2008 From: klas.johansson (Klas Johansson) Date: Wed, 5 Mar 2008 22:26:13 +0100 Subject: [erlang-questions] Python interface In-Reply-To: <4fd059680803031221n51364b51w34ec2e64d36aa58f@mail.gmail.com> References: <4fd059680803031221n51364b51w34ec2e64d36aa58f@mail.gmail.com> Message-ID: > is there something like the jinterface for python, which is up to date? > I'm asking, because the way via ports is to circuitous for my purpose. Hi, There's py-interface: http://www.lysator.liu.se/~tab/erlang/py_interface/ Regards, Klas From ulf.wiger Wed Mar 5 22:27:31 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Wed, 05 Mar 2008 22:27:31 +0100 Subject: [erlang-questions] Newbie question: avoiding massive 'case' statement In-Reply-To: References: Message-ID: <47CF1043.7020409@ericsson.com> David Mitchell skrev: > Hello everyone, > > Newbie alert... > > I've got a block of code that looks like: > > case TransactionType of > "ZABC" -> > zabc:process_request(Request); > "Z123" -> > z123:process_request(Request); > "YPQX" -> > ypqx:process_request(Request); > ... > TransactionType -> > error_logger:info_msg("Unknown transaction type") > end If this is indicative of a pattern, then you could try something like: M = list_to_existing_atom(string:to_lower(TransactionType)), M:process_request(Request). For some added safety, you could do something like case erlang:function_exported(M,process_request,1) of true -> M:process_request(Request); false -> %% Complication: M might not be loaded yet... error_logger:info_msg("Unknown transaction type") end. You can of course embellish the above to your liking. BR, Ulf W From erlangy Wed Mar 5 22:30:32 2008 From: erlangy (Michael McDaniel) Date: Wed, 5 Mar 2008 13:30:32 -0800 Subject: [erlang-questions] Newbie question: avoiding massive 'case' statement In-Reply-To: References: Message-ID: <20080305213032.GW20457@delora.autosys.us> maybe something like or a variation of ... TransactionType = "ZABC" , %% or however it gets loaded Request = "some appropriate request for TransactionType" , TT = string:to_lower(TransactionType) , %% no problem if already lower erlang:apply( erlang:list_to_atom(TT), process_request, [Request] ) , %% and catch the exception from the apply ~Michael On Thu, Mar 06, 2008 at 07:59:05AM +1100, David Mitchell wrote: > Hello everyone, > > Newbie alert... > > I've got a block of code that looks like: > > case TransactionType of > "ZABC" -> > zabc:process_request(Request); > "Z123" -> > z123:process_request(Request); > "YPQX" -> > ypqx:process_request(Request); > ... > TransactionType -> > error_logger:info_msg("Unknown transaction type") > end > > This is all fine and dandy, but I'm expecting the 'case' statement to > grow to handle several hundred different values of TransactionType > over time. The code is going to get unwieldy in size, and the > likelihood of mistakes in cut/paste updating of the 'case' block is > going to get pretty high. > > As an alternative to the above, is there a way to do something like > > try > &&&TransactionType&&&:process_request(Request) > catch > error_logger:info_msg("Unknown transaction type") > end > > where &&&TransactionType&&&:process_request(...) is some "magic code" > that lets me call the process_request function in the module that has > the name of the value of TransactionType (hopefully that's clear, if > not necessarily English)? > > Alternately, is there some sort of refactoring I could do to avoid the > massive 'case' statement? > > There may be some obvious solution to do this, but I haven't been able > to find it... > > Thanks in advance > > Dave Mitchell > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions -- Michael McDaniel Portland, Oregon, USA http://autosys.us +1 503 283 5284 From vances Wed Mar 5 22:31:59 2008 From: vances (Vance Shipley) Date: Wed, 5 Mar 2008 16:31:59 -0500 Subject: [erlang-questions] Newbie question: avoiding massive 'case' statement In-Reply-To: References: Message-ID: <20080305213158.GU66069@h216-235-12-172.host.egate.net> On Thu, Mar 06, 2008 at 07:59:05AM +1100, David Mitchell wrote: } try } &&&TransactionType&&&:process_request(Request) } catch } error_logger:info_msg("Unknown transaction type") } end } } where &&&TransactionType&&&:process_request(...) is some "magic code" receive TransactionType -> try TransactionType:process_request(Request) catch _ -> error_logger:info_msg("Unknown transaction type") end end Just send the transaction type as an atom. If you must receive it as a list use erlang:list_to_existing_atom(TransactionType). -Vance From richardc Wed Mar 5 22:33:32 2008 From: richardc (Richard Carlsson) Date: Wed, 05 Mar 2008 22:33:32 +0100 Subject: [erlang-questions] Newbie question: avoiding massive 'case' statement In-Reply-To: References: Message-ID: <47CF11AC.6010002@it.uu.se> You can do something like this: request_type("ZABC") -> zabc; request_type("Z123") -> z123; request_type("YPQX") -> ypqx; ... request_type(String) -> throw({unknown_transaction_type, String}). that maps identifier strings to module names, and then M = request_type(TransactionTypeString), Result = M:process_request(Request) Since atoms are quicker to compare, you probably want to do the string-to-atom mapping quite early. If you want to separate atoms that identify request types from the actual handler module names, you could use another function that performs id-as-atom-to-handler-module mapping: M = request_handler(request_type(TransactionTypeString)), ... /Richard David Mitchell wrote: > Hello everyone, > > Newbie alert... > > I've got a block of code that looks like: > > case TransactionType of > "ZABC" -> > zabc:process_request(Request); > "Z123" -> > z123:process_request(Request); > "YPQX" -> > ypqx:process_request(Request); > ... > TransactionType -> > error_logger:info_msg("Unknown transaction type") > end > > This is all fine and dandy, but I'm expecting the 'case' statement to > grow to handle several hundred different values of TransactionType > over time. The code is going to get unwieldy in size, and the > likelihood of mistakes in cut/paste updating of the 'case' block is > going to get pretty high. > > As an alternative to the above, is there a way to do something like > > try > &&&TransactionType&&&:process_request(Request) > catch > error_logger:info_msg("Unknown transaction type") > end > > where &&&TransactionType&&&:process_request(...) is some "magic code" > that lets me call the process_request function in the module that has > the name of the value of TransactionType (hopefully that's clear, if > not necessarily English)? > > Alternately, is there some sort of refactoring I could do to avoid the > massive 'case' statement? > > There may be some obvious solution to do this, but I haven't been able > to find it... > > Thanks in advance > > Dave Mitchell > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From ok Wed Mar 5 23:51:17 2008 From: ok (Richard A. O'Keefe) Date: Thu, 6 Mar 2008 11:51:17 +1300 Subject: [erlang-questions] Use of makefiles In-Reply-To: <1204703909.8234.14.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <053657FB-5463-4F29-9FD1-32D83CCC3B4C@telegraphics.com.au> <1204703909.8234.14.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: <077D18BE-4E02-4643-82E9-BBB040893467@cs.otago.ac.nz> On 5 Mar 2008, at 8:58 pm, Bengt Kleberg wrote: > The question I asked was if a perl program would be more likely to run > on ''any'' machine, than a makefile. Not because the person who wrote > the makefile forgot/failed to read the manual for gnu make, but > because > there are other make programs than gnu make out there. The 4 ones I > have > used where not compatible. They would not run each others makefiles. If you stick to what's described in the original Make paper, every Make I have ever come across (save on Windows) is compatible with that. I try to stick to what's described in the Single Unix Specification, and haven't had any trouble with portability. I haven't tried nmake on Windows, but GNU make is available for Windows and can handle POSIX (=SUS) makefiles. > > > I have heard that there is only one perl, so it should be compatible. It is not true that there is only one Perl. There has been one Perl development stream, but there have been many versions issued in that stream. What works in Perl 5.8.8 might not work in Perl 5.4, and probably won't work in Perl 6 if that ever gets finished. (You are aware that Perl 6 is supposed to be a whole new language?) > > So, is the chance of finding perl on ''any'' computer bigger than the > chance of finding the right make program for your makefile? I respectfully suggest that there is a bigger problem than makefile compatibility, and that is C compiler command line compatibility. For example, to get optimised code I write cc -O2 foobar.c on one machine, but cc -xO2 foobar.c on another, and on another machine, sadly decommissioned because the vendor having stopped making the hardware and having decided never to upgrade the compiler or operating system nevertheless decided to start charging a really ridiculous licence fee to run the thing in multiuser mode, the command line switches were different again. Come to think of it, I have three C compilers on one machine, all with different switches, so simply checking which operating system it is won't help. When I use R, all of that is handled for me; if I ask the R system to arrange a C (or Fortran) compilation for me, it remembers what worked when it was built, and does it for me. Wouldn't it be nice if installing Erlang gave you erl cc ... that would run a C compiler with all the right switches to work with Erlang? > > > > bengt > > .On Tue, 2008-03-04 at 13:09 -0500, Toby Thain wrote: >> On 4-Mar-08, at 11:57 AM, Bengt Kleberg wrote: >> >>> Greetings, >>> >>> Is it not also the case that perl is more standard than make? >> >> >> Is *everyone* supposed to rewrite make in Perl every time they want >> to build something? >> >>> I know very little of perl, but have fought at least 4 different >>> kinds >>> of make (files). >> >> The GNU make documentation is really very good. I don't know why >> people rarely refer to it. >> >> --T >> >>> >>> >>> bengt >>> >>> On Tue, 2008-03-04 at 10:11 -0600, James Hague wrote: >>>> On Sat, Mar 1, 2008 at 8:41 PM, Steve Vinoski >>>> wrote: >>>>> >>>>> Hi Joe, I agree with you 100%. Give me emacs (with its vast >>>>> emacs-lisp >>>>> extensibility), bash (or ksh), and various UNIX command-line >>>>> tools, >>>>> which I can combine as I wish using pipes, and keep the visual >>>>> tools >>>>> out of my way (and out of my RAM). >>>> >>>> I think this discussion has been misinterpreted :) No one is >>>> arguing >>>> for IDE-like features over makefiles. >>>> >>>> I have found that I don't need makefiles for my Erlang projects. I >>>> either recompile the same module repeatedly or I want to rebuild >>>> everything. The former is business as usual. The latter is easily >>>> done with a shell script, Perl script, or short Erlang program. I >>>> use >>>> makefiles infrequently enough that I always forget the syntax and >>>> nuances of using them. But I can bang out a Perl program that does >>>> the same thing--even checking file modification dates and so on--in >>>> very little time. It's more flexible than using a makefile, too, >>>> and >>>> usually ends up being less "code." >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions >>>> http://www.erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions >>> http://www.erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions >> http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions -- Te Reo Engarihi is a taonga of Te Iwi Pakeha, ergo we should keep it pure, sans m?lange, ruat caelum. From mcpherson Mon Mar 3 21:25:11 2008 From: mcpherson (Allen McPherson) Date: Mon, 3 Mar 2008 13:25:11 -0700 Subject: [erlang-questions] message ring test (memory allocation question) Message-ID: <85AC242D-D5DF-4917-BD92-393ABEA03A56@lanl.gov> Hello, First post here from a new Erlang programmer. As an exercise I have written the message ring benchmark that Joe talked about in his book: -module(cleanring). -compile(export_all). start(N, Msg) -> StartPid = launch(self(), N), StartPid ! {Msg, self(), 0}, receive {MsgRecvd, _FromPid, _Hop} -> done end, StartPid ! die, MsgRecvd. launch(Pid, N) -> FromPid = spawn(fun() -> loop(Pid) end), if N =:= 1 -> FromPid; true -> launch(FromPid, N-1) end. loop(ToPid) -> receive {Term, _FromPid, Hop} -> ToPid ! {Term, self(), Hop+1}, loop(ToPid); die -> ToPid ! die end. If I run as follows, it dies in malloc: 1> c(cleanring). 2> L = lists:seq(1,100000). 3> cleanring:start(32000, L). If I make L a binary (in a restarted erl shell) it runs fine (and too fast to believe): 1> c(cleanring). 2> L = lists:seq(1,100000). 3> LL = term_to_binary(L). 4> cleanring:start(32000, LL). Is the runtime somehow just passing around a pointer to LL by virtue of it being a binary? I'm not sure why it doesn't crash as the first run did. Also, if you spot anything really wrong with the program I'd appreciate a heads up. I'm new to Erlang and am sometimes not sure if the code I write is in the "right mindset" (functional programming-wise). Thanks -- Al From richard Thu Mar 6 00:26:27 2008 From: richard (Richard Bucker) Date: Wed, 5 Mar 2008 18:26:27 -0500 Subject: [erlang-questions] RSA encryption / missing methods Message-ID: crypto:mod_exp() is, randomly, not returning my data when decrypting and so I need help getting direction on how to debug this type of application. My application works like this: 1) generate a DEK (data encryption key) pub/priv key using openssl via os:cmd() 2) generate a KEK (key encryption key) pub/priv key using openssl via os:cmd() 3) use the pub & mod from the KEK to encrypt the priv of the DEK and in use... 1) encrypt my data with the crypto:mod_exp(Data, Pub, Mod). 2) then decrypt the message crypto:mod_exp(Data, Priv, Mod). 3) compare the before and after ---[SNIP]--- Msg = "my message", C2 = key_tools:mini2_encrypt(Msg), P2 = key_tools:mini2_decrypt(C2), Msg = binary_to_list(P2), ---[SNIP]--- so far so good, however, every so often it fails to 'match' /r From tomas.abrahamsson Thu Mar 6 00:36:04 2008 From: tomas.abrahamsson (Tomas Abrahamsson) Date: Thu, 6 Mar 2008 00:36:04 +0100 Subject: [erlang-questions] Python interface In-Reply-To: References: <4fd059680803031221n51364b51w34ec2e64d36aa58f@mail.gmail.com> Message-ID: >> is there something like the jinterface for python, which is up to date? >> I'm asking, because the way via ports is to circuitous for my purpose. > There's py-interface: > http://www.lysator.liu.se/~tab/erlang/py_interface/ Works with Erlang R12 and Python 2.4, but I haven't spent much time keeping it up to date, so no bitstring support, for example. /Tomas From mcpherson Tue Mar 4 16:54:04 2008 From: mcpherson (Allen McPherson) Date: Tue, 4 Mar 2008 08:54:04 -0700 Subject: [erlang-questions] message ring test (memory allocation question) Message-ID: <744BB52D-E4C4-41EB-AAB6-DF0A53B36C1A@lanl.gov> -- Re-post. Hope I don't generate a duplicate post but I just signed up. Hello, First post here from a new Erlang programmer. As an exercise I have written the message ring benchmark that Joe talked about in his book: -module(cleanring). -compile(export_all). start(N, Msg) -> StartPid = launch(self(), N), StartPid ! {Msg, self(), 0}, receive {MsgRecvd, _FromPid, _Hop} -> done end, StartPid ! die, MsgRecvd. launch(Pid, N) -> FromPid = spawn(fun() -> loop(Pid) end), if N =:= 1 -> FromPid; true -> launch(FromPid, N-1) end. loop(ToPid) -> receive {Term, _FromPid, Hop} -> ToPid ! {Term, self(), Hop+1}, loop(ToPid); die -> ToPid ! die end. If I run as follows, it dies in malloc: 1> c(cleanring). 2> L = lists:seq(1,100000). 3> cleanring:start(32000, L). If I make L a binary (in a restarted erl shell) it runs fine (and too fast to believe): 1> c(cleanring). 2> L = lists:seq(1,100000). 3> LL = term_to_binary(L). 4> cleanring:start(32000, LL). Is the runtime somehow just passing around a pointer to LL by virtue of it being a binary? I'm not sure why it doesn't crash as the first run did. Also, if you spot anything really wrong with the program I'd appreciate a heads up. I'm new to Erlang and am sometimes not sure if the code I write is in the "right mindset" (functional programming-wise). Thanks -- Al From ok Thu Mar 6 01:45:16 2008 From: ok (Richard A. O'Keefe) Date: Thu, 6 Mar 2008 13:45:16 +1300 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <20080305192807.GP66069@h216-235-12-172.host.egate.net> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> Message-ID: <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> > On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote: > } If this is what everyone seems to want, why hasn't the package > notation > } caught on? > But *is* it what everyone wants? I have argued at some length that the whole thing is back to front, inside out, and even upside down. I believe that you should be able to - move an entire group of closely related modules around in the module universe by changing one line in one place - incorporate (the fa?ade of) a cluster of modules by writing one line in one place - be able to retrospectively bundle up a cluster of related modules without touching their source code - be able to have two versions of a cluster at the same time without modifying their source code and a whole lot of things like that, which the Java-envious dotted names just make harder, and I have proposed a LACE-like means of accomplishing this. Not the least of the problems is that Java-envious dotted package names aren't really hierarchical; they are just flat strings with funny spelling. From bob Thu Mar 6 02:02:30 2008 From: bob (Bob Ippolito) Date: Wed, 5 Mar 2008 17:02:30 -0800 Subject: [erlang-questions] Use of makefiles In-Reply-To: <077D18BE-4E02-4643-82E9-BBB040893467@cs.otago.ac.nz> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <053657FB-5463-4F29-9FD1-32D83CCC3B4C@telegraphics.com.au> <1204703909.8234.14.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <077D18BE-4E02-4643-82E9-BBB040893467@cs.otago.ac.nz> Message-ID: <6a36e7290803051702t14b1f36bx8ea6ce58689c985b@mail.gmail.com> On Wed, Mar 5, 2008 at 2:51 PM, Richard A. O'Keefe wrote: > > On 5 Mar 2008, at 8:58 pm, Bengt Kleberg wrote: > > The question I asked was if a perl program would be more likely to run > > on ''any'' machine, than a makefile. Not because the person who wrote > > the makefile forgot/failed to read the manual for gnu make, but > > because > > there are other make programs than gnu make out there. The 4 ones I > > have > > used where not compatible. They would not run each others makefiles. > > If you stick to what's described in the original Make paper, every > Make I > have ever come across (save on Windows) is compatible with that. I try > to stick to what's described in the Single Unix Specification, and > haven't > had any trouble with portability. I haven't tried nmake on Windows, but > GNU make is available for Windows and can handle POSIX (=SUS) makefiles. > > > > > > > I have heard that there is only one perl, so it should be compatible. > > It is not true that there is only one Perl. There has been one Perl > development > stream, but there have been many versions issued in that stream. What > works > in Perl 5.8.8 might not work in Perl 5.4, and probably won't work in > Perl 6 if that > ever gets finished. (You are aware that Perl 6 is supposed to be a > whole new > language?) > > > > > So, is the chance of finding perl on ''any'' computer bigger than the > > chance of finding the right make program for your makefile? > > I respectfully suggest that there is a bigger problem than makefile > compatibility, > and that is C compiler command line compatibility. For example, to > get optimised > code I write > cc -O2 foobar.c > on one machine, but > cc -xO2 foobar.c > on another, and on another machine, sadly decommissioned because the > vendor > having stopped making the hardware and having decided never to upgrade > the > compiler or operating system nevertheless decided to start charging a > really > ridiculous licence fee to run the thing in multiuser mode, the command > line switches > were different again. Come to think of it, I have three C compilers > on one machine, > all with different switches, so simply checking which operating system > it is won't help. > > When I use R, all of that is handled for me; if I ask the R system to > arrange a C (or > Fortran) compilation for me, it remembers what worked when it was > built, and does > it for me. Wouldn't it be nice if installing Erlang gave you > erl cc ... > that would run a C compiler with all the right switches to work with > Erlang? That's what Python does, it saves the Makefile that was generated during the Python build and its distutils build system will parse out features from that Makefile in order to build extensions. It doesn't actually invoke make at any point beyond the initial ./configure; make of the python system, it's effectively used as a configuration file. -bob From yarivsadan Thu Mar 6 08:58:43 2008 From: yarivsadan (Yariv Sadan) Date: Wed, 5 Mar 2008 23:58:43 -0800 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: <17244f480803052358w365e9fdeneb740f3e0ddfd0b3@mail.gmail.com> Hi, I think I found a bug in lfe_eval. I created the following macro: (define-syntax bar (macro ((vals) (: lists map (lambda (x) (: io format '"~p~n" x)) vals) ()))) and the following function: (define (foo) (bar (1 2 3))) When I call '(foo)' I get the following error: ** exception error: lfe_eval:'-eval_lambda/2-fun-0-'/2 called with one argument in function lists:map/2 in call from lfe_eval:eval_body/2 in call from lfe_macro:macro/3 in call from lfe_macro:expand_tail/3 in call from lfe_macro:expand/2 in call from lfe_macro:expand_top_forms/2 in call from lfe_macro:expand_top_forms/2 in call from lfe_macro:expand_file/2 Also, can you please explain the difference between 'macro' and 'syntax-rules'? 'macro' seems to do what I expect and I'm not sure when syntax-rules would be a better option. Thanks, Yariv 2008/3/1 Robert Virding : > I have finally released LFE, Lisp Flavoured Erlang, which is a lisp syntax > front-end to the Erlang compiler. Code produced with it is compatible with > "normal" Erlang code. The is an LFE-mode for Emacs and the lfe-mode.el file > is include in the distribution. Most things seem to work but some things > have not been done yet: > > - The interpreter does handle recursive letrecs, binaries, receive or try. > - There is no lisp shell. > - Documentation! > > Yet. The system will be updated as new features are added. This is the 1st > release so there is much left to do. > > I have include the existing documentation lfe_guide.txt in this mail. There > are a number of LFE test files and a version of the LFE interpreter written > in LFE as examples of code. There are also a number of issues which need to > be decided for the next version and I have included a file lfe_issues.txt > which describe them in this mail. Both files are in the distribution. > > Note that while this this lisp has been inspired by Scheme (one of the > issues) it is a NOT Scheme, it is Erlang with a lisp syntax and many nice > lisp features. Not for that matter is it Common Lisp. In fact features of > the Erlang engine mean that it is actually impossible to implement full > Scheme of CL. No, they shouldn't be changed or added. > > It was quite writing Erlang code in lisp and I could easily consider using a > lisp syntax for Erlang. I suppose it depends where your preferences lye. It > was also easy to get into the traditional lisp habit of using long names for > everything which I personally think is not a Good Thing. Perhaps we should > do AFE, Arc Flavoured Erlang, instead? Although I think they have gone too > far and missed what makes programs easy to read. > > Macros are very nice, and it is easy to generate LFE code, which is one of > the benefits of lisp syntax. > > LFE also shows that it would probably be possible to write other front-ends > inspired by other languages, though why anyone should want to I don't know. > Perhaps back to a real Prolog syntax again. > > The system can be found in the "User Contributions" section at trapexit.org, > http://forum.trapexit.org/viewtopic.php?p=40268#40268. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From monch1962 Thu Mar 6 08:59:50 2008 From: monch1962 (David Mitchell) Date: Thu, 6 Mar 2008 18:59:50 +1100 Subject: [erlang-questions] Newbie question: avoiding massive 'case' statement In-Reply-To: <20080305213032.GW20457@delora.autosys.us> References: <20080305213032.GW20457@delora.autosys.us> Message-ID: Thanks everyone, I used Ulf's suggestion and it worked like a charm. Regards Dave Mitchell On 06/03/2008, Michael McDaniel wrote: > maybe something like or a variation of ... > > TransactionType = "ZABC" , %% or however it gets loaded > Request = "some appropriate request for TransactionType" , > > TT = string:to_lower(TransactionType) , %% no problem if already lower > > > erlang:apply( erlang:list_to_atom(TT), process_request, [Request] ) , > > > %% and catch the exception from the apply > > > ~Michael > > > > On Thu, Mar 06, 2008 at 07:59:05AM +1100, David Mitchell wrote: > > > Hello everyone, > > > > Newbie alert... > > > > I've got a block of code that looks like: > > > > case TransactionType of > > "ZABC" -> > > zabc:process_request(Request); > > "Z123" -> > > z123:process_request(Request); > > "YPQX" -> > > ypqx:process_request(Request); > > ... > > TransactionType -> > > error_logger:info_msg("Unknown transaction type") > > end > > > > This is all fine and dandy, but I'm expecting the 'case' statement to > > grow to handle several hundred different values of TransactionType > > over time. The code is going to get unwieldy in size, and the > > likelihood of mistakes in cut/paste updating of the 'case' block is > > going to get pretty high. > > > > As an alternative to the above, is there a way to do something like > > > > try > > &&&TransactionType&&&:process_request(Request) > > catch > > error_logger:info_msg("Unknown transaction type") > > end > > > > where &&&TransactionType&&&:process_request(...) is some "magic code" > > that lets me call the process_request function in the module that has > > the name of the value of TransactionType (hopefully that's clear, if > > not necessarily English)? > > > > Alternately, is there some sort of refactoring I could do to avoid the > > massive 'case' statement? > > > > There may be some obvious solution to do this, but I haven't been able > > to find it... > > > > Thanks in advance > > > > Dave Mitchell > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > -- > Michael McDaniel > Portland, Oregon, USA > http://autosys.us > +1 503 283 5284 > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From lovei Thu Mar 6 09:59:05 2008 From: lovei (=?ISO-8859-2?Q?L=F6vei_L=E1szl=F3?=) Date: Thu, 06 Mar 2008 09:59:05 +0100 Subject: [erlang-questions] packages (was: newbie: why c.erl is special?) In-Reply-To: <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> Message-ID: <47CFB259.7040205@elte.hu> Richard A. O'Keefe wrote: >> On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote: >> } If this is what everyone seems to want, why hasn't the package >> notation >> } caught on? >> > But *is* it what everyone wants? It seems to me (after reading the list archive) that everyone wants this, only some people want even more. But this notation is here, and it works, only some encouragement is missing for it to become widespread (like mentioning it in the reference manual and the tutorial). Personally I would very much like it to be an officially supported feature (with related bugs fixed). Maybe that would make way for later enhancements too. Laszlo From bengt.kleberg Thu Mar 6 10:22:14 2008 From: bengt.kleberg (Bengt Kleberg) Date: Thu, 06 Mar 2008 10:22:14 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> Message-ID: <1204795334.8525.11.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, While I do not know what everybody wants I have a question about the lack of hierarchy in the existing (unsupported) erlang dotted package name. Given a module a.b.c and another module a.b.d, is it not possible to say d:fun() in a.b.c and get a.b.d:fun()? If the system is flat strings I would expect to have to write a.b.d:fun() in a.b.c. Even so I would still like to have a LACE like system for erlang. It would be able to handle more situations with less work for me. bengt On Thu, 2008-03-06 at 13:45 +1300, Richard A. O'Keefe wrote: > > On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote: > > } If this is what everyone seems to want, why hasn't the package > > notation > > } caught on? > > > But *is* it what everyone wants? > I have argued at some length that the whole thing is back to front, > inside out, > and even upside down. I believe that you should be able to > - move an entire group of closely related modules around in the > module universe > by changing one line in one place > - incorporate (the fa?ade of) a cluster of modules > by writing one line in one place > - be able to retrospectively bundle up a cluster of related modules > without touching their source code > - be able to have two versions of a cluster at the same time > without modifying their source code > and a whole lot of things like that, which the Java-envious dotted > names just > make harder, and I have proposed a LACE-like means of accomplishing > this. > > Not the least of the problems is that Java-envious dotted package > names aren't > really hierarchical; they are just flat strings with funny spelling. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From bengt.kleberg Thu Mar 6 10:37:19 2008 From: bengt.kleberg (Bengt Kleberg) Date: Thu, 06 Mar 2008 10:37:19 +0100 Subject: [erlang-questions] Use of makefiles In-Reply-To: <077D18BE-4E02-4643-82E9-BBB040893467@cs.otago.ac.nz> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <053657FB-5463-4F29-9FD1-32D83CCC3B4C@telegraphics.com.au> <1204703909.8234.14.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <077D18BE-4E02-4643-82E9-BBB040893467@cs.otago.ac.nz> Message-ID: <1204796240.8525.25.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, You are correct. If we want to build C programs the different C compilers are more of a problem than perl or make incompatibilities. You suggestion that erlang could help with C compilation is a very good one. Thanks for explaining perl to me. It sounds as bad as make. Building erlang programs is, IMHO, best done with erl -make. Users are more interested in having later versions of the program they are really working with. Make/Perl is only secondary in this scenario. bengt On Thu, 2008-03-06 at 11:51 +1300, Richard A. O'Keefe wrote: > On 5 Mar 2008, at 8:58 pm, Bengt Kleberg wrote: > > The question I asked was if a perl program would be more likely to run > > on ''any'' machine, than a makefile. Not because the person who wrote > > the makefile forgot/failed to read the manual for gnu make, but > > because > > there are other make programs than gnu make out there. The 4 ones I > > have > > used where not compatible. They would not run each others makefiles. > > If you stick to what's described in the original Make paper, every > Make I > have ever come across (save on Windows) is compatible with that. I try > to stick to what's described in the Single Unix Specification, and > haven't > had any trouble with portability. I haven't tried nmake on Windows, but > GNU make is available for Windows and can handle POSIX (=SUS) makefiles. > > > > > > I have heard that there is only one perl, so it should be compatible. > > It is not true that there is only one Perl. There has been one Perl > development > stream, but there have been many versions issued in that stream. What > works > in Perl 5.8.8 might not work in Perl 5.4, and probably won't work in > Perl 6 if that > ever gets finished. (You are aware that Perl 6 is supposed to be a > whole new > language?) > > > > So, is the chance of finding perl on ''any'' computer bigger than the > > chance of finding the right make program for your makefile? > > I respectfully suggest that there is a bigger problem than makefile > compatibility, > and that is C compiler command line compatibility. For example, to > get optimised > code I write > cc -O2 foobar.c > on one machine, but > cc -xO2 foobar.c > on another, and on another machine, sadly decommissioned because the > vendor > having stopped making the hardware and having decided never to upgrade > the > compiler or operating system nevertheless decided to start charging a > really > ridiculous licence fee to run the thing in multiuser mode, the command > line switches > were different again. Come to think of it, I have three C compilers > on one machine, > all with different switches, so simply checking which operating system > it is won't help. > > When I use R, all of that is handled for me; if I ask the R system to > arrange a C (or > Fortran) compilation for me, it remembers what worked when it was > built, and does > it for me. Wouldn't it be nice if installing Erlang gave you > erl cc ... > that would run a C compiler with all the right switches to work with > Erlang? > > > > > > > > > bengt > > > > .On Tue, 2008-03-04 at 13:09 -0500, Toby Thain wrote: > >> On 4-Mar-08, at 11:57 AM, Bengt Kleberg wrote: > >> > >>> Greetings, > >>> > >>> Is it not also the case that perl is more standard than make? > >> > >> > >> Is *everyone* supposed to rewrite make in Perl every time they want > >> to build something? > >> > >>> I know very little of perl, but have fought at least 4 different > >>> kinds > >>> of make (files). > >> > >> The GNU make documentation is really very good. I don't know why > >> people rarely refer to it. > >> > >> --T > >> > >>> > >>> > >>> bengt > >>> > >>> On Tue, 2008-03-04 at 10:11 -0600, James Hague wrote: > >>>> On Sat, Mar 1, 2008 at 8:41 PM, Steve Vinoski > >>>> wrote: > >>>>> > >>>>> Hi Joe, I agree with you 100%. Give me emacs (with its vast > >>>>> emacs-lisp > >>>>> extensibility), bash (or ksh), and various UNIX command-line > >>>>> tools, > >>>>> which I can combine as I wish using pipes, and keep the visual > >>>>> tools > >>>>> out of my way (and out of my RAM). > >>>> > >>>> I think this discussion has been misinterpreted :) No one is > >>>> arguing > >>>> for IDE-like features over makefiles. > >>>> > >>>> I have found that I don't need makefiles for my Erlang projects. I > >>>> either recompile the same module repeatedly or I want to rebuild > >>>> everything. The former is business as usual. The latter is easily > >>>> done with a shell script, Perl script, or short Erlang program. I > >>>> use > >>>> makefiles infrequently enough that I always forget the syntax and > >>>> nuances of using them. But I can bang out a Perl program that does > >>>> the same thing--even checking file modification dates and so on--in > >>>> very little time. It's more flexible than using a makefile, too, > >>>> and > >>>> usually ends up being less "code." > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions > >>>> http://www.erlang.org/mailman/listinfo/erlang-questions > >>> > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questions > >>> http://www.erlang.org/mailman/listinfo/erlang-questions > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions > >> http://www.erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > -- > Te Reo Engarihi is a taonga of Te Iwi Pakeha, > ergo we should keep it pure, sans m?lange, ruat caelum. > > > From adam Thu Mar 6 10:49:30 2008 From: adam (Adam Lindberg) Date: Thu, 6 Mar 2008 10:49:30 +0100 Subject: [erlang-questions] Fwd: Newbie question: avoiding massive 'case' statement In-Reply-To: <95be1d3b0803051316y6ddf7436q7a642a6e0434f189@mail.gmail.com> References: <95be1d3b0803051315l1b708f56j75a6ac7ac1e9035e@mail.gmail.com> <95be1d3b0803051316y6ddf7436q7a642a6e0434f189@mail.gmail.com> Message-ID: <6344005f0803060149l1d6cd57tbfeff4fd393fc589@mail.gmail.com> Hi David! Why not convert the string to the module name directly? zabc = list_to_atom(string:to_lower("ZABC")). In that case you'd only need a case to handle if the module is undefined: Module = list_to_atom(string:to_lower(TransactionType)), case code:ensure_loaded(Module) of {module, Module} -> Module:process_request(Request); {error, nofile} -> error_logger:info_msg("Unknown transaction type") end, Hope this gets you closer to a solution! Cheers! Adam -- Adam Lindberg http://www.erlang-consulting.com On Wed, Mar 5, 2008 at 10:16 PM, Vlad Dumitrescu wrote: > Hi! > > > On Wed, Mar 5, 2008 at 9:59 PM, David Mitchell > wrote: > > I've got a block of code that looks like: > > case TransactionType of > > "ZABC" -> > > zabc:process_request(Request); > > "Z123" -> > > z123:process_request(Request); > > "YPQX" -> > > ypqx:process_request(Request); > > ... > > TransactionType -> > > error_logger:info_msg("Unknown transaction type") > > end > > You could use something like > > get_handler("ZABC") -> > zabc; > get_handler("Z123") -> > z123; > ....... > get_handler(_) -> > error_logger:info_msg("Unknown transaction type"), > error > > and in your code just call > > Module = get_Handler(TransactionType), > case Module of > error -> > done; > _ -> > Module:process_request(Request); > end, > > best regards, > Vlad > > -- > Some people see things that are and ask, Why? > Some people dream of things that never were and ask, Why not? > Some people have to go to work and don't have time for all that. > --- George Carlin > > > > -- > Some people see things that are and ask, Why? > Some people dream of things that never were and ask, Why not? > Some people have to go to work and don't have time for all that. > --- George Carlin > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080306/207d9dd5/attachment.html From adam Thu Mar 6 10:54:55 2008 From: adam (Adam Lindberg) Date: Thu, 6 Mar 2008 10:54:55 +0100 Subject: [erlang-questions] Patch downloads & delayed messages In-Reply-To: <002301c87db9$68e8fb20$6401a8c0@moneymaker2> References: <002301c87db9$68e8fb20$6401a8c0@moneymaker2> Message-ID: <6344005f0803060154r7ce95527jfd4f932f182146db@mail.gmail.com> I seem to remember similar delays, even so much that I have now turned on a delivery note from the mailing list so that I'm sure that the messages arrive. Cheers, Adam -- Adam Lindberg http://www.erlang-consulting.com On Tue, Mar 4, 2008 at 6:34 AM, Valentin Micic wrote: > Dear all, > > Is there a single place containing all the patches for a particular relase > (available for download, of course)? > > Also, for some reason my messages are deleyed -- sometimes for more than > two > days. Anybody else with a similar experience? > > V. > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080306/57d13f34/attachment.html From sean.hinde Thu Mar 6 10:59:40 2008 From: sean.hinde (Sean Hinde) Date: Thu, 6 Mar 2008 10:59:40 +0100 Subject: [erlang-questions] packages (was: newbie: why c.erl is special?) In-Reply-To: <47CFB259.7040205@elte.hu> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> <47CFB259.7040205@elte.hu> Message-ID: On 6 Mar 2008, at 09:59, L?vei L?szl? wrote: > > It seems to me (after reading the list archive) that everyone wants > this, only some people want even more. But this notation is here, > and it > works, only some encouragement is missing for it to become widespread > (like mentioning it in the reference manual and the tutorial). Read again. Some people (myself included) thought it was an ugly wart solving a problem that only a few newbies stumble across and making erlang code harder to read and maintain. One of the worst aspects of this would be the endless traversing up and down interminable directory hierarchies. Soon we would need a full IDE just to help us find the definition of a module in the filesystem. Sean From matthias Thu Mar 6 10:09:59 2008 From: matthias (Matthias Lang) Date: Thu, 6 Mar 2008 10:09:59 +0100 Subject: [erlang-questions] message ring test (memory allocation question) In-Reply-To: <85AC242D-D5DF-4917-BD92-393ABEA03A56@lanl.gov> References: <85AC242D-D5DF-4917-BD92-393ABEA03A56@lanl.gov> Message-ID: <18383.46311.310458.629780@antilipe.corelatus.se> Hi, Nobody else has answered this already as far as I can see, maybe because you've figured out the answer yourself. Death through memory exhaustion is expected in the first case, and you imply that you weren't suprised either (the list L is going to eat 400k on most machines. 32000 copies of that is too big for my machine) Binaries are indeed treated differently by the implementation. They're stored in their own reference-counted memory pool, which is possible since binaries by definition can't contain references to anything else. Each of the 32000 message queues then contains just a pointer (more or less) to the binary, as you guessed. Matt ---------------------------------------------------------------------- Allen McPherson writes: > Hello, > > First post here from a new Erlang programmer. As an exercise I > have written the message ring benchmark that Joe talked about in > his book: > > -module(cleanring). > -compile(export_all). > > start(N, Msg) -> > StartPid = launch(self(), N), > StartPid ! {Msg, self(), 0}, > receive > {MsgRecvd, _FromPid, _Hop} -> done > end, > StartPid ! die, > MsgRecvd. > > launch(Pid, N) -> > FromPid = spawn(fun() -> loop(Pid) end), > if > N =:= 1 -> FromPid; > true -> launch(FromPid, N-1) > end. > > loop(ToPid) -> > receive > {Term, _FromPid, Hop} -> > ToPid ! {Term, self(), Hop+1}, > loop(ToPid); > die -> > ToPid ! die > end. > > > If I run as follows, it dies in malloc: > > 1> c(cleanring). > 2> L = lists:seq(1,100000). > 3> cleanring:start(32000, L). > > If I make L a binary (in a restarted erl shell) it runs fine (and too > fast to believe): > > 1> c(cleanring). > 2> L = lists:seq(1,100000). > 3> LL = term_to_binary(L). > 4> cleanring:start(32000, LL). > > Is the runtime somehow just passing around a pointer to LL by virtue > of it being a binary? I'm not sure why it doesn't crash as the first > run did. > > Also, if you spot anything really wrong with the program I'd > appreciate a > heads up. I'm new to Erlang and am sometimes not sure if the code I > write > is in the "right mindset" (functional programming-wise). > > Thanks > -- > Al > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From hakan Thu Mar 6 11:36:43 2008 From: hakan (Hakan Mattsson) Date: Thu, 6 Mar 2008 11:36:43 +0100 (CET) Subject: [erlang-questions] Secondary Mnesia Table index In-Reply-To: <1218d6a50803051032i32ebb014ncc1919e29806f142@mail.gmail.com> References: <1218d6a50803051032i32ebb014ncc1919e29806f142@mail.gmail.com> Message-ID: On Wed, 5 Mar 2008, db wrote: db> Here is my problem: db> db> I have a unique field in one of the mnesia set db> table. Problem is that I can't query on that db> unique key. Why? db> If I create a secondary index, based on another db> field which is not so unique, this secondary index will db> bogg down mnesia inserts. Is this also true for db> dirty_insert? Yes, dirty updates does also maintain the indecies. The values of secondary indexed fields must be fairly unique in order to not slow down updates too much. For example it is a poor decision to have an index for a boolean field. db> mnesia bag table maybe an option. But in some cases, db> certain (key, value) pair would become bloated and db> unhealthy. The data wouldn't produce good uniform db> balanced distribution. db> db> I have created first element of mnesia set table to be db> a tuple, composed of unique_field and db> not_so_unique_field. db> db> My record looks like this: db> -record(Tab1, {{unique_field, not_so_unique_field}, db> unique_field, not_so_unique_field}) db> db> mnesia set table index is on the first element: db> {unique_field, not_so_unique_field} It is a little bit confusing with your choice of record field names. What are you trying to achieve? Are your record fields redundant? The choice of structure for the primary key as well as the choice of secondary indecies depends a lot of how you intend to access the record. db> Would I be able query on not_so_unique_field with an db> index based on tuple {unique_field, not_so_unique_field} ? Yes, if you put them in the same record field. /H?kan From gleber.p Thu Mar 6 12:38:25 2008 From: gleber.p (Gleb Peregud) Date: Thu, 6 Mar 2008 12:38:25 +0100 Subject: [erlang-questions] how: Purging old records from Mnesia table Message-ID: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> Hello. I would like to implement some algorithm of purging old data from mnesia table. Expiration date is written inside each record (could be 0 for permanent data). I have few ideas how to implement it: 0) Every few seconds iterate over whole table and purge old records. It is implemented in this way now and it eats about 35% of CPU on every purge cycle for about 10 000 entries. Will index on expiration field speed up selecting? Is it better to use qlc? Will it speed give speed up if i use mnesia:index_match_object() ? 1) Use erlang:send_after() to send messages to purge individual records (with special care to timeouts greater then max value of unsigned int). Will Erlang runtime handle efficiently potentially up to few millions of timers? 2) Use some sort of queue to manage sorted list of records to be purged. Make special process which will receive information about new records, insert into this queue and sleep until first record is to be purged. Probably gb_trees will handle it. Are there better ADS for this task? I'll be greateful for any advices and responses :) Best Regards, -- Gleb Peregud http://gleber.pl/ From bengt.kleberg Thu Mar 6 12:46:24 2008 From: bengt.kleberg (Bengt Kleberg) Date: Thu, 06 Mar 2008 12:46:24 +0100 Subject: [erlang-questions] newbie: why c.erl is special? In-Reply-To: <47CEAC63.7090507@it.uu.se> References: <1204723871.8234.34.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <47CEAC63.7090507@it.uu.se> Message-ID: <1204803984.8525.35.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, I would like to be hammered a little bit more, please. Since it sounds difficult to handle at compile time I would like to ask how this will work. We have the following: stdlib-0/ebin/lists.beam a/ebin/lists.beam b/ebin/b.beam Erlang is started and lists.beam from directory a is loaded. Then b.beam is loaded. b contains a call to lists:reverse/1. Will b get lists from a or stdlib-0/ebin ? I know which lists b want, but how does the erlang run time know? bengt On Wed, 2008-03-05 at 15:21 +0100, Richard Carlsson wrote: > Just to hammer down the point: the runtime system never sees > two different modules called lists. The import_as would cause > the names to be substituted at compile time. Atoms that are > not necessarily module names by context would either have to > be written fully qualified from start, or be wrapped in some > construct that marks them for expansion, such as: > > -import_as(foo, my_foo) > ... > f() -> > gen_server:start(i_am_a_module_name(foo), ...) > > (It would actually be a very good thing if all atoms that in > fact are used to name modules, would be marked up as such, in > one way or another. Dialyzer and other analyses would be much > helped by this. Currently, Erlang programs are way too liberally > sprinkled with random atoms which turn out to be a module name.) > > The basic point is: you never pass an atom that represents a > module name to anyone else unless it is already fully qualified. > > /Richard > > Bengt Kleberg wrote: > > Greetings, > > > > How does the erlang run time handle 2 modules called lists? > > > > Which lists module will those other modules that have not done > > -import_as(lists, stdlib_lists). > > get? > > > > > > bengt > > > > On Wed, 2008-03-05 at 21:23 +1100, Anthony Kong wrote: > >> Hi, Shiwei, > >> > >> I'd concur that a capability to alias an imported module sounds like > >> an attractive idea. > >> > >> I personally would prefer a new directive called "import_as". > >> > >> ====== > >> -module(lists). %% I want to call my module lists too. > >> -import_as(lists, stdlib_lists). > >> > >> ... > >> lists:copycat() -> > >> stdlib_lists:reverse([a,b,c]). %% essentially calling lists:reverse([a,b,c]) > >> > >> ====== > >> > >> Just the same as your idea of "-alias". > >> > >> Until then, I probably have to learn to live in this namespace flatland :-) > >> > >> Cheers, Anthony > >> > >> > >> > >> 2008/3/1 shiwei xu : > >>> I think flat module namespaces is a defect of erlang design. > >>> > >>> For example, I write a foo.erl, It works well. But maybe in a late erlang > >>> version (eg. R13B) also write such module named foo.erl. Then, you can > >>> see my application goes wrong. > >>> > >>> How to avoid things like this? Let's see the following ways: > >>> > >>> 1. Adjust module searching paths, and let user path (which contains my > >>> foo.erl) take precedence over erlang stdlib/otp path. But, this way can't > >>> always work well. If some other stdlib/otp modules use system foo.erl (not > >>> my foo.erl), Things goes wrong. > >>> > >>> 2. Write erlang modules always named with a prefix (a fake namespace. For > >>> example, projectname_foo.erl or organization_projectname_foo > >>> .erl). This way really can solve the problem. But, It seems ugly. > >>> > >>> Is there a way let's user still can call foo:func (not call foo.erl provied > >>> by stdlib/otp, but my projectname_foo.erl)? I have a suggestion: > >>> > >>> Can erlang provide a 'module name alias'? That is, I can rename a module's > >>> name temporarily in a module? For example: > >>> > >>> -module(a_module_that_call_my_foo). > >>> -alias(foo, organization_projectname_foo). %% alias > >>> > >>> some_func_call_foo() -> > >>> foo:func(). %% same as: organization_projectname_foo:func() > >>> > >>> Currently I can do this by using the 'define' keyword. For example: > >>> > >>> -module(a_module_that_call_my_foo). > >>> -define(FOO, organization_projectname_foo). %% alias > >>> > >>> some_func_call_foo() -> > >>> ?FOO:func(). > >>> > >>> It works well, but a bit ugly. > >>> > >>> > >>> > >>> On Sat, Mar 1, 2008 at 6:51 AM, Matt Stancliff wrote: > >>> > >>>> > >>>> > >>>> > >>>> > >>>> On Feb 29, 2008, at 14:34, Anthony Kong wrote: > >>>> > >>>>> If I rename c.erl to something else, the problem goes away. > >>>>> > >>>>> What is special about "-module(c)" ? > >>>> Welcome to the world of flat module namespaces. > >>>> > >>>> The code module is your friend in these circumstances. > >>>> Look into code:clash() and code:which(module). > >>>> > >>>> code:which(c) should return "/lib/erlang/lib/stdlib- > >>>> /ebin/c.beam" > >>>> > >>>> > >>>> -Matt > >>>> -- > >>>> Matt Stancliff sysop > >>>> AIM: seijimr iPhone: 678-591-9337 > >>>> "The best way to predict the future is to invent it." --Alan Kay > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions > >>>> http://www.erlang.org/mailman/listinfo/erlang-questions > >>>> > >>> > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questions > >>> http://www.erlang.org/mailman/listinfo/erlang-questions > >>> > >> > >> > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > From chsu79 Thu Mar 6 12:53:08 2008 From: chsu79 (Christian S) Date: Thu, 6 Mar 2008 12:53:08 +0100 Subject: [erlang-questions] Secondary Mnesia Table index In-Reply-To: References: <1218d6a50803051032i32ebb014ncc1919e29806f142@mail.gmail.com> Message-ID: > db> Would I be able query on not_so_unique_field with an > db> index based on tuple {unique_field, not_so_unique_field} ? > > Yes, if you put them in the same record field. The alternative approach is to have a second table that maps this compounded secondary key to the primary key. If I understand correctly, this is how ulf wiger's 'rdbm' project handles indexes (but makes it transparent the same way mnesia-indexes appear now). From bengt.kleberg Thu Mar 6 12:50:03 2008 From: bengt.kleberg (Bengt Kleberg) Date: Thu, 06 Mar 2008 12:50:03 +0100 Subject: [erlang-questions] how: Purging old records from Mnesia table In-Reply-To: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> References: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> Message-ID: <1204804203.8525.39.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, While only a small part of the total answer I would recommend that you could look into the module timer. It has apply_after/4 and it does not have the unsigned int problem. bengt On Thu, 2008-03-06 at 12:38 +0100, Gleb Peregud wrote: > Hello. > > I would like to implement some algorithm of purging old data from > mnesia table. Expiration date is written inside each record (could be > 0 for permanent data). > > I have few ideas how to implement it: > 0) Every few seconds iterate over whole table and purge old records. > It is implemented in this way now and it eats about 35% of CPU on > every purge cycle for about 10 000 entries. > Will index on expiration field speed up selecting? Is it better to use > qlc? Will it speed give speed up if i use mnesia:index_match_object() > ? > > 1) Use erlang:send_after() to send messages to purge individual > records (with special care to timeouts greater then max value of > unsigned int). Will Erlang runtime handle efficiently potentially up > to few millions of timers? > > 2) Use some sort of queue to manage sorted list of records to be > purged. Make special process which will receive information about new > records, insert into this queue and sleep until first record is to be > purged. Probably gb_trees will handle it. Are there better ADS for > this task? > > I'll be greateful for any advices and responses :) > > Best Regards, > -- > Gleb Peregud > http://gleber.pl/ > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From chsu79 Thu Mar 6 13:01:07 2008 From: chsu79 (Christian S) Date: Thu, 6 Mar 2008 13:01:07 +0100 Subject: [erlang-questions] how: Purging old records from Mnesia table In-Reply-To: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> References: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> Message-ID: On Thu, Mar 6, 2008 at 12:38 PM, Gleb Peregud wrote: > Hello. > > I would like to implement some algorithm of purging old data from > mnesia table. Expiration date is written inside each record (could be > 0 for permanent data). Maintain a second table updated as you insert records to this primary one. It could be a bag of records with the expiry-interval as the key. That way you would get less inefficient lookup of what records are to expire in the current interval you're in. From ulf.wiger Thu Mar 6 13:40:49 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Thu, 06 Mar 2008 13:40:49 +0100 Subject: [erlang-questions] how: docbuilder version tags in chapters Message-ID: <47CFE651.6060008@ericsson.com> I'd really like to have docbuilder recognize the and tags in the chapter DTD - not just in the surrounding (part) document. Is there any plan to support this? After all, the tags are in the DTD. It would be nice if they could also be made useful. BR, Ulf W From saleyn Thu Mar 6 13:44:02 2008 From: saleyn (Serge Aleynikov) Date: Thu, 06 Mar 2008 07:44:02 -0500 Subject: [erlang-questions] [erlang-patches] Running mnesia across a firewall In-Reply-To: <47CE9168.5090504@ericsson.com> References: <47CE1A4C.3020707@gmail.com> <47CE544C.7010700@ericsson.com> <47CE8D71.3090704@gmail.com> <47CE9168.5090504@ericsson.com> Message-ID: <47CFE712.20706@gmail.com> Ulf Wiger (TN/EAB) wrote: > Serge Aleynikov skrev: >> On which node, though? If this is one of the "master" nodes A holding >> a disk copy of a table X, then the node must have {dist_auto_connect, >> once} set. If the firewall prohibits inbound access to this node A >> from some other node C that uses remote mnesia interface to access >> table X, then the only way to establish connection to node C is to do >> on node A net_kernel:connect(C). However if that connection drops, >> there's no way to reestablish that connection without restarting node >> A. Remember that in case of {dist_auto_connect, once} net_kernel >> checks if a connection is barred and if it is it won't allow to >> connect to a node that previously was connected. > > Correction 1: It's net_kernel:connect_node(Node). My bad. > > Correction 2: net_kernel:connect_node/1 ignores the value of > dist_auto_connect > > What we've done is to keep a "maintenance channel" (not distr Erlang), > over which we can negotiate which node should restart. It turned out that was making the same mistake by using net_kernel:connect(Node) rather than net_kernel:connect_node(Node). Quite easy to get confused as two functions have the same signature. :-( Thanks for pointing this out! So for making mnesia work across a firewall a combination of kernel options including global_groups as well as user-level pinging/starting/stopping remote mnesia is sufficient. Serge From rapsey Thu Mar 6 14:03:29 2008 From: rapsey (Rapsey) Date: Thu, 6 Mar 2008 14:03:29 +0100 Subject: [erlang-questions] how: Purging old records from Mnesia table In-Reply-To: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> References: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> Message-ID: <97619b170803060503l7587c2d7y1e901366917cc1f1@mail.gmail.com> 0.1 - Iterate over the whole table slowly. use timer:sleep(delay_for_every_read). That's what I would do, since it's probably the simplest solution. Sergej On Thu, Mar 6, 2008 at 12:38 PM, Gleb Peregud wrote: > Hello. > > I would like to implement some algorithm of purging old data from > mnesia table. Expiration date is written inside each record (could be > 0 for permanent data). > > I have few ideas how to implement it: > 0) Every few seconds iterate over whole table and purge old records. > It is implemented in this way now and it eats about 35% of CPU on > every purge cycle for about 10 000 entries. > Will index on expiration field speed up selecting? Is it better to use > qlc? Will it speed give speed up if i use mnesia:index_match_object() > ? > > 1) Use erlang:send_after() to send messages to purge individual > records (with special care to timeouts greater then max value of > unsigned int). Will Erlang runtime handle efficiently potentially up > to few millions of timers? > > 2) Use some sort of queue to manage sorted list of records to be > purged. Make special process which will receive information about new > records, insert into this queue and sleep until first record is to be > purged. Probably gb_trees will handle it. Are there better ADS for > this task? > > I'll be greateful for any advices and responses :) > > Best Regards, > -- > Gleb Peregud > http://gleber.pl/ > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080306/063e7424/attachment-0001.html From hasan.veldstra Thu Mar 6 14:14:53 2008 From: hasan.veldstra (Hasan Veldstra) Date: Thu, 6 Mar 2008 13:14:53 +0000 Subject: [erlang-questions] ei and erl_interface linking problem on Ubuntu Message-ID: The following C program compiles without any troubles on two OSX machines (Tiger/PPC and Leopard/Intel), but fails to compile on an Ubuntu 7.10 machine. All machines have R12B. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #include "ei.h" int main() { ei_x_buff result; long x = 42; if(ei_x_new_with_version(&result) || ei_x_encode_tuple_header (&result, 2)) { return -1; } ei_x_encode_atom(&result, "ok"); ei_x_encode_long(&result, x); ei_x_free(&result); return 0; } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is how I compile the program on Macs: gcc-4.0 -I/opt/local/lib/erlang/lib/erl_interface-3.5.5.3/include - lpthread -L/opt/local/lib/erlang/lib/erl_interface-3.5.5.3/lib -lei - lerl_interface test.c And this is how I try to compile it on Ubuntu: gcc-4.1 -I/usr/lib/erlang/lib/erl_interface-3.5.5.3/include -lpthread -L/usr/lib/erlang/lib/erl_interface-3.5.5.3/lib -lei -lerl_interface test.c And this is the error I get: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tmp/cc26E8ki.o: In function `main': test.c:(.text+0x1f): undefined reference to `ei_x_new_with_version' test.c:(.text+0x36): undefined reference to `ei_x_encode_tuple_header' test.c:(.text+0x56): undefined reference to `ei_x_encode_atom' test.c:(.text+0x68): undefined reference to `ei_x_encode_long' test.c:(.text+0x73): undefined reference to `ei_x_free' collect2: ld returned 1 exit status ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Any pointers greatly appreciated. --Hasan From masterofquestions Thu Mar 6 14:55:25 2008 From: masterofquestions (db) Date: Thu, 6 Mar 2008 08:55:25 -0500 Subject: [erlang-questions] Secondary Mnesia Table index In-Reply-To: References: <1218d6a50803051032i32ebb014ncc1919e29806f142@mail.gmail.com> Message-ID: <1218d6a50803060555t536f6041mefd85738a3f0527e@mail.gmail.com> This is not an issue for me now (after plowing through the ml). In my mind, I have somehow made a false assumption that mnesia tab key is also used to create the index. Which is not the case. I can happily define index on not_so_unique_field and need for secondary mnesia table index goes away. thanks, -- rk That which we persist in doing becomes easier for us to do; not that the nature of the thing itself is changed, but that our power to do is increased. -Ralph Waldo Emerson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080306/7b3d2c6c/attachment.html From gleber.p Thu Mar 6 15:01:39 2008 From: gleber.p (Gleb Peregud) Date: Thu, 6 Mar 2008 15:01:39 +0100 Subject: [erlang-questions] how: Purging old records from Mnesia table In-Reply-To: <1204804203.8525.39.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> <1204804203.8525.39.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: <14f0e3620803060601m45d73c5di48377d14f11e4ee3@mail.gmail.com> On 3/6/08, Bengt Kleberg wrote: > Greetings, > > While only a small part of the total answer I would recommend that you > could look into the module timer. It has apply_after/4 and it does not > have the unsigned int problem. > > > bengt > > On Thu, 2008-03-06 at 12:38 +0100, Gleb Peregud wrote: > > Hello. > > > > I would like to implement some algorithm of purging old data from > > mnesia table. Expiration date is written inside each record (could be > > 0 for permanent data). > > > > I have few ideas how to implement it: > > 0) Every few seconds iterate over whole table and purge old records. > > It is implemented in this way now and it eats about 35% of CPU on > > every purge cycle for about 10 000 entries. > > Will index on expiration field speed up selecting? Is it better to use > > qlc? Will it speed give speed up if i use mnesia:index_match_object() > > ? > > > > 1) Use erlang:send_after() to send messages to purge individual > > records (with special care to timeouts greater then max value of > > unsigned int). Will Erlang runtime handle efficiently potentially up > > to few millions of timers? > > > > 2) Use some sort of queue to manage sorted list of records to be > > purged. Make special process which will receive information about new > > records, insert into this queue and sleep until first record is to be > > purged. Probably gb_trees will handle it. Are there better ADS for > > this task? > > > > I'll be greateful for any advices and responses :) > > > > Best Regards, > > -- > > Gleb Peregud > > http://gleber.pl/ > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > After checking source of timer module i can see it is implemented using ordered_set ets table. This table is used as a queue and gen_server module is pulling data at necessary moments (it is the same as my idea in point 3). It seems to be a good choice :) Hence it is enough to use timer:send_after() -- Gleb Peregud http://gleber.pl/ Every minute is to be grasped. Time waits for nobody. -- Inscription on a Zen Gong From ulf.wiger Thu Mar 6 15:25:16 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Thu, 06 Mar 2008 15:25:16 +0100 Subject: [erlang-questions] how: Purging old records from Mnesia table In-Reply-To: <14f0e3620803060601m45d73c5di48377d14f11e4ee3@mail.gmail.com> References: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> <1204804203.8525.39.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <14f0e3620803060601m45d73c5di48377d14f11e4ee3@mail.gmail.com> Message-ID: <47CFFECC.8090104@ericsson.com> Gleb Peregud skrev: > > After checking source of timer module i can see it is implemented > using ordered_set ets table. This table is used as a queue and > gen_server module is pulling data at necessary moments (it is the same > as my idea in point 3). It seems to be a good choice :) > > Hence it is enough to use timer:send_after() I don't know if it's what you're after, but I've been (slowly) working on a scheduler module based on mnesia. It's not ready, and wholly undocumented, but for those who enjoy source-as-documentation, the work in progress can be seen at: http://erlhive.svn.sourceforge.net/viewvc/erlhive/trunk/lib/erlhive/src/erlhive_schedule.erl?view=markup (It's in ErlHive, but there really isn't that much that's erlhive-specific about it.) The idea is that you should be able to register calendar-like 'appointments' - repeating if necessary - and tie them to actions that are fired at the right moment. BR, Ulf W From gleber.p Thu Mar 6 16:11:35 2008 From: gleber.p (Gleb Peregud) Date: Thu, 6 Mar 2008 16:11:35 +0100 Subject: [erlang-questions] how: Purging old records from Mnesia table In-Reply-To: <47CFFECC.8090104@ericsson.com> References: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> <1204804203.8525.39.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <14f0e3620803060601m45d73c5di48377d14f11e4ee3@mail.gmail.com> <47CFFECC.8090104@ericsson.com> Message-ID: <14f0e3620803060711p6b7f6cbdo87c2557f76d56656@mail.gmail.com> I'm working on simple caching server. Allowing to specify if and when item will expire. On 3/6/08, Ulf Wiger (TN/EAB) wrote: > Gleb Peregud skrev: > > > > After checking source of timer module i can see it is implemented > > using ordered_set ets table. This table is used as a queue and > > gen_server module is pulling data at necessary moments (it is the same > > as my idea in point 3). It seems to be a good choice :) > > > > Hence it is enough to use timer:send_after() > > I don't know if it's what you're after, but I've been (slowly) > working on a scheduler module based on mnesia. > > It's not ready, and wholly undocumented, but for those who > enjoy source-as-documentation, the work in progress can be > seen at: > > http://erlhive.svn.sourceforge.net/viewvc/erlhive/trunk/lib/erlhive/src/erlhive_schedule.erl?view=markup > > (It's in ErlHive, but there really isn't that much that's > erlhive-specific about it.) > > The idea is that you should be able to register calendar-like > 'appointments' - repeating if necessary - and tie them to actions that > are fired at the right moment. > > BR, > Ulf W > -- Gleb Peregud http://gleber.pl/ Every minute is to be grasped. Time waits for nobody. -- Inscription on a Zen Gong From erlang Thu Mar 6 18:02:20 2008 From: erlang (erlang) Date: Thu, 6 Mar 2008 14:02:20 -0300 (UYT) Subject: [erlang-questions] Mnesia log files - backup&restore and two schemas Message-ID: <15011602.1204822940303.JavaMail.tomcat@fe-ps02> Hi, I have two disc_copy nodes in a Mnesia schema (two machines at dbA) and a schema in another network with two disc_copy nodes (two machines at dbB). dbA can receive transactions (active) and dbB not (idle). What I need to do is to replicate Mnesia data from dbA to dbB at T time intervals. I have the following solutions in mind: 0) Using mnesia:dump_to_textfile and mnesia:load_from_textfile, but sometimes the dumping takes a very long time. 1) In an Incremental way using table events, but the subscription must be done in a disc_node needing a special work on a network failure. 2) Copying Mnesia log files, but I don?t clearly know if the . dcd files are sufficient for this and the number of transactions lost. Someone know about this or how to handle it the best way? Thanks, Eduardo From gbulmer Thu Mar 6 18:33:57 2008 From: gbulmer (G Bulmer) Date: Thu, 6 Mar 2008 17:33:57 +0000 Subject: [erlang-questions] Help: What's the correct way to add new BIFs? Message-ID: <657FD6DD-A7A4-410D-B43E-A2675047D047@gmail.com> I want to add a few new BIFs to erts for some DTrace experiments, and I'd like some pointers/advice. (They may not end up in the solution, so please don't panic yet:-) Is there a document which describes the correct approach? (I thought I'd seen it a few months ago, but I, google and spotlight can't find it :-( The questions I'd like some help/advice with are: 1. I read (in bif.tab) that ubifs are bif's without trace wrappers. Is this a critical decision, or is it okay to use ubifs, and decide later? 2. In the syntax description in bif.tab, its says: ::= "bif" [] | "ubif" [] ::= ":" "/" Actual examples are: ubif erlang:abs/1 ubif 'erl.lang.number':abs/1 ebif_abs_1 and bif erlang:binary_to_term/1 bif 'erl.lang.binary':to_term/1 ebif_binary_to_term_1 This example seems to define the same bif twice. What is this doing really? What is the atom 'erl.lang.number' or 'erl.lang.binary' for? (I've read the make_tables script, but my perl is bad, so it isn't clearto me, sorry.) Small point, I read the the syntax productions as is optional, but: bif erlang:atom_to_list/1 bif 'erl.lang.atom':to_string/1 ebif_atom_to_string_1 atom_to_list_1 has two. I think the syntax in the bif.tab comment maybe should read: ::= "bif" {} | "ubif" {} as {...} is conventionally 0 or more. 3. To be clean and tidy, I feel I should put our new bifs in a new set of source files (rather than mx them into the existing bif source files). Are there some naming conventions I should follow to align with the OTP team? I assume that the new bifs should be put in a section at the end of bif.tab. Thanks in advance for pointers/advice. G Bulmer From paul-trapexit Thu Mar 6 19:00:29 2008 From: paul-trapexit (Paul Mineiro) Date: Thu, 6 Mar 2008 10:00:29 -0800 (PST) Subject: [erlang-questions] how: Purging old records from Mnesia table In-Reply-To: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> References: <14f0e3620803060338y5b92de73r6b6bb45cbc590278@mail.gmail.com> Message-ID: gleb, lately i've been maintaining another mnesia table as an ordered_set with the expiration time as the first element in the tuple of the primary key. i then periodically iterate over that (with mnesia:first/1 and mnesia:next/2), terminating the iteration early when possible, which is most of the time. of course it means database modifications have to hit two tables, and unfortunately sometimes introduces the need for transactions where before dirty operations would do. so i'm eager to hear a better solution. -- p p.z. one thing not clear in your original post ... is this persistent data? cuz if so, timers and ets tables seem ill advised. On Thu, 6 Mar 2008, Gleb Peregud wrote: > Hello. > > I would like to implement some algorithm of purging old data from > mnesia table. Expiration date is written inside each record (could be > 0 for permanent data). > > I have few ideas how to implement it: > 0) Every few seconds iterate over whole table and purge old records. > It is implemented in this way now and it eats about 35% of CPU on > every purge cycle for about 10 000 entries. > Will index on expiration field speed up selecting? Is it better to use > qlc? Will it speed give speed up if i use mnesia:index_match_object() > ? > > 1) Use erlang:send_after() to send messages to purge individual > records (with special care to timeouts greater then max value of > unsigned int). Will Erlang runtime handle efficiently potentially up > to few millions of timers? > > 2) Use some sort of queue to manage sorted list of records to be > purged. Make special process which will receive information about new > records, insert into this queue and sleep until first record is to be > purged. Probably gb_trees will handle it. Are there better ADS for > this task? > > I'll be greateful for any advices and responses :) > > Best Regards, > -- > Gleb Peregud > http://gleber.pl/ > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > Optimism is an essential ingredient of innovation. How else can the individual favor change over security? -- Robert Noyce From vinoski Thu Mar 6 21:29:32 2008 From: vinoski (Steve Vinoski) Date: Thu, 6 Mar 2008 15:29:32 -0500 Subject: [erlang-questions] packages (was: newbie: why c.erl is special?) In-Reply-To: References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> <47CFB259.7040205@elte.hu> Message-ID: <65b2728e0803061229g2359b9a9xffe07d4ff5007fe7@mail.gmail.com> On 3/6/08, Sean Hinde wrote: > One of the worst aspects of this would be the endless traversing up > and down interminable directory hierarchies. Soon we would need a full > IDE just to help us find the definition of a module in the filesystem. YES! I was about to point out the same thing, and I'm very glad to know I'm not alone in my thinking. Java's abuse of the filesystem in this manner is very annoying, for example, and pushing Erlang to that model would be a huge mistake IMO. --steve From chandrashekhar.mullaparthi Thu Mar 6 22:27:31 2008 From: chandrashekhar.mullaparthi (Chandru) Date: Thu, 6 Mar 2008 21:27:31 +0000 Subject: [erlang-questions] Mnesia log files - backup&restore and two schemas In-Reply-To: <15011602.1204822940303.JavaMail.tomcat@fe-ps02> References: <15011602.1204822940303.JavaMail.tomcat@fe-ps02> Message-ID: On 06/03/2008, erlang wrote: > Hi, > > > > I have two disc_copy nodes in a Mnesia schema (two machines at dbA) > and a schema in another network with two disc_copy nodes (two machines > at dbB). > > dbA can receive transactions (active) and dbB not (idle). > > What I need to do is to replicate Mnesia data from dbA to dbB at T > time intervals. > If the table definitions are the same, you should be able to use mnesia:restore/2 to copy the contents of all/some of the tables. If you want to make sure that dbB is always an exact copy of dbA, then you can rename the nodes in the database backup you take from dbA (see example in mnesia user guide), and then do an mnesia:install_fallback. cheers Chandru From rvirding Thu Mar 6 22:39:43 2008 From: rvirding (Robert Virding) Date: Thu, 6 Mar 2008 22:39:43 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <17244f480803052358w365e9fdeneb740f3e0ddfd0b3@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <17244f480803052358w365e9fdeneb740f3e0ddfd0b3@mail.gmail.com> Message-ID: <3dbc6d1c0803061339q6356bc54h8d1e042abb84acbc@mail.gmail.com> On 06/03/2008, Yariv Sadan wrote: > > Hi, I think I found a bug in lfe_eval. > > I created the following macro: > > (define-syntax bar > (macro > ((vals) > (: lists map (lambda (x) (: io format '"~p~n" x)) vals) ()))) > > and the following function: > > (define (foo) > (bar (1 2 3))) > > When I call '(foo)' I get the following error: > > ** exception error: lfe_eval:'-eval_lambda/2-fun-0-'/2 called with one > argument > in function lists:map/2 > in call from lfe_eval:eval_body/2 > in call from lfe_macro:macro/3 > in call from lfe_macro:expand_tail/3 > in call from lfe_macro:expand/2 > in call from lfe_macro:expand_top_forms/2 > in call from lfe_macro:expand_top_forms/2 > in call from lfe_macro:expand_file/2 That's a bug, but it has now been fixed. I have released a patch on trapexit.org with a fix and a few other goodies. Also, can you please explain the difference between 'macro' and > 'syntax-rules'? 'macro' seems to do what I expect and I'm not sure > when syntax-rules would be a better option. 'syntax-rules' are simpler and are taken from Scheme. Each rule consists of (pattern expansion) where pattern is matched against the arguments of the macro call and the values of the variables from pattern are substituted into the expansion which is then returned. It is like a simple form of backquote macro where the only possible unquoting is symbol names. You can't "do" anything in the pattern except return it. So for example a simple recursive definition of let* (sequential let) would be: (define-syntax let* (syntax-rules ([(vb . vbs) . b] [let (vb) (let* vbs . b)]) ([() . b] [begin . b]))) Here I also use [...] as alternative to (...) to mark out the patterns and the expansion. Syntax-rules are useful when the macro can be written as a simple expansion, although there is not much difference in using macro with a simple backquote. See test_macro.lfe for an example of the same macro written in both ways. Macro needs the evaluator to evaluate the body while syntax-rules does not. I am thinking of changing the names to defsyntax and defmacro : (defsyntax let* (pat1 exp1) ... ) (defmacro let* (pat1 . body1) ... ) What does the "user community" feel about that? Having both under one define-syntax maybe a clearer way to express the intention though. Thanks, > > Yariv > Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080306/b64c1825/attachment.html From rvirding Thu Mar 6 22:43:09 2008 From: rvirding (Robert Virding) Date: Thu, 6 Mar 2008 22:43:09 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803021410j3cb1ea53s935c0669d82efd4b@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <3dbc6d1c0803021410j3cb1ea53s935c0669d82efd4b@mail.gmail.com> Message-ID: <3dbc6d1c0803061343w8d152e1td603b36d690f2da9@mail.gmail.com> First patch to LFE 0.1 has been added to trapexit.org, http://forum.trapexit.org/viewtopic.php?p=40619#40619. Apart from fixing the bug it also has: - Macro expansion now occurs in patterns - _ added as don't care variable to patterns as well as some internal code changes. Just unload it on top of the original files and recompile. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080306/a110a090/attachment.html From ok Thu Mar 6 23:03:23 2008 From: ok (Richard A. O'Keefe) Date: Fri, 7 Mar 2008 11:03:23 +1300 Subject: [erlang-questions] packages (was: newbie: why c.erl is special?) In-Reply-To: <47CFB259.7040205@elte.hu> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> <47CFB259.7040205@elte.hu> Message-ID: <87B5E982-D2AD-4532-825F-8E2167AC8D01@cs.otago.ac.nz> On 6 Mar 2008, at 9:59 pm, L?vei L?szl? wrote: > Richard A. O'Keefe wrote: >>> On Wed, Mar 05, 2008 at 12:21:30PM -0600, David Mercer wrote: >>> } If this is what everyone seems to want, why hasn't the package >>> notation >>> } caught on? >>> >> But *is* it what everyone wants? > > It seems to me (after reading the list archive) that everyone wants > this, only some people want even more.\ Let me offer an analogy: people want yummy food. they are offered seafloor ooze (which some organisms flourish on). I complain that I want real human food. It is suggested that people really want seafloor ooze, but some people want more. I say that the dotted package names not only don't solve most of our problems, they entrench problematic practice (package prefix = directory) and would make it much harder to provide a good solution later. In the mean time, life could get a lot simpler for people if they realised that .erl files don't have to be the very beginning of the build process (hint hint). From karol.skocik Fri Mar 7 00:21:52 2008 From: karol.skocik (karol skocik) Date: Fri, 7 Mar 2008 00:21:52 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803061339q6356bc54h8d1e042abb84acbc@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <17244f480803052358w365e9fdeneb740f3e0ddfd0b3@mail.gmail.com> <3dbc6d1c0803061339q6356bc54h8d1e042abb84acbc@mail.gmail.com> Message-ID: Yes, defsyntax & defmacro are definitely nicer. Also, 'begin' (progn) could be replaced with 'do', and other macros l do1/do2 (CL's progn1/progn2) would be nice. They are trivial with macros, having them built-in is about preventing dozens of 'common-utils' modules floating around doing the same basic stuff... Karol > I am thinking of changing the names to defsyntax and defmacro : > > (defsyntax let* > (pat1 exp1) > ... ) > > (defmacro let* > (pat1 . body1) > ... ) > > What does the "user community" feel about that? Having both under one > define-syntax maybe a clearer way to express the intention though. > Robert > From bcully Fri Mar 7 00:48:04 2008 From: bcully (Brian Cully) Date: Thu, 6 Mar 2008 18:48:04 -0500 Subject: [erlang-questions] packages (was: newbie: why c.erl is special?) In-Reply-To: <87B5E982-D2AD-4532-825F-8E2167AC8D01@cs.otago.ac.nz> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> <47CFB259.7040205@elte.hu> <87B5E982-D2AD-4532-825F-8E2167AC8D01@cs.otago.ac.nz> Message-ID: On 6-Mar-2008, at 17:03, Richard A. O'Keefe wrote: > In the mean time, life could get a lot simpler for people if they > realised that .erl files > don't have to be the very beginning of the build process (hint hint). Don't get me wrong: I hate package.names being tied to directories as well, and the idea of having to type foo.bar.baz:quux() every time i ref an external package would drive me up a wall. I /also/ like the M:F(A) style of external function call for code understandability, so "import" is not an ideal solution. Hell, I wish there wasn't an "import" directive at all, but that's for another day. However the only solution I can think of that's worse than that is one which destroys my ability to type C-c C-k in Emacs and do something useful. To that extent, any solution should probably be contained in the .erl itself, or on the outside a single-use bootstrap for loading a system (akin to asdf from CL land). I'm actually reasonably happy w/ the current system. It strikes a good balance between readability (M:F(A)) and writability (flat namespace). -bjc From rvirding Fri Mar 7 00:56:42 2008 From: rvirding (Robert Virding) Date: Fri, 7 Mar 2008 00:56:42 +0100 Subject: [erlang-questions] packages (was: newbie: why c.erl is special?) In-Reply-To: <65b2728e0803061229g2359b9a9xffe07d4ff5007fe7@mail.gmail.com> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> <47CFB259.7040205@elte.hu> <65b2728e0803061229g2359b9a9xffe07d4ff5007fe7@mail.gmail.com> Message-ID: <3dbc6d1c0803061556u67d38d80hfe08fbd5a1da3702@mail.gmail.com> On 06/03/2008, Steve Vinoski wrote: > > On 3/6/08, Sean Hinde wrote: > > One of the worst aspects of this would be the endless traversing up > > and down interminable directory hierarchies. Soon we would need a full > > IDE just to help us find the definition of a module in the filesystem. > > > YES! I was about to point out the same thing, and I'm very glad to > know I'm not alone in my thinking. Java's abuse of the filesystem in > this manner is very annoying, for example, and pushing Erlang to that > model would be a huge mistake IMO. One of our original goals, which is seldom mentioned today, was that we wanted to keep the language *simple*! Then many programmers in Ericsson, who were out potential users, were not very experienced and not well trained in the art/science of programming. This is one reason why features considered standard were added later. This may not have been a good design decision but it did result in a small simple base language. I have read on the net discussions about designing languages for the masses, or not. And, whatever its warts, a flat module system is easy to comprehend. If you call module foo there is only one module foo to which it can refer, irrespective of from where it is called. And you can always use naming conventions to handle the case of many modules in an application or sub-system. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080307/d236b67a/attachment.html From watson.timothy Fri Mar 7 02:34:01 2008 From: watson.timothy (Tim Watson) Date: Fri, 7 Mar 2008 01:34:01 +0000 Subject: [erlang-questions] Asynchronous port drivers Message-ID: <8fa878b90803061734qc8586ddya447256006a247a@mail.gmail.com> Hi all, I'm implementing a port driver for Erlang/OTP12B and I have a question. I want the driver to be able to process multiple concurrent requests. The way I'm dealing with the at the moment, is by responding to a port_command call in driver_output, unpacking the supplied buffer and passing it to driver_async along with a funtion to be called from a thread pool thread. I also pass a callback function to driver_async, which is getting called after the asynchronous processing takes place. In this callback function, I'm using driver_send_term to respond to the calling process. Here's my question(s): 1. Is the callback function I post to driver_async called from a thread pool thread or from the main emulator thread!? I'm hoping the latter. 2. Is it safe to open just one port to the driver and fire multiple concurrent requests at it using port_command!? Question 2 is the one I'm really concerned about. From what I can see in the documentation, port_command is a synchronous call. This is presumable thread safe on the erlang side (I hope). I'm planning on spawining a new process per request, letting that process call port_command and wait using receive for the response (driver_send_term is being supplied with the calling process' Pid, which I obtain within the driver_output callback using the driver_caller api call). Is this approach a safe one!? I ask only because I've noticed other people trying to implement production quality linked-in drivers are using a combination of driver_outputv and the driver queue (with it's delightful ErlIOVec and SysIOVec consuming functions) to deal with asynchronous requests. This approach looks complicated and (I'm guessing) makes writing portable code harder, from what I can see. Any assistance would be greatly appreciated! Thanks, Tim Watson From fritchie Fri Mar 7 03:56:41 2008 From: fritchie (Scott Lystig Fritchie) Date: Thu, 06 Mar 2008 20:56:41 -0600 Subject: [erlang-questions] how: Purging old records from Mnesia table In-Reply-To: Message of "Thu, 06 Mar 2008 16:11:35 +0100." <14f0e3620803060711p6b7f6cbdo87c2557f76d56656@mail.gmail.com> Message-ID: <51700.1204858601@snookles.snookles.com> A few messages ago, someone said: >> > Hence it is enough to use timer:send_after() Gleb Peregud wrote: gp> I'm working on simple caching server. Allowing to specify if and gp> when item will expire. When having the expiration even sent by a 2nd party, you must avoid race conditions somehow. Example: Store tuple {Key, Value0}, expires at time T. Time T arrives Client stores {Key, Value1}, expires at time T2 Server deletes Key Client attempts to fetch Key, fetch fails, client is sad. -Scott From ok Fri Mar 7 04:32:54 2008 From: ok (Richard A. O'Keefe) Date: Fri, 7 Mar 2008 16:32:54 +1300 Subject: [erlang-questions] Some comments on EEP 9 (binary: module) In-Reply-To: References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> <47CFB259.7040205@elte.hu> <87B5E982-D2AD-4532-825F-8E2167AC8D01@cs.otago.ac.nz> Message-ID: <622AF7B5-4B5F-4B81-9586-31A2F67E0B53@cs.otago.ac.nz> 1. Given that the module for lists is called 'lists', not 'list', it is rather confusing that the module for binaries is called 'binary', instead of the expected 'binaries'. On the other hand, given that the module for strings is called "string", maybe it's 'lists' that has the wrong name. Something needs to be done about naming consistency in modules for data types. 2. What do you return if you look for something and it isn't there? For some reason, people seem to like returning an out-of-range index at the wrong end. BASIC does this, Smalltalk does it, but that does not make it right. Life gets *so* much simpler if match(Haystack, Needle) returns an index past the *right* end of the haystack. Suppose, for example, we have input with an optional comment; we want to remove it. [Mind you, EEP 9 is handicapped by starting from a system where binary slicing uses just about the worst possible convention, but that is another and sadder story.] [Oh yes, the documentation for the erlang: module gets erlang:split_bionary/2 wrong. It says that the range for Pos is 1..size(Bin), but 0 is *rightly* allowed. Pos is actually the size of the first part, which is just right.] Example. Suppose we are given a line of text from some configuration file as a binary. It might contain a # comment or it might not. Our only interest is in getting rid of it. In a rational design, where match(Haystack, Needle) returns the length of the longest prefix of Haystack *not* containing Needle, we just do {Wanted,_} = split_binary(Given, match(Given, <<"#">>)) With the scheme actually proposed, we have to do case match(Given, <<"#">>) of 0 -> Wanted = Given ; N -> {Wanted,_} = split_binary(Given, N-1) end 3. I appreciate that slicing binaries is supposed to be cheap, but I still think it would be nice if match had a 3rd argument, saying how many bytes at the beginning of Haystack to skip. If it weren't 4pm on a Friday with my office floor still to tidy up, I could give examples of why this can make life simpler. 4. I agree that the proposed binary:split/2 function is useful, but the name is far too close to split_binary/2 for comfort. A longer name such as binaries:split_with_separator(Binary, Separator_Binary) might make for less confusion. Better still, why not make this like string:tokens/2, which really has exactly the same purpose except for the data type it applies to? 5. Ever since I met SNOBOL 4, I have known the operation of removing outer blanks from a string as trimmming. It's a little odd to find it called stripping. By analogy with ecdysiasis (hem hem) I would expect stripping to remove visible outer stuff. I wish string:strip/[1,2,3] could be renamed. 6. In the functions unsigned_to_bin/1 bin_to_unsigned/1 why is the word "binary" abbreviated to "bin"? 7. "nth" is a very strange name for a substring operation. I would prefer subbinary(Binary, Offset[, Length]) 0 =< Offset =< byte_size(Binary) 0 =< Length =< byte_size(Binary) - Offset which would make this compatible with the existing split_binary(Binary, Offset) function. While I have been picky about some of the details, it seems to me that this is a good beginning in a good direction. From saleyn Fri Mar 7 04:46:57 2008 From: saleyn (Serge Aleynikov) Date: Thu, 06 Mar 2008 22:46:57 -0500 Subject: [erlang-questions] Asynchronous port drivers In-Reply-To: <8fa878b90803061734qc8586ddya447256006a247a@mail.gmail.com> References: <8fa878b90803061734qc8586ddya447256006a247a@mail.gmail.com> Message-ID: <47D0BAB1.1030508@gmail.com> Tim Watson wrote: > Here's my question(s): > > 1. Is the callback function I post to driver_async called from a > thread pool thread or from the main emulator thread!? I'm hoping the > latter. All callbacks are always executed synchronously from the main emulator thread(s). > 2. Is it safe to open just one port to the driver and fire multiple > concurrent requests at it using port_command!? I assume you are talking about running emulator with SMP mode enabled. In this case the driver_entry's callback corresponding to port_call may obviously be called from different emulator's threads. However, since the driver_entry's callbacks (including (*call)(...)) are synchronized access to the driver should be thread-safe. > I'm planning on spawining a new process per request, letting that > process call port_command and wait using receive for the response > (driver_send_term is being supplied with the calling process' Pid, > which I obtain within the driver_output callback using the > driver_caller api call). > > Is this approach a safe one!? Indeed, and likely being more efficient as it avoids extra copying of data. > I ask only because I've noticed other > people trying to implement production quality linked-in drivers are > using a combination of driver_outputv and the driver queue (with it's > delightful ErlIOVec and SysIOVec consuming functions) to deal with > asynchronous requests. This approach looks complicated and (I'm > guessing) makes writing portable code harder, from what I can see. Perhaps someone else could comment on this, but it looks like the driver design went through several stages of refactoring and multiple data-passing interfaces are perhaps artifacts of backward-compatibility. Serge From jay Fri Mar 7 07:35:43 2008 From: jay (Jay Nelson) Date: Thu, 6 Mar 2008 22:35:43 -0800 Subject: [erlang-questions] Microsoft Singularity Research OS Message-ID: Microsoft has a "new concept" for OS research. It is an operating system written in C#. ?Our goal was to make Singularity small enough, simple enough, and well-designed enough that you can try out radical new ideas quickly,? Hunt says. ?Our thinking is that a researcher with a great new idea for improving operating systems could get from idea to published paper in under a year using Singularity.? There are three main principles behind the OS: 1) Software-isolated processes (SIPs) "Singularity pioneers the use of software-isolated processes (SIPs) to help protect programs and system services. SIPs enable programs to be broken down into components that are isolated from other software components running on the same device. This enables pieces of a system to fail without risking a total system failure. Consider this analogy: In a car, the brakes don?t fail if the radio stops working." 2) Contract-based channels for communicating among SIPs ?We figured out how to describe the form in which communications should take place between two processes, and using static analysis, we can check the codes of the processes at compile time,? Hunt explains. ?So before the code ever runs, we can confirm that the processes communicate correctly.? 3) Manifest-based programs with resources describing the structure ?We basically say, if you want to install a program to run on a Singularity system, you have to provide some information about it so we can preserve certain properties that make the system more reliable,? Larus explains. ?You have to provide a manifest of the program pieces and how they fit together, and we?re going to check it. More important, we reserve the right to say ?no.? If a certain program doesn?t follow the rules set down for the system, you can?t install or run it.? jay From jay Fri Mar 7 07:41:55 2008 From: jay (Jay Nelson) Date: Thu, 6 Mar 2008 22:41:55 -0800 Subject: [erlang-questions] Microsoft Singularity Research OS Message-ID: Forgot the link: http://research.microsoft.com/displayArticle.aspx?id=1922 From per.gustafsson Fri Mar 7 09:43:47 2008 From: per.gustafsson (Per Gustafsson) Date: Fri, 07 Mar 2008 09:43:47 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> Message-ID: <47D10043.4090703@it.uu.se> Very good work, but I do have some comments: Just as for lists and strings I think that there should be two different modules one which just operates on binaries and one that operates on binaries which are really strings. This module seems to be first of these two for the most part so functions that only makes sense if the binaries are strings should probably reside in some other module. The string_as_binary module could have more or less exactly the same API as string and similar modules could be defined for utf8, utf16 and utf32 if necessary. * to_upper(Binary1) -> Binary2 to_lower(Binary1) -> Binary2 Should be in the string_as_binary module * binary_to_atom(Binary) -> Atom atom_to_binary(Atom) -> Binary As you write these should probably be in the erlang module along with binary_to_existing_atom(Binary) -> Atom * unsigned_to_bin(Integer)-> Binary What does this function do? Does it create the shortest possible binary in which the unsigned integer would fit? better names might be binary:from_unsigned(Integer) -> Binary binary:to_unsigned(Binary) -> Integer * nth(N, Bin) -> Value To also satisfy 0-indexers there should probably be a nth0(N, Bin) -> Value just as in the lists module Per From adam Fri Mar 7 10:22:15 2008 From: adam (Adam Lindberg) Date: Fri, 7 Mar 2008 10:22:15 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <47D10043.4090703@it.uu.se> References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D10043.4090703@it.uu.se> Message-ID: <6344005f0803070122w2be77c3dt51d817abce68bf98@mail.gmail.com> Please name the module 'bstring' in instead of 'string_as_binary'. :-) Cheers! Adam On Fri, Mar 7, 2008 at 9:43 AM, Per Gustafsson wrote: > Very good work, but I do have some comments: > > Just as for lists and strings I think that there should be two different > modules one which just operates on binaries and one that operates on > binaries which are really strings. This module seems to be first of > these two for the most part so functions that only makes sense if the > binaries are strings should probably reside in some other module. The > string_as_binary module could have more or less exactly the same API as > string and similar modules could be defined for utf8, utf16 and utf32 if > necessary. > > * to_upper(Binary1) -> Binary2 > to_lower(Binary1) -> Binary2 > > Should be in the string_as_binary module > > > * binary_to_atom(Binary) -> Atom > atom_to_binary(Atom) -> Binary > > As you write these should probably be in the erlang module along with > > binary_to_existing_atom(Binary) -> Atom > > > * unsigned_to_bin(Integer)-> Binary > > What does this function do? Does it create the shortest possible binary > in which the unsigned integer would fit? > > better names might be > > binary:from_unsigned(Integer) -> Binary > binary:to_unsigned(Binary) -> Integer > > * nth(N, Bin) -> Value > > To also satisfy 0-indexers there should probably be a > > nth0(N, Bin) -> Value > > just as in the lists module > > > Per > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080307/9f939ddf/attachment.html From saleyn Fri Mar 7 13:41:59 2008 From: saleyn (Serge Aleynikov) Date: Fri, 07 Mar 2008 07:41:59 -0500 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> Message-ID: <47D13817.8050604@gmail.com> In addition to what others already have said, this function would be helpful: binary:join(List, Delim) -> binary() where: List = [binary()] | [string()] Delim = binary() | string() Examples: > binary:join([<<"abc">>, <<"def">>], <<$|>>). <<"abc|def">> > binary:join(["abc", "def"], [$|]). <<"abc|def">> Very good work! Regards, Serge Fredrik Svahn wrote: > Thanks for the positive response both here an on the EEPs mailing list! > > My suggestion is that we continue the discussion regarding EEP-9 here > on the erlang-questions mailing list since it has a broader audience > than eeps I think it would make it a lot easier if we can > keep it in this thread. > > For those who do not subscribe to the eeps mailing list, I would like > to once again stress that this EEP does not cover improvements which > requires changes to the compiler. It has been suggested to me that the > smaller the EEP the faster it gets implemented so let us please keep > the scope as narrow as possible. There is always room for new EEPs. > > A shortcut to EEP-9: http://www.erlang.org/eeps/eep-0009.html > > Now, to answer your questions: > >> 1) Can the reference implementation be made available publicly as a >> patch to R12B-1? (Or actually in any fashion would be great.) > > The reference implementation in erlang is attached, the c part will > follow in the next message as there is a maximum message size on > erlang-questions. It matches the described functions minus what was > added after a first round of comments from the OTP developers (the > regexps for instance are probably going to have many more features > after what I hear!). I may also have added one or two relatively > simple functions, e.g. atom_to_binary, after the implementation was > submitted. > >> 2) Which algorithm was choosen for the binary:match()? For multiple >> keyword, Aho-Corasick would be great, especially if the interface was >> something like this: > > In the reference implementation Aho-Corasick was indeed used for > multiple keywords. Boyer-Moore was a logical choice for single > keywords and there was even a brute force approach for short > keywords/searchstrings. > >> MatchContext = binary:match_compile( [<<"the">>, <<"big">>, >> <<"frog">>] ), >> Value = <<"when we had a frog, he was big">>, >> [{3, 14}, {2, 27}] = binary:match( MatchContext, Value ) > > Thanks for the comment. I think it makes a lot of sense to have a > separation of the building of the trie and the actual searching as you > suggest, especially if you are searching many binaries for the same > keyword(s). I am not sure how easy it would be to implement it, > though. I guess the returned match context would have to be some kind > of reference or packed in a binary. Maybe someone from the OTP team > could comment on that. I actually wanted to have the same thing for > regular expressions. > > I note that you also want a function which returns all the matches not > just the first one. Given that binary:match/3 takes indexes of the > start and end position of the search it is easy to also add a function > "binary:matches/2" in binary.erl which returns all the matches by > repeatedly calling match/3. Having both "match/2" and "matches/2" > would be similar to how it is done in the regexp module. > > BR /Fredrik > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From gleber.p Fri Mar 7 15:13:27 2008 From: gleber.p (Gleb Peregud) Date: Fri, 7 Mar 2008 15:13:27 +0100 Subject: [erlang-questions] how: Purging old records from Mnesia table In-Reply-To: <51700.1204858601@snookles.snookles.com> References: <14f0e3620803060711p6b7f6cbdo87c2557f76d56656@mail.gmail.com> <51700.1204858601@snookles.snookles.com> Message-ID: <14f0e3620803070613x3b52cacas93879b7cbfe6600b@mail.gmail.com> On Thu, Mar 6, 2008 at 7:00 PM, Paul Mineiro wrote: > lately i've been maintaining another mnesia table as an ordered_set with > the expiration time as the first element in the tuple of the primary key. > i then periodically iterate over that (with mnesia:first/1 and > mnesia:next/2), terminating the iteration early when possible, which is > most of the time. > > of course it means database modifications have to hit two tables, and > unfortunately sometimes introduces the need for transactions where before > dirty operations would do. > > so i'm eager to hear a better solution. > > p.z. one thing not clear in your original post ... is this persistent > data? cuz if so, timers and ets tables seem ill advised. Caching server, which i'm working on, would be able to store data in either ways. User will specify if: 1) Record will not expire (user is responsible for purging it) 2) Record will expire in arbitrary number of seconds 3) Record will expire at given date (user will have to pass unix timestamp) (expire field = Of course i'm not going to use any timers for data which will never expire :) And, as it can be seen in timer module's source, it is implemented in exacly the same way as you did it in your application. timer is using ets ordered_set table for storing ordered list of events which are going to be launched at given time. After handling some event it will fetch the first item from table and sleep appropriate time, and so on. On Fri, Mar 7, 2008 at 3:56 AM, Scott Lystig Fritchie wrote: > When having the expiration even sent by a 2nd party, you must avoid race > conditions somehow. Example: > > Store tuple {Key, Value0}, expires at time T. > Time T arrives > Client stores {Key, Value1}, expires at time T2 > Server deletes Key > Client attempts to fetch Key, fetch fails, client is sad. Thanks for the hint. I will store timer's "handle" in every record to be able to cancel it :) -- Gleb Peregud http://gleber.pl/ Every minute is to be grasped. Time waits for nobody. -- Inscription on a Zen Gong From dmercer Fri Mar 7 18:09:23 2008 From: dmercer (David Mercer) Date: Fri, 7 Mar 2008 11:09:23 -0600 Subject: [erlang-questions] packages (was: newbie: why c.erl is special?) In-Reply-To: <3dbc6d1c0803061556u67d38d80hfe08fbd5a1da3702@mail.gmail.com> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP><20080305192807.GP66069@h216-235-12-172.host.egate.net><36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz><47CFB259.7040205@elte.hu><65b2728e0803061229g2359b9a9xffe07d4ff5007fe7@mail.gmail.com> <3dbc6d1c0803061556u67d38d80hfe08fbd5a1da3702@mail.gmail.com> Message-ID: <010301c88075$fe8afe30$891ea8c0@SSI.CORP> Maybe we should name all our modules with a GUID. That would reduce the likelihood of module name clashes down close to zero. J Cheers, DBM _____ From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Robert Virding Sent: Thursday, March 06, 2008 17:57 To: Steve Vinoski Cc: erlang-questions Subject: Re: [erlang-questions] packages (was: newbie: why c.erl is special?) On 06/03/2008, Steve Vinoski wrote: On 3/6/08, Sean Hinde wrote: > One of the worst aspects of this would be the endless traversing up > and down interminable directory hierarchies. Soon we would need a full > IDE just to help us find the definition of a module in the filesystem. YES! I was about to point out the same thing, and I'm very glad to know I'm not alone in my thinking. Java's abuse of the filesystem in this manner is very annoying, for example, and pushing Erlang to that model would be a huge mistake IMO. One of our original goals, which is seldom mentioned today, was that we wanted to keep the language *simple*! Then many programmers in Ericsson, who were out potential users, were not very experienced and not well trained in the art/science of programming. This is one reason why features considered standard were added later. This may not have been a good design decision but it did result in a small simple base language. I have read on the net discussions about designing languages for the masses, or not. And, whatever its warts, a flat module system is easy to comprehend. If you call module foo there is only one module foo to which it can refer, irrespective of from where it is called. And you can always use naming conventions to handle the case of many modules in an application or sub-system. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080307/0b1e0e34/attachment.html From dmercer Fri Mar 7 18:18:24 2008 From: dmercer (David Mercer) Date: Fri, 7 Mar 2008 11:18:24 -0600 Subject: [erlang-questions] packages (was: newbie: why c.erl is special?) References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP><20080305192807.GP66069@h216-235-12-172.host.egate.net><36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz><47CFB259.7040205@elte.hu><65b2728e0803061229g2359b9a9xffe07d4ff5007fe7@mail.gmail.com> <3dbc6d1c0803061556u67d38d80hfe08fbd5a1da3702@mail.gmail.com> Message-ID: <010801c88077$40ab70a0$891ea8c0@SSI.CORP> You know, I sent this in jest, but now that I think about it, it's not such a bad idea. You can define a macro giving a better name for the module so you don't have to keep using the GUID. Howzat? -define(stringlib, 'a613fd8b-647c-4b1a-9f4c-810f0b99993a') . . . ?stringlib:reverse(.) DBM _____ From: David Mercer [mailto:dmercer] Sent: Friday, March 07, 2008 11:09 To: 'erlang-questions' Subject: RE: [erlang-questions] packages (was: newbie: why c.erl is special?) Maybe we should name all our modules with a GUID. That would reduce the likelihood of module name clashes down close to zero. J Cheers, DBM _____ From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Robert Virding Sent: Thursday, March 06, 2008 17:57 To: Steve Vinoski Cc: erlang-questions Subject: Re: [erlang-questions] packages (was: newbie: why c.erl is special?) On 06/03/2008, Steve Vinoski wrote: On 3/6/08, Sean Hinde wrote: > One of the worst aspects of this would be the endless traversing up > and down interminable directory hierarchies. Soon we would need a full > IDE just to help us find the definition of a module in the filesystem. YES! I was about to point out the same thing, and I'm very glad to know I'm not alone in my thinking. Java's abuse of the filesystem in this manner is very annoying, for example, and pushing Erlang to that model would be a huge mistake IMO. One of our original goals, which is seldom mentioned today, was that we wanted to keep the language *simple*! Then many programmers in Ericsson, who were out potential users, were not very experienced and not well trained in the art/science of programming. This is one reason why features considered standard were added later. This may not have been a good design decision but it did result in a small simple base language. I have read on the net discussions about designing languages for the masses, or not. And, whatever its warts, a flat module system is easy to comprehend. If you call module foo there is only one module foo to which it can refer, irrespective of from where it is called. And you can always use naming conventions to handle the case of many modules in an application or sub-system. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080307/2bf0a081/attachment.html From bbrown Fri Mar 7 18:44:24 2008 From: bbrown (bbrown) Date: Fri, 7 Mar 2008 12:44:24 -0500 Subject: [erlang-questions] Issue with my simple server, accept not accepting connections Message-ID: <20080307173522.M59127@www.botspiritcompany.com> Hello, this kind of a long post (lot of code) and maybe I need to simplify my code but I am writing a simple tcp server and maybe you see something that is totally off. I have one application module and a server module (a type of middle-man) and then the client-handler module. Everything gets called correctly, but I can't connect to the server. I get a connection refused for example if This is my server library as a gen_server module. The key code is here and my issue. When I try to connect to the server, it looks like it never calls the code after "accept". I get to this line: io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]) But I don't get to this line after the accept call: io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), ----------------- io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]), ClientSock = server_accept(ServSock), io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), ----------------- server_accept(ServSock) -> { ok, ClientSock } = gen_tcp:accept(ServSock), ClientSock. ----------------- handle_call(irc_server_bind, _From, #server_state{client=Client } = State) -> Port = Client#irc_server_info.port, io:format("trace: lib:handle_call:bind Port:<~p>~n", [Port]), {ok, ServSock} = server_bind(Port), {reply, ok, State#server_state{serv_sock=ServSock, state=connecting}}; handle_call(irc_accept_clients, _From, #server_state{serv_sock=ServSock, app_handler=AppHandler } = State) -> io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]), ClientSock = server_accept(ServSock), io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), { ok, ClientServ } = client_handler:start_link(), % Assign a new controlling process. gen_tcp:controlling_process(ClientSock, ClientServ), inet:setopts(ClientSock, [{packet, 0}, binary, {nodelay, true},{active, false}]), % Invoke gen_server:cast to handle the socket {reply, ok, State}; handle_call(get_cur_state, _From, #server_state{} = State) -> % Generic method to get the current state. io:format("trace: lib:handle_call:get_cur_state~n"), {reply, {ok, State}, State}. terminate(_Reason, #server_state{client=Client}) -> io:format("trace: lib:terminate reason:[~p]~n", [_Reason]), ok; terminate(shutdown, #server_state{client=Client}) -> io:format("trace: lib:terminate.shutdown~n"), ok. handle_info(server_timeout, #server_state{client=Client} = State) -> io:format("trace: lib:handle_info.server_timeout"), %{noreply, State#server_state{state=timeout, connection_timeout=undefined}}. {noreply, State}. server_listen(ServLib) -> io:format("trace: lib:server listen [~p]~n", [ServLib]), % Synchronous gen_server call gen_server:call(ServLib, irc_server_bind). %% Accept call and then cast to handle new client server_accept_call(ServLib) -> io:format("trace: lib:server accept new client~n"), gen_server:call(ServLib, irc_accept_clients). get_cur_state(ServLib) -> io:format("trace: lib:get_cur_state: pid:[~p] ~n", [ServLib]), % Return: {ok, State} gen_server:call(ServLib, get_cur_state). server_bind(Port) -> io:format("trace: attempting to bind server... [~p]~n", [Port]), gen_tcp:listen(Port, [binary, {packet, 0}, {active, false}]). server_accept(ServSock) -> { ok, ClientSock } = gen_tcp:accept(ServSock), ClientSock. connection_timeout() -> % Time out delay of 1 minute 600000. ---------------- start_test_serv() -> io:format("Running functional test~n"), % Ensure that the app_handler is associcated with this app process Client = #irc_server_info{app_handler=self()}, Pid = start(Client), io:format("trace: start server, handler:~p ~n", [Pid]), % Wait a couple of seconds and then send messages to wait_for_clients. timer:sleep(500), init_accept_clients(), % Pass the pid of the server handler process. wait_for_clients(Pid), io:format("Done~n"). wait_for_clients(ServHandler) -> io:format("trace: app: wait_for_clients~n"), receive Anything -> % Application process is ready to accept new clients io:format("trace: app: wait_messages:accept ~n"), accept_clients(ServHandler), wait_for_clients(ServHandler) after connection_timeout() + 20000 -> io:format("INFO: Timed out~n") end. ----------------- Here is my server handler code. server_handler(Client) -> ServStart = server_lib:start_link(Client), case ServStart of { ok, P } -> io:format("trace: app:server pid/lib [~p]~n", [P]), server_lib:server_listen(P), State = server_lib:get_cur_state(P), % io:format("trace: app:server state [~p]~n", [State]), server_handler(#serv_handler_info{lib_handler=P}, idle) end. server_handler(ServClient, idle) -> ServLib = ServClient#serv_handler_info.lib_handler, io:format("trace: [!] at server_handler.idle [~p]~n", [ServLib]), receive { ready_accept } -> % Application process is ready to accept new clients io:format("trace: app: wait_messages:accept ~n"), % Launch initial accept clients block AcceptCall = server_lib:server_accept_call(ServLib), io:format("!!!-->~p~n", [AcceptCall]), case AcceptCall of { ok, State } -> io:format("poo~n") end, server_handler(ServClient, idle); Error -> io:format("trace: [!] app:error.proceeed: ~p~n", [Error]), server_handler(ServClient, idle) after connection_timeout() -> io:format("trace: [!] at server_handler. TIMEOUT ~n"), server_handler(ServClient, idle) end. accept_clients(ServHandler) -> % Start waiting accept new client connections. ServHandler ! {ready_accept}. init_accept_clients() -> % Start waiting accept new client connections. self() ! {init_accept}. ----------------- And if you are really curious; here is the source in subversion: http://openbotlist.googlecode.com/svn/trunk/botlistprojects/laughingman/test/ircserver/src/ -- Berlin Brown email: berlin-dot-brown-AT-gmail-dot-com http://botspiritcompany.com/botlist/ From rec Fri Mar 7 19:06:05 2008 From: rec (Roger Critchlow) Date: Fri, 7 Mar 2008 11:06:05 -0700 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <6344005f0803070122w2be77c3dt51d817abce68bf98@mail.gmail.com> References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D10043.4090703@it.uu.se> <6344005f0803070122w2be77c3dt51d817abce68bf98@mail.gmail.com> Message-ID: <66d1c98f0803071006x54e8ecc2u2cad5ccd88272da3@mail.gmail.com> 2008/3/7 Adam Lindberg : > Please name the module 'bstring' in instead of 'string_as_binary'. :-) > > Please name the module with an unabbreviated description of its purpose.. Those who need a shorter name can -define(bs, string_as_binary). -- rec -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080307/7d4ed0d8/attachment.html From rec Fri Mar 7 19:34:17 2008 From: rec (Roger Critchlow) Date: Fri, 7 Mar 2008 11:34:17 -0700 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <66d1c98f0803071006x54e8ecc2u2cad5ccd88272da3@mail.gmail.com> References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D10043.4090703@it.uu.se> <6344005f0803070122w2be77c3dt51d817abce68bf98@mail.gmail.com> <66d1c98f0803071006x54e8ecc2u2cad5ccd88272da3@mail.gmail.com> Message-ID: <66d1c98f0803071034t33f1be99re7961b0fbe5e1274@mail.gmail.com> Oh, I see, old joke. -- rec -- On Fri, Mar 7, 2008 at 11:06 AM, Roger Critchlow wrote: > > > 2008/3/7 Adam Lindberg : > > > Please name the module 'bstring' in instead of 'string_as_binary'. :-) > > > > Please name the module with an unabbreviated description of its > purpose.. > > Those who need a shorter name can -define(bs, string_as_binary). > > -- rec -- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080307/cb3ebea5/attachment.html From thomasl_erlang Fri Mar 7 19:33:33 2008 From: thomasl_erlang (Thomas Lindgren) Date: Fri, 7 Mar 2008 10:33:33 -0800 (PST) Subject: [erlang-questions] packages (was: newbie: why c.erl is special?) In-Reply-To: <010801c88077$40ab70a0$891ea8c0@SSI.CORP> Message-ID: <642986.38346.qm@web38811.mail.mud.yahoo.com> --- David Mercer wrote: > You know, I sent this in jest, but now that I think > about it, it's not such > a bad idea. You can define a macro giving a better > name for the module so > you don't have to keep using the GUID. Howzat? > > > > -define(stringlib, > 'a613fd8b-647c-4b1a-9f4c-810f0b99993a') > > . . . > > ?stringlib:reverse(.) For what it's worth, I tend to use ?mod:f(X) when I'm trying out multiple implementations of some facility. A poor man's parametrized modules, in way. When I wrote a cross-module optimizer (EUC'01), I used a variant of the above GUID technique for renaming _records_, which got rid of a big practical problem: record name clashes. Adding the hash of the code to your beam file is probably a good principle too. So I'm basically with you :-) Best, Thomas ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From toby Fri Mar 7 22:29:30 2008 From: toby (Toby Thain) Date: Fri, 7 Mar 2008 16:29:30 -0500 Subject: [erlang-questions] Use of makefiles In-Reply-To: <1204796240.8525.25.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <053657FB-5463-4F29-9FD1-32D83CCC3B4C@telegraphics.com.au> <1204703909.8234.14.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <077D18BE-4E02-4643-82E9-BBB040893467@cs.otago.ac.nz> <1204796240.8525.25.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: On 6-Mar-08, at 4:37 AM, Bengt Kleberg wrote: > Greetings, > > You are correct. If we want to build C programs the different C > compilers are more of a problem than perl or make incompatibilities. Only in highly unusual projects. Make can help abstract this in several ways, firstly the name of the system compiler ($(CC), $(CXX)). OT by now though. --Toby > You > suggestion that erlang could help with C compilation is a very good > one. > > Thanks for explaining perl to me. It sounds as bad as make. > > Building erlang programs is, IMHO, best done with erl -make. Users are > more interested in having later versions of the program they are > really > working with. Make/Perl is only secondary in this scenario. > > > bengt > > On Thu, 2008-03-06 at 11:51 +1300, Richard A. O'Keefe wrote: >> On 5 Mar 2008, at 8:58 pm, Bengt Kleberg wrote: >>> The question I asked was if a perl program would be more likely >>> to run >>> on ''any'' machine, than a makefile. Not because the person who >>> wrote >>> the makefile forgot/failed to read the manual for gnu make, but >>> because >>> there are other make programs than gnu make out there. The 4 ones I >>> have >>> used where not compatible. They would not run each others makefiles. >> >> If you stick to what's described in the original Make paper, every >> Make I >> have ever come across (save on Windows) is compatible with that. >> I try >> to stick to what's described in the Single Unix Specification, and >> haven't >> had any trouble with portability. I haven't tried nmake on >> Windows, but >> GNU make is available for Windows and can handle POSIX (=SUS) >> makefiles. >>> >>> >>> I have heard that there is only one perl, so it should be >>> compatible. >> >> It is not true that there is only one Perl. There has been one Perl >> development >> stream, but there have been many versions issued in that stream. >> What >> works >> in Perl 5.8.8 might not work in Perl 5.4, and probably won't work in >> Perl 6 if that >> ever gets finished. (You are aware that Perl 6 is supposed to be a >> whole new >> language?) >>> >>> So, is the chance of finding perl on ''any'' computer bigger than >>> the >>> chance of finding the right make program for your makefile? >> >> I respectfully suggest that there is a bigger problem than makefile >> compatibility, >> and that is C compiler command line compatibility. For example, to >> get optimised >> code I write >> cc -O2 foobar.c >> on one machine, but >> cc -xO2 foobar.c >> on another, and on another machine, sadly decommissioned because the >> vendor >> having stopped making the hardware and having decided never to >> upgrade >> the >> compiler or operating system nevertheless decided to start charging a >> really >> ridiculous licence fee to run the thing in multiuser mode, the >> command >> line switches >> were different again. Come to think of it, I have three C compilers >> on one machine, >> all with different switches, so simply checking which operating >> system >> it is won't help. >> >> When I use R, all of that is handled for me; if I ask the R system to >> arrange a C (or >> Fortran) compilation for me, it remembers what worked when it was >> built, and does >> it for me. Wouldn't it be nice if installing Erlang gave you >> erl cc ... >> that would run a C compiler with all the right switches to work with >> Erlang? >> >>> >>> >>> >>> bengt >>> >>> .On Tue, 2008-03-04 at 13:09 -0500, Toby Thain wrote: >>>> On 4-Mar-08, at 11:57 AM, Bengt Kleberg wrote: >>>> >>>>> Greetings, >>>>> >>>>> Is it not also the case that perl is more standard than make? >>>> >>>> >>>> Is *everyone* supposed to rewrite make in Perl every time they want >>>> to build something? >>>> >>>>> I know very little of perl, but have fought at least 4 different >>>>> kinds >>>>> of make (files). >>>> >>>> The GNU make documentation is really very good. I don't know why >>>> people rarely refer to it. >>>> >>>> --T >>>> >>>>> >>>>> >>>>> bengt >>>>> >>>>> On Tue, 2008-03-04 at 10:11 -0600, James Hague wrote: >>>>>> On Sat, Mar 1, 2008 at 8:41 PM, Steve Vinoski >>>>>> wrote: >>>>>>> >>>>>>> Hi Joe, I agree with you 100%. Give me emacs (with its vast >>>>>>> emacs-lisp >>>>>>> extensibility), bash (or ksh), and various UNIX command-line >>>>>>> tools, >>>>>>> which I can combine as I wish using pipes, and keep the visual >>>>>>> tools >>>>>>> out of my way (and out of my RAM). >>>>>> >>>>>> I think this discussion has been misinterpreted :) No one is >>>>>> arguing >>>>>> for IDE-like features over makefiles. >>>>>> >>>>>> I have found that I don't need makefiles for my Erlang >>>>>> projects. I >>>>>> either recompile the same module repeatedly or I want to rebuild >>>>>> everything. The former is business as usual. The latter is >>>>>> easily >>>>>> done with a shell script, Perl script, or short Erlang >>>>>> program. I >>>>>> use >>>>>> makefiles infrequently enough that I always forget the syntax and >>>>>> nuances of using them. But I can bang out a Perl program that >>>>>> does >>>>>> the same thing--even checking file modification dates and so >>>>>> on--in >>>>>> very little time. It's more flexible than using a makefile, too, >>>>>> and >>>>>> usually ends up being less "code." >>>>>> _______________________________________________ >>>>>> erlang-questions mailing list >>>>>> erlang-questions >>>>>> http://www.erlang.org/mailman/listinfo/erlang-questions >>>>> >>>>> _______________________________________________ >>>>> erlang-questions mailing list >>>>> erlang-questions >>>>> http://www.erlang.org/mailman/listinfo/erlang-questions >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions >>>> http://www.erlang.org/mailman/listinfo/erlang-questions >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions >>> http://www.erlang.org/mailman/listinfo/erlang-questions >> >> -- >> Te Reo Engarihi is a taonga of Te Iwi Pakeha, >> ergo we should keep it pure, sans m?lange, ruat caelum. >> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From fredrik.svahn Fri Mar 7 23:13:50 2008 From: fredrik.svahn (Fredrik Svahn) Date: Fri, 7 Mar 2008 23:13:50 +0100 Subject: [erlang-questions] Fwd: [eeps] EEP 9 In-Reply-To: References: <548212.96608.qm@web31506.mail.mud.yahoo.com> Message-ID: Thanks for your comments! Please see answers below: On Tue, Mar 4, 2008 at 9:25 PM, Vat Raghavan wrote: > I really like this eep, and i can't wait for it (or something quite similar :) ) to be part of otp. At least in part, > it will mollify those who complain about erlang's string manipulation support > > though, i think a better name of the module would be binary_string or something along those lines. There seems to be several similar suggestions. binary_string, string_as_binary, bstring. I personally prefer binary_string. > according to the eep, the reference implementation was given to the otp team along w/ the eep, it seems to me > that according to the 'many eyes' theory such an implementation should also be available to all, either at the eep site (preferred) or at the author's website or what have you. > > as to your question paul, the eep makes some suggestions about either aho-corasick, or boyer-moore, so i think some profiling would be required before any implementation decision could be made; even still, we're more in api design phase at the moment, and whatever implementation is finally used, i don't think it's very relevant now. The code has been made available, although you should probably look at it as more of an example of what the code could look like than a final implementation. I had fun writing it, but I am sure that the OTP team will make it into something better and faster. > i do like the suggestion about binary:match,i often find when i search strings i want not only the index searched, but the string that was found -> > > [eep] > -Maybe binary:match(<<"hello, world\n">>,[<<"xx">>,<<" ">>]) > should return {Needle, Index} (i.e. {<<" ">>, 7}) instead? The downside is that it might be slower, especially for the split function. We should probably do some measurements to see if it matters. Having {Needle, Index} makes for more beautiful code than {NeedleNumber, Index}. > or perhaps {Index, NeedleLength} i.e. {7, 1}? In retrospect this is probably not very good. To know which pattern matched you will first have to extract it from the binary. > [/eep] > > > re: Unicode. perhaps it be better to have 2 seperate libraries for ascii vs. unicode? > also, how would the module handle different encodings, utf-8/utf-16/utf-32, etc? Either that or default ascii with an optional parameter for the Encoding. BR /Fredrik From fredrik.svahn Sat Mar 8 00:20:39 2008 From: fredrik.svahn (Fredrik Svahn) Date: Sat, 8 Mar 2008 00:20:39 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <47D10043.4090703@it.uu.se> References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D10043.4090703@it.uu.se> Message-ID: Thanks for looking and commenting on the EEP. Please see answers below. On Fri, Mar 7, 2008 at 9:43 AM, Per Gustafsson wrote: > Very good work, but I do have some comments: > > Just as for lists and strings I think that there should be two different > modules one which just operates on binaries and one that operates on > binaries which are really strings. This module seems to be first of > these two for the most part so functions that only makes sense if the > binaries are strings should probably reside in some other module. The > string_as_binary module could have more or less exactly the same API as > string and similar modules could be defined for utf8, utf16 and utf32 if > necessary. Agreed, I will update the EEP and split it into two modules. I prefer the name binary_string over string_as_binary. > > * to_upper(Binary1) -> Binary2 > to_lower(Binary1) -> Binary2 > > Should be in the string_as_binary module Agree. > > > * binary_to_atom(Binary) -> Atom > atom_to_binary(Atom) -> Binary > > As you write these should probably be in the erlang module along with > > binary_to_existing_atom(Binary) -> Atom I will change the EEP to say so. > * unsigned_to_bin(Integer)-> Binary > > What does this function do? Does it create the shortest possible binary > in which the unsigned integer would fit? Correct. > > better names might be > > binary:from_unsigned(Integer) -> Binary > binary:to_unsigned(Binary) -> Integer Good suggestions. I will change it names. > * nth(N, Bin) -> Value > > To also satisfy 0-indexers there should probably be a > > nth0(N, Bin) -> Value > > just as in the lists module I can't find a nth0 in lists, at least not in R12B. 3> lists:nth(1, "ABC"). 65 4> lists:nth0(1, "ABC"). ** exception error: undefined function lists:nth0/2 BR /Fredrik From jim.mccoy Sat Mar 8 00:52:16 2008 From: jim.mccoy (Jim McCoy) Date: Fri, 7 Mar 2008 15:52:16 -0800 Subject: [erlang-questions] Some comments on EEP 9 (binary: module) In-Reply-To: <622AF7B5-4B5F-4B81-9586-31A2F67E0B53@cs.otago.ac.nz> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> <47CFB259.7040205@elte.hu> <87B5E982-D2AD-4532-825F-8E2167AC8D01@cs.otago.ac.nz> <622AF7B5-4B5F-4B81-9586-31A2F67E0B53@cs.otago.ac.nz> Message-ID: On Thu, Mar 6, 2008 at 7:32 PM, Richard A. O'Keefe wrote: > 5. Ever since I met SNOBOL 4, I have known the operation of removing > outer > blanks from a string as trimmming. It's a little odd to find it > called > stripping. Perl probably started this particular terminology shift, and Python and Ruby finished the job. Sorry, but arguing this one is a lost cause... jim From per.gustafsson Sat Mar 8 09:25:08 2008 From: per.gustafsson (Per Gustafsson) Date: Sat, 08 Mar 2008 09:25:08 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D10043.4090703@it.uu.se> Message-ID: <47D24D64.8030900@it.uu.se> >> nth(N, Bin) -> Value >> >> To also satisfy 0-indexers there should probably be a >> >> nth0(N, Bin) -> Value >> >> just as in the lists module > > I can't find a nth0 in lists, at least not in R12B. > > 3> lists:nth(1, "ABC"). > 65 > 4> lists:nth0(1, "ABC"). > ** exception error: undefined function lists:nth0/2 > > BR /Fredrik I must have dreamed this up :) Well if that function does not exist it does not need to exist in this module either. Per From fredrik.svahn Sat Mar 8 10:58:15 2008 From: fredrik.svahn (Fredrik Svahn) Date: Sat, 8 Mar 2008 10:58:15 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <47D13817.8050604@gmail.com> References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D13817.8050604@gmail.com> Message-ID: Thanks, good suggestion. I will add it. BR /Fredrik On Fri, Mar 7, 2008 at 1:41 PM, Serge Aleynikov wrote: > In addition to what others already have said, this function would be > helpful: > > binary:join(List, Delim) -> binary() > > where: > List = [binary()] | [string()] > Delim = binary() | string() > > Examples: > > binary:join([<<"abc">>, <<"def">>], <<$|>>). > <<"abc|def">> > > > binary:join(["abc", "def"], [$|]). > <<"abc|def">> > > Very good work! > > Regards, > > Serge > > > > Fredrik Svahn wrote: > > Thanks for the positive response both here an on the EEPs mailing list! > > > > My suggestion is that we continue the discussion regarding EEP-9 here > > on the erlang-questions mailing list since it has a broader audience > > than eeps I think it would make it a lot easier if we can > > keep it in this thread. > > > > For those who do not subscribe to the eeps mailing list, I would like > > to once again stress that this EEP does not cover improvements which > > requires changes to the compiler. It has been suggested to me that the > > smaller the EEP the faster it gets implemented so let us please keep > > the scope as narrow as possible. There is always room for new EEPs. > > > > A shortcut to EEP-9: http://www.erlang.org/eeps/eep-0009.html > > > > Now, to answer your questions: > > > >> 1) Can the reference implementation be made available publicly as a > >> patch to R12B-1? (Or actually in any fashion would be great.) > > > > The reference implementation in erlang is attached, the c part will > > follow in the next message as there is a maximum message size on > > erlang-questions. It matches the described functions minus what was > > added after a first round of comments from the OTP developers (the > > regexps for instance are probably going to have many more features > > after what I hear!). I may also have added one or two relatively > > simple functions, e.g. atom_to_binary, after the implementation was > > submitted. > > > >> 2) Which algorithm was choosen for the binary:match()? For multiple > >> keyword, Aho-Corasick would be great, especially if the interface was > >> something like this: > > > > In the reference implementation Aho-Corasick was indeed used for > > multiple keywords. Boyer-Moore was a logical choice for single > > keywords and there was even a brute force approach for short > > keywords/searchstrings. > > > >> MatchContext = binary:match_compile( [<<"the">>, <<"big">>, > >> <<"frog">>] ), > >> Value = <<"when we had a frog, he was big">>, > >> [{3, 14}, {2, 27}] = binary:match( MatchContext, Value ) > > > > Thanks for the comment. I think it makes a lot of sense to have a > > separation of the building of the trie and the actual searching as you > > suggest, especially if you are searching many binaries for the same > > keyword(s). I am not sure how easy it would be to implement it, > > though. I guess the returned match context would have to be some kind > > of reference or packed in a binary. Maybe someone from the OTP team > > could comment on that. I actually wanted to have the same thing for > > regular expressions. > > > > I note that you also want a function which returns all the matches not > > just the first one. Given that binary:match/3 takes indexes of the > > start and end position of the search it is easy to also add a function > > "binary:matches/2" in binary.erl which returns all the matches by > > repeatedly calling match/3. Having both "match/2" and "matches/2" > > would be similar to how it is done in the regexp module. > > > > BR /Fredrik > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > From fredrik.svahn Sat Mar 8 10:58:15 2008 From: fredrik.svahn (Fredrik Svahn) Date: Sat, 8 Mar 2008 10:58:15 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <47D13817.8050604@gmail.com> References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D13817.8050604@gmail.com> Message-ID: Thanks, good suggestion. I will add it. BR /Fredrik On Fri, Mar 7, 2008 at 1:41 PM, Serge Aleynikov wrote: > In addition to what others already have said, this function would be > helpful: > > binary:join(List, Delim) -> binary() > > where: > List = [binary()] | [string()] > Delim = binary() | string() > > Examples: > > binary:join([<<"abc">>, <<"def">>], <<$|>>). > <<"abc|def">> > > > binary:join(["abc", "def"], [$|]). > <<"abc|def">> > > Very good work! > > Regards, > > Serge > > > > Fredrik Svahn wrote: > > Thanks for the positive response both here an on the EEPs mailing list! > > > > My suggestion is that we continue the discussion regarding EEP-9 here > > on the erlang-questions mailing list since it has a broader audience > > than eeps I think it would make it a lot easier if we can > > keep it in this thread. > > > > For those who do not subscribe to the eeps mailing list, I would like > > to once again stress that this EEP does not cover improvements which > > requires changes to the compiler. It has been suggested to me that the > > smaller the EEP the faster it gets implemented so let us please keep > > the scope as narrow as possible. There is always room for new EEPs. > > > > A shortcut to EEP-9: http://www.erlang.org/eeps/eep-0009.html > > > > Now, to answer your questions: > > > >> 1) Can the reference implementation be made available publicly as a > >> patch to R12B-1? (Or actually in any fashion would be great.) > > > > The reference implementation in erlang is attached, the c part will > > follow in the next message as there is a maximum message size on > > erlang-questions. It matches the described functions minus what was > > added after a first round of comments from the OTP developers (the > > regexps for instance are probably going to have many more features > > after what I hear!). I may also have added one or two relatively > > simple functions, e.g. atom_to_binary, after the implementation was > > submitted. > > > >> 2) Which algorithm was choosen for the binary:match()? For multiple > >> keyword, Aho-Corasick would be great, especially if the interface was > >> something like this: > > > > In the reference implementation Aho-Corasick was indeed used for > > multiple keywords. Boyer-Moore was a logical choice for single > > keywords and there was even a brute force approach for short > > keywords/searchstrings. > > > >> MatchContext = binary:match_compile( [<<"the">>, <<"big">>, > >> <<"frog">>] ), > >> Value = <<"when we had a frog, he was big">>, > >> [{3, 14}, {2, 27}] = binary:match( MatchContext, Value ) > > > > Thanks for the comment. I think it makes a lot of sense to have a > > separation of the building of the trie and the actual searching as you > > suggest, especially if you are searching many binaries for the same > > keyword(s). I am not sure how easy it would be to implement it, > > though. I guess the returned match context would have to be some kind > > of reference or packed in a binary. Maybe someone from the OTP team > > could comment on that. I actually wanted to have the same thing for > > regular expressions. > > > > I note that you also want a function which returns all the matches not > > just the first one. Given that binary:match/3 takes indexes of the > > start and end position of the search it is easy to also add a function > > "binary:matches/2" in binary.erl which returns all the matches by > > repeatedly calling match/3. Having both "match/2" and "matches/2" > > would be similar to how it is done in the regexp module. > > > > BR /Fredrik > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > From sebastian.bello Sat Mar 8 15:21:50 2008 From: sebastian.bello (Sebastian Bello) Date: Sat, 08 Mar 2008 12:21:50 -0200 Subject: [erlang-questions] Passing parameters to a port driver In-Reply-To: <200802011410.m11EA9xe004844@pluto.hedeland.org> References: <200802011410.m11EA9xe004844@pluto.hedeland.org> Message-ID: <47D2A0FE.9070209@inswitch.us> There is no argc/argv in a linked in driver as far as I know. On the driver side you have static ErlDrvData driver_start(ErlDrvPort port, char *buff) and buff just points to the driver name; if you load the driver with parameters you just get an "open_error". Any other ideas? Sebastian- Per Hedeland escribi?: > Sebastian Bello wrote: > >> sorry but I didn't mention I was thinking about a linked-in driver; >> > > You said "driver" which was quite sufficient - that was the case that my > answer described. (An external port program would (at least on *nix) get > the Command in the argc/argv arguments to main()...) > > --Per > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > __________ NOD32 2843 (20080201) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080308/90d67a32/attachment.html From berlin.brown Sat Mar 8 16:17:22 2008 From: berlin.brown (Berlin Brown) Date: Sat, 8 Mar 2008 10:17:22 -0500 Subject: [erlang-questions] Simple client handler "at the accept call" of a server Message-ID: I have some client handling code, ideally it is pretty simple; but I keep getting this function_clause error. Here is my test case. 1. Start the server 2. Launch a telnet session and type: ACB and then close the connection. (Note: if I don't type anything and just quit, the connection closes without error). --------------------------- Here is the error, I receive; it doesn't seem to reach tcp_closed for some reason. =ERROR REPORT==== 8-Mar-2008::10:16:55 === ** Generic server <0.30.0> terminating ** Last message in was {tcp_closed,#Port<0.90>} ** When Server state == {noreply, {client_state,<0.28.0>,undefined,starting, {client_info,<0.28.0>,<0.29.0>,#Port<0.90>}, undefined,undefined}} ** Reason for termination == ** {function_clause, [{client_handler,terminate, [{function_clause, [{client_handler,handle_info, [{tcp_closed,#Port<0.90>}, {noreply, {client_state,<0.28.0>,undefined,starting, {client_info,<0.28.0>,<0.29.0>,#Port<0.90>}, undefined,undefined}}]}, {gen_server,handle_msg,5}, {proc_lib,init_p,5}]}, {noreply, {client_state,<0.28.0>,undefined,starting, {client_info,<0.28.0>,<0.29.0>,#Port<0.90>}, undefined,undefined}}]}, {gen_server,terminate,6}, {proc_lib,init_p,5}]} {"init terminating in do_boot",{{function_clause,[{client_handler,terminate,[{function_clause,[{client_handler,handle_info,[{tcp_closed,#Port<0.90>},{noreply,{client_state,<0.28.0>,undefined,starting,{client_info,<0.28.0>,<0.29.0>,#Port<0.90>},undefined,undefined}}]},{gen_server,handle_msg,5},{proc_lib,init_p,5}]},{noreply,{client_state,<0.28.0>,undefined,starting,{client_info,<0.28.0>,<0.29.0>,#Port<0.90>},undefined,undefined}}]},{gen_server,terminate,6},{proc_lib,init_p,5}]},{gen_server,call,[<0.29.0>,irc_accept_clients,infinity]}}} --------------------------- At point 2; the following server code gets launched. io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]), ClientSock = server_accept(ServSock), io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), ClientInfo = #client_info{app_handler=AppHandler,serv_lib=self(), client_sock=ClientSock}, { ok, ClientServ } = client_handler:start_link(ClientInfo), gen_tcp:controlling_process(ClientSock, ClientServ), inet:setopts(ClientSock, [{packet, 0}, binary, {nodelay, true},{active, true}]), {reply, ok, State}; -------- This is my code for handling the client connection. start_link(Client) -> gen_server:start_link(?MODULE, [Client], []). init([Client]) -> AppHandler = Client#client_info.app_handler, io:format("trace: client_handler:init. handler:[~p]~n", [AppHandler]), {ok, #client_state{app_handler=AppHandler, connection_timeout=undefined, client=Client, state=starting}}. handle_call(get_cur_state, _From, #client_state{} = State) -> % Generic method to get the current state. io:format("trace: lib:handle_call:get_cur_state~n"), {reply, {ok, State}, State}. terminate(_Reason, #client_state{client=Client}) -> io:format("trace: client:handler:terminate reason:[~p]~n", [_Reason]), ok; terminate(normal, #client_state{client=Client}) -> io:format("trace: client:handler:terminate.normal~n"), ok; terminate(shutdown, #client_state{client=Client}) -> io:format("trace: client:handler:terminate.shutdown~n"), ok. handle_info({tcp, Sock, Data}, State) -> inet:setopts(Sock, [{active, once}]), io:format("trace: lib:info.tcp data [~p]~n", [Data]), {Prefix, Command, Args} = try data_lib:scan_string(Data) catch _:_ -> io:format("ERROR: error attempting to parse input command~n"), {"", "SYS_INVALID", ""} end, % Invoke the client data handler to process incoming messages. HandleState=client_handle_data(State, {Prefix, Command, Args}), {noreply, {noreply, State}}; handle_info({tcp_closed, Sock}, #client_state{app_handler=AppHandler} = State) -> io:format("trace: lib:info.tcp_closed~n"), inet:setopts(Sock, [{active, once}]), AppHandler ! {connection_closed}, {noreply, State#client_state{state=disconn}}; handle_info({tcp_error, Sock, Reason}, State) -> io:format("trace: lib:info.tcp_error~n"), inet:setopts(Sock, [{active, once}]), {noreply, State#client_state{state=disconn}}. -- Berlin Brown http://botspiritcompany.com/botlist/spring/help/about.html From gaperton Sat Mar 8 16:34:40 2008 From: gaperton (Vlad Balin) Date: Sat, 8 Mar 2008 18:34:40 +0300 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D13817.8050604@gmail.com> Message-ID: <7c1602610803080734p1e038ee4xe2039e5873016f4a@mail.gmail.com> One more issue. Take this function as an example. split(Binary, SplitKeys) -> List Binary = binary() SplitKeys = binary() | [binary()] Wouldn't it be useful to allow integers in SplitKeys in place of binaries? We can treat them as 1-byte binaries (should be easy to implement), and it will make code more readable in cases when keys consist of 1 character. With this option, we can just write split( Buffer, "\n " ) instead of > binary:match(<<"hello, world\n">>,[<<"\n">>,<<" ">>]). It can be applied to many functions in this module, and it should increase code readability in general. Thanks, Vlad. From pablo.polvorin Sat Mar 8 16:54:28 2008 From: pablo.polvorin (Pablo Polvorin) Date: Sat, 8 Mar 2008 12:54:28 -0300 Subject: [erlang-questions] Issue with my simple server, accept not accepting connections In-Reply-To: <20080307173522.M59127@www.botspiritcompany.com> References: <20080307173522.M59127@www.botspiritcompany.com> Message-ID: <1ffe809c0803080754g428dfaeet11201c7a457932e4@mail.gmail.com> Try to establish a tcp connection *really* quickly after starting the server and see what happens.. you will be able to connect (and then crash with {undef,[{client_handler,start_link,[]). I guess the reason you can't connect to the server is that you are hitting a timeout inside your gen_server: handle_call/3 implementation (witch doesn't return in the expected time). Anyway, there is an introductory TCP server example , at http://www.erlang.org/examples/klacke_examples/index.html you could use that as a starting point for simplifying your code. cheers, pablo. 2008/3/7, bbrown : > Hello, this kind of a long post (lot of code) and maybe I need to simplify my > code but I am writing a simple tcp server and maybe you see something that is > totally off. I have one application module and a server module (a type of > middle-man) and then the client-handler module. > > Everything gets called correctly, but I can't connect to the server. I get a > connection refused for example if > > This is my server library as a gen_server module. > > The key code is here and my issue. When I try to connect to the server, it > looks like it never calls the code after "accept". > > I get to this line: > io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]) > > But I don't get to this line after the accept call: > > io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), > > ----------------- > > io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]), > ClientSock = server_accept(ServSock), > io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), > > > ----------------- > > server_accept(ServSock) -> > { ok, ClientSock } = gen_tcp:accept(ServSock), > ClientSock. > ----------------- > handle_call(irc_server_bind, _From, > #server_state{client=Client } = State) -> > Port = Client#irc_server_info.port, > io:format("trace: lib:handle_call:bind Port:<~p>~n", [Port]), > {ok, ServSock} = server_bind(Port), > {reply, ok, State#server_state{serv_sock=ServSock, state=connecting}}; > handle_call(irc_accept_clients, _From, > #server_state{serv_sock=ServSock, app_handler=AppHandler } = State) -> > io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]), > ClientSock = server_accept(ServSock), > io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), > { ok, ClientServ } = client_handler:start_link(), > % Assign a new controlling process. > gen_tcp:controlling_process(ClientSock, ClientServ), > inet:setopts(ClientSock, [{packet, 0}, binary, > {nodelay, true},{active, false}]), > % Invoke gen_server:cast to handle the socket > {reply, ok, State}; > handle_call(get_cur_state, _From, #server_state{} = State) -> > % Generic method to get the current state. > io:format("trace: lib:handle_call:get_cur_state~n"), > {reply, {ok, State}, State}. > > terminate(_Reason, #server_state{client=Client}) -> > io:format("trace: lib:terminate reason:[~p]~n", [_Reason]), > ok; > terminate(shutdown, #server_state{client=Client}) -> > io:format("trace: lib:terminate.shutdown~n"), > ok. > > handle_info(server_timeout, #server_state{client=Client} = State) -> > io:format("trace: lib:handle_info.server_timeout"), > %{noreply, State#server_state{state=timeout, connection_timeout=undefined}}. > {noreply, State}. > > server_listen(ServLib) -> > io:format("trace: lib:server listen [~p]~n", [ServLib]), > % Synchronous gen_server call > gen_server:call(ServLib, irc_server_bind). > > %% Accept call and then cast to handle new client > server_accept_call(ServLib) -> > io:format("trace: lib:server accept new client~n"), > gen_server:call(ServLib, irc_accept_clients). > > get_cur_state(ServLib) -> > io:format("trace: lib:get_cur_state: pid:[~p] ~n", [ServLib]), > % Return: {ok, State} > gen_server:call(ServLib, get_cur_state). > > server_bind(Port) -> > io:format("trace: attempting to bind server... [~p]~n", [Port]), > gen_tcp:listen(Port, [binary, {packet, 0}, > {active, false}]). > > server_accept(ServSock) -> > { ok, ClientSock } = gen_tcp:accept(ServSock), > ClientSock. > > connection_timeout() -> > % Time out delay of 1 minute > 600000. > ---------------- > > start_test_serv() -> > io:format("Running functional test~n"), > % Ensure that the app_handler is associcated with this app process > Client = #irc_server_info{app_handler=self()}, > Pid = start(Client), > io:format("trace: start server, handler:~p ~n", [Pid]), > % Wait a couple of seconds and then send messages to wait_for_clients. > timer:sleep(500), > init_accept_clients(), > % Pass the pid of the server handler process. > wait_for_clients(Pid), > io:format("Done~n"). > > wait_for_clients(ServHandler) -> > io:format("trace: app: wait_for_clients~n"), > receive > Anything -> > % Application process is ready to accept new clients > io:format("trace: app: wait_messages:accept ~n"), > accept_clients(ServHandler), > wait_for_clients(ServHandler) > after connection_timeout() + 20000 -> > io:format("INFO: Timed out~n") > end. > ----------------- > > Here is my server handler code. > > server_handler(Client) -> > ServStart = server_lib:start_link(Client), > case ServStart of > { ok, P } -> > io:format("trace: app:server pid/lib [~p]~n", [P]), > server_lib:server_listen(P), > State = server_lib:get_cur_state(P), > % io:format("trace: app:server state [~p]~n", [State]), > server_handler(#serv_handler_info{lib_handler=P}, idle) > end. > > server_handler(ServClient, idle) -> > ServLib = ServClient#serv_handler_info.lib_handler, > io:format("trace: [!] at server_handler.idle [~p]~n", [ServLib]), > receive > { ready_accept } -> > % Application process is ready to accept new clients > io:format("trace: app: wait_messages:accept ~n"), > % Launch initial accept clients block > AcceptCall = server_lib:server_accept_call(ServLib), > io:format("!!!-->~p~n", [AcceptCall]), > case AcceptCall of > { ok, State } -> > io:format("poo~n") > end, > server_handler(ServClient, idle); > Error -> > io:format("trace: [!] app:error.proceeed: ~p~n", [Error]), > server_handler(ServClient, idle) > after connection_timeout() -> > io:format("trace: [!] at server_handler. TIMEOUT ~n"), > server_handler(ServClient, idle) > end. > > accept_clients(ServHandler) -> > % Start waiting accept new client connections. > ServHandler ! {ready_accept}. > > init_accept_clients() -> > % Start waiting accept new client connections. > self() ! {init_accept}. > > > ----------------- > > And if you are really curious; here is the source in subversion: > > http://openbotlist.googlecode.com/svn/trunk/botlistprojects/laughingman/test/ircserver/src/ > > -- > Berlin Brown > email: berlin-dot-brown-AT-gmail-dot-com > http://botspiritcompany.com/botlist/ > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- -- pablo http://ppolv.wordpress.com ---- From dizzyd Sat Mar 8 17:48:27 2008 From: dizzyd (Dave Smith) Date: Sat, 8 Mar 2008 09:48:27 -0700 Subject: [erlang-questions] Simple client handler "at the accept call" of a server In-Reply-To: References: Message-ID: On Sat, Mar 8, 2008 at 8:17 AM, Berlin Brown wrote: > I have some client handling code, ideally it is pretty simple; but I > keep getting this function_clause error. > > ** Reason for termination == > ** {function_clause, > [{client_handler,terminate, > [{function_clause, > [{client_handler,handle_info, > [{tcp_closed,#Port<0.90>}, > {noreply, > {client_state,<0.28.0>,undefined,starting, > {client_info,<0.28.0>,<0.29.0>,#Port<0.90>}, > undefined,undefined}}]}, I believe this is saying: No function that matches: client_handler:handle_info({tcp_closed, Port}, {noreply, {client_state}}) The actual bug lies in your handle_info method, wherein you're clumping an additional "noreply" atom in your state: > % Invoke the client data handler to process incoming messages. > HandleState=client_handle_data(State, {Prefix, Command, Args}), > {noreply, {noreply, State}}; Should be: > % Invoke the client data handler to process incoming messages. > HandleState=client_handle_data(State, {Prefix, Command, Args}), > {noreply, State}; Hope that helps... D. From fredrik.svahn Sat Mar 8 17:56:37 2008 From: fredrik.svahn (Fredrik Svahn) Date: Sat, 8 Mar 2008 17:56:37 +0100 Subject: [erlang-questions] Some comments on EEP 9 (binary: module) In-Reply-To: <622AF7B5-4B5F-4B81-9586-31A2F67E0B53@cs.otago.ac.nz> References: <47CE6FA5.7060808@it.uu.se> <007a01c87eed$c3ba3b10$891ea8c0@SSI.CORP> <20080305192807.GP66069@h216-235-12-172.host.egate.net> <36AAD721-6A34-48C6-B95E-A3ED489FC506@cs.otago.ac.nz> <47CFB259.7040205@elte.hu> <87B5E982-D2AD-4532-825F-8E2167AC8D01@cs.otago.ac.nz> <622AF7B5-4B5F-4B81-9586-31A2F67E0B53@cs.otago.ac.nz> Message-ID: Thanks for looking at the EEP. Please see comments below: On Fri, Mar 7, 2008 at 4:32 AM, Richard A. O'Keefe wrote: > 1. Given that the module for lists is called 'lists', not 'list', > it is rather confusing that the module for binaries is called > 'binary', > instead of the expected 'binaries'. > > On the other hand, given that the module for strings is called > "string", > maybe it's 'lists' that has the wrong name. Something needs to > be done > about naming consistency in modules for data types. I have noted the same thing and decided to make it like string, queue and array rather than like lists or sets. Binary/binary_string has the added advantage of also being slightly shorter than binaries/binary_strings. > 2. What do you return if you look for something and it isn't there? > For some reason, people seem to like returning an out-of-range > index > at the wrong end. BASIC does this, Smalltalk does it, but that > does not > make it right. Life gets *so* much simpler if match(Haystack, > Needle) > returns an index past the *right* end of the haystack. Suppose, > for > example, we have input with an optional comment; we want to > remove it. > [Mind you, EEP 9 is handicapped by starting from a system where > binary slicing uses just about the worst possible convention, > but that is > another and sadder story.] > [Oh yes, the documentation for the erlang: module gets > erlang:split_bionary/2 > wrong. It says that the range for Pos is 1..size(Bin), but 0 is > *rightly* > allowed. Pos is actually the size of the first part, which is > just right.] > > Example. Suppose we are given a line of text from some > configuration file > as a binary. It might contain a # comment or it might not. Our > only interest is > in getting rid of it. In a rational design, where > match(Haystack, Needle) > returns the length of the longest prefix of Haystack *not* > containing Needle, > we just do > {Wanted,_} = split_binary(Given, match(Given, <<"#">>)) > With the scheme actually proposed, we have to do > case match(Given, <<"#">>) > of 0 -> Wanted = Given > ; N -> {Wanted,_} = split_binary(Given, N-1) > end There are already two different return values in two different library modules for the "not found scenario". regexp:match/2 -> nomatch string:[r]str/2 -> 0 string:[r]chr/2 -> 0 I am afraid that adding a third way of marking "not found" in a third library is only going to add to the confusion. > 3. I appreciate that slicing binaries is supposed to be cheap, but I > still > think it would be nice if match had a 3rd argument, saying how > many bytes > at the beginning of Haystack to skip. If it weren't 4pm on a > Friday with > my office floor still to tidy up, I could give examples of why > this can > make life simpler. I am not sure I understand. There is already a match function in the EEP where you can specify where to start the matching. match(Haystack, Needles, {StartIndex, EndIndex}) -> Return > 4. I agree that the proposed binary:split/2 function is useful, but > the name > is far too close to split_binary/2 for comfort. A longer name > such as > binaries:split_with_separator(Binary, Separator_Binary) > might make for less confusion. Better still, why not make this > like > string:tokens/2, which really has exactly the same purpose except > for the > data type it applies to? The proposed split function is actually more like regexp:split/2 than string:tokens/2. As you know string:tokens/2 takes a list of separator chars and splits by any of the chars, which I usually find is *not* what I want it to do. Thus naming it tokens will give the wrong associations since it is already implemented in another way in the string library. string:tokens("cat and dog", "and"). ["c","t "," ","og"] regexp:split("cat and dog", "and"). {ok,["cat "," dog"]} Then again as the function is specified you could mimic the behaviour of tokens by giving binary:split/2 a list of binaries [<<"a">>, <<"n">>, <<"d">>], although you would end up with some empty binaries as well, just like you have the empty lists in regexp:split(): 2> regexp:split("cat and dog","a|n|d"). {ok,["c","t ",[],[]," ","og"]} Maybe split_with/2 or split_by/2 to keep it reasonable short? > 5. Ever since I met SNOBOL 4, I have known the operation of removing > outer > blanks from a string as trimmming. It's a little odd to find it > called > stripping. By analogy with ecdysiasis (hem hem) I would expect > stripping > to remove visible outer stuff. I wish string:strip/[1,2,3] could > be > renamed. This is analogous to string:strip/1. While I agree trim is a better name I think that calling it trim in one library and strip in another will only add confusion and strange questions to erlang-questions in the future. > > 6. In the functions > unsigned_to_bin/1 > bin_to_unsigned/1 > why is the word "binary" abbreviated to "bin"? Agreed. I will change bin to binary. > 7. "nth" is a very strange name for a substring operation. > I would prefer > subbinary(Binary, Offset[, Length]) > 0 =< Offset =< byte_size(Binary) > 0 =< Length =< byte_size(Binary) - Offset > which would make this compatible with the existing > split_binary(Binary, Offset) > function. Agreed, I was not pleased with the name myself. It is a leftover from the first version where it picked out one byte at the nth position (similar to lists:nth/2 operating on a string). I am planning (as per the suggestions here on the mailing list) to split the module into two, where one should be called binary_string or similar. In that module it should be named and behave like string:sub_string/2,3. BR /Fredrik From gaperton Sat Mar 8 18:06:14 2008 From: gaperton (Vlad Balin) Date: Sat, 8 Mar 2008 20:06:14 +0300 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <7c1602610803080734p1e038ee4xe2039e5873016f4a@mail.gmail.com> References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D13817.8050604@gmail.com> <7c1602610803080734p1e038ee4xe2039e5873016f4a@mail.gmail.com> Message-ID: <7c1602610803080906s4b296cd6wbe4c35a53ce27875@mail.gmail.com> Yes, and there are another idea, which would lead to more general approach. If we allow these functions to work on iolists (!) we could keep just single module "strings". That would be ideal approach from the application's programmer: 1) Concatenation of binaries is more expensive than making iolist out of 2 binaries. Therefore, we'll take benefit of extremely cheap string concatenations. 2) Function split can be used to reformat iolist. Quite intellegent operation, which is more general than just strings manipulation. I understand that this approach require more effort to implement than original proposal, but 1) It features backward compatibility with strings module. 2) It opens extended possibilities working with binary strings, which are not present in current languages, making Erlang one of the most advancel language for string manipulations. Such as "lazy" string concatenations with iolists. 2008/3/8, Vlad Balin : > One more issue. Take this function as an example. > > split(Binary, SplitKeys) -> List > Binary = binary() > SplitKeys = binary() | [binary()] > > > Wouldn't it be useful to allow integers in SplitKeys in place of > binaries? We can treat them as 1-byte binaries (should be easy to > implement), and it will make code more readable in cases when keys > consist of 1 character. > > With this option, we can just write > > split( Buffer, "\n " ) > > instead of > > > binary:match(<<"hello, world\n">>,[<<"\n">>,<<" ">>]). > > It can be applied to many functions in this module, and it should > increase code readability in general. > > Thanks, > > Vlad. > From fredrik.svahn Sat Mar 8 18:45:38 2008 From: fredrik.svahn (Fredrik Svahn) Date: Sat, 8 Mar 2008 18:45:38 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <7c1602610803080734p1e038ee4xe2039e5873016f4a@mail.gmail.com> References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D13817.8050604@gmail.com> <7c1602610803080734p1e038ee4xe2039e5873016f4a@mail.gmail.com> Message-ID: I agree that the proposal below would make for more readable code (although the difference between split(Buffer, "\n ") and split(Buffer, [<<"\n">>,<<" ">>]) is not really all that big). A potential problem is that it could lead to confusion and strange errors if you intended to write <<"and">> but instead by mistake wrote "and". With the proposal below the following two functions will be very similar but will return very different results: split(<<"cat and dog">>, "and") -> [<<"c">>,<<"t ">>,<<" ">>,<<"og">>] split(<<"cat and dog">>, <<"and">>) -> [<<"cat ">>, <<" dog">>] Confusing the two would be easy if you are not sitting with the ref manual open all the time. Seems like we need both a function similar to string:tokens/2 (which could take a list of one char separators, like "and" above) and a split_with function which takes a binary or a list of binaries. Maybe the examples above aren't all that great, but consider for instance the difference between "\r\n" and <<"\r\n">> when splitting headers according to RFC822. Which other functions where you thinking about? BR /Fredrik On Sat, Mar 8, 2008 at 4:34 PM, Vlad Balin wrote: > One more issue. Take this function as an example. > > split(Binary, SplitKeys) -> List > Binary = binary() > SplitKeys = binary() | [binary()] > > > Wouldn't it be useful to allow integers in SplitKeys in place of > binaries? We can treat them as 1-byte binaries (should be easy to > implement), and it will make code more readable in cases when keys > consist of 1 character. > > With this option, we can just write > > split( Buffer, "\n " ) > > instead of > > > binary:match(<<"hello, world\n">>,[<<"\n">>,<<" ">>]). > > It can be applied to many functions in this module, and it should > increase code readability in general. > > Thanks, > Vlad. > From berlin.brown Sat Mar 8 19:00:10 2008 From: berlin.brown (Berlin Brown) Date: Sat, 8 Mar 2008 13:00:10 -0500 Subject: [erlang-questions] Issue with my simple server, accept not accepting connections In-Reply-To: <1ffe809c0803080754g428dfaeet11201c7a457932e4@mail.gmail.com> References: <20080307173522.M59127@www.botspiritcompany.com> <1ffe809c0803080754g428dfaeet11201c7a457932e4@mail.gmail.com> Message-ID: On Sat, Mar 8, 2008 at 10:54 AM, Pablo Polvorin wrote: > Try to establish a tcp connection *really* quickly after starting the > server and see what happens.. you will be able to connect (and then > crash with {undef,[{client_handler,start_link,[]). > I guess the reason you can't connect to the server is that you are > hitting a timeout inside your gen_server: handle_call/3 > implementation (witch doesn't return in the expected time). > > Anyway, there is an introductory TCP server example , at > http://www.erlang.org/examples/klacke_examples/index.html > you could use that as a starting point for simplifying your code. > > cheers, > pablo. > > > > 2008/3/7, bbrown : > > > > Hello, this kind of a long post (lot of code) and maybe I need to simplify my > > code but I am writing a simple tcp server and maybe you see something that is > > totally off. I have one application module and a server module (a type of > > middle-man) and then the client-handler module. > > > > Everything gets called correctly, but I can't connect to the server. I get a > > connection refused for example if > > > > This is my server library as a gen_server module. > > > > The key code is here and my issue. When I try to connect to the server, it > > looks like it never calls the code after "accept". > > > > I get to this line: > > io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]) > > > > But I don't get to this line after the accept call: > > > > io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), > > > > ----------------- > > > > io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]), > > ClientSock = server_accept(ServSock), > > io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), > > > > > > ----------------- > > > > server_accept(ServSock) -> > > { ok, ClientSock } = gen_tcp:accept(ServSock), > > ClientSock. > > ----------------- > > handle_call(irc_server_bind, _From, > > #server_state{client=Client } = State) -> > > Port = Client#irc_server_info.port, > > io:format("trace: lib:handle_call:bind Port:<~p>~n", [Port]), > > {ok, ServSock} = server_bind(Port), > > {reply, ok, State#server_state{serv_sock=ServSock, state=connecting}}; > > handle_call(irc_accept_clients, _From, > > #server_state{serv_sock=ServSock, app_handler=AppHandler } = State) -> > > io:format("trace: lib:handle_call accept_clients. [~p]~n", [AppHandler]), > > ClientSock = server_accept(ServSock), > > io:format("trace: [!!] lib:handle_call client-socket: [~p]~n", [ClientSock]), > > { ok, ClientServ } = client_handler:start_link(), > > % Assign a new controlling process. > > gen_tcp:controlling_process(ClientSock, ClientServ), > > inet:setopts(ClientSock, [{packet, 0}, binary, > > {nodelay, true},{active, false}]), > > % Invoke gen_server:cast to handle the socket > > {reply, ok, State}; > > handle_call(get_cur_state, _From, #server_state{} = State) -> > > % Generic method to get the current state. > > io:format("trace: lib:handle_call:get_cur_state~n"), > > {reply, {ok, State}, State}. > > > > terminate(_Reason, #server_state{client=Client}) -> > > io:format("trace: lib:terminate reason:[~p]~n", [_Reason]), > > ok; > > terminate(shutdown, #server_state{client=Client}) -> > > io:format("trace: lib:terminate.shutdown~n"), > > ok. > > > > handle_info(server_timeout, #server_state{client=Client} = State) -> > > io:format("trace: lib:handle_info.server_timeout"), > > %{noreply, State#server_state{state=timeout, connection_timeout=undefined}}. > > {noreply, State}. > > > > server_listen(ServLib) -> > > io:format("trace: lib:server listen [~p]~n", [ServLib]), > > % Synchronous gen_server call > > gen_server:call(ServLib, irc_server_bind). > > > > %% Accept call and then cast to handle new client > > server_accept_call(ServLib) -> > > io:format("trace: lib:server accept new client~n"), > > gen_server:call(ServLib, irc_accept_clients). > > > > get_cur_state(ServLib) -> > > io:format("trace: lib:get_cur_state: pid:[~p] ~n", [ServLib]), > > % Return: {ok, State} > > gen_server:call(ServLib, get_cur_state). > > > > server_bind(Port) -> > > io:format("trace: attempting to bind server... [~p]~n", [Port]), > > gen_tcp:listen(Port, [binary, {packet, 0}, > > {active, false}]). > > > > server_accept(ServSock) -> > > { ok, ClientSock } = gen_tcp:accept(ServSock), > > ClientSock. > > > > connection_timeout() -> > > % Time out delay of 1 minute > > 600000. > > ---------------- > > > > start_test_serv() -> > > io:format("Running functional test~n"), > > % Ensure that the app_handler is associcated with this app process > > Client = #irc_server_info{app_handler=self()}, > > Pid = start(Client), > > io:format("trace: start server, handler:~p ~n", [Pid]), > > % Wait a couple of seconds and then send messages to wait_for_clients. > > timer:sleep(500), > > init_accept_clients(), > > % Pass the pid of the server handler process. > > wait_for_clients(Pid), > > io:format("Done~n"). > > > > wait_for_clients(ServHandler) -> > > io:format("trace: app: wait_for_clients~n"), > > receive > > Anything -> > > % Application process is ready to accept new clients > > io:format("trace: app: wait_messages:accept ~n"), > > accept_clients(ServHandler), > > wait_for_clients(ServHandler) > > after connection_timeout() + 20000 -> > > io:format("INFO: Timed out~n") > > end. > > ----------------- > > > > Here is my server handler code. > > > > server_handler(Client) -> > > ServStart = server_lib:start_link(Client), > > case ServStart of > > { ok, P } -> > > io:format("trace: app:server pid/lib [~p]~n", [P]), > > server_lib:server_listen(P), > > State = server_lib:get_cur_state(P), > > % io:format("trace: app:server state [~p]~n", [State]), > > server_handler(#serv_handler_info{lib_handler=P}, idle) > > end. > > > > server_handler(ServClient, idle) -> > > ServLib = ServClient#serv_handler_info.lib_handler, > > io:format("trace: [!] at server_handler.idle [~p]~n", [ServLib]), > > receive > > { ready_accept } -> > > % Application process is ready to accept new clients > > io:format("trace: app: wait_messages:accept ~n"), > > % Launch initial accept clients block > > AcceptCall = server_lib:server_accept_call(ServLib), > > io:format("!!!-->~p~n", [AcceptCall]), > > case AcceptCall of > > { ok, State } -> > > io:format("poo~n") > > end, > > server_handler(ServClient, idle); > > Error -> > > io:format("trace: [!] app:error.proceeed: ~p~n", [Error]), > > server_handler(ServClient, idle) > > after connection_timeout() -> > > io:format("trace: [!] at server_handler. TIMEOUT ~n"), > > server_handler(ServClient, idle) > > end. > > > > accept_clients(ServHandler) -> > > % Start waiting accept new client connections. > > ServHandler ! {ready_accept}. > > > > init_accept_clients() -> > > % Start waiting accept new client connections. > > self() ! {init_accept}. > > > > > > ----------------- > > > > And if you are really curious; here is the source in subversion: > > > > http://openbotlist.googlecode.com/svn/trunk/botlistprojects/laughingman/test/ircserver/src/ > > > > -- > > Berlin Brown > > email: berlin-dot-brown-AT-gmail-dot-com > > http://botspiritcompany.com/botlist/ > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > > -- > -- > pablo > http://ppolv.wordpress.com > ---- > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > I found the error, it was a copy paste error; I had returned the wrong type and then in later code, it was expecting a different type and hence the function_clause error. I changed this... {noreply, {noreply, State}}; To what is below... handle_info({tcp, Sock, Data}, State) -> inet:setopts(Sock, [{active, once}]), io:format("trace: lib:info.tcp data [~p]~n", [Data]), % Invoke the client data handler to process incoming messages. HandleState=client_handle_data(State, {Prefix, Command, Args}), {noreply, State}; -- Berlin Brown http://botspiritcompany.com/botlist/spring/help/about.html From jay Sat Mar 8 20:33:32 2008 From: jay (Jay Nelson) Date: Sat, 8 Mar 2008 11:33:32 -0800 Subject: [erlang-questions] Some comments on EEP 9 (binary: module) Message-ID: <6E6F190F-BA5E-4969-8E62-133B89B27AA0@duomark.com> > > 7. "nth" is a very strange name for a substring operation. > > I would prefer > > subbinary(Binary, Offset[, Length]) > > 0 =< Offset =< byte_size(Binary) > > 0 =< Length =< byte_size(Binary) - Offset > > which would make this compatible with the existing > > split_binary(Binary, Offset) > > function. > Agreed, I was not pleased with the name myself. It is a leftover from > the first version where it picked out one byte at the nth position > (similar to lists:nth/2 operating on a string). I am planning (as per > the suggestions here on the mailing list) to split the module into > two, where one should be called binary_string or similar. In that > module it should be named and behave like string:sub_string/2,3. Be careful in choosing the name for the function which extracts a subsequence from a binary. There is already a concept in erlang of a 'subbinary' (not sure if there is a dash or underscore but I think the docs and code refer to it all jammed together as one word), which specifically represents a minimal structure which points into another binary (or subbinary) so that there is no copying of contiguous elements to create a new binary. Whatever nomenclature is chosen, the semantics of subbinary should be preserved (possibly even to the point of having a separate module called subbinary which guarantees to operate on them in an efficient manner and identifies explicitly when a binary is returned and when a subbinary is returned). So, I am proposing that if a function such as binary:subbinary/2,3 is provided, it be documented and guaranteed that it doesn't copy the binary elements in constructing a result. If a new binary with copy semantics is the desired result, a different function name (for example, binary:copy_slice/2,3 or binary:copy_subseq/2,3) be provided. Likewise binary_string:subbinary/2,3 would not copy, while binary_string:sub_string/2,3 would. I'm not sure if the distinction of copying is necessary by having two sets of functions, or whether a binary:copy_binary/1 function could do the dirty work when needed, thereby only requiring all subseq operations to return a real 'subbinary' and the user explicitly copying when desired. In general, this approach would be the best I think by keeping the module signature to a minimal set of function. ------ A scenario I currently use is to read a text file as a single binary, scan it to create a list of subbinaries (for example, of all the configuration terms and values), then filter for some subset of the list which I want to continue using. I then would like to discard the large binary and all the unused binaries. It is almost an explicit garbage collect on one structure using application specific knowledge. A BIF should be provided which guarantees the return of a deep list of fresh copies of the binaries passed to it in a deep list: binary:copy_binaries(DeepListOfBinaries) The application code would be something like this: get_config_params() -> BigBin = load_binary(...), ParsedBins = parse_binary(BigBin), Keepers = filter_config_params(ParsedBins), FreshBins = binary:copy_binaries(Keepers). On return, the references to BigBin and all subbinaries parsed out are dropped, so only the FreshBins will be kept on the next garbage collection sweep. The key is to guarantee all references to BigBin are eliminated by copying the subbinaries to fresh memory. jay From rory Sat Mar 8 20:50:02 2008 From: rory (Rory Byrne) Date: Sat, 8 Mar 2008 20:50:02 +0100 Subject: [erlang-questions] fprof module loading problem on R12B-1 [was: Binary pattern matching inconsistencies with R12B] In-Reply-To: <20080303210149.GA12400@almeida.jinsky.com> References: <20080229174344.GA2361@almeida.jinsky.com> <20080303210149.GA12400@almeida.jinsky.com> Message-ID: <20080308195002.GA18069@almeida.jinsky.com> On Mon, Mar 03, 2008 at 10:01:49PM +0100, Rory Byrne wrote: > > Just applied the patch and everything works great now. Many thanks Bjorn! > Hello, I'm seeing some problems with fprof on i386 (but not on amd64). I'm not certain that the problem is related to this thread but I think it might be since it's the same code that is effected. Basically, fprof dies when it tries to load certain modules. It's not just my own modules that causes this - here's what happens when running fprof on http:request/1 on my machine: %% -- START CODE -- %% Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] [kernel-poll:false] Eshell V5.6 (abort with ^G) 1> inets:start(). ok 2> fprof:apply(http, request, ["http://www.erlang.com"]). Aborted %% -- END -- %% >From what I have seen, the modules that are effected can only be profiled sucessfully if you load the module and its dependencies before running fprof. The code that I posted at the start of this thread (weird.erl and scanner.erl) is effected by this problem so I'll use weird.erl in the following examples: %% -- START CODE -- %% $ erl Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] [kernel-poll:false] Eshell V5.6 (abort with ^G) 1> l(weird). {module,weird} 2> fprof:apply(weird, run, [1]). ok 3> fprof:apply(weird, run, [1]). ok 4> q(). ok $ erl Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] [kernel-poll:false] Eshell V5.6 (abort with ^G) 1> fprof:apply(weird, run, [1]). Aborted %% -- END -- %% Also, there is no weird:run/3, but I get the same result if I ask fprof to call it: %% -- START CODE -- %% $ erl Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] [kernel-poll:false] Eshell V5.6 (abort with ^G) 1> fprof:apply(weird, run, [what, the, f]). Aborted %% -- END -- %% Hipe is not supported on my i386 so I can't test with it. This isn't really a problem for me as I can make warm-up calls to my modules before profiling - probably a smart thing to do anyway. Just thought it might be of interest. Cheers. Rory From vychodil.hynek Sat Mar 8 20:40:37 2008 From: vychodil.hynek (Hynek Vychodil) Date: Sat, 8 Mar 2008 20:40:37 +0100 Subject: [erlang-questions] message ring test (memory allocation question) In-Reply-To: <744BB52D-E4C4-41EB-AAB6-DF0A53B36C1A@lanl.gov> References: <744BB52D-E4C4-41EB-AAB6-DF0A53B36C1A@lanl.gov> Message-ID: <4d08db370803081140l1e4af6e2mb37cb4533f1aae81@mail.gmail.com> On Tue, Mar 4, 2008 at 4:54 PM, Allen McPherson wrote: > -- Re-post. Hope I don't generate a duplicate post but I just signed > up. > > > Hello, > > First post here from a new Erlang programmer. As an exercise I > have written the message ring benchmark that Joe talked about in > his book: > > -module(cleanring). > -compile(export_all). > > start(N, Msg) -> > StartPid = launch(self(), N), > StartPid ! {Msg, self(), 0}, > receive > {MsgRecvd, _FromPid, _Hop} -> done > end, > StartPid ! die, > MsgRecvd. > > launch(Pid, N) -> > FromPid = spawn(fun() -> loop(Pid) end), > if > N =:= 1 -> FromPid; > true -> launch(FromPid, N-1) > end. > > loop(ToPid) -> > receive > {Term, _FromPid, Hop} -> > ToPid ! {Term, self(), Hop+1}, > loop(ToPid); > die -> > ToPid ! die > end. > > > If I run as follows, it dies in malloc: > > 1> c(cleanring). > 2> L = lists:seq(1,100000). > 3> cleanring:start(32000, L). > > If I make L a binary (in a restarted erl shell) it runs fine (and too > fast to believe): > > 1> c(cleanring). > 2> L = lists:seq(1,100000). > 3> LL = term_to_binary(L). > 4> cleanring:start(32000, LL). > > Is the runtime somehow just passing around a pointer to LL by virtue > of it being a binary? I'm not sure why it doesn't crash as the first > run did. > > You are right, binary messages are send only by passing pointer, but normal structures don't. Normal structures are send by copying because shared nothing processes strategy. Erlang GC don't free message immediately but after some amount of reductions (function calls) and your receive loop in each process is reduced only one time than your big message is kept in memory. Possible solution is explicit garbage collect after message send but it decrease performance for small messages (more than 20%): loop(ToPid) -> receive {Term, _FromPid, Hop} -> ToPid ! {Term, self(), Hop+1}, garbage_collect(), % explicit garbage collect message loop(ToPid); die -> ToPid ! die end. Also, if you spot anything really wrong with the program I'd > appreciate a > heads up. I'm new to Erlang and am sometimes not sure if the code I > write > is in the "right mindset" (functional programming-wise). I think your program is OK, but when you must pass many times huge message, good strategy is avoid this or send binary. > > Thanks > -- > Al > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- --Hynek (Pichi) Vychodil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080308/dad6c7f2/attachment-0001.html From gaperton Sat Mar 8 20:53:45 2008 From: gaperton (Vlad Balin) Date: Sat, 8 Mar 2008 22:53:45 +0300 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D13817.8050604@gmail.com> <7c1602610803080734p1e038ee4xe2039e5873016f4a@mail.gmail.com> Message-ID: <7c1602610803081153u16279e35o7cd6b7cf9a5c2238@mail.gmail.com> > I agree that the proposal below would make for more readable code > (although the difference between split(Buffer, "\n ") and > split(Buffer, [<<"\n">>,<<" ">>]) is not really all that big). A > potential problem is that it could lead to confusion and strange > errors if you intended to write <<"and">> but instead by mistake wrote > "and". I agree that it may lead to confusion. However, consider the case when you provide the list of one symbol separators to detect tokens... IMHO, it's too ugly to represent them as list of binaries. It would be good idea to ask others obout that. > Which other functions where you thinking about? I mean every function receiving Type = binary() | [ binary() ] as an argument. Just checked - there is a single other function - binary:match. Idea was to replace Type with Element = binary() | integer Value = [ Element ] which actually has IOList srtucture. From gbulmer Sat Mar 8 21:39:01 2008 From: gbulmer (G Bulmer) Date: Sat, 8 Mar 2008 20:39:01 +0000 Subject: [erlang-questions] Erlang-DTrace progress report: Erlang-DTrace BIFs Message-ID: Sorry for the slow progress. I've had a little time to work on Erlang- DTrace recently. I am posting this to both Erlang and DTrace groups, so I apologise if somethings are obvious to you. (For Erlang newbies: Erlang has massive advantages over traditional application technology because the Erlang VM can load new code without stopping, or quiescing the applications executing on the Erlang VM.) (For DTrace newbies: DTrace observation can be production systems, on- demand, and in 'real time' from process memory, rather than via file.) There are many pieces to Erlang-DTrace. This piece is about explicit support of DTrace from Erlang; Erlang-DTrace BIFs. The concept is to enable Erlang applications to explicitly choose to expose data to DTrace by providing hooks in Erlang to use DTrace probes. The hooks are provided as new Erlang Built-in-Functions (BIFs). When the DTrace probes are 'off' there is very little overhead. The Erlang program must explicitly use these BIFs. This isn't the only part of Erlang-DTrace, but is quite useful. DTrace probes can be enabled, used, and disabled without interacting with Erlang VMs. DTrace can monitor many VM's, or just one. Further, DTrace can correlate behaviour within the OS kernel and across other applications (e.g. Apache, MySQL, Firefox, etc.), so please read with that multi-application+kernel view in mind, rather than comparing with Erlangs own powerful trace facilities. Anyway ... I've added these Erlang BIFs as an experiment: erlang:is_dtrace_on() -> bool() Returns true if dtrace is observing probe erlang:::dtrace erlang:is_dtrace_off() -> bool() Returns false if dtrace is observing probe erlang:::dtrace erlang:dtrace(Binary) -> binary() triggers the probe erlang:::dtrace passing the Erlang process ID (Pid), and the binary data and size of Binary. erlang:dtrace returns the original Binary as it's value, so that it can be easily inserted into existing code, e.g. binary_to_list(B) can become binary_to_list(erlang:dtrace(B)) without changing it's meaning. The signature of the DTrace probe is: erlang:::dtrace(int Pid, char* binary_data, int binary_data_size) These BIFs can be called like any normal erlang function, from normal Erlang code. ----- Example ---- ( Here is a little dtrace script (with some macros to encapsulate extracting the fields of an Erlang process id): #define PID_NODE(ePid) ((ePid >> 19) & 0x1fff) #define PID_LPID(ePid) ((ePid >> 4) & 0x7ffff) #define PID_SER(ePid) ((ePid >>2) & 0x03) erlang*:::dtrace { printf("erlang* dtrace:"); printf(" pid=<%d.%d.%d> (arg0=0x%x)", PID_NODE(arg0), PID_LPID(arg0), PID_SER(arg0), arg0); s = stringof(copyin(arg1, arg2)); printf(" arg1='%s' (size:%d)\n", s, arg2); } ( Here is an Erlang session, in this case the dtrace script was stared before Erlang, and observes all Erlang Nodes (VMs) started, but it would still work correctly when Erlang Nodes (VMs) are already running, and this dtrace script is started when required: gb$ bin/erl Erlang (BEAM) emulator version 5.6 [source] [smp:2] [async-threads:0] [kernel-poll:false] Eshell V5.6 (abort with ^G) 1> erlang:is_dtrace_on(). true 2> B = <<"">>. <<"">> 3> erlang:dtrace(B). <<"">> 4> erlang:dtrace(<<"HTTP 1.0">>). <<"HTTP 1.0">> 5> erlang:dtrace(erlang:dtrace(B)). <<"">> 6> ( Here's the output of the DTrace session (with blank lines removed): gb$ ./tests.sh dtrace: script 'test1.d' matched 0 probes CPU ID FUNCTION:NAME 0 21486 dtrace_1:dtrace erlang* dtrace: pid=<0.31.0> (arg0=0x1f3) arg1='' (size:13) 0 21486 dtrace_1:dtrace erlang* dtrace: pid=<0.31.0> (arg0=0x1f3) arg1='HTTP 1.0' (size:8) 0 21486 dtrace_1:dtrace erlang* dtrace: pid=<0.31.0> (arg0=0x1f3) arg1='' (size:13) 0 21486 dtrace_1:dtrace erlang* dtrace: pid=<0.31.0> (arg0=0x1f3) arg1='' (size:13) ( tests.sh is a little wrapper to get the options correct: sudo dtrace -C -Z -s test1.d %%---- So, if an Erlang application calls the erlang:dtrace/1 BIF, the binary data is exposed to DTrace if the probe is enabled by dtrace. dtrace can be run at any time, and receives data from the probe *only* while dtrace is running, and the probe enabled. When the dtrace probes are not disabled (not active), there is little overhead (a single BIF call). The dtrace script can do whatever it likes with the data, including correlate across multiple Erlang VM's (Nodes) and other OS processes. Currently, the parameter to erlang:dtrace/1 must be an Erlang Binary, which suites my use case; sockets send and receive Binary data (a byte sequence). This is pre-pre*-alpha-quality. It's not integrated into the Erlang build system, I have to do a 'dtrace -h -s dtrace_probes.d' by hand. The code is in existing erlang source files, and should be factored out. Ideally, is_dtrace_on() and is_dtrace_off() should be allowed in guard expressions, as part of function/case pattern matching to make them more convenient and useful. G Bulmer From per Sat Mar 8 22:02:54 2008 From: per (Per Hedeland) Date: Sat, 8 Mar 2008 22:02:54 +0100 (CET) Subject: [erlang-questions] Passing parameters to a port driver In-Reply-To: <47D2A0FE.9070209@inswitch.us> Message-ID: <200803082102.m28L2s1H060375@pluto.hedeland.org> Sebastian Bello wrote: > >There is no argc/argv in a linked in driver as far as I know. Hm, it was a while ago, but according to your quote I wrote: >> (An external port program would (at least on *nix) get >> the Command in the argc/argv arguments to main()...) I'm sorry, but I'm quite unable to parse that as a claim that a driver would get argc/argv, so I have no idea why you feel the need to state that it doesn't. But you're quite correct of course. > On the >driver side you have > static ErlDrvData driver_start(ErlDrvPort port, char *buff) Exactly, and as I recall your question was what was in the "buff", which I explained. >and buff just points to the driver name; It points to (a C-style copy of) whatever string you passed to open_port/2. As far as open_port is concerned, the driver name ends at the first space (which is quite analogous to / consistent with how the string is parsed in the case of an external port program, though I hesitate to mention it...). > if you load the driver with >parameters you just get an "open_error". Please share the code that gives that result. Of course open_port doesn't "load the driver", but I assume it's open_port you're talking about - anyway that's what *I* am talking about. I'm successfully using the technique I described in commercial product code - in fact it's used in the OTP code too, e.g. in the dbg module. >Any other ideas? None needed. --Per From fredrik.svahn Sat Mar 8 22:34:42 2008 From: fredrik.svahn (Fredrik Svahn) Date: Sat, 8 Mar 2008 22:34:42 +0100 Subject: [erlang-questions] [eeps] EEP 9 In-Reply-To: <7c1602610803080906s4b296cd6wbe4c35a53ce27875@mail.gmail.com> References: <20080304161500.GA7329@erix.ericsson.se> <1204649541.6182.26.camel@pfisher-laptop> <47D13817.8050604@gmail.com> <7c1602610803080734p1e038ee4xe2039e5873016f4a@mail.gmail.com> <7c1602610803080906s4b296cd6wbe4c35a53ce27875@mail.gmail.com> Message-ID: I like this proposal. There is already a proposal to make a copy of the string module for binaries and call it binary_string (and possibly with variants for ascii/utf-x). If it could be merged with the current string module in a backward compatible fashion, all the better. As you say, implementation could become quite messy in some cases when there is a mix of data types. Consider for instance finding "cat" in ["c",<<"a">>, "ts and dogs"] if there are different algorithms for lists and binaries. I guess this would require the definition of string() to be widened somewhat to equal the definition of an iolist() (as defined in e.g. the manual page for the kernel/erlang module). Could this cause any trouble somewhere? I do not know. I would like to have some comments on this proposal. Anyway to sum up where we are now: we are looking into splitting the proposed set of functions into two parts, one binary_string (possibly merged with the current string module depending on the feedback this proposal gets) and one binary module. The string/binary_string module should have the functions in string today + a bif-version of str/2 which is faster and which could search for more than one key (this is the match function in the current version of the EEP). In addition to speeding up tokens/2 I propose a split/2 function which takes a separator string/binary rather than a list of separator chars. Something probably needs to be done about utf-x support as well, I am not sure if this is to big for this EEP or not. The binary module would only need functions for binaries which are not strings, e.g. sub_binary/2,3 from_unsigned/1 to_unsigned/1 first/1,2 last/1,2 nth/2 (different from sub_binary, this gets the nth byte) duplicate/2 match/2,3 (useful even if it isn't a string) split/2,3 (useful even if it isn't a string) In addition I would like to add functions to transform and filter binaries in a more efficient fashion than can be done by binary comprehensions, e.g. by a lookup table as suggested by Jay here: http://www.duomark.com/erlang/publications/acm2005.pdf (chapter 4.1 is especially interesting). This would mean some new built-in functions, binary:translate, binary:extract and possibly some more. BR /Fredrik On Sat, Mar 8, 2008 at 6:06 PM, Vlad Balin wrote: > Yes, and there are another idea, which would lead to more general approach. > > If we allow these functions to work on iolists (!) we could keep just > single module "strings". That would be ideal approach from the > application's programmer: > > 1) Concatenation of binaries is more expensive than making iolist out > of 2 binaries. Therefore, we'll take benefit of extremely cheap string > concatenations. > 2) Function split can be used to reformat iolist. Quite intellegent > operation, which is more general than just strings manipulation. > > I understand that this approach require more effort to implement than > original proposal, but > 1) It features backward compatibility with strings module. > 2) It opens extended possibilities working with binary strings, which > are not present in current languages, making Erlang one of the most > advancel language for string manipulations. Such as "lazy" string > concatenations with iolists. > > 2008/3/8, Vlad Balin : > > > > One more issue. Take this function as an example. > > > > split(Binary, SplitKeys) -> List > > Binary = binary() > > SplitKeys = binary() | [binary()] > > > > > > Wouldn't it be useful to allow integers in SplitKeys in place of > > binaries? We can treat them as 1-byte binaries (should be easy to > > implement), and it will make code more readable in cases when keys > > consist of 1 character. > > > > With this option, we can just write > > > > split( Buffer, "\n " ) > > > > instead of > > > > > binary:match(<<"hello, world\n">>,[<<"\n">>,<<" ">>]). > > > > It can be applied to many functions in this module, and it should > > increase code readability in general. > > > > Thanks, > > > > Vlad. > > > From jay Sun Mar 9 18:53:00 2008 From: jay (Jay Nelson) Date: Sun, 9 Mar 2008 10:53:00 -0700 Subject: [erlang-questions] [eeps] EEP 9 Message-ID: <5FCD7395-3B5E-4F3A-A22C-0DBBFD997BCC@duomark.com> > In addition I would like to add functions to transform and filter > binaries in a more efficient fashion than can be done by binary > comprehensions, e.g. by a lookup table as suggested by Jay here: > http://www.duomark.com/erlang/publications/acm2005.pdf (chapter 4.1 is > especially interesting). This would mean some new built-in functions, > binary:translate, binary:extract and possibly some more. Just a caveat that I did these comparisons on R10B-5 and I have not yet had a chance to rerun using R12B-1. The main speed up in stream_xlate was the elimination of excess memory allocation by pre- allocating the result binary and filling it in place, although the fast table lookup also helped. My understanding of how R12B binaries works using binary comprehensions indicates that you may approach the speed of the BIF now with a direct erlang expression, but I would still expect the BIF to be 2-4x faster (rather than 70-200x, just a random guess on my part): XlatedBinary = << if B >= $A andalso B =< $Z -> B - $A + $a; true -> B end || B <= RawBinary>>. I'm not sure how the result is allocated if there are any filter clauses, I just assume without filter clauses the entire binary size can be pre-computed and pre-allocated. jay From bengt.kleberg Mon Mar 10 09:12:25 2008 From: bengt.kleberg (Bengt Kleberg) Date: Mon, 10 Mar 2008 09:12:25 +0100 Subject: [erlang-questions] Use of makefiles In-Reply-To: References: <1D322437-2C7D-43D9-B228-660DEA296004@rodanotech.ch> <18376.1731.489367.449101@antilipe.corelatus.se> <2E474019-E809-46E5-A2C8-B0E6465D812E@telegraphics.com.au> <9b08084c0802291317o40c25bb1q6f5777ee7f7ebd30@mail.gmail.com> <65b2728e0803011841m4d59d7d8xadb92fc40d93da31@mail.gmail.com> <1204649828.31882.5.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <053657FB-5463-4F29-9FD1-32D83CCC3B4C@telegraphics.com.au> <1204703909.8234.14.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <077D18BE-4E02-4643-82E9-BBB040893467@cs.otago.ac.nz> <1204796240.8525.25.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: <1205136745.25807.13.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, Still OT since we are now talking about C compiling/linking. Since gcc does not need the -lsocket that the SUN C compiler needs for sockets, I think that these differences show up long before the project turns highly unusual. bengt On Fri, 2008-03-07 at 16:29 -0500, Toby Thain wrote: > On 6-Mar-08, at 4:37 AM, Bengt Kleberg wrote: > > > Greetings, > > > > You are correct. If we want to build C programs the different C > > compilers are more of a problem than perl or make incompatibilities. > > Only in highly unusual projects. > > Make can help abstract this in several ways, firstly the name of the > system compiler ($(CC), $(CXX)). > > OT by now though. > --Toby > > > > You > > suggestion that erlang could help with C compilation is a very good > > one. > > > > Thanks for explaining perl to me. It sounds as bad as make. > > > > Building erlang programs is, IMHO, best done with erl -make. Users are > > more interested in having later versions of the program they are > > really > > working with. Make/Perl is only secondary in this scenario. > > > > > > bengt > > > > On Thu, 2008-03-06 at 11:51 +1300, Richard A. O'Keefe wrote: > >> On 5 Mar 2008, at 8:58 pm, Bengt Kleberg wrote: > >>> The question I asked was if a perl program would be more likely > >>> to run > >>> on ''any'' machine, than a makefile. Not because the person who > >>> wrote > >>> the makefile forgot/failed to read the manual for gnu make, but > >>> because > >>> there are other make programs than gnu make out there. The 4 ones I > >>> have > >>> used where not compatible. They would not run each others makefiles. > >> > >> If you stick to what's described in the original Make paper, every > >> Make I > >> have ever come across (save on Windows) is compatible with that. > >> I try > >> to stick to what's described in the Single Unix Specification, and > >> haven't > >> had any trouble with portability. I haven't tried nmake on > >> Windows, but > >> GNU make is available for Windows and can handle POSIX (=SUS) > >> makefiles. > >>> > >>> > >>> I have heard that there is only one perl, so it should be > >>> compatible. > >> > >> It is not true that there is only one Perl. There has been one Perl > >> development > >> stream, but there have been many versions issued in that stream. > >> What > >> works > >> in Perl 5.8.8 might not work in Perl 5.4, and probably won't work in > >> Perl 6 if that > >> ever gets finished. (You are aware that Perl 6 is supposed to be a > >> whole new > >> language?) > >>> > >>> So, is the chance of finding perl on ''any'' computer bigger than > >>> the > >>> chance of finding the right make program for your makefile? > >> > >> I respectfully suggest that there is a bigger problem than makefile > >> compatibility, > >> and that is C compiler command line compatibility. For example, to > >> get optimised > >> code I write > >> cc -O2 foobar.c > >> on one machine, but > >> cc -xO2 foobar.c > >> on another, and on another machine, sadly decommissioned because the > >> vendor > >> having stopped making the hardware and having decided never to > >> upgrade > >> the > >> compiler or operating system nevertheless decided to start charging a > >> really > >> ridiculous licence fee to run the thing in multiuser mode, the > >> command > >> line switches > >> were different again. Come to think of it, I have three C compilers > >> on one machine, > >> all with different switches, so simply checking which operating > >> system > >> it is won't help. > >> > >> When I use R, all of that is handled for me; if I ask the R system to > >> arrange a C (or > >> Fortran) compilation for me, it remembers what worked when it was > >> built, and does > >> it for me. Wouldn't it be nice if installing Erlang gave you > >> erl cc ... > >> that would run a C compiler with all the right switches to work with > >> Erlang? > >> > >>> > >>> > >>> > >>> bengt > >>> > >>> .On Tue, 2008-03-04 at 13:09 -0500, Toby Thain wrote: > >>>> On 4-Mar-08, at 11:57 AM, Bengt Kleberg wrote: > >>>> > >>>>> Greetings, > >>>>> > >>>>> Is it not also the case that perl is more standard than make? > >>>> > >>>> > >>>> Is *everyone* supposed to rewrite make in Perl every time they want > >>>> to build something? > >>>> > >>>>> I know very little of perl, but have fought at least 4 different > >>>>> kinds > >>>>> of make (files). > >>>> > >>>> The GNU make documentation is really very good. I don't know why > >>>> people rarely refer to it. > >>>> > >>>> --T > >>>> > >>>>> > >>>>> > >>>>> bengt > >>>>> > >>>>> On Tue, 2008-03-04 at 10:11 -0600, James Hague wrote: > >>>>>> On Sat, Mar 1, 2008 at 8:41 PM, Steve Vinoski > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi Joe, I agree with you 100%. Give me emacs (with its vast > >>>>>>> emacs-lisp > >>>>>>> extensibility), bash (or ksh), and various UNIX command-line > >>>>>>> tools, > >>>>>>> which I can combine as I wish using pipes, and keep the visual > >>>>>>> tools > >>>>>>> out of my way (and out of my RAM). > >>>>>> > >>>>>> I think this discussion has been misinterpreted :) No one is > >>>>>> arguing > >>>>>> for IDE-like features over makefiles. > >>>>>> > >>>>>> I have found that I don't need makefiles for my Erlang > >>>>>> projects. I > >>>>>> either recompile the same module repeatedly or I want to rebuild > >>>>>> everything. The former is business as usual. The latter is > >>>>>> easily > >>>>>> done with a shell script, Perl script, or short Erlang > >>>>>> program. I > >>>>>> use > >>>>>> makefiles infrequently enough that I always forget the syntax and > >>>>>> nuances of using them. But I can bang out a Perl program that > >>>>>> does > >>>>>> the same thing--even checking file modification dates and so > >>>>>> on--in > >>>>>> very little time. It's more flexible than using a makefile, too, > >>>>>> and > >>>>>> usually ends up being less "code." > >>>>>> _______________________________________________ > >>>>>> erlang-questions mailing list > >>>>>> erlang-questions > >>>>>> http://www.erlang.org/mailman/listinfo/erlang-questions > >>>>> > >>>>> _______________________________________________ > >>>>> erlang-questions mailing list > >>>>> erlang-questions > >>>>> http://www.erlang.org/mailman/listinfo/erlang-questions > >>>> > >>>> _______________________________________________ > >>>> erlang-questions mailing list > >>>> erlang-questions > >>>> http://www.erlang.org/mailman/listinfo/erlang-questions > >>> > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questions > >>> http://www.erlang.org/mailman/listinfo/erlang-questions > >> > >> -- > >> Te Reo Engarihi is a taonga of Te Iwi Pakeha, > >> ergo we should keep it pure, sans m?lange, ruat caelum. > >> > >> > >> > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > From Dmitri.Girenko Mon Mar 10 12:07:18 2008 From: Dmitri.Girenko (Dmitri Girenko) Date: Mon, 10 Mar 2008 13:07:18 +0200 Subject: [erlang-questions] [clarify] Variable binding in case clause and coding style Message-ID: <697074A35ED91748882E3850BDCE295EE09528@leenu.akumiitti.net> Hi all, I have a question about variable binding inside the case clause, that I sometimes use to simplify some code like this: case Endianness of big-> <>; little-> <> end, do_something(A,Rest). But this seems to be a kind of... hack. I wonder what problems can this coding style cause? Can there be any problems with parse transformations? With refactoring tools? Dmitri Girenko Akumiitti Oy From bjorn Mon Mar 10 12:30:18 2008 From: bjorn (Bjorn Gustavsson) Date: 10 Mar 2008 12:30:18 +0100 Subject: [erlang-questions] Help: What's the correct way to add new BIFs? In-Reply-To: <657FD6DD-A7A4-410D-B43E-A2675047D047@gmail.com> References: <657FD6DD-A7A4-410D-B43E-A2675047D047@gmail.com> Message-ID: G Bulmer writes: > I want to add a few new BIFs to erts for some DTrace experiments, and > I'd like some pointers/advice. > (They may not end up in the solution, so please don't panic yet:-) > > Is there a document which describes the correct approach? (I thought > I'd seen it a few months ago, but I, google and spotlight can't find > it :-( > > The questions I'd like some help/advice with are: > 1. I read (in bif.tab) that ubifs are bif's without trace wrappers. Is > this a critical decision, or is it okay to use ubifs, and decide later? You should use bif; ubifs are only for guard BIFs. > This example seems to define the same bif twice. What is this doing > really? What is the atom 'erl.lang.number' or 'erl.lang.binary' for? > (I've read the make_tables script, but my perl is bad, so it isn't > clearto me, sorry.) You only need to define one name for your BIF. The other type of name is for the package system, which is currently unsupported. If you look at the end of the file, you can see that we no longer add duplicate names. > Small point, I read the the syntax productions as is > optional, but: > bif erlang:atom_to_list/1 > bif 'erl.lang.atom':to_string/1 ebif_atom_to_string_1 atom_to_list_1 > > has two. I think the syntax in the bif.tab comment maybe should read: > ::= "bif" {} | "ubif" {} > as {...} is conventionally 0 or more. Yers, the comment is out-of-date. > 3. To be clean and tidy, I feel I should put our new bifs in a new set > of source files (rather than mx them into the existing bif source > files). Yes. > Are there some naming conventions I should follow to align with the > OTP team? We generally use "erl_" prefix for all new source code files. > I assume that the new bifs should be put in a section at the end of > bif.tab. Yes. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bjorn Mon Mar 10 12:39:06 2008 From: bjorn (Bjorn Gustavsson) Date: 10 Mar 2008 12:39:06 +0100 Subject: [erlang-questions] fprof module loading problem on R12B-1 [was: Binary pattern matching inconsistencies with R12B] In-Reply-To: <20080308195002.GA18069@almeida.jinsky.com> References: <20080229174344.GA2361@almeida.jinsky.com> <20080303210149.GA12400@almeida.jinsky.com> <20080308195002.GA18069@almeida.jinsky.com> Message-ID: Rory Byrne writes: > Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] > [kernel-poll:false] > > Eshell V5.6 (abort with ^G) You should update to R12B-1. If I remember correctly, this was one of the bug we fixed for the R12B-1 release. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From francesco Mon Mar 10 12:47:02 2008 From: francesco (Francesco Cesarini) Date: Mon, 10 Mar 2008 11:47:02 +0000 Subject: [erlang-questions] Throughput on Yaws 1.68 / OTP R11B-3 / Suse Linux 10.2? In-Reply-To: <47CC5CBD.3010207@erlang-consulting.com> References: <47CBFA77.9040206@erlang-consulting.com> <47CC52F2.3050108@hyber.org> <47CC5CBD.3010207@erlang-consulting.com> Message-ID: <47D51FB6.6070401@erlang-consulting.com> Just an update for the archives in case others come across this problem in the future. We solved it by writing our own http client, after not having seen any performance degradation with tsung. The bottle neck was not in the inets driver, but in both ibrowse and the inets http client, both of which did not preform that well when scaling up to 1000s of simultaneously open socket connections on the same node (It was misleading as the http client was running at 2 - 3 % CPU while ibrowse was at 100%). Chandru has forwarded us an updated version of ibrowse which we will test soon. Regards, Francesco -- http://www.erlang-consulting.com Francesco Cesarini wrote: > No, not surprisingly, the bottle neck is not Yaws. We got a slight > improvement, which is understandable, but the system still stalls at a > ridiculously low rate and a degradation of service the more we increase > the load. It is still a few thousand hits per second, so most people > would probably not have noticed unless they've run proper stress tests. > I guess we will have to start digging in the inets driver. > > Francesco > -- > http://www.erlang-consulting.com > > Claes Wikstrom wrote: > >> Torbjorn Tornkvist wrote: >> >> >>> You could perhaps try the iserve-server provided by Sean Hinde: >>> >>> http://www.tornkvist.org/gitweb?p=iserve.git;a=summary >>> >>> This way you get the minimal turnaround in Erlang, just to >>> get an idea if the bottleneck is in Yaws or somewhere else. >>> >>> >>> >> If you find that the bottleneck is Yaws - I want to know. >> >> /klacke >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions >> http://www.erlang.org/mailman/listinfo/erlang-questions >> >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > From gbulmer Mon Mar 10 13:17:13 2008 From: gbulmer (G Bulmer) Date: Mon, 10 Mar 2008 12:17:13 +0000 Subject: [erlang-questions] Help: What's the correct way to add new BIFs? In-Reply-To: References: <657FD6DD-A7A4-410D-B43E-A2675047D047@gmail.com> Message-ID: <301A834F-A51A-459A-A311-291CF1800E10@gmail.com> Bjorn Thank you. > G Bulmer writes: >> I want to add a few new BIFs to erts for some DTrace experiments, and >> I'd like some pointers/advice. >> (They may not end up in the solution, so please don't panic yet:-) >> >> Is there a document which describes the correct approach? (I thought >> I'd seen it a few months ago, but I, google and spotlight can't find >> it :-( >> >> The questions I'd like some help/advice with are: >> 1. I read (in bif.tab) that ubifs are bif's without trace wrappers. >> Is >> this a critical decision, or is it okay to use ubifs, and decide >> later? > > You should use bif; ubifs are only for guard BIFs. Thank you. That clears that up. I would like to make the two predicates (is_dtrace_on/0 and is_dtrace_off/0 ) available in guard expressions. I have them in bif.tab as: ubif erlang:is_dtrace_on/0 ubif erlang:is_dtrace_off/0 but they do not show up as directly usable (without the erlang: syntax). If I use that erlang:is_dtrace_on() syntax I get a compile-time error, e.g. : f() when erlang:is_dtrace_on() -> I noticed e.g. is_tuple() is a ubif, and is_tuple() can be used in guards. It's ebif is in erl_pbifs.c, and it's its source is in erl_bif_op.c, and there doesn't appear to be anything magic there. It has an entry in erl_bif_table.c, which is auto-magically generated by make_table. I would like to understand the machinery that enables is_tuple() to appear in guard expressions. It doesn't look different in make_table, and its input bif.tab (is_tuple isn't in atom.names). So I assume that it is possible for us to add new guard predicates, and that I am missing some other piece of machinery. What other things are needed to do enable e.g. is_dtrace_on/0 to work in a 'when' guard? >> This example seems to define the same bif twice. What is this doing >> really? What is the atom 'erl.lang.number' or 'erl.lang.binary' for? >> (I've read the make_tables script, but my perl is bad, so it isn't >> clearto me, sorry.) > > You only need to define one name for your BIF. The other type of name > is for the package system, which is currently unsupported. If you > look at the end of the file, you can see that we no longer add > duplicate > names. That is very helpful. I had read the entries and the end of bif.tab, and have followed that convention, but I felt uncomfortable that I didn't understand what was happening. >> ... snip ... > >> Are there some naming conventions I should follow to align with the >> OTP team? > > We generally use "erl_" prefix for all new source code files. > >> ... snip ... > /Bjorn > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB Thank you again for your help. GB From chsu79 Mon Mar 10 13:21:36 2008 From: chsu79 (Christian S) Date: Mon, 10 Mar 2008 13:21:36 +0100 Subject: [erlang-questions] [clarify] Variable binding in case clause and coding style In-Reply-To: <697074A35ED91748882E3850BDCE295EE09528@leenu.akumiitti.net> References: <697074A35ED91748882E3850BDCE295EE09528@leenu.akumiitti.net> Message-ID: > case Endianness of > big-> <>; > little-> <> > end, > do_something(A,Rest). I rather rewrite it to this: case Endianness of big -> <>, do_something(A,Rest); little -> <>, do_something(A,Rest) end. It is simply easier to understand and not misinterpret. Lexical scoping for teh win. From mats.cronqvist Mon Mar 10 13:48:39 2008 From: mats.cronqvist (Mats Cronqvist) Date: Mon, 10 Mar 2008 13:48:39 +0100 Subject: [erlang-questions] erlang sucks Message-ID: <47D52E27.6060901@kreditor.se> Damien Katz ( of couchDB fame) has written a blog post about the warts of erlang. (http://damienkatz.net/2008/03/what_sucks_abou.html) i find this encouraging, because, as Damien says; "There are the languages everyone complains about, and there are the languages no one uses." excellent news if erlang is moving from the second to the first category. mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080310/d7c2f4e2/attachment.vcf From kosik Mon Mar 10 13:51:17 2008 From: kosik (Matej Kosik) Date: Mon, 10 Mar 2008 13:51:17 +0100 Subject: [erlang-questions] Microsoft Singularity Research OS In-Reply-To: References: Message-ID: <47D52EC5.7010209@fiit.stuba.sk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jay Nelson wrote: > Microsoft has a "new concept" for OS research. It is an operating > system written in C#. > ?Our goal was to make Singularity small enough, simple enough, and > well-designed enough that you can try out radical new ideas quickly,? > Hunt says. ?Our thinking is that a researcher with a great new idea > for improving operating systems could get from idea to published > paper in under a year using Singularity.? > > There are three main principles behind the OS: > > 1) Software-isolated processes (SIPs) > > "Singularity pioneers the use of software-isolated processes (SIPs) > to help protect programs and system services. SIPs enable programs to > be broken down into components that are isolated from other software > components running on the same device. This enables pieces of a > system to fail without risking a total system failure. Consider this > analogy: In a car, the brakes don?t fail if the radio stops working." > > > 2) Contract-based channels for communicating among SIPs > ?We figured out how to describe the form in which communications > should take place between two processes, and using static analysis, > we can check the codes of the processes at compile time,? Hunt > explains. ?So before the code ever runs, we can confirm that the > processes communicate correctly.? > > > 3) Manifest-based programs with resources describing the structure > ?We basically say, if you want to install a program to run on a > Singularity system, you have to provide some information about it so > we can preserve certain properties that make the system more > reliable,? Larus explains. ?You have to provide a manifest of the > program pieces and how they fit together, and we?re going to check > it. More important, we reserve the right to say ?no.? If a certain > program doesn?t follow the rules set down for the system, you can?t > install or run it.? I see a connection between things such as: - - OTP supervision trees in Erlang (for fighting bad-matches in servers) - - or reincarnation server (RS) of Minix3 (for fighting seg-faults in device drivers) and - - strong typing You need either one or the other. I am not sure if you (that much) need both. Do you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1S7FL+CaXfJI/hgRAm+aAJwMk3+SPzuV0a/WBLqPmfiVdpnSUwCgzpex RiXStoBKJDab2YjrmlLWsPo= =j3NP -----END PGP SIGNATURE----- From bjorn Mon Mar 10 14:31:10 2008 From: bjorn (Bjorn Gustavsson) Date: 10 Mar 2008 14:31:10 +0100 Subject: [erlang-questions] Help: What's the correct way to add new BIFs? In-Reply-To: <301A834F-A51A-459A-A311-291CF1800E10@gmail.com> References: <657FD6DD-A7A4-410D-B43E-A2675047D047@gmail.com> <301A834F-A51A-459A-A311-291CF1800E10@gmail.com> Message-ID: G Bulmer writes: > > You should use bif; ubifs are only for guard BIFs. > Thank you. That clears that up. > > I would like to make the two predicates (is_dtrace_on/0 and > is_dtrace_off/0 ) available in guard expressions. > I have them in bif.tab as: > ubif erlang:is_dtrace_on/0 > ubif erlang:is_dtrace_off/0 > Creating a new guard BIF is a lot harder than creating an ordinary BIF, so I suggest you'll wait with doing that. The reason for the difficulties is that guard BIFs are specially optimized and each BIF that can be used in guard must have corresponding BEAM instructions; the new instructions must be supported in both the compiler and the emulator. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From rory Mon Mar 10 15:08:29 2008 From: rory (Rory Byrne) Date: Mon, 10 Mar 2008 15:08:29 +0100 Subject: [erlang-questions] fprof module loading problem on R12B-1 [was: Binary pattern matching inconsistencies with R12B] In-Reply-To: References: <20080229174344.GA2361@almeida.jinsky.com> <20080303210149.GA12400@almeida.jinsky.com> <20080308195002.GA18069@almeida.jinsky.com> Message-ID: <20080310140829.GA22314@almeida.jinsky.com> On Mon, Mar 10, 2008 at 12:39:06PM +0100, Bjorn Gustavsson wrote: > Rory Byrne writes: > > > Erlang (BEAM) emulator version 5.6 [source] [async-threads:0] > > [kernel-poll:false] > > > > Eshell V5.6 (abort with ^G) > > You should update to R12B-1. If I remember correctly, this was one of the > bug we fixed for the R12B-1 release. > Oops! I really thought I was using R12B-1 on this machine. I'm all fixed now. Sorry about that. Rory From gbulmer Mon Mar 10 15:04:10 2008 From: gbulmer (G Bulmer) Date: Mon, 10 Mar 2008 14:04:10 +0000 Subject: [erlang-questions] Help: What's the correct way to add new BIFs? In-Reply-To: References: <657FD6DD-A7A4-410D-B43E-A2675047D047@gmail.com> <301A834F-A51A-459A-A311-291CF1800E10@gmail.com> Message-ID: Bjorn Thank you for the help. I will put guard BIFs on hold :-) GB > G Bulmerwrites: >>> You should use bif; ubifs are only for guard BIFs. >> Thank you. That clears that up. >> >> I would like to make the two predicates (is_dtrace_on/0 and >> is_dtrace_off/0 ) available in guard expressions. >> I have them in bif.tab as: >> ubif erlang:is_dtrace_on/0 >> ubif erlang:is_dtrace_off/0 >> > > Creating a new guard BIF is a lot harder than creating an ordinary > BIF, > so I suggest you'll wait with doing that. > > The reason for the difficulties is that guard BIFs are specially > optimized and > each BIF that can be used in guard must have corresponding BEAM > instructions; > the new instructions must be supported in both the compiler and the > emulator. That sounds non-trivial !-) I'll skip that for now. > /Bjorn > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From ConveyCJ Mon Mar 10 15:15:09 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Mon, 10 Mar 2008 10:15:09 -0400 Subject: [erlang-questions] How many threads does Erlang use? Message-ID: <1C538D67B37E5B4784128A22270DF5C3101CCD6D@npri54exc20.npt.nuwc.navy.mil> I've been experimenting with parallel programming in Erlang, but I'm confused about how many threads Erlang has.. I've got a dual-core Intel x86 processor. When I run what appears to be a single-threaded Erlang function, and without specifying the -smp option, both cores still seem to light up on my box. Can anyone explain that to me? Here's my code, inside z.erl: countdown(0) -> 0 ; countdown(X) -> 1 + countdown(X-1) . Then here's what I run on the command line: cjc:~/z$ erl Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.5.5 (abort with ^G) 1> z:countdown(500000000). And this seems to light up both CPUs, according to my performance monitor. Thanks, Christian From gbulmer Mon Mar 10 15:51:32 2008 From: gbulmer (G Bulmer) Date: Mon, 10 Mar 2008 14:51:32 +0000 Subject: [erlang-questions] erlounge: San Francisco/CA Thursday 13th March, Cambridge/MA Wednesday 18th/Thursday 19th? Message-ID: <2B0A0FD6-6CDE-4B99-894C-A90CC73DE6A4@gmail.com> Would anyone like to meet up for an 'Erlounge' while I am visiting the USA? I am attending the DTrace event at Sun in San Francisco. I am in San Francisco on Thursday 13th March. I can meet up late morning onwards. I am in the Cambridge MA area (actually Waltham) Tuesday 18th and Wednesday 19th March. I can be pretty flexible on where and when we can meet up. If your interested, I could give a quick demo, even a presentation, of Erlang-DTrace that Tim Becker and I are working on (but this is pre- pre*-alpha, so don't get too excited :-) TIA Garry From klacke Mon Mar 10 15:56:35 2008 From: klacke (Claes Wikstrom) Date: Mon, 10 Mar 2008 15:56:35 +0100 Subject: [erlang-questions] web client library In-Reply-To: References: <27ccae8e0802270328v6c7fffcboddab66d0d9f8daa1@mail.gmail.com> Message-ID: <47D54C23.9000901@hyber.org> Christian S wrote: > The ruby-project "hpricot" sets the standard for how convenient > html-scraping should be ( You'll find a decent HTML parser in the yaws code - yaws_html.erl /klacke From hasan.veldstra Mon Mar 10 16:09:57 2008 From: hasan.veldstra (Hasan Veldstra) Date: Mon, 10 Mar 2008 15:09:57 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D52E27.6060901@kreditor.se> References: <47D52E27.6060901@kreditor.se> Message-ID: A rather disappointing article. Erlang does have warts, but of the 8 points made in the article, only 3 are valid in my opinion: the ones on records, documentation, and perhaps code organization. The documentation situation, for one, is bound to improve as the number of Erlang programmers grows. The other two probably will too, given enough push. The important thing is that Erlang gets the hard fundamental stuff right. The rest can be improved with time. On 10 Mar 2008, at 12:48, Mats Cronqvist wrote: > Damien Katz ( of couchDB fame) has written a blog post about the > warts of erlang. > (http://damienkatz.net/2008/03/what_sucks_abou.html) > i find this encouraging, because, as Damien says; "There are the > languages everyone complains about, and there are the languages no > one uses." excellent news if erlang is moving from the second to > the first category. > > > mats______________________________________________ > _ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From jay Mon Mar 10 16:42:30 2008 From: jay (Jay Nelson) Date: Mon, 10 Mar 2008 08:42:30 -0700 Subject: [erlang-questions] [clarify] Variable binding in case clause and coding style Message-ID: <51A92268-CC02-494A-88EC-B03314B63AC7@duomark.com> Christian S wrote: > I rather rewrite it to this: > > case Endianness of > big -> > <>, > do_something(A,Rest); > little -> > <>, > do_something(A,Rest) > end. It is simply easier to understand and not misinterpret. Lexical scoping for teh win. If you don't like the repetition of function names, you can return a new structure which gives fresh variable references and avoid using the ones created in the case branches: {Integer, More} = case Endianness of big -> <>, {A, Rest}; little -> <>, {A, Rest} end, do_something(Integer, More). The main point is that it is error prone to rely on all branches of a case to set variables which are used later. Better to make it explicit and let the compiler help you notice when one is missing. jay From chsu79 Mon Mar 10 16:42:58 2008 From: chsu79 (Christian S) Date: Mon, 10 Mar 2008 16:42:58 +0100 Subject: [erlang-questions] web client library In-Reply-To: <47D54C23.9000901@hyber.org> References: <27ccae8e0802270328v6c7fffcboddab66d0d9f8daa1@mail.gmail.com> <47D54C23.9000901@hyber.org> Message-ID: On Mon, Mar 10, 2008 at 3:56 PM, Claes Wikstrom wrote: > > The ruby-project "hpricot" sets the standard for how convenient > > html-scraping should be ( > You'll find a decent HTML parser in the yaws code - yaws_html.erl Has it been improved since it was first contributed? Because back then when i tried it, it did not handle faulty/ambiguous html that popular browsers handle without complaints. The kind of html that are all over web pages out there. From ConveyCJ Mon Mar 10 16:45:25 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Mon, 10 Mar 2008 11:45:25 -0400 Subject: [erlang-questions] erlang sucks Message-ID: <1C538D67B37E5B4784128A22270DF5C3101CD133@npri54exc20.npt.nuwc.navy.mil> > A rather disappointing article. Erlang does have warts, but > of the 8 points made in the article, only 3 are valid in my > opinion: the ones on records, documentation, and perhaps code > organization. The documentation situation, for one, is bound > to improve as the number of Erlang programmers grows. The > other two probably will too, given enough push. Just speaking from my own impression as a newcommer, I really agree with the original author about the separator-vs.-terminator issue. The separators are a hassle for me. Perhaps in order to make it work nicely, Erlang would need a major shake-up of its tokens and syntax, and thus the change wouldn't be worthwhile. I'm just saying that if I could design Erlang's syntax from scratch it would largely reflect the author's concerns. From armando Mon Mar 10 16:52:07 2008 From: armando (Armando Di Cianno) Date: Mon, 10 Mar 2008 11:52:07 -0400 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> Message-ID: <1205164327.18244.73.camel@localhost> On Mon, 2008-03-10 at 15:09 +0000, Hasan Veldstra wrote: > The important thing is that Erlang gets the hard fundamental stuff > right. The rest can be improved with time. This is very true -- however, it also means that the community now needs to go through the EEP's, massive discussion of somekind, strong arm someone with commit access, or enter into some kind of bureaucratic ordealto do something like improve support for UTF-8 or strings, instead of just /fixing it/. Shouldn't the "hard fundamental stuff" be that which deserves discussion, and the simple, pretty stuff already be in place? With people we are aware of both, can't we get the pretty stuff in place /now/, and improve it's performance /later/? This is clearly going to be a recurring theme in Erlang-world as more and more people see the power in Erlang, and are turned to stone viewing the visage of it's warts. -- Armando Di Cianno http://dicianno.org/blog armando armando From rrerlang Mon Mar 10 17:20:11 2008 From: rrerlang (Robert Raschke) Date: Mon, 10 Mar 2008 16:20:11 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <1C538D67B37E5B4784128A22270DF5C3101CD133@npri54exc20.npt.nuwc.navy.mil> Message-ID: Convey Christian J NPRI writes: > Just speaking from my own impression as a newcommer, I really agree > with the original author about the separator-vs.-terminator issue. > The separators are a hassle for me. Not sure if this is visible enough in the documentation, but "comma" reads as "and", "semicolon" reads as "or", and the full stop should be self explanatory. Pretty straightforward. (Yes, this comes from the Prolog heritage.) I think people get hung up about this, because it is easy to have an opinion on. Kinda like indentation, or _ vs CamelCaps. Robby PS I actually think the syntax differences are great, cause it means I don't get suckered into writing Java code in Erlang! From rsaccon Mon Mar 10 17:25:42 2008 From: rsaccon (Roberto Saccon) Date: Mon, 10 Mar 2008 13:25:42 -0300 Subject: [erlang-questions] web client library In-Reply-To: References: <27ccae8e0802270328v6c7fffcboddab66d0d9f8daa1@mail.gmail.com> <47D54C23.9000901@hyber.org> Message-ID: mochiweb also has a decent HTML parser On Mon, Mar 10, 2008 at 12:42 PM, Christian S wrote: > On Mon, Mar 10, 2008 at 3:56 PM, Claes Wikstrom wrote: > > > The ruby-project "hpricot" sets the standard for how convenient > > > html-scraping should be ( > > You'll find a decent HTML parser in the yaws code - yaws_html.erl > > Has it been improved since it was first contributed? > > Because back then when i tried it, it did not handle faulty/ambiguous > html that popular browsers handle without complaints. The kind of > html that are all over web pages out there. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Roberto Saccon http://rsaccon.com From bekesa Mon Mar 10 17:10:49 2008 From: bekesa (Andras Georgy Bekes) Date: Mon, 10 Mar 2008 17:10:49 +0100 Subject: [erlang-questions] =?iso-8859-1?q?=5Bclarify=5D_Variable_binding_?= =?iso-8859-1?q?in_case_clause=09and_coding_style?= In-Reply-To: <51A92268-CC02-494A-88EC-B03314B63AC7@duomark.com> References: <51A92268-CC02-494A-88EC-B03314B63AC7@duomark.com> Message-ID: <200803101710.49682.bekesa@sch.bme.hu> > The main point is that it is error prone to rely on all branches of a > case to set variables which are used later. Why? The compiler helps you notice when one is missing. Complains like this (error message, not warning): variable 'X' unsafe in 'case' (line XXX) > Better to make it > explicit and let the compiler help you notice when one is missing. For that reason I don't understand this. Georgy From kevin Mon Mar 10 18:03:05 2008 From: kevin (Kevin Scaldeferri) Date: Mon, 10 Mar 2008 10:03:05 -0700 Subject: [erlang-questions] web client library In-Reply-To: References: <27ccae8e0802270328v6c7fffcboddab66d0d9f8daa1@mail.gmail.com> <47D54C23.9000901@hyber.org> Message-ID: Personally, I find it frustrating that general-purpose tools like this seem to be buried inside large frameworks. I think it would be quite beneficial to the community, and to adoption, if these base utilities were pulled out and distributed separately. -kevin On Mar 10, 2008, at 9:25 AM, Roberto Saccon wrote: > mochiweb also has a decent HTML parser > > On Mon, Mar 10, 2008 at 12:42 PM, Christian S > wrote: >> On Mon, Mar 10, 2008 at 3:56 PM, Claes Wikstrom >> wrote: >>>> The ruby-project "hpricot" sets the standard for how convenient >>>> html-scraping should be ( >>> You'll find a decent HTML parser in the yaws code - yaws_html.erl >> >> Has it been improved since it was first contributed? >> >> Because back then when i tried it, it did not handle faulty/ambiguous >> html that popular browsers handle without complaints. The kind of >> html that are all over web pages out there. >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions >> http://www.erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > Roberto Saccon > http://rsaccon.com > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From chsu79 Mon Mar 10 18:35:54 2008 From: chsu79 (Christian S) Date: Mon, 10 Mar 2008 18:35:54 +0100 Subject: [erlang-questions] web client library In-Reply-To: References: <27ccae8e0802270328v6c7fffcboddab66d0d9f8daa1@mail.gmail.com> <47D54C23.9000901@hyber.org> Message-ID: On Mon, Mar 10, 2008 at 6:03 PM, Kevin Scaldeferri wrote: > Personally, I find it frustrating that general-purpose tools like this > seem to be buried inside large frameworks. I think it would be quite > beneficial to the community, and to adoption, if these base utilities > were pulled out and distributed separately. Swedish lesson #1: "Du har hela helgen p? dig." English: You have the whole weekend for it. From kevin Mon Mar 10 18:43:19 2008 From: kevin (Kevin Scaldeferri) Date: Mon, 10 Mar 2008 10:43:19 -0700 Subject: [erlang-questions] web client library In-Reply-To: References: <27ccae8e0802270328v6c7fffcboddab66d0d9f8daa1@mail.gmail.com> <47D54C23.9000901@hyber.org> Message-ID: <6CDBA3B2-83C9-4E80-BA28-DF97ADE9E378@scaldeferri.com> On Mar 10, 2008, at 10:35 AM, Christian S wrote: > On Mon, Mar 10, 2008 at 6:03 PM, Kevin Scaldeferri > wrote: >> Personally, I find it frustrating that general-purpose tools like >> this >> seem to be buried inside large frameworks. I think it would be quite >> beneficial to the community, and to adoption, if these base utilities >> were pulled out and distributed separately. > > Swedish lesson #1: "Du har hela helgen p? dig." > > English: You have the whole weekend for it. Actually, that is how I spent a good chunk of my weekend :-) Although, I'm not particularly clear what to do next... We seem to have this proliferation of repositories / distribution systems. Should I just submit stuff everywhere? -kevin From jay Mon Mar 10 18:50:05 2008 From: jay (Jay Nelson) Date: Mon, 10 Mar 2008 10:50:05 -0700 Subject: [erlang-questions] (no subject) Message-ID: Georgy wrote: > Jay wrote: > > The main point is that it is error prone to rely on all branches of a > > case to set variables which are used later. > Why? The compiler helps you notice when one is missing. > Complains like this (error message, not warning): > variable 'X' unsafe in 'case' (line XXX) > > Jay wrote: > > Better to make it > > explicit and let the compiler help you notice when one is missing. > For that reason I don't understand this. I stand corrected. I wasn't aware of the compiler error because I avoid that style of code. The reason I avoid it, is that I find it more difficult to visually verify in the editor. Also, if more clauses are added in the future, you have to keep track that the following code relies on setting some variables (or else, apparently, wait until you compile to notice you need some others). I just find that the following style: { ... args needed ... } = compound statement, use args advertises the programmer's intent much more clearly. It states that the compound statement is being executed for the side effect of binding a particular set of variables. This binding environment is necessary for the following statements. It corresponds to a (let (...) ...) clause in lisp. jay From chsu79 Mon Mar 10 19:09:56 2008 From: chsu79 (Christian S) Date: Mon, 10 Mar 2008 19:09:56 +0100 Subject: [erlang-questions] web client library In-Reply-To: <6CDBA3B2-83C9-4E80-BA28-DF97ADE9E378@scaldeferri.com> References: <27ccae8e0802270328v6c7fffcboddab66d0d9f8daa1@mail.gmail.com> <47D54C23.9000901@hyber.org> <6CDBA3B2-83C9-4E80-BA28-DF97ADE9E378@scaldeferri.com> Message-ID: > Although, I'm not particularly clear what to do next... We seem to > have this proliferation of repositories / distribution systems. > Should I just submit stuff everywhere? In spirit with Joe Armstrong's "If you add something, you need to take something away": For a component to survive away from its monolithic project it is important to backport it so your component is used where you have torn it out from. Otherwise you have only forked development. As for hosting, you have tons of alternatives. It is not really an issue. From alpar Mon Mar 10 19:16:35 2008 From: alpar (=?ISO-8859-1?Q?Alp=E1r_J=FCttner?=) Date: Mon, 10 Mar 2008 18:16:35 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: References: Message-ID: <1205172995.6705.25.camel@piko.site> On Mon, 2008-03-10 at 16:20 +0000, Robert Raschke wrote: > Convey Christian J NPRI writes: > > Just speaking from my own impression as a newcommer, I really agree > > with the original author about the separator-vs.-terminator issue. > > The separators are a hassle for me. [snip] > I think people get hung up about this, because it is easy to have an > opinion on. Kinda like indentation, or _ vs CamelCaps. I don't think so. This is more like a practical thing: it is indeed a little bit cumbersome to reorganize the branches because you have to change the line endings. Not a big issue, anyway. Regards, Alpar > Robby > > PS I actually think the syntax differences are great, cause it means I > don't get suckered into writing Java code in Erlang! > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From bob Mon Mar 10 19:37:14 2008 From: bob (Bob Ippolito) Date: Mon, 10 Mar 2008 11:37:14 -0700 Subject: [erlang-questions] web client library In-Reply-To: References: <27ccae8e0802270328v6c7fffcboddab66d0d9f8daa1@mail.gmail.com> <47D54C23.9000901@hyber.org> Message-ID: <6a36e7290803101137l62ad0702lb3c19bec23373315@mail.gmail.com> mochiweb isn't very large, and the html parser/generator module is largely standalone. It depends on mochiweb_charref and it uses the float encoder from mochinum if you give it a float to encode. Pulling these things out would simply be a pain in the ass, Erlang does not have good distribution tools yet. Our primary goal is to get work done, and having a whole bunch of libraries to deal with (both as the producers and consumers of these modules) is counter to that. On Mon, Mar 10, 2008 at 10:03 AM, Kevin Scaldeferri wrote: > Personally, I find it frustrating that general-purpose tools like this > seem to be buried inside large frameworks. I think it would be quite > beneficial to the community, and to adoption, if these base utilities > were pulled out and distributed separately. > > > -kevin > > > > > On Mar 10, 2008, at 9:25 AM, Roberto Saccon wrote: > > > mochiweb also has a decent HTML parser > > > > On Mon, Mar 10, 2008 at 12:42 PM, Christian S > > wrote: > >> On Mon, Mar 10, 2008 at 3:56 PM, Claes Wikstrom > >> wrote: > >>>> The ruby-project "hpricot" sets the standard for how convenient > >>>> html-scraping should be ( > >>> You'll find a decent HTML parser in the yaws code - yaws_html.erl > >> > >> Has it been improved since it was first contributed? > >> > >> Because back then when i tried it, it did not handle faulty/ambiguous > >> html that popular browsers handle without complaints. The kind of > >> html that are all over web pages out there. > >> > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions > >> http://www.erlang.org/mailman/listinfo/erlang-questions > >> > > > > > > > > -- > > Roberto Saccon > > http://rsaccon.com > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From dmercer Mon Mar 10 19:41:03 2008 From: dmercer (David Mercer) Date: Mon, 10 Mar 2008 13:41:03 -0500 Subject: [erlang-questions] web client library In-Reply-To: <6CDBA3B2-83C9-4E80-BA28-DF97ADE9E378@scaldeferri.com> References: <27ccae8e0802270328v6c7fffcboddab66d0d9f8daa1@mail.gmail.com><47D54C23.9000901@hyber.org> <6CDBA3B2-83C9-4E80-BA28-DF97ADE9E378@scaldeferri.com> Message-ID: <005501c882de$54058e60$891ea8c0@SSI.CORP> > Although, I'm not particularly clear what to do next... We seem to > have this proliferation of repositories / distribution systems. > Should I just submit stuff everywhere? I think the Erlang way is to embed it in your pet project, which you host on a web site of your choice. Whenever someone asks on this list for a module that does what your module does, reply by pointing them to your pet project. That way, you get free advertising for your pet project. DBM -----Original Message----- From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Kevin Scaldeferri Sent: Monday, March 10, 2008 12:43 To: Christian S Cc: erlang-questions Subject: Re: [erlang-questions] web client library On Mar 10, 2008, at 10:35 AM, Christian S wrote: > On Mon, Mar 10, 2008 at 6:03 PM, Kevin Scaldeferri > wrote: >> Personally, I find it frustrating that general-purpose tools like >> this >> seem to be buried inside large frameworks. I think it would be quite >> beneficial to the community, and to adoption, if these base utilities >> were pulled out and distributed separately. > > Swedish lesson #1: "Du har hela helgen p? dig." > > English: You have the whole weekend for it. Actually, that is how I spent a good chunk of my weekend :-) Although, I'm not particularly clear what to do next... We seem to have this proliferation of repositories / distribution systems. Should I just submit stuff everywhere? -kevin _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From mazen Mon Mar 10 20:04:48 2008 From: mazen (Mazen Harake) Date: Mon, 10 Mar 2008 19:04:48 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: References: Message-ID: <47D58650.9030803@erlang-consulting.com> Robert Raschke wrote: > Convey Christian J NPRI writes: > >> Just speaking from my own impression as a newcommer, I really agree >> with the original author about the separator-vs.-terminator issue. >> The separators are a hassle for me. >> > > Not sure if this is visible enough in the documentation, but > "comma" reads as "and", > "semicolon" reads as "or", > and the full stop should be self explanatory. > Pretty straightforward. > > (Yes, this comes from the Prolog heritage.) > > I think people get hung up about this, because it is easy to have an > opinion on. Kinda like indentation, or _ vs CamelCaps. > > Robby > > PS I actually think the syntax differences are great, cause it means I > don't get suckered into writing Java code in Erlang! > I was sitting and thinking about writing and defending the syntax a little bit since I don't agree with many of the complaints, however, when I read these two last lines I think it says it all. Very well put, bravo! > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Mazen Harake Erlang Software Developer and Consultant, Erlang Training & Consulting, Ltd Mobile Phone: +44 (0)795 13 26 317 Office Phone: +44 (0)207 45 61 020 Office Address: 401 London Fruit & Wool Exchange Brushfield St, London, E1 6EL United Kingdom This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of "Erlang Training & Consulting, Ltd". If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error. From stondage123 Mon Mar 10 21:08:40 2008 From: stondage123 (Andrew Stone) Date: Mon, 10 Mar 2008 13:08:40 -0700 (PDT) Subject: [erlang-questions] EUnit Message-ID: <567995.67741.qm@web35914.mail.mud.yahoo.com> All, I've been experimenting with EUnit for a bit and have a quick question. I wrote some test cases and they work fine when run with Module:test(). How do I run all my unit tests in a given directory. Do I have to wrap them by hand? The edoc seems a little light here. Thanks, Andrew From tobbe Mon Mar 10 22:11:48 2008 From: tobbe (Torbjorn Tornkvist) Date: Mon, 10 Mar 2008 22:11:48 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: Perhaps a stupid question. Do LFE implement currying? If not, why? I want currying... :-) --Tobbe Robert Virding wrote: > I have finally released LFE, Lisp Flavoured Erlang, which is a lisp > syntax front-end to the Erlang compiler. Code produced with it is > compatible with "normal" Erlang code. The is an LFE-mode for Emacs and > the lfe-mode.el file is include in the distribution. Most things seem to > work but some things have not been done yet: > > - The interpreter does handle recursive letrecs, binaries, receive or try. > - There is no lisp shell. > - Documentation! > > Yet. The system will be updated as new features are added. This is the > 1st release so there is much left to do. > > I have include the existing documentation lfe_guide.txt in this mail. > There are a number of LFE test files and a version of the LFE > interpreter written in LFE as examples of code. There are also a number > of issues which need to be decided for the next version and I have > included a file lfe_issues.txt which describe them in this mail. Both > files are in the distribution. > > Note that while this this lisp has been inspired by Scheme (one of the > issues) it is a NOT Scheme, it is Erlang with a lisp syntax and many > nice lisp features. Not for that matter is it Common Lisp. In fact > features of the Erlang engine mean that it is actually impossible to > implement full Scheme of CL. No, they shouldn't be changed or added. > > It was quite writing Erlang code in lisp and I could easily consider > using a lisp syntax for Erlang. I suppose it depends where your > preferences lye. It was also easy to get into the traditional lisp habit > of using long names for everything which I personally think is not a > Good Thing. Perhaps we should do AFE, Arc Flavoured Erlang, instead? > Although I think they have gone too far and missed what makes programs > easy to read. > > Macros are very nice, and it is easy to generate LFE code, which is one > of the benefits of lisp syntax. > > LFE also shows that it would probably be possible to write other > front-ends inspired by other languages, though why anyone should want to > I don't know. Perhaps back to a real Prolog syntax again. > > The system can be found in the "User Contributions" section at > trapexit.org , > http://forum.trapexit.org/viewtopic.php?p=40268#40268. > From rvirding Mon Mar 10 22:14:25 2008 From: rvirding (Robert Virding) Date: Mon, 10 Mar 2008 22:14:25 +0100 Subject: [erlang-questions] (no subject) In-Reply-To: References: Message-ID: <3dbc6d1c0803101414u2fb8e9adja1f6e2ae276da5ce@mail.gmail.com> On 10/03/2008, Jay Nelson wrote: > > I stand corrected. I wasn't aware of the compiler error because I > avoid that style of code. > > The reason I avoid it, is that I find it more difficult to visually > verify in the editor. Also, if more clauses are added in the future, > you have to keep track that the following code relies on setting some > variables (or else, apparently, wait until you compile to notice you > need some others). > > I just find that the following style: > > { ... args needed ... } = compound statement, > use args > > advertises the programmer's intent much more clearly. It states that > the compound statement is being executed for the side effect of > binding a particular set of variables. This binding environment is > necessary for the following statements. It corresponds to a (let > (...) ...) clause in lisp. Yes, it is a matter of style which method you use. The scope of variables is the whole function clause. I also prefer returning the values which are "exported" from the if/case/receive, it is clearer, but I am not always consistent in this I know. Although many prefer just exporting them. Unfortunately it is impossible to be completely consistent all the time as the compiler quite happily exports all variables which are bound in all clauses. This can cause some confusion. So if you have: case ... of ... -> ..., Tmp = ..., ...; ... -> ..., Tmp = ..., ...; ... end, where Tmp is bound in all clauses then Tmp will automatically be exported. And if it is then later used it will already be bound, which can cause some confusion. So you have to be certain to use unique names for temporary variables. This is another reason to avoid large function clauses where it can be harder to see reuse. There is no way around this. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080310/61b96f7d/attachment.html From dmercer Mon Mar 10 22:35:58 2008 From: dmercer (David Mercer) Date: Mon, 10 Mar 2008 16:35:58 -0500 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205172995.6705.25.camel@piko.site> References: <1205172995.6705.25.camel@piko.site> Message-ID: <006501c882f6$bc4ae610$891ea8c0@SSI.CORP> I complained about this issue 7 months ago: http://www.erlang.org/pipermail/erlang-questions/2007-August/028516.html In the end, LFE might be the way to go. I have not had time to take a look however. Anyone have anything bad to say about it? DBM -----Original Message----- From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Alp?r J?ttner Sent: Monday, March 10, 2008 13:17 To: Robert Raschke Cc: erlang-questions Subject: Re: [erlang-questions] erlang sucks On Mon, 2008-03-10 at 16:20 +0000, Robert Raschke wrote: > Convey Christian J NPRI writes: > > Just speaking from my own impression as a newcommer, I really agree > > with the original author about the separator-vs.-terminator issue. > > The separators are a hassle for me. [snip] > I think people get hung up about this, because it is easy to have an > opinion on. Kinda like indentation, or _ vs CamelCaps. I don't think so. This is more like a practical thing: it is indeed a little bit cumbersome to reorganize the branches because you have to change the line endings. Not a big issue, anyway. Regards, Alpar > Robby > > PS I actually think the syntax differences are great, cause it means I > don't get suckered into writing Java code in Erlang! > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From richardc Mon Mar 10 22:42:53 2008 From: richardc (Richard Carlsson) Date: Mon, 10 Mar 2008 22:42:53 +0100 Subject: [erlang-questions] EUnit In-Reply-To: <567995.67741.qm@web35914.mail.mud.yahoo.com> References: <567995.67741.qm@web35914.mail.mud.yahoo.com> Message-ID: <47D5AB5D.30703@it.uu.se> Andrew Stone wrote: > All, > I've been experimenting with EUnit for a bit and have a quick question. > I wrote some test cases and they work fine when run with Module:test(). > > How do I run all my unit tests in a given directory. Do I have to wrap them by hand? > The edoc seems a little light here. I'd suggest that you treat that just like any fixture setup, i.e., use a {setup, ...}, with a setup part that fetches the current directory with file:get_cwd(), sets the new directory with file:set_cwd(), and returns the old value; and a cleanup part that does set_cwd to get back to the original directory. /Richard From stondage123 Mon Mar 10 23:05:02 2008 From: stondage123 (Andrew Stone) Date: Mon, 10 Mar 2008 15:05:02 -0700 (PDT) Subject: [erlang-questions] EUnit Message-ID: <343189.35763.qm@web35914.mail.mud.yahoo.com> Thanks Richard. But I'm still having a little trouble. What I meant was how do I create a fixture etc...? Do I just add the appropriate tuples to a test file that includes eunit.hrl? Any help would be appreciated. Thanks, Andrew ----- Original Message ---- From: Richard Carlsson To: Andrew Stone Cc: erlang-questions Sent: Monday, March 10, 2008 5:42:53 PM Subject: Re: [erlang-questions] EUnit Andrew Stone wrote: > All, > I've been experimenting with EUnit for a bit and have a quick question. > I wrote some test cases and they work fine when run with Module:test(). > > How do I run all my unit tests in a given directory. Do I have to wrap them by hand? > The edoc seems a little light here. I'd suggest that you treat that just like any fixture setup, i.e., use a {setup, ...}, with a setup part that fetches the current directory with file:get_cwd(), sets the new directory with file:set_cwd(), and returns the old value; and a cleanup part that does set_cwd to get back to the original directory. /Richard From rvirding Mon Mar 10 23:11:07 2008 From: rvirding (Robert Virding) Date: Mon, 10 Mar 2008 23:11:07 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <006501c882f6$bc4ae610$891ea8c0@SSI.CORP> References: <1205172995.6705.25.camel@piko.site> <006501c882f6$bc4ae610$891ea8c0@SSI.CORP> Message-ID: <3dbc6d1c0803101511l59782af1o6143b2a2de462d78@mail.gmail.com> On 10/03/2008, David Mercer wrote: > > I complained about this issue 7 months ago: > http://www.erlang.org/pipermail/erlang-questions/2007-August/028516.html > > In the end, LFE might be the way to go. I have not had time to take a > look > however. Anyone have anything bad to say about it? The trouble with LFE is that it uses lisp syntax, and look on the net how difficult many find lisp syntax. :-) I don't have any trouble with it, after a while you count parentheses automatically, but many fall back in horror. There is nothing bad you can say about it. :-) "Practically perfect in every way", or soon will be anyway. Robert (the culprit) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080310/a87a2cff/attachment.html From justin Mon Mar 10 23:24:47 2008 From: justin (Justin T. Sampson) Date: Mon, 10 Mar 2008 15:24:47 -0700 Subject: [erlang-questions] erlounge: San Francisco/CA Thursday 13th March, Cambridge/MA Wednesday 18th/Thursday 19th? In-Reply-To: <2B0A0FD6-6CDE-4B99-894C-A90CC73DE6A4@gmail.com> References: <2B0A0FD6-6CDE-4B99-894C-A90CC73DE6A4@gmail.com> Message-ID: On Mon, Mar 10, 2008 at 7:51 AM, G Bulmer wrote: > I am in San Francisco on Thursday 13th March. I can meet up late > morning onwards. I'm in San Francisco, and I can never make it to evening Erlounges, so how about lunch on Thursday? Downtown is best for me (I work near Market & 3rd St.). Cheers, Justin From rvirding Mon Mar 10 23:26:28 2008 From: rvirding (Robert Virding) Date: Mon, 10 Mar 2008 23:26:28 +0100 Subject: [erlang-questions] Erlang Syntax - again Message-ID: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Hello all, I have read Damien's post and Yariv's reply. My question is: they say what they don't want, but what do they actually want? I mean this question seriously. Perhaps someone who is new to the language could answer and tell what they found most difficult when learning the syntax. I have spoken Erlang so long that I see it as natural, warts and all. Even records look like they do for a specific reason and it is harder than you would think to change them. Other Erlang features force issues. Getting back. What do people want? Do they want something that looks like Java, or C++, or Python, or Perl, or ... ? This is actually possible to do, BUT (there is always a but) you would not have the Java or C++ or Python or ... semantics, you would still have Erlang semantics. Would we then get complaints that while it looks like Java it doesn't behave like Java, and why not? As I said I am serious about this question, even if we don't do a JFE (Java Flavoured Erlang) it would be interesting to know what people want. Do people know what they want? Is or is it just that it looks and behaves differently to what they are used? Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080310/38183b2f/attachment-0001.html From per Mon Mar 10 23:29:02 2008 From: per (Per Hedeland) Date: Mon, 10 Mar 2008 23:29:02 +0100 (CET) Subject: [erlang-questions] Use of makefiles In-Reply-To: <1205136745.25807.13.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: <200803102229.m2AMT2q9024026@pluto.hedeland.org> Bengt Kleberg wrote: > >Still OT since we are now talking about C compiling/linking. > >Since gcc does not need the -lsocket that the SUN C compiler needs for >sockets, I think that these differences show up long before the project >turns highly unusual. Not sure if it matters much for the discussion, but differences in required libraries are generally (always?) dependent on the OS, not the compiler. On Solaris, which is probably the only place you use the Sun C compiler, you need -lsocket, whereas on most OSes where gcc is the "standard" compiler, you don't - which is probably the source of your misunderstanding. --Per Hedeland $ uname -sr SunOS 5.10 $ echo 'main(){socket();}' > xxx.c $ gcc xxx.c Undefined first referenced symbol in file socket /var/tmp//ccQwllM5.o ld: fatal: Symbol referencing errors. No output written to a.out collect2: ld returned 1 exit status $ gcc xxx.c -lsocket $ From rvirding Mon Mar 10 23:30:26 2008 From: rvirding (Robert Virding) Date: Mon, 10 Mar 2008 23:30:26 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: <3dbc6d1c0803101530j31ea63b4wc6bbb5dafe6c1e1d@mail.gmail.com> On 10/03/2008, Torbjorn Tornkvist wrote: > > > Perhaps a stupid question. Do LFE implement currying? > If not, why? > > I want currying... :-) > > --Tobbe Nope, not until it is supported in the VM and by the language*. Write some macros for it. Robert * I personally think that the way Erlang is defined today will always make currying in Erlang a bit of a hack, and a rather risky hack at that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080310/89e9d86b/attachment.html From kevin Mon Mar 10 23:44:30 2008 From: kevin (Kevin Scaldeferri) Date: Mon, 10 Mar 2008 15:44:30 -0700 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: On Mar 10, 2008, at 2:11 PM, Torbjorn Tornkvist wrote: > > Perhaps a stupid question. Do LFE implement currying? > If not, why? > > I want currying... :-) > Here's something I threw together in a couple minutes: %% F({a,b}) -> F'(a,b) curry(F, Arity) -> if Arity =:= 1 -> fun(A) -> F({A}) end; Arity =:= 2 -> fun(A,B) -> F({A,B}) end; Arity =:= 3 -> fun(A,B,C) -> F({A,B,C}) end; Arity =:= 4 -> fun(A,B,C,D) -> F({A,B,C,D}) end; Arity =:= 5 -> fun(A,B,C,D,E) -> F({A,B,C,D,E}) end; true -> throw(unsupported_arity) end. %% F(a,b) -> F'({a,b}) uncurry(F) -> fun(Tuple) -> apply(F, tuple_to_list(Tuple)) end. A gross hack, to be sure, although I can't see how you could have any hope to avoid having to specify an Arity to curry(). Maybe there's a way to implement it less horribly, though. BTW, did you actually mean that you want partial application? Via a similar process: papply(F, Arity, Arg) -> if Arity =:= 1 -> fun() -> F(Arg) end; Arity =:= 2 -> fun(A) -> F(Arg,A) end; Arity =:= 3 -> fun(A,B) -> F(Arg,A,B) end; Arity =:= 4 -> fun(A,B,C) -> F(Arg,A,B,C) end; Arity =:= 5 -> fun(A,B,C,D) -> F(Arg,A,B,C,D) end; true -> throw(unsupported_arity) end. -kevin From kevin Mon Mar 10 23:58:30 2008 From: kevin (Kevin Scaldeferri) Date: Mon, 10 Mar 2008 15:58:30 -0700 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: On Mar 10, 2008, at 3:26 PM, Robert Virding wrote: > Hello all, > > I have read Damien's post and Yariv's reply. My question is: they > say what they don't want, but what do they actually want? I mean > this question seriously. Perhaps someone who is new to the language > could answer and tell what they found most difficult when learning > the syntax. I have spoken Erlang so long that I see it as natural, > warts and all. "if" is very unintuitive. As best as I can remember, everything else was a minor annoyance at worst. I certainly wouldn't complain if lambda functions and records were less verbose, but they weren't _difficult_ to learn the syntax. > > Even records look like they do for a specific reason and it is > harder than you would think to change them. Other Erlang features > force issues. > > Getting back. What do people want? Do they want something that looks > like Java, or C++, or Python, or Perl, or ... ? This is actually > possible to do, BUT (there is always a but) you would not have the > Java or C++ or Python or ... semantics, you would still have Erlang > semantics. Would we then get complaints that while it looks like > Java it doesn't behave like Java, and why not? Personally, I would like it if functional programming were better supported and less verbose. (i.e., function composition, lambda functions, currying and partial application, etc). user-defined infix operators might also be nice. -kevin From kevin Tue Mar 11 00:25:51 2008 From: kevin (Kevin Scaldeferri) Date: Mon, 10 Mar 2008 16:25:51 -0700 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: On Mar 10, 2008, at 3:44 PM, Kevin Scaldeferri wrote: > > On Mar 10, 2008, at 2:11 PM, Torbjorn Tornkvist wrote: > >> >> Perhaps a stupid question. Do LFE implement currying? >> If not, why? >> >> I want currying... :-) >> > > Here's something I threw together in a couple minutes: > > %% F({a,b}) -> F'(a,b) > curry(F, Arity) -> > if > Arity =:= 1 -> fun(A) -> F({A}) end; > Arity =:= 2 -> fun(A,B) -> F({A,B}) end; > Arity =:= 3 -> fun(A,B,C) -> F({A,B,C}) end; > Arity =:= 4 -> fun(A,B,C,D) -> F({A,B,C,D}) end; > Arity =:= 5 -> fun(A,B,C,D,E) -> F({A,B,C,D,E}) end; > true -> throw(unsupported_arity) > end. > Should do slightly more browsing of the docs before posting :-). This is a slight improvement: %% F({a,b}) -> F'(a,b) curry(F) -> {arity, Arity} = erlang:fun_info(F, arity), if Arity =:= 1 -> fun(A) -> F({A}) end; Arity =:= 2 -> fun(A,B) -> F({A,B}) end; Arity =:= 3 -> fun(A,B,C) -> F({A,B,C}) end; Arity =:= 4 -> fun(A,B,C,D) -> F({A,B,C,D}) end; Arity =:= 5 -> fun(A,B,C,D,E) -> F({A,B,C,D,E}) end; true -> throw(unsupported_arity) end. From chandrashekhar.mullaparthi Tue Mar 11 00:28:48 2008 From: chandrashekhar.mullaparthi (Chandru) Date: Mon, 10 Mar 2008 23:28:48 +0000 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: On 10/03/2008, Robert Virding wrote: > Hello all, > > I have read Damien's post and Yariv's reply. My question is: they say what > they don't want, but what do they actually want? I mean this question > seriously. Perhaps someone who is new to the language could answer and tell > what they found most difficult when learning the syntax. I have spoken > Erlang so long that I see it as natural, warts and all. I was new to the language ten years ago. I didn't understand how I could write serious programs with single assignment. 30 minutes later that problem was solved. I've never really looked back since then. All the complaints about erlang seem whimsical at best and attention seeking at worst. I've written a fair amount of erlang code over the years, and I honestly can't think of any time when I felt that the erlang was impeding my progress. And it is getting better by the day. The bit syntax, xref, dialyzer, typer, SMP erlang... I remember being quite delighted when records came along in erlang. Suddenly it became much easier to maintain state in servers. All these complaints remind me of this article: http://www.kenrockwell.com/tech/notcamera.htm cheers Chandru From fess-erlang Tue Mar 11 01:17:25 2008 From: fess-erlang (fess) Date: Mon, 10 Mar 2008 17:17:25 -0700 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: <512EF517-83DA-4446-A775-47894764148C@fess.org> On Mar 10, 2008, at 4:28 PM, Chandru wrote: > I was new to the language ten years ago. I didn't understand how I > could write serious programs with single assignment. 30 minutes later > that problem was solved. I've never really looked back since then. All > the complaints about erlang seem whimsical at best and attention > seeking at worst. I find the syntax termination to be annoying, I never get it right, the complier always gives me some misplaced ';', '.', or ',' somewhere so it slows me down, I do slowly get better at it overtime, but it's extra mental energy. So what I'd like the syntax to allow reordering of lines via editor's cut in paste to less frequently break code, not to mention be simpler to enter the first time. Maybe that's whimsical. However, imagine all the mental energy as each programer re-learns some idiosyncratic thing that could be saved in the cases where those idiosyncrasies can be eliminated. Say it takes 30mins to get over Single Assignment, that probably has enough value to be worth it. [ well at least I think it does ] but if you can give back 30min [ more? ] to millions of programmers who keep getting compiler errors do to a reordering of lines causing the wrong terminator in the wrong place well, that's a whole lot of time to give back to the world. Of course then they'll just use that time to complain about whimsical stuff. Anyhow, it seems that code is the humans interface to instructing the machines what to do, and as such it should be a very human interface. Of course what that is is very debatable, but in the end it's probably worth it to constantly improve the interface. --fess From ok Tue Mar 11 01:40:12 2008 From: ok (Richard A. O'Keefe) Date: Tue, 11 Mar 2008 13:40:12 +1300 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D52E27.6060901@kreditor.se> References: <47D52E27.6060901@kreditor.se> Message-ID: <94129836-78E3-4E3E-8407-719C32DD3354@cs.otago.ac.nz> On 11 Mar 2008, at 1:48 am, Mats Cronqvist wrote: > Damien Katz ( of couchDB fame) has written a blog post about the > warts of erlang. > (http://damienkatz.net/2008/03/what_sucks_abou.html) Some of what Damien Katz says puzzles me greatly. He claims, for example, that Erlang is exceptionally hard to edit. I can only say that I have not found it so, and I don't even use an Erlang-aware editor. When he writes Erlang string operations are just not as simple or easy as most languages with integrated string types the obvious retort is "No, they are simpler and easier". However, sometimes giving a whining child a lollipop is a rational thing to do. Maybe it is time for a string type that holds sequences of Unicode characters in some unspecified compact format; binaries with a different tag. From fig Tue Mar 11 01:46:24 2008 From: fig (Michael FIG) Date: Mon, 10 Mar 2008 18:46:24 -0600 (CST) Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: <28084749.45631205196384652.JavaMail.root@zimbra> Hi, If I could change just one thing about Erlang's syntax, I would want to allow an optional semicolon before a "case" expression's "end", just so I could do: case myfun(abc) of zot -> bar; zing -> baz; end, and swap the "zot" and "zing" lines without getting a compilation error. Following this through to its natural (but uglier) conclusion would be to allow trailing commas in -record definitions, -export and -import lists, and before a "fun" expression's "end". In short, I have never thanked the compiler for pointing out to me that I forgot that a statement was the last one in a comma or semicolon-separated list. If there was a nice-looking way to terminate a top-level function without putting a period behind the return value, I'd suggest that too, but I can't think of any. These changes are all motivated because I use an editor where cutting and pasting a single line is really easy, but manipulating punctuation is not. Thanks for listening, -- Michael FIG , PMP MarkeTel Multi-Line Dialing Systems, Ltd. Phone: (306) 359-6893 ext. 528 From ok Tue Mar 11 02:14:14 2008 From: ok (Richard A. O'Keefe) Date: Tue, 11 Mar 2008 14:14:14 +1300 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D58650.9030803@erlang-consulting.com> References: <47D58650.9030803@erlang-consulting.com> Message-ID: My take on the separators issue: (1) I'm used to the Prolog approach, where every clause ends with a full stop. I'm also used to SML and Haskell and Clean, where again every clause ends the same way (with nothing). If Prolog and Haskell can figure out that adjacent clauses defining the same thing belong to the same definition, it isn't clear to me why Erlang can't. I once wrote a functional preprocessor for Prolog where I could write append([], Ys) = Ys. append([X|Xs], Ys) = [X | append(Xs, Ys)]. and the use of a dot at the end of every function clause was no trouble at all. Nor is it any trouble in Mercury. I generally don't accept arguments about re-ordering definition clauses, because if you know what you are doing it is pretty rare. But I *do* accept arguments about *adding* clauses when you revise a data type, so I wish that Erlang would allow all function clauses to end with a full stop. (2) Again, I generally don't accept arguments about re-ordering function calls in a body. I don't find that to be a common mistake. Oh, I do make mistakes in Erlang. I make mistakes all the time in all sorts of languages. One mistake I do make in Erlang and in C is to get the order of arguments wrong. So why isn't Mr "Erlang sucks" complaining bitterly about how C and Java use different terminators after the last argument ")" and all the others ",", making it hard to swap arguments? Presumably he isn't complaining about that BECAUSE C and Java do the same thing, so he hasn't noticed it. (3) For what it's worth, my text editor, modelled on Emacs, but originally small enough to fit comfortably on a PDP-11, has a "swap terms" command that interchanges the closed terms on either side of the cursor. Given foo(X) -> bar(X),^ ugh(X). with the cursor where the ^ is, Ctrl-X t will convert this to foo(X) -> ugh(X),^ bar(X). with no trouble at all. More generally, the DEdit editor in Interlisp-D had a nice facility: you could build up a stack of selections and then choose an operation, so you could select thing one (except for its terminator) select thing two (except for its terminator) swap top selections Gosh, I miss the ability to have multiple selections. So this is arguably an EDITOR problem, not a LANGUAGE problem, and it can be addressed by more/better editor support. (Is there an XCode plugin for Erlang?) From fig Tue Mar 11 02:19:52 2008 From: fig (Michael FIG) Date: Mon, 10 Mar 2008 19:19:52 -0600 (CST) Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <28084749.45631205196384652.JavaMail.root@zimbra> Message-ID: <30424938.45661205198392398.JavaMail.root@zimbra> Hi again, [Sorry for the self-reply, but on reading more e-mail it seems a lot of people are focusing on this issue. This is a continuation of my prior mail.] My suggestion for top-level functions would be: doit(abc) -> some(), other(), stuff(), ; doit(def) -> some(), stuff(), ; fruit(apple) -> ok, ; In other words, allow semicolon to be used as a substitute for period (by eliminating the "head mismatch" error when it is followed by another function, and the "unterminated function" error when it is at the end of file), and allow an optional comma before the function terminator. Then, people can program as if "," means "end expression" and ";" means "end block". Note that all of these suggestions are backward-compatible with the old syntax. I think that would help satisfy the separator vs. terminator debate without having to force anybody to change their existing style (or (heaven forbid!) introduce whitespace into the syntax ala Python or Haskell). I hope this answers your question as to my own personal annoyance, and how I would solve it if I had a choice, -- Michael FIG , PMP MarkeTel Multi-Line Dialing Systems, Ltd. Phone: (306) 359-6893 ext. 528 From bob Tue Mar 11 02:31:03 2008 From: bob (Bob Ippolito) Date: Mon, 10 Mar 2008 18:31:03 -0700 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <28084749.45631205196384652.JavaMail.root@zimbra> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <28084749.45631205196384652.JavaMail.root@zimbra> Message-ID: <6a36e7290803101831y6f33df1cra50832323e1a32fb@mail.gmail.com> On Mon, Mar 10, 2008 at 5:46 PM, Michael FIG wrote: > Hi, > > If I could change just one thing about Erlang's syntax, I would want to allow an optional semicolon before a "case" expression's "end", just so I could do: > > case myfun(abc) of > zot -> bar; > zing -> baz; > end, > > and swap the "zot" and "zing" lines without getting a compilation error. > > Following this through to its natural (but uglier) conclusion would be to allow trailing commas in -record definitions, -export and -import lists, and before a "fun" expression's "end". > Allowing trailing commas in lists would be very convenient as well, that's one thing I really like about Python's grammar. -bob From ok Tue Mar 11 04:46:59 2008 From: ok (Richard A. O'Keefe) Date: Tue, 11 Mar 2008 16:46:59 +1300 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <28084749.45631205196384652.JavaMail.root@zimbra> References: <28084749.45631205196384652.JavaMail.root@zimbra> Message-ID: On 11 Mar 2008, at 1:46 pm, Michael FIG wrote: > Hi, > > If I could change just one thing about Erlang's syntax, I would want > to allow an optional semicolon before a "case" expression's "end", > just so I could do: > > case myfun(abc) of > zot -> bar; > zing -> baz; > end, I wish I could remember which programming language it was that allowed an optional occurrence of its equivalent of the semicolon at the BEGINNING. Because what I've always wanted is case myfun(abc) of ; zot -> bar ; zing -> baz end Currently I write case myfun(abc) of zot -> bar ; zing -> baz end and it seems to work out OK. Ada of course uses 'when' the way I'm using ';', and it's not optional. Why do I want to put the ';' at the beginning of a line? Because patterns in Erlang designedly look a whole lot like expressions, and I want it to be *obvious* to the reader, especially me, that "here is a pattern". From ttmrichter Tue Mar 11 04:48:53 2008 From: ttmrichter (Michael T. Richter) Date: Tue, 11 Mar 2008 11:48:53 +0800 Subject: [erlang-questions] erlang sucks In-Reply-To: <94129836-78E3-4E3E-8407-719C32DD3354@cs.otago.ac.nz> References: <47D52E27.6060901@kreditor.se> <94129836-78E3-4E3E-8407-719C32DD3354@cs.otago.ac.nz> Message-ID: <1205207333.19731.11.camel@isolde> On Tue, 2008-03-11 at 13:40 +1300, Richard A. O'Keefe wrote: > However, sometimes giving a whining child a lollipop is a rational > thing to do. Way to dismiss valid complaints with an insulting backhand. And then people wonder why it is technical types have a reputation for having no social skills. -- Michael T. Richter (GoogleTalk: ttmrichter) All really first class designers are both artists, engineers, and men of a powerful and intolerant temper, quick to resist the least modification of the plans, energetic in fighting the least infringement upon what they regard as their own sphere of action. (Nevil Shute) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/e361f39f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/e361f39f/attachment.bin From vychodil.hynek Tue Mar 11 07:32:55 2008 From: vychodil.hynek (Hynek Vychodil) Date: Tue, 11 Mar 2008 07:32:55 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: <4d08db370803102332p39ac9f8fhb37cc57cbe8a4ea1@mail.gmail.com> On Tue, Mar 11, 2008 at 12:25 AM, Kevin Scaldeferri wrote: > > On Mar 10, 2008, at 3:44 PM, Kevin Scaldeferri wrote: > > > > > On Mar 10, 2008, at 2:11 PM, Torbjorn Tornkvist wrote: > > > >> > >> Perhaps a stupid question. Do LFE implement currying? > >> If not, why? > >> > >> I want currying... :-) > >> > > > > Here's something I threw together in a couple minutes: > > > > %% F({a,b}) -> F'(a,b) > > curry(F, Arity) -> > > if > > Arity =:= 1 -> fun(A) -> F({A}) end; > > Arity =:= 2 -> fun(A,B) -> F({A,B}) end; > > Arity =:= 3 -> fun(A,B,C) -> F({A,B,C}) end; > > Arity =:= 4 -> fun(A,B,C,D) -> F({A,B,C,D}) end; > > Arity =:= 5 -> fun(A,B,C,D,E) -> F({A,B,C,D,E}) end; > > true -> throw(unsupported_arity) > > end. > > > > Should do slightly more browsing of the docs before posting :-). This > is a slight improvement: > > %% F({a,b}) -> F'(a,b) > curry(F) -> > {arity, Arity} = erlang:fun_info(F, arity), > if > Arity =:= 1 -> fun(A) -> F({A}) end; > Arity =:= 2 -> fun(A,B) -> F({A,B}) end; > Arity =:= 3 -> fun(A,B,C) -> F({A,B,C}) end; > Arity =:= 4 -> fun(A,B,C,D) -> F({A,B,C,D}) end; > Arity =:= 5 -> fun(A,B,C,D,E) -> F({A,B,C,D,E}) end; > true -> throw(unsupported_arity) > end. > That's wrong I think. Function F will be always called with arity 1. > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- --Hynek (Pichi) Vychodil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/4cf55e6a/attachment.html From yarivsadan Tue Mar 11 07:40:53 2008 From: yarivsadan (Yariv Sadan) Date: Mon, 10 Mar 2008 23:40:53 -0700 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> Hi Robert, I think the "issues" with Erlang's syntax are quite overblown. They took me about a day to master and I hardly notice any of them when I'm actually writing and editing code. I certainly don't want Erlang to look any more like Java/C than it does now. I'm pretty happy with the Erlang syntax (I also think that LFE provides a very interesting option for those who are curious about Lisp :) ) The main change I would like to see is to have the compiler automatically infer the types of record variables (when possible) to shorten the amount of code required for accessing their properties. I created an unfinished solution here: http://code.google.com/p/recless/. This page has a couple of examples for how it could be used. I would also like to be able to overload macro names with different arities and to have some mechanism for introspecting the properties of records and accessing them dynamically at runtime. Best regards, Yariv 2008/3/10 Robert Virding : > Hello all, > > I have read Damien's post and Yariv's reply. My question is: they say what > they don't want, but what do they actually want? I mean this question > seriously. Perhaps someone who is new to the language could answer and tell > what they found most difficult when learning the syntax. I have spoken > Erlang so long that I see it as natural, warts and all. > > Even records look like they do for a specific reason and it is harder than > you would think to change them. Other Erlang features force issues. > > Getting back. What do people want? Do they want something that looks like > Java, or C++, or Python, or Perl, or ... ? This is actually possible to do, > BUT (there is always a but) you would not have the Java or C++ or Python or > ... semantics, you would still have Erlang semantics. Would we then get > complaints that while it looks like Java it doesn't behave like Java, and > why not? > > As I said I am serious about this question, even if we don't do a JFE (Java > Flavoured Erlang) it would be interesting to know what people want. Do > people know what they want? Is or is it just that it looks and behaves > differently to what they are used? > > Robert > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From hasan.veldstra Tue Mar 11 08:00:12 2008 From: hasan.veldstra (Hasan Veldstra) Date: Tue, 11 Mar 2008 07:00:12 +0000 Subject: [erlang-questions] EUnit In-Reply-To: <343189.35763.qm@web35914.mail.mud.yahoo.com> References: <343189.35763.qm@web35914.mail.mud.yahoo.com> Message-ID: Andrew Stone wrote: > Thanks Richard. But I'm still having a little trouble. What I meant was how do I create a fixture etc...? Here's an example of a simple fixture: simple_test_() -> {setup, local, fun setup/0, %% This is called before the tests are run (to set up things). fun cleanup/1, %% This is called after the tests have been run (to clean up). fun(List) -> %% The argument to this is the return value of setup(). [ ?_assert(2*2 == 4), ?_assert(not(true) == false) ] end}. I agree, the docs are a bit cryptic and it took me a wee while to figure it out. -- http://12monkeys.co.uk http://hypernumbers.com From bengt.kleberg Tue Mar 11 08:20:07 2008 From: bengt.kleberg (Bengt Kleberg) Date: Tue, 11 Mar 2008 08:20:07 +0100 Subject: [erlang-questions] Use of makefiles In-Reply-To: <200803102229.m2AMT2q9024026@pluto.hedeland.org> References: <200803102229.m2AMT2q9024026@pluto.hedeland.org> Message-ID: <1205220007.8068.7.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, Thank you for the clarification. FWIW: I promise that I do know that -l is for the linker. That is why I wrote "compiling/linking". For some reason that I have forgotten, but it sounded really convincing at the time, I was told to always use the C compiler to handle the linking. Therefore I do not know what the SUN and GNU linkers are called, so that is why I wrote SUN C/gcc. At the time I thought it would save some writing. My mistake. bengt On Mon, 2008-03-10 at 23:29 +0100, Per Hedeland wrote: > Bengt Kleberg wrote: > > > >Still OT since we are now talking about C compiling/linking. > > > >Since gcc does not need the -lsocket that the SUN C compiler needs for > >sockets, I think that these differences show up long before the project > >turns highly unusual. > > Not sure if it matters much for the discussion, but differences in > required libraries are generally (always?) dependent on the OS, not the > compiler. On Solaris, which is probably the only place you use the Sun C > compiler, you need -lsocket, whereas on most OSes where gcc is the > "standard" compiler, you don't - which is probably the source of your > misunderstanding. > > --Per Hedeland > > $ uname -sr > SunOS 5.10 > $ echo 'main(){socket();}' > xxx.c > $ gcc xxx.c > Undefined first referenced > symbol in file > socket /var/tmp//ccQwllM5.o > ld: fatal: Symbol referencing errors. No output written to a.out > collect2: ld returned 1 exit status > $ gcc xxx.c -lsocket > $ > From Dmitri.Girenko Tue Mar 11 08:26:31 2008 From: Dmitri.Girenko (Dmitri Girenko) Date: Tue, 11 Mar 2008 09:26:31 +0200 Subject: [erlang-questions] (no subject) In-Reply-To: <3dbc6d1c0803101414u2fb8e9adja1f6e2ae276da5ce@mail.gmail.com> References: <3dbc6d1c0803101414u2fb8e9adja1f6e2ae276da5ce@mail.gmail.com> Message-ID: <697074A35ED91748882E3850BDCE295EE09539@leenu.akumiitti.net> Well, both versions have their pros and cons. Probably depending on the number of variables, it might be better to use the "side effect" of the case clause as it shortens the code significantly. What I am more worried about is the effect it has on the automatic source code processing like refactoring, parse transforms, etc. For instance if we have Value = case Var of one->Tmp=blah_blah, calcValue(SomeArgs); two->Tmp=blah_2, calcValue(OtherArgs); end, ... code goes on ... do_something(Tmp, YetOtherArgs).. Later one decides to extract a function (aka extract a method in OO), then the code should be rewritten as {Value, Tmp} = new_func(...); .... new_func(..) -> Value = case Var of one->Tmp=blah_blah, calcValue(SomeArgs); two->Tmp=blah_2, calcValue(OtherArgs); end, {Value, Tmp}. So the question is: are these kind of features easily handled in the AST? Do refactoring tools have to take special care of the case like that? P.S. All these questions arose only because the binary match specs have to be static, not like: <> = Binary. :-) ________________________________ From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Robert Virding Sent: 10. maaliskuuta 2008 23:14 To: Jay Nelson Cc: erlang-questions Subject: Re: [erlang-questions] (no subject) On 10/03/2008, Jay Nelson wrote: I stand corrected. I wasn't aware of the compiler error because I avoid that style of code. The reason I avoid it, is that I find it more difficult to visually verify in the editor. Also, if more clauses are added in the future, you have to keep track that the following code relies on setting some variables (or else, apparently, wait until you compile to notice you need some others). I just find that the following style: { ... args needed ... } = compound statement, use args advertises the programmer's intent much more clearly. It states that the compound statement is being executed for the side effect of binding a particular set of variables. This binding environment is necessary for the following statements. It corresponds to a (let (...) ...) clause in lisp. Yes, it is a matter of style which method you use. The scope of variables is the whole function clause. I also prefer returning the values which are "exported" from the if/case/receive, it is clearer, but I am not always consistent in this I know. Although many prefer just exporting them. Unfortunately it is impossible to be completely consistent all the time as the compiler quite happily exports all variables which are bound in all clauses. This can cause some confusion. So if you have: case ... of ... -> ..., Tmp = ..., ...; ... -> ..., Tmp = ..., ...; ... end, where Tmp is bound in all clauses then Tmp will automatically be exported. And if it is then later used it will already be bound, which can cause some confusion. So you have to be certain to use unique names for temporary variables. This is another reason to avoid large function clauses where it can be harder to see reuse. There is no way around this. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/8d49f151/attachment.html From kevin Tue Mar 11 08:17:03 2008 From: kevin (Kevin Scaldeferri) Date: Tue, 11 Mar 2008 00:17:03 -0700 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <4d08db370803102332p39ac9f8fhb37cc57cbe8a4ea1@mail.gmail.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <4d08db370803102332p39ac9f8fhb37cc57cbe8a4ea1@mail.gmail.com> Message-ID: <0353893A-483E-4BFF-9A12-29663E4C5A2B@scaldeferri.com> On Mar 10, 2008, at 11:32 PM, Hynek Vychodil wrote: > > > On Tue, Mar 11, 2008 at 12:25 AM, Kevin Scaldeferri > wrote: > > On Mar 10, 2008, at 3:44 PM, Kevin Scaldeferri wrote: > > > > > On Mar 10, 2008, at 2:11 PM, Torbjorn Tornkvist wrote: > > > >> > >> Perhaps a stupid question. Do LFE implement currying? > >> If not, why? > >> > >> I want currying... :-) > >> > > > > Here's something I threw together in a couple minutes: > > > > %% F({a,b}) -> F'(a,b) > > curry(F, Arity) -> > > if > > Arity =:= 1 -> fun(A) -> F({A}) end; > > Arity =:= 2 -> fun(A,B) -> F({A,B}) end; > > Arity =:= 3 -> fun(A,B,C) -> F({A,B,C}) end; > > Arity =:= 4 -> fun(A,B,C,D) -> F({A,B,C,D}) end; > > Arity =:= 5 -> fun(A,B,C,D,E) -> F({A,B,C,D,E}) end; > > true -> throw(unsupported_arity) > > end. > > > > Should do slightly more browsing of the docs before posting :-). This > is a slight improvement: > > %% F({a,b}) -> F'(a,b) > curry(F) -> > {arity, Arity} = erlang:fun_info(F, arity), > if > Arity =:= 1 -> fun(A) -> F({A}) end; > Arity =:= 2 -> fun(A,B) -> F({A,B}) end; > Arity =:= 3 -> fun(A,B,C) -> F({A,B,C}) end; > Arity =:= 4 -> fun(A,B,C,D) -> F({A,B,C,D}) end; > Arity =:= 5 -> fun(A,B,C,D,E) -> F({A,B,C,D,E}) end; > true -> throw(unsupported_arity) > end. > > That's wrong I think. Function F will be always called with arity 1. Yup, I realized that later as well. That change works for papply, but not for curry. (This shortcoming is not restricted to Erlang, one should note. For example, in Haskell, curry and uncurry only operate on binary functions.) -kevin From tobbe Tue Mar 11 09:04:54 2008 From: tobbe (Torbjorn Tornkvist) Date: Tue, 11 Mar 2008 09:04:54 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: Well, the notion that M:F/Arity is unique doesn't need to hold if you're implementing your own language on top of Erlang core, or ? As an example, look at my little Haskell-to-Erlang experiment: http://blog.tornkvist.org/blog.yaws?id=1190846785574003 As you can see, it is also possible to make user-defined guards when you're rolling your own language on top of Erlang core. Cheers, Tobbe Kevin Scaldeferri wrote: > On Mar 10, 2008, at 2:11 PM, Torbjorn Tornkvist wrote: > >> Perhaps a stupid question. Do LFE implement currying? >> If not, why? >> >> I want currying... :-) >> > > Here's something I threw together in a couple minutes: > > %% F({a,b}) -> F'(a,b) > curry(F, Arity) -> > if > Arity =:= 1 -> fun(A) -> F({A}) end; > Arity =:= 2 -> fun(A,B) -> F({A,B}) end; > Arity =:= 3 -> fun(A,B,C) -> F({A,B,C}) end; > Arity =:= 4 -> fun(A,B,C,D) -> F({A,B,C,D}) end; > Arity =:= 5 -> fun(A,B,C,D,E) -> F({A,B,C,D,E}) end; > true -> throw(unsupported_arity) > end. > > %% F(a,b) -> F'({a,b}) > uncurry(F) -> > fun(Tuple) -> apply(F, tuple_to_list(Tuple)) end. > > > A gross hack, to be sure, although I can't see how you could have any > hope to avoid having to specify an Arity to curry(). Maybe there's a > way to implement it less horribly, though. > > BTW, did you actually mean that you want partial application? Via a > similar process: > > papply(F, Arity, Arg) -> > if > Arity =:= 1 -> fun() -> F(Arg) end; > Arity =:= 2 -> fun(A) -> F(Arg,A) end; > Arity =:= 3 -> fun(A,B) -> F(Arg,A,B) end; > Arity =:= 4 -> fun(A,B,C) -> F(Arg,A,B,C) end; > Arity =:= 5 -> fun(A,B,C,D) -> F(Arg,A,B,C,D) end; > true -> throw(unsupported_arity) > end. > > > > > -kevin From ulf Tue Mar 11 09:11:15 2008 From: ulf (Ulf Wiger) Date: Tue, 11 Mar 2008 09:11:15 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205207333.19731.11.camel@isolde> References: <47D52E27.6060901@kreditor.se> <94129836-78E3-4E3E-8407-719C32DD3354@cs.otago.ac.nz> <1205207333.19731.11.camel@isolde> Message-ID: <8209f740803110111i539844bal445fd155989cb595@mail.gmail.com> 2008/3/11, Michael T. Richter : > > > On Tue, 2008-03-11 at 13:40 +1300, Richard A. O'Keefe wrote: > > However, sometimes giving a whining child a lollipop is a rational > thing to do. > > > Way to dismiss valid complaints with an insulting backhand. > > And then people wonder why it is technical types have a reputation for > having no social skills. > Just like someone saying "kill two birds with one stone" most likely doesn't mean it literally, I would wager that mr ROK did not literally refer to Damien as a whining child - not least because he is not literally offering a lollipop. Thus, it's surely to be read as a metaphor - not an insult. I would have been more offended by the depiction "Mr Erlang Sucks". (: IOW many complain about various quirks in Erlang, as well as the apparent lack of efficient (at the very least familiar) string handling support. We can choose to dismiss the complaints as secondary (which may or may not be true, depending on context), or address the specific issues. I am quite sure I read ROK's post as suggesting the latter, as he suggests fixing the deliminator issue, and puts in a vote for a unicode-capable string type. BR, Ulf W -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/2a050dfa/attachment-0001.html From mats.cronqvist Tue Mar 11 09:31:38 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 11 Mar 2008 09:31:38 +0100 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <0353893A-483E-4BFF-9A12-29663E4C5A2B@scaldeferri.com> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <4d08db370803102332p39ac9f8fhb37cc57cbe8a4ea1@mail.gmail.com> <0353893A-483E-4BFF-9A12-29663E4C5A2B@scaldeferri.com> Message-ID: <47D6436A.7080608@kreditor.se> Kevin Scaldeferri wrote: > On Mar 10, 2008, at 11:32 PM, Hynek Vychodil wrote: > > >> On Tue, Mar 11, 2008 at 12:25 AM, Kevin Scaldeferri > >>> wrote: >>> >> On Mar 10, 2008, at 3:44 PM, Kevin Scaldeferri wrote: >> >> >>> On Mar 10, 2008, at 2:11 PM, Torbjorn Tornkvist wrote: >>> >>> >>>> Perhaps a stupid question. Do LFE implement currying? >>>> If not, why? >>>> >>>> I want currying... :-) >>>> >>>> >>> Here's something I threw together in a couple minutes: >>> >>> %% F({a,b}) -> F'(a,b) >>> curry(F, Arity) -> >>> if >>> Arity =:= 1 -> fun(A) -> F({A}) end; >>> Arity =:= 2 -> fun(A,B) -> F({A,B}) end; >>> Arity =:= 3 -> fun(A,B,C) -> F({A,B,C}) end; >>> Arity =:= 4 -> fun(A,B,C,D) -> F({A,B,C,D}) end; >>> Arity =:= 5 -> fun(A,B,C,D,E) -> F({A,B,C,D,E}) end; >>> true -> throw(unsupported_arity) >>> end. >>> >>> IANACS(*), but i thought currying was supposed to look like this; curry(F,Arg) -> case erlang:fun_info(F,arity) of {_,1} -> fun() -> F(Arg) end; {_,2} -> fun(A) -> F(A,Arg) end; {_,3} -> fun(A,B) -> F(A,B,Arg) end; {_,4} -> fun(A,B,C) -> F(A,B,C,Arg) end end. mats (*) I Am Not A Computer Scientist -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/2cc98ea6/attachment.vcf From ulf Tue Mar 11 09:43:30 2008 From: ulf (Ulf Wiger) Date: Tue, 11 Mar 2008 09:43:30 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D52E27.6060901@kreditor.se> References: <47D52E27.6060901@kreditor.se> Message-ID: <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> 2008/3/10, Mats Cronqvist : > Damien Katz ( of couchDB fame) has written a blog post about the warts > of erlang. > (http://damienkatz.net/2008/03/what_sucks_abou.html) There are several threads in the article (and comments) perhaps worthy of discussion here at EQ. My general impression of the article is that while I agree that the complaints are valid, the reader comes away from it with the distinct impression that Damien Katz would be content if he never had to touch Erlang again, despite the contention that he could fill a book with the things he likes about it - much like everyone now "knows" that Erlang sucks at file I/O, since it did in the original Wayfinder experiments, and it was noted in a blog article. So, I'm inclined to agree with Tobbe. Someone reading the article, who might have been interested in checking out Erlang, might well be persuaded not to do so. I don't think that was the author's intention. Still, the blogosphere is free, thankfully, so - on to the complaints. - I'd like to try (= see someone else implement) an indentation-sensitive front-end to the compiler, but perhaps ROK's suggestion that a full stop can be used in place of a semicolon would cause less uproar. - With the bit syntax improvements in R12B, and EEP9, I think we're starting to come close to the foundations of an alternative string handling library. When we get there, we'll surely be able to see further. - I don't agree that Erlang is bad for writing test suites. On the contrary, I think Erlang is, on the whole, just about the best test automation environment in existence, especially if you include QuickCheck. The problem with numbering variables is real, but can be addressed with a change of programming style (which is both a good thing and a very bad thing, depending on your POV). The advantage of immutable variables far outweighs this inconvenience, anyway, even though I guess that this particular issue is much less of a problem in currying languages. - The gripe about records, well, is well-founded, but also ground well covered. Perhaps we should finally do something about it? - I agree with Klacke on the out-of-memory issue. I once complained about it, but have long-since decided that exit(1) is most likely the best option in general. It is possible that one could allow for a callback, or specification, that could guide the VM in releasing memory, in the cases where this would be a reasonable thing to do. Perhaps before killing processes, one could have a go at removing memory fragmentation, which would appear as a very expensive GC. But Erlang does already have options for plugging in a more aggressive memory allocator, which works harder to avoid fragmentation in the first place. It also has quite a battery of features for implementing sophisticated load control, e.g. barring new jobs if there doesn't seem to be enough memory left. - Regarding the uneven documentation, I'd like to point out that docbuilder allows people to write alternative documentation that has the same look and feel as the Erlang/OTP documentation. This is new as of OTP R12B. - One comment dismissed Erlang as a specialized language. I think this reflects the idea that concurrency is something that you only use when it's really needed, and something to avoid otherwise. I'd like to turn the tables and suggest that languages that are very good at sequential processing, but suck at concurrency, are the specialized ones. So many interesting applications require strong concurrency support, and as it turns out, message-passing lightweight concurrency is a modeling paradigm in its own right at least as powerful as OO. Perhaps we can improve at getting this message across? BR, Ulf W From lenartlad Tue Mar 11 10:02:02 2008 From: lenartlad (Ladislav Lenart) Date: Tue, 11 Mar 2008 10:02:02 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> Message-ID: <47D64A8A.8000008@volny.cz> Yariv Sadan wrote: > Hi Robert, > > I think the "issues" with Erlang's syntax are quite overblown. They > took me about a day to master and I hardly notice any of them when I'm > actually writing and editing code. I certainly don't want Erlang to > look any more like Java/C than it does now. I'm pretty happy with the > Erlang syntax (I also think that LFE provides a very interesting > option for those who are curious about Lisp :) ) > > The main change I would like to see is to have the compiler > automatically infer the types of record variables (when possible) to > shorten the amount of code required for accessing their properties. I > created an unfinished solution here: > http://code.google.com/p/recless/. This page has a couple of examples > for how it could be used. > > I would also like to be able to overload macro names with different > arities and to have some mechanism for introspecting the properties of > records and accessing them dynamically at runtime. This is almost what I was about to write (except that I don't have partial solution to the problem :-) For me, the syntax is still a bit too noisy. Whenever I write a module and compile it I have two or three comile-error cycles on errors that wouldn't be there if the syntax was a little bit different. But as many pointed out this is not a big deal really. But what I would like to have in Erlang is definitely better introspection / reflection capabilities. I would like to have records as runtime structures, so I could write: Var#{x = foo, y = bar} where Var could be any record that has slots x and y (it might have others), record_info would be a normal function that can operate on variables. I would also very much like to be able to programmatically create/inspect/modify receive (and other) clauses at runtime. But this is just wishful thinking I think. Ladislav Lenart From ulf.wiger Tue Mar 11 10:52:23 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 11 Mar 2008 10:52:23 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: References: <28084749.45631205196384652.JavaMail.root@zimbra> Message-ID: <47D65657.7050406@ericsson.com> Richard A. O'Keefe skrev: > > Currently I write > case myfun(abc) > of zot -> bar > ; zing -> baz > end > and it seems to work out OK. > > Ada of course uses 'when' the way I'm using ';', and it's not optional. > > Why do I want to put the ';' at the beginning of a line? > Because patterns in Erlang designedly look a whole lot like expressions, > and I want it to be *obvious* to the reader, especially me, that > "here is a pattern". And for those who continuously have problems with the different trailing deliminators, this could pretty much solve the problem. Of course, using Emacs, one would have to turn off the "electric semicolon" feature, which often gets it wrong, anyway. The auto-indentation of the emacs mode also butchers this style of writing. So any emacs user who hasn't dug into the .emacs file changing the defaults, would most likely go bezerk if they had to edit a program written in this style - that - or turn off the emacs erlang-mode completely. (Not saying this couldn't be fixed. I also find the style visually appealing.) BR, Ulf W From ulf.wiger Tue Mar 11 11:09:44 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 11 Mar 2008 11:09:44 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: <47D65A68.9010309@ericsson.com> Robert Virding skrev: > > Getting back. What do people want? Do they want something that looks > like Java, or C++, or Python, or Perl, or ... ? This is actually > possible to do, BUT (there is always a but) you would not have the Java > or C++ or Python or ... semantics, you would still have Erlang > semantics. Would we then get complaints that while it looks like Java it > doesn't behave like Java, and why not? I think this is a very valid question. Differences in syntax actually play an important role in conveying differences in semantics. Deliberately copying the syntax of another language might lead to lots of confusion if one doesn't copy the semantics as well. It reminds me of one of my favorite gripes about UML. The main point of a standard notation is that everyone should be able to look at a symbol an immediately agree on what it means. The UML approach has been to include everything in the standard, leading to a huge specification that no mortal fully understands, and then leaving enough vital details undefined so as to allow tool makers to make their own UML adaptation with the same symbols, but slightly different semantics... Some aspects of the syntax could perhaps be polished without falling into this quagmire of semantics confusion, though. I haven't used Erlang as long as you have (few have, obviously), but long enough to have developed a similar blindness to its faults. If I were to make some suggestions, I would perhaps choose: - A more compact lambda notation (Haskell envy) (*) - Record syntax improvements that make record operations more portable across modules, and reducing the very unfortunate compile-time dependencies. - A way to parameterize receive clauses (or perhaps pattern matching in general, but it hurts the most in receive). BR, Ulf W (*) I will say, though, that the erlang lambda syntax is much more obvious (if a bit verbose) than the Haskell version. When damaged by other languages, one can stare for quite a while at a Haskell expression and not have a first clue about what it does, since the syntax is so different. This surely scares people, when they could learn to love the syntax if they only set aside a full day of intense study. Someone said "learning haskell is hard, but /programming/ haskell is easy. In a way, I think this gives a very important perspective on the syntax debate. It's less important what you think of the syntax at first sight, than it is what you think of it after a year or more. Having said that, Damien Katz is obviously no beginner, so he ought to fall in the latter category... From vychodil.hynek Tue Mar 11 11:20:24 2008 From: vychodil.hynek (Hynek Vychodil) Date: Tue, 11 Mar 2008 11:20:24 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <47D64A8A.8000008@volny.cz> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> Message-ID: <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> On Tue, Mar 11, 2008 at 10:02 AM, Ladislav Lenart wrote: > Yariv Sadan wrote: > > Hi Robert, > > > > I think the "issues" with Erlang's syntax are quite overblown. They > > took me about a day to master and I hardly notice any of them when I'm > > actually writing and editing code. I certainly don't want Erlang to > > look any more like Java/C than it does now. I'm pretty happy with the > > Erlang syntax (I also think that LFE provides a very interesting > > option for those who are curious about Lisp :) ) > > > > The main change I would like to see is to have the compiler > > automatically infer the types of record variables (when possible) to > > shorten the amount of code required for accessing their properties. I > > created an unfinished solution here: > > http://code.google.com/p/recless/. This page has a couple of examples > > for how it could be used. > > > > I would also like to be able to overload macro names with different > > arities and to have some mechanism for introspecting the properties of > > records and accessing them dynamically at runtime. > > This is almost what I was about to write (except that I don't have partial > solution to the problem :-) > > For me, the syntax is still a bit too noisy. Whenever I write a module and > compile it I have two or three comile-error cycles on errors that wouldn't > be there if the syntax was a little bit different. But as many pointed out > this is not a big deal really. > > But what I would like to have in Erlang is definitely better introspection > / > reflection capabilities. I would like to have records as runtime > structures, > so I could write: > > Var#{x = foo, y = bar} > > where Var could be any record that has slots x and y (it might have > others), > record_info would be a normal function that can operate on variables. > It is misunderstand what record is. Record is not this sort of things. Use our own structure for this purpose. Record is not object, hash, dictionary or whatever you really want. Record is not designed for some sort of inheritance. Record is structure for memory friendly storage of fixed "records" a which one will be changed very rare and just only by design. > > I would also very much like to be able to programmatically > create/inspect/modify > receive (and other) clauses at runtime. But this is just wishful thinking > I think. > > Ladislav Lenart > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- --Hynek (Pichi) Vychodil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/8692aea0/attachment.html From chsu79 Tue Mar 11 12:05:44 2008 From: chsu79 (Christian S) Date: Tue, 11 Mar 2008 12:05:44 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> Message-ID: > It is misunderstand what record is. Record is not this sort of things. Use > our own structure for this purpose. Record is not object, hash, dictionary > or whatever you really want. Record is not designed for some sort of > inheritance. Record is structure for memory friendly storage of fixed > "records" a which one will be changed very rare and just only by design. That is what they are. What we want might be something else though. Thinking out loud: Would it be possible to create a pattern matching syntax for some kind of association map? As I understand it, guards without near O(1) properties are not that popular. But others do exist already. Perhaps something that recognizes {[Fields::atom()], FieldValue1::term()} so that both {[gurka, avocado, sallad, dressing], 1, 2, 3, 4} and {[tacos, salsa, avocado], 8, 4, 2} could be matched when asking for avocado=2 in this something. %% What better character to use for a beta feature than ? !!? cook(?{avocado=1}) -> guacamole(). The real wart in record _syntax_ is when you update a record in a record ( in a record ( in a record ...)). From ConveyCJ Tue Mar 11 12:53:04 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Tue, 11 Mar 2008 07:53:04 -0400 Subject: [erlang-questions] How many scheduler threads to I need? Message-ID: <1C538D67B37E5B4784128A22270DF5C310254F4C@npri54exc20.npt.nuwc.navy.mil> Could someone clear this up for me please? When I run a simple, single-process Erlang function from the erl shell, I light up both CPU cores on my computer. So... * How does a single process light up two cores? Is one core busy with garbage collection or something? * If I can light up two cores with just a simple invocation of the erl shell, then why does the "-smp +S n" option exist? Thanks, Christian BTW, here's the code I ran: countdown(X) -> countdown(X, 0). countdown(0, Acc) -> Acc ; countdown(X, Acc) -> countdown(X-1, Acc+1) . countdown(50000000). From vychodil.hynek Tue Mar 11 13:27:37 2008 From: vychodil.hynek (Hynek Vychodil) Date: Tue, 11 Mar 2008 13:27:37 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> Message-ID: <4d08db370803110527i1f6e5747y199a871ac40bc8e@mail.gmail.com> On Tue, Mar 11, 2008 at 12:05 PM, Christian S wrote: > > It is misunderstand what record is. Record is not this sort of things. > Use > > our own structure for this purpose. Record is not object, hash, > dictionary > > or whatever you really want. Record is not designed for some sort of > > inheritance. Record is structure for memory friendly storage of fixed > > "records" a which one will be changed very rare and just only by design. > > That is what they are. What we want might be something else though. > > > Thinking out loud: > > Would it be possible to create a pattern matching syntax for some kind > of association map? > > As I understand it, guards without near O(1) properties are not that > popular. But others do exist already. > > Perhaps something that recognizes {[Fields::atom()], > FieldValue1::term()} so that > both {[gurka, avocado, sallad, dressing], 1, 2, 3, 4} and {[tacos, > salsa, avocado], 8, 4, 2} could be > matched when asking for avocado=2 in this something. > > %% What better character to use for a beta feature than ? !!? > cook(?{avocado=1}) -> > guacamole(). > You can wrote [{gurka,1}, {avocado,2}, {sallad,3}, {dressing,4}] and [{tacos,8}, {salsa, 4}, {avocado, 2}] and cook(L) -> case proplist:get_value(avocado, L) of 2 -> guacamole() end. Your ? guard is not O(1) like mine solution. But again, it is not records use case. You can make our own solution and erlange give you enough power to do it and do it elegant. At least you can make your own parse transform to do it with syntax sugar. If {[gurka, avocado, sallad, dressing], 1, 2, 3, 4} and {[tacos, salsa, avocado], 8, 4, 2} are #a{gurka= 1, avocado=2, salad=3, dressing=4} and #b{tacos=8, salas=4, avocado=2} you can simply wrote cook(#a{avocado=2}) -> guacamole(); cook(#b{avocado=2}) -> guacamole(). I know, this solution is only for finite number of record types and there is nice solution for huge amount of records, look for records helper function ( 8.7 in http://erlang.org/doc/reference_manual/records.html). And again, you are looking for some other construct than record. > > > The real wart in record _syntax_ is when you update a record in a > record ( in a record ( in a record ...)). > -- --Hynek (Pichi) Vychodil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/55beb03e/attachment.html From klacke Tue Mar 11 13:32:10 2008 From: klacke (Claes Wikstrom) Date: Tue, 11 Mar 2008 13:32:10 +0100 Subject: [erlang-questions] Function to print a record with fieldnames? In-Reply-To: <47CD624E.7020107@kreditor.se> References: <1C538D67B37E5B4784128A22270DF5C30FF782EC@npri54exc20.npt.nuwc.navy.mil> <47CD624E.7020107@kreditor.se> Message-ID: <47D67BCA.6010502@hyber.org> Mats Cronqvist wrote: > Convey Christian J NPRI wrote: >> I've got a record definition along the lines of: -record(myrec, {foo >> = undefined, bar=undefined}). > We have this in some code: It's not especially good but works. 1. in a .hrl file %% Used to print records nicely as in %% io:format("Just got ~s\n", [?format_record(Message, message)]), -define(format_record(Rec, Name), misc:format_record(Rec, Name, record_info(fields, Name))). 2. And then in a module ...... %% returns {record, RecName, [Field1, Val1} .....] format_record(Record, Name, Fields) -> case tuple_to_list(Record) of [Name | Rest] -> io_lib:format("record ~w {\n~s", [Name, format_record(Rest, Fields)]); _X -> "badrecord" end. format_record([], []) -> []; format_record([Val|Vals], [F|Fs]) when is_integer(Val); Val == []; atom(Val); is_float(Val)-> Curly = if Vals == [] -> " }"; true -> "," end, [io_lib:format(" ~w = ~w~s\n", [F,Val,Curly]), format_record(Vals, Fs)]; format_record([Val|Vals], [F|Fs]) -> case is_string(Val) of true -> [io_lib:format(" ~w = ~s\n", [F,Val]), format_record(Vals, Fs)]; false -> [io_lib:format(" ~w = ~p~n", [F, Val]), format_record(Vals, Fs)] end. is_string(L) when list(L) -> all_integer(L); is_string(_) -> false. all_integer([H|T]) when is_integer(H), $A < H, H < $z -> all_integer(T); all_integer([_|_]) -> false; all_integer([]) -> true. From vychodil.hynek Tue Mar 11 13:42:53 2008 From: vychodil.hynek (Hynek Vychodil) Date: Tue, 11 Mar 2008 13:42:53 +0100 Subject: [erlang-questions] How many scheduler threads to I need? In-Reply-To: <1C538D67B37E5B4784128A22270DF5C310254F4C@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C310254F4C@npri54exc20.npt.nuwc.navy.mil> Message-ID: <4d08db370803110542r2c32df7dvd0e2160c1568f634@mail.gmail.com> I don't know what sort of system nor erlang you use but on my dual-core Linux laptop your countdown use only one core as expected. vmstat: (see 51 user and 49 idle CPU in last rows) procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 1503332 29180 252236 0 0 0 0 393 1044 1 0 99 0 1 0 0 1503332 29180 252236 0 0 0 0 432 1117 1 1 98 0 1 0 0 1503380 29180 252236 0 0 0 0 434 2035 1 1 97 0 0 0 0 1503380 29180 252236 0 0 0 0 370 939 0 0 99 0 0 0 0 1503380 29180 252236 0 0 0 0 386 955 0 0 100 0 0 0 0 1503380 29180 252236 0 0 0 0 395 1046 1 0 99 0 0 0 0 1503380 29180 252236 0 0 0 0 481 1729 4 1 95 0 0 0 0 1503380 29180 252236 0 0 0 0 411 1118 4 1 95 0 0 0 0 1503396 29184 252236 0 0 0 52 440 1101 2 1 97 0 0 0 0 1503396 29184 252236 0 0 0 0 362 912 1 0 99 0 0 0 0 1503428 29184 252236 0 0 0 0 387 936 2 1 97 0 0 0 0 1503428 29184 252236 0 0 0 0 390 962 1 0 98 0 0 0 0 1503444 29184 252236 0 0 0 0 392 920 3 1 96 0 1 0 0 1503444 29192 252228 0 0 0 236 482 962 30 1 69 0 1 0 0 1503476 29192 252236 0 0 0 0 502 1112 54 1 46 0 1 0 0 1503476 29192 252236 0 0 0 0 483 765 54 0 47 0 1 0 0 1503476 29192 252236 0 0 0 0 500 784 54 0 46 0 1 0 0 1503476 29192 252236 0 0 0 0 467 738 53 1 46 0 1 0 0 1503476 29192 252236 0 0 0 4 558 1083 53 1 46 0 1 0 0 1503476 29200 252236 0 0 0 56 514 930 51 1 49 0 1 0 0 1503484 29200 252236 0 0 0 0 532 936 51 0 49 0 3 0 0 1503484 29200 252236 0 0 0 0 536 1016 51 1 49 0 1 0 0 1503516 29200 252236 0 0 0 0 553 1023 51 1 49 0 On Tue, Mar 11, 2008 at 12:53 PM, Convey Christian J NPRI < ConveyCJ> wrote: > Could someone clear this up for me please? > > When I run a simple, single-process Erlang function from the erl shell, I > light up both CPU cores on my computer. So... > > * How does a single process light up two cores? Is one core busy with > garbage collection or something? > * If I can light up two cores with just a simple invocation of the erl > shell, then why does the "-smp +S n" option exist? > > Thanks, > Christian > > BTW, here's the code I ran: > > > countdown(X) -> countdown(X, 0). > > countdown(0, Acc) -> > Acc > ; > countdown(X, Acc) -> > countdown(X-1, Acc+1) > . > > countdown(50000000). > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- --Hynek (Pichi) Vychodil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/85bf8450/attachment.html From doug.mansell Tue Mar 11 13:44:27 2008 From: doug.mansell (doug mansell) Date: Tue, 11 Mar 2008 13:44:27 +0100 Subject: [erlang-questions] How many scheduler threads to I need? In-Reply-To: <1C538D67B37E5B4784128A22270DF5C310254F4C@npri54exc20.npt.nuwc.navy.mil> References: <1C538D67B37E5B4784128A22270DF5C310254F4C@npri54exc20.npt.nuwc.navy.mil> Message-ID: On Tue, Mar 11, 2008 at 12:53 PM, Convey Christian J NPRI wrote: > Could someone clear this up for me please? > > When I run a simple, single-process Erlang function from the erl shell, I light up both CPU cores on my computer. So... > > * How does a single process light up two cores? Is one core busy with garbage collection or something? Running this test under Vista i can see that both CPUs show some activity, but looking deeper with process explorer there's only actually one busy thread. So the OS is scheduling it to run on both cores. doug From mats.cronqvist Tue Mar 11 13:47:27 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 11 Mar 2008 13:47:27 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> Message-ID: <47D67F5F.1040807@kreditor.se> Ulf Wiger wrote: > 2008/3/10, Mats Cronqvist : > >> Damien Katz ( of couchDB fame) has written a blog post about the warts >> of erlang. >> (http://damienkatz.net/2008/03/what_sucks_abou.html) >> > > There are several threads in the article (and comments) perhaps worthy > of discussion here at EQ. > > My general impression of the article is that while I agree that the > complaints are valid, the reader comes away from it with the distinct > impression that Damien Katz would be content if he never had to > touch Erlang again, despite the contention that he could fill a book > with the things he likes about it - much like everyone now "knows" > that Erlang sucks at file I/O, since it did in the original Wayfinder > experiments, and it was noted in a blog article. > > So, I'm inclined to agree with Tobbe. Someone reading the article, who > might have been interested in checking out Erlang, might well be > persuaded not to do so. I don't think that was the author's intention. > katz starts out like this; "...it's time to whine about my favorite language I use quite extensively." seems pretty clear that the problem is not that he is a troll, but rather that the erlang community (or at least certain members of it) is immature. CouchDB is a major erlang application, and katz should not have to take any crap from people that has never written a significant piece of erlang (I'm not talking about you, ulf!) more so because most of his complaints are essentially valid. * the syntax does suck. for beginners, because it looks weird (i.e. not like ALGOL), thus being a major obstacle to adoption. for pros, because the silly separators, and the needless verbosity (lambdas, using 'receive' instead of '?', etc) * 'if' is completely worthless, and should ideally be obsoleted. * strings as lists of integers is often annoying. * the X1=x1(X),X2=x2(X1),,, pattern is tedious and error prone. * records are "limited and verbose" (for a reason, but still) * some of the libs/docs are of poor quality. clearly, none of this is particularly bothersome once you've built up some experience. but that doesn't mean they shouldn't be taken seriously, especially if Erlang is to attract coders of katz' quality. (http://damienkatz.net/2005/01/formula-engine-rewrite.html) so what to do? some suggestions; * documenting bad design patterns such as; using 'if', the "numbering variables" pattern etc. * writing a string handling lib on top of binaries * introducing syntax for currying and monads * introducing an alternative to records (http://www.erlang.org/faq/faq.html#AEN1268). * gen_servers with less boilerplate. not very ground-breaking (quite the opposite). A "Worst Practice" document prominently placed on the OTP home page would probably go a long way. > - I'd like to try (= see someone else implement) an indentation-sensitive > front-end to the compiler, but perhaps ROK's suggestion that a full stop > can be used in place of a semicolon would cause less uproar. > this would be truly cool. see http://okasaki.blogspot.com/2008/02/in-praise-of-mandatory-indentation-for.html mats p.s. just to be clear; i think the conservative approach of the OTP team is one of the great things about erlang. in my 10 years at ericsson, where I took part in deploying 1000's of erlang systems, i can not remember a single emulator crash (in a live system). p.p.s. exit(1) when malloc() fails is, i think, The Right Thing(tm). -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/88c8c790/attachment.vcf From parnell.flynn Tue Mar 11 15:48:00 2008 From: parnell.flynn (parnell) Date: Tue, 11 Mar 2008 07:48:00 -0700 (PDT) Subject: [erlang-questions] Unable to get distel documentation Message-ID: <8b34cb5e-fdd4-49af-8529-79232b5abe08@u69g2000hse.googlegroups.com> I have been unable to download the distel documentation I keep getting the following error: "While trying to retrieve the URL: http://fresh.homeunix.net/~luke/distel/distel-3.1.pdf The following error was encountered: Unable to determine IP address from host name for fresh.homeunix.net The dnsserver returned: Name Error: The domain name does not exist. Has anyone else had this issue recently?" Parnell From armando Tue Mar 11 15:50:16 2008 From: armando (Armando Di Cianno) Date: Tue, 11 Mar 2008 10:50:16 -0400 Subject: [erlang-questions] erlang sucks In-Reply-To: <8209f740803110111i539844bal445fd155989cb595@mail.gmail.com> References: <47D52E27.6060901@kreditor.se> <94129836-78E3-4E3E-8407-719C32DD3354@cs.otago.ac.nz> <1205207333.19731.11.camel@isolde> <8209f740803110111i539844bal445fd155989cb595@mail.gmail.com> Message-ID: <1205247016.18244.115.camel@localhost> On Tue, 2008-03-11 at 09:11 +0100, Ulf Wiger wrote: > IOW many complain about various quirks in Erlang, as well as the > apparent lack of efficient (at the very least familiar) string > handling support. We can choose to dismiss the complaints as secondary > (which may or may not be true, depending on context), or address the > specific issues. I am quite sure I read ROK's post as suggesting the > latter, as he suggests fixing the deliminator issue, and puts in a > vote for a unicode-capable string type. I think that something that gets lost in the noise of this discussion is the difference between /better string support/ and /first class support of UTF-8/. I can deal w/o the better string support ad infinitum. I can also deal w/o first class UTF-8 support as long as I'm writing apps that go DB <-> Web. However, if I can't write in Hindi/Sanskrit -- for e.g. -- for a GUI app running on a system, without jumping through hoops, I'm not terribly interested to write more-native-type programs in that language. -- Armando Di Cianno http://dicianno.org/blog armando armando From hasan.veldstra Tue Mar 11 16:17:12 2008 From: hasan.veldstra (Hasan Veldstra) Date: Tue, 11 Mar 2008 15:17:12 +0000 Subject: [erlang-questions] Unicode string library for Erlang Message-ID: <1942F38D-0FBC-4EDB-B6AD-2BA8C753CC32@gmail.com> I've released the alpha version of the Unicode string library for Erlang (based on ICU) that I mentioned on this list a while ago. Right now, most basic operations are supported, like comparison (with or no regard for case), concatenation, getting substrings, searching for substrings, and case conversions. Strings are represented by binaries containing normalized sequences of UTF-16 code units. There are functions to convert between ustrings and UTF-8 lists and binaries. This is alpha code -- there are bugs and limitations. I need your patches, comments and suggestions. :) Starling homepage: http://12monkeys.co.uk/starling/ Google Code page: http://code.google.com/p/starling/ ICU homepage: http://icu-project.org From ulf.wiger Tue Mar 11 16:27:29 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 11 Mar 2008 16:27:29 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> Message-ID: <47D6A4E1.4050402@ericsson.com> Hynek Vychodil skrev: > > > But what I would like to have in Erlang is definitely better > introspection / > reflection capabilities. I would like to have records as runtime > structures, > so I could write: > > Var#{x = foo, y = bar} > > where Var could be any record that has slots x and y (it might have > others), > record_info would be a normal function that can operate on variables. > > > It is misunderstand what record is. Record is not this sort of things. > Use our own structure for this purpose. Record is not object, hash, > dictionary or whatever you really want. Record is not designed for some > sort of inheritance. Record is structure for memory friendly storage of > fixed "records" a which one will be changed very rare and just only by > design. I don't think that these particular aspects of the current record syntax are a "feature", but rather a pretty severe drawback. I have used a hack called exprecs (*), which I think addresses some of the main problems. For one thing, it allows me to "export" record accessors from a certain module, thus letting users of the records read and modify attributes of a record object without having to ensure that their own module was compiled exactly the right version of some include file containing the record definition. I've also found this quite comfortable e.g. when writing a Diameter stack, where a record is the most intuitive representation of a message, but the central logic needs to be able to check the value of a given attribute (e.g. 'Destination-Host'), even though it can't possibly know all add-on message record formats at compile-time: has_dest_host(Rec, Dict) -> try Dict:'#get-'('Destination-Host', Rec) of T -> T /= undefined andalso T /= [] catch error:_ -> false end. Not that I'm putting this forth as an example of better syntax, but as an example of what one might want to do. In general, I think that records and macros introduce compile-time dependencies that can be very painful in large projects. Given that just about everything else can be properly encapsulated and managed at runtime, with polymorphism and all, records and macros stick out like a sore thumb. BR, Ulf W (*) http://forum.trapexit.org/viewtopic.php?p=21790#21790 From rsaccon Tue Mar 11 16:32:56 2008 From: rsaccon (Roberto Saccon) Date: Tue, 11 Mar 2008 12:32:56 -0300 Subject: [erlang-questions] Unable to get distel documentation In-Reply-To: <8b34cb5e-fdd4-49af-8529-79232b5abe08@u69g2000hse.googlegroups.com> References: <8b34cb5e-fdd4-49af-8529-79232b5abe08@u69g2000hse.googlegroups.com> Message-ID: Have you checked all the available doc at http://code.google.com/p/distel ? On Tue, Mar 11, 2008 at 11:48 AM, parnell wrote: > I have been unable to download the distel documentation I keep getting > the following error: > > > > "While trying to retrieve the URL: http://fresh.homeunix.net/~luke/distel/distel-3.1.pdf > > The following error was encountered: > > Unable to determine IP address from host name for > fresh.homeunix.net > > The dnsserver returned: > > Name Error: The domain name does not exist. > > > Has anyone else had this issue recently?" > > Parnell > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Roberto Saccon http://rsaccon.com From sean.hinde Tue Mar 11 16:51:00 2008 From: sean.hinde (Sean Hinde) Date: Tue, 11 Mar 2008 15:51:00 +0000 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <47D6A4E1.4050402@ericsson.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> <47D6A4E1.4050402@ericsson.com> Message-ID: <08B13395-D9DD-4606-A2F7-F3470BBA1F79@gmail.com> > > In general, I think that records and macros introduce > compile-time dependencies that can be very painful in large > projects. Given that just about everything else can be > properly encapsulated and managed at runtime, with polymorphism > and all, records and macros stick out like a sore thumb. We use edep from jungerl to manage record dependencies in normal develop/make cycles. A quick "make depend" after a checkout sets up makefile dependencies for all record definitions. This at least means that future calls to make after a record change will cause all dependent modules to be re- compiled. Highly recommended for larger projects. Sean From mats.cronqvist Tue Mar 11 16:56:25 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 11 Mar 2008 16:56:25 +0100 Subject: [erlang-questions] Unable to get distel documentation In-Reply-To: <8b34cb5e-fdd4-49af-8529-79232b5abe08@u69g2000hse.googlegroups.com> References: <8b34cb5e-fdd4-49af-8529-79232b5abe08@u69g2000hse.googlegroups.com> Message-ID: <47D6ABA9.8050205@kreditor.se> parnell wrote: > I have been unable to download the distel documentation I keep getting > the following error: > > > > "While trying to retrieve the URL: http://fresh.homeunix.net/~luke/distel/distel-3.1.pdf > ~luke is unfortunately out of the picture as far as distel goes. distel is still maintained over at code.google.com/p/distel mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/7e6a4307/attachment.vcf From bekesa Tue Mar 11 16:32:47 2008 From: bekesa (Andras Georgy Bekes) Date: Tue, 11 Mar 2008 16:32:47 +0100 Subject: [erlang-questions] (no subject) In-Reply-To: References: Message-ID: <200803111632.47863.bekesa@sch.bme.hu> > I just find that the following style: > > { ... args needed ... } = compound statement, > use args > > advertises the programmer's intent much more clearly. It states that > the compound statement is being executed for the side effect of > binding a particular set of variables. This binding environment is > necessary for the following statements. I agree, this style is in most cases much better. I tend to use it when I want to bind few names, and I use the other when I bind more. When binding like more than 3 names, writing a >3-tuple everywhere is less readable than binding the names in each of the branches of cases, ifs or receives. However, there is a case when binding values in each case gets problematic: when you throw an exception in some of the cases, but bind names in others. Although you know your function will stop executing in some cases and not binding the names is no problem, the compiler will complain even if it can see the literal throw/1 calls. Georgy From ulf.wiger Tue Mar 11 17:22:19 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 11 Mar 2008 17:22:19 +0100 Subject: [erlang-questions] Unicode string library for Erlang In-Reply-To: <1942F38D-0FBC-4EDB-B6AD-2BA8C753CC32@gmail.com> References: <1942F38D-0FBC-4EDB-B6AD-2BA8C753CC32@gmail.com> Message-ID: <47D6B1BB.4050806@ericsson.com> Hasan Veldstra skrev: > I've released the alpha version of the Unicode string library for > Erlang (based on ICU) that I mentioned on this list a while ago. > > Right now, most basic operations are supported, like comparison (with > or no regard for case), concatenation, getting substrings, searching > for substrings, and case conversions. > > Strings are represented by binaries containing normalized sequences > of UTF-16 code units. There are functions to convert between ustrings > and UTF-8 lists and binaries. > > This is alpha code -- there are bugs and limitations. I need your > patches, comments and suggestions. :) Cool! You may want to think about using a named port instead of always going through a server. Then, any process could call the driver directly using port_call(Port, Op, Data). This is of course an optimization, and figuring out how to do that at this stage may not be worth your time. BR, Ulf W From james.hague Tue Mar 11 17:46:08 2008 From: james.hague (James Hague) Date: Tue, 11 Mar 2008 11:46:08 -0500 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: Ah, this topic :) First the trivia: 1. I'm on board with getting rid of 'if'. I always had to stop and think about whether I wanted 'if' or 'case' so now I use the latter for everything. 2. Oh for swapping the meanings of "=:=" and "==". Now the real issue: commas and semicolons. It used to bother me, to the point where I considered writing a preprocessor to convert from indentation-based formatting, but I've since gotten used to it. The tricky part of indentation based syntax is that you can do stuff like this: [atom1, atom2, 2, case X of true -> ... false -> ... end] Python uses a continuation character at the end of the line, but yuck. It *would* be nice to get rid of semicolons and periods for top-level function definitions, though. That could be done without ambiguity and mocked up via a Perl script in half an hour. James From kevin Tue Mar 11 17:48:38 2008 From: kevin (Kevin Scaldeferri) Date: Tue, 11 Mar 2008 09:48:38 -0700 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205247016.18244.115.camel@localhost> References: <47D52E27.6060901@kreditor.se> <94129836-78E3-4E3E-8407-719C32DD3354@cs.otago.ac.nz> <1205207333.19731.11.camel@isolde> <8209f740803110111i539844bal445fd155989cb595@mail.gmail.com> <1205247016.18244.115.camel@localhost> Message-ID: <96E75A93-77CA-4636-A809-14D8D0CEE38D@scaldeferri.com> On Mar 11, 2008, at 7:50 AM, Armando Di Cianno wrote: > > On Tue, 2008-03-11 at 09:11 +0100, Ulf Wiger wrote: >> IOW many complain about various quirks in Erlang, as well as the >> apparent lack of efficient (at the very least familiar) string >> handling support. We can choose to dismiss the complaints as >> secondary >> (which may or may not be true, depending on context), or address the >> specific issues. I am quite sure I read ROK's post as suggesting the >> latter, as he suggests fixing the deliminator issue, and puts in a >> vote for a unicode-capable string type. > > I think that something that gets lost in the noise of this > discussion is > the difference between /better string support/ and /first class > support > of UTF-8/. Honestly, in this day and age, I'm not convinced there's a strong difference here. Or, rather, the second is a subset of the first. Doing strings well in the modern world necessarily means confronting the issues of Unicode support. (Which I assume is what you really meant. UTF-8 vs. any other character encoding is an implementation detail.) From stondage123 Tue Mar 11 17:41:22 2008 From: stondage123 (Andrew Stone) Date: Tue, 11 Mar 2008 09:41:22 -0700 (PDT) Subject: [erlang-questions] EUnit Message-ID: <154947.44015.qm@web35904.mail.mud.yahoo.com> Thank you very much Hasan. I also noticed that there is an examples directory in the eunit source. I should've given that a look first :) One more question: I put some io:format statements in my setup and cleanup functions but they don't show up. Does that mean they aren't being run properly? Do I need to run something like 'eunit:setup()' first? Also, after some experimentation, I found that a simple way to run all tests in the current directory is eunit:test("."). Thanks, Andrew ----- Original Message ---- From: Hasan Veldstra To: erlang-questions Sent: Tuesday, March 11, 2008 3:00:12 AM Subject: Re: [erlang-questions] EUnit Andrew Stone wrote: > Thanks Richard. But I'm still having a little trouble. What I meant was how do I create a fixture etc...? Here's an example of a simple fixture: simple_test_() -> {setup, local, fun setup/0, %% This is called before the tests are run (to set up things). fun cleanup/1, %% This is called after the tests have been run (to clean up). fun(List) -> %% The argument to this is the return value of setup(). [ ?_assert(2*2 == 4), ?_assert(not(true) == false) ] end}. I agree, the docs are a bit cryptic and it took me a wee while to figure it out. -- http://12monkeys.co.uk http://hypernumbers.com _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From jim.mccoy Tue Mar 11 18:42:57 2008 From: jim.mccoy (Jim McCoy) Date: Tue, 11 Mar 2008 10:42:57 -0700 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: I can live with just about all of the various syntax quirks compared to other languages and in fact am starting to enjoy some of them, but I have to chime in with support for the suggestions that record access needs to be cleaned up a bit. Regardless of what records were intended to solve, they have become the generic "structure" datum for Erlang and I think they need to be extended somewhat to make them a bit more programmer-friendly. Basic introspection, an easier access mechanism, etc. When the FAQ has an entry that is titled "Is it just me, or are records ugly?" I think this might be an indication of the first place to look for syntax tweaks... From sebastian.bello Tue Mar 11 19:11:52 2008 From: sebastian.bello (Sebastian Bello) Date: Tue, 11 Mar 2008 15:11:52 -0300 Subject: [erlang-questions] Passing parameters to a port driver In-Reply-To: <200803082102.m28L2s1H060375@pluto.hedeland.org> References: <200803082102.m28L2s1H060375@pluto.hedeland.org> Message-ID: <47D6CB68.5000705@inswitch.us> Hi Per, thanks for your response. Ideally I would like to perform something like Port = open_port({spawn, "./mylib parm1 parm2"}, []) at the Erlang side, and be able to parse /parmN /from the C side: static ErlDrvData driver_start(ErlDrvPort port, char *buff) { // parse parameters from *buff } That's all; is that possible with a linked-in driver? Thanks, Sebastian- Per Hedeland escribi?: > Sebastian Bello wrote: > >> There is no argc/argv in a linked in driver as far as I know. >> > > Hm, it was a while ago, but according to your quote I wrote: > > >>> (An external port program would (at least on *nix) get >>> the Command in the argc/argv arguments to main()...) >>> > > I'm sorry, but I'm quite unable to parse that as a claim that a driver > would get argc/argv, so I have no idea why you feel the need to state > that it doesn't. But you're quite correct of course. > > >> On the >> driver side you have >> static ErlDrvData driver_start(ErlDrvPort port, char *buff) >> > > Exactly, and as I recall your question was what was in the "buff", which > I explained. > > >> and buff just points to the driver name; >> > > It points to (a C-style copy of) whatever string you passed to > open_port/2. As far as open_port is concerned, the driver name ends at > the first space (which is quite analogous to / consistent with how the > string is parsed in the case of an external port program, though I > hesitate to mention it...). > > >> if you load the driver with >> parameters you just get an "open_error". >> > > Please share the code that gives that result. Of course open_port > doesn't "load the driver", but I assume it's open_port you're talking > about - anyway that's what *I* am talking about. I'm successfully using > the technique I described in commercial product code - in fact it's used > in the OTP code too, e.g. in the dbg module. > > >> Any other ideas? >> > > None needed. > > --Per > > __________ NOD32 2933 (20080310) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/7a9758c2/attachment.html From sebastian.bello Tue Mar 11 19:15:18 2008 From: sebastian.bello (Sebastian Bello) Date: Tue, 11 Mar 2008 15:15:18 -0300 Subject: [erlang-questions] Passing parameters to a port driver In-Reply-To: <47D6CB68.5000705@inswitch.us> References: <200803082102.m28L2s1H060375@pluto.hedeland.org> <47D6CB68.5000705@inswitch.us> Message-ID: <47D6CC36.50002@inswitch.us> It doesn't work with the environment either: Port = open_port({spawn, SharedLib}, [{env, [{"PARM1","p1"},{"PARM2","p2"},{"PARM3","p3"}]}]), Sebastian- Sebastian Bello escribi?: > Hi Per, > > thanks for your response. > Ideally I would like to perform something like > > Port = open_port({spawn, "./mylib parm1 parm2"}, []) > > at the Erlang side, and be able to parse /parmN /from the C side: > > static ErlDrvData driver_start(ErlDrvPort port, char *buff) { > > // parse parameters from *buff > } > > That's all; is that possible with a linked-in driver? > Thanks, > Sebastian- > > > Per Hedeland escribi?: >> Sebastian Bello wrote: >> >>> There is no argc/argv in a linked in driver as far as I know. >>> >> >> Hm, it was a while ago, but according to your quote I wrote: >> >> >>>> (An external port program would (at least on *nix) get >>>> the Command in the argc/argv arguments to main()...) >>>> >> >> I'm sorry, but I'm quite unable to parse that as a claim that a driver >> would get argc/argv, so I have no idea why you feel the need to state >> that it doesn't. But you're quite correct of course. >> >> >>> On the >>> driver side you have >>> static ErlDrvData driver_start(ErlDrvPort port, char *buff) >>> >> >> Exactly, and as I recall your question was what was in the "buff", which >> I explained. >> >> >>> and buff just points to the driver name; >>> >> >> It points to (a C-style copy of) whatever string you passed to >> open_port/2. As far as open_port is concerned, the driver name ends at >> the first space (which is quite analogous to / consistent with how the >> string is parsed in the case of an external port program, though I >> hesitate to mention it...). >> >> >>> if you load the driver with >>> parameters you just get an "open_error". >>> >> >> Please share the code that gives that result. Of course open_port >> doesn't "load the driver", but I assume it's open_port you're talking >> about - anyway that's what *I* am talking about. I'm successfully using >> the technique I described in commercial product code - in fact it's used >> in the OTP code too, e.g. in the dbg module. >> >> >>> Any other ideas? >>> >> >> None needed. >> >> --Per >> >> __________ NOD32 2933 (20080310) Information __________ >> >> This message was checked by NOD32 antivirus system. >> http://www.eset.com >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/bc4a2ec0/attachment.html From attila.rajmund.nohl Tue Mar 11 19:25:03 2008 From: attila.rajmund.nohl (attila.rajmund.nohl) Date: Tue, 11 Mar 2008 19:25:03 +0100 (CET) Subject: [erlang-questions] erlang sucks In-Reply-To: <47D67F5F.1040807@kreditor.se> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> Message-ID: On Tue, 11 Mar 2008, Mats Cronqvist wrote: [...] > more so because most of his complaints are essentially valid. > * the syntax does suck. for beginners, because it looks weird (i.e. not like > ALGOL), thus being a major obstacle to adoption. for pros, because the silly > separators, and the needless verbosity (lambdas, using 'receive' instead of > '?', etc) > * 'if' is completely worthless, and should ideally be obsoleted. > * strings as lists of integers is often annoying. > * the X1=x1(X),X2=x2(X1),,, pattern is tedious and error prone. > * records are "limited and verbose" (for a reason, but still) > * some of the libs/docs are of poor quality. There's one more thing that sometimes drive me nuts - due to the lack of decent 'if' statement, new functions are written instead of branches of a conditional statement. So I see a lot of code like this: do_something(X, Y) -> really_do_something(X, Y). really_do_something(a, Y) -> really_really_do_something(a, Y); ... really_really_do_something(a, b) -> ... % could be a one liner The problem is that the really_really_do_something is way to long to type for people whose editor can't complete function names, so they'll write rrds instead - which is very non-intuitive. I've just checked and our code contains more than 150 functions with 3 character name, more than 50 functions with 2 character name and more than 150 functions with 4 character name. Some of these names actually make sense (e.g. get, set), but most of them do not - and I don't like function names that do not make sense. I haven't seen this practice in C++ or Java projects. Bye,NAR -- "Beware of bugs in the above code; I have only proved it correct, not tried it." From mats.cronqvist Tue Mar 11 19:27:09 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 11 Mar 2008 19:27:09 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <47D6A4E1.4050402@ericsson.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> <47D6A4E1.4050402@ericsson.com> Message-ID: <47D6CEFD.6050606@kreditor.se> Ulf Wiger (TN/EAB) wrote: > > In general, I think that records and macros introduce > compile-time dependencies that can be very painful in large > projects. Given that just about everything else can be > properly encapsulated and managed at runtime, with polymorphism > and all, records and macros stick out like a sore thumb. > ... and parse transforms... mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/f6a091d2/attachment.vcf From attila.rajmund.nohl Tue Mar 11 19:30:14 2008 From: attila.rajmund.nohl (attila.rajmund.nohl) Date: Tue, 11 Mar 2008 19:30:14 +0100 (CET) Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D58650.9030803@erlang-consulting.com> Message-ID: On Tue, 11 Mar 2008, Richard A. O'Keefe wrote: [...] > I generally don't accept arguments about re-ordering definition > clauses, > because if you know what you are doing it is pretty rare. But I > *do* > accept arguments about *adding* clauses when you revise a data > type, so > I wish that Erlang would allow all function clauses to end with a > full > stop. Commenting out first or last clauses or first or last statements are not that rare during debugging - and the compiler error is really annoying at that time. > (2) Again, I generally don't accept arguments about re-ordering function > calls in a body. I don't find that to be a common mistake. Oh, > I do > make mistakes in Erlang. I make mistakes all the time in all > sorts of > languages. One mistake I do make in Erlang and in C is to get > the order > of arguments wrong. So why isn't Mr "Erlang sucks" complaining > bitterly > about how C and Java use different terminators after the last > argument ")" > and all the others ",", making it hard to swap arguments? > Presumably he > isn't complaining about that BECAUSE C and Java do the same > thing, so he > hasn't noticed it. Actually that's annoying in C or Java too. However, reordering arguments is rare during debugging, commenting out arguments is not that rare. And we've got the /* */ style comment in those languages that makes it easy. Bye,NAR -- "Beware of bugs in the above code; I have only proved it correct, not tried it." From mats.cronqvist Tue Mar 11 19:33:08 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 11 Mar 2008 19:33:08 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: <47D6D064.3050205@kreditor.se> Jim McCoy wrote: > ... Regardless of what records were > intended to solve... > i believe that the original requirement was something like; "access to tuple elements by name, but with zero overhead compared to normal tuple access." a pretty tall order (and, with hindsight, misguided)... mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/753a98a9/attachment.vcf From ashishonline Tue Mar 11 19:45:49 2008 From: ashishonline (Ashish Sharma) Date: Wed, 12 Mar 2008 00:15:49 +0530 Subject: [erlang-questions] DHT in erlang Message-ID: <7629cacc0803111145r2dfd1002ybad89e60a813b046@mail.gmail.com> Hi Has anyone implemented some DHT (standard or custom) distributed hash table in erlang or has seen such implementation. Thanks Ashish -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/d3b4d589/attachment.html From richardc Tue Mar 11 20:05:47 2008 From: richardc (Richard Carlsson) Date: Tue, 11 Mar 2008 20:05:47 +0100 Subject: [erlang-questions] EUnit In-Reply-To: <154947.44015.qm@web35904.mail.mud.yahoo.com> References: <154947.44015.qm@web35904.mail.mud.yahoo.com> Message-ID: <47D6D80B.1070302@it.uu.se> Andrew Stone wrote: > One more question: I put some io:format statements in my setup and > cleanup functions but they don't show up. Does that mean they aren't > being run properly? Do I need to run something like 'eunit:setup()' > first? Eunit captures all standard i/o from the tests; you won't see the output from any normal io:format calls. But there are some useful macros defined in eunit.hrl (at the end of the file) that you can use to produce nice debug printouts including module name and line number. These are not only useful while eunit-testing, but can be used for arbitrary printf-debugging. They always send the output to the terminal. (It seems that I never got around to documenting them, but I should. They're pretty straightforward, anyway.) ?debugMsg(S) prints a string ?debugHere prints the current line number ?debugFmt(S, As) prints a formatted string ?debugVal(X) pretty-prints an Erlang term E.g., ?debugHere produces a message like this: ** modulename: 142: <- ?debugMsg("got here") produces: ** modulename: 17: got here and so on. If you define NODEBUG before including eunit.hrl, they have no effect. /Richard From per Tue Mar 11 20:05:38 2008 From: per (Per Hedeland) Date: Tue, 11 Mar 2008 20:05:38 +0100 (CET) Subject: [erlang-questions] Passing parameters to a port driver In-Reply-To: <47D6CB68.5000705@inswitch.us> Message-ID: <200803111905.m2BJ5cKE049297@pluto.hedeland.org> >Sebastian Bello wrote: > >Ideally I would like to perform something like > >Port = open_port({spawn, "./mylib parm1 parm2"}, []) > >at the Erlang side, and be able to parse /parmN /from the C side: > >static ErlDrvData driver_start(ErlDrvPort port, char *buff) { > > // parse parameters from *buff >} > >That's all; is that possible with a linked-in driver? Yes. --Per From sean.hinde Tue Mar 11 20:18:15 2008 From: sean.hinde (Sean Hinde) Date: Tue, 11 Mar 2008 19:18:15 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D67F5F.1040807@kreditor.se> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> Message-ID: On 11 Mar 2008, at 12:47, Mats Cronqvist wrote: > > * 'if' is completely worthless, and should ideally be obsoleted. No, no no! I like 'if' It allows some neat constructs that are horrible with case. Counting 'if' and 'case' for one of the apps in our codebase gives this result: alex:src sean$ grep -v '^[[:space:]]*\($\|%\)' $(find . -name "*rl") | grep " if " | wc -l 345 alex:src sean$ grep -v '^[[:space:]]*\($\|%\)' $(find . -name "*rl") | grep " case " | wc -l 1052 ~ one quarter of branching constructs are 'if'. Not at all insignificant. Sean From mats.cronqvist Tue Mar 11 20:26:51 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 11 Mar 2008 20:26:51 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> Message-ID: <47D6DCFB.9050604@kreditor.se> Sean Hinde wrote: > > On 11 Mar 2008, at 12:47, Mats Cronqvist wrote: > >> >> * 'if' is completely worthless, and should ideally be obsoleted. > > No, no no! I like 'if' It allows some neat constructs that are > horrible with case. i was afraid no one was going to bite... still, I'd like an example or 2. mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/7ae3d7ec/attachment.vcf From fredrik.svahn Tue Mar 11 20:30:32 2008 From: fredrik.svahn (Fredrik Svahn) Date: Tue, 11 Mar 2008 20:30:32 +0100 Subject: [erlang-questions] EEP9 new version Message-ID: A new version of EEP9 is available. In this version I have split the functionality into three parts as per popular demand. A binary_strings module (interface compatible with strings, although some extras added), a binary module (for non-string binaries) and a regexp module (yet to be named, for backwards compatibility it will probably need to exist in parallel with the old). http://www.erlang.org/eeps/eep-0009.html I am also hoping that someone is willing to step up and take the lead for an EEP on unicode support as I believe this is to big to be in this eep. Better many small EEPs than one huge. BR /Fredrik From suranap Tue Mar 11 20:24:34 2008 From: suranap (Pinku Surana) Date: Tue, 11 Mar 2008 15:24:34 -0400 Subject: [erlang-questions] beginner: passing messages between supervisor trees Message-ID: I'm still new to the idea of supervisors in Erlang. Assume I have a client C managed by supervisor MC, and server S managed by supervisor MS. When C sends a message to S, does the message get routed through MC and MS first? Or do C and S communicate directly? If so, where in the code are they connected together? If C sends a message to S and S fails, will C's message be saved somewhere so it can try again after restarting S? Is this done automatically, or manually by one of the supervisors? If S fails repeatedly, then I want to replace it with S2 (a simpler task). How can C's messages be routed to S2 transparently? I don't want C to be aware of the failures. I hope that made sense. Thanks. _________________________________________________________________ Climb to the top of the charts!?Play the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/fc674a04/attachment.html From parnell.flynn Tue Mar 11 20:59:52 2008 From: parnell.flynn (parnell) Date: Tue, 11 Mar 2008 12:59:52 -0700 (PDT) Subject: [erlang-questions] Unable to get distel documentation In-Reply-To: References: <8b34cb5e-fdd4-49af-8529-79232b5abe08@u69g2000hse.googlegroups.com> Message-ID: Yes I installed the user guide, but the paper Distel: Distributed Emacs Lisp, and the reference manual looked interesting. On Mar 11, 9:32 am, "Roberto Saccon" wrote: > Have you checked all the available doc athttp://code.google.com/p/distel? > > On Tue, Mar 11, 2008 at 11:48 AM, parnell > > > > wrote: > > I have been unable to download the distel documentation I keep getting > > the following error: > > > "While trying to retrieve the URL:http://fresh.homeunix.net/~luke/distel/distel-3.1.pdf > > > The following error was encountered: > > > Unable to determine IP address from host name for > > fresh.homeunix.net > > > The dnsserver returned: > > > Name Error: The domain name does not exist. > > > Has anyone else had this issue recently?" > > > Parnell > > _______________________________________________ > > erlang-questions mailing list > > erlang-questi... > > http://www.erlang.org/mailman/listinfo/erlang-questions > > -- > Roberto Sacconhttp://rsaccon.com > _______________________________________________ > erlang-questions mailing list > erlang-questi...://www.erlang.org/mailman/listinfo/erlang-questions From sean.hinde Tue Mar 11 21:06:03 2008 From: sean.hinde (Sean Hinde) Date: Tue, 11 Mar 2008 20:06:03 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D6DCFB.9050604@kreditor.se> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> Message-ID: On 11 Mar 2008, at 19:26, Mats Cronqvist wrote: > Sean Hinde wrote: >> >> On 11 Mar 2008, at 12:47, Mats Cronqvist wrote: >> >>> >>> * 'if' is completely worthless, and should ideally be obsoleted. >> >> No, no no! I like 'if' It allows some neat constructs that are >> horrible with case. > > i was afraid no one was going to bite... still, I'd like an example > or 2. I'm thinking of things like: case X of _ when X == abc; X == xyz -> do_abc_or_xyz(); _ when X == '123', X == '456' -> do_123456() '123' -> do_123_only(); fred -> do_fred() end vs if X == abc; X == xyz -> do_abc_or_xyz(); X == '123', X == '456' -> do_123456(); X == '123' -> do_123_only(); X == fred -> do_fred() end I don't much like the _ when business. 'if' is also useful when you want to branch on a bunch of unrelated boolean variables in various combinations: case {X,Y,Z} of {true, false, _} -> do_a(); {false, _, true} -> do_b(); _ -> do_c() end vs if X and not Y -> do_a; not X and Z -> do_b; true -> do_c end. I find the second more clearly states the intent. You also don't have to remember the positions in the tuple to parse the code (though you do need to know that 'not' is stickier* than 'and') Sean * IANACS From ulf.wiger Tue Mar 11 21:32:15 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 11 Mar 2008 21:32:15 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> Message-ID: <47D6EC4F.50801@ericsson.com> attila.rajmund.nohl skrev: > > There's one more thing that sometimes drive me nuts - due to the lack of > decent 'if' statement, new functions are written instead of branches of > a conditional statement. So I see a lot of code like this: > do_something(X, Y) -> > really_do_something(X, Y). > > really_do_something(a, Y) -> > really_really_do_something(a, Y); > ... > > really_really_do_something(a, b) -> > ... % could be a one liner > > The problem is that the really_really_do_something is way to long to > type for people whose editor can't complete function names, so they'll > write rrds instead - which is very non-intuitive. I've just checked and > our code contains more than 150 functions with 3 character name, more > than 50 functions with 2 character name and more than 150 functions with > 4 character name. Some of these names actually make sense (e.g. get, > set), but most of them do not - and I don't like function names that do > not make sense. I haven't seen this practice in C++ or Java projects. One very good reason for doing this(*) is that Erlang has excellent trace facilities for function calls, but no ability to trace on branching. I tend to agree that it often leads to less readable code, but I don't agree that it's because of 'if' - at least not in the cases where I've observed it in our code. (*) this = using many small functions - not using illegible function names, which is just silly. BR, Ulf W From ulf.wiger Tue Mar 11 21:36:26 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 11 Mar 2008 21:36:26 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <47D6CEFD.6050606@kreditor.se> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> <47D6A4E1.4050402@ericsson.com> <47D6CEFD.6050606@kreditor.se> Message-ID: <47D6ED4A.70807@ericsson.com> Mats Cronqvist skrev: > Ulf Wiger (TN/EAB) wrote: >> >> In general, I think that records and macros introduce >> compile-time dependencies that can be very painful in large >> projects. Given that just about everything else can be >> properly encapsulated and managed at runtime, with polymorphism >> and all, records and macros stick out like a sore thumb. >> > > ... and parse transforms... > > mats No no no no - parse transforms are just wonderful. (: The only thing missing with parse transforms is the ability to introduce new syntax (e.g. like !!). BR, Ulf W From monch1962 Tue Mar 11 21:53:56 2008 From: monch1962 (David Mitchell) Date: Wed, 12 Mar 2008 07:53:56 +1100 Subject: [erlang-questions] Making the step from Erlang to Erlang/OTP Message-ID: Hello all, I'm finding it difficult to jump from "pure" (for want of another term) Erlang code to OTP. I can see that OTP is what I want to be using, but I'm struggling to get my head around taking an existing non-OTP application and converting it to run under OTP. I've read through a bunch of OTP documentation online, but for whatever reason it just isn't jelling in my brain at this point. I think I'm probably at the "information overload" point, and what I need to see now is a walkthrough/tutorial type of document that I haven't come across yet. I can feel that "a-ha!" moment is coming, but it's just out of reach at the moment. If someone's gone through this process and can recommend some online tutorials/discussions/whatever that they found to be particularly useful, could you please highlight them? There's a lot of OTP info out there, and I'm progressively wading through it all, but a pointer to what others have found particularly enlightening would be very handy at this point. Thanks in advance for any suggestions Dave Mitchell From pfisher Tue Mar 11 22:08:43 2008 From: pfisher (Paul Fisher) Date: Tue, 11 Mar 2008 16:08:43 -0500 Subject: [erlang-questions] Making the step from Erlang to Erlang/OTP In-Reply-To: References: Message-ID: <1205269723.6095.121.camel@pfisher-laptop> On Wed, 2008-03-12 at 07:53 +1100, David Mitchell wrote: > Hello all, > > I'm finding it difficult to jump from "pure" (for want of another > term) Erlang code to OTP. > ... > If someone's gone through this process and can recommend some online > tutorials/discussions/whatever that they found to be particularly > useful, could you please highlight them? There's a lot of OTP info > out there, and I'm progressively wading through it all, but a pointer > to what others have found particularly enlightening would be very > handy at this point. I found a few of the tutorials at trapexit.org the most instructive, since they did things that I otherwise understood: http://www.trapexit.org/Building_An_OTP_Application http://www.trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles http://www.trapexit.org/A_fast_web_server_demonstrating_some_undocumented_Erlang_features -- paul From gleber.p Tue Mar 11 22:12:21 2008 From: gleber.p (Gleb Peregud) Date: Tue, 11 Mar 2008 22:12:21 +0100 Subject: [erlang-questions] Making the step from Erlang to Erlang/OTP In-Reply-To: References: Message-ID: <14f0e3620803111412o42f169fbseb9946c0c588c4db@mail.gmail.com> Hello. I'm struggling with the same problem now. I would be very grateful for any suggestions and links too :) Learning curve of OTP is rather steep... On 3/11/08, David Mitchell wrote: > Hello all, > > I'm finding it difficult to jump from "pure" (for want of another > term) Erlang code to OTP. > > I can see that OTP is what I want to be using, but I'm struggling to > get my head around taking an existing non-OTP application and > converting it to run under OTP. > > I've read through a bunch of OTP documentation online, but for > whatever reason it just isn't jelling in my brain at this point. I > think I'm probably at the "information overload" point, and what I > need to see now is a walkthrough/tutorial type of document that I > haven't come across yet. I can feel that "a-ha!" moment is coming, > but it's just out of reach at the moment. > > If someone's gone through this process and can recommend some online > tutorials/discussions/whatever that they found to be particularly > useful, could you please highlight them? There's a lot of OTP info > out there, and I'm progressively wading through it all, but a pointer > to what others have found particularly enlightening would be very > handy at this point. > > Thanks in advance for any suggestions > > Dave Mitchell > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Gleb Peregud http://gleber.pl/ Every minute is to be grasped. Time waits for nobody. -- Inscription on a Zen Gong From ok Tue Mar 11 22:13:34 2008 From: ok (Richard A. O'Keefe) Date: Wed, 12 Mar 2008 10:13:34 +1300 Subject: [erlang-questions] erlang sucks In-Reply-To: <8209f740803110111i539844bal445fd155989cb595@mail.gmail.com> References: <47D52E27.6060901@kreditor.se> <94129836-78E3-4E3E-8407-719C32DD3354@cs.otago.ac.nz> <1205207333.19731.11.camel@isolde> <8209f740803110111i539844bal445fd155989cb595@mail.gmail.com> Message-ID: <009DDCBB-25DF-4EE8-8226-56BA769D8C9E@cs.otago.ac.nz> On 11 Mar 2008, at 9:11 pm, Ulf Wiger wrote: > Just like someone saying "kill two birds with one stone" most likely > doesn't mean it literally, I would wager that mr ROK did not > literally refer to Damien as a whining child - not least because he > is not literally offering a lollipop. For what it's worth, it was an indirect reference to Alan Perlis's epigram number 93: When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. (See SIGPLAN Notices Vol. 17, No. 9, September 1982, pages 7-13.) Epigram 73 is also relevant: It is not a language's weaknesses but its strengths that control the gradient of its change: Alas, a language never escapes its embryonic sac. Epigram 93 got cross-linked with the fact that I *have* children who *do* whine sometimes (well, one of them has experienced pretty much constant pain for over a year and the hospital are having no luck diagnosing it; she can bear it but it's no fun) and I *have* found it rational to offer a lollipop from time to time (distraction is an approved method of coping with pain). Some times there are other things you have to do, and there isn't any point in arguing any more. Take strings. 3 decades of computing have convinced me that in any and every language STRINGS ARE WRONG. Perl is the perfect example of how easy a language can make it to write the wrong program (a program that does the wrong thing, and does it badly). I keep a book on my shelves to show to Perl fans: it's a book explaining in all earnest how to do some useful things in Perl, and every single program in it has at least one fundamental flaw that means it will mostly work most of the time, but break when you need it most. One of the reasons I found C to be a vastly better language for text processing than PL/I (yes, I'm old enough to have been a PL/I programmer) was that C did NOT have a built in string data type. One of the reasons that my C code can still make student C++ code look like a sick snail is that C does not have a built in string data type, and C++ these days does. As for Java, let's not go there. I suspect that there are two things that influence my views which many others do not share. First, a taste for minimalism. In many respects Erlang is a minimalist language, in contrast to C++, which is a maximalist language (except where it might be useful; the arguments against nested functions that made sense for classic C are absurd in the context of C++). Second, experience with several declarative languages and familiarity with the "trees are trivial" way of thinking that goes with that. I have been shocked at how hard our Java-trained students find trees to be; it's a safe bet that someone with a C++ or Java or Perl or Python or Ruby background not only isn't going to think of an alternative to strings for representing text, they aren't going to find it imaginable that there might _be_ an alternative or that it might be desirable. One particular experience sticks with me. Before learning Prolog, I learned Interlisp. I was impressed by the Interlisp pattern-match compiler. Boy, that was cool. I thought. When I met Prolog, I said to myself: "I would like to have something like the Interlisp pattern-match compiler for Prolog. What I'll do is work through the Lisp pattern constructs and see how they can be translated to Prolog, and then I'll write a compiler, using term_expansion/2." But by the time I had finished seeing how to convert an Interlisp pattern to Prolog, I didn't want Interlisp patterns any more. That was for two reasons. The first was that I could now write whatever Interlisp pattern I wanted *directly* in Prolog, and it looked rather better. The second was that I realised that I should usually be using trees, not lists, so that I didn't *have* to do complicated pattern matching. So when people go on and on about wanting strings in Erlang, I find myself wanting to shout THINK! MEASURE! IMAGINE! Or "if you want Perl, you know where to find it". But there comes a point where you realise that that is no longer rational. The fact that we now have to deal with Unicode, which is much more complicated than most programmers realise, means that a string data type would *now* do more than soothe people crying for the old familiar ways of doing things. It really could make it easier for people to write correct Erlang programs, by packaging up all the things that Unicode makes tricky. It *is* in the spirit of Erlang/OTP to provide support for something tricky useful in communication, and binaries (which are logically redundant, given tuples and integers) show that it's in the spirit of Erlang to provide such support even at the expense of minimalism. From ok Tue Mar 11 22:19:59 2008 From: ok (Richard A. O'Keefe) Date: Wed, 12 Mar 2008 10:19:59 +1300 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <47D64A8A.8000008@volny.cz> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> Message-ID: <70FFB05B-F86F-43F4-B5ED-69251F959DAD@cs.otago.ac.nz> On 11 Mar 2008, at 10:02 pm, Ladislav Lenart wrote: > But what I would like to have in Erlang is definitely better > introspection / > reflection capabilities. I would like to have records as runtime > structures, Joe Armstrong and I have independently come up with essentially the same proposal, which is essentially the same thing as LIFE's psi-terms and as a data type whose name I forget in IBM Prolog. Given that these things have been implemented in those two languages, and given my outline of how to implement them, we KNOW it can be done, and it can be done with tolerable effiency. People keep on asking for it. I'm busy this week, but next week I might have time to reformat my proposal as an EEP. If you are reading this, Joe, do you want to do a rival EEP, or should we merge our proposals? From ok Tue Mar 11 22:25:04 2008 From: ok (Richard A. O'Keefe) Date: Wed, 12 Mar 2008 10:25:04 +1300 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> Message-ID: <6AB9FC93-A3E3-4441-BBE7-D5B2B46207CD@cs.otago.ac.nz> On 12 Mar 2008, at 12:05 am, Christian S wrote: > Would it be possible to create a pattern matching syntax for some kind > of association map? Yes it would. Joe Armstrong and I have both produced such designs. I don't know how he intends his to be implemented, but mine manages to be sufficiently memory-efficient in the usual case to completely replace existing uses of records, while still being flexible. It is *definitely* EEP time. From Lennart.Ohman Tue Mar 11 22:14:06 2008 From: Lennart.Ohman (=?iso-8859-1?Q?Lennart_=D6hman?=) Date: Tue, 11 Mar 2008 22:14:06 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> Message-ID: I am compelled to "help" Sean. Further, I feel there is a difference between to pattern-match a branch decision, and to do logical tests. Example of perfectly legal but in my opinion ugly code (where 'if' or using guards in a function-head of a help function is the correct solution): case X of X when X>10 -> :-) Lennart --------------------------------------------------------------------------- Lennart ?hman phone : +46-8-587 623 27 Sj?land & Thyselius Telecom AB cellular: +46-70-552 6735 H?lsingegatan 43, 10th floor fax : +46-8-667 8230 SE-113 31 STOCKHOLM, SWEDEN email : lennart.ohman -----Original Message----- From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Sean Hinde Sent: den 11 mars 2008 20:18 To: Mats Cronqvist Cc: Erlang mailing list Subject: Re: [erlang-questions] erlang sucks On 11 Mar 2008, at 12:47, Mats Cronqvist wrote: > > * 'if' is completely worthless, and should ideally be obsoleted. No, no no! I like 'if' It allows some neat constructs that are horrible with case. Counting 'if' and 'case' for one of the apps in our codebase gives this result: alex:src sean$ grep -v '^[[:space:]]*\($\|%\)' $(find . -name "*rl") | grep " if " | wc -l 345 alex:src sean$ grep -v '^[[:space:]]*\($\|%\)' $(find . -name "*rl") | grep " case " | wc -l 1052 ~ one quarter of branching constructs are 'if'. Not at all insignificant. Sean _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From chandrashekhar.mullaparthi Tue Mar 11 22:29:11 2008 From: chandrashekhar.mullaparthi (Chandru) Date: Tue, 11 Mar 2008 21:29:11 +0000 Subject: [erlang-questions] beginner: passing messages between supervisor trees In-Reply-To: References: Message-ID: On 11/03/2008, Pinku Surana wrote: > > I'm still new to the idea of supervisors in Erlang. Assume I have a client C > managed by supervisor MC, and server S managed by supervisor MS. When C > sends a message to S, does the message get routed through MC and MS first? > Or do C and S communicate directly? No - C and S communicate directly. > If so, where in the code are they connected together? First thing to understand is that a process can use code from many modules. There is no one-to-one mapping from a process to a module. In the code which implements the functionality of C, you send a message to S as follows. S ! message_to_send > > If C sends a message to S and S fails, will C's message be saved somewhere > so it can try again after restarting S? No - any pending messages in the mailbox of S are lost if S exits before processing them.. > Is this done automatically, or manually by one of the supervisors? The supervisor's function is to keep a process alive according to its specification. It is not involved in the message passing. If you want guaranteed message delivery semantics then you have to implement it at an application level i.e server S acknowledged every message it receives to C. > If S fails repeatedly, then I want to replace it with S2 (a simpler task). When you create a supervisor specification, you specify how the process should be started. You have to put such logic in that part of your code. > How can C's messages be routed to S2 transparently? I don't want C to be > aware of the failures. Make sure that S2 registers itself with a name which is the same name you used for S. cheers Chandru From mats.cronqvist Tue Mar 11 22:40:22 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 11 Mar 2008 22:40:22 +0100 Subject: [erlang-questions] Unable to get distel documentation In-Reply-To: References: <8b34cb5e-fdd4-49af-8529-79232b5abe08@u69g2000hse.googlegroups.com> Message-ID: <47D6FC46.7050509@kreditor.se> parnell wrote: > Yes I installed the user guide, but the paper Distel: Distributed > Emacs Lisp, and the reference manual looked interesting. > > On Mar 11, 9:32 am, "Roberto Saccon" wrote: > >> Have you checked all the available doc athttp://code.google.com/p/distel? >> >> On Tue, Mar 11, 2008 at 11:48 AM, parnell >> >> >> >> wrote: >> >>> I have been unable to download the distel documentation I keep getting >>> the following error: >>> >>> "While trying to retrieve the URL:http://fresh.homeunix.net/~luke/distel/distel-3.1.pdf i just tried it and it works... mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/a39dfbcb/attachment.vcf From gaperton Tue Mar 11 22:42:06 2008 From: gaperton (Vlad Balin) Date: Wed, 12 Mar 2008 00:42:06 +0300 Subject: [erlang-questions] SIP server Message-ID: <7c1602610803111442u75143010q8d840af21b98a96a@mail.gmail.com> Hello. I've got following problem - need to design fault-tolerant SIP IP-PBX without single point of failure. We need to tolerate HW failure of single server. Which approach would you suggest? IP address migration, or there are other ways if we dealing with SIP? Thanks in advance, Vlad. From ulf.wiger Tue Mar 11 22:47:49 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Tue, 11 Mar 2008 22:47:49 +0100 Subject: [erlang-questions] beginner: passing messages between supervisor trees In-Reply-To: References: Message-ID: <47D6FE05.1060507@ericsson.com> Pinku Surana skrev: > I'm still new to the idea of supervisors in Erlang. Assume I have a > client C managed by supervisor MC, and server S managed by supervisor > MS. When C sends a message to S, does the message get routed through MC > and MS first? Or do C and S communicate directly? If so, where in the > code are they connected together? The supervisor has nothing to do with messages going between C and S. The only job of the supervisor is to monitor its children, and perhaps restart them if they die. > If C sends a message to S and S fails, will C's message be saved > somewhere so it can try again after restarting S? Is this done > automatically, or manually by one of the supervisors? No. > If S fails repeatedly, then I want to replace it with S2 (a simpler > task). How can C's messages be routed to S2 transparently? I don't > want C to be aware of the failures. If you want this sort of behaviour, you need some kind of buffering process between C and S. The supervisors in Erlang offer no facility for replacing S with S2 after repeating failures. The main reason is that the arguments used for (re-)starting S are the same each time, and S is given no information about why it is restarting, or how many times it's restarted. I did make an extended supervisor behaviour once (haven't mentioned it since end of 2003, so if I'm harping on about it, it's at least at a very low intensity.) It never caught on, so I guess most people are perfectly happy with the existing supervisor module. (: http://www.erlang.org/pipermail/erlang-questions/2003-November/010763.html BR, Ulf W From mogorman Tue Mar 11 22:59:40 2008 From: mogorman (mog) Date: Tue, 11 Mar 2008 16:59:40 -0500 Subject: [erlang-questions] SIP server In-Reply-To: <7c1602610803111442u75143010q8d840af21b98a96a@mail.gmail.com> References: <7c1602610803111442u75143010q8d840af21b98a96a@mail.gmail.com> Message-ID: <47D700CC.1020701@astjab.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vlad Balin wrote: > Hello. > > I've got following problem - need to design fault-tolerant SIP IP-PBX > without single point of failure. We need to tolerate HW failure of > single server. Which approach would you suggest? IP address migration, > or there are other ways if we dealing with SIP? > The best way would be using something like carp or vrrp and an otp based server, with much of the call state and rtp info stored in mnesia across machines. Its a very complicated problem, I have been looking in to doing something similar with iax2 another voip protocol but it is not for the weak of heart. Mog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1wDMpCttrJGOY6gRAu75AKCD1Pd5hsgRprC856KirJlp5eXrgQCfUdx7 RRmeDa5e5XBcM82AJLLaVCk= =4Pmb -----END PGP SIGNATURE----- From chsu79 Tue Mar 11 23:03:16 2008 From: chsu79 (Christian S) Date: Tue, 11 Mar 2008 23:03:16 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <6AB9FC93-A3E3-4441-BBE7-D5B2B46207CD@cs.otago.ac.nz> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> <6AB9FC93-A3E3-4441-BBE7-D5B2B46207CD@cs.otago.ac.nz> Message-ID: On Tue, Mar 11, 2008 at 10:25 PM, Richard A. O'Keefe wrote: > On 12 Mar 2008, at 12:05 am, Christian S wrote: > > Would it be possible to create a pattern matching syntax for some kind > > of association map? > > Yes it would. Joe Armstrong and I have both produced such designs. > I don't know how he intends his to be implemented, but mine manages > to be sufficiently memory-efficient in the usual case to completely > replace existing uses of records, while still being flexible. It is > *definitely* EEP time. I've been looking around for what you have in mind. This one suggests some major changes: http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf This one seem very doable, to the point that I want them already: http://www.erlang.org/ml-archive/erlang-questions/200509/msg00329.html From mats.cronqvist Tue Mar 11 23:11:21 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 11 Mar 2008 23:11:21 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> Message-ID: <47D70389.4030303@kreditor.se> Sean Hinde wrote: > > On 11 Mar 2008, at 19:26, Mats Cronqvist wrote: > >> Sean Hinde wrote: >>> >>> On 11 Mar 2008, at 12:47, Mats Cronqvist wrote: >>> >>>> >>>> * 'if' is completely worthless, and should ideally be obsoleted. >>> >>> No, no no! I like 'if' It allows some neat constructs that are >>> horrible with case. >> >> i was afraid no one was going to bite... still, I'd like an example >> or 2. > > I'm thinking of things like: > > case X of > _ when X == abc; X == xyz -> > do_abc_or_xyz(); > _ when X == '123', X == '456' -> > do_123456() > '123' -> > do_123_only(); > fred -> > do_fred() > end > > vs > > if > X == abc; > X == xyz -> > do_abc_or_xyz(); > X == '123', > X == '456' -> > do_123456(); > X == '123' -> > do_123_only(); > X == fred -> > do_fred() > end > > I don't much like the _ when business. of course, a less (more?) contrived example would be this; case is_imaginary(Friend) of true -> sad(self()); false-> sound(self()) end. vs. FriendIsImaginary = is_imaginary(Friend), if not FriendIsImaginary -> sad(self()); true -> sound(self()) end. where the second one makes my head spin. the point is that you can't ignore the fact that you have to bind X, Y and Z in the 'if' example. > 'if' is also useful when you want to branch on a bunch of unrelated > boolean variables in various combinations: > > case {X,Y,Z} of > {true, false, _} -> > do_a(); > {false, _, true} -> > do_b(); > _ -> > do_c() > end > > vs > > if > X and not Y -> > do_a; > not X and Z -> > do_b; > true -> > do_c > end. same here; when you take into account that you have to bind X, Y and Z in the second example, but not in the first, the 'case' version comes out ahead. objectively :> i remain convinced that 'if' is worthless and does nothing but add to the bloat. mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/f68fa379/attachment.vcf From mats.cronqvist Tue Mar 11 23:14:36 2008 From: mats.cronqvist (Mats Cronqvist) Date: Tue, 11 Mar 2008 23:14:36 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <47D6ED4A.70807@ericsson.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> <47D6A4E1.4050402@ericsson.com> <47D6CEFD.6050606@kreditor.se> <47D6ED4A.70807@ericsson.com> Message-ID: <47D7044C.6020000@kreditor.se> Ulf Wiger (TN/EAB) wrote: > Mats Cronqvist skrev: >> Ulf Wiger (TN/EAB) wrote: >>> >>> In general, I think that records and macros introduce >>> compile-time dependencies that can be very painful in large >>> projects. Given that just about everything else can be >>> properly encapsulated and managed at runtime, with polymorphism >>> and all, records and macros stick out like a sore thumb. >>> >> >> ... and parse transforms... >> >> mats > > No no no no - parse transforms are just wonderful. (: > > The only thing missing with parse transforms is the > ability to introduce new syntax (e.g. like !!). at the very least, the ability to introduce weird compile-time dependencies is second to none. mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080311/6759d2d6/attachment-0001.vcf From mogorman Tue Mar 11 23:29:32 2008 From: mogorman (mog) Date: Tue, 11 Mar 2008 17:29:32 -0500 Subject: [erlang-questions] SIP server In-Reply-To: <7c1602610803111518u1bdca659k99428feed5653ac4@mail.gmail.com> References: <7c1602610803111442u75143010q8d840af21b98a96a@mail.gmail.com> <47D700CC.1020701@astjab.org> <7c1602610803111518u1bdca659k99428feed5653ac4@mail.gmail.com> Message-ID: <47D707CC.1020308@astjab.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Vlad Balin wrote: > CARP looks interesting. Is it supported on Windows? Can't find any > guides how to write CARP-enable applications. > you don't really write carp enabled apps, it just clones the interface and watches for failure. You also don't need this for sip as its udp based so you can have an interface fail and still recover, however you do need to keep up with the state of the calls and the rtp traffic across machines. Mog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1wfMpCttrJGOY6gRAp8vAJoCKH6pacj8f0r2VWI7se6zg8xsRQCfV4rw DSL143Bw/ClJbNyIkWZ4g/Q= =nDs8 -----END PGP SIGNATURE----- From sean.hinde Tue Mar 11 23:31:17 2008 From: sean.hinde (Sean Hinde) Date: Tue, 11 Mar 2008 22:31:17 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D70389.4030303@kreditor.se> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> Message-ID: <48A4CA2B-BFE4-40FA-9955-5169590DF9A8@gmail.com> On 11 Mar 2008, at 22:11, Mats Cronqvist wrote: > Sean Hinde wrote: >> >> >> I don't much like the _ when business. > > of course, a less (more?) contrived example would be this; > > case is_imaginary(Friend) of > true -> sad(self()); > false-> sound(self()) > end. > > vs. > > FriendIsImaginary = is_imaginary(Friend), > if > not FriendIsImaginary -> sad(self()); > true -> sound(self()) > end. > > where the second one makes my head spin. the point is that you can't > ignore the fact that you have to bind X, Y and Z in the 'if' example. I agree your second version is ugly. That is why I idid not write my usage of 'if' in that way ;-) OTOH in our shop we do have one or two horrible sections of code following your convention. In one place we have around 10 variables made boolean then scattered throughout a huge if with many clauses of complex boolean logic - head spinning indeed! Although it's not that obvious how to deal with it in a much better way. We could carefully pick it all apart, looking for state space reductions and building complex hiearchies of smaller functions, but that is a lot of work for perhaps little real gain... > > >> 'if' is also useful when you want to branch on a bunch of unrelated >> boolean variables in various combinations: >> >> case {X,Y,Z} of >> {true, false, _} -> >> do_a(); >> {false, _, true} -> >> do_b(); >> _ -> >> do_c() >> end >> >> vs >> >> if >> X and not Y -> >> do_a; >> not X and Z -> >> do_b; >> true -> >> do_c >> end. > same here; when you take into account that you have to bind X, Y and > Z in the second example, but not in the first, the 'case' version > comes out ahead. objectively :> Why, as the reader of the code, should I care that Z does not have to be bound. As the reader of the code I can divine the intention much more clearly with the second one, therefore it is better. > i remain convinced that 'if' is worthless and does nothing but add > to the bloat. 1/4 of our code says you are wrong! Sean From Attila.Rajmund.Nohl Tue Mar 11 23:36:14 2008 From: Attila.Rajmund.Nohl (Nohl Attila Rajmund) Date: Tue, 11 Mar 2008 23:36:14 +0100 (CET) Subject: [erlang-questions] erlang sucks In-Reply-To: <47D6EC4F.50801@ericsson.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> Message-ID: On Tue, 11 Mar 2008, Ulf Wiger (TN/EAB) wrote: > attila.rajmund.nohl skrev: >> >> There's one more thing that sometimes drive me nuts - due to the lack of >> decent 'if' statement, new functions are written instead of branches of >> a conditional statement. So I see a lot of code like this: >> do_something(X, Y) -> >> really_do_something(X, Y). >> >> really_do_something(a, Y) -> >> really_really_do_something(a, Y); >> ... >> >> really_really_do_something(a, b) -> >> ... % could be a one liner >> >> The problem is that the really_really_do_something is way to long to >> type for people whose editor can't complete function names, so they'll >> write rrds instead - which is very non-intuitive. I've just checked and >> our code contains more than 150 functions with 3 character name, more >> than 50 functions with 2 character name and more than 150 functions with >> 4 character name. Some of these names actually make sense (e.g. get, >> set), but most of them do not - and I don't like function names that do >> not make sense. I haven't seen this practice in C++ or Java projects. > > One very good reason for doing this(*) is that Erlang has excellent > trace facilities for function calls, but no ability to trace on > branching. Yes, erlang has excellent trace facilities, it shows me that the 'rfmm' function was called - unfortunately it doesn't show that which of the 10 rfmm functions was called. OK, I could figure out from the argument list (also in the trace), but when the argument list is 100 lines long (you have to pass the whole damn state as a parameter!), I just don't find it that useful. Actually it's faster to insert some io:format calls into the code and check the output. > I tend to agree that it often leads to less readable > code, but I don't agree that it's because of 'if' - at least not > in the cases where I've observed it in our code. > > (*) this = using many small functions - not using illegible function > names, which is just silly. I agree that using small functions is a good practice. However, many one liner function just makes following the code flow harder, because in the end the code is longer. One pattern I often see is: some_function(X, Y, Z) -> rc(handle_some_function(X, Y, Z)). rc(ok) -> ok; rc(error1) -> handle_error1(); rc(error2) -> handle_error2(). I think this is just bloat, it's a lot more elegant even in pesudo-C: some_function(X, Y, Z) { rc=handle_some_function(X, Y, Z); if (error1==rc) { handle_error1(); } else if (error2==rc) { handle_error2(); } } It's shorter by only 2 lines, still, my eyes don't have to jump around that much when I follow the code. I guess this could be done in erlang with if's, but the crusaders against if's have reached our design rule document :-) Bye,NAR -- NOHL Attila Rajmund, Research Fellow Ericsson R&D, Hungary, IP Services Phone: +36-1-437-7471 H-1037 Budapest, Laborc u. 1. Fax: +36-1-437-7792 Email: Attila.Rajmund.Nohl From sean.hinde Tue Mar 11 23:36:56 2008 From: sean.hinde (Sean Hinde) Date: Tue, 11 Mar 2008 22:36:56 +0000 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> <6AB9FC93-A3E3-4441-BBE7-D5B2B46207CD@cs.otago.ac.nz> Message-ID: On 11 Mar 2008, at 22:03, Christian S wrote: > On Tue, Mar 11, 2008 at 10:25 PM, Richard A. O'Keefe > wrote: >> On 12 Mar 2008, at 12:05 am, Christian S wrote: >>> Would it be possible to create a pattern matching syntax for some >>> kind >>> of association map? >> >> Yes it would. Joe Armstrong and I have both produced such designs. >> I don't know how he intends his to be implemented, but mine manages >> to be sufficiently memory-efficient in the usual case to completely >> replace existing uses of records, while still being flexible. It is >> *definitely* EEP time. > > I've been looking around for what you have in mind. This one suggests > some major changes: > http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf > > This one seem very doable, to the point that I want them already: > http://www.erlang.org/ml-archive/erlang-questions/200509/msg00329.html Or there was the abstract patterns proposal I rather liked: http://www.erlang.org/ml-archive/erlang-questions/200309/msg00309.html Sean From ok Tue Mar 11 23:41:24 2008 From: ok (Richard A.O'Keefe) Date: Wed, 12 Mar 2008 11:41:24 +1300 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <6AB9FC93-A3E3-4441-BBE7-D5B2B46207CD@cs.otago.ac.nz> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <17244f480803102340r7a3ae83ep1bb79579808dd7c8@mail.gmail.com> <47D64A8A.8000008@volny.cz> <4d08db370803110320s77eb3e2akf6df6df20e36fae0@mail.gmail.com> <6AB9FC93-A3E3-4441-BBE7-D5B2B46207CD@cs.otago.ac.nz> Message-ID: <470A097D-F03B-43DF-9E18-866EBF2ACABB@cs.otago.ac.nz> On 12 Mar 2008, at 10:25 am, Richard A. O'Keefe wrote: > It is > *definitely* EEP time. Until I find the time to recast this in EEP form, could people who are interested in a replacement for records and haven't already done so look at http://www.cs.otago.ac.nz/staffpriv/ok/frames.pdf which is my 2003 proposal. From sean.hinde Tue Mar 11 23:50:31 2008 From: sean.hinde (Sean Hinde) Date: Tue, 11 Mar 2008 22:50:31 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> Message-ID: On 11 Mar 2008, at 22:36, Nohl Attila Rajmund wrote: > On Tue, 11 Mar 2008, Ulf Wiger (TN/EAB) wrote: > >> attila.rajmund.nohl skrev: >>> >>> > > I agree that using small functions is a good practice. However, many > one > liner function just makes following the code flow harder, because in > the > end the code is longer. One pattern I often see is: > > some_function(X, Y, Z) -> > rc(handle_some_function(X, Y, Z)). > > rc(ok) -> > ok; > > rc(error1) -> > handle_error1(); > > rc(error2) -> > handle_error2(). > > I think this is just bloat, it's a lot more elegant even in pesudo-C: > > some_function(X, Y, Z) { > rc=handle_some_function(X, Y, Z); > if (error1==rc) { > handle_error1(); > } > else if (error2==rc) { > handle_error2(); > } > } > > It's shorter by only 2 lines, still, my eyes don't have to jump around > that much when I follow the code. I guess this could be done in erlang > with if's, but the crusaders against if's have reached our design rule > document :-) If rc is a common error handling function for many functions throughout the module then I'd say this was OK and serves it's purpose well. The more normal Erlang way to write the equivalent of the C version would be simply: some_function(X,Y,Z) -> case handle_some_function(X,Y,Z) of ok -> ok; error1 -> handle_error1(); error2 -> handle_error2() end. I'd argue that it is even more readable than the C version. And not an 'if' in sight :-) Sean From kevin Tue Mar 11 23:41:34 2008 From: kevin (Kevin Scaldeferri) Date: Tue, 11 Mar 2008 15:41:34 -0700 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: <47D6FE69.4030209@kreditor.se> References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <4d08db370803102332p39ac9f8fhb37cc57cbe8a4ea1@mail.gmail.com> <0353893A-483E-4BFF-9A12-29663E4C5A2B@scaldeferri.com> <47D6436A.7080608@kreditor.se> <5383FCBE-E9A5-4AAB-BFBC-FBCD9D92EDA8@scaldeferri.com> <47D6A707.5020009@kreditor.se> <47D6FE69.4030209@kreditor.se> Message-ID: somehow this branch of the conversation went off-list. Bringing it back as others might be interested. -kevin On Mar 11, 2008, at 2:49 PM, Mats Cronqvist wrote: > Kevin Scaldeferri wrote: >> >> On Mar 11, 2008, at 8:36 AM, Mats Cronqvist wrote: >> >>> Kevin Scaldeferri wrote: >>>> >>>> On Mar 11, 2008, at 1:31 AM, Mats Cronqvist wrote: >>>> >>>>>>>> >>>>> IANACS(*), but i thought currying was supposed to look like this; >>>>> >>>>> curry(F,Arg) -> >>>>> case erlang:fun_info(F,arity) of >>>>> {_,1} -> fun() -> F(Arg) end; >>>>> {_,2} -> fun(A) -> F(A,Arg) end; >>>>> {_,3} -> fun(A,B) -> F(A,B,Arg) end; >>>>> {_,4} -> fun(A,B,C) -> F(A,B,C,Arg) end >>>>> end. >>>>> >>>> >>>> No, that's partial application. Or, sort of reverse partial >>>> application. Compare to the papply function I wrote. >>>> >>>> >>>> -kevin >>> >>> like i said, i really have no idea what i'm talking about. but i >>> found several descriptions like this; >>> >>> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52549 >>> >>> "In functional programming, currying is a way to bind arguments with >>> a function and wait for the rest of the arguments to show up later. >>> You "curry in" the first few parameters to a function, giving >>> you a function that takes subsequent parameters as input and >>> calls the original with all of those parameters." >>> >>> i'm so confused... >> >> So is the author of that paragraph :-). Here's a better >> explanation from wikipedia: http://en.wikipedia.org/wiki/Currying >> >> "Given a function f of type f : (X x Y) -> Z , then currying it >> makes a function curry(f) : X -> (Y -> Z) . That is, curry(f) takes >> an argument of type X and returns a function of type Y -> Z . " >> >> So, what you see here is that in some sense currying is a precursor >> to partial application. > > i guess you just can't trust random web pages these days... i found > a better source of info on the haskell web (surprise!) > >> Part of the confusion in talking about this is that this is all in >> the context of theories of computation where all functions are >> unary (like the lambda calculus). In languages with arbitrary >> arity of functions, it's a little less clear what currying means. >> I made the choice to interpret it as converting a unary function >> expecting a tuple into a multi-ary function. You could argue, >> though, that maybe it should be this instead: >> >> curry(F) when is_function(F,2)-> >> fun(X) -> >> fun(Y) -> F(X,Y) end >> end. >> >> >> Notice, though, that curry() doesn't actually apply any arguments, >> it just returns a function which naturally allows partial >> application. > > i see... thanks a lot for your time! > >> >> -kevin >> >> P.S. Did you intentionally only send this to me? I think there's >> frequent confusion about this, so it seems to be like valuable >> discussion for the list >> > i did "reply all" in my trusty old thunderbird; i think your > previous mail was sent to me only (at least it looked like that to > thunderbird). feel free to forward any/all of this to the list. i'm > pretty sure i'm not the only one confused by this (though i might be > the only one that cares, of course.) > > mats > From gaperton Wed Mar 12 00:24:49 2008 From: gaperton (Vlad Balin) Date: Wed, 12 Mar 2008 02:24:49 +0300 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> Message-ID: <7c1602610803111624o7a1814b4k4ea4317ba205f395@mail.gmail.com> > Perhaps a stupid question. Do LFE implement currying? > If not, why? > > I want currying... :-) Not a big deal. your_curried_func( A ) -> fun( B, C ) -> your_curried_func( A, B, C ) end. your_curried_func( A, B ) -> fun( C ) -> your_curried_func( A, B, C ) end. your_curried_func( A, B, C ) -> ... One extra line for each curring case. For me it's completely ok, but you can define macro to hide this stuff if it bothers you. You'll get something like this: ?curried_3( your_curried_func ) your_curried_func( A, B, C ) -> ... From rvirding Wed Mar 12 01:27:57 2008 From: rvirding (Robert Virding) Date: Wed, 12 Mar 2008 01:27:57 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <47D6D064.3050205@kreditor.se> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <47D6D064.3050205@kreditor.se> Message-ID: <3dbc6d1c0803111727n3a987fd1y17a342c564b063ad@mail.gmail.com> On 11/03/2008, Mats Cronqvist wrote: > > Jim McCoy wrote: > > ... Regardless of what records were > > intended to solve... > > > i believe that the original requirement was something like; "access to > tuple elements by name, but with zero overhead compared to normal tuple > access." > a pretty tall order (and, with hindsight, misguided)... Yes, this was one of the original requirements of our first/major users. They wanted named fields but as fast as using tuples directly. The system (computer+emulator) wasn't as fast in those days and they felt they couldn't offer performance. It was not misguided then. Anyway this meant that everything had to be done at compile-time, which *is* very un-Erlangy. Some other factors which influenced the syntax: - No typing in Erlang and no record information in the record (for speed). This meant that you either have a shared field-name space over all records with unique field-names over all records or you had to explicitly say which record type it was. We chose the latter as being more manageable. - The syntax and semantics of '=' as a match and that it returned the RHS value which meant that you can do X = {P,Q,R} = ... . There were no aliases in patterns then. This made a field setting syntax difficult. Perhaps it would have been better to generate access functions or macros instead (like lisps and LFE do) but macros were very new then and we weren't yet into that. That would be possible to add today. I definitely think it is time to add runtime dynamic structures to the language. As Richard O'Keefe mentioned there are at least two suggestions for this, his own and one from Joe. Robert mats > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/242e6817/attachment-0001.html From rvirding Wed Mar 12 01:43:38 2008 From: rvirding (Robert Virding) Date: Wed, 12 Mar 2008 01:43:38 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D70389.4030303@kreditor.se> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> Message-ID: <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> On 11/03/2008, Mats Cronqvist wrote: > > > > i remain convinced that 'if' is worthless and does nothing but add to > the bloat. It would actually be possible to extend 'if' to allow non-guard tests and user defined boolean functions in the test. Like in lisp. It would be almost backwards compatible in that existing code would behave the same, BUT there would be one fundamental difference for other tests. As the tests in 'if' are guard tests then type errors just equate to failure of the guard while an error in a non-guard test function (user or otherwise) would result in an error being generated for the whole 'if' and function. Catching errors in the test would probably be expensive (Bj?rn?) and in some way break Erlang semantics in adding implicit 'try's. But the resulting 'if' would definitely be more useful. Robert mats > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/6350fc36/attachment.html From rvirding Wed Mar 12 01:58:38 2008 From: rvirding (Robert Virding) Date: Wed, 12 Mar 2008 01:58:38 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> Message-ID: <3dbc6d1c0803111758w6aa6eb6ob781cbc675bdc580@mail.gmail.com> Very few of the misfeatures of Erlang syntax are new, though this doesn't make them less important. Some are be fixable. I was probably a little unclear but I was interested in the question of a whole new syntax, which at least Ulf understood. And the follow-up question of whether this would satisfy people? For example assume we did a new flavour of Erlang based on Java which had the look of Java but still had Erlang semantics (it couldn't be otherwise). Would this make new users who came from more traditional languages happy? Or would it just make it worse in that it might look the same as what they are used to (sort of) but there would still be no "real" assignments or destructive operations or loops etc ? I suppose the question really gets back to where the *real* problem is. Is it really the syntax, or is it actually the semantics but people see it a syntax problem because that is what they see first, the syntax? If a new syntax really solved new users problems then it might be worth doing, otherwise not. What do people think? One benefit on basing a new syntax on a typed language would be that adding (optional) type declarations would still look "right". Typing records just looks weird to me. :-) Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/6b9c382a/attachment.html From ok Wed Mar 12 05:35:44 2008 From: ok (Richard A. O'Keefe) Date: Wed, 12 Mar 2008 17:35:44 +1300 Subject: [erlang-questions] LFE - Lisp Flavoured Erlang released In-Reply-To: References: <3dbc6d1c0803011700p185f4a9o70c87958ca6def29@mail.gmail.com> <4d08db370803102332p39ac9f8fhb37cc57cbe8a4ea1@mail.gmail.com> <0353893A-483E-4BFF-9A12-29663E4C5A2B@scaldeferri.com> <47D6436A.7080608@kreditor.se> <5383FCBE-E9A5-4AAB-BFBC-FBCD9D92EDA8@scaldeferri.com> <47D6A707.5020009@kreditor.se> <47D6FE69.4030209@kreditor.se> Message-ID: <179BF66C-A961-4DD1-BCFD-AC2B017D3EA2@cs.otago.ac.nz> Can we distinguish, please, between partial application and currying? Neither of them is a special case of the other. Currying is the act of taking a function of multiple arguments and, without binding any, returning a function that takes them one at a time. For example, curry(F) -> case erlang:fun_info(F, arity) of 0 -> fun (_) -> F() end ; 1 -> F ; 2 -> fun (X1) -> fun (X2) -> F(X1,X2) end end ; 3 -> fun (X1) -> fun (X2) -> fun (X3) -> F(X1,X2,X3) end end end % continue as long as you have patience or use end. Partial application is the act of taking a function of multiple arguments and, by some means, supplying some but not all of them, returning a function, not necessarily unary, awaiting the rest. The British AI language Pop-2 supported partial application but not currying. If I remember correctly, f(% ... %) provided *trailing* arguments for f, leaving it still awaiting its leading arguments. With a curried function, it is easiest to provide leading arguments, but it is often useful to supply others. For example, in Haskell a binary operator like > is curried: > :: Ord a => a -> a -> Bool We might want to supply *either* of the arguments: x_exceeds = (x >) returns \y -> x > y exceeding_x = (> x) returns \y -> y > x Working on binary functions, we might have apply_left(X, Op) -> fun (Y) -> Op(X, Y) end. apply_right(Op, Y) -> fun (X) -> Op(X, Y) end. From ok Wed Mar 12 05:56:40 2008 From: ok (Richard A. O'Keefe) Date: Wed, 12 Mar 2008 17:56:40 +1300 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803111758w6aa6eb6ob781cbc675bdc580@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <3dbc6d1c0803111758w6aa6eb6ob781cbc675bdc580@mail.gmail.com> Message-ID: On 12 Mar 2008, at 1:58 pm, Robert Virding wrote: > Very few of the misfeatures of Erlang syntax are new, though this > doesn't make them less important. Some are be fixable. > > I was probably a little unclear but I was interested in the question > of a whole new syntax, which at least Ulf understood. And the follow- > up question of whether this would satisfy people? It seems to me that a new syntax for Erlang should do one of three things, and ideally should do them all. (1) Reduce the labour of creating Erlang. I have a proposal for 'HaskErl' -- a Haskell-inspired syntax for Erlang, which has not kept up with developments in the bit syntax. I found that this can reduce the SLOC count by a factor of 1.6. That is, for every 8 lines of Erlang, there would be 5 lines of HaskErl. In code which is heavily commented, of course, the total effect would be much reduced, because the comments would not change. (2) Reduce the error rate when creating Erlang. That is, it should lead you into making fewer mistakes. One can have ideas about what _ought_ to be error prone, but really, empirical measurement is called for. HaskErl requires explicit 'let' for binding identifiers (or equally explicit comprehensions), reducing some errors, but the great reduction in parentheses and commas presumably increases others. (3) Reduce the labout of editing Erlang. This, of course, invites (NOT "begs") the question "by what editor?" Arguably, Lisp is about as good as it gets here, and LFE is a very worthwhile experiment. I don't list "familiarity" as a criterion, for two reasons. - The kind of programmer who is likely to be interested in Erlang is likely to already be familiar with at least one language that didn't steal its syntax from C. - Too much similarity can lead to mistakes when things aren't _exactly_ the same. When I was taught French at school, I was warned about "faux amis": words that looked exactly like English words, but didn't mean the same. > I suppose the question really gets back to where the *real* problem > is. Is it really the syntax, or is it actually the semantics but > people see it a syntax problem because that is what they see first, > the syntax? If a new syntax really solved new users problems then it > might be worth doing, otherwise not. What do people think? Does anyone remember a story by John Brunner about "stardroppers"? It appeared as a serial in Analog, but was also published as a book. The hero was a government agent. One of the nice little gimmicks in the book was that he communicated with his superiors in a unique language specially designed for him, based on his person and personality. When he reported to them, he never knew what he said, but it felt really really comfortable saying it. My point is that syntax isn't *the* problem, but it is *a* problem in the sense that practically everyone has a language in them, and Erlang isn't it, and the mismatch will be a source of discomfort. Does anyone remember the wave of PL/I-like languages? Or the wave of Algol 68-inspired languages? Or the later wave of Pascal-like languages? Heck, I've even seen a language that borrowed the control structures of SNOBOL! PL/I is pretty much gone; Pascal is pretty much gone; SNOBOL is gone; but Lisp is still with us. Oh yeah, so are Fortran, Basic, and COBOL. Should we make Erlang look like COBOL? If Erlang got a Java-inspired syntax, we'd still get grief from people who wanted it to look like C# instead. From paul-trapexit Wed Mar 12 06:07:55 2008 From: paul-trapexit (Paul Mineiro) Date: Tue, 11 Mar 2008 22:07:55 -0700 (PDT) Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803111758w6aa6eb6ob781cbc675bdc580@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <3dbc6d1c0803111758w6aa6eb6ob781cbc675bdc580@mail.gmail.com> Message-ID: Re: syntax vs. semantics, from someone who recently learned the language. I got the semantics. It's why I pushed through the warts in the syntax; and coming from Haskell, there were alot of things that were not as nice. Most of them have already been mentioned, no need to rehash. Now I'm used to it, and in 3 months our little startup has a cloud computing infrastructure that I only dreamed about at my large company job, and we never go down thanks to hot code deployment. So Erlang does not suck. However I hope it does not rest on its laurels either. Good syntax makes life more pleasant. -- p On Wed, 12 Mar 2008, Robert Virding wrote: > Very few of the misfeatures of Erlang syntax are new, though this doesn't > make them less important. Some are be fixable. > > I was probably a little unclear but I was interested in the question of a > whole new syntax, which at least Ulf understood. And the follow-up question > of whether this would satisfy people? > > For example assume we did a new flavour of Erlang based on Java which had > the look of Java but still had Erlang semantics (it couldn't be otherwise). > Would this make new users who came from more traditional languages happy? Or > would it just make it worse in that it might look the same as what they are > used to (sort of) but there would still be no "real" assignments or > destructive operations or loops etc ? > > I suppose the question really gets back to where the *real* problem is. Is > it really the syntax, or is it actually the semantics but people see it a > syntax problem because that is what they see first, the syntax? If a new > syntax really solved new users problems then it might be worth doing, > otherwise not. What do people think? > > One benefit on basing a new syntax on a typed language would be that adding > (optional) type declarations would still look "right". Typing records just > looks weird to me. :-) > > Robert > Optimism is an essential ingredient of innovation. How else can the individual favor change over security? -- Robert Noyce From bengt.kleberg Wed Mar 12 08:11:07 2008 From: bengt.kleberg (Bengt Kleberg) Date: Wed, 12 Mar 2008 08:11:07 +0100 Subject: [erlang-questions] EEP9 new version In-Reply-To: References: Message-ID: <1205305868.5392.2.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, The existing module is called 'string' (not strings). Perhaps you do want binary_string but mistyped it as binary_strings below? bengt On Tue, 2008-03-11 at 20:30 +0100, Fredrik Svahn wrote: > A new version of EEP9 is available. > > In this version I have split the functionality into three parts as per > popular demand. A binary_strings module (interface compatible with > strings, although some extras added), a binary module (for non-string > binaries) and a regexp module (yet to be named, for backwards > compatibility it will probably need to exist in parallel with the > old). > > http://www.erlang.org/eeps/eep-0009.html > > I am also hoping that someone is willing to step up and take the lead > for an EEP on unicode support as I believe this is to big to be in > this eep. Better many small EEPs than one huge. > > BR /Fredrik > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From francisstephens Wed Mar 12 08:22:10 2008 From: francisstephens (Francis Stephens) Date: Wed, 12 Mar 2008 20:22:10 +1300 Subject: [erlang-questions] Functional Datastructures Message-ID: <1630bf30803120022h3f9203dcr72328e46dd352c1c@mail.gmail.com> I am trying to build an efficient data structure for representing boolean expressions in Erlang. I am having trouble producing a good data structure in a functional context, although there are very fast data structures for imperative languages like C. The data structure is to be used for a functional SAT solver. A boolean expression (always in conjunctive normal form) can be described as a set of variables, such as {p,q,r...} where each variable in the set is mapped to one of three values true|false|indetermined yielding something like {{p->ind},{q->true},{r->ind},...}. The expression is described as a set of sets of literals, where a literal is a variable with a possible negation (~). So we have something like {{~p,q},{~q,r}} which describes a formula that would usually be written (~p v q)&(~q v r). Each of the inner sets has the property that if one of its literals evaluates to true then the whole set can be removed from the outer set. To being with we can represent the expression as a list of lists where the variable-name, negation and value are all stored in one tuple. [[{name,negation,value}]] Now if we assign a value to a variable we then need to traverse every sublist ensuring a consistent assignment is made for every occurrence of the varia ble in the expression. However, as a reward for this effort we can easily check each sublist to see whether one of its members evaluates to true (meaning the sublist can be removed). Alternately we could represent the expression as a list of lists where just the variable name and negation are recorded {name,negation} and have the assignment values stored as a separate mapping. This makes assignments fast and safer, but we still need to traverse every sublist to see that it does not now contain a literal evaluating to true. Is there a better way, I suspect that I am thinking about it in the wrong way. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/ffe55ad2/attachment-0001.html From fredrik.svahn Wed Mar 12 08:27:26 2008 From: fredrik.svahn (Fredrik Svahn) Date: Wed, 12 Mar 2008 08:27:26 +0100 Subject: [erlang-questions] EEP9 new version In-Reply-To: <1205305868.5392.2.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <1205305868.5392.2.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: I seem to have slipped on the keyboard when writing the mail. binary_string it is. BR /Fredrik On Wed, Mar 12, 2008 at 8:11 AM, Bengt Kleberg wrote: > Greetings, > > The existing module is called 'string' (not strings). Perhaps you do > want binary_string but mistyped it as binary_strings below? > > > bengt > > > > On Tue, 2008-03-11 at 20:30 +0100, Fredrik Svahn wrote: > > A new version of EEP9 is available. > > > > In this version I have split the functionality into three parts as per > > popular demand. A binary_strings module (interface compatible with > > strings, although some extras added), a binary module (for non-string > > binaries) and a regexp module (yet to be named, for backwards > > compatibility it will probably need to exist in parallel with the > > old). > > > > http://www.erlang.org/eeps/eep-0009.html > > > > I am also hoping that someone is willing to step up and take the lead > > for an EEP on unicode support as I believe this is to big to be in > > this eep. Better many small EEPs than one huge. > > > > BR /Fredrik > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From anders.gs.svensson Wed Mar 12 08:39:28 2008 From: anders.gs.svensson (Anders G S Svensson) Date: Wed, 12 Mar 2008 08:39:28 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: References: Message-ID: <18391.34992.129455.726409@gargle.gargle.HOWL> Attila.Rajmund.Nohl writes: > > On Tue, 11 Mar 2008, Ulf Wiger (TN/EAB) wrote: > > > attila.rajmund.nohl skrev: > > > > One very good reason for doing this(*) is that Erlang has excellent > > trace facilities for function calls, but no ability to trace on > > branching. > > Yes, erlang has excellent trace facilities, it shows me that the 'rfmm' > function was called - unfortunately it doesn't show that which of the 10 > rfmm functions was called. OK, I could figure out from the argument list > (also in the trace), but when the argument list is 100 lines long (you > have to pass the whole damn state as a parameter!), I just don't find it > that useful. Actually it's faster to insert some io:format calls into > the code and check the output. You might not think that when the code is at a customer site and applying patches isn't something the customer (or the layers of management between you and the customer) will let you do. > > I tend to agree that it often leads to less readable > > code, but I don't agree that it's because of 'if' - at least not > > in the cases where I've observed it in our code. > > > > (*) this = using many small functions - not using illegible function > > names, which is just silly. > > I agree that using small functions is a good practice. However, many one > liner function just makes following the code flow harder, because in the > end the code is longer. One pattern I often see is: This is just your opinion of course but consider your example below and replace handle_error1/handle_error2 with calls to some popular OTP function say. The advantage of the one-liners is that you can see what code you've executed by tracing on rc/1 alone. Rewrite it as a case and you might still be able to if the different branches of your case return distinct values but if not then you have to trace on these popular OTP functions as well, which may give you a lot more trace than you bargained for for starters. Things can get a lot worse in real code in which constructing appropriate trace to determine what's going on can be a real chore. If I had my way I'd remove the case statement along with the if statement since their overuse can effectively negate the advantage that the trace facilities provide. Anders > > some_function(X, Y, Z) -> > rc(handle_some_function(X, Y, Z)). > > rc(ok) -> > ok; > > rc(error1) -> > handle_error1(); > > rc(error2) -> > handle_error2(). > > I think this is just bloat, it's a lot more elegant even in pesudo-C: > > some_function(X, Y, Z) { > rc=handle_some_function(X, Y, Z); > if (error1==rc) { > handle_error1(); > } > else if (error2==rc) { > handle_error2(); > } > } > > It's shorter by only 2 lines, still, my eyes don't have to jump around > that much when I follow the code. I guess this could be done in erlang > with if's, but the crusaders against if's have reached our design rule > document :-) > Bye,NAR > -- > NOHL Attila Rajmund, Research Fellow > Ericsson R&D, Hungary, IP Services Phone: +36-1-437-7471 > H-1037 Budapest, Laborc u. 1. Fax: +36-1-437-7792 > Email: Attila.Rajmund.Nohl From ulf.wiger Wed Mar 12 08:42:02 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Wed, 12 Mar 2008 08:42:02 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> Message-ID: <47D7894A.3030909@ericsson.com> Robert Virding skrev: > > It would actually be possible to extend 'if' to allow non-guard tests > and user defined boolean functions in the test. Like in lisp. It would > be almost backwards compatible in that existing code would behave the > same, BUT there would be one fundamental difference for other tests. As > the tests in 'if' are guard tests then type errors just equate to > failure of the guard while an error in a non-guard test function (user > or otherwise) would result in an error being generated for the whole > 'if' and function. Catching errors in the test would probably be > expensive (Bj?rn?) and in some way break Erlang semantics in adding > implicit 'try's. > > But the resulting 'if' would definitely be more useful. If there's such a dire need for an if-like construct with slightly different semantics than the existing 'if', let's not break existing code by changing 'if', but rather adding (bloat) another construct. Perhaps we should call it 'switch', and make it almost like a C switch, but subtly different in creative ways? (: The 'if' statement is not high on my list of things that need improving. It's actually quite ok, except it could perhaps have been named differently, in order not to give people false expectations. BR, Ulf W From mats.cronqvist Wed Mar 12 09:20:11 2008 From: mats.cronqvist (Mats Cronqvist) Date: Wed, 12 Mar 2008 09:20:11 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D7894A.3030909@ericsson.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> Message-ID: <47D7923B.8080400@kreditor.se> Ulf Wiger (TN/EAB) wrote: > Robert Virding skrev: > >> ... >> But the resulting 'if' would definitely be more useful. >> > ... > > The 'if' statement is not high on my list of things that need > improving. It's actually quite ok, except it could perhaps have > been named differently, in order not to give people false > expectations. just to be clear; i don't think 'if ' should be improved. and i realize it cannot be removed either :< what i proposed was that it'd be obsoleted. in practice that would mean that there'd be a prominent document named "Obsolete features" or somesuch. That document would list old cruft; such as * 'if' * the three different 'and' (*) * split_binary() * the old type guards (integer() vs. is_integer()) * tuple funs etc... mats (*) (case x of x when true,false ->ok; _-> nok end. nok case x of x when true and false ->ok; _-> nok end. nok case x of x when true andalso false ->ok; _-> nok end. nok -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/6b0e81be/attachment.vcf From mats.cronqvist Wed Mar 12 09:32:07 2008 From: mats.cronqvist (Mats Cronqvist) Date: Wed, 12 Mar 2008 09:32:07 +0100 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803111727n3a987fd1y17a342c564b063ad@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <47D6D064.3050205@kreditor.se> <3dbc6d1c0803111727n3a987fd1y17a342c564b063ad@mail.gmail.com> Message-ID: <47D79507.4070702@kreditor.se> Robert Virding wrote: > On 11/03/2008, *Mats Cronqvist* > wrote: > > Jim McCoy wrote: > > ... Regardless of what records were > > intended to solve... > > > i believe that the original requirement was something like; > "access to > tuple elements by name, but with zero overhead compared to normal > tuple > access." > a pretty tall order (and, with hindsight, misguided)... > > > Yes, this was one of the original requirements of our first/major > users. They wanted named fields but as fast as using tuples directly. > The system (computer+emulator) wasn't as fast in those days and they > felt they couldn't offer performance. It was not misguided then. > Anyway this meant that everything had to be done at compile-time, > which *is* very un-Erlangy. (with hindsight) i think it's obvious that a few percentage points of performance was not worth the drawbacks of records. mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/7d5e957e/attachment.vcf From C.Grasl Wed Mar 12 09:38:30 2008 From: C.Grasl (Grasl Christoph) Date: Wed, 12 Mar 2008 09:38:30 +0100 Subject: [erlang-questions] erlang ***** Message-ID: <94C5430AA547F24AA801BA5706F29D2E25CD02@srvkeyx01.KEYTRONIX.local> Hi all! Since this topic seems to be dominant in the last days i would recommend a topic-name change. It's a real pitty to read this in conjunction with a powerful & pragmatic language (obviously with certain advantages and disadvantages). A lot of people are very enthusiastic about erlang, and that for a lot of good reasons.. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/31ea00d9/attachment.html From tuncer.ayaz Wed Mar 12 10:32:33 2008 From: tuncer.ayaz (Tuncer Ayaz) Date: Wed, 12 Mar 2008 10:32:33 +0100 Subject: [erlang-questions] SIP server In-Reply-To: <7c1602610803111442u75143010q8d840af21b98a96a@mail.gmail.com> References: <7c1602610803111442u75143010q8d840af21b98a96a@mail.gmail.com> Message-ID: <4ac8254d0803120232h71b1964bh6a9c0ed9b2514700@mail.gmail.com> On Tue, Mar 11, 2008 at 10:42 PM, Vlad Balin wrote: > Hello. > > I've got following problem - need to design fault-tolerant SIP IP-PBX > without single point of failure. We need to tolerate HW failure of > single server. Which approach would you suggest? IP address migration, > or there are other ways if we dealing with SIP? Just in case you're in search for an Erlang based SIP server already available you might want to have a look at YXA: http://www.stacken.kth.se/project/yxa/ I'm sure you heard of it though. From lemenkov Wed Mar 12 11:01:59 2008 From: lemenkov (Peter Lemenkov) Date: Wed, 12 Mar 2008 13:01:59 +0300 Subject: [erlang-questions] SIP server In-Reply-To: <4ac8254d0803120232h71b1964bh6a9c0ed9b2514700@mail.gmail.com> References: <7c1602610803111442u75143010q8d840af21b98a96a@mail.gmail.com> <4ac8254d0803120232h71b1964bh6a9c0ed9b2514700@mail.gmail.com> Message-ID: Hello All! 2008/3/12, Tuncer Ayaz : > Just in case you're in search for an Erlang > based SIP server already available you might > want to have a look at YXA: > http://www.stacken.kth.se/project/yxa/ BTW does anybody knows any weak points of this SIP-stack? Who already tried to use it? > I'm sure you heard of it though. No doubts. -- With best regards! From justin Wed Mar 12 11:20:21 2008 From: justin (Justin T. Sampson) Date: Wed, 12 Mar 2008 03:20:21 -0700 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <3dbc6d1c0803111758w6aa6eb6ob781cbc675bdc580@mail.gmail.com> Message-ID: Funny... Having only written smallish programs in both Haskell and Erlang, and having read through some library and example code from each, I've gotta say most of the Erlang code I've seen has been easier to understand than the most of the Haskell code I've seen, so my own impression is that Erlang syntax is nicer than Haskell syntax. It's partly cultural, of course -- I see a lot more single-letter variable names in Haskell, which maybe is an academic thing -- but syntax features like the ability to jam random punctuation together and call it an operator doesn't help. As for semantics, the computer scientist in me really really likes the purity and laziness in Haskell, and Erlang's non-pure semantics turned me off for a while; but when I realized that Erlang does at least keep all values immutable, the beautiful concurrency model tipped the scales for me to start checking it out... The one last semantic thing that bugged me in Erlang turned out to be a misconception: Seeing references to functions like io:format made me think they were direct I/O calls, which was disappointing because I hoped that all side-effects would be done through message passing (to satisfy my craving for some kind of "purity"). But recently I took a look at the source code for the io module, and lo-and-behold, it's message passing! Yay. :) Okay, anyway, there's another newbie datapoint for y'all. ;) (Almost all my professional work has been in Java, and now a project in PHP, which is sad, because my concentrations in college were programming languages, compiler design, and the theory of computation... I like Java better than any of the other "mainstream" languages because at least it has a defined concurrency semantics, even if it's too low-level; so I've been able to amuse myself with building higher-level concurrency abstractions, including working on Prevayler... And prodding people over and over on project after project to please please properly synchronize all access to shared state, because you really don't know what's going to happen when that race condition pops up when you're not looking so it's really not worth the perceived performance benefit you think you're going to get because "sychronization is slow" etc., etc., ...) Cheers, Justin On Tue, Mar 11, 2008 at 10:07 PM, Paul Mineiro wrote: > Re: syntax vs. semantics, from someone who recently learned the language. > > I got the semantics. It's why I pushed through the warts in the syntax; > and coming from Haskell, there were alot of things that were not as nice. > Most of them have already been mentioned, no need to rehash. > > Now I'm used to it, and in 3 months our little startup has a cloud > computing infrastructure that I only dreamed about at my large company > job, and we never go down thanks to hot code deployment. So Erlang does > not suck. However I hope it does not rest on its laurels either. Good > syntax makes life more pleasant. > > -- p From tty.erlang Wed Mar 12 12:34:43 2008 From: tty.erlang (t ty) Date: Wed, 12 Mar 2008 07:34:43 -0400 Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803111758w6aa6eb6ob781cbc675bdc580@mail.gmail.com> References: <3dbc6d1c0803101526j37e09053v14a633b514c73c2d@mail.gmail.com> <3dbc6d1c0803111758w6aa6eb6ob781cbc675bdc580@mail.gmail.com> Message-ID: <290b3ba10803120434k1507c760u442971cae522e86b@mail.gmail.com> If I really wanted a whole new Java like syntax with Erlang like semantics I would be coding/promoting/improving Scala. All I am looking for is consistency within Erlang's constructs. The rest I can deal with. Regards, t 2008/3/11 Robert Virding : > Very few of the misfeatures of Erlang syntax are new, though this doesn't > make them less important. Some are be fixable. > > I was probably a little unclear but I was interested in the question of a > whole new syntax, which at least Ulf understood. And the follow-up question > of whether this would satisfy people? > > For example assume we did a new flavour of Erlang based on Java which had > the look of Java but still had Erlang semantics (it couldn't be otherwise). > Would this make new users who came from more traditional languages happy? Or > would it just make it worse in that it might look the same as what they are > used to (sort of) but there would still be no "real" assignments or > destructive operations or loops etc ? > > I suppose the question really gets back to where the *real* problem is. Is > it really the syntax, or is it actually the semantics but people see it a > syntax problem because that is what they see first, the syntax? If a new > syntax really solved new users problems then it might be worth doing, > otherwise not. What do people think? > > One benefit on basing a new syntax on a typed language would be that adding > (optional) type declarations would still look "right". Typing records just > looks weird to me. :-) > > Robert > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From thomasl_erlang Wed Mar 12 12:57:10 2008 From: thomasl_erlang (Thomas Lindgren) Date: Wed, 12 Mar 2008 04:57:10 -0700 (PDT) Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <6AB9FC93-A3E3-4441-BBE7-D5B2B46207CD@cs.otago.ac.nz> Message-ID: <358862.58445.qm@web38801.mail.mud.yahoo.com> --- "Richard A. O'Keefe" wrote: > On 12 Mar 2008, at 12:05 am, Christian S wrote: > > Would it be possible to create a pattern matching > syntax for some kind > > of association map? > > Yes it would. Joe Armstrong and I have both > produced such designs. > I don't know how he intends his to be implemented, > but mine manages > to be sufficiently memory-efficient in the usual > case to completely > replace existing uses of records, while still being > flexible. It is > *definitely* EEP time. I think this is a fairly good time for hashes/dicts/structs/association maps/... (Though if it's this or unicode, I'd choose unicode.) Anyway, I'd want these terms to have Richard's semantics and Joe's syntax. (half :-) Best, Thomas ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From thomasl_erlang Wed Mar 12 13:04:47 2008 From: thomasl_erlang (Thomas Lindgren) Date: Wed, 12 Mar 2008 05:04:47 -0700 (PDT) Subject: [erlang-questions] Erlang Syntax - again In-Reply-To: <3dbc6d1c0803111727n3a987fd1y17a342c564b063ad@mail.gmail.com> Message-ID: <373448.62976.qm@web38801.mail.mud.yahoo.com> --- Robert Virding wrote: > Yes, this was one of the original requirements of > our first/major users. > They wanted named fields but as fast as using tuples > directly. The system > (computer+emulator) wasn't as fast in those days and > they felt they couldn't > offer performance. It was not misguided then. Anyway > this meant that > everything had to be done at compile-time, which > *is* very un-Erlangy. The problem is really that, coupled with the backward compatibility commitment, all those quick fixes then can never ever be revised. (Well ... hardly ever :-) Anyway. Not pretty, but perhaps not a huge issue -- platforms such as Java and Unix live with the same, or worse. Best, Thomas ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From parnell.flynn Wed Mar 12 13:27:28 2008 From: parnell.flynn (Parnell Flynn) Date: Wed, 12 Mar 2008 07:27:28 -0500 Subject: [erlang-questions] Unable to get distel documentation In-Reply-To: <47D6FC46.7050509@kreditor.se> Message-ID: I just tried again and this time it worked as well, well sorry for the spam. parnell Parnell Flynn * 230 South Lasalle Street * Suite 400 * Chicago, IL 60604 * 312.244.5317 (o) * parnell.flynn -----Original Message----- From: Mats Cronqvist [mailto:mats.cronqvist] Sent: Tuesday, March 11, 2008 4:40 PM To: Parnell Flynn Cc: erlang-questions Subject: Re: [erlang-questions] Unable to get distel documentation parnell wrote: > Yes I installed the user guide, but the paper Distel: Distributed > Emacs Lisp, and the reference manual looked interesting. > > On Mar 11, 9:32 am, "Roberto Saccon" wrote: > >> Have you checked all the available doc athttp://code.google.com/p/distel? >> >> On Tue, Mar 11, 2008 at 11:48 AM, parnell >> >> >> >> wrote: >> >>> I have been unable to download the distel documentation I keep getting >>> the following error: >>> >>> "While trying to retrieve the URL:http://fresh.homeunix.net/~luke/distel/distel-3.1.pdf i just tried it and it works... mats From ConveyCJ Wed Mar 12 14:00:37 2008 From: ConveyCJ (Convey Christian J NPRI) Date: Wed, 12 Mar 2008 09:00:37 -0400 Subject: [erlang-questions] The mystery of CPU utilization. Progress... Message-ID: <1C538D67B37E5B4784128A22270DF5C31031EF10@npri54exc20.npt.nuwc.navy.mil> I guess this is more than an FYI than an actual question... Earlier this week I asked some questions about what "-smp S n" does. I was confused because even running a single Erlang process in non-smp mode caused both of my cores to light up. In case anyone is interested, I have some more details. Still baffling, but... On my dual-core box, when run a single-process Erlang function, one CPU core runs at about 100% user load, and the other CPU core runs at about 100% *system* load. On a quad-core box I have access to, I ran the same function concurrently, using between one and four Erlang processes. As you'd expect, for each Erlang processes I had going, I pegged one CPU core at ~ 100% user load. But unlike on my dual-core box, none of the quad-core's cores experienced any significant *system* load. (One both computers I used the 'mpstat' program, with one instance of it monitoring each CPU core.) Christian Convey Scientist, Naval Undersea Warfare Centers Newport, RI From ft Wed Mar 12 14:03:37 2008 From: ft (Fredrik Thulin) Date: Wed, 12 Mar 2008 14:03:37 +0100 Subject: [erlang-questions] Making the step from Erlang to Erlang/OTP In-Reply-To: References: Message-ID: <47D7D4A9.8000107@it.su.se> David Mitchell wrote: > Hello all, > > I'm finding it difficult to jump from "pure" (for want of another > term) Erlang code to OTP. > > I can see that OTP is what I want to be using, but I'm struggling to > get my head around taking an existing non-OTP application and > converting it to run under OTP. ... Speaking as someone who took that step a couple of years ago (hand firmly held by OTP knowledgeable person at the time), I would like to suggest that you 1) create an OTP supervisor that is started when you start your program ("program" to not risk overloading the word "application" that means something specific in Erlang/OTP) 2) convert the first of your existing persistent processes into a gen_server. OTP gen_servers are what handles your typical receive Foo -> act_on(Foo) after 100 -> timeout end and use the supervisor from 1) to start the gen_server. This is the way I took into OTP land, and I'd say I turned out alright ;) /Fredrik From thomasl_erlang Wed Mar 12 13:19:10 2008 From: thomasl_erlang (Thomas Lindgren) Date: Wed, 12 Mar 2008 05:19:10 -0700 (PDT) Subject: [erlang-questions] erlang sucks In-Reply-To: <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> Message-ID: <272139.40056.qm@web38802.mail.mud.yahoo.com> --- Robert Virding wrote: > On 11/03/2008, Mats Cronqvist > wrote: > > > > > > > > i remain convinced that 'if' is worthless and > does nothing but add to > > the bloat. > > > It would actually be possible to extend 'if' to > allow non-guard tests and > user defined boolean functions in the test. Like in > lisp. We even have a keyword waiting for this: cond. On consideration, I think I'd prefer instead generalizing guards into deep guards (ie, at the very least, user-defined calls available) everywhere. An arbitrary call exiting in a guard would have to convert to failure, just as guards work today. I'd also suggest turning off side-effects while inside a guard (even deep down in function calls), converting attempted side-effects into exits. (I guess the modest proposal above ought to be an EEP too.) Best, Thomas ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From vychodil.hynek Wed Mar 12 14:37:46 2008 From: vychodil.hynek (Hynek Vychodil) Date: Wed, 12 Mar 2008 14:37:46 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D7923B.8080400@kreditor.se> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <47D7923B.8080400@kreditor.se> Message-ID: <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> 2008/3/12 Mats Cronqvist : > Ulf Wiger (TN/EAB) wrote: > > Robert Virding skrev: > > > >> ... > >> But the resulting 'if' would definitely be more useful. > >> > > ... > > > > The 'if' statement is not high on my list of things that need > > improving. It's actually quite ok, except it could perhaps have > > been named differently, in order not to give people false > > expectations. > > > just to be clear; i don't think 'if ' should be improved. > and i realize it cannot be removed either :< > > what i proposed was that it'd be obsoleted. in practice that would > mean that there'd > be a prominent document named "Obsolete features" or somesuch. That > document would list > old cruft; such as > * 'if' > * the three different 'and' (*) > * split_binary() > * the old type guards (integer() vs. is_integer()) > * tuple funs > etc... > > mats > > (*) > (case x of x when true,false ->ok; _-> nok end. > nok > case x of x when true and false ->ok; _-> nok end. > nok > case x of x when true andalso false ->ok; _-> nok end. > nok > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > If you don't know reason, don't say there is not reason: 6> F1 = fun() -> ok =/= io:format("F1~n") end. #Fun 7> F2 = fun() -> ok =/= io:format("F2~n") end. #Fun 8> F1() and F2(). F1 F2 false 9> F1() andalso F2(). F1 false -- --Hynek (Pichi) Vychodil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/9eca5e51/attachment.html From mats.cronqvist Wed Mar 12 15:02:05 2008 From: mats.cronqvist (Mats Cronqvist) Date: Wed, 12 Mar 2008 15:02:05 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <47D7923B.8080400@kreditor.se> <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> Message-ID: <47D7E25D.30909@kreditor.se> Hynek Vychodil wrote: > > > 2008/3/12 Mats Cronqvist >: > > > * 'if' > * the three different 'and' (*) > * split_binary() > * the old type guards (integer() vs. is_integer()) > * tuple funs > etc... > > mats > > (*) > (case x of x when true,false ->ok; _-> nok end. > nok > case x of x when true and false ->ok; _-> nok end. > nok > case x of x when true andalso false ->ok; _-> nok end. > nok > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > > If you don't know reason, don't say there is not reason: i am aware that the different kinds of 'and' are subtly incompatible. that's the reason i think it's a problem... or are you saying there is a need for several 'and'? in that case i disagree. mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/97f91815/attachment-0001.vcf From hasan.veldstra Wed Mar 12 15:08:36 2008 From: hasan.veldstra (Hasan Veldstra) Date: Wed, 12 Mar 2008 14:08:36 +0000 Subject: [erlang-questions] EEP9 new version In-Reply-To: References: Message-ID: <6139E5F6-13C0-4E37-928D-A914D51C6F1E@gmail.com> > I am also hoping that someone is willing to step up and take the lead > for an EEP on unicode support as I believe this is to big to be in > this eep. Better many small EEPs than one huge. I can take a shot at this. What would the first step be, writing a rough draft and submitting it to eeps? --Hasan From dustin.whitney Wed Mar 12 15:13:37 2008 From: dustin.whitney (Dustin Whitney) Date: Wed, 12 Mar 2008 10:13:37 -0400 Subject: [erlang-questions] erlang ***** In-Reply-To: <94C5430AA547F24AA801BA5706F29D2E25CD02@srvkeyx01.KEYTRONIX.local> References: <94C5430AA547F24AA801BA5706F29D2E25CD02@srvkeyx01.KEYTRONIX.local> Message-ID: <23def8000803120713m4347a7e3v9a50db6e7886bcc7@mail.gmail.com> 2008/3/12 Grasl Christoph : > Hi all! > > Since this topic seems to be dominant in the last days > i would recommend a topic-name change. It's a real pitty to > read this in conjunction with a powerful & pragmatic language > (obviously with certain advantages and disadvantages). > > A lot of people are very enthusiastic about erlang, > and that for a lot of good reasons.. > > Cheers > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > I agree - topic name change. I'd add that, in his blog, Damien Katz also said Erlang was his favorite language, which is far from the subject "erlang sucks" -Dustin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/4834cc45/attachment.html From gbulmer Wed Mar 12 15:40:45 2008 From: gbulmer (G Bulmer) Date: Wed, 12 Mar 2008 07:40:45 -0700 Subject: [erlang-questions] erlounge: San Francisco/CA Thursday 13th March, Cambridge/MA Wednesday 18th/Thursday 19th? In-Reply-To: References: <2B0A0FD6-6CDE-4B99-894C-A90CC73DE6A4@gmail.com> Message-ID: <00428A28-BE28-4A25-8FBC-98A2B83B2F60@gmail.com> Justin Thursday lunch SFO, somewhere near Market and 3rd; I am over near Union Square, so I can come over in your direction. Will you choose a spot? Cafe, bar, restaurant, hotel lobby, ...? Anyone else available for an Erlunch on Thursday? Garry On 10 Mar 2008, at 15:24, Justin T. Sampson wrote: > On Mon, Mar 10, 2008 at 7:51 AM, G Bulmer wrote: > >> I am in San Francisco on Thursday 13th March. I can meet up late >> morning onwards. > > I'm in San Francisco, and I can never make it to evening Erlounges, so > how about lunch on Thursday? Downtown is best for me (I work near > Market & 3rd St.). > > Cheers, > Justin From r.kelsall Wed Mar 12 16:08:53 2008 From: r.kelsall (Richard Kelsall) Date: Wed, 12 Mar 2008 15:08:53 +0000 Subject: [erlang-questions] Line numbers for logging/errors. In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> Message-ID: <47D7F205.90207@millstream.com> Nohl Attila Rajmund wrote: > Yes, erlang has excellent trace facilities, it shows me that the 'rfmm' > function was called - unfortunately it doesn't show that which of the 10 > rfmm functions was called. Breaking a small subject off the main thread. I haven't written much Erlang yet so maybe I'm just missing something, but I get the impression Erlang won't tell me the line number when something goes wrong. I feel it would be useful to know this and very in keeping with the Erlang approach of making bugs nice and visible. So my vote while we're all requesting changes to Erlang :) is for more line number visibility. On a related subject I've played around with the LINE macro to tag my own logging/error messages with line numbers and the best I could produce was something like this : -define(log(Line, Message, Var), log_message(?MODULE, Line, Message, ??Var, Var)). % LINE macro always gives '1' if I put it here. log_message(Module, Line, Message, VarName, Var) -> io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message, VarName, Var]). and then in my code I can do things like ?log(?LINE, "Unexpected post", Other), This works fine, but it would be nice to just write ?log("Unexpected post", Other), and get the line number somehow. Can this be done? Richard. From vychodil.hynek Wed Mar 12 16:28:23 2008 From: vychodil.hynek (Hynek Vychodil) Date: Wed, 12 Mar 2008 16:28:23 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D7E25D.30909@kreditor.se> References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <47D7923B.8080400@kreditor.se> <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> <47D7E25D.30909@kreditor.se> Message-ID: <4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com> On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist wrote: > Hynek Vychodil wrote: > > > > > > 2008/3/12 Mats Cronqvist > >: > > > > > > * 'if' > > * the three different 'and' (*) > > * split_binary() > > * the old type guards (integer() vs. is_integer()) > > * tuple funs > > etc... > > > > mats > > > > (*) > > (case x of x when true,false ->ok; _-> nok end. > > nok > > case x of x when true and false ->ok; _-> nok end. > > nok > > case x of x when true andalso false ->ok; _-> nok end. > > nok > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > > > If you don't know reason, don't say there is not reason: > i am aware that the different kinds of 'and' are subtly incompatible. > that's the reason i think it's a problem... > > or are you saying there is a need for several 'and'? in that case i > disagree. > Well, than say it to Joe :-) 'and' is and in mathematical manner 'andalso' is lazy and in programmers manner I think there is no way to change it, because if you remove 'andalso' and use 'and' in programmers manner lazy behaviour, you will break some legacy code a vice versa. This change is impossible. You can be not agree with it. You can argue against it, but it is all what you can do with it. > mats > > -- --Hynek (Pichi) Vychodil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/84833136/attachment.html From ft Wed Mar 12 15:30:36 2008 From: ft (Fredrik Thulin) Date: Wed, 12 Mar 2008 15:30:36 +0100 Subject: [erlang-questions] OT: Re: SIP server In-Reply-To: <47D707CC.1020308@astjab.org> References: <7c1602610803111442u75143010q8d840af21b98a96a@mail.gmail.com> <47D700CC.1020701@astjab.org> <7c1602610803111518u1bdca659k99428feed5653ac4@mail.gmail.com> <47D707CC.1020308@astjab.org> Message-ID: <47D7E90C.1070307@it.su.se> mog wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Vlad Balin wrote: >> CARP looks interesting. Is it supported on Windows? Can't find any >> guides how to write CARP-enable applications. >> > you don't really write carp enabled apps, it just clones the interface > and watches for failure. You also don't need this for sip as its udp > based so you can have an interface fail and still recover, This is off topic, but SIP is NOT UDP based (although UDP is one available transport for SIP - one that sucks by the way). Also, to address the original question (how you could do away with relying on a single server) - SIP generally uses DNS (specifically NAPTR and SRV records) for this. /Fredrik From mats.cronqvist Wed Mar 12 16:53:57 2008 From: mats.cronqvist (Mats Cronqvist) Date: Wed, 12 Mar 2008 16:53:57 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com> References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <47D7923B.8080400@kreditor.se> <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> <47D7E25D.30909@kreditor.se> <4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com> Message-ID: <47D7FC95.8040906@kreditor.se> Hynek Vychodil wrote: > > > On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist > > wrote: > > or are you saying there is a need for several 'and'? in that case i > disagree. > > ... > I think there is no way to change it, because if you remove 'andalso' > and use 'and' in programmers manner lazy behaviour, you will break > some legacy code a vice versa. This change is impossible. You can be > not agree with it. You can argue against it, but it is all what you > can do with it. if you go back a few posts, you'll see that i try to make it very clear that nothing will be removed (at least not for the next few years). mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/482ee47e/attachment.vcf From eider.oliveira Wed Mar 12 17:47:37 2008 From: eider.oliveira (Eider Silva de Oliveira) Date: Wed, 12 Mar 2008 13:47:37 -0300 Subject: [erlang-questions] Line numbers for logging/errors. In-Reply-To: <47D7F205.90207@millstream.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> <47D7F205.90207@millstream.com> Message-ID: I use this: -define(d(Format, Args), io:format("~s" ++ Format, [string:left(lists:flatten(io_lib:format("~p~p(~p):", [self(),? MODULE, ?LINE])), 35, $ ) | Args])). On 12/03/2008, at 12:08, Richard Kelsall wrote: > Nohl Attila Rajmund wrote: >> Yes, erlang has excellent trace facilities, it shows me that the >> 'rfmm' >> function was called - unfortunately it doesn't show that which of >> the 10 >> rfmm functions was called. > > Breaking a small subject off the main thread. I haven't written much > Erlang yet so maybe I'm just missing something, but I get the > impression > Erlang won't tell me the line number when something goes wrong. I feel > it would be useful to know this and very in keeping with the Erlang > approach of making bugs nice and visible. So my vote while we're all > requesting changes to Erlang :) is for more line number visibility. > > On a related subject I've played around with the LINE macro to tag > my own logging/error messages with line numbers and the best I could > produce was something like this : > > -define(log(Line, Message, Var), log_message(?MODULE, Line, Message, > ??Var, Var)). % LINE macro always gives '1' if I put it > here. > > log_message(Module, Line, Message, VarName, Var) -> > io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message, > VarName, Var]). > > and then in my code I can do things like > > ?log(?LINE, "Unexpected post", Other), > > This works fine, but it would be nice to just write > > ?log("Unexpected post", Other), > > and get the line number somehow. Can this be done? > > > Richard. > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From paul-trapexit Wed Mar 12 17:52:14 2008 From: paul-trapexit (Paul Mineiro) Date: Wed, 12 Mar 2008 09:52:14 -0700 (PDT) Subject: [erlang-questions] erlang ***** In-Reply-To: <23def8000803120713m4347a7e3v9a50db6e7886bcc7@mail.gmail.com> References: <94C5430AA547F24AA801BA5706F29D2E25CD02@srvkeyx01.KEYTRONIX.local> <23def8000803120713m4347a7e3v9a50db6e7886bcc7@mail.gmail.com> Message-ID: What about: "Erlang is the worst programming language, except all others." -- p On Wed, 12 Mar 2008, Dustin Whitney wrote: > 2008/3/12 Grasl Christoph : > > > Hi all! > > > > Since this topic seems to be dominant in the last days > > i would recommend a topic-name change. It's a real pitty to > > read this in conjunction with a powerful & pragmatic language > > (obviously with certain advantages and disadvantages). > > > > A lot of people are very enthusiastic about erlang, > > and that for a lot of good reasons.. > > > > Cheers > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > I agree - topic name change. I'd add that, in his blog, Damien Katz also > said Erlang was his favorite language, which is far from the subject "erlang > sucks" > > -Dustin > Optimism is an essential ingredient of innovation. How else can the individual favor change over security? -- Robert Noyce From attila.rajmund.nohl Wed Mar 12 18:22:01 2008 From: attila.rajmund.nohl (attila.rajmund.nohl) Date: Wed, 12 Mar 2008 18:22:01 +0100 (CET) Subject: [erlang-questions] erlang sucks In-Reply-To: <18391.34992.129455.726409@gargle.gargle.HOWL> References: <18391.34992.129455.726409@gargle.gargle.HOWL> Message-ID: On Wed, 12 Mar 2008, Anders G S Svensson wrote: [...] > You might not think that when the code is at a customer site and > applying patches isn't something the customer (or the layers of > management between you and the customer) will let you do. Thankfully I haven't been in this situation. But I stand by my claim - if it's possible, it's often faster to insert io:format calls into the call than to try to make sense of hundreds of lines of trace generated by two simple function calls. Actually it would be nice if we'd have a tool that could parse such trace and the source code and could show me that which function was called... Bye,NAR -- "Beware of bugs in the above code; I have only proved it correct, not tried it." From attila.rajmund.nohl Wed Mar 12 18:29:17 2008 From: attila.rajmund.nohl (attila.rajmund.nohl) Date: Wed, 12 Mar 2008 18:29:17 +0100 (CET) Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> Message-ID: On Tue, 11 Mar 2008, Sean Hinde wrote: [...] > The more normal Erlang way to write the equivalent of the C version would be > simply: > > some_function(X,Y,Z) -> > case handle_some_function(X,Y,Z) of > ok -> ok; > error1 -> handle_error1(); > error2 -> handle_error2() > end. > > I'd argue that it is even more readable than the C version. And not an 'if' > in sight :-) But you have to write nonsense like: ok -> ok; Bye,NAR -- "Beware of bugs in the above code; I have only proved it correct, not tried it." From r.kelsall Wed Mar 12 18:44:06 2008 From: r.kelsall (Richard Kelsall) Date: Wed, 12 Mar 2008 17:44:06 +0000 Subject: [erlang-questions] Line numbers for logging/errors. In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> <47D7F205.90207@millstream.com> Message-ID: <47D81666.2030009@millstream.com> Thank you. That looks good. I'll experiment with it. Eider Silva de Oliveira wrote: > I use this: > > -define(d(Format, Args), > io:format("~s" ++ Format, > [string:left(lists:flatten(io_lib:format("~p~p(~p):", [self(),?MODULE, > ?LINE])), 35, $ ) | Args])). > > > On 12/03/2008, at 12:08, Richard Kelsall wrote: > >> Nohl Attila Rajmund wrote: >>> Yes, erlang has excellent trace facilities, it shows me that the 'rfmm' >>> function was called - unfortunately it doesn't show that which of the 10 >>> rfmm functions was called. >> >> Breaking a small subject off the main thread. I haven't written much >> Erlang yet so maybe I'm just missing something, but I get the impression >> Erlang won't tell me the line number when something goes wrong. I feel >> it would be useful to know this and very in keeping with the Erlang >> approach of making bugs nice and visible. So my vote while we're all >> requesting changes to Erlang :) is for more line number visibility. >> >> On a related subject I've played around with the LINE macro to tag >> my own logging/error messages with line numbers and the best I could >> produce was something like this : >> >> -define(log(Line, Message, Var), log_message(?MODULE, Line, Message, >> ??Var, Var)). % LINE macro always gives '1' if I put it here. >> >> log_message(Module, Line, Message, VarName, Var) -> >> io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message, >> VarName, Var]). >> >> and then in my code I can do things like >> >> ?log(?LINE, "Unexpected post", Other), >> >> This works fine, but it would be nice to just write >> >> ?log("Unexpected post", Other), >> >> and get the line number somehow. Can this be done? >> From dmercer Wed Mar 12 18:44:29 2008 From: dmercer (David Mercer) Date: Wed, 12 Mar 2008 12:44:29 -0500 Subject: [erlang-questions] erlounge in Mobile, Ala.? In-Reply-To: <00428A28-BE28-4A25-8FBC-98A2B83B2F60@gmail.com> References: <2B0A0FD6-6CDE-4B99-894C-A90CC73DE6A4@gmail.com> <00428A28-BE28-4A25-8FBC-98A2B83B2F60@gmail.com> Message-ID: <006f01c88468$c770c1e0$891ea8c0@SSI.CORP> Anyone on this list in (or around) Mobile, Alabama? (Didn't think so...) DBM -----Original Message----- From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of G Bulmer Sent: Wednesday, March 12, 2008 09:41 To: Justin T. Sampson Cc: erlang-questions Subject: Re: [erlang-questions] erlounge: San Francisco/CA Thursday 13thMarch, Cambridge/MA Wednesday 18th/Thursday 19th? Justin Thursday lunch SFO, somewhere near Market and 3rd; I am over near Union Square, so I can come over in your direction. Will you choose a spot? Cafe, bar, restaurant, hotel lobby, ...? Anyone else available for an Erlunch on Thursday? Garry On 10 Mar 2008, at 15:24, Justin T. Sampson wrote: > On Mon, Mar 10, 2008 at 7:51 AM, G Bulmer wrote: > >> I am in San Francisco on Thursday 13th March. I can meet up late >> morning onwards. > > I'm in San Francisco, and I can never make it to evening Erlounges, so > how about lunch on Thursday? Downtown is best for me (I work near > Market & 3rd St.). > > Cheers, > Justin _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From dmercer Wed Mar 12 18:48:14 2008 From: dmercer (David Mercer) Date: Wed, 12 Mar 2008 12:48:14 -0500 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se><8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com><47D67F5F.1040807@kreditor.se><47D6DCFB.9050604@kreditor.se> Message-ID: <007001c88469$4242b680$891ea8c0@SSI.CORP> Perhaps I am misunderstanding the comma or == operator, but for what values of X will the following guard evaluate to true? when X == '123', X == '456' Please advise. Thank-you. DBM -----Original Message----- From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Sean Hinde Sent: Tuesday, March 11, 2008 15:06 To: Mats Cronqvist Cc: Erlang mailing list Subject: Re: [erlang-questions] erlang sucks On 11 Mar 2008, at 19:26, Mats Cronqvist wrote: > Sean Hinde wrote: >> >> On 11 Mar 2008, at 12:47, Mats Cronqvist wrote: >> >>> >>> * 'if' is completely worthless, and should ideally be obsoleted. >> >> No, no no! I like 'if' It allows some neat constructs that are >> horrible with case. > > i was afraid no one was going to bite... still, I'd like an example > or 2. I'm thinking of things like: case X of _ when X == abc; X == xyz -> do_abc_or_xyz(); _ when X == '123', X == '456' -> do_123456() '123' -> do_123_only(); fred -> do_fred() end vs if X == abc; X == xyz -> do_abc_or_xyz(); X == '123', X == '456' -> do_123456(); X == '123' -> do_123_only(); X == fred -> do_fred() end I don't much like the _ when business. 'if' is also useful when you want to branch on a bunch of unrelated boolean variables in various combinations: case {X,Y,Z} of {true, false, _} -> do_a(); {false, _, true} -> do_b(); _ -> do_c() end vs if X and not Y -> do_a; not X and Z -> do_b; true -> do_c end. I find the second more clearly states the intent. You also don't have to remember the positions in the tuple to parse the code (though you do need to know that 'not' is stickier* than 'and') Sean * IANACS _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From eider.oliveira Wed Mar 12 19:09:59 2008 From: eider.oliveira (Eider Silva de Oliveira) Date: Wed, 12 Mar 2008 15:09:59 -0300 Subject: [erlang-questions] Line numbers for logging/errors. In-Reply-To: <47D81666.2030009@millstream.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> <47D7F205.90207@millstream.com> <47D81666.2030009@millstream.com> Message-ID: <1B3EC6CD-17EE-4486-B2AE-210ABDFF3FB9@gmail.com> I've found it in the mnesia example code! You'd find a lot of hints in the original source code. On 12/03/2008, at 14:44, Richard Kelsall wrote: > Thank you. That looks good. I'll experiment with it. > > Eider Silva de Oliveira wrote: >> I use this: >> -define(d(Format, Args), >> io:format("~s" ++ Format, >> [string:left(lists:flatten(io_lib:format("~p~p(~p):", [self(),? >> MODULE, ?LINE])), 35, $ ) | Args])). >> On 12/03/2008, at 12:08, Richard Kelsall wrote: >>> Nohl Attila Rajmund wrote: >>>> Yes, erlang has excellent trace facilities, it shows me that the >>>> 'rfmm' >>>> function was called - unfortunately it doesn't show that which of >>>> the 10 >>>> rfmm functions was called. >>> >>> Breaking a small subject off the main thread. I haven't written much >>> Erlang yet so maybe I'm just missing something, but I get the >>> impression >>> Erlang won't tell me the line number when something goes wrong. I >>> feel >>> it would be useful to know this and very in keeping with the Erlang >>> approach of making bugs nice and visible. So my vote while we're all >>> requesting changes to Erlang :) is for more line number visibility. >>> >>> On a related subject I've played around with the LINE macro to tag >>> my own logging/error messages with line numbers and the best I could >>> produce was something like this : >>> >>> -define(log(Line, Message, Var), log_message(?MODULE, Line, >>> Message, >>> ??Var, Var)). % LINE macro always gives '1' if I put it >>> here. >>> >>> log_message(Module, Line, Message, VarName, Var) -> >>> io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message, >>> VarName, Var]). >>> >>> and then in my code I can do things like >>> >>> ?log(?LINE, "Unexpected post", Other), >>> >>> This works fine, but it would be nice to just write >>> >>> ?log("Unexpected post", Other), >>> >>> and get the line number somehow. Can this be done? >>> > From sean.hinde Wed Mar 12 19:30:26 2008 From: sean.hinde (Sean Hinde) Date: Wed, 12 Mar 2008 18:30:26 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> Message-ID: <12C977C5-97C6-4BA1-845E-C902CA0CEBB6@gmail.com> On 12 Mar 2008, at 17:29, attila.rajmund.nohl wrote: > On Tue, 11 Mar 2008, Sean Hinde wrote: > [...] >> The more normal Erlang way to write the equivalent of the C version >> would be >> simply: >> >> some_function(X,Y,Z) -> >> case handle_some_function(X,Y,Z) of >> ok -> ok; >> error1 -> handle_error1(); >> error2 -> handle_error2() >> end. >> >> I'd argue that it is even more readable than the C version. And not >> an 'if' >> in sight :-) > > But you have to write nonsense like: > ok -> ok; You seem to be mostly complaining about the fact that case .. end and if .. end do not have an implicit pass through when no clauses match. Well, Erlang is not C. Idiomatic Elang does not mean writing everything in single function with a few hundred lines of ifs and gotos. I've read many C programs in that style, and also seen Erlang code attempting to follow the same style. It makes for ugly and hard to debug Erlang code. I've no idea if it is good C coding style. In Erlang you have the choice to throw a runtime exception if no clause matches, or to provide an explicit wildcard case. The Erlang "crash early" philosophy means that in most cases wildcard is the wrong solution. Sean > > Bye,NAR > -- > "Beware of bugs in the above code; I have only proved it correct, not > tried it." > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From sean.hinde Wed Mar 12 19:31:22 2008 From: sean.hinde (Sean Hinde) Date: Wed, 12 Mar 2008 18:31:22 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <007001c88469$4242b680$891ea8c0@SSI.CORP> References: <47D52E27.6060901@kreditor.se><8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com><47D67F5F.1040807@kreditor.se><47D6DCFB.9050604@kreditor.se> <007001c88469$4242b680$891ea8c0@SSI.CORP> Message-ID: <43139AE6-136F-4183-8C85-D1D6961042A4@gmail.com> This line will indeed never match :-) Well spotted Sean On 12 Mar 2008, at 17:48, David Mercer wrote: > Perhaps I am misunderstanding the comma or == operator, but for what > values > of X will the following guard evaluate to true? > > when X == '123', X == '456' > > Please advise. Thank-you. > > DBM > > -----Original Message----- > From: erlang-questions-bounces > [mailto:erlang-questions-bounces] On Behalf Of Sean Hinde > Sent: Tuesday, March 11, 2008 15:06 > To: Mats Cronqvist > Cc: Erlang mailing list > Subject: Re: [erlang-questions] erlang sucks > > > On 11 Mar 2008, at 19:26, Mats Cronqvist wrote: > >> Sean Hinde wrote: >>> >>> On 11 Mar 2008, at 12:47, Mats Cronqvist wrote: >>> >>>> >>>> * 'if' is completely worthless, and should ideally be obsoleted. >>> >>> No, no no! I like 'if' It allows some neat constructs that are >>> horrible with case. >> >> i was afraid no one was going to bite... still, I'd like an example >> or 2. > > I'm thinking of things like: > > case X of > _ when X == abc; X == xyz -> > do_abc_or_xyz(); > _ when X == '123', X == '456' -> > do_123456() > '123' -> > do_123_only(); > fred -> > do_fred() > end > > vs > > if > X == abc; > X == xyz -> > do_abc_or_xyz(); > X == '123', > X == '456' -> > do_123456(); > X == '123' -> > do_123_only(); > X == fred -> > do_fred() > end > > I don't much like the _ when business. > > 'if' is also useful when you want to branch on a bunch of unrelated > boolean variables in various combinations: > > case {X,Y,Z} of > {true, false, _} -> > do_a(); > {false, _, true} -> > do_b(); > _ -> > do_c() > end > > vs > > if > X and not Y -> > do_a; > not X and Z -> > do_b; > true -> > do_c > end. > > I find the second more clearly states the intent. You also don't have > to remember the positions in the tuple to parse the code (though you > do need to know that 'not' is stickier* than 'and') > > Sean > > * IANACS > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From pfisher Wed Mar 12 19:50:54 2008 From: pfisher (Paul Fisher) Date: Wed, 12 Mar 2008 13:50:54 -0500 Subject: [erlang-questions] erlounge in Mobile, Ala.? In-Reply-To: <006f01c88468$c770c1e0$891ea8c0@SSI.CORP> References: <2B0A0FD6-6CDE-4B99-894C-A90CC73DE6A4@gmail.com> <00428A28-BE28-4A25-8FBC-98A2B83B2F60@gmail.com> <006f01c88468$c770c1e0$891ea8c0@SSI.CORP> Message-ID: <1205347854.6095.130.camel@pfisher-laptop> On Wed, 2008-03-12 at 12:44 -0500, David Mercer wrote: > Anyone on this list in (or around) Mobile, Alabama? > > (Didn't think so...) Heh... or in Houston, Texas. -- paul From justin Wed Mar 12 20:06:11 2008 From: justin (Justin T. Sampson) Date: Wed, 12 Mar 2008 12:06:11 -0700 Subject: [erlang-questions] erlounge: San Francisco/CA Thursday 13th March, Cambridge/MA Wednesday 18th/Thursday 19th? In-Reply-To: <00428A28-BE28-4A25-8FBC-98A2B83B2F60@gmail.com> References: <2B0A0FD6-6CDE-4B99-894C-A90CC73DE6A4@gmail.com> <00428A28-BE28-4A25-8FBC-98A2B83B2F60@gmail.com> Message-ID: How about right in the middle of Union Square itself? There's a sandwich place right there, though I don't know how good/expensive it is. I often get lunch somewhere and take it to eat outside at Union Square. -Justin On Wed, Mar 12, 2008 at 7:40 AM, G Bulmer wrote: > Justin > > Thursday lunch SFO, somewhere near Market and 3rd; I am over near > Union Square, so I can come over in your direction. > Will you choose a spot? Cafe, bar, restaurant, hotel lobby, ...? > > Anyone else available for an Erlunch on Thursday? > > Garry > > > > > On 10 Mar 2008, at 15:24, Justin T. Sampson wrote: > > > On Mon, Mar 10, 2008 at 7:51 AM, G Bulmer wrote: > > > >> I am in San Francisco on Thursday 13th March. I can meet up late > >> morning onwards. > > > > I'm in San Francisco, and I can never make it to evening Erlounges, so > > how about lunch on Thursday? Downtown is best for me (I work near > > Market & 3rd St.). > > > > Cheers, > > Justin > > From fredrik.svahn Wed Mar 12 20:35:42 2008 From: fredrik.svahn (Fredrik Svahn) Date: Wed, 12 Mar 2008 20:35:42 +0100 Subject: [erlang-questions] Unicode EEP (was: EEP9 new version) Message-ID: Great! The instructions for what an EEP should ideally contain are here: http://www.erlang.org/eeps/eep-0001.html. An EEP template can be found here: http://www.erlang.org/eeps/eep-0002.txt. As you say a rough draft is the next step. If I were you I would start by building upon the already existing string (and/or binary_string module from EEP-9, maybe it is easier to add it to binaries than to lists?) module and just briefly describe what needs to be added to the existing interface in terms of new functions or parameters, just to keep it short initially. Personally I would also like to see which other parts of the system might be affected, how about the io module for instance? Should the regexp module handle unicode as well? What about the shell? If there is anything that cannot be added without breaking backwards compatibility it needs to be very carefully handled. I am guessing that the unicode support would be added mostly as an optional Encoding parameter to a number of existing functions so it should be fairly safe? Maybe also provide an example or suggestion on how to implement it for a number of functions (I don't think you should spend too much time here, in my view the interface is much more important for now, just as long as you think that the functions can be implemented with reasonable characteristics). BR /Fredrik On Wed, Mar 12, 2008 at 3:08 PM, Hasan Veldstra wrote: > > > I am also hoping that someone is willing to step up and take the lead > > for an EEP on unicode support as I believe this is to big to be in > > this eep. Better many small EEPs than one huge. > > I can take a shot at this. What would the first step be, writing a > rough draft and submitting it to eeps? > > --Hasan > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From torben.lehoff Wed Mar 12 21:19:13 2008 From: torben.lehoff (Torben Hoffmann) Date: Wed, 12 Mar 2008 21:19:13 +0100 Subject: [erlang-questions] Functional Datastructures In-Reply-To: <1630bf30803120022h3f9203dcr72328e46dd352c1c@mail.gmail.com> References: <1630bf30803120022h3f9203dcr72328e46dd352c1c@mail.gmail.com> Message-ID: Its been a while since I had a look at this type of thing, but I would suggest that you had a look at Binary Decision Diagrams( http://en.wikipedia.org/wiki/Binary_decision_diagram) which I know from own experience in another millennium can be implemented in SML without too much hazzle. I would suspect that it is just as easy in Erlang... especially since you have some neat data structures available that can make the implementation easier to do. If that can handle undetermined values is for further study by you!! ;-) Cheers, Torben 2008/3/12 Francis Stephens : > I am trying to build an efficient data structure for representing boolean > expressions in Erlang. I am having trouble producing a good data structure > in a functional context, although there are very fast data structures for > imperative languages like C. The data structure is to be used for a > functional SAT solver. > > A boolean expression (always in conjunctive normal form) can be described > as a set of variables, such as {p,q,r...} where each variable in the set is > mapped to one of three values true|false|indetermined yielding something > like {{p->ind},{q->true},{r->ind},...}. > > The expression is described as a set of sets of literals, where a literal > is a variable with a possible negation (~). So we have something like > {{~p,q},{~q,r}} which describes a formula that would usually be written (~p > v q)&(~q v r). Each of the inner sets has the property that if one of its > literals evaluates to true then the whole set can be removed from the outer > set. > > To being with we can represent the expression as a list of lists where the > variable-name, negation and value are all stored in one tuple. > [[{name,negation,value}]] > > Now if we assign a value to a variable we then need to traverse every > sublist ensuring a consistent assignment is made for every occurrence of the > varia ble in the expression. However, as a reward for this effort we can > easily check each sublist to see whether one of its members evaluates to > true (meaning the sublist can be removed). > > Alternately we could represent the expression as a list of lists where > just the variable name and negation are recorded {name,negation} and have > the assignment values stored as a separate mapping. This makes assignments > fast and safer, but we still need to traverse every sublist to see that it > does not now contain a literal evaluating to true. Is there a better way, I > suspect that I am thinking about it in the wrong way. Thanks. > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/3d2a1395/attachment.html From mogorman Wed Mar 12 21:28:50 2008 From: mogorman (mog) Date: Wed, 12 Mar 2008 15:28:50 -0500 Subject: [erlang-questions] erlounge in Mobile, Ala.? In-Reply-To: <006f01c88468$c770c1e0$891ea8c0@SSI.CORP> References: <2B0A0FD6-6CDE-4B99-894C-A90CC73DE6A4@gmail.com> <00428A28-BE28-4A25-8FBC-98A2B83B2F60@gmail.com> <006f01c88468$c770c1e0$891ea8c0@SSI.CORP> Message-ID: <47D83D02.6070501@astjab.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Mercer wrote: > Anyone on this list in (or around) Mobile, Alabama? > I am from mobile, and currently live in Huntsville, and would be up for a meet up. Mog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2D0BpCttrJGOY6gRAuHnAJ9S6fnXNaixl41jm+wswtiUpEHsggCeJiyT b4QRV9pXzh1squ/7MmRSskw= =9m39 -----END PGP SIGNATURE----- From mogorman Wed Mar 12 21:31:56 2008 From: mogorman (mog) Date: Wed, 12 Mar 2008 15:31:56 -0500 Subject: [erlang-questions] OT: Re: SIP server In-Reply-To: <47D7E90C.1070307@it.su.se> References: <7c1602610803111442u75143010q8d840af21b98a96a@mail.gmail.com> <47D700CC.1020701@astjab.org> <7c1602610803111518u1bdca659k99428feed5653ac4@mail.gmail.com> <47D707CC.1020308@astjab.org> <47D7E90C.1070307@it.su.se> Message-ID: <47D83DBC.2080604@astjab.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fredrik Thulin wrote: > mog wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Vlad Balin wrote: >>> CARP looks interesting. Is it supported on Windows? Can't find any >>> guides how to write CARP-enable applications. >>> >> you don't really write carp enabled apps, it just clones the interface >> and watches for failure. You also don't need this for sip as its udp >> based so you can have an interface fail and still recover, > > This is off topic, but SIP is NOT UDP based (although UDP is one > available transport for SIP - one that sucks by the way). > You are correct, however the majority of sip traffic is UDP, and all the media, the bulk of the traffic, is rtp which is sent as udp unless you are crazy. Mog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2D28pCttrJGOY6gRAjuuAKCfDDq/7FuDMXQ6PToGg8AZLw6kEwCgoRB3 ynoStze7FLgenMSXOCjhGXo= =AVAK -----END PGP SIGNATURE----- From vychodil.hynek Wed Mar 12 21:35:16 2008 From: vychodil.hynek (Hynek Vychodil) Date: Wed, 12 Mar 2008 21:35:16 +0100 Subject: [erlang-questions] Line numbers for logging/errors. In-Reply-To: <47D7F205.90207@millstream.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> <47D7F205.90207@millstream.com> Message-ID: <4d08db370803121335u64588f30y7289830b2de5dd0d@mail.gmail.com> May be I missed some, but it works for me in R11B-5 -module(temp). -export([test/0]). -define(log(Message, Var), log_message(?MODULE, ?LINE, Message, ??Var, Var)). log_message(Module, Line, Message, VarName, Var) -> io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message, VarName, Var]). test() -> X = {a,b}, ?log("Unexpected post", X). % here is line 20 %end $ erl -smp Erlang (BEAM) emulator version 5.5.5 [source] [smp:1] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.5.5 (abort with ^G) 1> c(temp). {ok,temp} 2> temp:test(). log: {temp, 20} Unexpected post X = {a,b} ok 3> On Wed, Mar 12, 2008 at 4:08 PM, Richard Kelsall wrote: > Nohl Attila Rajmund wrote: > > Yes, erlang has excellent trace facilities, it shows me that the 'rfmm' > > function was called - unfortunately it doesn't show that which of the 10 > > rfmm functions was called. > > Breaking a small subject off the main thread. I haven't written much > Erlang yet so maybe I'm just missing something, but I get the impression > Erlang won't tell me the line number when something goes wrong. I feel > it would be useful to know this and very in keeping with the Erlang > approach of making bugs nice and visible. So my vote while we're all > requesting changes to Erlang :) is for more line number visibility. > > On a related subject I've played around with the LINE macro to tag > my own logging/error messages with line numbers and the best I could > produce was something like this : > > -define(log(Line, Message, Var), log_message(?MODULE, Line, Message, > ??Var, Var)). % LINE macro always gives '1' if I put it here. > > log_message(Module, Line, Message, VarName, Var) -> > io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message, > VarName, Var]). > > and then in my code I can do things like > > ?log(?LINE, "Unexpected post", Other), > > This works fine, but it would be nice to just write > > ?log("Unexpected post", Other), > > and get the line number somehow. Can this be done? > > > Richard. > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- --Hynek (Pichi) Vychodil -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080312/ad60c3b7/attachment.html From ok Thu Mar 13 00:11:47 2008 From: ok (Richard A. O'Keefe) Date: Thu, 13 Mar 2008 12:11:47 +1300 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D7894A.3030909@ericsson.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> Message-ID: <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> Concerning 'if', may I remind readers that the 'cond' proposal (not mine) has been around for quite a while, and except for using 'cond' rather than 'if' as the keyword, completely answers the claimed need for an if with user-defined functions callable in the guards. What happens if those user defined functions exchange messages with the rest of the world is not something I want to think about... From jay Thu Mar 13 04:21:08 2008 From: jay (Jay Nelson) Date: Wed, 12 Mar 2008 20:21:08 -0700 Subject: [erlang-questions] User-level heartbeat (was mnesia bug) Message-ID: <1C8245FE-8DF3-4DCA-9469-71C9557726E8@duomark.com> Serge wrote: > The only solution is to follow a variation of Uffe's advise (*) on > recovering mnesia from a partitioned network - run the NodeC node with > {dist_auto_connect, once} and upon detecting a nodedown event on NodeC > enabling user-level heartbeat, and upon receiving a response from NodeA > or NodeB restart NodeC. What exactly are you referring to when you say "user-level heartbeat"? Is this an application you rolled yourself for pinging with UDP packets, or is there some option for turning on and off the heartbeat process that comes with OTP? jay From jeffm Thu Mar 13 04:59:08 2008 From: jeffm (jm) Date: Thu, 13 Mar 2008 14:59:08 +1100 Subject: [erlang-questions] DHT in erlang In-Reply-To: <7629cacc0803111145r2dfd1002ybad89e60a813b046@mail.gmail.com> References: <7629cacc0803111145r2dfd1002ybad89e60a813b046@mail.gmail.com> Message-ID: <47D8A68C.2080502@ghostgun.com> Ashish Sharma wrote: > Hi > > Has anyone implemented some DHT (standard or custom) distributed hash > table in erlang or has seen such implementation. > I've thought about it in passing but had to start working on something else. I was looking at it from the bit torrent perspective though. The intent was more trying to optimise local network traffic than to actually run a tracker or bt client. Where you thinking of something specific algorithm (eg chord http://pdos.csail.mit.edu/chord/), purpose, etc? Jeff. From jay Thu Mar 13 06:27:51 2008 From: jay (Jay Nelson) Date: Wed, 12 Mar 2008 22:27:51 -0700 Subject: [erlang-questions] if vs. case (long) Message-ID: There were a few points in the if vs. case discussion and the binding of multiple variables in the case statements that I wanted to make, but couldn't find all the relevant bits so I started a new thread. I personally almost never use 'if'. I think it was an unfortunate name choice because it is so ingrained in any imperative programmer's toolset, but it has a different meaning in erlang. I would not miss it if it were removed, however, I do see Sean's points about other people's style. I think someone else showed that the alternatives in a function definition can be used in place of both 'if' and 'case' so neither is really necessary, but I think case does make code more concise if it is not abused with too much complexity. My default instinct in erlang is to use case because I know it can always be easily expanded to include more branches, and it guarantees that all legal cases are enumerated so nothing is hidden in the order of branches: Var = computeStuff(), case DebugOn of true -> log(Var); false -> ok end, continue(Var). While this may seem like extra typing, it is clear that there are only two legal cases. In general, I don't often find myself in this situation. It has something to do with thinking in imperative terms, versus thinking in functional terms. In general, I would probably end up with the following log function: %% Standard clauses for logging. log(What, true) -> log(What); log(_What, false) -> ok. %% or use _NotTrue instead of false if other values are ignored. And then would pass around a debug logging flag. Even though it looks inefficient, the compiler should do a good job of optimizing this, it allows tracing as others have said, and gives the option of adding special cases of What that apply to all code locations: %% Placed as first clause of function, catches special cases... log({special_case, Value} = What, true) -> report_special_case(Value), log(What); The added advantage is that the inline code has no branches because the case is eliminated, so it is easier to read in a functional manner. I tend to prefer to call out to a function which may have several alternatives, but always returns a common value (or no value) which hides the complexity of what needs to be done. Var = computeStuff(), log(Var, DebugOn), continue(Var). ------------------------------------------------ Case is my default when differentiating on a single value. I resort to if when there are different reasons for each branch, which depend on different bindings: if StopLight =:= red -> stop(); StopLight =:= yellow and CopPresent =:= true -> stop(); PedestrianInCrosswalk =:= true -> stop(); true -> go() end Without an if statement, I would turn this into a function: drive() -> go_or_stop(StopLight, CopPresent, PedestrianInCrosswalk). go_or_stop(red, _, _) -> stop(); go_or_stop(yellow, true, _) -> stop(); go_or_stop(_, _, true) -> stop(); go_or_stop(_, _, _) -> go(). The confusion on which argument represents which value can be documented in one of two ways: 1) Use labels => (yellow = _LightColor, true = _CopPresent, _ = _PedestrianInCrosswalk) 2) Pass the args as a record => #intersection_state{color = yellow, cop = true, ped = false} ------------------------------------------------ There was another discussion about adding variables to case statements. The starting clauses were: {ValA, ValB} = case Var of 2 -> {5, computeB(2)}; 4 -> {computeA(4), 5}; _Other -> {5,5} end, ... Over time, more cases and variables are added to get something like the following: {ValA, ValB, ValC, ValD, ValE} = case Var of ... 12 different branches ... end, ... I would argue that the code has long ago evolved past the original construct, and should have been refactored. How it is refactored depends on how related the variable bindings are. If the variables are being set independently of one another, or some of them are being set based on bindings other than the discriminator (in this case, Var), they should be split from the rest. One alternative is to use a separate function for those that are independent of Var: ValA = computeA(AltVar), ValB = computeB(AltVar, AnotherVar), {ValC, ValD} = case Var of ... end, ValE = computeE(Var, AltVar), ... The separate functions for computing can each have a different number of branches. If the 5 variable bindings are related to each other, use encapsulation techniques to show their relationship just as you would in an OO language: create a record type that holds the values. Then call a separate function that takes all the parameters needed to construct the bound record instance: Obj = make_new_object(AltVar, AnotherVar, Var), ... make_new_object(AltVar, AnotherVar, Var) -> {ValC, ValD} = compute_dependent_vars(Var), ValA = computeA(AltVar), ValB = computeB(AltVar, AnotherVar), ValE = computeE(Var, AltVar), #object{a=ValA, b=ValB, c=ValC, d=ValD, e=ValE}. Related to this someone mentioned that things get complicated when a throw is used inside one of the branches of the complex case statement. I tend to avoid throw and rely on crashes instead. It is best not to test for cases that have to be handled in a special way if there is an easier mechanism to get around them. If you really have to throw, I think you will find the helper function approach (either of the last two cases above) to more easily accommodate a traceable throw coming from one of the support functions. ---------------------------------------------------- I think Mats suggestion to put a Good vs. Bad coding style manual in the docs would help alleviate a lot of complaints that are not language issues, but poor usage approaches. jay From ulf Thu Mar 13 08:34:13 2008 From: ulf (Ulf Wiger) Date: Thu, 13 Mar 2008 08:34:13 +0100 Subject: [erlang-questions] User-level heartbeat (was mnesia bug) In-Reply-To: <1C8245FE-8DF3-4DCA-9469-71C9557726E8@duomark.com> References: <1C8245FE-8DF3-4DCA-9469-71C9557726E8@duomark.com> Message-ID: <8209f740803130034q3484b19bi60189d9ed0c75289@mail.gmail.com> If it's following my advice, it's basically an administrative channel apart from Distributed Erlang. We use an UDP port, and our cluster controllers periodically send a status message to each of the others. If you receive such a message from a node that's not in your nodes() list (and you have connect_once semantics), then you have a problem. With this semantics, the channel doesn't really need to be fully reliable; if a message is dropped, the indication will be delayed until the next interval. BR, Ulf W 2008/3/13, Jay Nelson : > Serge wrote: > > > The only solution is to follow a variation of Uffe's advise (*) on > > recovering mnesia from a partitioned network - run the NodeC node > with > > {dist_auto_connect, once} and upon detecting a nodedown event on > NodeC > > enabling user-level heartbeat, and upon receiving a response from > NodeA > > or NodeB restart NodeC. > > What exactly are you referring to when you say "user-level > heartbeat"? Is this an application you rolled yourself for pinging > with UDP packets, or is there some option for turning on and off the > heartbeat process that comes with OTP? > > jay > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From ulf Thu Mar 13 08:38:19 2008 From: ulf (Ulf Wiger) Date: Thu, 13 Mar 2008 08:38:19 +0100 Subject: [erlang-questions] if vs. case (long) In-Reply-To: References: Message-ID: <8209f740803130038r1c575cc5oef4ca1fcc408ea2c@mail.gmail.com> 2008/3/13, Jay Nelson : > My default instinct in erlang is to use case because I know it can > always be easily expanded to include more branches, and it guarantees > that all legal cases are enumerated so nothing is hidden in the order > of branches: > > Var = computeStuff(), > case DebugOn of > true -> log(Var); > false -> ok > end, A colleague of mine would most definitely write this as DebugOn andalso log(Var). I'll save him the trouble of pointing that out. (: We've had some discussions about whether this is good style. BR, Ulf W From bengt.kleberg Thu Mar 13 08:41:03 2008 From: bengt.kleberg (Bengt Kleberg) Date: Thu, 13 Mar 2008 08:41:03 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D7FC95.8040906@kreditor.se> References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <47D7923B.8080400@kreditor.se> <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> <47D7E25D.30909@kreditor.se> <4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com> <47D7FC95.8040906@kreditor.se> Message-ID: <1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, Out of interest: Does anybody know of _anything_ that has been removed, ever? bengt On Wed, 2008-03-12 at 16:53 +0100, Mats Cronqvist wrote: > Hynek Vychodil wrote: > > > > > > On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist > > > wrote: > > > > or are you saying there is a need for several 'and'? in that case i > > disagree. > > > > ... > > I think there is no way to change it, because if you remove 'andalso' > > and use 'and' in programmers manner lazy behaviour, you will break > > some legacy code a vice versa. This change is impossible. You can be > > not agree with it. You can argue against it, but it is all what you > > can do with it. > if you go back a few posts, you'll see that i try to make it very > clear that nothing will be removed (at least not for the next few years). > > mats > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From mats.cronqvist Thu Mar 13 08:59:09 2008 From: mats.cronqvist (Mats Cronqvist) Date: Thu, 13 Mar 2008 08:59:09 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <18391.34992.129455.726409@gargle.gargle.HOWL> Message-ID: <47D8DECD.509@kreditor.se> attila.rajmund.nohl wrote: > On Wed, 12 Mar 2008, Anders G S Svensson wrote: > [...] > >> You might not think that when the code is at a customer site and >> applying patches isn't something the customer (or the layers of >> management between you and the customer) will let you do. >> > > Thankfully I haven't been in this situation. But I stand by my claim - > if it's possible, it's often faster to insert io:format calls into the > call than to try to make sense of hundreds of lines of trace generated by > two simple function calls. Actually it would be nice if we'd have a tool > that could parse such trace and the source code and could show me that > which function was called... > i claim that in a real system, it is *always* faster to use the trace BIF than io:format, if you are equally skilled with both. for example, the "hundreds of lines of trace" you're talking about would presumably be the arguments to functions calls? from the erlang:trace/3 man page; "arity - Used in conjunction with the call trace flag. {M, F, Arity} will be specified instead of {M, F, Args} in call trace messages." the need for a better tool than dbg to interface with the trace BIF is a different issue. mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080313/392d256a/attachment.vcf From erik.reitsma Thu Mar 13 09:05:46 2008 From: erik.reitsma (Erik Reitsma) Date: Thu, 13 Mar 2008 09:05:46 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <47D52E27.6060901@kreditor.se><47D6DCFB.9050604@kreditor.se><47D70389.4030303@kreditor.se><3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com><47D7894A.3030909@ericsson.com> <47D7923B.8080400@kreditor.se><4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com><47D7E25D.30909@kreditor.se><4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com><47D7FC95.8040906@kreditor.se> <1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: <110BA8ACEE682C479D0B008B6BE4AEB105E49EE7@esealmw107.eemea.ericsson.se> If you count libraries: after rewriting a GUI from iv to tcl I gave up when tcl was removed. I guess gs has been around long enough to consider it, but then again there are still GUI alternatives floating around, and I am afraid they will become better than gs and gs will be replaced. *Erik. > Out of interest: > Does anybody know of _anything_ that has been removed, ever? > > > bengt > > On Wed, 2008-03-12 at 16:53 +0100, Mats Cronqvist wrote: > > Hynek Vychodil wrote: > > > > > > > > > On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist > > > > wrote: > > > > > > or are you saying there is a need for several > 'and'? in that case i > > > disagree. > > > > > > ... > > > I think there is no way to change it, because if you > remove 'andalso' > > > and use 'and' in programmers manner lazy behaviour, you > will break > > > some legacy code a vice versa. This change is impossible. > You can be > > > not agree with it. You can argue against it, but it is > all what you > > > can do with it. > > if you go back a few posts, you'll see that i try to make it very > > clear that nothing will be removed (at least not for the > next few years). > > > > mats > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From mats.cronqvist Thu Mar 13 09:12:20 2008 From: mats.cronqvist (Mats Cronqvist) Date: Thu, 13 Mar 2008 09:12:20 +0100 Subject: [erlang-questions] if vs. case (long) In-Reply-To: <8209f740803130038r1c575cc5oef4ca1fcc408ea2c@mail.gmail.com> References: <8209f740803130038r1c575cc5oef4ca1fcc408ea2c@mail.gmail.com> Message-ID: <47D8E1E4.5030708@kreditor.se> Ulf Wiger wrote: > 2008/3/13, Jay Nelson : > > >> My default instinct in erlang is to use case because I know it can >> always be easily expanded to include more branches, and it guarantees >> that all legal cases are enumerated so nothing is hidden in the order >> of branches: >> >> Var = computeStuff(), >> case DebugOn of >> true -> log(Var); >> false -> ok >> end, >> > > > A colleague of mine would most definitely write this as > > DebugOn andalso log(Var). > > I'll save him the trouble of pointing that out. (: > > We've had some discussions about whether this is good style. > > BR, > Ulf W > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > that's too verbose, and log/1 has to return a boolean. here's the Right Way(tm); [log(Var) || DebugOn]. mats p.s. sarcasm! this construct is only to be used in obfuscated erlang competitions! -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080313/6171c0d9/attachment-0001.vcf From mats.cronqvist Thu Mar 13 09:15:42 2008 From: mats.cronqvist (Mats Cronqvist) Date: Thu, 13 Mar 2008 09:15:42 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <47D7923B.8080400@kreditor.se> <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> <47D7E25D.30909@kreditor.se> <4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com> <47D7FC95.8040906@kreditor.se> <1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: <47D8E2AE.40509@kreditor.se> Bengt Kleberg wrote: > Greetings, > > Out of interest: > Does anybody know of _anything_ that has been removed, ever? > not me. and i think it will be impossible to ever remove anything unless a mechanism to obsolete things is put in place (or there is a fork of OTP.) mats -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080313/f12e0d15/attachment.vcf From fredrik.svahn Thu Mar 13 09:32:19 2008 From: fredrik.svahn (Fredrik Svahn) Date: Thu, 13 Mar 2008 09:32:19 +0100 Subject: [erlang-questions] Removed deprecated functions Message-ID: > Does anybody know of _anything_ that has been removed, ever? Yes, depending on what you include in anything :-). See http://erlang.org/doc/incompatible.html for some examples: # The ets:fixtable/2 function, which has been deprecated for several releases, has been removed. The OTP team are however very very careful and functions usually are marked as deprecated (with compiler warnings I believe) for several releases before they go. There are usually very good technical grounds for removing things. I cannot recall that it has ever been a problem for us. BR /Fredrik On Thu, Mar 13, 2008 at 8:41 AM, Bengt Kleberg wrote: > Greetings, > > Out of interest: > Does anybody know of _anything_ that has been removed, ever? > > > bengt > > > > On Wed, 2008-03-12 at 16:53 +0100, Mats Cronqvist wrote: > > Hynek Vychodil wrote: > > > > > > > > > On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist > > > > wrote: > > > > > > or are you saying there is a need for several 'and'? in that case i > > > disagree. > > > > > > ... > > > I think there is no way to change it, because if you remove 'andalso' > > > and use 'and' in programmers manner lazy behaviour, you will break > > > some legacy code a vice versa. This change is impossible. You can be > > > not agree with it. You can argue against it, but it is all what you > > > can do with it. > > if you go back a few posts, you'll see that i try to make it very > > clear that nothing will be removed (at least not for the next few years). > > > > mats > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > > > http://www.erlang.org/mailman/listinfo/erlang-questions > From bjorn Thu Mar 13 09:32:11 2008 From: bjorn (Bjorn Gustavsson) Date: 13 Mar 2008 09:32:11 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <47D7923B.8080400@kreditor.se> <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> <47D7E25D.30909@kreditor.se> <4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com> <47D7FC95.8040906@kreditor.se> <1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Message-ID: Bengt Kleberg writes: > Greetings, > > Out of interest: > Does anybody know of _anything_ that has been removed, ever? A number of deprecated BIFs and functions were removed in R12B. Minor features (such as zombie processes) have been removed in past. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From me Thu Mar 13 09:53:52 2008 From: me (KatolaZ) Date: Thu, 13 Mar 2008 09:53:52 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <47D67F5F.1040807@kreditor.se> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> Message-ID: <20080313085352.GK4483@katolaz.homeunix.net> On Tue, Mar 11, 2008 at 01:47:27PM +0100, Mats Cronqvist wrote: > katz starts out like this; "...it's time to whine about my favorite > language I use quite extensively." seems pretty clear that the problem > is not that he is a troll, but rather that the erlang community (or at > least certain members of it) is immature. CouchDB is a major erlang > application, and katz should not have to take any crap from people that > has never written a significant piece of erlang (I'm not talking about > you, ulf!) > > more so because most of his complaints are essentially valid. > * the syntax does suck. for beginners, because it looks weird (i.e. not > like ALGOL), thus being a major obstacle to adoption. for pros, because > the silly separators, and the needless verbosity (lambdas, using > 'receive' instead of '?', etc) > * 'if' is completely worthless, and should ideally be obsoleted. > * strings as lists of integers is often annoying. > * the X1=x1(X),X2=x2(X1),,, pattern is tedious and error prone. > * records are "limited and verbose" (for a reason, but still) > * some of the libs/docs are of poor quality. > I mostly agree with all those complaints about Erlang. Syntax is not usually a problem for programmers that know and use more than one language at a time, but it is still an obstacle for newcomers. My (little) experience about teaching Erlang at university gave me the impression that students are attracted by many of the *cool* features of the language (concurrency, message passing, reliability, gen_*) but are mostly disappointed by syntax and libraries. Maybe it is due to the fact that most of them know C/C++/Java/Python. Maybe Erlang syntax is not so intuitive and easy as one could expect from a modern and powerful languages. Maybe because the standard library is not so rich and not so consistent as expected from a mature language. I think that the blogpost written by kats summerizes the most relevant issues that should be solved in order to make Erlang a main-stream language. Given that this community and people at Ericsson really want this to happen......:-) HND Enzo -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] From sean.hinde Thu Mar 13 10:35:17 2008 From: sean.hinde (Sean Hinde) Date: Thu, 13 Mar 2008 09:35:17 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <20080313085352.GK4483@katolaz.homeunix.net> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> Message-ID: <437C0D6E-4B81-4BD3-B8CC-AA7C368B10BE@gmail.com> On 13 Mar 2008, at 08:53, KatolaZ wrote: > On Tue, Mar 11, 2008 at 01:47:27PM +0100, Mats Cronqvist wrote: > > > Maybe it is due to the fact that most of them know C/C++/Java/Python. > Maybe Erlang syntax is not so intuitive and easy as one could expect > from a modern and powerful languages. > Maybe because the standard library is not so rich and not so > consistent as expected from a mature language. As someone who learned Erlang before C or Java my observation was quite the opposite. I found the Erlang syntax to be extremely simple and elegant, and that it was very easy to express the meaning of the code. I find C/Java Syntax ugly and unnatural. Erlang syntax didn't spring from nowhere. I bet Prolog programmers find it quite comfortable :-) Sean From chsu79 Thu Mar 13 11:10:47 2008 From: chsu79 (Christian S) Date: Thu, 13 Mar 2008 11:10:47 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <437C0D6E-4B81-4BD3-B8CC-AA7C368B10BE@gmail.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <437C0D6E-4B81-4BD3-B8CC-AA7C368B10BE@gmail.com> Message-ID: > As someone who learned Erlang before C or Java my observation was > quite the opposite. I found the Erlang syntax to be extremely simple > and elegant, and that it was very easy to express the meaning of the > code. I find C/Java Syntax ugly and unnatural. Also, as having been a student and among students I know that students are way too stupid to have worthy opinions. From fig Thu Mar 13 11:15:54 2008 From: fig (Michael FIG) Date: Thu, 13 Mar 2008 04:15:54 -0600 (CST) Subject: [erlang-questions] DepMods in OTP appup "downgrade update" instructions Message-ID: <32323438.68251205403354062.JavaMail.root@zimbra> Hi all, I recently wanted to simplify my .appup files by introducing a central configuration OTP application (starconf) that understands how to set up configuration files for various versions of external programs. Each of these external programs has a corresponding Erlang application that provides a supervisor and gen_server interface. Now here is the problem I have: given that I had made many naive releases of one of these applications, proport, I accumulated an appup file that looked something like this: {"3.3.0", % -*-Erlang-*- [{"3.2.1", [{restart_application, proport}]}, {"3.2.2", [{restart_application, proport}]}, {"3.2.3", [{restart_application, proport}]}, ... ], [{"3.2.1", [{restart_application, proport}]}, {"3.2.2", [{restart_application, proport}]}, {"3.2.3", [{restart_application, proport}]}, ... ] }. What I wanted to do was to rewrite this appup file so that I could use my new, spiffy starconf-dependent code_change callbacks for the gen_server (named proport), so I tried: {"3.3.0", % -*-Erlang-*- [{"3.2.1", [{update, proport, {advanced, restart}, [starconf]}]}, {"3.2.2", [{update, proport, {advanced, restart}, [starconf]}]}, {"3.2.3", [{update, proport, {advanced, restart}, [starconf]}]}, ... ], [{"3.2.1", [{update, proport, {advanced, restart}, [starconf]}]}, {"3.2.2", [{update, proport, {advanced, restart}, [starconf]}]}, {"3.2.3", [{update, proport, {advanced, restart}, [starconf]}]}, ... ] }. But, to my chagrin, this equally naive appup file failed with "Undefined module: starconf" when I tried to run make_relup. Some binary search testing revealed that I could use it as a dependency in all of the upgrade instructions, but none of the downgrade instructions. This made me wonder: what is the state of the runtime when a "downgrade update" instruction is being executed? Why are modules that are included in the current release (but notably not in any prior release) not accessible to the downgrade process? If this is insurmountable, how would you suggest I refactor the downgrade code when the latest starconf is always going to know the best way to downgrade? The OTP appup documentation seems to imply that putting starconf in the downgrade's DepMods is the right thing to do, and it means that starconf will be suspended only after proport has been downgraded. If somebody could shed some light on this matter, I would be very grateful, and would also suggest adding it to the official appup docs. Thanks for any help you can offer, -- Michael FIG , PMP MarkeTel Multi-Line Dialing Systems, Ltd. Phone: (306) 359-6893 ext. 528 From sean.hinde Thu Mar 13 11:27:53 2008 From: sean.hinde (Sean Hinde) Date: Thu, 13 Mar 2008 10:27:53 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <437C0D6E-4B81-4BD3-B8CC-AA7C368B10BE@gmail.com> Message-ID: On 13 Mar 2008, at 10:10, Christian S wrote: >> As someone who learned Erlang before C or Java my observation was >> quite the opposite. I found the Erlang syntax to be extremely simple >> and elegant, and that it was very easy to express the meaning of the >> code. I find C/Java Syntax ugly and unnatural. > > Also, as having been a student and among students I know that students > are way too stupid to have worthy opinions. I mostly avoided EE class so couldn't comment. Maybe I should have blogged about how C syntax should change to be more like Erlang. Darn! Blogs weren't invented then ;-) Sean From bqt Thu Mar 13 12:23:28 2008 From: bqt (Johnny Billquist) Date: Thu, 13 Mar 2008 12:23:28 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <437C0D6E-4B81-4BD3-B8CC-AA7C368B10BE@gmail.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <437C0D6E-4B81-4BD3-B8CC-AA7C368B10BE@gmail.com> Message-ID: <47D90EB0.3040204@softjar.se> Sean Hinde wrote: > On 13 Mar 2008, at 08:53, KatolaZ wrote: > >> On Tue, Mar 11, 2008 at 01:47:27PM +0100, Mats Cronqvist wrote: >> >> >> Maybe it is due to the fact that most of them know C/C++/Java/Python. >> Maybe Erlang syntax is not so intuitive and easy as one could expect >> from a modern and powerful languages. >> Maybe because the standard library is not so rich and not so >> consistent as expected from a mature language. > > As someone who learned Erlang before C or Java my observation was > quite the opposite. I found the Erlang syntax to be extremely simple > and elegant, and that it was very easy to express the meaning of the > code. I find C/Java Syntax ugly and unnatural. > > Erlang syntax didn't spring from nowhere. I bet Prolog programmers > find it quite comfortable :-) Speaking as one who knew Prolog before learning Erlang, I found the syntax faimilar, but that wasn't a help. Once you started write code you soon realized that this just fooled you into believing Erlang did all those nice thing Prolog does, but it doesn't. (Not surprising really, since Erlang is functional, not logic based.) Also, there are some subtle differences in the syntax, and those are usually around the things people have been complaining about here, such as the different separators. In Prolog much of these things don't happen since the order of definitions and statements are pretty unimportant in Prolog (you should get the same results no matter how you define things, just the order of the results will differ. Prolog will give all solutions, and not just the first that matches.) (Prolog is much nicer... ;-) ) Johnny From john.hughes Thu Mar 13 12:30:44 2008 From: john.hughes (John Hughes) Date: Thu, 13 Mar 2008 12:30:44 +0100 Subject: [erlang-questions] erlang sucks References: Message-ID: <002a01c884fd$aee53b70$bcfcb253@JTablet2007> > On Tue, Mar 11, 2008 at 01:47:27PM +0100, Mats Cronqvist wrote: > > Maybe because the standard library is not so rich and not so > consistent as expected from a mature language. > Coming from Haskell I do find that the Erlang lists library has some surprising omissions. An easy concrete step would be just to borrow the missing functions on lists from Haskell. John From saleyn Thu Mar 13 12:42:02 2008 From: saleyn (Serge Aleynikov) Date: Thu, 13 Mar 2008 07:42:02 -0400 Subject: [erlang-questions] User-level heartbeat (was mnesia bug) In-Reply-To: <1C8245FE-8DF3-4DCA-9469-71C9557726E8@duomark.com> References: <1C8245FE-8DF3-4DCA-9469-71C9557726E8@duomark.com> Message-ID: <47D9130A.4090101@gmail.com> Jay Nelson wrote: > Serge wrote: > > > The only solution is to follow a variation of Uffe's advise (*) on > > recovering mnesia from a partitioned network - run the NodeC node > with > > {dist_auto_connect, once} and upon detecting a nodedown event on > NodeC > > enabling user-level heartbeat, and upon receiving a response from > NodeA > > or NodeB restart NodeC. > > What exactly are you referring to when you say "user-level > heartbeat"? Is this an application you rolled yourself for pinging > with UDP packets, or is there some option for turning on and off the > heartbeat process that comes with OTP? Unfortunately OTP doesn't have this feature as it looks like it was designed with reliable networks in mind. So some time ago I put together a link monitoring app that during losses of connectivity does UDP/TCP pinging of nodes it's supposed to be connected to and upon seeing echoes from the peer nodes it calls some user-defined callbacks to determine the recovery action (e.g. what to do with mnesia instance, restart the node, reconnect, etc.). Serge From alpar Thu Mar 13 12:41:10 2008 From: alpar (=?ISO-8859-1?Q?Alp=E1r_J=FCttner?=) Date: Thu, 13 Mar 2008 11:41:10 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <20080313085352.GK4483@katolaz.homeunix.net> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> Message-ID: <1205408470.4296.28.camel@piko.site> > Maybe it is due to the fact that most of them know C/C++/Java/Python. > Maybe Erlang syntax is not so intuitive and easy as one could expect > from a modern and powerful languages. > Maybe because the standard library is not so rich and not so > consistent as expected from a mature language. I cannot agree with it. I grew up in the C/C++ world and also had known Python before I met Erlang, still I find it very intuitive. I'm also _very_ impressed by the simplicity and the expressive power. (I'm not a student though...) I think, the major obstacle for newcomers is not the syntax, but the immutable data structures, the impossibility of variable rebinding, and the miss of loop constructs like 'for' and 'while'. For someone familiar (only) with procedural languages, it is hard to believe that a language can be efficient without these features. Regards, Alpar From alpar Thu Mar 13 12:41:10 2008 From: alpar (=?ISO-8859-1?Q?Alp=E1r_J=FCttner?=) Date: Thu, 13 Mar 2008 11:41:10 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <20080313085352.GK4483@katolaz.homeunix.net> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> Message-ID: <1205408470.4296.28.camel@piko.site> > Maybe it is due to the fact that most of them know C/C++/Java/Python. > Maybe Erlang syntax is not so intuitive and easy as one could expect > from a modern and powerful languages. > Maybe because the standard library is not so rich and not so > consistent as expected from a mature language. I cannot agree with it. I grew up in the C/C++ world and also had known Python before I met Erlang, still I find it very intuitive. I'm also _very_ impressed by the simplicity and the expressive power. (I'm not a student though...) I think, the major obstacle for newcomers is not the syntax, but the immutable data structures, the impossibility of variable rebinding, and the miss of loop constructs like 'for' and 'while'. For someone familiar (only) with procedural languages, it is hard to believe that a language can be efficient without these features. Regards, Alpar From saleyn Thu Mar 13 12:54:54 2008 From: saleyn (Serge Aleynikov) Date: Thu, 13 Mar 2008 07:54:54 -0400 Subject: [erlang-questions] User-level heartbeat (was mnesia bug) In-Reply-To: <8209f740803130034q3484b19bi60189d9ed0c75289@mail.gmail.com> References: <1C8245FE-8DF3-4DCA-9469-71C9557726E8@duomark.com> <8209f740803130034q3484b19bi60189d9ed0c75289@mail.gmail.com> Message-ID: <47D9160E.4040903@gmail.com> One additional requirement I stumbled across was that some nodes could be behind a firewall and UDP may not have been allowed in either direction. In this case the "administrative channel" should be configurable to attempt TCP pings (connect/send/receive/disconnect) with short connect timeout for those nodes that are behind the firewall. Additionally, TCP connections can be restricted only to one direction (inside firewall to outside), so the channel pinging needs to be uni-directional. I'll see if I find time to document the app. Then I could make it available to public. Ulf Wiger wrote: > If it's following my advice, it's basically an administrative channel > apart from Distributed Erlang. We use an UDP port, and our > cluster controllers periodically send a status message to each > of the others. If you receive such a message from a node that's > not in your nodes() list (and you have connect_once semantics), > then you have a problem. > > With this semantics, the channel doesn't really need to be fully > reliable; if a message is dropped, the indication will be delayed > until the next interval. > > BR, > Ulf W > > 2008/3/13, Jay Nelson : >> Serge wrote: >> >> > The only solution is to follow a variation of Uffe's advise (*) on >> > recovering mnesia from a partitioned network - run the NodeC node >> with >> > {dist_auto_connect, once} and upon detecting a nodedown event on >> NodeC >> > enabling user-level heartbeat, and upon receiving a response from >> NodeA >> > or NodeB restart NodeC. >> >> What exactly are you referring to when you say "user-level >> heartbeat"? Is this an application you rolled yourself for pinging >> with UDP packets, or is there some option for turning on and off the >> heartbeat process that comes with OTP? >> >> jay >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions >> http://www.erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From david_holz Thu Mar 13 13:30:41 2008 From: david_holz (David Holz) Date: Thu, 13 Mar 2008 12:30:41 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> Message-ID: From: ok > Concerning 'if', may I remind readers that the 'cond' proposal (not > mine) > has been around for quite a while, and except for using 'cond' rather > than 'if' as the keyword, completely answers the claimed need for an if > with user-defined functions callable in the guards. Claimed need? Predicate functions are absolutely necessary in handling dispatch decisions for any sort of system whose message vocabulary is upgraded over time, in my experience. Having to put the explicit matching specification any place where a message or data structure is handled (even for simple dispatch pass-through which doesn't do anything with the contents) instead of deferring to a predicate is a horrible violation of DRY, and requires error-prone code hunting if it ever changes shape. Also, the ability to handle an entire category of messages via predicate, as opposed to matching each individual shape in its own clause, is substantial. Of course, one work-around to the lack of functions in guards is to prepend all functions you'd use before the case/receive and bind their results in variables. That works, but again trashes your code organization, especially when your main receive or case dispatch gets to be fairly large; is again a violation of DRY putting all the gory message details into something that doesn't use them; and is horribly sub-optimal since everything is called all the time instead of only enough to get the result that's needed. > What happens if those user defined functions exchange messages with the > rest of the world is not something I want to think about... If you're so worried about being coddled by the language, then we really need a notion similar to C++ "constness". Track and propagate which functions are pure functional, and toss compile-time, module-load time, or runtime errors if you choose to do so. I'd much rather have user-defined guard functions and have it upon myself to use them properly, than to throw out the baby with the bathwater just because it could possibly be misused. Yeah, I'm a little irate about the guard issue, simply because it seems it's clung to purely because of stick-in-the-mud attitude. Yes, I know that guard BIFs compile into BEAM directly and have their own optimization strategy, but function calls are still BEAM code you can generate. I don't care if it's a bit slower. We use code generation from spec DSLs for all event types and now full protocol specifications, so the ability to defer "is this a Hello message?" decisions to external generated functions is a basic requirement. Right now, we have to try to hack it into ?IS_HELLO style macros which expand to only guard BIFs where it can fit and mess with .hrl files. If you say that that's a decent solution, I might have more irate words to dispense. ;) _________________________________________________________________ Shed those extra pounds with MSN and The Biggest Loser! http://biggestloser.msn.com/ From jay Thu Mar 13 14:13:45 2008 From: jay (Jay Nelson) Date: Thu, 13 Mar 2008 06:13:45 -0700 Subject: [erlang-questions] if vs. case (long) In-Reply-To: <47D8E1E4.5030708@kreditor.se> References: <8209f740803130038r1c575cc5oef4ca1fcc408ea2c@mail.gmail.com> <47D8E1E4.5030708@kreditor.se> Message-ID: <93D5D13E-3134-4F81-A76B-F3C1A5355C55@duomark.com> On Mar 13, 2008, at 1:12 AM, Mats Cronqvist wrote: > Ulf Wiger wrote: >> >> A colleague of mine would most definitely write this as >> >> DebugOn andalso log(Var). >> That's definitely shorter, although Mats points out the returning a boolean issue. Not a bad solution and most telling of its intent, including any side-effects caused by log/1. > > that's too verbose, and log/1 has to return a boolean. here's the > Right Way(tm); > > [log(Var) || DebugOn]. > > mats > > p.s. sarcasm! this construct is only to be used in obfuscated > erlang competitions! > > I tend to forget about the ways to abuse list comprehensions. I don't mind adopting a particular idiomatic odd construct usage if it has the following characteristics: 1) It is used to mean precisely one thing 2) You are consistent in your usage 3) Once figured out, it cannot be confused with normal usage of the construct 4) Optional: put it in a macro and give it a better name Since andalso is good enough and clear I would use it or put it in a macro, although to me it has a PERL feel to it rather than an erlang feel. I tend to expect erlang code to execute everything, rather than to skip over some statements. I don't expect this in guard or case situations where andalso is normally used. But there may be another good (ab)use of list comprehensions that I haven't tried yet ;-). And in the list comprehension case, the statement _is_ executed. You expect some elements of the source list to be skipped, possibly all of them. The comprehension also can be expanded to a series of things: [log(A) and log(B) || DebugOn] How's this for obfuscation? [[log(E) || E <- LogVars] || DebugOn] jay From ingela Thu Mar 13 14:15:14 2008 From: ingela (Ingela Anderton Andin) Date: Thu, 13 Mar 2008 14:15:14 +0100 Subject: [erlang-questions] Things that has been removed (new subject) In-Reply-To: References: Message-ID: <47D928E2.4070106@erix.ericsson.se> erlang-questions-request wrote >> Greetings, >> >> Out of interest: >> Does anybody know of _anything_ that has been removed, ever? >> > > A number of deprecated BIFs and functions were removed in R12B. > > Minor features (such as zombie processes) have been removed in past. > > /Bjorn > Some more examples of things that has been removed: From odbc-2.0 releasnotes: (this was a long time ago) - The old interface that became deprecated in odbc 1.0 has now been removed. From Inets-5.0 release notes: (R12) -Deprecated base64 decode/encode functions have been removed. Inets uses base64 in STDLIB instead. - The Inets application now has to be explicitly started and stopped i.e. it will not automatically be started as a temporary application as it did before. Although a practical feature when testing things in the shell it is not desirable that people take advantage of this and not start the Inets application in a correct way in their products. Added functions to the Inets API that call application:start/stop. From ssl-2.1 release notes: (this was a long time ago) - The confounded notions of verify mode and verify depth has been corrected. The option verifydepth has been removed, and the two separate options verify and depth has been added. The list can be made much longer but I have better thing to do ;) Regards Ingela From r.kelsall Thu Mar 13 14:58:09 2008 From: r.kelsall (Richard Kelsall) Date: Thu, 13 Mar 2008 13:58:09 +0000 Subject: [erlang-questions] Line numbers for logging/errors. In-Reply-To: <4d08db370803121335u64588f30y7289830b2de5dd0d@mail.gmail.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6EC4F.50801@ericsson.com> <47D7F205.90207@millstream.com> <4d08db370803121335u64588f30y7289830b2de5dd0d@mail.gmail.com> Message-ID: <47D932F1.6010007@millstream.com> Gah, indeed it does work, more egg on face :) I went through several versions to get to that point, I must have tried substituting ?LINE into a previous version and failed somehow. Thank you. Richard. Hynek Vychodil wrote: > May be I missed some, but it works for me in R11B-5 > > -module(temp). > -export([test/0]). > -define(log(Message, Var), log_message(?MODULE, ?LINE, Message, ??Var, > Var)). > > > > log_message(Module, Line, Message, VarName, Var) -> > io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message, > VarName, Var]). > > test() -> > X = {a,b}, > ?log("Unexpected post", X). % here is line 20 > > %end > > $ erl -smp > Erlang (BEAM) emulator version 5.5.5 [source] [smp:1] [async-threads:0] > [hipe] [kernel-poll:false] > > Eshell V5.5.5 (abort with ^G) > 1> c(temp). > {ok,temp} > 2> temp:test(). > log: {temp, 20} Unexpected post X = {a,b} > ok > 3> > > > On Wed, Mar 12, 2008 at 4:08 PM, Richard Kelsall > > wrote: > > Nohl Attila Rajmund wrote: > > Yes, erlang has excellent trace facilities, it shows me that the > 'rfmm' > > function was called - unfortunately it doesn't show that which of > the 10 > > rfmm functions was called. > > Breaking a small subject off the main thread. I haven't written much > Erlang yet so maybe I'm just missing something, but I get the impression > Erlang won't tell me the line number when something goes wrong. I feel > it would be useful to know this and very in keeping with the Erlang > approach of making bugs nice and visible. So my vote while we're all > requesting changes to Erlang :) is for more line number visibility. > > On a related subject I've played around with the LINE macro to tag > my own logging/error messages with line numbers and the best I could > produce was something like this : > > -define(log(Line, Message, Var), log_message(?MODULE, Line, Message, > ??Var, Var)). % LINE macro always gives '1' if I put it here. > > log_message(Module, Line, Message, VarName, Var) -> > io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message, > VarName, Var]). > > and then in my code I can do things like > > ?log(?LINE, "Unexpected post", Other), > > This works fine, but it would be nice to just write > > ?log("Unexpected post", Other), > > and get the line number somehow. Can this be done? > > > Richard. > > > -- > --Hynek (Pichi) Vychodil From me Thu Mar 13 15:01:27 2008 From: me (KatolaZ) Date: Thu, 13 Mar 2008 15:01:27 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205408470.4296.28.camel@piko.site> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> Message-ID: <20080313140127.GL4483@katolaz.homeunix.net> On Thu, Mar 13, 2008 at 11:41:10AM +0000, Alp?r J?ttner wrote: > > Maybe it is due to the fact that most of them know C/C++/Java/Python. > > Maybe Erlang syntax is not so intuitive and easy as one could expect > > from a modern and powerful languages. > > Maybe because the standard library is not so rich and not so > > consistent as expected from a mature language. > > I cannot agree with it. I grew up in the C/C++ world and also had known > Python before I met Erlang, still I find it very intuitive. I'm also > _very_ impressed by the simplicity and the expressive power. (I'm not a > student though...) If we should talk about expressiveness, I think that haskell mostly wins among functional languages. But haskell syntax (just to keep this example) is far more intuitive and clear (and orthogonal) than Erlang's. > > I think, the major obstacle for newcomers is not the syntax, but the > immutable data structures, the impossibility of variable rebinding, and > the miss of loop constructs like 'for' and 'while'. For someone familiar > (only) with procedural languages, it is hard to believe that a language > can be efficient without these features. > Those features are not erlang-centric: also Ocaml and haskell would require a little of an effort for a C programmer. BTW, the little experience I have in writing Erlang code says that if I had written it in haskell it would have benn far more readable and nice. In a couple of words, we don't have just to choose among Erlang OR imperative programming (C/Java/Python & Co.): we've a lot of choices in the field of funtional languages, and a couple of them have some nicer syntax and features compared to Erlang. HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] From alpar Thu Mar 13 17:13:56 2008 From: alpar (=?ISO-8859-1?Q?Alp=E1r_J=FCttner?=) Date: Thu, 13 Mar 2008 16:13:56 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <20080313140127.GL4483@katolaz.homeunix.net> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313140127.GL4483@katolaz.homeunix.net> Message-ID: <1205424836.4296.57.camel@piko.site> > If we should talk about expressiveness, I think that haskell mostly wins > among functional languages. But haskell syntax (just to keep this example) > is far more intuitive and clear (and orthogonal) than Erlang's. I didn't try to compare Erlang to any other functional language. You said that it is seems hard-to-learn for students and concluded that it must be because of its bad syntax. What I answered is that basically nothing is wrong with the syntax of Erlang (it is simple, intuitive and easy-to-learn). It might be better, but the real difficulty of its learning for a student that it is functional. > Those features are not erlang-centric: also Ocaml and haskell would > require a little of an effort for a C programmer. I didn't want to say the opposite. > In a couple of words, we don't have just to choose among Erlang OR > imperative programming (C/Java/Python & Co.): we've a lot of choices > in the field of funtional languages, and a couple of them have some > nicer syntax and features compared to Erlang. What is your experience, do your students tend to really prefer Haskell to Erlang? Best regards, Alpar From rpettit Thu Mar 13 17:11:29 2008 From: rpettit (Rick Pettit) Date: Thu, 13 Mar 2008 11:11:29 -0500 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205408470.4296.28.camel@piko.site> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> Message-ID: <20080313161129.GA23334@vailsys.com> On Thu, Mar 13, 2008 at 11:41:10AM +0000, Alp?r J?ttner wrote: > > Maybe it is due to the fact that most of them know C/C++/Java/Python. > > Maybe Erlang syntax is not so intuitive and easy as one could expect > > from a modern and powerful languages. > > Maybe because the standard library is not so rich and not so > > consistent as expected from a mature language. > > I cannot agree with it. I grew up in the C/C++ world and also had known > Python before I met Erlang, still I find it very intuitive. I'm also > _very_ impressed by the simplicity and the expressive power. (I'm not a > student though...) > > I think, the major obstacle for newcomers is not the syntax, but the > immutable data structures, the impossibility of variable rebinding, and These "features" make it much easier to write buggy code (and much harder to find such buggy code). The developers you speak of need to take off their blinders if they ever hope to see the light. > the miss of loop constructs like 'for' and 'while'. Erlang has plenty of loop constructs--how else could you write a server loop? And with the use of tail-recursion this need not be inefficient. There's also lists:foldl/3, lists:foreach/2, list comprehensions, etc. I much, much prefer the look of these constructs over the equivalent for or while loops--regardless, the same can be accomplished with both. > For someone familiar > (only) with procedural languages, it is hard to believe that a language > can be efficient without these features. For someone more familiar with functional languages, it is hard to believe applications can be written correctly (let alone efficiently) _with_ those features. -Rick From ulf.wiger Thu Mar 13 17:40:11 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Thu, 13 Mar 2008 17:40:11 +0100 Subject: [erlang-questions] Other functional languages In-Reply-To: <20080313140127.GL4483@katolaz.homeunix.net> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313140127.GL4483@katolaz.homeunix.net> Message-ID: <47D958EB.9060204@ericsson.com> KatolaZ skrev: > In a couple of words, we don't have just to choose among Erlang OR > imperative programming (C/Java/Python & Co.): we've a lot of choices > in the field of funtional languages, and a couple of them have some > nicer syntax and features compared to Erlang. I agree that Haskell's syntax is very nice, once you've gotten used to it. The main problem for a beginner, is that it has so little of the usual cruft, that it's difficult to tell what's going on. (: I think it's a bit unfortunate that there isn't more sharing between Haskell, ML/OCaml and Erlang. Every once in a while, there has been some talk about developing interop libraries for going back and forth between the different languages. Personally, I think it's a cop-out to say that all three support interfacing to C. It still leaves a lot of work for the programmer wanting to make use of some good library written in one of the other languages. There is the ErlOCaml Google group, which actually has some code in it: http://code.google.com/p/erlocaml/ Then there are the various pet projects offering alternative syntax on top of the Erlang VM. These are the various projects I know of: - lersp which interprets "an approximation of scheme" (http://jungerl.cvs.sourceforge.net/jungerl/jungerl/lib/lersp/), - Erlang/Gambit interface (interfacing Erlang from Scheme) http://theschemeway.blogspot.com/2007/07/schemeerlang-interoperability-sequel.html (especially aiming at accessing Mnesia from Scheme, it seems) - LFE - Lisp for Erlang, obviously - HaskErl - Haskell to Erlang Core Compiler http://blog.tornkvist.org/blog.yaws?id=1190846785574003 (There is also a Perl extension to Haskell, called Haskerl, predating the above by about 15 years...) - ETOS - Erlang to Scheme compiler http://www.iro.umontreal.ca/~larosem/papers/etos.ps.gz - Stoe - Scheme to Erlang compiler https://webmail.iro.umontreal.ca/pipermail/gambit-list/2007-June/001466.html - My own hack to allow different syntaxes in the Erlang shell: http://ulf.wiger.net/weblog/2007/11/21/extending-the-erlang-shell-part-2/ (it would be better if there existed a Core Erlang evaluator) Judging by past attempts, I'd say that interop solutions have a far better chance of gathering an audience than an X-to-Y compiler. But whatever stimulates sharing of ideas across communities is most likely a Good Thing. BR, Ulf W From alpar Thu Mar 13 17:57:43 2008 From: alpar (=?ISO-8859-1?Q?Alp=E1r_J=FCttner?=) Date: Thu, 13 Mar 2008 16:57:43 +0000 Subject: [erlang-questions] erlang sucks In-Reply-To: <20080313161129.GA23334@vailsys.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313161129.GA23334@vailsys.com> Message-ID: <1205427463.4296.72.camel@piko.site> For the heaven's sake, I have never said it is a disadvantage of Erlang that is functional !!!! I only said that it might cause some difficulties for a beginner (a student), because most of them are already familiar with a procedural language, and they want to write program in Erlang in the same way as they did in C/C++/Java/Python. Is my English so bad? Regars, Alpar On Thu, 2008-03-13 at 11:11 -0500, Rick Pettit wrote: > On Thu, Mar 13, 2008 at 11:41:10AM +0000, Alp?r J?ttner wrote: > > > Maybe it is due to the fact that most of them know C/C++/Java/Python. > > > Maybe Erlang syntax is not so intuitive and easy as one could expect > > > from a modern and powerful languages. > > > Maybe because the standard library is not so rich and not so > > > consistent as expected from a mature language. > > > > I cannot agree with it. I grew up in the C/C++ world and also had known > > Python before I met Erlang, still I find it very intuitive. I'm also > > _very_ impressed by the simplicity and the expressive power. (I'm not a > > student though...) > > > > I think, the major obstacle for newcomers is not the syntax, but the > > immutable data structures, the impossibility of variable rebinding, and > > These "features" make it much easier to write buggy code (and much harder to > find such buggy code). The developers you speak of need to take off their > blinders if they ever hope to see the light. > > > the miss of loop constructs like 'for' and 'while'. > > Erlang has plenty of loop constructs--how else could you write a server > loop? And with the use of tail-recursion this need not be inefficient. > > There's also lists:foldl/3, lists:foreach/2, list comprehensions, etc. I > much, much prefer the look of these constructs over the equivalent > for or while loops--regardless, the same can be accomplished with both. > > > For someone familiar > > (only) with procedural languages, it is hard to believe that a language > > can be efficient without these features. > > For someone more familiar with functional languages, it is hard to believe > applications can be written correctly (let alone efficiently) _with_ those > features. > > -Rick From kevin Thu Mar 13 17:59:27 2008 From: kevin (Kevin Scaldeferri) Date: Thu, 13 Mar 2008 09:59:27 -0700 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205424836.4296.57.camel@piko.site> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313140127.GL4483@katolaz.homeunix.net> <1205424836.4296.57.camel@piko.site> Message-ID: <679AE570-F640-477B-B80F-86F56571F48F@scaldeferri.com> On Mar 13, 2008, at 9:13 AM, Alp?r J?ttner wrote: > > >> In a couple of words, we don't have just to choose among Erlang OR >> imperative programming (C/Java/Python & Co.): we've a lot of choices >> in the field of funtional languages, and a couple of them have some >> nicer syntax and features compared to Erlang. > > What is your experience, do your students tend to really prefer > Haskell > to Erlang? Personally, I feel like for the type of tasks that most students / academics do, Haskell is nicer. For the sort of thing that most professional programmers do, Erlang is nicer. I can live with some modest extra verbosity in exchange for solving some really hard practical problems. -kevin From vances Thu Mar 13 18:41:15 2008 From: vances (Vance Shipley) Date: Thu, 13 Mar 2008 13:41:15 -0400 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205427463.4296.72.camel@piko.site> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313161129.GA23334@vailsys.com> <1205427463.4296.72.camel@piko.site> Message-ID: <20080313174115.GW75744@h216-235-12-172.host.egate.net> Learning Erlang often also means learning functional programming. I believe it helps a good deal to understand that while you are doing it. If I had known the basics of what "functional" meant I wouldn't have had such a hard time wrapping my head around single assignment and the like (oh so many years ago). -Vance From me Thu Mar 13 20:21:53 2008 From: me (KatolaZ) Date: Thu, 13 Mar 2008 20:21:53 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <679AE570-F640-477B-B80F-86F56571F48F@scaldeferri.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313140127.GL4483@katolaz.homeunix.net> <1205424836.4296.57.camel@piko.site> <679AE570-F640-477B-B80F-86F56571F48F@scaldeferri.com> Message-ID: <20080313192153.GN4483@katolaz.homeunix.net> On Thu, Mar 13, 2008 at 09:59:27AM -0700, Kevin Scaldeferri wrote: > > Personally, I feel like for the type of tasks that most students / > academics do, Haskell is nicer. For the sort of thing that most > professional programmers do, Erlang is nicer. I can live with some > modest extra verbosity in exchange for solving some really hard > practical problems. > To be honest, I don't think that the matter is "the type of tasks that most students / academics do" :-) I think that Erlang has some nice stuff that haskell still misses (like native support for reliability management, for instance); but anybody who knows a bit of haskell cannot deny that its syntax is much more clear and expressive, and this does not have anything to do with the fact that you are an experienced firm programmer or an undergraduate student: it is just a matter of fact :-) I usually hear Erlang programmers complaining about Lisp parentheses, but if you look into an Erlang module which does something meaningful, you would find tons of parentheses, and of 4 different types: "()", "[]", "{}", "<<>>". What I mean is that we need to use a little of criticism also when we talk about our favourite language, and in this sense I really appreciated that blogpost which started this kind of flame: if we read it from a "neutral" point of view, we'll find that most of what ketz have written is TRUE, expecially if we use another FPL like haskell for the comparison. Finally, I agree with Ulf when he says that Erlang, Haskell, lisp/scheme and ML/OCaml communities should work together much more than how they are actually doing: all of them could benefit from such kind of collaboration. Maybe Erlang would have been a better language today from many perspectives, if our community had got ideas and solutions from haskell/OCaml/scheme experiences. My2Cents Enzo -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] From raould Thu Mar 13 20:34:47 2008 From: raould (Raoul Duke) Date: Thu, 13 Mar 2008 12:34:47 -0700 Subject: [erlang-questions] erlang sucks In-Reply-To: <20080313192153.GN4483@katolaz.homeunix.net> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313140127.GL4483@katolaz.homeunix.net> <1205424836.4296.57.camel@piko.site> <679AE570-F640-477B-B80F-86F56571F48F@scaldeferri.com> <20080313192153.GN4483@katolaz.homeunix.net> Message-ID: <91a2ba3e0803131234y6c28e881n55dd8ade20ff0f8a@mail.gmail.com> > stuff that haskell still misses (like native support for reliability > management, for instance); but anybody who knows a bit of haskell http://www.macs.hw.ac.uk/~dsg/gdh/papers/FaultToleranceProposal_sfp00_draft.ps is a little bit in that direction, i guess. presumably not exactly industrially proven yet, vs. Erlang's hallowed history :) From rpettit Thu Mar 13 21:12:07 2008 From: rpettit (Rick Pettit) Date: Thu, 13 Mar 2008 15:12:07 -0500 Subject: [erlang-questions] erlang sucks In-Reply-To: <1205427463.4296.72.camel@piko.site> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313161129.GA23334@vailsys.com> <1205427463.4296.72.camel@piko.site> Message-ID: <20080313201207.GD31854@vailsys.com> On Thu, Mar 13, 2008 at 04:57:43PM +0000, Alp?r J?ttner wrote: > For the heaven's sake, I have never said it is a disadvantage of Erlang > that is functional !!!! I only said that it might cause some > difficulties for a beginner (a student), because most of them are > already familiar with a procedural language, and they want to write > program in Erlang in the same way as they did in C/C++/Java/Python. > > Is my English so bad? Not at all, and I apologize if I offended you. The bottom line, though, is erlang is not a procedural language. Therefore, people that can't switch to a functional/concurrent programming paradigm are naturally going to have a hard time, and maybe even dislike the language. Tossing something that looks like a for or while loop at them to help them learn the language doesn't make sense--it doesn't help them switch to the new paradigm. Where iteration used to be a "good fit", now recursion is employed, etc. Likewise, variables are single assignment. Dict and other modules can be used to try and cheat and get multiple assignment (or worse, global variables), but that's terrible style and so it also won't help them out in the long run (probably won't help in the short run, either). I used to be one of these poor souls, but I switched over to erlang so long ago and haven't look back since--I'm not sure I recall exactly how I got here :-) I do think there's hope for newcomers, though, considering I did get here and without a lot of resources now available to newcomers: 1) Joe's new book 2) better docs 3) sites like erlware, trap exit, etc which give great examples, include tutorials geared towards the beginner, etc 4) this mailing list (which was around way back when I was learning, but with so many more subscribers today than 5+ years ago it's that much quicker/easier to get answers--and there's years of archives to dig through as well) -Rick From tty.erlang Thu Mar 13 21:46:11 2008 From: tty.erlang (t ty) Date: Thu, 13 Mar 2008 16:46:11 -0400 Subject: [erlang-questions] erlang sucks In-Reply-To: <20080313201207.GD31854@vailsys.com> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313161129.GA23334@vailsys.com> <1205427463.4296.72.camel@piko.site> <20080313201207.GD31854@vailsys.com> Message-ID: <290b3ba10803131346u59af0883o877045c168cbff0e@mail.gmail.com> 5) the irc channel on irc.freenode.net t On Thu, Mar 13, 2008 at 4:12 PM, Rick Pettit wrote: [snip] > > 1) Joe's new book > > 2) better docs > > 3) sites like erlware, trap exit, etc which give great examples, include > tutorials geared towards the beginner, etc > > 4) this mailing list (which was around way back when I was learning, but > with so many more subscribers today than 5+ years ago it's that much > quicker/easier to get answers--and there's years of archives to dig > through as well) > > > > -Rick > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > From massimo.cesaro Thu Mar 13 21:54:07 2008 From: massimo.cesaro (Massimo Cesaro) Date: Thu, 13 Mar 2008 21:54:07 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <20080313192153.GN4483@katolaz.homeunix.net> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <20080313085352.GK4483@katolaz.homeunix.net> <1205408470.4296.28.camel@piko.site> <20080313140127.GL4483@katolaz.homeunix.net> <1205424836.4296.57.camel@piko.site> <679AE570-F640-477B-B80F-86F56571F48F@scaldeferri.com> <20080313192153.GN4483@katolaz.homeunix.net> Message-ID: <7ae16d50803131354u27492b53xcf3086b2e7fa3cba@mail.gmail.com> On Thu, Mar 13, 2008 at 8:21 PM, KatolaZ wrote: > On Thu, Mar 13, 2008 at 09:59:27AM -0700, Kevin Scaldeferri wrote: > > > > Personally, I feel like for the type of tasks that most students / > > academics do, Haskell is nicer. For the sort of thing that most > > professional programmers do, Erlang is nicer. I can live with some > > modest extra verbosity in exchange for solving some really hard > > practical problems. > > > > To be honest, I don't think that the matter is "the type of tasks that > most students / academics do" :-) I think that Erlang has some nice > stuff that haskell still misses (like native support for reliability My personal experience is closer to Kevin's point of view. For our company, Erlang is actually an engineering tool, and a really effective one. As far as I know, Erlang design was driven by Ericsson requirements, ie a telecom industry development tool with peculiar features. I believe that this goal was achieved brilliantly, both in terms of completeness and effectiveness. I remeber I was quite impressed with Ulf paper on the increase of productivity among programmers using Erlang for the AXD development, and was even more impressed to verify his claims as completely true. Sure, we had to completely change our reference paradigms, switching from object oriented C++ modeling to the functional Erlang approach; but once we began to think in Erlang, we saw that the solution of most of the problems we struggled in the last 15 years were distilled in Erlang and OTP (just like Steve Vinovski describe in the interview cited by Ulf). As an engineering tool, we appreciate Erlang because it allows us to solve very complex TLC problems with a fraction of the effort required by any other development tool we know; in this respect, for us Erlang is a domain specific language that happens to solve also a broader range of problems. As engineers in a specific problem domain, we are looking for getting the job done in the best way, paying attention to the code manufacturing and maintenance costs; it is a different approach from the computer scientist or from the student. > > What I mean is that we need to use a little of criticism also when we > talk about our favourite language, and in this sense I really > appreciated that blogpost which started this kind of flame: if we read > it from a "neutral" point of view, we'll find that most of what ketz > have written is TRUE, expecially if we use another FPL like haskell > for the comparison. > Reading Damien Katz blog I understand that he used a pragmatic approach to develop CouchDB. In this respect, Erlang and OTP proved invaluable tools to achieve his goals and he'll use them again for this application. It seems that his criticism are related to his idea of using Erlang outside the problem domain Erlang was designed for, but then we are talking about a different language. I'm happy that the open source model of Erlang is in the firm hands of Ericsson: this is the best guarantee that Erlang will always be an engineering tools to solve engineering problems. Massimo > > Finally, I agree with Ulf when he says that Erlang, Haskell, > lisp/scheme and ML/OCaml communities should work together much more > than how they are actually doing: all of them could benefit from such > kind of collaboration. Maybe Erlang would have been a better language > today from many perspectives, if our community had got ideas and > solutions from haskell/OCaml/scheme experiences. > > My2Cents > > Enzo > > -- > [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] > [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] > [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] > [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080313/9b1b7285/attachment.html From elliot.murphy Thu Mar 13 23:18:13 2008 From: elliot.murphy (Elliot Murphy) Date: Thu, 13 Mar 2008 18:18:13 -0400 Subject: [erlang-questions] Erlang history converted to Bazaar and published on launchpad Message-ID: <595970ad0803131518y428b585ajb07dcf1f52607e66@mail.gmail.com> Hi! I've been learning Erlang, and when I went to look at how Erlang was built on the inside, I felt disappointed at only having source tarballs and not a version control system to examine how things changed over time. So, I went back and tried to invent some history! I've imported most of the last 10 years of source releases into bazaar, and published the result here: https://code.launchpad.net/erlang You can see a screenshot of bazaar displaying some of the history here: http://elliotmurphy.com/2008/03/13/published-some-erlang-history/ I hope this might be mildly useful to other folks trying to learn this fascinating system. If anyone is interested in helping me maintain this history as additional releases are made going forward, let me know and I'll add you to the team with write access, or will merge your branches (anyone can publish a branch to launchpad and mark it as associated with the Erlang project). I've tried to make the page clear that it is not the official Erlang site, and link back to the real project home page. Enjoy! -- Elliot Murphy | https://launchpad.net/~statik/ From alex.arnon Thu Mar 13 23:26:58 2008 From: alex.arnon (Alex Arnon) Date: Fri, 14 Mar 2008 00:26:58 +0200 Subject: [erlang-questions] Controlling TCP transmission buffer length. Message-ID: <944da41d0803131526w69ef5209h4789a3776b34b118@mail.gmail.com> Hi All, We are writing a TCP server where the protocol with an asymmetric amount of traffic between client and server. More specifically: - The server will acknowledge the client's requests, however the client is not required to. - The server may occasionally (even often) stream much data towards the client. As stated before, this data does no need to be acknowledged. - Responsiveness to client requests is important. In short, I think the question could be summed up as: How would one go about a TCP connection where A. there is low latency (no timed sleeping), and B. one can generally ensure that transmit traffic/messages do not back up over a preset amount. The message interface to sockets is very attractive, but the lack of option to receive notification about blocking (or unblocking) makes it unusable for the above purposes. Maybe someone has used a hybrid approach...? Thanks in advance, Alex. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080314/8471205d/attachment.html From sten Thu Mar 13 23:29:55 2008 From: sten (Sten Kvamme) Date: Thu, 13 Mar 2008 23:29:55 +0100 Subject: [erlang-questions] ex11 Message-ID: <1205447395.7130.8.camel@bautasten> When I installed erlang and ex11 on the Openmoko mobile phone I had to change a line in ex11_lib_utils (line 179). Instead of taking the head of the screen_depth_list I had to take the reverse head. I don't know exactly what I am doing - is there a more general solution? Thanks, Sten From rvirding Thu Mar 13 23:43:31 2008 From: rvirding (Robert Virding) Date: Thu, 13 Mar 2008 23:43:31 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> Message-ID: <3dbc6d1c0803131543pc89e6fbm7511205040f5793@mail.gmail.com> On 13/03/2008, David Holz wrote: > > > Yeah, I'm a little irate about the guard issue, simply because it seems > it's clung to purely because of stick-in-the-mud attitude. Yes, I know that > guard BIFs compile into BEAM directly and have their own optimization > strategy, but function calls are still BEAM code you can generate. I don't > care if it's a bit slower. We use code generation from spec DSLs for all > event types and now full protocol specifications, so the ability to defer > "is this a Hello message?" decisions to external generated functions is a > basic requirement. Right now, we have to try to hack it into ?IS_HELLO > style macros which expand to only guard BIFs where it can fit and mess with > .hrl files. If you say that that's a decent solution, I might have more > irate words to dispense. ;) I don't definitely don't think that the main problem with user defined guards is efficiency or anything like that. It is not difficult to make a user function used in a guard as fast as the same function outside a guard. The main problem is semantic! What does it mean when you call a general function inside a guard. The example which Richard gives is a good one. Assume I am in a receive and in the guard of testing one message I call a function which also receives messages. What happens to the message queue? Does the guard receive "see" the original message? Will the original receive "see" any messages removed by the guard receive? What happens if the guard receive takes the message the top receive is processing? Etc... Do I have logical message queue handling where each receive sees the complete queue it had when it was called? This problem is similar to the handling of the Prolog database which now are logical, but that does lead to some strange effects. This is not just a matter of choosing any solution and running with it as you have to be able to explain it to people so it is understandable, consistent and USABLE. One suggestion which has been made is to "turn off" using any unsafe BIF calls and have them cause the function to exit. But that would mean that user functions would behave differently if they are used normally or within a guard. Which could be difficult if you are calling functions from someone else's libraries. The trouble with adding a feature like this, or any feature for that matter, is that you have to be able to handle all cases, and I mean *ALL* cases, not just the reasonable ones which you had in mind when planning the feature. And give meaning to all cases as well. "It is impossible to make something foolproof because fools are so ingenuous." Forgot about 'cond'. We should add that and allow any user code in the tests. We can either catch errors in tests and treat them as false or just let them generate a normal error. The latter I think. Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080313/351aaf20/attachment-0001.html From raould Thu Mar 13 23:50:23 2008 From: raould (Raoul Duke) Date: Thu, 13 Mar 2008 15:50:23 -0700 Subject: [erlang-questions] erlang sucks In-Reply-To: <3dbc6d1c0803131543pc89e6fbm7511205040f5793@mail.gmail.com> References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> <3dbc6d1c0803131543pc89e6fbm7511205040f5793@mail.gmail.com> Message-ID: <91a2ba3e0803131550n41491d80j557c540e89ca60dd@mail.gmail.com> > Assume I am in a receive and in the guard of testing one message I call a > function which also receives messages. What happens to the message queue? this has nothing to do with the reality of Erlang :-) but presumably in a sufficiently powerful type system you could constrain the guards to be safe? From ok Fri Mar 14 06:16:55 2008 From: ok (Richard A. O'Keefe) Date: Fri, 14 Mar 2008 18:16:55 +1300 Subject: [erlang-questions] erlang sucks In-Reply-To: References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> Message-ID: <07EF836B-BDE7-407E-92BB-8B2D33227B19@cs.otago.ac.nz> I wrote that >> the 'cond' proposal ... completely answers the claimed need for an >> if >> with user-defined functions callable in the guards. > On 14 Mar 2008, at 1:30 am, David Holz wrote: > Claimed need? Yes. CLAIMED need. Remember, while guards resemble Erlang expressions, they are fundamentally different. Indeed, it is a real shame that new BIFs have been introduced that can be used in both guards and expressions; it would have been better to make the two sets of BIFs disjoint. It is also a real shame that there are alternatives to "," and ";" in guards borrowed from the expression world. Again, the two should have been kept clearly distinct. The differences really boil down to this: guards are for INDEXING. Just as a compiler is free to do unification in any order and to share submatches across any number of clauses, so a compiler is free to do guard code in any order, to share guard tests across any number of alternatives, and to arbitrarily interleave matching and guard testing. For example, I would hope a compiler to translate p(X, "big hairy pattern") when integer(X), X > 0 -> ... by testing the type and value of X before matching "big hairy pattern". In order to freely reorder and share guard computations, the code must be known to be free of side effects, including input/output and message passing. To handle "exception = guard failure", it really pays to have operations that could raise exceptions where the index compiler can see them, not hidden in functions that do who knows what. Haskell has it easier here, of course, because any side effects of a function must be revealed in its type. Suppose we ha cond E1 -> S1 ; E2 -> S2 ; En -> Sn end This can be handled pretty closely by case E1 of true -> S1; case E2 of true -> S2; ... case En of true -> Sn end ... end end All that's really needed here is an equivalent of Algol 68's "ouse", which was to 'case' as 'elif' was to 'if'. So add it! case E1 of true -> S1 ouse E2 of true -> S2 ... ouse En of true -> Sn end "ouse" is pretty horrible (almost the only Algol 68 keyword I disliked; what have cases got to do with the river Ouse?). Doubtless some better keyword could be found. 'orca', perhaps? (Joke.) > Predicate functions are absolutely necessary in handling dispatch > decisions for any sort of system whose message vocabulary is > upgraded over time, in my experience. Just today I found that something I thought for *sure* was a Boolean function actually needed to distinguish three cases. I have to agree that *classification* functions are necessary; it is far from obvious that they have to be Boolean. Again, in Haskell I often find that something I originally thought of as returning a Boolean should return a Maybe or Either instead. Above I explained why changing 'if' to be 'cond' would be a bad idea. We really do have good uses for something that acts the way 'if' does now. I have also mentioned the 'cond' proposal. But I have now explained why 'cond' should normally be avoided even if we had it: it forces you to use Boolean results, which may seriously limit your imagination. Any time you have cond p1(X) -> f(X, g1(X)) ; p2(X) -> h(X, g2(X)) ... you should probably be using case classify(X) of {p1,G1} -> f(X, G1) ; {p2,G2) -> h(X, G2) ... just as it is better to do case X of [H|T] -> ... than if is_cons(X) -> ... head(X) .. tail(X) ... > Having to put the explicit matching specification any place where a > message or data structure is handled (even for simple dispatch pass- > through which doesn't do anything with the contents) instead of > deferring to a predicate is a horrible violation of DRY, I don't know what the acronym "DRY" stands for. To the extent that I follow what you are saying here, I agree that you shouldn't do that, but I deny that the absence of xif/cond makes you do it. The suggestion about something similar to C++ "constness" (really, something similar to what other declaration languages call "purity") is something I thought about back in 1988, and was actually writing up a proposal for when funs were introduced into the language and made it much more difficult. C++ does it in the type system, and Erlang doesn't normally use a type system, because of the difficulties combining that with hot loading. If you are generating Erlang code from a DSL, then why not just fix your code generator? As a matter of fact, the 'abstract patterns' proposal I put forward oh so many years ago would presumably solve your problem pretty much the way you want to solve it, because abstract patterns are sufficiently constrained that they CAN be safely used in guards. f(Msg = #hello{}) -> ... is necessarily safe, whereas f(Msg) when strange_module:is_hello(Msg) -> would not be. I'm not sure whether to be gratified at how abstract patterns keep solving problems, or saddened... From ulf.wiger Fri Mar 14 10:27:16 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Fri, 14 Mar 2008 10:27:16 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <91a2ba3e0803131550n41491d80j557c540e89ca60dd@mail.gmail.com> References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> <3dbc6d1c0803131543pc89e6fbm7511205040f5793@mail.gmail.com> <91a2ba3e0803131550n41491d80j557c540e89ca60dd@mail.gmail.com> Message-ID: <47DA44F4.4070305@ericsson.com> Raoul Duke skrev: >> Assume I am in a receive and in the guard of testing one message I call a >> function which also receives messages. What happens to the message queue? > > this has nothing to do with the reality of Erlang :-) but presumably > in a sufficiently powerful type system you could constrain the guards > to be safe? Given the state of type checking in Erlang nowadays, this might indeed be ripe for some research and prototyping. BR, Ulf W From mats.cronqvist Fri Mar 14 09:07:58 2008 From: mats.cronqvist (Mats Cronqvist) Date: Fri, 14 Mar 2008 09:07:58 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <07EF836B-BDE7-407E-92BB-8B2D33227B19@cs.otago.ac.nz> References: <47D52E27.6060901@kreditor.se> <8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com> <47D67F5F.1040807@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> <07EF836B-BDE7-407E-92BB-8B2D33227B19@cs.otago.ac.nz> Message-ID: <47DA325E.6040606@kreditor.se> Richard A. O'Keefe wrote: > > I don't know what the acronym "DRY" stands for. Don't Repeat Yourself. Popularized by the Pragmatic Programmers. -------------- next part -------------- A non-text attachment was scrubbed... Name: mats_cronqvist.vcf Type: text/x-vcard Size: 179 bytes Desc: not available Url : http://www.erlang.org/pipermail/erlang-questions/attachments/20080314/4273f225/attachment.vcf From thomasl_erlang Fri Mar 14 11:15:20 2008 From: thomasl_erlang (Thomas Lindgren) Date: Fri, 14 Mar 2008 03:15:20 -0700 (PDT) Subject: [erlang-questions] erlang sucks In-Reply-To: <47DA44F4.4070305@ericsson.com> Message-ID: <22403.55128.qm@web38814.mail.mud.yahoo.com> --- "Ulf Wiger (TN/EAB)" wrote: > Raoul Duke skrev: > > > this has nothing to do with the reality of Erlang > :-) but presumably > > in a sufficiently powerful type system you could > constrain the guards > > to be safe? > > Given the state of type checking in Erlang nowadays, > this might indeed > be ripe for some research and prototyping. Marking functions as safe/pure is straightforward when you have the whole program -- just mark the uncertain cases as impure -- so you could easily verify that a certain software release only uses safe guards. As far as I can see, the main problem would be piecemeal use of code, such as in ad hoc hot code loading. But even here, it seems you could reject the module at load time by (a) enclosing suitable annotations with the beam file and (b) a quick bit of load-time analysis. Best, Thomas ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ From ulf.wiger Fri Mar 14 13:10:54 2008 From: ulf.wiger (Ulf Wiger (TN/EAB)) Date: Fri, 14 Mar 2008 13:10:54 +0100 Subject: [erlang-questions] erlang sucks In-Reply-To: <22403.55128.qm@web38814.mail.mud.yahoo.com> References: <22403.55128.qm@web38814.mail.mud.yahoo.com> Message-ID: <47DA6B4E.9000805@ericsson.com> Thomas Lindgren skrev: > --- "Ulf Wiger (TN/EAB)" > wrote: > >> Raoul Duke skrev: >> >>> this has nothing to do with the reality of Erlang >> :-) but presumably >>> in a sufficiently powerful type system you could >> constrain the guards >>> to be safe? >> Given the state of type checking in Erlang nowadays, >> this might indeed >> be ripe for some research and prototyping. > > Marking functions as safe/pure is straightforward when > you have the whole program -- just mark the uncertain > cases as impure -- so you could easily verify that a > certain software release only uses safe guards. > > As far as I can see, the main problem would be > piecemeal use of code, such as in ad hoc hot code > loading. But even here, it seems you could reject the > module at load time by (a) enclosing suitable > annotations with the beam file and (b) a quick bit of > load-time analysis. ...or mark calls to external functions as impure/unsafe. I think this is a reasonable restriction. BR, Ulf W From bekesa Fri Mar 14 12:57:31 2008 From: bekesa (Andras Georgy Bekes) Date: Fri, 14 Mar 2008 12:57:31 +0100 Subject: [erlang-questions] erlang ***** In-Reply-To: References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> Message-ID: <200803141257.32178.bekesa@sch.bme.hu> Hi, I was following this topic and was waiting for the right time to throw in my ideas :-) > case X of > _ when X == abc; X == xyz -> > do_abc_or_xyz(); > I don't much like the _ when business. Yes, I agree, but while you suggest using 'if' in similar cases, I suggest a different solution. The point here is that you want do have the same result in several cases, but you can't do it with the 'case' construct. You use guards instead of pattern matching, because the logic "OR" operator (;) can be used with guards, while it cannot be used with patterns. Pattern matching basically tests whether a term is a member of a subset of terms. So a pattern describes a subset of terms. Patterns and guards together do the same, they describe a subset of terms by deselecting values that don't satisfy the guards. The ; operator means union. The pattern Pattern when Guard1; Guard2 describes the subset of terms: (Pattern when Guard1) UNION (Pattern when Guard2) Why don't we extend the notion of patterns to somehow describe the union set operation? We already can describe the intersection of patterns: Pattern1=Pattern2 describes the subset Pattern1 INTERSECTION Pattern2 I think there is no '\/' operator in Erlang, so Pattern1 \/ Pattern2 could mean Pattern1 UNION Pattern2 Let's see some example uses: {a,_,_} \/ {b,_,_} [ a \/ b | Tail ] {a,X,_} when is_integer(X) \/ {X,b,_} when X>3 The union of patterns matches if (at least) one of the patterns matches. The union pattern binds only the names that are present in each pattern. Other names are considered unsafe. There is one more basic set operation: subtraction. With the use of guards, you can subtract a subsets from a set described by a pattern: A positive guard subtracts the terms that don't satisfy the guard, negated guards subtract the terms that do. But you cannot subtract a subset of terms described by a pattern. I've already suggested a pattern-match-test operator. It does have other uses as well, but it is also useful for subtracting subsets: Let "Pattern ~= Expression" semantically mean case Expression of Pattern -> true; _ -> false end You'll want to use this in guards: Pattern1 when not (Pattern2 ~= Pattern1) means Pattern1 MINUS Pattern2 Of course the syntax might seem terrible, there are probably better symbols for set operations. The addition of these two constructs would: - amend patterns to be a complete syntax for describing a subset of terms - allow programmers to avoid duplicated code - only _extend_ Erlang, not changing the behaviour of existing programs - almost entirely obsolate the 'if' construct However, in order to fully obsolate 'if', we'd need some case-like construct that can check multiple expressions. This is what Richard A. O'Keefe suggested: > This can be handled pretty closely by > case E1 of true -> S1; > case E2 of true -> S2; > ... > case En of true -> Sn > end ... end end > All that's really needed here is an equivalent of Algol 68's "ouse", > which was to 'case' as 'elif' was to 'if'. So add it! > > case E1 of true -> S1 > ouse E2 of true -> S2 > ... > ouse En of true -> Sn > end I don't have a better syntax proposal, but I completely agree. Besides: > The differences really boil down to this: > guards are for INDEXING. Yes, patterns and guards not only have to be expressive, they also have to be very efficient. You might think that the above idea of extending pattern matching with the union operator ruins the clever indexing of patterns. It does not, because the decision diagram does not have to be a tree, i.e. union'd patterns might have independent paths in the decision diagram, but end in the same leaf (function or case clause). Georgy From vladdu55 Fri Mar 14 14:34:14 2008 From: vladdu55 (Vlad Dumitrescu) Date: Fri, 14 Mar 2008 14:34:14 +0100 Subject: [erlang-questions] erlang ***** In-Reply-To: <200803141257.32178.bekesa@sch.bme.hu> References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> <200803141257.32178.bekesa@sch.bme.hu> Message-ID: <95be1d3b0803140634r6a143ed3q925f790755f3a1ca@mail.gmail.com> Hi, On Fri, Mar 14, 2008 at 12:57 PM, Andras Georgy Bekes wrote: > Why don't we extend the notion of patterns to somehow describe the union > set operation? That's a very good idea, I think. I mean not only the union operation, but the whole proposal. Maybe you should prepare an EEP -- pattern matching is one of the main strengths of Erlang as a language and improving it would affect positively all the code base. [and it's a backward-compatible change] I see a couple of additional (future) steps: ** Since something new is added to the language, we could look at removing something: the guards, by allowing inlined guard expressions in the pattern itself, like for example {integer(X), _, X>3, atom(Y), Z!=[X,Y]} or {integer(X>3), _, X, atom(Y), Z!={X,Y]} would be equivalent to {X, _, X, Y} when is_integer(X), X>3, is_atom(Y), not(Z ~=[X, Y]). ** And from here I think only the '?' and '*' operators (i.e. the optional marker and the Kleene closure) are missing in order to get a pattern language with full regular expression power. But that can wait for a little while, maybe :-) best regards, Vlad -- Some people see things that are and ask, Why? Some people dream of things that never were and ask, Why not? Some people have to go to work and don't have time for all that. --- George Carlin From romain.lenglet Fri Mar 14 15:05:29 2008 From: romain.lenglet (Romain Lenglet) Date: Fri, 14 Mar 2008 23:05:29 +0900 Subject: [erlang-questions] erlounge: Erlounge in Shibuya, Tokyo, Tuesday April 22nd? Message-ID: <200803142305.30003.romain.lenglet@berabera.info> ?????? ?????????? I propose to meet for an "Erlounge" in Shibuya, Tokyo, during the second week of April. Tuesday April 22nd is a priori a good date. This Erlounge would be a good occasion to celebrate the publication of Kazuya Sakakihara's translation of Joe Armstrong's "Programming Erlang" book into Japanese! Depending on the number of persons, I think that we should either go to a bar, or to an izakaya (where it should be easier to reserve tables). I got the following suggestions: - "Les Hydropathes": http://search.japantimes.co.jp/cgi-bin/fg20021124rs.html - "Toriyoshi": http://www.bento.com/rev/0646.html - "En": http://www.obanzai-nana.com/101.shtml Please answer if you can attend and say which place you prefer, or to suggest another date or place. It would be good to know roughly the number of persons one week before, in order to reserve tables / a room if necessary. ??????????????????? Cheers, -- Romain Lenglet From henrique.ferreiro Fri Mar 14 16:24:03 2008 From: henrique.ferreiro (Henrique Ferreiro) Date: Fri, 14 Mar 2008 16:24:03 +0100 Subject: [erlang-questions] DHT in erlang In-Reply-To: <47D8A68C.2080502@ghostgun.com> References: <7629cacc0803111145r2dfd1002ybad89e60a813b046@mail.gmail.com> <47D8A68C.2080502@ghostgun.com> Message-ID: <1205508244.6404.7.camel@macbook> ?I implemented the chord DHT for an end of degree project. Let me now if you have any questions. O Xov, 13-03-2008 ?s 14:59 +1100, jm escribiu: > Ashish Sharma wrote: > > Hi > > > > Has anyone implemented some DHT (standard or custom) distributed hash > > table in erlang or has seen such implementation. > > > > I've thought about it in passing but had to start working on something > else. I was looking at it from the bit torrent perspective though. The > intent was more trying to optimise local network traffic than to > actually run a tracker or bt client. Where you thinking of something > specific algorithm (eg chord http://pdos.csail.mit.edu/chord/), purpose, > etc? > > > Jeff. > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From rpettit Fri Mar 14 17:12:20 2008 From: rpettit (Rick Pettit) Date: Fri, 14 Mar 2008 11:12:20 -0500 Subject: [erlang-questions] erlang sucks In-Reply-To: <47DA325E.6040606@kreditor.se> References: <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> <07EF836B-BDE7-407E-92BB-8B2D33227B19@cs.otago.ac.nz> <47DA325E.6040606@kreditor.se> Message-ID: <20080314161220.GA18938@vailsys.com> On Fri, Mar 14, 2008 at 09:07:58AM +0100, Mats Cronqvist wrote: > Richard A. O'Keefe wrote: > > > >I don't know what the acronym "DRY" stands for. > Don't Repeat Yourself. Popularized by the Pragmatic Programmers. I'm still a bit fuzzy on the difference between DRY and SPOT (single point of truth). I've got the book around here someplace--maybe I need a review :-) -Rick P.S. Naturally if DRY == SPOT then DRY wins (less typing, and we all know that laziness is a virtue). From fess-erlang Fri Mar 14 18:25:57 2008 From: fess-erlang (fess) Date: Fri, 14 Mar 2008 10:25:57 -0700 Subject: [erlang-questions] erlang rules!! In-Reply-To: <43139AE6-136F-4183-8C85-D1D6961042A4@gmail.com> References: <47D52E27.6060901@kreditor.se><8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com><47D67F5F.1040807@kreditor.se><47D6DCFB.9050604@kreditor.se> <007001c88469$4242b680$891ea8c0@SSI.CORP> <43139AE6-136F-4183-8C85-D1D6961042A4@gmail.com> Message-ID: Hi, just changing the subject on this thread, so I don't have to repeatedly be told in my inbox that erlang sucks. of course, it probably won't work because people will keep replying to the old thread, and then every few minutes my mail will inform me that erlang sucks. *grin* --fess "erlang high school football rules!" From sean.hinde Fri Mar 14 18:33:42 2008 From: sean.hinde (Sean Hinde) Date: Fri, 14 Mar 2008 17:33:42 +0000 Subject: [erlang-questions] erlang sucks!! In-Reply-To: References: <47D52E27.6060901@kreditor.se><8209f740803110143h53b2df4br28c85a93d826abef@mail.gmail.com><47D67F5F.1040807@kreditor.se><47D6DCFB.9050604@kreditor.se> <007001c88469$4242b680$891ea8c0@SSI.CORP> <43139AE6-136F-4183-8C85-D1D6961042A4@gmail.com> Message-ID: > just changing the subject on this thread, so I don't have to > repeatedly be told in my inbox that erlang sucks. > > of course, it probably won't work because people will keep replying > to the old thread, and then every few minutes my mail will inform me > that erlang sucks. > I'm sure Erlang will survive the accusation :-) Sean From michael.campbell Fri Mar 14 18:47:54 2008 From: michael.campbell (Michael Campbell) Date: Fri, 14 Mar 2008 13:47:54 -0400 Subject: [erlang-questions] erlang sucks In-Reply-To: <20080314161220.GA18938@vailsys.com> References: <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com> <706F1C58-5465-4372-A54F-CDD3A191E267@cs.otago.ac.nz> <07EF836B-BDE7-407E-92BB-8B2D33227B19@cs.otago.ac.nz> <47DA325E.6040606@kreditor.se> <20080314161220.GA18938@vailsys.com> Message-ID: <47DABA4A.3050604@unixgeek.com> Rick Pettit wrote: > On Fri, Mar 14, 2008 at 09:07:58AM +0100, Mats Cronqvist wrote: >> Richard A. O'Keefe wrote: >>> I don't know what the acronym "DRY" stands for. >> Don't Repeat Yourself. Popularized by the Pragmatic Programmers. > > I'm still a bit fuzzy on the difference between DRY and SPOT (single point of > truth). Don't forget the (tongue in cheek) converse "WET" principal... "Write Everything Twice". =) From elmer_fwd Fri Mar 14 18:57:10 2008 From: elmer_fwd (elmer_fwd) Date: Fri, 14 Mar 2008 09:57:10 -0800 Subject: [erlang-questions] port_driver.c problems Message-ID: <47dabc76.162.3737.70484518@antelecom.net> The code for port_driver.c does an: #include "port_driver.h" When I compile the example code with the command: gcc -o exmpledrv -shared complex.c port_driver.c At the link phase, I get the errors: /cygdrive/c/DOCUME~1/s360852/LOCALS~1/Temp/ccXxTBKu.o:port_driver.c:(.text+0xe): undefined reference to `_driver_alloc' /cygdrive/c/DOCUME~1/s360852/LOCALS~1/Temp/ccXxTBKu.o:port_driver.c:(.text+0x2f): undefined reference to `_driver_free' /cygdrive/c/DOCUME~1/s360852/LOCALS~1/Temp/ccXxTBKu.o:port_driver.c:(.text+0x98): undefined reference to `_driver_output' This implies to me that the functions driver_alloc, driver_free and driver_output are not available for linking. Anybody have a suggestion? thanks From valentin Fri Mar 14 20:45:52 2008 From: valentin (Valentin Micic) Date: Fri, 14 Mar 2008 21:45:52 +0200 Subject: [erlang-questions] Linux O_DIRECT flag Message-ID: <002701c8860c$02c6c650$6401a8c0@moneymaker2> Dear all, One thing that has to make a top 10 most-likely-to-frustrate-you features in LINUX is its uncontrollable usage of memory for I/O caching. Whilst good for most applications, it seems quite redundant if you connect a big storage array that has a cache on its own. After a brief investigation regarding ones ability to bypass the cache (performed by our hardware supplier), I've been told that an application may bypass the cache by porviding additional flag to "open" system call -- O_DIRECT to be more specific. I assume that file:open/2 does not support this flag, so I'd like to ask, before we start hacking around: is there an easy way to expose this flag, and would you consider it for inclusion in one of the next releases. Provided that O_DIRECT does what we think it does, of course. Thanks in advance, Valenitn. From rapsey Fri Mar 14 21:32:50 2008 From: rapsey (Rapsey) Date: Fri, 14 Mar 2008 21:32:50 +0100 Subject: [erlang-questions] Linux O_DIRECT flag In-Reply-To: <002701c8860c$02c6c650$6401a8c0@moneymaker2> References: <002701c8860c$02c6c650$6401a8c0@moneymaker2> Message-ID: <97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com> I don't understand. Why is that a problem? Access to RAM will always be much faster than access to a storage array. On Fri, Mar 14, 2008 at 8:45 PM, Valentin Micic wrote: > Dear all, > > One thing that has to make a top 10 most-likely-to-frustrate-you features > in > LINUX is its uncontrollable usage of memory for I/O caching. Whilst good > for > most applications, it seems quite redundant if you connect a big storage > array that has a cache on its own. > After a brief investigation regarding ones ability to bypass the cache > (performed by our hardware supplier), I've been told that an application > may > bypass the cache by porviding additional flag to "open" system call -- > O_DIRECT to be more specific. I assume that file:open/2 does not support > this flag, so I'd like to ask, before we start hacking around: is there > an > easy way to expose this flag, and would you consider it for inclusion in > one > of the next releases. Provided that O_DIRECT does what we think it does, > of > course. > > Thanks in advance, > > Valenitn. > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080314/d295c4dc/attachment.html From dmercer Fri Mar 14 23:17:41 2008 From: dmercer (David Mercer) Date: Fri, 14 Mar 2008 17:17:41 -0500 Subject: [erlang-questions] Erlang GUIs In-Reply-To: <110BA8ACEE682C479D0B008B6BE4AEB105E49EE7@esealmw107.eemea.ericsson.se> References: <47D52E27.6060901@kreditor.se><47D6DCFB.9050604@kreditor.se><47D70389.4030303@kreditor.se><3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com><47D7894A.3030909@ericsson.com><47D7923B.8080400@kreditor.se><4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com><47D7E25D.30909@kreditor.se><4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com><47D7FC95.8040906@kreditor.se><1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <110BA8ACEE682C479D0B008B6BE4AEB105E49EE7@esealmw107.eemea.ericsson.se> Message-ID: <005601c88621$38b88a40$891ea8c0@SSI.CORP> Speaking of which, what are the best ways of creating GUIs to interact with Erlang? Gs? Run Yaws or Erlyweb or something and use the web browser? I heard Joe once mention using Flash as the UI front end? What is the state of the art right now? Thanks. Cheers, David -----Original Message----- From: erlang-questions-bounces [mailto:erlang-questions-bounces] On Behalf Of Erik Reitsma Sent: Thursday, March 13, 2008 03:06 To: Bengt Kleberg Cc: Erlang mailing list Subject: Re: [erlang-questions] erlang sucks If you count libraries: after rewriting a GUI from iv to tcl I gave up when tcl was removed. I guess gs has been around long enough to consider it, but then again there are still GUI alternatives floating around, and I am afraid they will become better than gs and gs will be replaced. *Erik. > Out of interest: > Does anybody know of _anything_ that has been removed, ever? > > > bengt > > On Wed, 2008-03-12 at 16:53 +0100, Mats Cronqvist wrote: > > Hynek Vychodil wrote: > > > > > > > > > On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist > > > > wrote: > > > > > > or are you saying there is a need for several > 'and'? in that case i > > > disagree. > > > > > > ... > > > I think there is no way to change it, because if you > remove 'andalso' > > > and use 'and' in programmers manner lazy behaviour, you > will break > > > some legacy code a vice versa. This change is impossible. > You can be > > > not agree with it. You can argue against it, but it is > all what you > > > can do with it. > > if you go back a few posts, you'll see that i try to make it very > > clear that nothing will be removed (at least not for the > next few years). > > > > mats > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions From valentin Fri Mar 14 22:14:55 2008 From: valentin (Valentin Micic) Date: Fri, 14 Mar 2008 23:14:55 +0200 Subject: [erlang-questions] Linux O_DIRECT flag References: <002701c8860c$02c6c650$6401a8c0@moneymaker2> <97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com> Message-ID: <004101c88618$75ebbda0$6401a8c0@moneymaker2> Not when your application starts to swap-in and out because it is running out of RAM, and yet you still have plenty of RAM occupied by files that have been open and read, say few months ago, and no longer needed. Now, consider 64GB RAM of which 32 GB is occupied by cache. Between faster and fast enough, I'm always inclined to select fast enough, especially if that's going to allow me to use memory the way I need to vs. the way OS forces me to. V. ----- Original Message ----- From: Rapsey To: erlang-questions Sent: Friday, March 14, 2008 10:32 PM Subject: Re: [erlang-questions] Linux O_DIRECT flag I don't understand. Why is that a problem? Access to RAM will always be much faster than access to a storage array. On Fri, Mar 14, 2008 at 8:45 PM, Valentin Micic wrote: Dear all, One thing that has to make a top 10 most-likely-to-frustrate-you features in LINUX is its uncontrollable usage of memory for I/O caching. Whilst good for most applications, it seems quite redundant if you connect a big storage array that has a cache on its own. After a brief investigation regarding ones ability to bypass the cache (performed by our hardware supplier), I've been told that an application may bypass the cache by porviding additional flag to "open" system call -- O_DIRECT to be more specific. I assume that file:open/2 does not support this flag, so I'd like to ask, before we start hacking around: is there an easy way to expose this flag, and would you consider it for inclusion in one of the next releases. Provided that O_DIRECT does what we think it does, of course. Thanks in advance, Valenitn. _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions ------------------------------------------------------------------------------ _______________________________________________ erlang-questions mailing list erlang-questions http://www.erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080314/d0aca31e/attachment.html From toby Sat Mar 15 01:53:17 2008 From: toby (Toby Thain) Date: Fri, 14 Mar 2008 20:53:17 -0400 Subject: [erlang-questions] Linux O_DIRECT flag In-Reply-To: <004101c88618$75ebbda0$6401a8c0@moneymaker2> References: <002701c8860c$02c6c650$6401a8c0@moneymaker2> <97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com> <004101c88618$75ebbda0$6401a8c0@moneymaker2> Message-ID: On 14-Mar-08, at 5:14 PM, Valentin Micic wrote: > Not when your application starts to swap-in and out because it is > running out of RAM, That should never happen! Are you sure you've got the right analysis? --Toby > and yet you still have plenty of RAM occupied by files that have > been open and read, say few months ago, and no longer needed. Now, > consider 64GB RAM of which 32 GB is occupied by cache. > > Between faster and fast enough, I'm always inclined to select fast > enough, especially if that's going to allow me to use memory the > way I need to vs. the way OS forces me to. > > V. > > ----- Original Message ----- > From: Rapsey > To: erlang-questions > Sent: Friday, March 14, 2008 10:32 PM > Subject: Re: [erlang-questions] Linux O_DIRECT flag > > I don't understand. Why is that a problem? Access to RAM will > always be much faster than access to a storage array. > > > On Fri, Mar 14, 2008 at 8:45 PM, Valentin Micic > wrote: > Dear all, > > One thing that has to make a top 10 most-likely-to-frustrate-you > features in > LINUX is its uncontrollable usage of memory for I/O caching. Whilst > good for > most applications, it seems quite redundant if you connect a big > storage > array that has a cache on its own. > After a brief investigation regarding ones ability to bypass the cache > (performed by our hardware supplier), I've been told that an > application may > bypass the cache by porviding additional flag to "open" system call -- > O_DIRECT to be more specific. I assume that file:open/2 does not > support > this flag, so I'd like to ask, before we start hacking around: is > there an > easy way to expose this flag, and would you consider it for > inclusion in one > of the next releases. Provided that O_DIRECT does what we think it > does, of > course. > > Thanks in advance, > > Valenitn. > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080314/8bcca3f1/attachment-0001.html From per Sat Mar 15 02:23:44 2008 From: per (Per Hedeland) Date: Sat, 15 Mar 2008 02:23:44 +0100 (CET) Subject: [erlang-questions] Linux O_DIRECT flag In-Reply-To: Message-ID: <200803150123.m2F1NiSZ046867@pluto.hedeland.org> Toby Thain wrote: > >On 14-Mar-08, at 5:14 PM, Valentin Micic wrote: > >> Not when your application starts to swap-in and out because it is >> running out of RAM, > >That should never happen! At least not when you include the "few months ago" part - inactive non-dirty pages are of course just tossed if RAM is needed for other purposes - but there's no point in doing it earlier, which sometimes leads to the newbie (sorry:-) question "Where has all my RAM gone?" What *can* be a problem though is that *active* massive I/O operations force other pages out to swap due to unrestricted cache growth - which is why "some other" OSes implement some "push-back" mechanisms for the cache, or in older times simply had a hard limit as percentage of RAM. I don't know off-hand whether there is a way to make Linux do something like that, but I would think so (at least the hard limit method, maybe with a number calculated by the user) - but the default is AFAIK "give the cache all it wants". > Are you sure you've got the right analysis? I would also doubt that, given the way the problem is presented. In any case the O_DIRECT thing sounds like a performance disaster unless you have an application that has been specifically designed with those semantics in mind. --Per Hedeland From tatezhou Sat Mar 15 05:08:42 2008 From: tatezhou (tatezhou) Date: Sat, 15 Mar 2008 12:08:42 +0800 Subject: [erlang-questions] How to the a ets table is exists or not ? References: <002701c8860c$02c6c650$6401a8c0@moneymaker2><97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com><004101c88618$75ebbda0$6401a8c0@moneymaker2> Message-ID: <002d01c88652$43637190$8b01a8c0@ZHOUBO> Greets: I need to create a ets table if it is not exists, how to code it ? I have check the online docs of chapter "ets", there is not function to handle this . Current solution is to get all the ets tables and check if the table i want in the list. but i don't think this is a good idea. code: Ret = ets:new(client_cmd_hooks, [named_table]), thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080315/79d84ade/attachment.html From shehan Sat Mar 15 05:40:46 2008 From: shehan (shehan) Date: Sat, 15 Mar 2008 10:10:46 +0530 Subject: [erlang-questions] regexp behaviour Message-ID: <20080315044414.8ED9E19DC20E@mail.wavenet.lk> Hi all, Is the some way to stop the following behaviour of the "sub" function in the "regexp" module Str1 = "String with & character" Str2 = "Replace the following tag with str1" regexp:sub(Str2, "", Str1). {ok, NewStr, Count} = regexp:gsub(Str1, [""], Ad2). NewStr. "Replace the following tag String with character with str1" The is replaced by the content of Str1, but the & character in Str1 has been replaced by the replaced character set . is there some way to stop this from happening. Thanx Shehan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080315/05cac1e8/attachment.html From rapsey Sat Mar 15 06:57:46 2008 From: rapsey (Rapsey) Date: Sat, 15 Mar 2008 06:57:46 +0100 Subject: [erlang-questions] How to the a ets table is exists or not ? In-Reply-To: <002d01c88652$43637190$8b01a8c0@ZHOUBO> References: <002701c8860c$02c6c650$6401a8c0@moneymaker2> <97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com> <004101c88618$75ebbda0$6401a8c0@moneymaker2> <002d01c88652$43637190$8b01a8c0@ZHOUBO> Message-ID: <97619b170803142257k2af52099i16fd92c22c37bbcd@mail.gmail.com> >From ets module documentation: info(Tab) -> [{Item, Value}] | undefined Returns information about the table Tab as a list of {Item, Value} tuples. If Tab has the correct type for a table identifier, but does not refer to an existing ETS table, undefined is returned. If Tab is not of the correct type, this function fails with reason badarg. That should work. 2008/3/15 tatezhou : > Greets: > > I need to create a ets table if it is not exists, how to code it ? I have > check the online docs of chapter "ets", there is not function to handle this > . > > > Current solution is to get all the ets tables and check if the table i > want in the list. but i don't think this is a good idea. > > > > code: > > > Ret = ets:new(client_cmd_hooks, [named_table]), > > > thanks. > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080315/889491b9/attachment.html From alpar Sat Mar 15 07:12:18 2008 From: alpar (=?ISO-8859-1?Q?Alp=E1r_J=FCttner?=) Date: Sat, 15 Mar 2008 06:12:18 +0000 Subject: [erlang-questions] Linux O_DIRECT flag In-Reply-To: References: <002701c8860c$02c6c650$6401a8c0@moneymaker2> <97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com> <004101c88618$75ebbda0$6401a8c0@moneymaker2> Message-ID: <1205561538.4481.17.camel@piko.site> On Fri, 2008-03-14 at 20:53 -0400, Toby Thain wrote: > > On 14-Mar-08, at 5:14 PM, Valentin Micic wrote: > > > Not when your application starts to swap-in and out because it is > > running out of RAM, > That should never happen! It may be, but it still happens. For example if you just copy a very big file of directory tree (cp -a), the linux desktop often becomes unusably sluggish. If you don't use an application (e.g. Firefox) for some time, it gets out of the RAM and it takes several seconds until it reacts the first click. Some time later you want to go back to Emacs, the same happens. But this should be a factor of the kernel configuration, because sometimes linux does it sometime it doesn't. For example there is a kernel 'swappisess' parameter /proc/sys/vm/swappiness which should control this. I asked google about this file and the first hit was this: http://lwn.net/Articles/83588/ Regards, Alpar From buricchio Sat Mar 15 09:27:01 2008 From: buricchio (andrey-google) Date: Sat, 15 Mar 2008 10:27:01 +0200 Subject: [erlang-questions] How to the a ets table is exists or not ? In-Reply-To: <002d01c88652$43637190$8b01a8c0@ZHOUBO> References: <002701c8860c$02c6c650$6401a8c0@moneymaker2><97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com><004101c88618$75ebbda0$6401a8c0@moneymaker2> <002d01c88652$43637190$8b01a8c0@ZHOUBO> Message-ID: <893033258.20080315102701@gmail.com> You may use try..catch ... try ;;do_something with ets table, e.g. ets:update_counter ets:update_counter(mytable, mycounter, 1) catch error:badarg -> init_mytables() end. ... or more specific catch ... case (catch ets:update_counter(mytable, mycounter, 1)) of {'EXIT', {badarg, ...}} -> ... Cheers! From valentin Sat Mar 15 09:00:26 2008 From: valentin (Valentin Micic) Date: Sat, 15 Mar 2008 10:00:26 +0200 Subject: [erlang-questions] Linux O_DIRECT flag References: <002701c8860c$02c6c650$6401a8c0@moneymaker2> <97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com> <004101c88618$75ebbda0$6401a8c0@moneymaker2> <1205561538.4481.17.camel@piko.site> Message-ID: <006901c88672$a4bca7c0$6401a8c0@moneymaker2> Per wrote: > I would also doubt that, given the way the problem is presented. In any > case the O_DIRECT thing sounds like a performance disaster unless you > have an application that has been specifically designed with those > semantics in mind. Application was designed to take advantage of RAM, with journaling and write behind... however, I fail to see a relevance of answers visa-a-vis my question -- question was how to do it, and not so much, if at all, why one should not do it. As far as implementing support for O_DIRECT flag: I suppose that a proper place for it would be in "prim_file.erl" open_mode/4. However, doing it on my own would mean that I have to do it every time a new release is out. Well, I'm not crazy about it -- wouldn't it be far more convenient if this becomes a part of standard release (pveeez). I mean, if O_DIRECT option exist, it is there for a reason, so if someone is crazy (or stupid) enough to use it, let him knock (him|her)self out, right? V. PS IMHO, performance tuning is much more difficult if one needs to do it at kernel level -- you may fix one thing, but brake another. If one could establish desired behavior/performance at the application level, one has a better way to manage performance of such application in a long run. ----- Original Message ----- From: "Alp?r J?ttner" To: "Toby Thain" Cc: "Valentin Micic" ; Sent: Saturday, March 15, 2008 8:12 AM Subject: Re: [erlang-questions] Linux O_DIRECT flag > > On Fri, 2008-03-14 at 20:53 -0400, Toby Thain wrote: >> >> On 14-Mar-08, at 5:14 PM, Valentin Micic wrote: >> >> > Not when your application starts to swap-in and out because it is >> > running out of RAM, > >> That should never happen! > > It may be, but it still happens. For example if you just copy a very big > file of directory tree (cp -a), the linux desktop often becomes unusably > sluggish. If you don't use an application (e.g. Firefox) for some time, > it gets out of the RAM and it takes several seconds until it reacts the > first click. Some time later you want to go back to Emacs, the same > happens. > > But this should be a factor of the kernel configuration, because > sometimes linux does it sometime it doesn't. For example there is a > kernel 'swappisess' parameter /proc/sys/vm/swappiness which should > control this. I asked google about this file and the first hit was this: > > http://lwn.net/Articles/83588/ > > Regards, > Alpar > > > > From chsu79 Sat Mar 15 12:22:07 2008 From: chsu79 (Christian S) Date: Sat, 15 Mar 2008 12:22:07 +0100 Subject: [erlang-questions] Linux O_DIRECT flag In-Reply-To: <002701c8860c$02c6c650$6401a8c0@moneymaker2> References: <002701c8860c$02c6c650$6401a8c0@moneymaker2> Message-ID: > After a brief investigation regarding ones ability to bypass the cache > (performed by our hardware supplier), I've been told that an application may > bypass the cache by porviding additional flag to "open" system call -- > O_DIRECT to be more specific. I assume that file:open/2 does not support > this flag, so I'd like to ask, before we start hacking around: is there an > easy way to expose this flag, and would you consider it for inclusion in one > of the next releases. Provided that O_DIRECT does what we think it does, of > course. It seems like O_DIRECT requires userspace buffers to be page-aligned. That might be another problem other than just passing O_DIRECT to the open syscall. My guess is that you want to write your own loadable driver to make use of these os-specific features. From frej.drejhammar Sat Mar 15 12:32:50 2008 From: frej.drejhammar (Frej Drejhammar) Date: Sat, 15 Mar 2008 12:32:50 +0100 Subject: [erlang-questions] Linux O_DIRECT flag In-Reply-To: <006901c88672$a4bca7c0$6401a8c0@moneymaker2> (Valentin Micic's message of "Sat, 15 Mar 2008 10:00:26 +0200") References: <002701c8860c$02c6c650$6401a8c0@moneymaker2> <97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com> <004101c88618$75ebbda0$6401a8c0@moneymaker2> <1205561538.4481.17.camel@piko.site> <006901c88672$a4bca7c0$6401a8c0@moneymaker2> Message-ID: > As far as implementing support for O_DIRECT flag: I suppose that a > proper place for it would be in "prim_file.erl" > open_mode/4. However, doing it on my own would mean that I have to > do it every time a new release is out. Well, I'm not crazy about it > -- wouldn't it be far more convenient if this becomes a part of > standard release (pveeez). I mean, if O_DIRECT option exist, it is > there for a reason, so if someone is crazy (or stupid) enough to use > it, let him knock (him|her)self out, right? Start reading http://kerneltrap.org/node/7563 and follow the references for why O_DIRECT probably is not what you want on Linux. The article also gives hints on what to do (posix_fadvise + POSIX_FADV_NOREUSE). Regards, --Frej From chsu79 Sat Mar 15 12:36:05 2008 From: chsu79 (Christian S) Date: Sat, 15 Mar 2008 12:36:05 +0100 Subject: [erlang-questions] How to the a ets table is exists or not ? In-Reply-To: <002d01c88652$43637190$8b01a8c0@ZHOUBO> References: <002701c8860c$02c6c650$6401a8c0@moneymaker2> <97619b170803141332u1bd54441pd368d666cb555156@mail.gmail.com> <004101c88618$75ebbda0$6401a8c0@moneymaker2> <002d01c88652$43637190$8b01a8c0@ZHOUBO> Message-ID: 2008/3/15 tatezhou : > I need to create a ets table if it is not exists, how to code it ? I have > check the online docs of chapter "ets", there is not function to handle this > > Current solution is to get all the ets tables and check if the table i want > in the list. but i don't think this is a good idea. > > Ret = ets:new(client_cmd_hooks, [named_table]), Overall this seem a bit weird designed. Who will be the designated ets table owner for this named table? First arriving process to need the table to exist? Why is it not created at start up by a supervised owner in your application? If your application is running, the table is there, if your application crashes, the owner will be restarted and create it anew. From toby Sat Mar 15 16:10:06 2008 From: toby (Toby Thain) Date: Sat, 15 Mar 2008 11:10:06 -0400 Subject: [erlang-questions] Linux O_DIRECT flag In-Reply-To: <200803150123.m2F1NiSZ046867@pluto.hedeland.org> References: <200803150123.m2F1NiSZ046867@pluto.hedeland.org> Message-ID: <2CAF75E2-F3AD-4791-9619-1FE0F4117B74@telegraphics.com.au> On 14-Mar-08, at 9:23 PM, Per Hedeland wrote: > ... > is why "some other" OSes implement some "push-back" mechanisms for the > cache, or in older times simply had a hard limit as percentage of RAM. > > I don't know off-hand whether there is a way to make Linux do > something > like that, but I would think so (at least the hard limit method, maybe > with a number calculated by the user) - but the default is AFAIK "give > the cache all it wants". Valentin, have you investigated tuning/limiting the cache. OTOH I don't know whether it's possible but it seems strange that the capability would have been entirely omitted. --Toby From bob Sat Mar 15 19:20:37 2008 From: bob (Bob Cowdery) Date: Sat, 15 Mar 2008 18:20:37 +0000 Subject: [erlang-questions] Erlang GUIs In-Reply-To: <005601c88621$38b88a40$891ea8c0@SSI.CORP> References: <47D52E27.6060901@kreditor.se> <47D6DCFB.9050604@kreditor.se> <47D70389.4030303@kreditor.se> <3dbc6d1c0803111743l4421b17drc0729ccb4b8b8fb3@mail.gmail.com> <47D7894A.3030909@ericsson.com><47D7923B.8080400@kreditor.se> <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> <47D7E25D.30909@kreditor.se> <4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com> <47D7FC95.8040906@kreditor.se> <1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <110BA8ACEE682C479D0B008B6BE4AEB105E49EE7@esealmw107.eemea.ericsson.se> <005601c88621$38b88a40$891ea8c0@SSI.CORP> Message-ID: <1205605237.6473.14.camel@ubuntu-life-vm> David I've tried three approaches, all of which work well depending on what you want to do. There are of course other approaches. wxErlang is an interface to the wxWidgets library and although it's coverage is not 100% yet I've found it stable and good enough to write reasonably complex GUI's. This is good if you want to stay entirely in the Erlang world. Java and Swing using the jInterface library. This also works very well if you don't mind straying away from Erlang and don't mind some code bloat in the interfacing. Yaws and Erlyweb make a good pair but it depends on your interface complexity and usability. You might actually end up with a good bit of your ui code in java script using perhaps one of the Ajax libraries like DoJo. Just my pennyworth. - Bob On Fri, 2008-03-14 at 17:17 -0500, David Mercer wrote: > Speaking of which, what are the best ways of creating GUIs to interact with > Erlang? Gs? Run Yaws or Erlyweb or something and use the web browser? I > heard Joe once mention using Flash as the UI front end? > > What is the state of the art right now? > > Thanks. > > Cheers, > > David > > -----Original Message----- > From: erlang-questions-bounces > [mailto:erlang-questions-bounces] On Behalf Of Erik Reitsma > Sent: Thursday, March 13, 2008 03:06 > To: Bengt Kleberg > Cc: Erlang mailing list > Subject: Re: [erlang-questions] erlang sucks > > If you count libraries: after rewriting a GUI from iv to tcl I gave up > when tcl was removed. I guess gs has been around long enough to consider > it, but then again there are still GUI alternatives floating around, and > I am afraid they will become better than gs and gs will be replaced. > > *Erik. > > > Out of interest: > > Does anybody know of _anything_ that has been removed, ever? > > > > > > bengt > > > > On Wed, 2008-03-12 at 16:53 +0100, Mats Cronqvist wrote: > > > Hynek Vychodil wrote: > > > > > > > > > > > > On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist > > > > > > wrote: > > > > > > > > or are you saying there is a need for several > > 'and'? in that case i > > > > disagree. > > > > > > > > ... > > > > I think there is no way to change it, because if you > > remove 'andalso' > > > > and use 'and' in programmers manner lazy behaviour, you > > will break > > > > some legacy code a vice versa. This change is impossible. > > You can be > > > > not agree with it. You can argue against it, but it is > > all what you > > > > can do with it. > > > if you go back a few posts, you'll see that i try to make it very > > > clear that nothing will be removed (at least not for the > > next few years). > > > > > > mats > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions > > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions From harveyd Sat Mar 15 19:27:16 2008 From: harveyd (Dale Harvey) Date: Sat, 15 Mar 2008 18:27:16 +0000 Subject: [erlang-questions] Erlang GUIs In-Reply-To: <1205605237.6473.14.camel@ubuntu-life-vm> References: <47D52E27.6060901@kreditor.se> <47D7923B.8080400@kreditor.se> <4d08db370803120637q1cabfd29ve8441056d53cd392@mail.gmail.com> <47D7E25D.30909@kreditor.se> <4d08db370803120828r78cd0c37xb14dc61c2306a96@mail.gmail.com> <47D7FC95.8040906@kreditor.se> <1205394063.20252.1.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> <110BA8ACEE682C479D0B008B6BE4AEB105E49EE7@esealmw107.eemea.ericsson.se> <005601c88621$38b88a40$891ea8c0@SSI.CORP> <1205605237.6473.14.camel@ubuntu-life-vm> Message-ID: I would certainly put a vote in for yaws / a server based application with a flash / javascript front end. Both flash and javascript have widget libraries that are at least as easy to use and powerful than their desktop counterparts. If you are planning to have a heavily customised interface i would suggest something like jquery / dojo / prototype. If you are planning on using a more familiar widget set then extjs or flex are probably better places to start looking. if you need more os intergration than traditional flash / js can do Adobe Air is another product to look at. (or the previously mentioned swing / wxwidgets) On 15/03/2008, Bob Cowdery wrote: > > David > > I've tried three approaches, all of which work well depending on what > you want to do. There are of course other approaches. > > wxErlang is an interface to the wxWidgets library and although it's > coverage is not 100% yet I've found it stable and good enough to write > reasonably complex GUI's. This is good if you want to stay entirely in > the Erlang world. > > Java and Swing using the jInterface library. This also works very well > if you don't mind straying away from Erlang and don't mind some code > bloat in the interfacing. > > Yaws and Erlyweb make a good pair but it depends on your interface > complexity and usability. You might actually end up with a good bit of > your ui code in java script using perhaps one of the Ajax libraries like > DoJo. > > Just my pennyworth. > > > - Bob > > > On Fri, 2008-03-14 at 17:17 -0500, David Mercer wrote: > > Speaking of which, what are the best ways of creating GUIs to interact > with > > Erlang? Gs? Run Yaws or Erlyweb or something and use the web > browser? I > > heard Joe once mention using Flash as the UI front end? > > > > What is the state of the art right now? > > > > Thanks. > > > > Cheers, > > > > David > > > > -----Original Message----- > > From: erlang-questions-bounces > > [mailto:erlang-questions-bounces] On Behalf Of Erik Reitsma > > Sent: Thursday, March 13, 2008 03:06 > > To: Bengt Kleberg > > Cc: Erlang mailing list > > Subject: Re: [erlang-questions] erlang sucks > > > > If you count libraries: after rewriting a GUI from iv to tcl I gave up > > when tcl was removed. I guess gs has been around long enough to consider > > it, but then again there are still GUI alternatives floating around, and > > I am afraid they will become better than gs and gs will be replaced. > > > > *Erik. > > > > > Out of interest: > > > Does anybody know of _anything_ that has been removed, ever? > > > > > > > > > bengt > > > > > > On Wed, 2008-03-12 at 16:53 +0100, Mats Cronqvist wrote: > > > > Hynek Vychodil wrote: > > > > > > > > > > > > > > > On Wed, Mar 12, 2008 at 3:02 PM, Mats Cronqvist > > > > > > > > wrote: > > > > > > > > > > or are you saying there is a need for several > > > 'and'? in that case i > > > > > disagree. > > > > > > > > > > ... > > > > > I think there is no way to change it, because if you > > > remove 'andalso' > > > > > and use 'and' in programmers manner lazy behaviour, you > > > will break > > > > > some legacy code a vice versa. This change is impossible. > > > You can be > > > > > not agree with it. You can argue against it, but it is > > > all what you > > > > > can do with it. > > > > if you go back a few posts, you'll see that i try to make it very > > > > clear that nothing will be removed (at least not for the > > > next few years). > > > > > > > > mats > > > > _______________________________________________ > > > > erlang-questions mailing list > > > > erlang-questions > > > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > > > _______________________________________________ > > > erlang-questions mailing list > > > erlang-questions > > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions > > http://www.erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions > http://www.erlang.org/mailman/listinfo/erlang-questions > -- * http://hypernumbers.com * http://arandomurl.com/ * http://www.flickr.com/photos/daleharvey/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.erlang.org/pipermail/erlang-questions/attachments/20080315/ea8cad50/attachment.html From buricchio Sat Mar 15 19:59:56 2008 From: buricchio (andrey-google) Date: Sat, 15 Mar 2008 20:59:56 +0200 Subject: [erlang-questions] How to the a ets table is exists or not ? Message-ID: <1722934013.20080315205956@gmail.com> You may use try..catch ... try ;;do_something with ets table, e.g. ets:update_counter ets:update_counter(mytable, mycounter, 1) catch error:badarg -> init_mytables() end. ... or more specific catch ... case (catch ets:update_counter(mytable, mycounter, 1)) of {'EXIT', {badarg, ...}} -> ... Cheers! From rvirding Sat Mar 15 21:15:37 2008 From: rvirding (Robert Virding) Date: Sat, 15 Mar 2008 21:15:37 +0100 Subject: [erlang-questions] regexp behaviour In-Reply-To: <20080315044414.8ED9E19DC20E@mail.wavenet.lk> References: <20080315044414.8ED9E19DC20E@mail.wavenet.lk> Message-ID: <3dbc6d1c0803151315j3b4f13daxb72316d2555cf55c@mail.gmail.com> Hi, If you quote the '&' character with \ then you will get a & in the out put string. So Str1 = "String with \\& character" N.B. you need an extra \ because it is in a string and the string parsing converts \\ into \ in the resultant string. Robert On 15/03/2008, shehan wrote: > > Hi all, > > > > Is the some way to stop the following behaviour of the "sub" function in > the "regexp" module > >