From francesco@REDACTED Mon Feb 1 10:13:59 2010 From: francesco@REDACTED (Francesco Cesarini (Erlang Solutions)) Date: Mon, 01 Feb 2010 09:13:59 +0000 Subject: Erjang - a JVM-based Erlang VM (London Erlang User Group Talk 4 Feb) Message-ID: <4B669B57.3050703@erlang-solutions.com> Hi all, Join us for London Erlang User Group meeting on Thursday, 4th February 2010. Our guest will be Kresten Krab Thorup, CTO of Trifork. Kresten will talk about Erjang - a JVM-based virtual machine for Erlang. That's a very controversial topic both in Erlang and Java communities - you cannot miss this talk! The meeting will be held in Erlang Solutions' meeting room on the 1st floor of the Fruit and Wool Exchange. For directions, visit our Contact page . Be there at 18.00 for an 18.30 start. In order to attend this free event, you have to register . Registering allows us to plan refreshments accordingly, provide security with a list of names and ensure we have enough space. Register here , as places are limited! More information on the event is here: http://www.erlang-solutions.com/events/2/entry/1131 As we usually do not announce these events on the Erlang Questions mailing list, if you are interested in these talks and based in the London area, subscribe to the Erlang London Yahoo gourps in the right column of the page: http://www.erlang-solutions.com/etc/usergroup/london Hope to see many new faces on Thursday! Francesco --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From rumata-estor@REDACTED Mon Feb 1 11:56:49 2010 From: rumata-estor@REDACTED (Dmitry Belayev) Date: Mon, 01 Feb 2010 13:56:49 +0300 Subject: This in parametrized module Message-ID: <4B66B371.20707@nm.ru> Hi, I have parametrized module(mymodule, [Param1, ..., ParamN]). I want to send this module with parameters somewhere where it's function will be called like this ThatModule:do_smth(). How can I get _this_ module with all parameters? I don't like to create new values like tuple by hands or use mymodule:new(Param1, ..., ParamN). And another question. Can I write my own new method? From magnus@REDACTED Mon Feb 1 13:53:53 2010 From: magnus@REDACTED (Magnus Henoch) Date: Mon, 01 Feb 2010 12:53:53 +0000 Subject: This in parametrized module In-Reply-To: <4B66B371.20707@nm.ru> (Dmitry Belayev's message of "Mon, 01 Feb 2010 13:56:49 +0300") References: <4B66B371.20707@nm.ru> Message-ID: <84ljfdyv4u.fsf@linux-b2a3.site> Dmitry Belayev writes: > Hi, I have parametrized module(mymodule, [Param1, ..., ParamN]). > I want to send this module with parameters somewhere where it's > function will be called like this ThatModule:do_smth(). > > How can I get _this_ module with all parameters? I don't like to > create new values like tuple by hands or use mymodule:new(Param1, ..., > ParamN). There is a magic variable called THIS: other_module:call_me(THIS). See section 4 of http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf . > And another question. Can I write my own new method? Yes, see slide 5 of http://www.erlang.se/euc/07/papers/1700Carlsson.pdf (which shows inheritance at the same time). Basically, write something like: -module(mymodule, [A, B]). -export([new/3]). new(X, Y, Z) -> instance(X, Y+Z). I.e., export a 'new' function with any arity, which calls the 'instance' function with the actual arity of your module. -- Magnus Henoch, magnus@REDACTED Erlang Solutions http://www.erlang-solutions.com/ --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From rumata-estor@REDACTED Mon Feb 1 14:41:44 2010 From: rumata-estor@REDACTED (Dmitry Belayev) Date: Mon, 01 Feb 2010 16:41:44 +0300 Subject: [erlang-questions] Re: This in parametrized module In-Reply-To: <84ljfdyv4u.fsf@linux-b2a3.site> References: <4B66B371.20707@nm.ru> <84ljfdyv4u.fsf@linux-b2a3.site> Message-ID: <4B66DA18.5090104@nm.ru> Wow. I see "inheritance" in erlang for the first time. Is it implemented already? Magnus Henoch wrote: > Dmitry Belayev writes: > > >> Hi, I have parametrized module(mymodule, [Param1, ..., ParamN]). >> I want to send this module with parameters somewhere where it's >> function will be called like this ThatModule:do_smth(). >> >> How can I get _this_ module with all parameters? I don't like to >> create new values like tuple by hands or use mymodule:new(Param1, ..., >> ParamN). >> > > There is a magic variable called THIS: > > other_module:call_me(THIS). > > See section 4 of > http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf . > > >> And another question. Can I write my own new method? >> > > Yes, see slide 5 of http://www.erlang.se/euc/07/papers/1700Carlsson.pdf > (which shows inheritance at the same time). Basically, write something > like: > > -module(mymodule, [A, B]). > > -export([new/3]). > > new(X, Y, Z) -> > instance(X, Y+Z). > > I.e., export a 'new' function with any arity, which calls the 'instance' > function with the actual arity of your module. > > From mononcqc@REDACTED Mon Feb 1 14:47:51 2010 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 1 Feb 2010 08:47:51 -0500 Subject: [erlang-questions] Re: This in parametrized module In-Reply-To: <4B66DA18.5090104@nm.ru> References: <4B66B371.20707@nm.ru> <84ljfdyv4u.fsf@linux-b2a3.site> <4B66DA18.5090104@nm.ru> Message-ID: <8b9ee55b1002010547m623b177p5d5ff05c725a942a@mail.gmail.com> Yes, see -extend(ModuleName). This will make it so any functions called of the form "YourModule:Function()" that are not part of your current module will be looked up into the extended module. This is not supported, as far as I know. On Mon, Feb 1, 2010 at 8:41 AM, Dmitry Belayev wrote: > Wow. I see "inheritance" in erlang for the first time. Is it implemented > already? > > > Magnus Henoch wrote: > >> Dmitry Belayev writes: >> >> >> >>> Hi, I have parametrized module(mymodule, [Param1, ..., ParamN]). >>> I want to send this module with parameters somewhere where it's >>> function will be called like this ThatModule:do_smth(). >>> >>> How can I get _this_ module with all parameters? I don't like to >>> create new values like tuple by hands or use mymodule:new(Param1, ..., >>> ParamN). >>> >>> >> >> There is a magic variable called THIS: >> >> other_module:call_me(THIS). >> >> See section 4 of >> http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf . >> >> >> >>> And another question. Can I write my own new method? >>> >>> >> >> Yes, see slide 5 of http://www.erlang.se/euc/07/papers/1700Carlsson.pdf >> (which shows inheritance at the same time). Basically, write something >> like: >> >> -module(mymodule, [A, B]). >> >> -export([new/3]). >> >> new(X, Y, Z) -> >> instance(X, Y+Z). >> >> I.e., export a 'new' function with any arity, which calls the 'instance' >> function with the actual arity of your module. >> >> >> > > > ________________________________________________________________ > erlang-questions mailing list. See http://www.erlang.org/faq.html > erlang-questions (at) erlang.org > > From dmercer@REDACTED Mon Feb 1 15:15:53 2010 From: dmercer@REDACTED (David Mercer) Date: Mon, 1 Feb 2010 08:15:53 -0600 Subject: [erlang-questions] Re: This in parametrized module In-Reply-To: <8b9ee55b1002010547m623b177p5d5ff05c725a942a@mail.gmail.com> References: <4B66B371.20707@nm.ru> <84ljfdyv4u.fsf@linux-b2a3.site> <4B66DA18.5090104@nm.ru> <8b9ee55b1002010547m623b177p5d5ff05c725a942a@mail.gmail.com> Message-ID: <6B62D13A634B4067AFD8CEFE72708ED2@SSI.CORP> > This is not supported, as far as I know. Are parameterized modules even supported? From mononcqc@REDACTED Mon Feb 1 15:37:16 2010 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 1 Feb 2010 09:37:16 -0500 Subject: [erlang-questions] Re: This in parametrized module In-Reply-To: <6B62D13A634B4067AFD8CEFE72708ED2@SSI.CORP> References: <4B66B371.20707@nm.ru> <84ljfdyv4u.fsf@linux-b2a3.site> <4B66DA18.5090104@nm.ru> <8b9ee55b1002010547m623b177p5d5ff05c725a942a@mail.gmail.com> <6B62D13A634B4067AFD8CEFE72708ED2@SSI.CORP> Message-ID: <8b9ee55b1002010637y5c65d26ao7dffe5c80057d742@mail.gmail.com> Nope, but they're a lot more common, being used in mochiweb and others. On Mon, Feb 1, 2010 at 9:15 AM, David Mercer wrote: > > This is not supported, as far as I know. > > Are parameterized modules even supported? > > > ________________________________________________________________ > erlang-questions mailing list. See http://www.erlang.org/faq.html > erlang-questions (at) erlang.org > > From alex.arnon@REDACTED Mon Feb 1 17:13:18 2010 From: alex.arnon@REDACTED (Alex Arnon) Date: Mon, 1 Feb 2010 18:13:18 +0200 Subject: [erlang-questions] Re: This in parametrized module In-Reply-To: <8b9ee55b1002010637y5c65d26ao7dffe5c80057d742@mail.gmail.com> References: <4B66B371.20707@nm.ru> <84ljfdyv4u.fsf@linux-b2a3.site> <4B66DA18.5090104@nm.ru> <8b9ee55b1002010547m623b177p5d5ff05c725a942a@mail.gmail.com> <6B62D13A634B4067AFD8CEFE72708ED2@SSI.CORP> <8b9ee55b1002010637y5c65d26ao7dffe5c80057d742@mail.gmail.com> Message-ID: <944da41d1002010813w4da478bblab12f6d7343ec427@mail.gmail.com> Indeed, it looks like their use is becoming common in high-profile applications. Beginning with what version are 'inherit' etc. usable? On Mon, Feb 1, 2010 at 4:37 PM, Fred Hebert wrote: > Nope, but they're a lot more common, being used in mochiweb and others. > > On Mon, Feb 1, 2010 at 9:15 AM, David Mercer wrote: > > > > This is not supported, as far as I know. > > > > Are parameterized modules even supported? > > > > > > ________________________________________________________________ > > erlang-questions mailing list. See http://www.erlang.org/faq.html > > erlang-questions (at) erlang.org > > > > > From rapsey@REDACTED Tue Feb 2 09:18:47 2010 From: rapsey@REDACTED (Rapsey) Date: Tue, 2 Feb 2010 09:18:47 +0100 Subject: [Erlyaws-list] Detailed guide? In-Reply-To: References: Message-ID: <97619b171002020018q2ec2f035mfc9b89df0134206e@mail.gmail.com> http://learnyousomeerlang.com/content http://www.erlang.org/doc/reference_manual/users_guide.html http://www.pragprog.com/titles/jaerlang/programming-erlang http://www.amazon.com/ERLANG-Programming-Francesco-Cesarini/dp/0596518188 I learned with Programming Erlang by Joe Armstrong. Sergej On Tue, Feb 2, 2010 at 8:55 AM, Kurtis Rainbolt-Greene < thinkwritemute@REDACTED> wrote: > I really want to use Erlang, but I haven't found a guide that can really > help me go from Beginner to Expert. Does such a guide/book exist? Would > there be a lot of want for such a guide/book? > > -- > Kurtis Rainbolt-Greene > 1-541-805-2263 > http://krainbolt-greene.selfip.net > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Erlyaws-list mailing list > Erlyaws-list@REDACTED > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > > From ulfn@REDACTED Tue Feb 2 12:04:10 2010 From: ulfn@REDACTED (Ulf Norell) Date: Tue, 2 Feb 2010 12:04:10 +0100 Subject: Output from programs started with open_port Message-ID: I'm using open_port to communicate with external programs, and I'm having some problems with the output from these programs. The output I'm interested in is mainly debug output so I'd prefer to have it echoed to the terminal. The problem is that on unixy systems (Linux/Mac) newlines are treated just as line feeds without carriage return and on Windows I'm not getting any output at all. Here's a simple example: % The Erlang code -module(simple). -compile(export_all). test() -> Port = open_port({spawn_executable, "./main"}, [{packet, 1}]), receive {Port, {data, [0]}} -> port_close(Port) end. // The external program #include int main (void) { fprintf(stderr, "hello\nworld\nHELLO\n\rWORLD\n\r"); write(1, "\1\0", 2); return 0; } On unixy system I get 1> simple:test(). hello world HELLO WORLD true and on Windows simply 1> simple:test(). true Having to add \r's when you have the source of the external program is a nuisance but not the end of the world, but in many cases I don't have the source code of the external program and in that case the output is pretty much useless without proper newlines. On Windows it even worse since I don't get any output at all. Is this a known issue, and is there anything I can do about it? / Ulf From tony@REDACTED Tue Feb 2 16:14:37 2010 From: tony@REDACTED (Tony Arcieri) Date: Tue, 2 Feb 2010 08:14:37 -0700 Subject: Erlang + LLVM Message-ID: Has there been any thought given to using LLVM as the execution backend for BEAM? BEAM is a register machine. LLVM is a register machine. Seems like it might be possible? -- Tony Arcieri Medioh! A Kudelski Brand From ulf.wiger@REDACTED Tue Feb 2 17:06:00 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 02 Feb 2010 17:06:00 +0100 Subject: [erlang-questions] Erlang + LLVM In-Reply-To: References: Message-ID: <4B684D68.1070204@erlang-solutions.com> Tony Arcieri wrote: > Has there been any thought given to using LLVM as the execution backend for > BEAM? BEAM is a register machine. LLVM is a register machine. Seems like > it might be possible? > It does indeed. http://old.nabble.com/benchmarks-llvm-vs-gcc-tt18837645.html#a18837645 (I have no more info than that, though.) BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From g9414002.pccu.edu.tw@REDACTED Tue Feb 2 18:01:04 2010 From: g9414002.pccu.edu.tw@REDACTED (=?UTF-8?B?6buD6ICA6LOiIChZYXUtSHNpZW4gSHVhbmcp?=) Date: Wed, 3 Feb 2010 01:01:04 +0800 Subject: [erlang-questions] Output from programs started with open_port In-Reply-To: References: Message-ID: Hi, Ulf. The first message sent out from the C program is fed in stderr and would not be caught by the Erlang program. In unixy system the "hello world ..." string is printed when the Erlang process call and execute the C program, while the later one puts those messages in stderr as representing an error message. And in Windows those error messages are not showed when the C program puts them into stderr. I think that the Erlang implementation in Windows does not open as port as direct executing it. To execute you codes in Windows, I've modified them with another open_port statement: Port = open_port({spawn, "main.exe"}, [{packet,1}]), instead of the original one, Port = open_port({spawn_executable, "./main"}, [{packet, 1}]), and I think that it is different between open_port with spawn and one with spawn_executable. Do you agree with me? On Tue, Feb 2, 2010 at 7:04 PM, Ulf Norell wrote: > I'm using open_port to communicate with external programs, and I'm having > some problems with the output from these programs. The output I'm > interested > in is mainly debug output so I'd prefer to have it echoed to the terminal. > The problem is that on unixy systems (Linux/Mac) newlines are treated just > as line feeds without carriage return and on Windows I'm not getting any > output at all. > > Here's a simple example: > > % The Erlang code > -module(simple). > > -compile(export_all). > > test() -> > Port = open_port({spawn_executable, "./main"}, [{packet, 1}]), > receive > {Port, {data, [0]}} -> > port_close(Port) > end. > > // The external program > #include > > int main (void) > { > fprintf(stderr, "hello\nworld\nHELLO\n\rWORLD\n\r"); > write(1, "\1\0", 2); > return 0; > } > > On unixy system I get > > 1> simple:test(). > hello > world > HELLO > WORLD > true > > and on Windows simply > > 1> simple:test(). > true > > Having to add \r's when you have the source of the external program is a > nuisance but not the end of the world, but in many cases I don't have the > source code of the external program and in that case the output is pretty > much useless without proper newlines. On Windows it even worse since I > don't > get any output at all. > > Is this a known issue, and is there anything I can do about it? > > / Ulf > From tony@REDACTED Tue Feb 2 18:12:37 2010 From: tony@REDACTED (Tony Arcieri) Date: Tue, 2 Feb 2010 10:12:37 -0700 Subject: [erlang-questions] Erlang + LLVM In-Reply-To: <4B684D68.1070204@erlang-solutions.com> References: <4B684D68.1070204@erlang-solutions.com> Message-ID: On Tue, Feb 2, 2010 at 9:06 AM, Ulf Wiger wrote: > It does indeed. > > http://old.nabble.com/benchmarks-llvm-vs-gcc-tt18837645.html#a18837645 > > (I have no more info than that, though.) > This is a bit different than what I was proposing. This is using LLVM as the backend of the C compiler used to build the C source code of the Erlang interpreter. I am suggesting LLVM could be used to compile BEAM bytecode to native code, enabling faster execution. I'm aware HiPE already offers native code compilation. -- Tony Arcieri Medioh! A Kudelski Brand From hynek@REDACTED Tue Feb 2 18:48:54 2010 From: hynek@REDACTED (Hynek Vychodil) Date: Tue, 2 Feb 2010 18:48:54 +0100 Subject: [erlang-questions] Integer nth-root (Re: [erlang-questions] Integer square root) In-Reply-To: <20100126054401.GA50849@k2r.org> References: <201001211340.11272.clist@uah.es> <8E1F9D5A-C8D5-4F2D-AD0D-294069B6D5E6@cs.otago.ac.nz> <201001231101.30788.clist@uah.es> <53CA7566-8AF7-40CB-97F7-D5AC6F616990@cs.otago.ac.nz> <73BF5BD8-2DBB-44E3-BD45-C658B4059206@cs.otago.ac.nz> <20100126012647.GA46364@k2r.org> <20100126051648.GA50404@k2r.org> <20100126054401.GA50849@k2r.org> Message-ID: <4d08db371002020948q49ec3e01j34399c0b79e7a656@mail.gmail.com> Numeric mathematic is not as simple as seems at first sight. Rounding errors can lead to numeric instability. Try bignum_root:root(3,2) for example. There is little bit improved version: http://gist.github.com/292750 On Tue, Jan 26, 2010 at 6:44 AM, Kenji Rikitake wrote: > http://gist.github.com/286576 > for the GitHub users. > > Kenji Rikitake > >> %% This is a quick hack of code for Integer nth-root in Erlang. >> >> %% Power function (X ^ Y) and root function (X ^ (1/Y)) for >> %% integers in Erlang >> %% by Kenji Rikitake 26-JAN-2010 >> %% Distributed under MIT license at the end of the source code. > > ________________________________________________________________ > erlang-questions mailing list. See http://www.erlang.org/faq.html > erlang-questions (at) erlang.org > > -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero! Try GoodData now for free: www.gooddata.com From kenji.rikitake@REDACTED Wed Feb 3 00:26:05 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 3 Feb 2010 08:26:05 +0900 Subject: [erlang-questions] Integer nth-root (Re: [erlang-questions] Integer square root) In-Reply-To: <4d08db371002020948q49ec3e01j34399c0b79e7a656@mail.gmail.com> References: <201001211340.11272.clist@uah.es> <8E1F9D5A-C8D5-4F2D-AD0D-294069B6D5E6@cs.otago.ac.nz> <201001231101.30788.clist@uah.es> <53CA7566-8AF7-40CB-97F7-D5AC6F616990@cs.otago.ac.nz> <73BF5BD8-2DBB-44E3-BD45-C658B4059206@cs.otago.ac.nz> <20100126012647.GA46364@k2r.org> <20100126051648.GA50404@k2r.org> <20100126054401.GA50849@k2r.org> <4d08db371002020948q49ec3e01j34399c0b79e7a656@mail.gmail.com> Message-ID: <20100202232605.GA12219@k2r.org> The newer version has a math:log/1 out-of-range problem when handling a very large number. I'll fix mine soon. Thanks for the fix anyway, Hynek. I also needed to find out the convergence decision issue. Kenji Rikitake In the message <4d08db371002020948q49ec3e01j34399c0b79e7a656@REDACTED> dated Tue, Feb 02, 2010 at 06:48:30PM +0100, Hynek Vychodil writes: > Numeric mathematic is not as simple as seems at first sight. Rounding > errors can lead to numeric instability. Try bignum_root:root(3,2) for > example. > > There is little bit improved version: > http://gist.github.com/292750 From kenji.rikitake@REDACTED Wed Feb 3 01:46:41 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 3 Feb 2010 09:46:41 +0900 Subject: [erlang-questions] Integer nth-root (Re: [erlang-questions] Integer square root) In-Reply-To: <20100202232605.GA12219@k2r.org> References: <201001211340.11272.clist@uah.es> <8E1F9D5A-C8D5-4F2D-AD0D-294069B6D5E6@cs.otago.ac.nz> <201001231101.30788.clist@uah.es> <53CA7566-8AF7-40CB-97F7-D5AC6F616990@cs.otago.ac.nz> <73BF5BD8-2DBB-44E3-BD45-C658B4059206@cs.otago.ac.nz> <20100126012647.GA46364@k2r.org> <20100126051648.GA50404@k2r.org> <20100126054401.GA50849@k2r.org> <4d08db371002020948q49ec3e01j34399c0b79e7a656@mail.gmail.com> <20100202232605.GA12219@k2r.org> Message-ID: <20100203004641.GA13268@k2r.org> New version of bignum_root.erl http://gist.github.com/293169 (merged code of root estimation for very large integers) Thanks Hynek. Regards, Kenji Rikitake From james.hague@REDACTED Wed Feb 3 03:29:04 2010 From: james.hague@REDACTED (James Hague) Date: Tue, 2 Feb 2010 20:29:04 -0600 Subject: [erlang-questions] Erlang + LLVM In-Reply-To: References: <4B684D68.1070204@erlang-solutions.com> Message-ID: > I am suggesting LLVM could be used to compile BEAM bytecode to native code, > enabling faster execution. ?I'm aware HiPE already offers native code > compilation. Another odd idea is to use LLVM to generate the main loop of the BEAM interpreter itself. The current interpreter is reliant on hacky gcc extensions (well okay, it works without them but is much slower). Years ago I wanted to rewrite the BEAM main loop directly in x86 assembly to see if an optimization opportunities presented themselves--what a pain! James From max.lapshin@REDACTED Wed Feb 3 06:33:00 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 3 Feb 2010 08:33:00 +0300 Subject: [erlang-questions] Erlang + LLVM In-Reply-To: References: <4B684D68.1070204@erlang-solutions.com> Message-ID: It will be rather easy to test, how BEAM is compiled with LLVM, especially after Apple finishes migration from gcc to CLang. But Tony asked other thing: it is possible to transform erlang bytecode to llvm instructions and let LLVM compile, not HiPE? From kostis@REDACTED Wed Feb 3 09:47:58 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 03 Feb 2010 10:47:58 +0200 Subject: [erlang-questions] Erlang + LLVM In-Reply-To: References: <4B684D68.1070204@erlang-solutions.com> Message-ID: <4B69383E.8070002@cs.ntua.gr> Tony Arcieri wrote: > On Tue, Feb 2, 2010 at 9:06 AM, Ulf Wiger wrote: > >> It does indeed. >> >> http://old.nabble.com/benchmarks-llvm-vs-gcc-tt18837645.html#a18837645 >> >> (I have no more info than that, though.) >> > > This is a bit different than what I was proposing. This is using LLVM as > the backend of the C compiler used to build the C source code of the Erlang > interpreter. > > I am suggesting LLVM could be used to compile BEAM bytecode to native code, > enabling faster execution. I'm aware HiPE already offers native code > compilation. To compile to native code, the HiPE compiler uses various internal representations which go roughly as follows: BEAM bytecode -> HiPE Icode -> HiPE RTL -> native (x86, x86_64, ...) Anyway, about one and a half years ago, I gave to a group of two graduate students a project to map the HiPE's RTL to LLVM's RTL with the aim to use the LLVM backend optimizations and see how LLVM performs compared to HiPE. The project never matured to the point that we could get measurements, so I do not have something very concrete to report here, other than some thoughts. If you are about to do this sort of thing, you have to ask yourself the following questions: - Why am I doing this? Is it just out of curiosity to see what sort of speedup I can get, or do I want to do it for real? In the latter case: - Is the performance from BEAM bytecode not good enough? Have I used HiPE on my code and I did not get a decent speedup? Do I have good reasons to believe that the speedup with LLVM will be (considerably) better in big applications? - What is the design I want? Do I want to be able to just native code produced by LLVM or should I be able to load and run BEAM code too? - Who is responsible for memory management? Do I use the same memory organization for processes as the current Erlang/OTP runtime system? - Do I maintain Erlang semantics as far as loading/reloading code of modules is concerned or not? - How is the scheduling of Erlang processes performed? Do I want a single-threaded or a multi-threaded implementation? Note that the devil is not just in the details, but in major decisions. The BEAM bytecode is not really self-contained. A lot of issues are handled by the BEAM loader, which performs mucho magic, and/or appear in parts of the runtime system of Erlang/OTP. Understanding and foreseeing these issues is the tricky part... Kostis From schramm.ingo@REDACTED Wed Feb 3 13:30:29 2010 From: schramm.ingo@REDACTED (ingo.schramm) Date: Wed, 3 Feb 2010 04:30:29 -0800 (PST) Subject: jinterface: mbox==thread or thread(mbox)? Message-ID: <71730025-15ca-4989-bf1c-1c492a7ba48c@u41g2000yqe.googlegroups.com> Writing a bridge from Erlang to neo4j (nerlo) I come around the problem of threading at the Java side. My question is: does a new OtpMbox run in a separate thread already (similar to spawn()) or do I have to create a new thread containing a new OtpMbox? Is anything known about problems in conjunction with jinterface, multithreading and multiple mboxes? Cheers, Ingo From g9414002.pccu.edu.tw@REDACTED Wed Feb 3 17:44:03 2010 From: g9414002.pccu.edu.tw@REDACTED (=?UTF-8?B?6buD6ICA6LOiIChZYXUtSHNpZW4gSHVhbmcp?=) Date: Thu, 4 Feb 2010 00:44:03 +0800 Subject: [erlang-questions] Output from programs started with open_port In-Reply-To: References: Message-ID: I'm more familiar with {line, N} than {packet, 1}. And I think that it's no matter whether it's {packet, 1} or not. The problem you mentioned is that when executing C programs it need redirect the error channel to the normal standard output channel. However, for Erlang port, there is only one channel called "port," and normal messages and error messages are separated by using some customized structure within data. Erlang client must known how to separate different messages in the data. Besides, if an external C process is linked by the Erlang process, some errors will be propagated to the Erlang process. Thus instructions for writing them into the error channel, stderr, can be omitted. 2010/2/3 Samuel Rivas > Hi, > > I have no idea about how to make it work for windows. For linux we had > the carriage return problem also, but we just went practical and > redirected the error outuput to a file and used tail -f in other > terminal. Note that if you can't control the binaries you execute > there is a chance that they output to stdio as well, confusing your > port communication (I see you are using {packet, 1} which means that > the process must write to stdio using a fixed protocol). > > > > 2010/2/2 ??? (Yau-Hsien Huang) : > > Hi, Ulf. > > > > The first message sent out from the C program is fed in stderr and would > not > > be caught by the Erlang program. In unixy system the "hello world ..." > > string is printed when the Erlang process call and execute the C program, > > while the later one puts those messages in stderr as representing an > error > > message. And in Windows those error messages are not showed when the C > > program puts them into stderr. > > > > I think that the Erlang implementation in Windows does not open as port > as > > direct executing it. To execute you codes in Windows, I've modified them > > with another open_port statement: > > > > Port = open_port({spawn, "main.exe"}, [{packet,1}]), > > > > instead of the original one, > > > > Port = open_port({spawn_executable, "./main"}, [{packet, 1}]), > > > > and I think that it is different between open_port with spawn and one > with > > spawn_executable. Do you agree with me? > > > > > > On Tue, Feb 2, 2010 at 7:04 PM, Ulf Norell wrote: > > > >> I'm using open_port to communicate with external programs, and I'm > having > >> some problems with the output from these programs. The output I'm > >> interested > >> in is mainly debug output so I'd prefer to have it echoed to the > terminal. > >> The problem is that on unixy systems (Linux/Mac) newlines are treated > just > >> as line feeds without carriage return and on Windows I'm not getting any > >> output at all. > >> > >> Here's a simple example: > >> > >> % The Erlang code > >> -module(simple). > >> > >> -compile(export_all). > >> > >> test() -> > >> Port = open_port({spawn_executable, "./main"}, [{packet, 1}]), > >> receive > >> {Port, {data, [0]}} -> > >> port_close(Port) > >> end. > >> > >> // The external program > >> #include > >> > >> int main (void) > >> { > >> fprintf(stderr, "hello\nworld\nHELLO\n\rWORLD\n\r"); > >> write(1, "\1\0", 2); > >> return 0; > >> } > >> > >> On unixy system I get > >> > >> 1> simple:test(). > >> hello > >> world > >> HELLO > >> WORLD > >> true > >> > >> and on Windows simply > >> > >> 1> simple:test(). > >> true > >> > >> Having to add \r's when you have the source of the external program is a > >> nuisance but not the end of the world, but in many cases I don't have > the > >> source code of the external program and in that case the output is > pretty > >> much useless without proper newlines. On Windows it even worse since I > >> don't > >> get any output at all. > >> > >> Is this a known issue, and is there anything I can do about it? > >> > >> / Ulf > >> > > > > > > -- > Samuel > From clist@REDACTED Wed Feb 3 22:19:49 2010 From: clist@REDACTED (Angel) Date: Wed, 3 Feb 2010 22:19:49 +0100 Subject: [erlang-questions] packet sniffing In-Reply-To: <9b08084c1001260552w294228e1q9869fe65308bc94c@mail.gmail.com> References: <9b08084c1001260552w294228e1q9869fe65308bc94c@mail.gmail.com> Message-ID: <201002032219.49601.clist@uah.es> On Martes, 26 de Enero de 2010 14:52:00 Joe Armstrong escribi?: > Can I use the standard socket libraries to sniff all packets from an > interface? > > I have a C driver that does > > rawsock = socket(PF_PACKET, SOCK_RAW, htons(p ETH_P_IP)) > > and then binds rawsock to "eth0" > > Can I do the equivalent directly in Erlang and throw away my C code? > > Also can I bind a listening socket to an arbitrary interface? > > > /Joe > Hi i came across this page: http://xumingyong.javaeye.com/blog/585229 He is using erl_nif Now he is doing a new sniffer on XP.... /Angel From gleber.p@REDACTED Wed Feb 3 22:32:12 2010 From: gleber.p@REDACTED (Gleb Peregud) Date: Wed, 3 Feb 2010 22:32:12 +0100 Subject: [erlang-questions] packet sniffing In-Reply-To: <201002032219.49601.clist@uah.es> References: <9b08084c1001260552w294228e1q9869fe65308bc94c@mail.gmail.com> <201002032219.49601.clist@uah.es> Message-ID: <14f0e3621002031332k7d5e6bd4gc233835b4f5d0546@mail.gmail.com> On Wed, Feb 3, 2010 at 22:19, Angel wrote: > Hi i came across this page: > > http://xumingyong.javaeye.com/blog/585229 > > He is using erl_nif This solution looks very flawed, since it employs busy waiting on capture/0. AFAIK right now there is no way to implement anything asynchronous/event-based/callback-based using NIFs, so they are not really usable for this purpose. Please correct me if I'm wrong From michael.santos@REDACTED Wed Feb 3 23:11:51 2010 From: michael.santos@REDACTED (Michael Santos) Date: Wed, 3 Feb 2010 17:11:51 -0500 Subject: [erlang-questions] packet sniffing In-Reply-To: <14f0e3621002031332k7d5e6bd4gc233835b4f5d0546@mail.gmail.com> References: <9b08084c1001260552w294228e1q9869fe65308bc94c@mail.gmail.com> <201002032219.49601.clist@uah.es> <14f0e3621002031332k7d5e6bd4gc233835b4f5d0546@mail.gmail.com> Message-ID: <20100203221151.GA19171@ecn.lan> On Wed, Feb 03, 2010 at 10:32:12PM +0100, Gleb Peregud wrote: > On Wed, Feb 3, 2010 at 22:19, Angel wrote: > > Hi i came across this page: > > > > http://xumingyong.javaeye.com/blog/585229 > > > > He is using erl_nif > > This solution looks very flawed, since it employs busy waiting on > capture/0. AFAIK right now there is no way to implement anything > asynchronous/event-based/callback-based using NIFs, so they are not > really usable for this purpose. Please correct me if I'm wrong There's also a buffer overflow in opendevice/1, which is sort of unsettling since erlang has to run as root for this to work. But, still, the idea is cool for playing around with. If a short timeout were used in pcap_open_live(), an erlang process could call capture/0 to poll the pcap device. For completeness, I have another erlang interface for pcap on github: http://github.com/msantos/epcap epcap runs as a port. From rickard@REDACTED Thu Feb 4 03:27:01 2010 From: rickard@REDACTED (Rickard Green) Date: Thu, 4 Feb 2010 03:27:01 +0100 Subject: [erlang-questions] Problems cross compiling: eheap_alloc: Cannot reallocate 3480006320 bytes of memory In-Reply-To: References: Message-ID: <10d7e35f1002031827r4ca30cbco39fbd488b554a799@mail.gmail.com> Current cross compiling support has lots of issues. I'd recommend that you wait for the R13B04 release if you want to cross compile Erlang/OTP. The upcoming R13B04 release will have much better support for cross compiling. I've just committed a bunch of cross fixes in the r13b04 development branch which are available at (ccase/r13b04_dev branch). If you want to try it out, have a look at the xcomp/README since lots of things have changed regarding cross compiling since R13B03. If you get it working with r13b04_dev, the configure results from r13b04_dev may give you a hint about what is wrong with the R13B03 configuration. However, I'd still recommend that you wait for the R13B04 release. Regards, Rickard Green, Erlang/OTP, Ericsson AB. 2010/1/29 Winston Smith : > Trying to run a cross compiled version of R13B03 on an AVR32-Linux > system (NGW100/buildroot-2.3.0) I get the following: > > /home/avr32 # erl > > Crash dump was written to: erl_crash.dump > eheap_alloc: Cannot reallocate 3480006320 bytes of memory (of type "heap"). > Aborted > > > I've had this working before (I think with R13B01) but I've since > upgraded my build host from Ubuntu 9.04 to 9.10. I actually had this > same issue originally, and I somehow solved it, but I can't for the > life of me remember what I did. I am setting up an xconf file with > the proper values for size_t, off_t, big endian etc; in fact I based > my build script on Brian Zhou's script for building Erlang on NSLU2 > Linux: > > http://svn.nslu2-linux.org/svnroot/optware/trunk/make/erlang.mk > > Any thoughts on where to start debugging/diagnosing this? (the > embedded gdb doesn't work) Is the erl_crash.dump useful (and how do I > interpret it!)? > > Many thanks in advance! > > ________________________________________________________________ > erlang-questions mailing list. See http://www.erlang.org/faq.html > erlang-questions (at) erlang.org > > From hynek@REDACTED Thu Feb 4 11:25:30 2010 From: hynek@REDACTED (Hynek Vychodil) Date: Thu, 4 Feb 2010 11:25:30 +0100 Subject: [erlang-questions] Re: sending a json body with http:request In-Reply-To: References: <966030.96419.qm@web112607.mail.gq1.yahoo.com> <872382.78291.qm@web112616.mail.gq1.yahoo.com> Message-ID: <4d08db371002040225o4957a84w4ea8932a2b1f02c1@mail.gmail.com> I think http:request should accept iolist and you don't need neither binary_to_list neither iolist_to_binary. On Fri, Jan 29, 2010 at 9:56 AM, Tim Fletcher wrote: >> I've tried: >> binary_to_list(iolist_to_binary(mochijson2:encode(Data))) >> >> It works but there is probably a better way. > > The http request body can be a string or a binary, so no need to call > binary_to_list. > > ________________________________________________________________ > erlang-questions mailing list. See http://www.erlang.org/faq.html > erlang-questions (at) erlang.org > > -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero! Try GoodData now for free: www.gooddata.com From ulf.wiger@REDACTED Thu Feb 4 11:54:06 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 04 Feb 2010 11:54:06 +0100 Subject: unsplit - resolving mnesia inconsistencies Message-ID: <4B6AA74E.1030802@erlang-solutions.com> I have had some modest success with a prototype to resolve netsplits in Mnesia. I pushed the code to Github: http://github.com/uwiger/unsplit I think there are still some nasty corner cases that need resolving, and I'm not convinced that they can be solved without some added functionality in Mnesia. Approach: An application, unsplit, starts and subscribes to mnesia system events. When the unsplit_server receives an event signaling that the database is inconsistent ({inconsistent_database, Context, Node}), it enters a critical section (using global:trans/3) and tries to resolve the inconsistency. The critical section is needed since both sides will detect the condition at roughly the same time*. Note that at this time, the two erlang nodes are in contact, but mnesia has aborted the attempt to merge the two nodes, so each mnesia instance considers the other side down. * I have on occasion seen only one printout of the "partitioned network" message, and once or twice the contition has gone undetected if I disconnect and reconnect very quickly. This bothers me, but I have not been able to reproduce or analyse it. When entering the critical section, it checks whether the other node is in mnesia's 'running_db_nodes' list. If so, the other side has already resolved the inconsistency and nothing more needs to be done. Otherwise, it checks which tables have copies on both nodes and proceeds to merge them. Table locks are taken on all affected tables, but the actual reading and writing of data are dirty. The reasons for this are: 1. Obviously, locks must be taken, since we don't want others to write to the tables during the process. 2. When reading the data, we have to read the two separate copies. The transaction read will not allow this, so we have to read the remote copy through rpc:call(), which means it has to be dirty. 3. I was hoping to have a proxy process on the other side that locks its copy, then does the reading and writing before we connect the two mnesia nodes. However, mnesia didn't like this at all, when told to connect the nodes and commit. The actual connect of the two sides is accomplished using (undocumented) mnesia_monitor:connect_nodes([OtherNode]). Currently, I do this before I lock the tables; I believe this creates a small race condition, but haven't found any other way to do it. For each table, an 'unsplit_method' can be defined. The default is {unsplit_lib, no_action, []}, which is probably seldom a good choice. I have written a method called {unsplit_lib, last_modified, []}, which is equivalent to {unsplit_lib, last_version, [modified]}, simply comparing the value of the 'modified' attribute of each two records with the same key (this particular method won't work for bags) and picking the latest one - aborting if the objects are different, but the 'modified' value are the same. For more sophisticated callbacks, I suggest scavenging the riak source code for Lamport clocks, Merkle trees etc. Obviously, you also need to plan the record representation, e.g. if you want to be able to hold multiple versions of the same object, like riak does. Some test commands are in the file commands.txt. I don't think the dist_auto_connect once setting should be needed, but it sure makes it easier during testing. Everything is still very rough at the edges, but I would like some feedback before continuing - not least from the Mnesia maintainers. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From magnus@REDACTED Thu Feb 4 12:18:06 2010 From: magnus@REDACTED (Magnus Henoch) Date: Thu, 04 Feb 2010 11:18:06 +0000 Subject: sending a json body with http:request In-Reply-To: <4d08db371002040225o4957a84w4ea8932a2b1f02c1@mail.gmail.com> (Hynek Vychodil's message of "Thu, 4 Feb 2010 11:25:30 +0100") References: <966030.96419.qm@web112607.mail.gq1.yahoo.com> <872382.78291.qm@web112616.mail.gq1.yahoo.com> <4d08db371002040225o4957a84w4ea8932a2b1f02c1@mail.gmail.com> Message-ID: <84tytxntap.fsf@linux-b2a3.site> Hynek Vychodil writes: >>> The http request body can be a string or a binary, so no need to call >>> binary_to_list. >>> > > I think http:request should accept iolist and you don't need neither > binary_to_list neither iolist_to_binary. You'd think so :) In the hope of saving someone else the time I spent debugging this (probably more than once), I'll let you know that http:request accepts only flat strings and binaries, _not_ iolists. It seems to work fine, and the data is actually sent, but the Content-Length header is calculated using length/1, not iolist_size/1, so the server will not see the entire body. (For example, length([$f, $o, $o, "bar"]) is 4, while iolist_size of the same is 6. You want the latter.) Generally, the inets http client increases the amount of suffering in the world. You'd be better off using lhttpc instead: http://bitbucket.org/etc/lhttpc/wiki/Home -- Magnus Henoch, magnus@REDACTED Erlang Solutions http://www.erlang-solutions.com/ --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From twoggle@REDACTED Thu Feb 4 12:26:07 2010 From: twoggle@REDACTED (Tim Fletcher) Date: Thu, 4 Feb 2010 03:26:07 -0800 (PST) Subject: sending a json body with http:request In-Reply-To: <84tytxntap.fsf@linux-b2a3.site> References: <966030.96419.qm@web112607.mail.gq1.yahoo.com> <872382.78291.qm@web112616.mail.gq1.yahoo.com> <4d08db371002040225o4957a84w4ea8932a2b1f02c1@mail.gmail.com> <84tytxntap.fsf@linux-b2a3.site> Message-ID: > You'd think so :) In the hope of saving someone else the time I spent > debugging this (probably more than once), I'll let you know that > http:request accepts only flat strings and binaries, _not_ iolists. Yes, and you don't even need to debug it or check the source to verify; just check the type definitions in the docs: http://erlang.org/doc/man/http.html#id2275333 :) From kdronnqvist@REDACTED Thu Feb 4 12:27:24 2010 From: kdronnqvist@REDACTED (=?ISO-8859-1?Q?Daniel_R=F6nnqvist?=) Date: Thu, 4 Feb 2010 12:27:24 +0100 Subject: Unique atom with make_ref()? Message-ID: <65691fa01002040327q26b574e9h2f3c0ca5162a1539@mail.gmail.com> Hello, Why sholdn't I use erlang:ref_to_list/1 in application programs? As it says here: http://erlang.org/doc/man/erlang.html#erlang:ref_to_list-1 Let's say that I wanted to create a unique atom, isn't this a good way? list_to_atom(erlang:ref_to_list(make_ref())) BR, Daniel R?nnqvist From andrewmmc@REDACTED Thu Feb 4 13:23:41 2010 From: andrewmmc@REDACTED (andrew mmc) Date: Thu, 4 Feb 2010 13:23:41 +0100 Subject: Mnesia table type change Message-ID: Hello, What is the easiest way to change a table type with a large number of records from ordered set to set? Thanks in advance! Andrew From seancribbs@REDACTED Thu Feb 4 13:29:02 2010 From: seancribbs@REDACTED (Sean Cribbs) Date: Thu, 04 Feb 2010 07:29:02 -0500 Subject: [erlang-questions] Unique atom with make_ref()? In-Reply-To: <65691fa01002040327q26b574e9h2f3c0ca5162a1539@mail.gmail.com> References: <65691fa01002040327q26b574e9h2f3c0ca5162a1539@mail.gmail.com> Message-ID: <4B6ABD8E.5000602@gmail.com> The primary reason you wouldn't want to create atoms dynamically is that they are not garbage collected. If an attacker knows you do this, it should become pretty obvious how to take down your application. I think it's reasonable to use a ref as a unique identifier, but I'd reserve atoms for symbolic names. Sean On 2/4/10 6:27 AM, Daniel R?nnqvist wrote: > Hello, > > Why sholdn't I use erlang:ref_to_list/1 in application programs? As it > says here: > > http://erlang.org/doc/man/erlang.html#erlang:ref_to_list-1 > > Let's say that I wanted to create a unique atom, isn't this a good way? > > list_to_atom(erlang:ref_to_list(make_ref())) > > BR, > Daniel R?nnqvist > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From max.lapshin@REDACTED Thu Feb 4 13:43:14 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Thu, 4 Feb 2010 15:43:14 +0300 Subject: [erlang-questions] Unique atom with make_ref()? In-Reply-To: <4B6ABD8E.5000602@gmail.com> References: <65691fa01002040327q26b574e9h2f3c0ca5162a1539@mail.gmail.com> <4B6ABD8E.5000602@gmail.com> Message-ID: For example, you may use not blabla143, but {blabla, Ref} as an identifier. From seancribbs@REDACTED Thu Feb 4 14:01:55 2010 From: seancribbs@REDACTED (Sean Cribbs) Date: Thu, 04 Feb 2010 08:01:55 -0500 Subject: [erlang-questions] Unique atom with make_ref()? In-Reply-To: References: <65691fa01002040327q26b574e9h2f3c0ca5162a1539@mail.gmail.com> <4B6ABD8E.5000602@gmail.com> Message-ID: <4B6AC543.9000303@gmail.com> Yes, but I still wouldn't create that blabla atom at runtime using list_to_atom (list_to_existing_atom would be ok). The latter seems like a reasonable unique identifier, however. On 2/4/10 7:43 AM, Max Lapshin wrote: > For example, you may use not blabla143, but {blabla, Ref} as an identifier. > > From chandrashekhar.mullaparthi@REDACTED Thu Feb 4 14:58:56 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Thu, 4 Feb 2010 13:58:56 +0000 Subject: [erlang-questions] Mnesia table type change In-Reply-To: References: Message-ID: On 4 February 2010 12:23, andrew mmc wrote: > Hello, > > What is the easiest way to change a table type with a large number of > records from ordered set to set? > > Backup db Delete table Recreate table with correct type Traverse backup and reinsert records into table If the table is very big, create the table as ram_copies first and once you've populated all your entries, change table type to disc_copies. cheers Chandru From ulf.wiger@REDACTED Thu Feb 4 17:59:33 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 04 Feb 2010 17:59:33 +0100 Subject: [erlang-questions] unsplit - resolving mnesia inconsistencies In-Reply-To: <4B6AA74E.1030802@erlang-solutions.com> References: <4B6AA74E.1030802@erlang-solutions.com> Message-ID: <4B6AFCF5.5080100@erlang-solutions.com> ...no longer using an un-patched mnesia. :-/ http://github.com/uwiger/otp/tree/mnesia_merge I made a fairly small change to mnesia_schema.erl and mnesia_monitor.erl, so that I could pass a wrapper to the schema_merge() function and give as extra argument to it which tables besides 'schema' that it should lock. mnesia_controller:connect_nodes( [NodeB], fun(MergeF) -> case MergeF(TabsAndNodes) of {merged,_,_} = Res -> show_locks(NodeB), %% For now, assume that we have merged with the right %% node, and not with others that could also be %% consistent (mnesia gurus, how does this work?) io:fwrite("stitching: ~p~n", [TabMethods]), stitch_tabs(TabMethods, NodeB), Res; Other -> Other end end). MergeF is the fun given by mnesia_schema: merge_schema(UserFun) -> schema_transaction(fun() -> UserFun(fun(Arg) -> do_merge_schema(Arg) end) end). Running this, I of course discovered that you still have to use dirty updates of the separate copies, since replication is not yet enabled for the nodes being merged. Here's an extract from my small test run: + + + + + inconsistency. Context = running_partitioned_network; Node = n2@REDACTED have lock... nodes_of(test) = [n1@REDACTED,n2@REDACTED] Affected tabs = [test] Methods = [{test,{unsplit_lib,last_modified,[]}}] Held locks = {[[{{test,'______WHOLETABLE_____'},write,{tid,68,<0.117.0>}}, {{schema,'______WHOLETABLE_____'},write,{tid,68,<0.117.0>}}], [{{test,'______WHOLETABLE_____'},write,{tid,68,<0.117.0>}}, {{schema,'______WHOLETABLE_____'},write,{tid,68,<0.117.0>}}]], []} stitching: [{test,{unsplit_lib,last_modified,[]}}] do_stitch({test,{unsplit_lib,last_modified,[]}}, n2@REDACTED). Calling unsplit_lib:last_modified(init, [test,[key,modified,value]])Starting merge of test ([key,modified,value]) -> {ok,{test,3}} Calling unsplit_lib:last_modified([{test,1,{1265,301600,551309},a}], [{test,1,{1265,301600,551309},a}], {test,3}) last_version_entry({[{test,1,{1265,301600,551309},a}], [{test,1,{1265,301600,551309},a}]}) ModA = {1265,301600,551309}, ModB = {1265,301600,551309} -> {ok,[{write,{test,1,{1265,301600,551309},a}}],same,{test,3}} + + + + + In other words, tables are locked on both nodes before table deconflict begins. I have not tried to prepare the mnesia_merge branch as an official patch (I haven't run the test suites. Then again, the mnesia test suites are not on github...) I'm by no means done. :) I'm only testing a very trivial scenario. What other scenarios would be really interesting to try? BR, Ulf W Ulf Wiger wrote: > > I have had some modest success with a prototype to > resolve netsplits in Mnesia. > > I pushed the code to Github: > > http://github.com/uwiger/unsplit > > I think there are still some nasty corner cases that need > resolving, and I'm not convinced that they can be solved > without some added functionality in Mnesia. > > Approach: > > An application, unsplit, starts and subscribes to mnesia > system events. > > When the unsplit_server receives an event signaling that > the database is inconsistent ({inconsistent_database, Context, Node}), > it enters a critical section (using global:trans/3) and tries to > resolve the inconsistency. The critical section is needed since > both sides will detect the condition at roughly the same time*. > Note that at this time, the two erlang nodes are in contact, but > mnesia has aborted the attempt to merge the two nodes, so each > mnesia instance considers the other side down. > > * I have on occasion seen only one printout of the "partitioned > network" message, and once or twice the contition has gone > undetected if I disconnect and reconnect very quickly. This > bothers me, but I have not been able to reproduce or analyse it. > > When entering the critical section, it checks whether the other > node is in mnesia's 'running_db_nodes' list. If so, the other > side has already resolved the inconsistency and nothing more > needs to be done. Otherwise, it checks which tables have copies > on both nodes and proceeds to merge them. > > Table locks are taken on all affected tables, but the actual > reading and writing of data are dirty. The reasons for this are: > > 1. Obviously, locks must be taken, since we don't want others > to write to the tables during the process. > 2. When reading the data, we have to read the two separate copies. > The transaction read will not allow this, so we have to read > the remote copy through rpc:call(), which means it has to be > dirty. > 3. I was hoping to have a proxy process on the other side that > locks its copy, then does the reading and writing before > we connect the two mnesia nodes. However, mnesia didn't > like this at all, when told to connect the nodes and commit. > > The actual connect of the two sides is accomplished using > (undocumented) mnesia_monitor:connect_nodes([OtherNode]). > Currently, I do this before I lock the tables; I believe this > creates a small race condition, but haven't found any other > way to do it. > > For each table, an 'unsplit_method' can be defined. The > default is {unsplit_lib, no_action, []}, which is > probably seldom a good choice. I have written a method > called {unsplit_lib, last_modified, []}, which is equivalent > to {unsplit_lib, last_version, [modified]}, simply comparing > the value of the 'modified' attribute of each two records > with the same key (this particular method won't work for > bags) and picking the latest one - aborting if the objects > are different, but the 'modified' value are the same. > > For more sophisticated callbacks, I suggest scavenging > the riak source code for Lamport clocks, Merkle trees > etc. Obviously, you also need to plan the record > representation, e.g. if you want to be able to hold > multiple versions of the same object, like riak does. > > Some test commands are in the file commands.txt. > > I don't think the dist_auto_connect once setting should be > needed, but it sure makes it easier during testing. > > Everything is still very rough at the edges, but I would > like some feedback before continuing - not least from the > Mnesia maintainers. > > BR, > Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com From cthulahoops@REDACTED Thu Feb 4 20:11:29 2010 From: cthulahoops@REDACTED (Adam Kelly) Date: Thu, 4 Feb 2010 19:11:29 +0000 Subject: [erlang-questions] Unique atom with make_ref()? In-Reply-To: <65691fa01002040327q26b574e9h2f3c0ca5162a1539@mail.gmail.com> References: <65691fa01002040327q26b574e9h2f3c0ca5162a1539@mail.gmail.com> Message-ID: <8d1798e91002041111p33f3cd8dq20aed26d79439da7@mail.gmail.com> 2010/2/4 Daniel R?nnqvist : > Why sholdn't I use erlang:ref_to_list/1 in application programs? As it > says here: > > http://erlang.org/doc/man/erlang.html#erlang:ref_to_list-1 > > Let's say that I wanted to create a unique atom, isn't this a good way? > > list_to_atom(erlang:ref_to_list(make_ref())) Start up two nodes. Run that function on both and they will both generate the same atom. It's slightly confusing, but the string representation of a ref doesn't have the uniqueness property that the ref does. If you send the ref itself between nodes, it will appear differently on each node but be unique on both. Pids have similar behaviour. If you want a unique value that you can store outside of erlang, the following is pretty good: {node(), erlang:now()}. (erlang:now() does some magic to make sure that it doesn't generate the same value twice on the same node.) Adam. From andrew@REDACTED Thu Feb 4 21:44:05 2010 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 4 Feb 2010 15:44:05 -0500 Subject: [erlang-questions] unsplit - resolving mnesia inconsistencies In-Reply-To: <4B6AFCF5.5080100@erlang-solutions.com> References: <4B6AA74E.1030802@erlang-solutions.com> <4B6AFCF5.5080100@erlang-solutions.com> Message-ID: <20100204204405.GA21394@hijacked.us> This is great. We've been doing this manually in not nearly so nice a fashion. How will this work with mnesia clusters of more than 2, like lets say a 3 node cluster where one node gets split off by a netsplit for a while - how do you avoid both of the other nodes trying to reconcile the split? Andrew From Antonio.Musumeci@REDACTED Thu Feb 4 22:02:55 2010 From: Antonio.Musumeci@REDACTED (Musumeci, Antonio S) Date: Thu, 4 Feb 2010 16:02:55 -0500 Subject: RPC and spawn Message-ID: <01489E237C2C8F45AF7898E135F48E8001DA4E07BB@NYWEXMBX2129.msad.ms.com> Does anyone know a reason why net_kernel:spawn and rpc aren't based on one another? I suppose the former on the latter. I'm asking because I'm looking to sandbox linked nodes and while you can shutdown rex with little harm that can't be said for net_kernel and it's spawn which is what erlang:spawn/4 relies on. Ideally I want to be able to expand on rex to include white/black listing so that existing rpc users can continue to work but everything else is limited. It'd be easier if if there was a single standard service providing rpc. Additionally, is it intended that rpc:stop/0 causes kernel_sup to exit? rex is setup to be permanent rather than transient so when rpc:stop/0 is called it brings down kernel_sup which is set to 0 retries with one_for_all which in turn brings down beam. Thanks. -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. From ulf.wiger@REDACTED Thu Feb 4 22:39:02 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 04 Feb 2010 22:39:02 +0100 Subject: [erlang-questions] unsplit - resolving mnesia inconsistencies In-Reply-To: <20100204204405.GA21394@hijacked.us> References: <4B6AA74E.1030802@erlang-solutions.com> <4B6AFCF5.5080100@erlang-solutions.com> <20100204204405.GA21394@hijacked.us> Message-ID: <4B6B3E76.2070507@erlang-solutions.com> Andrew Thompson wrote: > This is great. We've been doing this manually in not nearly so nice a > fashion. How will this work with mnesia clusters of more than 2, like > lets say a 3 node cluster where one node gets split off by a netsplit > for a while - how do you avoid both of the other nodes trying to > reconcile the split? These are good questions. I guess the big question is how many islands you expect to end up with in the worst case. In the case you mention, there are still two islands. One of the instances will enter the critical section (I guess the call to global:trans/3 has no reason not to use all available nodes) and address the split. The others should notice that it's fixed once they enter the critical section. But I appreciate all attempts to poke holes in the approach. If we find a scenario that is not fixable, it is certainly better to find out this way, than having your mission-critical system go belly-up at the worst possible time. :) There will always be pathological cases, of course. I've seen dual-ethernet backbones become so fragmented that the full mesh in an Erlang network started looking like Swiss cheese. If we can handle at least the sane error situations in a reliable way, I'll be fairly happy. BR, Ulf -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com From andrew@REDACTED Thu Feb 4 22:49:57 2010 From: andrew@REDACTED (Andrew Thompson) Date: Thu, 4 Feb 2010 16:49:57 -0500 Subject: [erlang-questions] unsplit - resolving mnesia inconsistencies In-Reply-To: <4B6B3E76.2070507@erlang-solutions.com> References: <4B6AA74E.1030802@erlang-solutions.com> <4B6AFCF5.5080100@erlang-solutions.com> <20100204204405.GA21394@hijacked.us> <4B6B3E76.2070507@erlang-solutions.com> Message-ID: <20100204214957.GB21394@hijacked.us> On Thu, Feb 04, 2010 at 10:39:02PM +0100, Ulf Wiger wrote: > Andrew Thompson wrote: > >This is great. We've been doing this manually in not nearly so nice a > >fashion. How will this work with mnesia clusters of more than 2, like > >lets say a 3 node cluster where one node gets split off by a netsplit > >for a while - how do you avoid both of the other nodes trying to > >reconcile the split? > > These are good questions. I guess the big question is how many > islands you expect to end up with in the worst case. In the > case you mention, there are still two islands. One of the > instances will enter the critical section (I guess the call > to global:trans/3 has no reason not to use all available > nodes) and address the split. The others should notice that > it's fixed once they enter the critical section. > > But I appreciate all attempts to poke holes in the approach. > If we find a scenario that is not fixable, it is certainly > better to find out this way, than having your mission-critical > system go belly-up at the worst possible time. :) > > There will always be pathological cases, of course. I've > seen dual-ethernet backbones become so fragmented that > the full mesh in an Erlang network started looking like > Swiss cheese. If we can handle at least the sane error > situations in a reliable way, I'll be fairly happy. > Well, I think since you're only handing one 'unsplit' at a time and locking while doing it, any other 'unsplits' that happen while you're handling the first one will patiently wait their turn in the mailbox, so you should only ever have 1 unsplit to deal with at any one time. I agree that so long as we handle the typical netsplit cases we should be good - it might be nice to have some tools that could be used to manually fix things if something goes terribly wrong - its often annoying to fix mnesia issues like this by hand. Andrew From ishwar@REDACTED Thu Feb 4 23:11:13 2010 From: ishwar@REDACTED (Ish Rattan) Date: Thu, 4 Feb 2010 17:11:13 -0500 (EST) Subject: erlang+C?? Message-ID: Is it possible for a C based client to transact with an 'echo'server in Erlang? In my case the Erlang server/client work fine, but the C client just hangs (as if the request does not reach the server). -ishwar From bflatmaj7th@REDACTED Thu Feb 4 23:18:55 2010 From: bflatmaj7th@REDACTED (Richard Andrews) Date: Fri, 5 Feb 2010 09:18:55 +1100 Subject: [erlang-questions] erlang+C?? In-Reply-To: References: Message-ID: <7702c0611002041418t536cdb1fqe6c9d5ab22d221cb@mail.gmail.com> On Fri, Feb 5, 2010 at 9:11 AM, Ish Rattan wrote: > > Is it possible for a C based client to transact with > an 'echo'server in Erlang? > > In my case the Erlang server/client work fine, > but the C client just hangs (as if the request > does not reach the server). Of course! Send a message then receive a message. From yogishb@REDACTED Fri Feb 5 01:00:49 2010 From: yogishb@REDACTED (Yogish Baliga) Date: Thu, 4 Feb 2010 16:00:49 -0800 (PST) Subject: About Common test run_test script Message-ID: <599323.74624.qm@web112606.mail.gq1.yahoo.com> run_test script generated via http://www.erlang.org/doc/apps/common_test/install_chapter.html#general is having a conflicting command line parameter with Erlang shell parameter. -config is being used as a configuration parameter for test specification configuration. This parameter name is conflicting with -config parameter of erlang shell. By using run_test script, it is not possible to configure the application. For example, disabling error_logger [ -kernel error_logger silent ]. For one or 2 parameters, this seems to be a OK solution to set the application environment on the run_test command line. The application I am testing is having many application environments. Can this be fixed in the next release by changing the run_test parameter to something like -ct_config? NOTE: For the time being, I have changed the run_test script in my working environment. Thanx, -- baliga "Point of view is worth 80 IQ points" --Alan Kay http://dudefrommangalore.blogspot.com/ From smith.winston.101@REDACTED Fri Feb 5 04:47:23 2010 From: smith.winston.101@REDACTED (Winston Smith) Date: Thu, 4 Feb 2010 22:47:23 -0500 Subject: [erlang-questions] Problems cross compiling: eheap_alloc: Cannot reallocate 3480006320 bytes of memory In-Reply-To: <10d7e35f1002031827r4ca30cbco39fbd488b554a799@mail.gmail.com> References: <10d7e35f1002031827r4ca30cbco39fbd488b554a799@mail.gmail.com> Message-ID: This is *exactly* what I did, and with what's in r13b04_dev I got it working on the avr32-linux platform (NGW100) pretty easily. I'm just in the process of preparing a patch that includes a xcomp/.conf file for avr32-linux for submission to erlang-patches. The new system works really well, the only thing I had to do was set the environment variable ac_cv_sizeof_off_t to 4 as configure can't figure it out and picks 8 (incorrectly). I noticed in the xcomp/README that you suggest updating otp_build to include new settings such as this, so I'm adding new settings for ac_cv_sizeof_off_t and also ac_cv_sizeof_size_t so they can more easily be customized in the .conf file. Many thanks and a great job on significantly improving the cross compilation support for Erlang! Winston. On Wed, Feb 3, 2010 at 9:27 PM, Rickard Green wrote: > Current cross compiling support has lots of issues. I'd recommend that > you wait for the R13B04 release if you want to cross compile > Erlang/OTP. > > The upcoming R13B04 release will have much better support for cross > compiling. I've just committed a bunch of cross fixes in the r13b04 > development branch which are available at > (ccase/r13b04_dev branch). If you want > to try it out, have a look at the xcomp/README > > since lots of things have changed regarding cross compiling since > R13B03. > > If you get it working with r13b04_dev, the configure results from > r13b04_dev may give you a hint about what is wrong with the R13B03 > configuration. However, I'd still recommend that you wait for the > R13B04 release. > > Regards, > Rickard Green, Erlang/OTP, Ericsson AB. > > 2010/1/29 Winston Smith : >> Trying to run a cross compiled version of R13B03 on an AVR32-Linux >> system (NGW100/buildroot-2.3.0) I get the following: >> >> /home/avr32 # erl >> >> Crash dump was written to: erl_crash.dump >> eheap_alloc: Cannot reallocate 3480006320 bytes of memory (of type "heap"). >> Aborted >> >> >> I've had this working before (I think with R13B01) but I've since >> upgraded my build host from Ubuntu 9.04 to 9.10. ?I actually had this >> same issue originally, and I somehow solved it, but I can't for the >> life of me remember what I did. ?I am setting up an xconf file with >> the proper values for size_t, off_t, big endian etc; in fact I based >> my build script on Brian Zhou's script for building Erlang on NSLU2 >> Linux: >> >> http://svn.nslu2-linux.org/svnroot/optware/trunk/make/erlang.mk >> >> Any thoughts on where to start debugging/diagnosing this? ?(the >> embedded gdb doesn't work) ?Is the erl_crash.dump useful (and how do I >> interpret it!)? >> >> Many thanks in advance! >> >> ________________________________________________________________ >> erlang-questions mailing list. See http://www.erlang.org/faq.html >> erlang-questions (at) erlang.org >> >> > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ulf.norell@REDACTED Fri Feb 5 07:15:26 2010 From: ulf.norell@REDACTED (Ulf Norell) Date: Fri, 5 Feb 2010 07:15:26 +0100 Subject: [erlang-questions] Output from programs started with open_port In-Reply-To: References: Message-ID: 2010/2/3 Samuel Rivas > Hi, > > I have no idea about how to make it work for windows. For linux we had > the carriage return problem also, but we just went practical and > redirected the error outuput to a file and used tail -f in other > terminal. Note that if you can't control the binaries you execute > there is a chance that they output to stdio as well, confusing your > port communication (I see you are using {packet, 1} which means that > the process must write to stdio using a fixed protocol). Indeed. I simplified my example to make it shorter. On unix systems I use nouse_stdio to avoid this problem (that doesn't work on Windows though, but that's a different issue). Redirecting to a file is the workaround I'm using, but I was hoping someone would know what the problem is and whether it can be fixed. :-) / Ulf From max.lapshin@REDACTED Fri Feb 5 10:52:30 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 5 Feb 2010 12:52:30 +0300 Subject: Fresh erlang packages for debian Message-ID: Hi, debian and ubuntu has old version of erlang (R12) and I want to package my erlyvideo. I have created repository for erlyvideo on http://debian.erlyvideo.org and think to build R13B4 into debian package, but I cannot find those debian catalog for erlang. Maybe I don't need to build it by myself and just need to provide custom repository? Where should I find new debian package or debian instructions folder? From gleber.p@REDACTED Fri Feb 5 11:03:43 2010 From: gleber.p@REDACTED (Gleb Peregud) Date: Fri, 5 Feb 2010 11:03:43 +0100 Subject: [erlang-questions] Fresh erlang packages for debian In-Reply-To: References: Message-ID: <14f0e3621002050203r303c10d0g3b676a8e7513a862@mail.gmail.com> Ubuntu Lucid and Debian Sid and Debian Experimental has packages of quite new versions R13 (can't recall exact numbers), so I guess it solves your issue On 2010-02-05, Max Lapshin wrote: > Hi, debian and ubuntu has old version of erlang (R12) and I want to > package my erlyvideo. > I have created repository for erlyvideo on http://debian.erlyvideo.org > and think to build R13B4 into debian package, > but I cannot find those debian catalog for erlang. > > Maybe I don't need to build it by myself and just need to provide > custom repository? Where should I find new debian package or > debian instructions folder? > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > -- Sent from my mobile device From max.lapshin@REDACTED Fri Feb 5 11:07:52 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 5 Feb 2010 13:07:52 +0300 Subject: [erlang-questions] Fresh erlang packages for debian In-Reply-To: <14f0e3621002050203r303c10d0g3b676a8e7513a862@mail.gmail.com> References: <14f0e3621002050203r303c10d0g3b676a8e7513a862@mail.gmail.com> Message-ID: On Fri, Feb 5, 2010 at 1:03 PM, Gleb Peregud wrote: > Ubuntu Lucid and Debian Sid and Debian Experimental has packages of > quite new versions R13 (can't recall exact numbers), so I guess it > solves your issue I see, thank you. Perhaps, I will not try to build it by myself =) Btw, in our company we have migrated to runit handling of all services, does anybody else use it? I want to make erlyvideo starting via runit. From ulf.wiger@REDACTED Fri Feb 5 15:59:04 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 05 Feb 2010 15:59:04 +0100 Subject: [erlang-questions] unsplit - resolving mnesia inconsistencies In-Reply-To: <20100204214957.GB21394@hijacked.us> References: <4B6AA74E.1030802@erlang-solutions.com> <4B6AFCF5.5080100@erlang-solutions.com> <20100204204405.GA21394@hijacked.us> <4B6B3E76.2070507@erlang-solutions.com> <20100204214957.GB21394@hijacked.us> Message-ID: <4B6C3238.1090804@erlang-solutions.com> Andrew Thompson wrote: > On Thu, Feb 04, 2010 at 10:39:02PM +0100, Ulf Wiger wrote: >> Andrew Thompson wrote: >>> This is great. We've been doing this manually in not nearly so nice a >>> fashion. How will this work with mnesia clusters of more than 2, like >>> lets say a 3 node cluster where one node gets split off by a netsplit >>> for a while - how do you avoid both of the other nodes trying to >>> reconcile the split? I have now added a check to determine all nodes in each "island" of the split, and include all tables that have at least one copy in each island. I have not tested on clusters of more than two nodes. I also modified the mnesia patch slightly to have the schema merge function determine where to lock; the caller only specifies which tables to lock. Perhaps we could move further discussion to the issue tracker in the github project? http://github.com/uwiger/unsplit/issues BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From rickard@REDACTED Fri Feb 5 16:21:35 2010 From: rickard@REDACTED (Rickard Green) Date: Fri, 05 Feb 2010 16:21:35 +0100 Subject: [erlang-questions] Problems cross compiling: eheap_alloc: Cannot reallocate 3480006320 bytes of memory In-Reply-To: References: <10d7e35f1002031827r4ca30cbco39fbd488b554a799@mail.gmail.com> Message-ID: <4B6C377F.1020701@erlang.org> I found a bug that can cause `configure' to detect wrong size of `off_t' when cross compiling. I'll fix it and inform you when the fix has appeared in r13b04_dev (probably monday next week). I'm not to fond of adding ac_cv_sizeof_* to the xcomp-conf files. `configure' should be able to figure these things out. If `configure' doesn't, it is a bug that should be fixed (and you can always pass the value on the command line, or in the environment as a workaround until the bug has been fixed). Regards, Rickard Winston Smith wrote: > This is *exactly* what I did, and with what's in r13b04_dev I got it > working on the avr32-linux platform (NGW100) pretty easily. I'm just > in the process of preparing a patch that includes a xcomp/.conf file > for avr32-linux for submission to erlang-patches. > > The new system works really well, the only thing I had to do was set > the environment variable ac_cv_sizeof_off_t to 4 as configure can't > figure it out and picks 8 (incorrectly). > > I noticed in the xcomp/README that you suggest updating otp_build to > include new settings such as this, so I'm adding new settings for > ac_cv_sizeof_off_t and also ac_cv_sizeof_size_t so they can more > easily be customized in the .conf file. > > Many thanks and a great job on significantly improving the cross > compilation support for Erlang! > > > Winston. > > On Wed, Feb 3, 2010 at 9:27 PM, Rickard Green wrote: >> Current cross compiling support has lots of issues. I'd recommend that >> you wait for the R13B04 release if you want to cross compile >> Erlang/OTP. >> >> The upcoming R13B04 release will have much better support for cross >> compiling. I've just committed a bunch of cross fixes in the r13b04 >> development branch which are available at >> (ccase/r13b04_dev branch). If you want >> to try it out, have a look at the xcomp/README >> >> since lots of things have changed regarding cross compiling since >> R13B03. >> >> If you get it working with r13b04_dev, the configure results from >> r13b04_dev may give you a hint about what is wrong with the R13B03 >> configuration. However, I'd still recommend that you wait for the >> R13B04 release. >> >> Regards, >> Rickard Green, Erlang/OTP, Ericsson AB. >> >> 2010/1/29 Winston Smith : >>> Trying to run a cross compiled version of R13B03 on an AVR32-Linux >>> system (NGW100/buildroot-2.3.0) I get the following: >>> >>> /home/avr32 # erl >>> >>> Crash dump was written to: erl_crash.dump >>> eheap_alloc: Cannot reallocate 3480006320 bytes of memory (of type "heap"). >>> Aborted >>> >>> >>> I've had this working before (I think with R13B01) but I've since >>> upgraded my build host from Ubuntu 9.04 to 9.10. I actually had this >>> same issue originally, and I somehow solved it, but I can't for the >>> life of me remember what I did. I am setting up an xconf file with >>> the proper values for size_t, off_t, big endian etc; in fact I based >>> my build script on Brian Zhou's script for building Erlang on NSLU2 >>> Linux: >>> >>> http://svn.nslu2-linux.org/svnroot/optware/trunk/make/erlang.mk >>> >>> Any thoughts on where to start debugging/diagnosing this? (the >>> embedded gdb doesn't work) Is the erl_crash.dump useful (and how do I >>> interpret it!)? >>> >>> Many thanks in advance! >>> >>> ________________________________________________________________ >>> erlang-questions mailing list. See http://www.erlang.org/faq.html >>> erlang-questions (at) erlang.org >>> >>> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > -- Rickard Green, Erlang/OTP, Ericsson AB. From ishwar@REDACTED Fri Feb 5 17:00:49 2010 From: ishwar@REDACTED (Ish Rattan) Date: Fri, 5 Feb 2010 11:00:49 -0500 (EST) Subject: IPaddress/FQDN? Message-ID: How does one specify the ipadress or domain-name of the host in the following construct? {ok, Listen} = gen_tcp:listen(5901, [binary, {packet, 4}, {reuseaddr, true}, {active, true}]), As above defaults to "localhost" -ishwar From attila.r.nohl@REDACTED Fri Feb 5 17:15:52 2010 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Fri, 5 Feb 2010 17:15:52 +0100 Subject: [erlang-questions] IPaddress/FQDN? In-Reply-To: References: Message-ID: <401d3ba31002050815h6756d936w9b202822c64b9dad@mail.gmail.com> 2010/2/5, Ish Rattan : > > How does one specify the ipadress or domain-name of the > host in the following construct? > > {ok, Listen} = gen_tcp:listen(5901, [binary, {packet, 4}, > {reuseaddr, true}, {active, true}]), Maybe gen_tcp:listen(5901, [binary, {packet, 4}, {reuseaddr, true}, {active, true}, {ip, {1,2,3,4}}, inet]) ? From igor@REDACTED Fri Feb 5 17:59:27 2010 From: igor@REDACTED (Igor Goryachev) Date: Fri, 05 Feb 2010 19:59:27 +0300 Subject: [erlang-questions] Fresh erlang packages for debian In-Reply-To: (Max Lapshin's message of "Fri, 5 Feb 2010 13:07:52 +0300") References: <14f0e3621002050203r303c10d0g3b676a8e7513a862@mail.gmail.com> Message-ID: <87bpg34o0g.fsf@goryachev.org> On Fri, Feb 05, 2010 at 13:07, Max Lapshin wrote: >> Ubuntu Lucid and Debian Sid and Debian Experimental has packages of >> quite new versions R13 (can't recall exact numbers), so I guess it >> solves your issue > > I see, thank you. Perhaps, I will not try to build it by myself =) If you prefer to use rock-solid Debian GNU/Linux's stable branch, then the best practice is to backport necessary packages from unstable or experimental branch. -- Igor Goryachev E-Mail/Jabber: igor@REDACTED From gliptak@REDACTED Fri Feb 5 23:32:45 2010 From: gliptak@REDACTED (=?ISO-8859-1?B?R+Fib3IgTGlwdOFr?=) Date: Fri, 5 Feb 2010 17:32:45 -0500 Subject: jinterface.jar in the Maven repository? In-Reply-To: <20100205085519.GA29445@erix.ericsson.se> References: <3c64b6c31002021752k3fe9564cnf94e2885ecaf44a9@mail.gmail.com> <20100205085519.GA29445@erix.ericsson.se> Message-ID: <3c64b6c31002051432q78abb48emafe623c67c3d02f9@mail.gmail.com> In order to make Java/Erlang projects easier to develop and package, "official" jinterface.jar could be uploaded to Maven and uses as a dependency for Java builds. Here is a description on the process: https://docs.sonatype.com/display/NX/OSS+Repository+Hosting this would require participation from domain/project owners. I would be happy to facilitate the process and prepare Maven related artifacts needed. Is there an interest in this? Thank you From gliptak@REDACTED Fri Feb 5 23:36:44 2010 From: gliptak@REDACTED (=?ISO-8859-1?B?R+Fib3IgTGlwdOFr?=) Date: Fri, 5 Feb 2010 17:36:44 -0500 Subject: [erlang-questions] Fresh erlang packages for debian In-Reply-To: <87bpg34o0g.fsf@goryachev.org> References: <14f0e3621002050203r303c10d0g3b676a8e7513a862@mail.gmail.com> <87bpg34o0g.fsf@goryachev.org> Message-ID: <3c64b6c31002051436q588154f5p909738a9f85a1c4f@mail.gmail.com> Will the jinterface.jar (with a Java dependency?) also be packaged for Debian? Thanks On Fri, Feb 5, 2010 at 11:59, Igor Goryachev wrote: > On Fri, Feb 05, 2010 at 13:07, Max Lapshin wrote: > > >> Ubuntu Lucid and Debian Sid and Debian Experimental has packages of > >> quite new versions R13 (can't recall exact numbers), so I guess it > >> solves your issue > > > > I see, thank you. Perhaps, I will not try to build it by myself =) > > If you prefer to use rock-solid Debian GNU/Linux's stable branch, then > the best practice is to backport necessary packages from unstable or > experimental branch. > > > -- > Igor Goryachev E-Mail/Jabber: igor@REDACTED > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From eric.l.2046@REDACTED Sat Feb 6 04:02:05 2010 From: eric.l.2046@REDACTED (Eric Liang) Date: Sat, 06 Feb 2010 11:02:05 +0800 Subject: {error,enoent} occurs while staring the Erlang/OTP test_server by ts:install() Message-ID: <4B6CDBAD.2050209@gmail.com> Hi all, I'm trying the Erlang/OTP test_server, but always get the error: Eshell V5.7.2 (abort with ^G) 1> ts:install(). Running configure for cross architecture, network target name {unix,linux} {error,enoent} 2> After debug the ts_install.erl, it looks like the ts requires file: conf_vars, while there is only one file:conf_vars.in in the test_server directory. Would you mind having a look at this and help me out? Thanks in advance. The detailed steps are following: 1 download Erlang/OTP (R13B03 now) from here , and unpack it get dir: otp_src_R13B03 2 download test_server-3.1.1.tar.gz, emulator-tests-2004-05-26.tar.gz and stdlib-tests-2004-05-26.tar.gz from here , and unpack to dir: otp_src_R13B03 3 cd otp_src_R13B03 and export ERL_TOP=`pwd` 4 ./configure and make 5 mkdir /home/sunny/codes_in_git/erlang_test for test codes.(TESTROOT) 6.1 cd lib/test_server/ ( orignally from test_server-3.1.1.tar.gz ) and make release_tests TESTROOT=/home/sunny/codes_in_git/erlang_test/ 6.2 cd lib/stdlib/test/ ( orignally from stdlib-tests-2004-05-26.tar.gz ) and make release_tests TESTROOT=/home/sunny/codes_in_git/erlang_test/ 6.3 cd erts/emulator/test/ ( orignally from emulator-tests-2004-05-26.tar.gz ) and make release_tests TESTROOT=/home/sunny/codes_in_git/erlang_test/ Though I can't install ts, but when I run: ts:tests(), the returns looks right: 7> ts:tests(). [emulator,stdlib] Please let me know if you need anything more. Thanks, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From kagato@REDACTED Sat Feb 6 06:10:47 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Fri, 5 Feb 2010 21:10:47 -0800 Subject: [erlang-questions] Re: jinterface.jar in the Maven repository? In-Reply-To: <3c64b6c31002051432q78abb48emafe623c67c3d02f9@mail.gmail.com> References: <3c64b6c31002021752k3fe9564cnf94e2885ecaf44a9@mail.gmail.com> <20100205085519.GA29445@erix.ericsson.se> <3c64b6c31002051432q78abb48emafe623c67c3d02f9@mail.gmail.com> Message-ID: +1 On Feb 5, 2010, at 2:32 PM, G?bor Lipt?k wrote: > In order to make Java/Erlang projects easier to develop and package, > "official" jinterface.jar could be uploaded to Maven and uses as a > dependency for Java builds. > > Here is a description on the process: > > https://docs.sonatype.com/display/NX/OSS+Repository+Hosting > > this would require participation from domain/project owners. I would be > happy to facilitate the process and prepare Maven related artifacts needed. > > Is there an interest in this? > > Thank you -- Jayson Vantuyl kagato@REDACTED From bgustavsson@REDACTED Sat Feb 6 06:58:59 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sat, 6 Feb 2010 06:58:59 +0100 Subject: [erlang-questions] {error,enoent} occurs while staring the Erlang/OTP test_server by ts:install() In-Reply-To: <4B6CDBAD.2050209@gmail.com> References: <4B6CDBAD.2050209@gmail.com> Message-ID: <6672d0161002052158p194e42a8w9efe32de6a1cbb50@mail.gmail.com> On Sat, Feb 6, 2010 at 4:02 AM, Eric Liang wrote: > I'm trying the Erlang/OTP test_server, but always get the error: Modern versions of the test_server and test suites can be found in out git repository. Instructions for building and running the tests can be found here: http://wiki.github.com/erlang/otp/running-tests -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From eric.l.2046@REDACTED Sat Feb 6 08:46:46 2010 From: eric.l.2046@REDACTED (Eric Liang) Date: Sat, 06 Feb 2010 15:46:46 +0800 Subject: [erlang-questions] {error,enoent} occurs while staring the Erlang/OTP test_server by ts:install() In-Reply-To: <6672d0161002052158p194e42a8w9efe32de6a1cbb50@mail.gmail.com> References: <4B6CDBAD.2050209@gmail.com> <6672d0161002052158p194e42a8w9efe32de6a1cbb50@mail.gmail.com> Message-ID: <4B6D1E66.2080200@gmail.com> On 02/06/2010 01:58 PM, Bj?rn Gustavsson wrote: > On Sat, Feb 6, 2010 at 4:02 AM, Eric Liang wrote: > > >> I'm trying the Erlang/OTP test_server, but always get the error: >> > Modern versions of the test_server and test suites can be found > in out git repository. Instructions for building and running the > tests can be found here: > > http://wiki.github.com/erlang/otp/running-tests > > Thanks you, Bj?rn. Actually the reason why I use otp release package is because I failed to compile the sources in git. It looks like there is something mismatching on the autoconf: $ export ERL_TOP=`pwd` $ ./otp_build autoconf *************************************************** *************************************************** *** WARNING: System might fail to configure or *** might be erroneously configured *** since autoconf version 2.13 is used *** instead of version 2.59! *************************************************** *************************************************** === running autoconf in lib /usr/bin/m4:configure.in:25: cannot open `m4sugar/foreach.m4': No such file or directory I did research the malling-list, somebody said: autoreconf -fis helps. The configure script was generated, but after configure, I still get the related error(m4sugar/foreach.m4) while making. Do you have any advice on this? Also, any other suggestions will be appreciated . Thanks in advance. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From kostis@REDACTED Sat Feb 6 09:19:09 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 06 Feb 2010 10:19:09 +0200 Subject: [erlang-questions] {error,enoent} occurs while staring the Erlang/OTP test_server by ts:install() In-Reply-To: <4B6D1E66.2080200@gmail.com> References: <4B6CDBAD.2050209@gmail.com> <6672d0161002052158p194e42a8w9efe32de6a1cbb50@mail.gmail.com> <4B6D1E66.2080200@gmail.com> Message-ID: <4B6D25FD.7080506@cs.ntua.gr> Eric Liang wrote: > Thanks you, Bj?rn. > > Actually the reason why I use otp release package is because I failed to > compile the sources in git. It looks like there is something mismatching > on the autoconf: > > $ export ERL_TOP=`pwd` > $ ./otp_build autoconf > *************************************************** > *************************************************** > *** WARNING: System might fail to configure or > *** might be erroneously configured > *** since autoconf version 2.13 is used > *** instead of version 2.59! > *************************************************** > *************************************************** You need to upgrade to autoconf version 2.59 or higher. Kostis From eric.l.2046@REDACTED Sat Feb 6 12:33:41 2010 From: eric.l.2046@REDACTED (Eric Liang) Date: Sat, 06 Feb 2010 19:33:41 +0800 Subject: [erlang-questions] {error,enoent} occurs while staring the Erlang/OTP test_server by ts:install() In-Reply-To: <4B6D25FD.7080506@cs.ntua.gr> References: <4B6CDBAD.2050209@gmail.com> <6672d0161002052158p194e42a8w9efe32de6a1cbb50@mail.gmail.com> <4B6D1E66.2080200@gmail.com> <4B6D25FD.7080506@cs.ntua.gr> Message-ID: <4B6D5395.80406@gmail.com> On 02/06/2010 04:19 PM, Kostis Sagonas wrote: > Eric Liang wrote: >> Thanks you, Bj?rn. >> >> Actually the reason why I use otp release package is because I failed >> to compile the sources in git. It looks like there is something >> mismatching on the autoconf: >> >> $ export ERL_TOP=`pwd` >> $ ./otp_build autoconf >> *************************************************** >> *************************************************** >> *** WARNING: System might fail to configure or >> *** might be erroneously configured >> *** since autoconf version 2.13 is used >> *** instead of version 2.59! >> *************************************************** >> *************************************************** > > You need to upgrade to autoconf version 2.59 or higher. > > Kostis Thanks Kostis, this solves the compilation problem. :) I'll check the test_server later. Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From eric.l.2046@REDACTED Sat Feb 6 14:18:14 2010 From: eric.l.2046@REDACTED (Eric Liang) Date: Sat, 06 Feb 2010 21:18:14 +0800 Subject: [erlang-questions] {error,enoent} occurs while staring the Erlang/OTP test_server by ts:install() In-Reply-To: <6672d0161002052158p194e42a8w9efe32de6a1cbb50@mail.gmail.com> References: <4B6CDBAD.2050209@gmail.com> <6672d0161002052158p194e42a8w9efe32de6a1cbb50@mail.gmail.com> Message-ID: <4B6D6C16.6000505@gmail.com> On 02/06/2010 01:58 PM, Bj?rn Gustavsson wrote: > On Sat, Feb 6, 2010 at 4:02 AM, Eric Liang wrote: > > >> I'm trying the Erlang/OTP test_server, but always get the error: >> > Modern versions of the test_server and test suites can be found > in out git repository. Instructions for building and running the > tests can be found here: > > http://wiki.github.com/erlang/otp/running-tests > > Bingo, solved this by using the git respository. Thanks you two again :) Eric -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From alex.arnon@REDACTED Sat Feb 6 15:43:45 2010 From: alex.arnon@REDACTED (Alex Arnon) Date: Sat, 6 Feb 2010 16:43:45 +0200 Subject: [erlang-questions] Re: jinterface.jar in the Maven repository? In-Reply-To: References: <3c64b6c31002021752k3fe9564cnf94e2885ecaf44a9@mail.gmail.com> <20100205085519.GA29445@erix.ericsson.se> <3c64b6c31002051432q78abb48emafe623c67c3d02f9@mail.gmail.com> Message-ID: <944da41d1002060643y3c1f7754u3d22ff7e88d88963@mail.gmail.com> +1 indeed!!! In my project ('jports' on Google Code, warning - Work In Progress :) ), I am forced to instruct the user to copy java_src directly to a jinterface artifact, due to the license. This is inconvenient and breaks the common expectation that a Maven project should be one-click-buildable anywhere. On Sat, Feb 6, 2010 at 7:10 AM, Jayson Vantuyl wrote: > +1 > > On Feb 5, 2010, at 2:32 PM, G?bor Lipt?k wrote: > > > In order to make Java/Erlang projects easier to develop and package, > > "official" jinterface.jar could be uploaded to Maven and uses as a > > dependency for Java builds. > > > > Here is a description on the process: > > > > https://docs.sonatype.com/display/NX/OSS+Repository+Hosting > > > > this would require participation from domain/project owners. I would be > > happy to facilitate the process and prepare Maven related artifacts > needed. > > > > Is there an interest in this? > > > > Thank you > > -- > Jayson Vantuyl > kagato@REDACTED > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From clist@REDACTED Sun Feb 7 15:29:49 2010 From: clist@REDACTED (Angel) Date: Sun, 7 Feb 2010 15:29:49 +0100 Subject: extrange output of =?utf-8?q?=C3=82_on?= erlang Message-ID: <201002071529.49516.clist@uah.es> Hi just reading some Jo?l redmont articles. He did and array vs tree comparison and blogged the results so im just downloaded his code and tried... (code attached) Joel's test shows: 27> arr:test(). Fixed-size array: get: 2921us, set: 5902us Extensible array: get: 3336us, set: 8144us Tuple: get: 632us, set: 107467us Tree: get: 4321us, set: 45256us ok Where me machine shows: 1> arr:test(). Fixed-size array: get: 11586??s, set: 24969??s Extensible array: get: 11586??s, set: 23787??s Tuple: get: 1223??s, set: 491196??s Tree: get: 9480??s, set: 101000??s ok I cant explain where that strange ? come... (tested on openSUSE 11.2 Konsole) Anyone can tell me what's wrong on my machine??? -- Most people know C is not so high level.... ...Everybody else just got assembler overdose -------------- next part -------------- A non-text attachment was scrubbed... Name: arr.erl Type: text/x-erlang Size: 1934 bytes Desc: not available URL: From rvirding@REDACTED Sun Feb 7 16:47:20 2010 From: rvirding@REDACTED (Robert Virding) Date: Sun, 7 Feb 2010 16:47:20 +0100 Subject: =?ISO-8859-1?Q?Re=3A_=5Berlang=2Dquestions=5D_extrange_output_of_=C2_on_erla?= =?ISO-8859-1?Q?ng?= In-Reply-To: <201002071529.49516.clist@uah.es> References: <201002071529.49516.clist@uah.es> Message-ID: <3dbc6d1c1002070747x43498706lbc3496831b443809@mail.gmail.com> For some reason the format strings in test/1 contain the ? character so it is naturally printed out. As far as I can see there are two reasons to why Joel did not see it hwile you did: - Something happened when copying the files to introduce them. - On Joel's machine non.ASCII characters were not printed out in his terminal window while they are in yours. What is more interesting is that on your machine the relative times are different. Robert On 7 February 2010 15:29, Angel wrote: > Hi > > just reading some Jo?l redmont articles. > > He did and array vs tree comparison and blogged the results > so im just downloaded his code and tried... > > (code attached) > > Joel's test shows: > > 27> arr:test(). > > Fixed-size array: get: 2921us, set: 5902us > Extensible array: get: 3336us, set: 8144us > Tuple: get: 632us, set: 107467us > Tree: get: 4321us, set: 45256us > ok > > > Where me machine shows: > > 1> arr:test(). > > Fixed-size array: get: ? ?11586??s, set: ? ?24969??s > Extensible array: get: ? ?11586??s, set: ? ?23787??s > Tuple: ? ? ? ? ? ?get: ? ? 1223??s, set: ? 491196??s > Tree: ? ? ? ? ? ? get: ? ? 9480??s, set: ? 101000??s > ok > > > I cant explain where that strange ? come... (tested on openSUSE 11.2 Konsole) > > Anyone can tell me what's wrong on my machine??? > > > > > > > -- > Most people know C is not so high level.... > ? ? ? ? ? ? ? ?...Everybody else just got assembler overdose > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From clist@REDACTED Sun Feb 7 21:13:57 2010 From: clist@REDACTED (Angel) Date: Sun, 7 Feb 2010 21:13:57 +0100 Subject: [erlang-questions] extrange output of =?utf-8?q?=C3=82_on?= erlang In-Reply-To: <3dbc6d1c1002070747x43498706lbc3496831b443809@mail.gmail.com> References: <201002071529.49516.clist@uah.es> <3dbc6d1c1002070747x43498706lbc3496831b443809@mail.gmail.com> Message-ID: <201002072113.57327.clist@uah.es> This is going better over the time... On Domingo, 7 de Febrero de 2010 16:47:20 usted escribi?: > For some reason the format strings in test/1 contain the ? character > so it is naturally printed out. As far as I can see there are two > reasons to why Joel did not see it hwile you did: > > - Something happened when copying the files to introduce them. I re-downloaded the file form github, still those ? are printed.. This issue is only visible on the erlang console: sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl Erlang R13B03 (erts-5.7.4) [source] [rq:1] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.7.4 (abort with ^G) 1> arr:test(). Fixed-size array: get: 11577??s, set: 24369??s Extensible array: get: 12717??s, set: 24135??s Tuple: get: 1222??s, set: 489969??s Tree: get: 10605??s, set: 99338??s ok 2> q(). ok While almost the ? and the time direfences are gone doing: sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl -noshell -run arr test -run init stop Fixed-size array: get: 5324?s, set: 11211?s Extensible array: get: 5327?s, set: 10682?s Tuple: get: 1220?s, set: 440337?s Tree: get: 9436?s, set: 100457?s sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> > - On Joel's machine non.ASCII characters were not printed out in his > terminal window while they are in yours. Maybe i sitll trying to open the file with diferent codes to see.. > > What is more interesting is that on your machine the relative times > are different. Now observe the preceding console printout, the time diferences are on the same machine slow on erlang console but faster whout shell?? Now im very upset with this mesurements! :-( > > Robert > > On 7 February 2010 15:29, Angel wrote: > > Hi > > > > just reading some Jo?l redmont articles. > > > > He did and array vs tree comparison and blogged the results > > so im just downloaded his code and tried... > > > > (code attached) > > > > Joel's test shows: > > > > 27> arr:test(). > > > > Fixed-size array: get: 2921us, set: 5902us > > Extensible array: get: 3336us, set: 8144us > > Tuple: get: 632us, set: 107467us > > Tree: get: 4321us, set: 45256us > > ok > > > > > > Where me machine shows: > > > > 1> arr:test(). > > > > Fixed-size array: get: 11586??s, set: 24969??s > > Extensible array: get: 11586??s, set: 23787??s > > Tuple: get: 1223??s, set: 491196??s > > Tree: get: 9480??s, set: 101000??s > > ok > > > > > > I cant explain where that strange ? come... (tested on openSUSE 11.2 > > Konsole) > > > > Anyone can tell me what's wrong on my machine??? > > > > > > > > > > > > > > -- > > Most people know C is not so high level.... > > ...Everybody else just got assembler overdose > > > > > > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > See http://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > Most people know C is not so high level.... ...Everybody else just got assembler overdose From clist@REDACTED Sun Feb 7 21:44:55 2010 From: clist@REDACTED (Angel) Date: Sun, 7 Feb 2010 21:44:55 +0100 Subject: Extrange output of =?utf-8?q?=C3=82s_and_varing_times_on_erlang_console_when_testing?= =?utf-8?q?_array=5Fvs=5Ftuples?= In-Reply-To: <201002072113.57327.clist@uah.es> References: <201002071529.49516.clist@uah.es> <3dbc6d1c1002070747x43498706lbc3496831b443809@mail.gmail.com> <201002072113.57327.clist@uah.es> Message-ID: <201002072144.55991.clist@uah.es> 1) The ? symbol is related to the microsecond symbol and appears only when testing from the erlang console, where at bash level (konsole, and plain tty) the caracter is not shown. 2) The time rougly doubles in the erlang console. Calling the test funtion from bash via: "erl -noshell -run arr test" shown "proper" times. Can test code at: http://gist.github.com/266826 (Joel's github) sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl -noshell -run arr test -run init stop Fixed-size array: get: 5354?s, set: 11242?s Extensible array: get: 5357?s, set: 10639?s Tuple: get: 1224?s, set: 441784?s Tree: get: 9409?s, set: 100486?s sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl Erlang R13B03 (erts-5.7.4) [source] [rq:1] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.7.4 (abort with ^G) 1> arr:test(). Fixed-size array: get: 11618??s, set: 28557??s Extensible array: get: 10083??s, set: 23536??s Tuple: get: 1218??s, set: 481610??s Tree: get: 9682??s, set: 102533??s ok 2> q(). /angel Most people know C is not so high level.... ...Everybody else just got assembler overdose From mjtruog@REDACTED Sun Feb 7 22:00:02 2010 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 07 Feb 2010 13:00:02 -0800 Subject: [erlang-questions] Extrange output of =?UTF-8?B?w4JzIGFuZCB2?= =?UTF-8?B?YXJpbmcgdGltZXMgb24gZXJsYW5nIGNvbnNvbGUgd2hlbiB0ZXN0aW5nIGFycmE=?= =?UTF-8?B?eV92c190dXBsZXM=?= In-Reply-To: <201002072144.55991.clist@uah.es> References: <201002071529.49516.clist@uah.es> <3dbc6d1c1002070747x43498706lbc3496831b443809@mail.gmail.com> <201002072113.57327.clist@uah.es> <201002072144.55991.clist@uah.es> Message-ID: <4B6F29D2.5020809@gmail.com> Here is a version with other types added that you might be interested in: http://okeuday.livejournal.com/15662.html Angel wrote: > 1) The ? symbol is related to the microsecond symbol and appears only when > testing from the erlang console, where at bash level (konsole, and plain tty) the > caracter is not shown. > > 2) The time rougly doubles in the erlang console. Calling the test funtion from > bash via: "erl -noshell -run arr test" shown "proper" times. > > Can test code at: http://gist.github.com/266826 (Joel's github) > > > > sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl -noshell -run arr test -run init stop > Fixed-size array: get: 5354?s, set: 11242?s > Extensible array: get: 5357?s, set: 10639?s > Tuple: get: 1224?s, set: 441784?s > Tree: get: 9409?s, set: 100486?s > > > sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl > Erlang R13B03 (erts-5.7.4) [source] [rq:1] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.7.4 (abort with ^G) > 1> arr:test(). > Fixed-size array: get: 11618??s, set: 28557??s > Extensible array: get: 10083??s, set: 23536??s > Tuple: get: 1218??s, set: 481610??s > Tree: get: 9682??s, set: 102533??s > ok > 2> q(). > > > > > /angel > > > > > > > Most people know C is not so high level.... > ...Everybody else just got assembler overdose > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From clist@REDACTED Sun Feb 7 22:25:50 2010 From: clist@REDACTED (Angel) Date: Sun, 7 Feb 2010 22:25:50 +0100 Subject: [erlang-questions] Extrange output of =?utf-8?q?=C3=82s_and_varing_times_on_erlang_console_when_testing?= =?utf-8?q?_array=5Fvs=5Ftuples?= In-Reply-To: <4B6F29D2.5020809@gmail.com> References: <201002071529.49516.clist@uah.es> <201002072144.55991.clist@uah.es> <4B6F29D2.5020809@gmail.com> Message-ID: <201002072225.50895.clist@uah.es> Did you find similar diferences when running the rbdictized Test from erlang console and at the shell level? (Assumed you picked the original Joel's code to test rbdicts) Ive been testing with diferenct heaps to see if is a memory related diference with no luck. All i can see (after deleting those ?s) is that this test behaves diferent with and without the erlang console... provided the arr.erl module the following runs show diferent result and timmings: erl -noshell -run arr test -run init stop Fixed-size array: get: 5332 ?s, set: 11249 ?s Extensible array: get: 5334 ?s, set: 10648 ?s Tuple: get: 1222 ?s, set: 437980 ?s Tree: get: 9457 ?s, set: 99774 ?s erl -run arr test -run init stop Erlang R13B03 (erts-5.7.4) [source] [rq:1] [async-threads:0] [hipe] [kernel- poll:false] Eshell V5.7.4 (abort with ^G) 1> Fixed-size array: get: 5372 ??s, set: 62407 ??s Extensible array: get: 5393 ??s, set: 10772 ??s Tuple: get: 2392 ??s, set: 462941 ??s Tree: get: 9481 ??s, set: 99098 ??s so the rlang console is responsible form this unespected high runnig times (and those estrange ?s) On Domingo, 7 de Febrero de 2010 22:00:02 usted escribi?: > Here is a version with other types added that you might be interested in: > http://okeuday.livejournal.com/15662.html > > Angel wrote: > > 1) The ? symbol is related to the microsecond symbol and appears only > > when testing from the erlang console, where at bash level (konsole, and > > plain tty) the caracter is not shown. > > > > 2) The time rougly doubles in the erlang console. Calling the test > > funtion from bash via: "erl -noshell -run arr test" shown "proper" times. > > > > Can test code at: http://gist.github.com/266826 (Joel's github) > > > > > > > > sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl -noshell -run arr > > test -run init stop Fixed-size array: get: 5354?s, set: 11242?s > > Extensible array: get: 5357?s, set: 10639?s > > Tuple: get: 1224?s, set: 441784?s > > Tree: get: 9409?s, set: 100486?s > > > > > > sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl > > Erlang R13B03 (erts-5.7.4) [source] [rq:1] [async-threads:0] [hipe] > > [kernel-poll:false] > > > > Eshell V5.7.4 (abort with ^G) > > 1> arr:test(). > > Fixed-size array: get: 11618??s, set: 28557??s > > Extensible array: get: 10083??s, set: 23536??s > > Tuple: get: 1218??s, set: 481610??s > > Tree: get: 9682??s, set: 102533??s > > ok > > 2> q(). > > > > > > > > > > /angel > > > > > > > > > > > > > > Most people know C is not so high level.... > > ...Everybody else just got assembler overdose > > > > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > See http://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > Most people know C is not so high level.... ...Everybody else just got assembler overdose From mjtruog@REDACTED Sun Feb 7 22:38:04 2010 From: mjtruog@REDACTED (Michael Truog) Date: Sun, 07 Feb 2010 13:38:04 -0800 Subject: [erlang-questions] Extrange output of =?UTF-8?B?w4JzIGFuZCB2?= =?UTF-8?B?YXJpbmcgdGltZXMgb24gZXJsYW5nIGNvbnNvbGUgd2hlbiB0ZXN0aW5nIGFycmE=?= =?UTF-8?B?eV92c190dXBsZXM=?= In-Reply-To: <201002072225.50895.clist@uah.es> References: <201002071529.49516.clist@uah.es> <201002072144.55991.clist@uah.es> <4B6F29D2.5020809@gmail.com> <201002072225.50895.clist@uah.es> Message-ID: <4B6F32BC.3050507@gmail.com> To be honest, I don't remember which way I was doing the test. I was looking for the relative time and was not as focused on absolute time. However, it does seem like the best way to do this test is with: erl -noshell -run arr test -run init stop I am not sure about the overhead shell processing adds, but it should be the closest (when ran without the shell) to a production system's usage of data structures (ignoring unique memory configuration and any other obscure parameters). Angel wrote: > Did you find similar diferences when running the rbdictized Test from erlang > console and at the shell level? (Assumed you picked the original Joel's code > to test rbdicts) > > Ive been testing with diferenct heaps to see if is a memory related diference > with no luck. All i can see (after deleting those ?s) is that this test > behaves diferent with and without the erlang console... > > provided the arr.erl module the following runs show diferent result and > timmings: > > erl -noshell -run arr test -run init stop > > Fixed-size array: get: 5332 ?s, set: 11249 ?s > Extensible array: get: 5334 ?s, set: 10648 ?s > Tuple: get: 1222 ?s, set: 437980 ?s > Tree: get: 9457 ?s, set: 99774 ?s > > erl -run arr test -run init stop > Erlang R13B03 (erts-5.7.4) [source] [rq:1] [async-threads:0] [hipe] [kernel- > poll:false] > > Eshell V5.7.4 (abort with ^G) > 1> Fixed-size array: get: 5372 ??s, set: 62407 ??s > Extensible array: get: 5393 ??s, set: 10772 ??s > Tuple: get: 2392 ??s, set: 462941 ??s > Tree: get: 9481 ??s, set: 99098 ??s > > so the rlang console is responsible form this unespected high runnig times > (and those estrange ?s) > > > > > > On Domingo, 7 de Febrero de 2010 22:00:02 usted escribi?: > >> Here is a version with other types added that you might be interested in: >> http://okeuday.livejournal.com/15662.html >> >> Angel wrote: >> >>> 1) The ? symbol is related to the microsecond symbol and appears only >>> when testing from the erlang console, where at bash level (konsole, and >>> plain tty) the caracter is not shown. >>> >>> 2) The time rougly doubles in the erlang console. Calling the test >>> funtion from bash via: "erl -noshell -run arr test" shown "proper" times. >>> >>> Can test code at: http://gist.github.com/266826 (Joel's github) >>> >>> >>> >>> sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl -noshell -run arr >>> test -run init stop Fixed-size array: get: 5354?s, set: 11242?s >>> Extensible array: get: 5357?s, set: 10639?s >>> Tuple: get: 1224?s, set: 441784?s >>> Tree: get: 9409?s, set: 100486?s >>> >>> >>> sinchan@REDACTED:~/Documentos/Personal/Erlang/Code> erl >>> Erlang R13B03 (erts-5.7.4) [source] [rq:1] [async-threads:0] [hipe] >>> [kernel-poll:false] >>> >>> Eshell V5.7.4 (abort with ^G) >>> 1> arr:test(). >>> Fixed-size array: get: 11618??s, set: 28557??s >>> Extensible array: get: 10083??s, set: 23536??s >>> Tuple: get: 1218??s, set: 481610??s >>> Tree: get: 9682??s, set: 102533??s >>> ok >>> 2> q(). >>> >>> >>> >>> >>> /angel >>> >>> >>> >>> >>> >>> >>> Most people know C is not so high level.... >>> ...Everybody else just got assembler overdose >>> >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> > > Most people know C is not so high level.... > ...Everybody else just got assembler overdose > > > From ok@REDACTED Sun Feb 7 23:45:07 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 8 Feb 2010 11:45:07 +1300 Subject: =?ISO-8859-1?Q?Re:_[erlang-questions]_extrange_output_of_=C2_on_?= =?ISO-8859-1?Q?erlang?= In-Reply-To: <201002071529.49516.clist@uah.es> References: <201002071529.49516.clist@uah.es> Message-ID: On Feb 8, 2010, at 3:29 AM, Angel wrote: > Fixed-size array: get: 11586??s, set: 24969??s > Extensible array: get: 11586??s, set: 23787??s > Tuple: get: 1223??s, set: 491196??s > Tree: get: 9480??s, set: 101000??s > ok > > > I cant explain where that strange ? come... (tested on openSUSE 11.2 > Konsole) > > Anyone can tell me what's wrong on my machine??? The program is writing UTF-8 but the terminal emulator is expecting Latin 1. The micron character is U+00b5, or 0000 0000 1011 0101 xxx xxyy yyyy which will be encoded in UTF-8 as 1100 0010 1011 0101 x xxxx yy yyyy or C2 B5, and C2 just happens to be ?. The result is that any Latin 1 character in the range 80 to BF will display with an extra ?. Characters in the range C0 to FF get an extra ? instead. You must either make the program generate Latin 1, or the terminal accept UTF-8. Read the Konsole documentation to find out how to select the character encoding. From ok@REDACTED Mon Feb 8 00:14:45 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 8 Feb 2010 12:14:45 +1300 Subject: Teaching Erlang as part of a paper -- advice sought Message-ID: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> This year I am in the happy position of teaching a paper on concurrent programming. I propose to start by teaching Erlang, as being by far the simplest concurrent programming language I know (except possibly Occam, but while the restrictions in Occam are _motivated_, they are still quite painful, and make the language harder to use). However, I've never actually _taught_ Erlang before. These are 4th year students with Java and C. Last year in a class at the same level one group did an assignment in Erlang without needing to be taught. Has anyone tried more than one Erlang book? What works well? I propose to explain Erlang as - take a minimal programming language (which means pretty much lambda calculus) - add a few simple data structures (integers, floats, lists, tuples, atoms) - add pattern matching - add minimal support for concurrency (processes and process IDs, !, receive) - add support for large scale programming (modules) - add support for practical programming (testing, debugging, monitoring, most of which I don't plan to cover) - add support for distribution (nodes, unreliable messaging, timeouts, &c) - add support for persistent data (might/might not mention) but I'm really only interested in Erlang as a means to an end. What I am *really* interested in is "how do we design and build reliable concurrent systems". My use of Erlang for this paper is purely pragmatic. I have considered and dismissed C (although POSIX threads will make an appearance near the end, perhaps I should call this "C THreads, Unsafe Libraries, and Hazardous Undertakings" programming (:-)), C++, Cilk, OpenMP (although I think I do have to mention it), Ada (lots going for it including SPARK/Ada, but I'd have to spend more time teaching Ada than Erlang), Limbo, Go, Concurrent ML, Haskell, Occam, various Scheme dialects, Java, and C# amongst others. I believe Erlang will get them writing working concurrent code sooner than any of the others. Here there is a dispute between me and one of the other lecturers in the department, who will not be involved in this paper, at least not this year. I want the students to start learning about concurrent programming in a language in which data races (at least data races not involving external resources) are simply impossible. He thinks they should (a) learn what a data race looks like the hard way early on and (b) learn not be be afraid of data races, because the low level locking code on x86-64 Linux apparently has a benign data race. "How do we design and build reliable concurrent systems" is obviously an opportunity to exploit some of the hard thinking that went into Erlang/OTP and teach the "behaviours", although the first "design pattern" I want to teach is acyclic networks of pipes. The question is "how do we look at a problem and see the concurrency there", and if anyone has any recommendations I'd be very pleased to get them. A *huge* thank you to Joe Armstrong and the Erlang/OTP team for all their work. From kostis@REDACTED Mon Feb 8 01:03:28 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 08 Feb 2010 02:03:28 +0200 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> Message-ID: <4B6F54D0.9030304@cs.ntua.gr> Richard O'Keefe wrote: > ... > Here there is a dispute between me and one of the other lecturers > in the department, who will not be involved in this paper, at least > not this year. I want the students to start learning about > concurrent programming in a language in which data races (at least > data races not involving external resources) are simply impossible. It is true that Erlang offers a lot of advantages w.r.t. concurrency and is a very attractive choice for teaching about concurrent programming to students. However, because of the existence of BIFs and internal data structures shared by all processes, it is NOT "a language in which data races are simply impossible". A recent paper on how dialyzer was extended to detect data races in Erlang (cf. the new dialyzer option -Wrace_conditions) elaborates more on some of the kinds of data races possible in Erlang. The paper is accessible at: http://www.it.uu.se/research/group/hipe/dialyzer/publications/races.pdf Kostis From ok@REDACTED Mon Feb 8 02:58:17 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 8 Feb 2010 14:58:17 +1300 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <4B6F54D0.9030304@cs.ntua.gr> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <4B6F54D0.9030304@cs.ntua.gr> Message-ID: On Feb 8, 2010, at 1:03 PM, Kostis Sagonas wrote: > It is true that Erlang offers a lot of advantages w.r.t. concurrency > and is a very attractive choice for teaching about concurrent > programming to students. However, because of the existence of BIFs > and internal data structures shared by all processes, it is NOT "a > language in which data races are simply impossible". Ah. Yes, I see what you mean. I never did like the registry, in fact I criticised it on these grounds, in what, 1997? And I was extremely critical of a metastasis of similar registries in the ISO Prolog threading proposal. I wasn't going to teach them about the registry, and I was proposing to mention ETS/DETS/Mnesia, if at all, together with external files, and treat the consequent races as a coherent group of "access to external data" problems. So it would be more accurate to say that "the subset of Erlang I propose to teach can only have data races when accessing external resources, and this is a large enough subset to be practically useful and interesting." Thanks for the reminder, though. I really _must_ introduce the students to the Dialyzer, and I had forgotten to put that in the list of topics. I presume it's ok to hand out copies of that article in the class? From enewhuis@REDACTED Mon Feb 8 05:25:48 2010 From: enewhuis@REDACTED (Eric Newhuis) Date: Sun, 7 Feb 2010 22:25:48 -0600 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <4B6F54D0.9030304@cs.ntua.gr> Message-ID: <8B96E05C-25CA-4EB0-A4C1-39AB3336EBC7@gmail.com> Mnesia is very good to mention. I'll bet there may also be some interest among students for map/reduce style databases. What might be fun for students is to actually build one--a distributed map/reduce. That'd teach some aspect of the database concept, the Erlang grammar, and get them thinking in distributed terms all in one fell swoop maybe. On Feb 7, 2010, at 7:58 PM, Richard O'Keefe wrote: > > On Feb 8, 2010, at 1:03 PM, Kostis Sagonas wrote: >> It is true that Erlang offers a lot of advantages w.r.t. concurrency and is a very attractive choice for teaching about concurrent programming to students. However, because of the existence of BIFs and internal data structures shared by all processes, it is NOT "a language in which data races are simply impossible". > > Ah. Yes, I see what you mean. I never did like the registry, in fact > I criticised it on these grounds, in what, 1997? And I was extremely > critical of a metastasis of similar registries in the ISO Prolog > threading proposal. > > I wasn't going to teach them about the registry, and I was proposing to > mention ETS/DETS/Mnesia, if at all, together with external files, > and treat the consequent races as a coherent group of "access to external > data" problems. > > So it would be more accurate to say that "the subset of Erlang I propose > to teach can only have data races when accessing external resources, and > this is a large enough subset to be practically useful and interesting." > > Thanks for the reminder, though. I really _must_ introduce the students > to the Dialyzer, and I had forgotten to put that in the list of topics. > > I presume it's ok to hand out copies of that article in the class? > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From mononcqc@REDACTED Mon Feb 8 06:07:19 2010 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 8 Feb 2010 00:07:19 -0500 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> Message-ID: <8b9ee55b1002072107o6c4d0e2al6c58b8143300ca87@mail.gmail.com> I have found many of the lessons from the 1996 book (Concurrent Programmin in ERLANG, by Armstrong, Virding, Wikstr?m and Williams) to be pretty good to teach the fundamentals of some concurrent and distributed computing. If I recall correctly, the concurrent part showed how to use the basic Erlang stuff (mailboxes, spawning processes, etc.). It showed inter-process communication through FSMs, the client-server model, etc. The chapter about Distributed Programming Techinques (ch. 11, p.258) basically showed how to implement the rpc module, how to broadcast message, lets the user implement the 'global' module, process groups (with leader election), promises, how to attain basic redundancy with many nodes, basic load distribution, etc. The following chapter (Distributed Data, p.184) discusses how to handle concurrency and data race conditions by using timestamps, clocks, transactions, and so on. I'm certainly not a professional of distributed computing nor a teacher. I also know time is probably short if you do need to show the language to the students (it took me a few months to write my guide on the very basics of sequential Erlang). However, these parts of the book really showed what I could consider core issues when building applications on top of a concurrent or distributed system. Maybe showing students how a few of the standard library modules are implemented would be something useful. It did seem to work well in the book. On Sun, Feb 7, 2010 at 6:14 PM, Richard O'Keefe wrote: > This year I am in the happy position of teaching a paper on > concurrent programming. I propose to start by teaching Erlang, > as being by far the simplest concurrent programming language I > know (except possibly Occam, but while the restrictions in > Occam are _motivated_, they are still quite painful, and make > the language harder to use). > > However, I've never actually _taught_ Erlang before. > These are 4th year students with Java and C. Last year in a > class at the same level one group did an assignment in Erlang > without needing to be taught. > > Has anyone tried more than one Erlang book? What works well? > > I propose to explain Erlang as > - take a minimal programming language (which means > pretty much lambda calculus) > - add a few simple data structures (integers, floats, > lists, tuples, atoms) > - add pattern matching > - add minimal support for concurrency > (processes and process IDs, !, receive) > - add support for large scale programming (modules) > - add support for practical programming (testing, debugging, > monitoring, most of which I don't plan to cover) > - add support for distribution > (nodes, unreliable messaging, timeouts, &c) > - add support for persistent data (might/might not mention) > but I'm really only interested in Erlang as a means to an end. > > What I am *really* interested in is "how do we design and build > reliable concurrent systems". My use of Erlang for this paper is > purely pragmatic. I have considered and dismissed C (although > POSIX threads will make an appearance near the end, perhaps I > should call this "C THreads, Unsafe Libraries, and Hazardous > Undertakings" programming (:-)), C++, Cilk, OpenMP (although I > think I do have to mention it), Ada (lots going for it including > SPARK/Ada, but I'd have to spend more time teaching Ada than Erlang), > Limbo, Go, Concurrent ML, Haskell, Occam, various Scheme dialects, > Java, and C# amongst others. I believe Erlang will get them writing > working concurrent code sooner than any of the others. > > Here there is a dispute between me and one of the other lecturers > in the department, who will not be involved in this paper, at least > not this year. I want the students to start learning about > concurrent programming in a language in which data races (at least > data races not involving external resources) are simply impossible. > He thinks they should (a) learn what a data race looks like the hard > way early on and (b) learn not be be afraid of data races, because > the low level locking code on x86-64 Linux apparently has a benign > data race. > > "How do we design and build reliable concurrent systems" is obviously > an opportunity to exploit some of the hard thinking that went into > Erlang/OTP and teach the "behaviours", although the first "design > pattern" I want to teach is acyclic networks of pipes. The question is > "how do we look at a problem and see the concurrency there", and if > anyone has any recommendations I'd be very pleased to get them. > > A *huge* thank you to Joe Armstrong and the Erlang/OTP team for > all their work. > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From erlang@REDACTED Mon Feb 8 10:18:38 2010 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 8 Feb 2010 10:18:38 +0100 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> Message-ID: <9b08084c1002080118wbc27ed8k9a5de171036fb56d@mail.gmail.com> Hi Richard, Error detection and recovery seems to be conspicuously absent from your list. I often think the way we do errors is the most misunderstood part of Erlang. If you have a system with large numbers of small processes, having a few die is no big deal. All you do is detect these errors *somewhere else* and let the process that detects the error perform the corrective action. "Somewhere else" being on a physically different machine is the basis for building fault-tolerant systems. In sequential languages error avoidance is a huge deal - if you have only one process and it crashes you are are screwed. Thus in C, avoiding errors is an enormous deal. The entire school of "defensive programming" comes from the idea that if you only have one process you'd better take enormous steps to make sure it doesn't crash. Not so in Erlang. The notion of an error-detection mechanism that works across machine boundaries is the key idea in Erlang. link/spawn_link/trap_errors/monitor does the magic stuff. I think this point should be hammered home early and often. "To build a fault-tolerant system you need at least two machines" "Let it crash" /Joe On Mon, Feb 8, 2010 at 12:14 AM, Richard O'Keefe wrote: > This year I am in the happy position of teaching a paper on > concurrent programming. ?I propose to start by teaching Erlang, > as being by far the simplest concurrent programming language I > know (except possibly Occam, but while the restrictions in > Occam are _motivated_, they are still quite painful, and make > the language harder to use). > > However, I've never actually _taught_ Erlang before. > These are 4th year students with Java and C. ?Last year in a > class at the same level one group did an assignment in Erlang > without needing to be taught. > > Has anyone tried more than one Erlang book? ?What works well? > > I propose to explain Erlang as > ? ? ? ?- take a minimal programming language (which means > ? ? ? ? ?pretty much lambda calculus) > ? ? ? ?- add a few simple data structures (integers, floats, > ? ? ? ? ?lists, tuples, atoms) > ? ? ? ?- add pattern matching > ? ? ? ?- add minimal support for concurrency > ? ? ? ? ?(processes and process IDs, !, receive) > ? ? ? ?- add support for large scale programming (modules) > ? ? ? ?- add support for practical programming (testing, debugging, > ? ? ? ? ?monitoring, most of which I don't plan to cover) > ? ? ? ?- add support for distribution > ? ? ? ? ?(nodes, unreliable messaging, timeouts, &c) > ? ? ? ?- add support for persistent data (might/might not mention) > but I'm really only interested in Erlang as a means to an end. > > What I am *really* interested in is "how do we design and build > reliable concurrent systems". ?My use of Erlang for this paper is > purely pragmatic. ?I have considered and dismissed C (although > POSIX threads will make an appearance near the end, perhaps I > should call this "C THreads, Unsafe Libraries, and Hazardous > Undertakings" programming (:-)), C++, Cilk, OpenMP (although I > think I do have to mention it), Ada (lots going for it including > SPARK/Ada, but I'd have to spend more time teaching Ada than Erlang), > Limbo, Go, Concurrent ML, Haskell, Occam, various Scheme dialects, > Java, and C# amongst others. ?I believe Erlang will get them writing > working concurrent code sooner than any of the others. > > Here there is a dispute between me and one of the other lecturers > in the department, who will not be involved in this paper, at least > not this year. ?I want the students to start learning about > concurrent programming in a language in which data races (at least > data races not involving external resources) are simply impossible. > He thinks they should (a) learn what a data race looks like the hard > way early on and (b) learn not be be afraid of data races, because > the low level locking code on x86-64 Linux apparently has a benign > data race. > > "How do we design and build reliable concurrent systems" is obviously > an opportunity to exploit some of the hard thinking that went into > Erlang/OTP and teach the "behaviours", although the first "design > pattern" I want to teach is acyclic networks of pipes. ?The question is > "how do we look at a problem and see the concurrency there", and if > anyone has any recommendations I'd be very pleased to get them. > > A *huge* thank you to Joe Armstrong and the Erlang/OTP team for > all their work. > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ulf.wiger@REDACTED Mon Feb 8 10:33:23 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 08 Feb 2010 10:33:23 +0100 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> Message-ID: <4B6FDA63.4060602@erlang-solutions.com> Richard O'Keefe wrote: > > Here there is a dispute between me and one of the other lecturers > in the department, who will not be involved in this paper, at least > not this year. I want the students to start learning about > concurrent programming in a language in which data races (at least > data races not involving external resources) are simply impossible. > He thinks they should (a) learn what a data race looks like the hard > way early on and (b) learn not be be afraid of data races, because > the low level locking code on x86-64 Linux apparently has a benign > data race. Kostis has alreay mentioned that data races are possible in Erlang. One possible benefit of using your approach is that it can highlight that race conditions come in different forms. Some are part of the problem domain (e.g. handshakes in peer-to-peer networks, credit card transaction processing, session management in messaging systems in general, etc.) while others are accidental - a consequence of the chosen implementation technique. I would think that reasoning about the high-level races provides an ample foundation for talking about low-level data races. BTW, which mutual exclusion techniques can not be illustrated in Erlang? I've seen many examples of programmers trying to wish away races by e.g. changing calls to casts, failing to recognize that they simply made potential deadlocks etc. harder to diagnose. The proper way to address race conditions, IMHO, is from the top down, and if you start with a language that causes lots of accidental complexity, chances are that you will end up covering much less ground. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From ktoumura@REDACTED Mon Feb 8 14:16:33 2010 From: ktoumura@REDACTED (=?ISO-2022-JP?B?GyRCRWxCPEsuSScbKEI=?=) Date: Mon, 8 Feb 2010 22:16:33 +0900 Subject: Strange behavior of http:request/4 Message-ID: <53c3bdd71002080516j44ffd38auc1b08b8656846371@mail.gmail.com> Hi I just found strange behavior of http:request/4. When I tried to retrieve a missing content with {sync, false} and {stream, {self,once}} options, http:request/4 sent two messages like following. {http,{#Ref<...>, stream, <<"\n">>}} {http,{#Ref<...>, {{"HTTP/1.1",404,"Not Found"}, [{"connection","Keep-Alive"}, ...}], <<>>}}} There is no "stream_start/end" message, but there is "stream" message. And, in the second message, a body part is empty. In the inets reference manual, it says that "stream: Streams the body of a 200 or 206 response to the calling process or to a file". So, I think it should return just one message like following {http,{#Ref<...>, {{"HTTP/1.1",404,"Not Found"}, [{"connection","Keep-Alive"}, ...}], <<"\n">>}}} (because it is impossible to return a status code when using "stream*" messages) A console output is below. ------ $ erl Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false] Eshell V5.7.4 (abort with ^G) 1> inets:start(). ok 2> http:request(get,{"http://www.erlang.org/no_such_file",[]},[],[{sync,false},{stream,{self,once}}]). {ok,#Ref<0.0.0.68>} 3> flush(). Shell got {http,{#Ref<0.0.0.68>,stream, <<"\n\n404 Not Found\n\n

Not Found

\nThe requested URL /no_such_file was not found on this server.

\n

\n
Apache/1.3.29 Server at www.erlang.org Port 80
\n\n">>}} Shell got {http,{#Ref<0.0.0.68>, {{"HTTP/1.1",404,"Not Found"}, [{"connection","Keep-Alive"}, {"date","Mon, 08 Feb 2010 12:13:51 GMT"}, {"server","Apache"}, {"content-length","277"}, {"content-type","text/html; charset=iso-8859-1"}, {"keep-alive","timeout=35, max=99"}], <<>>}}} ok ------ -- Kunihiko Toumura ktoumura@REDACTED From rickard@REDACTED Mon Feb 8 15:55:45 2010 From: rickard@REDACTED (Rickard Green) Date: Mon, 08 Feb 2010 15:55:45 +0100 Subject: [erlang-questions] Problems cross compiling: eheap_alloc: Cannot reallocate 3480006320 bytes of memory In-Reply-To: <4B6C377F.1020701@erlang.org> References: <10d7e35f1002031827r4ca30cbco39fbd488b554a799@mail.gmail.com> <4B6C377F.1020701@erlang.org> Message-ID: <4B7025F1.6050305@erlang.org> The fix is now available in the ccase/r13b04_dev branch at github. If the fix doesn't solve your problem, please send me the $ERL_TOP/erts/config.log file and the complete printout (stdout) from your configure run. Some changes has been made in xcomp/README, so it might be worth having a look at the diff. The bug was that configure checked for large file support using `getconf' for the build machine. This can cause 8 byte off_t for the target machine when 4 byte off_t should be used. The fix tries to figure out how to enable large file support using a `getconf' for the target machine (or by user input). That is, if you get an 8 byte off_t it isn't necessarily wrong. It then probably succeeded in figuring out how to enable large file support. Regards, Rickard Rickard Green wrote: > I found a bug that can cause `configure' to detect wrong size of `off_t' > when cross compiling. I'll fix it and inform you when the fix has > appeared in r13b04_dev (probably monday next week). > > I'm not to fond of adding ac_cv_sizeof_* to the xcomp-conf files. > `configure' should be able to figure these things out. If `configure' > doesn't, it is a bug that should be fixed (and you can always pass the > value on the command line, or in the environment as a workaround until > the bug has been fixed). > > Regards, > Rickard > > Winston Smith wrote: >> This is *exactly* what I did, and with what's in r13b04_dev I got it >> working on the avr32-linux platform (NGW100) pretty easily. I'm just >> in the process of preparing a patch that includes a xcomp/.conf file >> for avr32-linux for submission to erlang-patches. >> >> The new system works really well, the only thing I had to do was set >> the environment variable ac_cv_sizeof_off_t to 4 as configure can't >> figure it out and picks 8 (incorrectly). >> >> I noticed in the xcomp/README that you suggest updating otp_build to >> include new settings such as this, so I'm adding new settings for >> ac_cv_sizeof_off_t and also ac_cv_sizeof_size_t so they can more >> easily be customized in the .conf file. >> >> Many thanks and a great job on significantly improving the cross >> compilation support for Erlang! >> >> >> Winston. >> >> On Wed, Feb 3, 2010 at 9:27 PM, Rickard Green wrote: >>> Current cross compiling support has lots of issues. I'd recommend that >>> you wait for the R13B04 release if you want to cross compile >>> Erlang/OTP. >>> >>> The upcoming R13B04 release will have much better support for cross >>> compiling. I've just committed a bunch of cross fixes in the r13b04 >>> development branch which are available at >>> (ccase/r13b04_dev branch). If you want >>> to try it out, have a look at the xcomp/README >>> >>> since lots of things have changed regarding cross compiling since >>> R13B03. >>> >>> If you get it working with r13b04_dev, the configure results from >>> r13b04_dev may give you a hint about what is wrong with the R13B03 >>> configuration. However, I'd still recommend that you wait for the >>> R13B04 release. >>> >>> Regards, >>> Rickard Green, Erlang/OTP, Ericsson AB. >>> >>> 2010/1/29 Winston Smith : >>>> Trying to run a cross compiled version of R13B03 on an AVR32-Linux >>>> system (NGW100/buildroot-2.3.0) I get the following: >>>> >>>> /home/avr32 # erl >>>> >>>> Crash dump was written to: erl_crash.dump >>>> eheap_alloc: Cannot reallocate 3480006320 bytes of memory (of type >>>> "heap"). >>>> Aborted >>>> >>>> >>>> I've had this working before (I think with R13B01) but I've since >>>> upgraded my build host from Ubuntu 9.04 to 9.10. I actually had this >>>> same issue originally, and I somehow solved it, but I can't for the >>>> life of me remember what I did. I am setting up an xconf file with >>>> the proper values for size_t, off_t, big endian etc; in fact I based >>>> my build script on Brian Zhou's script for building Erlang on NSLU2 >>>> Linux: >>>> >>>> http://svn.nslu2-linux.org/svnroot/optware/trunk/make/erlang.mk >>>> >>>> Any thoughts on where to start debugging/diagnosing this? (the >>>> embedded gdb doesn't work) Is the erl_crash.dump useful (and how do I >>>> interpret it!)? >>>> >>>> Many thanks in advance! >>>> >>>> ________________________________________________________________ >>>> erlang-questions mailing list. See http://www.erlang.org/faq.html >>>> erlang-questions (at) erlang.org >>>> >>>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >>> >> > > -- Rickard Green, Erlang/OTP, Ericsson AB. From max.lapshin@REDACTED Mon Feb 8 18:37:34 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 8 Feb 2010 20:37:34 +0300 Subject: Erlang, Windows and PATH env Message-ID: Hi, I have to make an erlyvideo installer for windows and it is a pity for me, that installer doesn't add path to erl into PATH variables. I have either to hardcode path of erlsrv, either ask users to add to PATH. Maybe it is possible to fix the installer to next release? From anthonym@REDACTED Mon Feb 8 20:22:06 2010 From: anthonym@REDACTED (Anthony Molinaro) Date: Mon, 8 Feb 2010 11:22:06 -0800 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> Message-ID: <20100208192206.GB62679@alumni.caltech.edu> Hi Richard, I'm not an instructor but am currently almost done reading Erlang Programming, and read Programming Erlang: Software for a Concurrent World when it was released. So given that I've read both, I would probably recommend Erlang Programming as a course book. Joe's book was a great introduction to the language, while Erlang Programming seems to be much more geared towards building applications for production systems. There are often asides which describe the runtime system (how reductions work, ways to inspect processes, resource usages, etc), and examples and exercies follow a nice progression from sequential to concurrent, to process design patterns. Also, hot code loading, tracing and debugging, and unit testing each have their own chapters. Many of these topics are touched on in Programming Erlang, but the treatment in Erlang Programming is more in depth. Regardless both books are great, many thanks to Joe, Francesco and Simon. Hopefully that helps some, -Anthony On Mon, Feb 08, 2010 at 12:14:45PM +1300, Richard O'Keefe wrote: > This year I am in the happy position of teaching a paper on > concurrent programming. I propose to start by teaching Erlang, > as being by far the simplest concurrent programming language I > know (except possibly Occam, but while the restrictions in > Occam are _motivated_, they are still quite painful, and make > the language harder to use). > > However, I've never actually _taught_ Erlang before. > These are 4th year students with Java and C. Last year in a > class at the same level one group did an assignment in Erlang > without needing to be taught. > > Has anyone tried more than one Erlang book? What works well? > > I propose to explain Erlang as > - take a minimal programming language (which means > pretty much lambda calculus) > - add a few simple data structures (integers, floats, > lists, tuples, atoms) > - add pattern matching > - add minimal support for concurrency > (processes and process IDs, !, receive) > - add support for large scale programming (modules) > - add support for practical programming (testing, debugging, > monitoring, most of which I don't plan to cover) > - add support for distribution > (nodes, unreliable messaging, timeouts, &c) > - add support for persistent data (might/might not mention) > but I'm really only interested in Erlang as a means to an end. > > What I am *really* interested in is "how do we design and build > reliable concurrent systems". My use of Erlang for this paper is > purely pragmatic. I have considered and dismissed C (although > POSIX threads will make an appearance near the end, perhaps I > should call this "C THreads, Unsafe Libraries, and Hazardous > Undertakings" programming (:-)), C++, Cilk, OpenMP (although I > think I do have to mention it), Ada (lots going for it including > SPARK/Ada, but I'd have to spend more time teaching Ada than Erlang), > Limbo, Go, Concurrent ML, Haskell, Occam, various Scheme dialects, > Java, and C# amongst others. I believe Erlang will get them writing > working concurrent code sooner than any of the others. > > Here there is a dispute between me and one of the other lecturers > in the department, who will not be involved in this paper, at least > not this year. I want the students to start learning about > concurrent programming in a language in which data races (at least > data races not involving external resources) are simply impossible. > He thinks they should (a) learn what a data race looks like the hard > way early on and (b) learn not be be afraid of data races, because > the low level locking code on x86-64 Linux apparently has a benign > data race. > > "How do we design and build reliable concurrent systems" is obviously > an opportunity to exploit some of the hard thinking that went into > Erlang/OTP and teach the "behaviours", although the first "design > pattern" I want to teach is acyclic networks of pipes. The question is > "how do we look at a problem and see the concurrency there", and if > anyone has any recommendations I'd be very pleased to get them. > > A *huge* thank you to Joe Armstrong and the Erlang/OTP team for > all their work. > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- ------------------------------------------------------------------------ Anthony Molinaro From jay@REDACTED Mon Feb 8 21:46:38 2010 From: jay@REDACTED (Jay Nelson) Date: Mon, 8 Feb 2010 12:46:38 -0800 Subject: Teaching Erlang as part of a paper -- advice sought Message-ID: Richard wrote: > The question is "how do we look at a problem and see the > concurrency there", and if anyone has any recommendations > I'd be very pleased to get them. I have always concentrated on "processing granularity" for concurrency. To get multiple things done simultaneously, it is essential that there are no dependencies among them. The idea is to reduce any block of code to the minimal amount that (a) computes a particular task result or performs a verifiable task and (b) can succinctly communicate that result to another piece of the system. There is a three way trade off of processing time, memory used, and communication bandwidth. If any of these three become a bottleneck, the code is pushed into the other two. Trading processing time for memory and communication is a form of compression. Trading memory and communication for processing time is a form of resiliency or responsiveness (two separate concepts). When the granularity of processes is small enough, they fit more tightly in a container just like sand versus pebbles in a jar. Failure of a process is easier to deal with because the scope of the concept it covers is smaller, and the ability to reason about the recovery replacement is simpler. If many processes are progressing while a few fail and recover, the impact is not really noticeable in the system as a whole. Granularity of computation, data and communication is in my mind the essence of concurrency. jay From ok@REDACTED Mon Feb 8 23:53:19 2010 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 9 Feb 2010 11:53:19 +1300 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <9b08084c1002080118wbc27ed8k9a5de171036fb56d@mail.gmail.com> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <9b08084c1002080118wbc27ed8k9a5de171036fb56d@mail.gmail.com> Message-ID: On Feb 8, 2010, at 10:18 PM, Joe Armstrong wrote: > Hi Richard, > > Error detection and recovery seems to be conspicuously absent from > your list. From the list, yes, from my thoughts, no. In fact just after sending that message I looked at it with some annoyance and realised I'd left that out. I even had another "essence of Erlang" draft which had it in! If I were trying sufficiently hard to wriggle out of looking stupid, I'd say "I did mention building RELIABLE systems". But I'm not that kind of person (:-) (:-). > I think this point should be hammered home early and often. > > "To build a fault-tolerant system you need at least two machines" > "Let it crash" > There was something bothering me about everything else I looked at, including Google's "go". I couldn't put my finger on it. THAT's what bothered me. Yes, Joe, you're right, and this is PRECISELY the kind of advice I needed. This is EXACTLY the thing you don't find in the courses I had been looking at. It's fairly conventional to start a concurrent programming paper with very much a "single system" mindset and then move on to distribution later. I was already planning to *start* with distribution as the model, and touch on CTHULHU programming later. And of course doing it this way around will make it much much easier for me to follow your "this point ... early" advice. From ok@REDACTED Tue Feb 9 00:12:30 2010 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 9 Feb 2010 12:12:30 +1300 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <4B6FDA63.4060602@erlang-solutions.com> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <4B6FDA63.4060602@erlang-solutions.com> Message-ID: <2E085E87-855D-4C26-983E-46A43E1ED4ED@cs.otago.ac.nz> On Feb 8, 2010, at 10:33 PM, Ulf Wiger wrote: > Kostis has alreay mentioned that data races are possible in Erlang. I am dusting off my old 'pid_name' proposal from the 90s and turning it into an EEP. I'd like to avoid races in the core language. > > One possible benefit of using your approach is that it can highlight > that race conditions come in different forms. Some are part of the > problem domain (e.g. handshakes in peer-to-peer networks, credit > card transaction processing, session management in messaging systems > in general, etc.) while others are accidental - a consequence of the > chosen implementation technique. I would think that reasoning about > the high-level races provides an ample foundation for talking about > low-level data races. I was proposing to have a couple of lectures about modelling systems in some sort of process calculus. Because I know NuSMV, that's what I was planning to use. I've always been very impressed by the work Thomas Arts and his colleagues did, but the latest version of EVT I can find is 2001, and since then, not only have Linux and Solaris and Java changed, so has Erlang changed. Ulf, can you recommend anything I should look at to understand the issues in "(e.g. handshakes in peer-to-peer networks, credit > card transaction processing, session management in messaging systems > in general, etc.)"? > BTW, which mutual exclusion techniques > can not be illustrated in Erlang? None that I know of. At least, no _high level_ ones. If you want to demonstrate how, e.g., spin-locks _work_ at a low level, that's another matter. From smith.winston.101@REDACTED Tue Feb 9 00:17:08 2010 From: smith.winston.101@REDACTED (Winston Smith) Date: Mon, 8 Feb 2010 18:17:08 -0500 Subject: [erlang-questions] Problems cross compiling: eheap_alloc: Cannot reallocate 3480006320 bytes of memory In-Reply-To: <4B7025F1.6050305@erlang.org> References: <10d7e35f1002031827r4ca30cbco39fbd488b554a799@mail.gmail.com> <4B6C377F.1020701@erlang.org> <4B7025F1.6050305@erlang.org> Message-ID: On Mon, Feb 8, 2010 at 9:55 AM, Rickard Green wrote: > The fix is now available in the ccase/r13b04_dev branch at github. If the > fix doesn't solve your problem, please send me the $ERL_TOP/erts/config.log > file and the complete printout (stdout) from your configure run. It works well now, thank you. I did see an error about missing headers (sorry, I don't have the exact message), but that could've been because I have done previous builds with the old mechanism. It did seem to go away after I ran: ./otp_build autoconf --xcomp-conf= I don't know if this fixed it or not; it's no longer mentioned in the xcomp/README. Is there an easy way to reset my git working directory to remove any previous autoconf/configure junk (aside from doing a clean clone of the repo)? > Some changes has been made in xcomp/README, so it might be worth having a > look at the diff. I updated my .conf file based on the updated examples you have there, it looks much more straightforward now. I did notice a couple of things in the xcomp/README. Firstly, you now describe the two ways of building, using configure or using otp_build -- it wasn't immediately obvious what the differences and why I'd use one vs the other until I'd read in more detail. Secondly, you have a typo on line 225; you say the command line for otp_build configure has --with-xcomp-conf= when it's really just --xcomp-conf=. Also, the script doesn't seem to expand a ~ in the filename, not a big deal though. > The bug was that configure checked for large file support > using `getconf' for the build machine. This can cause 8 byte off_t for the > target machine when 4 byte off_t should be used. The fix tries to figure out > how to enable large file support using a `getconf' for the target machine > (or by user input). That is, if you get an 8 byte off_t it isn't necessarily > wrong. It then probably succeeded in figuring out how to enable large file > support. This is fixed (at least for avr32-linux), it correctly detected the size of off_t as 4. Many thanks! From bernie@REDACTED Tue Feb 9 02:04:14 2010 From: bernie@REDACTED (Bernard Duggan) Date: Tue, 09 Feb 2010 12:04:14 +1100 Subject: Watching mnesia transactions Message-ID: <4B70B48E.7080206@m5net.com> Hi all, Bit of a complex mnesia question here. First, I need to describe what we want to do: For reasons of interacting with a legacy system (which I'll call "L") we want to be able to track changes to certain of our mnesia tables, and send those changes off so L can update its own copy of the data. Sadly, it's thoroughly impractical to remove the local copy in L, so we're pretty much stuck with this approach for now. I'll explain the approaches we've tried so far and the problems we've had - hopefully someone can either suggest where our thinking has gone astray, or an entirely different system :) Attempt 1: Using mnesia:subscribe({mnesia_table_event...}), we watch for table events and send them off to L. That's very nice and simple, except there's no way we can see to group transaction events together - every table event has its own ActivityID, certainly, but how do you know when all the events for a given ActivityID have arrived? This seems like a pretty serious limitation on what otherwise is a very handy system. Attempt 2: Use the mnesia_access callback module and mnesia:activity(transaction...). Here, we've done the following: * Prior to each mnesia:activity call, we set up an ETS table and throw it in the process dictionary. * In the transaction function we first empty the ETS table (to ensure that if the transaction restarts, the table will be cleared) * In the activity callback functions we record to the ETS table each write/delete event that takes place on mnesia. * When the transaction successfully completes, we can dump that table to get a full record of write events, grouped as a transaction, and throw those to L. We were really happy with that implementation until I realised a minor problem with it this morning: The posting of events to L happens /after/ the transaction completes. Consider the case of two transactions, T1 and T2 in separate processes which both modify the same row. You could then have the case where: * T1 runs * T2 runs * T2 sends its change to L * T1 sends its older change to L If, alternatively, we do the posting inside the transaction, even as the last operation, it seems like it might be possible for the transaction to restart after the post and get us in all kinds of trouble. We've come up with a number of elaborate modifications to this plan to resolve the issue, but I can't help but think we're missing something obvious (or non-obvious). After all, mnesia knows full well what's gone on and in what order, so why do we seem to need to go to such lengths to reconstruct that information? I've slightly simplified this to keep it relatively short, so I'll apologise in advance if any of your questions are answered with "yeah we already thought of that and with won't work/doesn't apply because blah blah" :) Thanks for reading this far :) Cheers, Bernard From gliptak@REDACTED Tue Feb 9 02:47:35 2010 From: gliptak@REDACTED (=?ISO-8859-1?B?R+Fib3IgTGlwdOFr?=) Date: Mon, 8 Feb 2010 20:47:35 -0500 Subject: [erlang-questions] Re: jinterface.jar in the Maven repository? In-Reply-To: <944da41d1002060643y3c1f7754u3d22ff7e88d88963@mail.gmail.com> References: <3c64b6c31002021752k3fe9564cnf94e2885ecaf44a9@mail.gmail.com> <20100205085519.GA29445@erix.ericsson.se> <3c64b6c31002051432q78abb48emafe623c67c3d02f9@mail.gmail.com> <944da41d1002060643y3c1f7754u3d22ff7e88d88963@mail.gmail.com> Message-ID: <3c64b6c31002081747v53050be4qb17b432c5422c0b2@mail.gmail.com> I uploaded a snapshot to: http://oss.sonatype.org/content/repositories/snapshots/org/erlang/otp/jinterface/1.5.1-SNAPSHOT/ Waiting for project admins to learn how to proceed with a released version. On Sat, Feb 6, 2010 at 09:43, Alex Arnon wrote: > +1 indeed!!! > > In my project ('jports' on Google Code, warning - Work In Progress :) ), I > am forced to instruct the user to copy java_src directly to a jinterface > artifact, due to the license. This is inconvenient and breaks the common > expectation that a Maven project should be one-click-buildable anywhere. > > > On Sat, Feb 6, 2010 at 7:10 AM, Jayson Vantuyl wrote: > > > +1 > > > > On Feb 5, 2010, at 2:32 PM, G?bor Lipt?k wrote: > > > > > In order to make Java/Erlang projects easier to develop and package, > > > "official" jinterface.jar could be uploaded to Maven and uses as a > > > dependency for Java builds. > > > > > > Here is a description on the process: > > > > > > https://docs.sonatype.com/display/NX/OSS+Repository+Hosting > > > > > > this would require participation from domain/project owners. I would be > > > happy to facilitate the process and prepare Maven related artifacts > > needed. > > > > > > Is there an interest in this? > > > > > > Thank you > > > > -- > > Jayson Vantuyl > > kagato@REDACTED > > > > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > See http://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > > > From dgud@REDACTED Tue Feb 9 08:49:45 2010 From: dgud@REDACTED (Dan Gudmundsson) Date: Tue, 9 Feb 2010 08:49:45 +0100 Subject: [erlang-questions] Watching mnesia transactions In-Reply-To: <4B70B48E.7080206@m5net.com> References: <4B70B48E.7080206@m5net.com> Message-ID: <93df43b61002082349m1cbc77bk5827b00c2a51e337@mail.gmail.com> There is no way to get that info today without patching mnesia, I think a variant of 'mnesia:subscribe' is the best solution. /Dan On Tue, Feb 9, 2010 at 2:04 AM, Bernard Duggan wrote: > Hi all, > ? ?Bit of a complex mnesia question here. ?First, I need to describe > what we want to do: > > ? ?For reasons of interacting with a legacy system (which I'll call > "L") we want to be able to track changes to certain of our mnesia > tables, and send those changes off so L can update its own copy of the > data. ?Sadly, it's thoroughly impractical to remove the local copy in L, > so we're pretty much stuck with this approach for now. ?I'll explain the > approaches we've tried so far and the problems we've had - hopefully > someone can either suggest where our thinking has gone astray, or an > entirely different system :) > > > Attempt 1: > Using mnesia:subscribe({mnesia_table_event...}), we watch for table > events and send them off to L. ?That's very nice and simple, except > there's no way we can see to group transaction events together - every > table event has its own ActivityID, certainly, but how do you know when > all the events for a given ActivityID have arrived? ?This seems like a > pretty serious limitation on what otherwise is a very handy system. > > > Attempt 2: > Use the mnesia_access callback module and > mnesia:activity(transaction...). ?Here, we've done the following: > * Prior to each mnesia:activity call, we set up an ETS table and throw > it in the process dictionary. > * In the transaction function we first empty the ETS table (to ensure > that if the transaction restarts, the table will be cleared) > * In the activity callback functions we record to the ETS table each > write/delete event that takes place on mnesia. > * When the transaction successfully completes, we can dump that table to > get a full record of write events, grouped as a transaction, and throw > those to L. > > We were really happy with that implementation until I realised a minor > problem with it this morning: > The posting of events to L happens /after/ the transaction completes. > Consider the case of two transactions, T1 and T2 in separate processes > which both modify the same row. ?You could then have the case where: > * T1 runs > * T2 runs > * T2 sends its change to L > * T1 sends its older change to L > If, alternatively, we do the posting inside the transaction, even as the > last operation, it seems like it might be possible for the transaction > to restart after the post and get us in all kinds of trouble. > > We've come up with a number of elaborate modifications to this plan to > resolve the issue, but I can't help but think we're missing something > obvious (or non-obvious). ?After all, mnesia knows full well what's gone > on and in what order, so why do we seem to need to go to such lengths to > reconstruct that information? > > > I've slightly simplified this to keep it relatively short, so I'll > apologise in advance if any of your questions are answered with "yeah we > already thought of that and with won't work/doesn't apply because blah > blah" :) > > Thanks for reading this far :) > > Cheers, > > Bernard > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ulf.wiger@REDACTED Tue Feb 9 09:36:35 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 09 Feb 2010 09:36:35 +0100 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <2E085E87-855D-4C26-983E-46A43E1ED4ED@cs.otago.ac.nz> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <4B6FDA63.4060602@erlang-solutions.com> <2E085E87-855D-4C26-983E-46A43E1ED4ED@cs.otago.ac.nz> Message-ID: <4B711E93.8030000@erlang-solutions.com> Richard O'Keefe wrote: > > On Feb 8, 2010, at 10:33 PM, Ulf Wiger wrote: >> Kostis has alreay mentioned that data races are possible in Erlang. > > I am dusting off my old 'pid_name' proposal from the 90s and turning > it into an EEP. I'd like to avoid races in the core language. Some of the issues in the EEP were also dealt with in my gproc paper (http://portal.acm.org/citation.cfm?id=1292522, also http://svn.ulf.wiger.net/gproc/trunk/gproc/doc/erlang07-wiger.pdf). I solved the race problem on registration by only allowing a process to register itself. There is still a race in the sense that two processes may contend for the same name, or that a registered process may die before a "registered send" is delivered, but this is, I think, an unavoidable part of the semantics of referring to processes by name, combined with dynamic typing and asynchronous message passing. >> One possible benefit of using your approach is that it can highlight >> that race conditions come in different forms. Some are part of the >> problem domain (e.g. handshakes in peer-to-peer networks, credit >> card transaction processing, session management in messaging systems >> in general, etc.) while others are accidental - a consequence of the >> chosen implementation technique. I would think that reasoning about >> the high-level races provides an ample foundation for talking about >> low-level data races. > > I was proposing to have a couple of lectures about modelling systems > in some sort of process calculus. Because I know NuSMV, that's what > I was planning to use. I've always been very impressed by the work > Thomas Arts and his colleagues did, but the latest version of EVT I > can find is 2001, and since then, not only have Linux and Solaris > and Java changed, so has Erlang changed. On the topic of the process registry, there is also some recent QuickCheck work that might be of interest. Claessen, K., Palka, M., Smallbone, N., Hughes, J., Svensson, H., Arts, T., and Wiger, U. 2009. Finding race conditions in Erlang with QuickCheck and PULSE. SIGPLAN Not. 44, 9 (Aug. 2009), 149-160. DOI= http://doi.acm.org/10.1145/1631687.1596574 > Ulf, can you recommend anything I should look at to understand the > issues in "(e.g. handshakes in peer-to-peer networks, credit >> card transaction processing, session management in messaging systems >> in general, etc.)"? For peer-to-peer networks, the example that comes to mind is DIAMETER (RFC 3588), but there may be other examples that are less complex. One of the characteristics of peer-to-peer is that you cannot know which side will initiate a connection request - in this regard, the traditional telephony system is obviously also a peer-to-peer network. Both sides must therefore be prepared to be both "Initiator" and "Responder" in a session setup (REF 3588, Ch 5.6). The problem is somewhat compounded by the fact that the Connection Establishment Request (CER) has to be preceded by a TCP or SCTP connect to the peer's listen socket. This already establishes a low-level session between the two sides, and if both sides simultaneously connect, you will have one TCP/SCTP session too many. This must be resolved. On session management in messaging systems, this is related to the above, but I was thinking specifically of the handling of message sends in e.g. Jabber systems. There is another QuickCheck paper - not yet published, I believe - which deals with the problem that a message to a user should be delivered immediately if the recipient is on-line, but should be stored for later delivery otherwise. The problem lies in determining when it is correct to deliver or store respectively, considering that both the message delivery and logout actions are asynchronous and take significant time (as in non-zero amount of time). In more traditional settings, the POTS (Plain Old Telephony System) case includes the obviuos race condition where you place a call to someone who is busy talking or placing a call (perhaps even to you). If so, you should get a busy signal. As the two end users are not synchronized in time (except for the trivial case where you call yourseelf), this amounts to a race condition, albeit one that is part of the specification, and with a well-defined semantics. The more subtle and somewhat eerie manifestation of this is when you pick up the phone to call someone, and that someone is already at the end of the line - but you didn't hear it ring! The phone system vendors have had a long time to polish the edges of their specifications... Essentially, the system cancels out the transition states and "fast-forwards" to the most practically useful stable state. The issue of credit card transactions is sort of a grey area, as the 'specification' reflects the limitations of current technology. If your transaction is on-line, it is possible for the credit card company to perform a real-time check of your balance. But if you are off-line (or abroad, in which case the same tends to apply), you are allowed to simply sign a slip. After this, if you are disciplined enough to keep good track of your spending, the balance in your head differs from the balance in the credit card company computers*, and subsequent real-time checks cannot guarantee that you aren't already in overdraft. * ...and if not, it's likely to differ more often than not. One thing that makes Erlang a bit special compared to most other languages is that it came about as the result of extensive programming experiments on a system where these types of races (and their big brother "feature interaction") are commonplace, and inescapable. So Erlang had to have a strategy for coping with the event-state complexity explosion that is inevitable if you pick the wrong approach. There are papers at Ericsson (now surely only available as hard copy) from the late 70s written by Mike Williams, Goran Bage, Bjarne Dacker et al, outlining this. >> BTW, which mutual exclusion techniques >> can not be illustrated in Erlang? > > None that I know of. At least, no _high level_ ones. If you want > to demonstrate how, e.g., spin-locks _work_ at a low level, that's > another matter. AFAIR, there is a theorem similar to that of Turing completeness that says that any complete paradigm for mututal exclusion is sufficient to model any other complete paradigm, but I've lost the reference. But granted, it is more illustrative to experiment with spin locks in C. But this can be covered in one lecture and a subsequent lab. I recall that experience from a course in embedded systems programming. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From ulf.wiger@REDACTED Tue Feb 9 09:46:31 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 09 Feb 2010 09:46:31 +0100 Subject: [erlang-questions] Watching mnesia transactions In-Reply-To: <4B70B48E.7080206@m5net.com> References: <4B70B48E.7080206@m5net.com> Message-ID: <4B7120E7.6000807@erlang-solutions.com> The RDBMS contrib (jungerl) has some similar problems, and implemented commit/abort triggers with the help of the mnesia callback system. I ended up patching mnesia to try to come to grips with the JIT compilation of the data dictionary checks and reliable loading of the generated modules in a distributed setting as a result of _committed_ schema transactions. This was roughly the point where I called it a day and stopped working on it, as some of the robustness tests showed subtly different behaviour with and without JIT compilation. I think some of the constructs in rdbms.erl might at least get you further than you are today. BR, Ulf W Bernard Duggan wrote: > Hi all, > Bit of a complex mnesia question here. First, I need to describe > what we want to do: > > For reasons of interacting with a legacy system (which I'll call > "L") we want to be able to track changes to certain of our mnesia > tables, and send those changes off so L can update its own copy of the > data. Sadly, it's thoroughly impractical to remove the local copy in L, > so we're pretty much stuck with this approach for now. I'll explain the > approaches we've tried so far and the problems we've had - hopefully > someone can either suggest where our thinking has gone astray, or an > entirely different system :) > > > Attempt 1: > Using mnesia:subscribe({mnesia_table_event...}), we watch for table > events and send them off to L. That's very nice and simple, except > there's no way we can see to group transaction events together - every > table event has its own ActivityID, certainly, but how do you know when > all the events for a given ActivityID have arrived? This seems like a > pretty serious limitation on what otherwise is a very handy system. > > > Attempt 2: > Use the mnesia_access callback module and > mnesia:activity(transaction...). Here, we've done the following: > * Prior to each mnesia:activity call, we set up an ETS table and throw > it in the process dictionary. > * In the transaction function we first empty the ETS table (to ensure > that if the transaction restarts, the table will be cleared) > * In the activity callback functions we record to the ETS table each > write/delete event that takes place on mnesia. > * When the transaction successfully completes, we can dump that table to > get a full record of write events, grouped as a transaction, and throw > those to L. > > We were really happy with that implementation until I realised a minor > problem with it this morning: > The posting of events to L happens /after/ the transaction completes. > Consider the case of two transactions, T1 and T2 in separate processes > which both modify the same row. You could then have the case where: > * T1 runs > * T2 runs > * T2 sends its change to L > * T1 sends its older change to L > If, alternatively, we do the posting inside the transaction, even as the > last operation, it seems like it might be possible for the transaction > to restart after the post and get us in all kinds of trouble. > > We've come up with a number of elaborate modifications to this plan to > resolve the issue, but I can't help but think we're missing something > obvious (or non-obvious). After all, mnesia knows full well what's gone > on and in what order, so why do we seem to need to go to such lengths to > reconstruct that information? > > > I've slightly simplified this to keep it relatively short, so I'll > apologise in advance if any of your questions are answered with "yeah we > already thought of that and with won't work/doesn't apply because blah > blah" :) > > Thanks for reading this far :) > > Cheers, > > Bernard > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From erlang@REDACTED Tue Feb 9 10:02:27 2010 From: erlang@REDACTED (Joe Armstrong) Date: Tue, 9 Feb 2010 10:02:27 +0100 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <9b08084c1002080118wbc27ed8k9a5de171036fb56d@mail.gmail.com> Message-ID: <9b08084c1002090102s3be138bawb21572bc7f84f6ee@mail.gmail.com> On Mon, Feb 8, 2010 at 11:53 PM, Richard O'Keefe wrote: > > On Feb 8, 2010, at 10:18 PM, Joe Armstrong wrote: > >> Hi Richard, >> >> Error detection and recovery seems to be conspicuously absent from your >> list. > > From the list, yes, from my thoughts, no. > In fact just after sending that message I looked at it with some > annoyance and realised I'd left that out. ?I even had another > "essence of Erlang" draft which had it in! > > If I were trying sufficiently hard to wriggle out of looking stupid, > I'd say "I did mention building RELIABLE systems". > But I'm not that kind of person (:-) (:-). > >> I think this point should be hammered home early and often. >> >> ? ?"To build a fault-tolerant system you need at least two machines" >> ? ?"Let it crash" >> > There was something bothering me about everything else I looked at, > including Google's "go". ?I couldn't put my finger on it. > > THAT's what bothered me. > > Yes, Joe, you're right, and this is PRECISELY the kind of advice I > needed. ?This is EXACTLY the thing you don't find in the courses I > had been looking at. > > It's fairly conventional to start a concurrent programming paper with > very much a "single system" mindset and then move on to distribution > later. ?I was already planning to *start* with distribution as the > model, and touch on CTHULHU programming later. ?And of course doing > it this way around will make it much much easier for me to follow > your "this point ... early" advice. > Absolutly. One (open) question I ask when I give a lecture is the following: Suppose you want to design a system of (say) max 200 communicating nodes (or agents, or whatever), it will start with a small number of nodes (say 10) and grow with time as demand increases There could be three ways to do this: 1) design for one node and scale it up to 200 2) design for 200 nodes and scale it down to 10 3) design for an infinite (or very very large) number of nodes and scale it down to 10 Question: Is the design the same? Answer: No - I don't think so - I don't know - this is a thought experiment not a real one. I don't think you end up with the same architecture. From experience building fixed limits into anything is always wrong - if we design for an address space of zeta-bytes we won't go far wrong. (After I wrote this I checked - I was wrong - Mr. Google told me that Eric Schmidt had said that the digital data is growing at the rate of about 1 zetta byte/year) I would design for a colossal address space and scale downwards - this might be sub-optimal for small problems but who cares - "small problems are not the problem" ie small problem don't consume massive resources, so there is no point optimizing them. Big problems do - so design for the worse case and scale down. The same is true for error recovery. Want a failure probability of 10^-100? Then take 34 *independent* machines with a failure probability of 10^-3 - they chance they all fail at the same time is 10^-102. When we start talking in terms of 5_nines reliability we've missed the plot, we're walking in a forest but we don't see the trees. To make a system with 5 nines reliability we design for 1000 nines reliability and scale downwards NOT design for 3 nines and scale up. If you shift your perspective and ask how can I make things infinitely reliable, infinitely scalable and scale down you will ask the right questions and get a decent design. Then the question is "how can I make an infinity reliable or scalable system" and the answer to both questions is the same - make the bits independent. if the bits are independent you can scale them by replicating, and make them fault-tolerant (by replication). So architecturally the identification of the independent components becomes the thing you have to look for to make a scalable or fault-tolerant system. make it very scalable and you (almost) get the fault-tolerance for free (just add, links, pepper, and a bit of chilli powder, bring to the boil and stir every ten minutes till ready) /Joe > > From leap@REDACTED Tue Feb 9 10:13:49 2010 From: leap@REDACTED (Michael Turner) Date: Tue, 09 Feb 2010 09:13:49 +0000 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <4B711E93.8030000@erlang-solutions.com> Message-ID: On 2/9/2010, "Ulf Wiger" wrote: >I solved the race problem on registration by only allowing a >process to register itself. There is still a race in the sense >that two processes may contend for the same name, or that a >registered process may die before a "registered send" is delivered, >but this is, I think, an unavoidable part of the semantics of >referring to processes by name, combined with dynamic typing >and asynchronous message passing. *Sigh*. As a hack, I've been relying on the process registry for something -- luckily in a way that's not going to mean ongoing performance bottlenecks if I serialize the name registrations, since the registrations are restricted to a brief initialization phase. However, the realization that I was using well-known race-condition code sent me on a literature search that serendipitously turned up this: "Fallacies of Distributed Computing Explained" http://www.rgoarchitects.com/Files/fallacies.pdf To the extent that the course is about *distributed* computing, not just concurrent computing, structuring the discussion around the now-classic Eight Fallacies could be useful. -michael turner From max.lapshin@REDACTED Tue Feb 9 10:27:42 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 9 Feb 2010 12:27:42 +0300 Subject: erlang and crc32 Message-ID: Hi, while working with MPEG TS, I've encountered problems with crc32. Here is a part of PAT header: PAT = <<00,00,16#b0,16#0d,16#1c,16#18,16#d1,00,00,00,16#01,16#e0,16#42>>. VLC generates such CRC32: <<16#90,16#25,16#12,16#e2>> = <<2418348770:32>>. But erlang:crc32(PAT) = 2322700764 In this article author solves the same problem: http://easyerl.blogspot.com/2007/11/nagios-beurk-nrpe-support-for-erlang.html He implements the same algorithm, as VLC does. More discussion: http://www.mail-archive.com/linux-dvb@REDACTED/msg22401.html There is told, that algorithm requires changes. Questions are: 1) are there really different flavours of crc32? 2) can I rearrange my data so, that erlang:crc32 or any other default function will work? From hakan@REDACTED Tue Feb 9 11:11:25 2010 From: hakan@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Tue, 9 Feb 2010 11:11:25 +0100 Subject: [erlang-questions] Watching mnesia transactions In-Reply-To: <4B7120E7.6000807@erlang-solutions.com> References: <4B70B48E.7080206@m5net.com> <4B7120E7.6000807@erlang-solutions.com> Message-ID: <922d05851002090211q445133e3ibd35392a87a014d9@mail.gmail.com> Do keep in mind that if you implement a replication mechanism on top of Ulf's RDBMS or Mnesia's subscriptions (with or without Dannes extensions), you still need to handle potential recovery of the last transactions before a node crash. In case of a node crash, Mnesia's transaction recovery mechanism will recover interrupted transactions. Some of the transactions will be committed while others will be aborted. In your (poor mans) replication mechanism, built on top of Mnesia, you need to handle this so the tables that Mnesia handles and the tables that your code handles always will be consistent. /H?kan On Tue, Feb 9, 2010 at 9:46 AM, Ulf Wiger wrote: > > The RDBMS contrib (jungerl) has some similar problems, > and implemented commit/abort triggers with the help of > the mnesia callback system. I ended up patching mnesia > to try to come to grips with the JIT compilation of > the data dictionary checks and reliable loading of the > generated modules in a distributed setting as a result > of _committed_ schema transactions. This was roughly > the point where I called it a day and stopped working > on it, as some of the robustness tests showed subtly > different behaviour with and without JIT compilation. > > I think some of the constructs in rdbms.erl might at > least get you further than you are today. > > BR, > Ulf W > > Bernard Duggan wrote: >> >> Hi all, >> ? ?Bit of a complex mnesia question here. ?First, I need to describe >> what we want to do: >> >> ? ?For reasons of interacting with a legacy system (which I'll call >> "L") we want to be able to track changes to certain of our mnesia >> tables, and send those changes off so L can update its own copy of the >> data. ?Sadly, it's thoroughly impractical to remove the local copy in L, >> so we're pretty much stuck with this approach for now. ?I'll explain the >> approaches we've tried so far and the problems we've had - hopefully >> someone can either suggest where our thinking has gone astray, or an >> entirely different system :) >> >> >> Attempt 1: >> Using mnesia:subscribe({mnesia_table_event...}), we watch for table >> events and send them off to L. ?That's very nice and simple, except >> there's no way we can see to group transaction events together - every >> table event has its own ActivityID, certainly, but how do you know when >> all the events for a given ActivityID have arrived? ?This seems like a >> pretty serious limitation on what otherwise is a very handy system. >> >> >> Attempt 2: >> Use the mnesia_access callback module and >> mnesia:activity(transaction...). ?Here, we've done the following: >> * Prior to each mnesia:activity call, we set up an ETS table and throw >> it in the process dictionary. * In the transaction function we first empty >> the ETS table (to ensure >> that if the transaction restarts, the table will be cleared) >> * In the activity callback functions we record to the ETS table each >> write/delete event that takes place on mnesia. >> * When the transaction successfully completes, we can dump that table to >> get a full record of write events, grouped as a transaction, and throw >> those to L. >> >> We were really happy with that implementation until I realised a minor >> problem with it this morning: >> The posting of events to L happens /after/ the transaction completes. >> Consider the case of two transactions, T1 and T2 in separate processes >> which both modify the same row. ?You could then have the case where: >> * T1 runs >> * T2 runs >> * T2 sends its change to L >> * T1 sends its older change to L >> If, alternatively, we do the posting inside the transaction, even as the >> last operation, it seems like it might be possible for the transaction >> to restart after the post and get us in all kinds of trouble. >> >> We've come up with a number of elaborate modifications to this plan to >> resolve the issue, but I can't help but think we're missing something >> obvious (or non-obvious). ?After all, mnesia knows full well what's gone >> on and in what order, so why do we seem to need to go to such lengths to >> reconstruct that information? >> >> >> I've slightly simplified this to keep it relatively short, so I'll >> apologise in advance if any of your questions are answered with "yeah we >> already thought of that and with won't work/doesn't apply because blah >> blah" :) >> >> Thanks for reading this far :) >> >> Cheers, >> >> Bernard > > > -- > Ulf Wiger > CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd > http://www.erlang-solutions.com > --------------------------------------------------- > > --------------------------------------------------- > > WE'VE CHANGED NAMES! > > Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG > SOLUTIONS LTD. > > www.erlang-solutions.com From rickard@REDACTED Tue Feb 9 11:39:19 2010 From: rickard@REDACTED (Rickard Green) Date: Tue, 09 Feb 2010 11:39:19 +0100 Subject: [erlang-questions] Problems cross compiling: eheap_alloc: Cannot reallocate 3480006320 bytes of memory In-Reply-To: References: <10d7e35f1002031827r4ca30cbco39fbd488b554a799@mail.gmail.com> <4B6C377F.1020701@erlang.org> <4B7025F1.6050305@erlang.org> Message-ID: <4B713B57.3070201@erlang.org> Winston Smith wrote: > On Mon, Feb 8, 2010 at 9:55 AM, Rickard Green wrote: >> The fix is now available in the ccase/r13b04_dev branch at github. If the >> fix doesn't solve your problem, please send me the $ERL_TOP/erts/config.log >> file and the complete printout (stdout) from your configure run. > > It works well now, thank you. Great! > I did see an error about missing > headers (sorry, I don't have the exact message), but that could've > been because I have done previous builds with the old mechanism. It > did seem to go away after I ran: > > ./otp_build autoconf --xcomp-conf= > > I don't know if this fixed it or not; it's no longer mentioned in the > xcomp/README. I'm a bit surprised by the missing header message, but since it went away after running `./otp_build autoconf' it was probably due to a misconfiguration. If it should appear again please send us info about that. `./otp_build autoconf' (no need for --xcomp-conf here) regenerates all configure scripts and is needed in git when a configure.in or aclocal.m4 have changed. `./otp_build autoconf' is not mentioned since it is not needed in the source tar released. However, we probably should mention it since there are a lot of people building in git. > Is there an easy way to reset my git working directory > to remove any previous autoconf/configure junk (aside from doing a > clean clone of the repo)? > `git clean -dfx' should clean up the whole source tree. Note that I haven't used it myself (I'm still mostly working in clearcase), so please read the man page before using it. >> Some changes has been made in xcomp/README, so it might be worth having a >> look at the diff. > > I updated my .conf file based on the updated examples you have there, > it looks much more straightforward now. > > I did notice a couple of things in the xcomp/README. Firstly, you now > describe the two ways of building, using configure or using otp_build > -- it wasn't immediately obvious what the differences and why I'd use > one vs the other until I'd read in more detail. Secondly, you have a > typo on line 225; you say the command line for otp_build configure has > --with-xcomp-conf= when it's really just --xcomp-conf=. Also, the > script doesn't seem to expand a ~ in the filename, not a big deal > though. Thanks, I'll fix the typo, the tilde expansion, and clarify the difference between otp_build and configure/make a bit. > >> The bug was that configure checked for large file support >> using `getconf' for the build machine. This can cause 8 byte off_t for the >> target machine when 4 byte off_t should be used. The fix tries to figure out >> how to enable large file support using a `getconf' for the target machine >> (or by user input). That is, if you get an 8 byte off_t it isn't necessarily >> wrong. It then probably succeeded in figuring out how to enable large file >> support. > > This is fixed (at least for avr32-linux), it correctly detected the > size of off_t as 4. Great! > > Many thanks! > Regards, Rickard -- Rickard Green, Erlang/OTP, Ericsson AB. From sergey.miryanov@REDACTED Tue Feb 9 12:18:28 2010 From: sergey.miryanov@REDACTED (sergey-miryanov) Date: Tue, 9 Feb 2010 03:18:28 -0800 (PST) Subject: Communicate with running application as with Erlang port? Message-ID: <7cad64b0-944b-433d-8caf-a69228d9c00e@a32g2000yqm.googlegroups.com> Hi, all. What I want - run a port (or linked in driver) from Erlang and send to port a command to start new process (ProcessA). How I can communicate with ProcessA as with usual Erlang port? I can not start ProcessA as a Erlang port. Sergey From rapsey@REDACTED Tue Feb 9 13:14:00 2010 From: rapsey@REDACTED (Rapsey) Date: Tue, 9 Feb 2010 13:14:00 +0100 Subject: [erlang-questions] erlang and crc32 In-Reply-To: References: Message-ID: <97619b171002090414ie321950od97cdd2fec5689e7@mail.gmail.com> crc(B) -> crc(B, 4294967295). crc(<>,CRC) -> <> = <>, crc(Rem, element((N bxor F) + 1, ?CRC) bxor (CRC bsr 8)); crc(<<>>, LCRC) -> <> = <>, CRC. -define(CRC, {16#00000000, 16#B71DC104, 16#6E3B8209, 16#D926430D, 16#DC760413, 16#6B6BC517, 16#B24D861A, 16#0550471E, 16#B8ED0826, 16#0FF0C922, 16#D6D68A2F, 16#61CB4B2B, 16#649B0C35, 16#D386CD31, 16#0AA08E3C, 16#BDBD4F38, 16#70DB114C, 16#C7C6D048, 16#1EE09345, 16#A9FD5241, 16#ACAD155F, 16#1BB0D45B, 16#C2969756, 16#758B5652, 16#C836196A, 16#7F2BD86E, 16#A60D9B63, 16#11105A67, 16#14401D79, 16#A35DDC7D, 16#7A7B9F70, 16#CD665E74, 16#E0B62398, 16#57ABE29C, 16#8E8DA191, 16#39906095, 16#3CC0278B, 16#8BDDE68F, 16#52FBA582, 16#E5E66486, 16#585B2BBE, 16#EF46EABA, 16#3660A9B7, 16#817D68B3, 16#842D2FAD, 16#3330EEA9, 16#EA16ADA4, 16#5D0B6CA0, 16#906D32D4, 16#2770F3D0, 16#FE56B0DD, 16#494B71D9, 16#4C1B36C7, 16#FB06F7C3, 16#2220B4CE, 16#953D75CA, 16#28803AF2, 16#9F9DFBF6, 16#46BBB8FB, 16#F1A679FF, 16#F4F63EE1, 16#43EBFFE5, 16#9ACDBCE8, 16#2DD07DEC, 16#77708634, 16#C06D4730, 16#194B043D, 16#AE56C539, 16#AB068227, 16#1C1B4323, 16#C53D002E, 16#7220C12A, 16#CF9D8E12, 16#78804F16, 16#A1A60C1B, 16#16BBCD1F, 16#13EB8A01, 16#A4F64B05, 16#7DD00808, 16#CACDC90C, 16#07AB9778, 16#B0B6567C, 16#69901571, 16#DE8DD475, 16#DBDD936B, 16#6CC0526F, 16#B5E61162, 16#02FBD066, 16#BF469F5E, 16#085B5E5A, 16#D17D1D57, 16#6660DC53, 16#63309B4D, 16#D42D5A49, 16#0D0B1944, 16#BA16D840, 16#97C6A5AC, 16#20DB64A8, 16#F9FD27A5, 16#4EE0E6A1, 16#4BB0A1BF, 16#FCAD60BB, 16#258B23B6, 16#9296E2B2, 16#2F2BAD8A, 16#98366C8E, 16#41102F83, 16#F60DEE87, 16#F35DA999, 16#4440689D, 16#9D662B90, 16#2A7BEA94, 16#E71DB4E0, 16#500075E4, 16#892636E9, 16#3E3BF7ED, 16#3B6BB0F3, 16#8C7671F7, 16#555032FA, 16#E24DF3FE, 16#5FF0BCC6, 16#E8ED7DC2, 16#31CB3ECF, 16#86D6FFCB, 16#8386B8D5, 16#349B79D1, 16#EDBD3ADC, 16#5AA0FBD8, 16#EEE00C69, 16#59FDCD6D, 16#80DB8E60, 16#37C64F64, 16#3296087A, 16#858BC97E, 16#5CAD8A73, 16#EBB04B77, 16#560D044F, 16#E110C54B, 16#38368646, 16#8F2B4742, 16#8A7B005C, 16#3D66C158, 16#E4408255, 16#535D4351, 16#9E3B1D25, 16#2926DC21, 16#F0009F2C, 16#471D5E28, 16#424D1936, 16#F550D832, 16#2C769B3F, 16#9B6B5A3B, 16#26D61503, 16#91CBD407, 16#48ED970A, 16#FFF0560E, 16#FAA01110, 16#4DBDD014, 16#949B9319, 16#2386521D, 16#0E562FF1, 16#B94BEEF5, 16#606DADF8, 16#D7706CFC, 16#D2202BE2, 16#653DEAE6, 16#BC1BA9EB, 16#0B0668EF, 16#B6BB27D7, 16#01A6E6D3, 16#D880A5DE, 16#6F9D64DA, 16#6ACD23C4, 16#DDD0E2C0, 16#04F6A1CD, 16#B3EB60C9, 16#7E8D3EBD, 16#C990FFB9, 16#10B6BCB4, 16#A7AB7DB0, 16#A2FB3AAE, 16#15E6FBAA, 16#CCC0B8A7, 16#7BDD79A3, 16#C660369B, 16#717DF79F, 16#A85BB492, 16#1F467596, 16#1A163288, 16#AD0BF38C, 16#742DB081, 16#C3307185, 16#99908A5D, 16#2E8D4B59, 16#F7AB0854, 16#40B6C950, 16#45E68E4E, 16#F2FB4F4A, 16#2BDD0C47, 16#9CC0CD43, 16#217D827B, 16#9660437F, 16#4F460072, 16#F85BC176, 16#FD0B8668, 16#4A16476C, 16#93300461, 16#242DC565, 16#E94B9B11, 16#5E565A15, 16#87701918, 16#306DD81C, 16#353D9F02, 16#82205E06, 16#5B061D0B, 16#EC1BDC0F, 16#51A69337, 16#E6BB5233, 16#3F9D113E, 16#8880D03A, 16#8DD09724, 16#3ACD5620, 16#E3EB152D, 16#54F6D429, 16#7926A9C5, 16#CE3B68C1, 16#171D2BCC, 16#A000EAC8, 16#A550ADD6, 16#124D6CD2, 16#CB6B2FDF, 16#7C76EEDB, 16#C1CBA1E3, 16#76D660E7, 16#AFF023EA, 16#18EDE2EE, 16#1DBDA5F0, 16#AAA064F4, 16#738627F9, 16#C49BE6FD, 16#09FDB889, 16#BEE0798D, 16#67C63A80, 16#D0DBFB84, 16#D58BBC9A, 16#62967D9E, 16#BBB03E93, 16#0CADFF97, 16#B110B0AF, 16#060D71AB, 16#DF2B32A6, 16#6836F3A2, 16#6D66B4BC, 16#DA7B75B8, 16#035D36B5, 16#B440F7B1, 16#00000001}). Sergej On Tue, Feb 9, 2010 at 10:27 AM, Max Lapshin wrote: > Hi, while working with MPEG TS, I've encountered problems with crc32. > Here is a part of PAT header: > > PAT = <<00,00,16#b0,16#0d,16#1c,16#18,16#d1,00,00,00,16#01,16#e0,16#42>>. > > VLC generates such CRC32: > > <<16#90,16#25,16#12,16#e2>> = <<2418348770:32>>. > > But erlang:crc32(PAT) = 2322700764 > > In this article author solves the same problem: > > http://easyerl.blogspot.com/2007/11/nagios-beurk-nrpe-support-for-erlang.html > > He implements the same algorithm, as VLC does. More discussion: > http://www.mail-archive.com/linux-dvb@REDACTED/msg22401.html > There is told, that algorithm requires changes. > > Questions are: > 1) are there really different flavours of crc32? > 2) can I rearrange my data so, that erlang:crc32 or any other default > function will work? > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From sergey.miryanov@REDACTED Tue Feb 9 13:52:15 2010 From: sergey.miryanov@REDACTED (sergey-miryanov) Date: Tue, 9 Feb 2010 04:52:15 -0800 (PST) Subject: Communicate with running application as with Erlang port? In-Reply-To: <7cad64b0-944b-433d-8caf-a69228d9c00e@a32g2000yqm.googlegroups.com> References: <7cad64b0-944b-433d-8caf-a69228d9c00e@a32g2000yqm.googlegroups.com> Message-ID: > ?What I want - run a port (or linked in driver) from Erlang and send I start a Erlang process and send command to this process to start ProcessA and return Port to command sender. Sergey. From pablo.platt@REDACTED Tue Feb 9 17:52:47 2010 From: pablo.platt@REDACTED (Pablo Platt) Date: Tue, 9 Feb 2010 08:52:47 -0800 (PST) Subject: grpoc for session management Message-ID: <50240.1078.qm@web112607.mail.gq1.yahoo.com> Hi I'm building a simple comet chat server. Each user can have several resource each represented by a process. Each incoming message should be sent to all online resources of a user. There are two scenarios in which I need to find a process: 1. message is directed to:user_id 2. incoming message contain a session_id Is it better to have a unique name per user_id+resource and then use gproc:select to find the pids of the resources or to use a property user_id and then find all the pids that have this property. I think I need a unique name session_id in addition to that. Is it better to use gen_fsm(to handle auth for example) for each process or a simple process? Will gproc support global scope in the near future? Thanks From ulf.wiger@REDACTED Tue Feb 9 20:26:35 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 09 Feb 2010 20:26:35 +0100 Subject: [erlang-questions] grpoc for session management In-Reply-To: <50240.1078.qm@web112607.mail.gq1.yahoo.com> References: <50240.1078.qm@web112607.mail.gq1.yahoo.com> Message-ID: <4B71B6EB.80600@erlang-solutions.com> Pablo Platt wrote: > Hi > > I'm building a simple comet chat server. Each user can have several > resource each represented by a process. Each incoming message should > be sent to all online resources of a user. > > There are two scenarios in which I need to find a process: 1. message > is directed to:user_id 2. incoming message contain a session_id > > Is it better to have a unique name per user_id+resource and then use > gproc:select to find the pids of the resources or to use a property > user_id and then find all the pids that have this property. Part of the idea with gproc was that you should be able to do either. Which one is best for your problem is probably up to you. :) > Is it better to use gen_fsm(to handle auth for example) for each > process or a simple process? Some people like gen_fsm. It provides structure, and is suitable e.g. when implementing a FSM from a specification, since they tend to be described that event-state matrix form. What I dislike about gen_fsm is that it does away with selective receive, which can often be used to simplify the state machine. Then again, there are many FSMs where this doesn't matter (you still have the benefit of selective receive when calling support functions from within the gen_fsm callback, for example). > Will gproc support global scope in the near future? In the experimental branch (never mind the name, this is the recommended branch), the code has been restructured so that you get to provide the gen_leader options yourself. You can then also choose which version of gen_leader you want to run. There are a few versions out there, particularly on github. The only real problem with the latest gproc version is that the global support hasn't been tested. :) Almost by definition, this means it doesn't work, but I expect there to be only minor issues, quickly fixed. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From pablo.platt@REDACTED Tue Feb 9 20:48:16 2010 From: pablo.platt@REDACTED (Pablo Platt) Date: Tue, 9 Feb 2010 11:48:16 -0800 (PST) Subject: [erlang-questions] grpoc for session management In-Reply-To: <4B71B6EB.80600@erlang-solutions.com> References: <50240.1078.qm@web112607.mail.gq1.yahoo.com> <4B71B6EB.80600@erlang-solutions.com> Message-ID: <434070.82665.qm@web112619.mail.gq1.yahoo.com> In your article you compare the performance of gproc to ETS and find that gproc is three time slower when storing a property. What is the reason? What will be the performance and memory of gproc compared to storing properties in the process state? I realize that gproc let you query properties from outside the process but what would you use for storing the user online friends for example? Assuming this data will only be accessed from the process itself. Thanks ________________________________ From: Ulf Wiger To: Pablo Platt Cc: erlang-questions@REDACTED Sent: Tue, February 9, 2010 9:26:35 PM Subject: Re: [erlang-questions] grpoc for session management Pablo Platt wrote: > Hi > > I'm building a simple comet chat server. Each user can have several > resource each represented by a process. Each incoming message should > be sent to all online resources of a user. > > There are two scenarios in which I need to find a process: 1. message > is directed to:user_id 2. incoming message contain a session_id > > Is it better to have a unique name per user_id+resource and then use > gproc:select to find the pids of the resources or to use a property > user_id and then find all the pids that have this property. Part of the idea with gproc was that you should be able to do either. Which one is best for your problem is probably up to you. :) > Is it better to use gen_fsm(to handle auth for example) for each > process or a simple process? Some people like gen_fsm. It provides structure, and is suitable e.g. when implementing a FSM from a specification, since they tend to be described that event-state matrix form. What I dislike about gen_fsm is that it does away with selective receive, which can often be used to simplify the state machine. Then again, there are many FSMs where this doesn't matter (you still have the benefit of selective receive when calling support functions from within the gen_fsm callback, for example). > Will gproc support global scope in the near future? In the experimental branch (never mind the name, this is the recommended branch), the code has been restructured so that you get to provide the gen_leader options yourself. You can then also choose which version of gen_leader you want to run. There are a few versions out there, particularly on github. The only real problem with the latest gproc version is that the global support hasn't been tested. :) Almost by definition, this means it doesn't work, but I expect there to be only minor issues, quickly fixed. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From bernie@REDACTED Tue Feb 9 22:28:00 2010 From: bernie@REDACTED (Bernard Duggan) Date: Wed, 10 Feb 2010 08:28:00 +1100 Subject: [erlang-questions] Watching mnesia transactions In-Reply-To: <922d05851002090211q445133e3ibd35392a87a014d9@mail.gmail.com> References: <4B70B48E.7080206@m5net.com> <4B7120E7.6000807@erlang-solutions.com> <922d05851002090211q445133e3ibd35392a87a014d9@mail.gmail.com> Message-ID: <4B71D360.3050606@m5net.com> H?kan Mattsson wrote: > Do keep in mind that if you implement a replication mechanism > on top of Ulf's RDBMS or Mnesia's subscriptions (with or without > Dannes extensions), you still need to handle potential recovery > of the last transactions before a node crash. > Thanks for the warning. As it turns out, in our particular scenario, that's not so much of an issue. For the time being, the legacy system's data is recognised as authoritative, and we have a bunch of stuff already in place to re-sync the erlang side to it in pretty much every restart/reconnection scenario (at least, every one we've been able to think of). Definitely something for us to keep in mind, however, as we start to consider shifting the authority to the erlang side. Cheers, Bernard From ulf.wiger@REDACTED Tue Feb 9 22:57:24 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 09 Feb 2010 22:57:24 +0100 Subject: [erlang-questions] grpoc for session management In-Reply-To: <434070.82665.qm@web112619.mail.gq1.yahoo.com> References: <50240.1078.qm@web112607.mail.gq1.yahoo.com> <4B71B6EB.80600@erlang-solutions.com> <434070.82665.qm@web112619.mail.gq1.yahoo.com> Message-ID: <4B71DA44.4000602@erlang-solutions.com> Pablo Platt wrote: > In your article you compare the performance of gproc to ETS > and find that gproc is three time slower when storing a property. > What is the reason? Gproc has to store the property, a reverse mapping, and ensure that the gproc server has a monitor on the process. > What will be the performance and memory of gproc compared to storing > properties in the process state? Basically, the reverse mapping doubles the memory consumption in the normal case. > I realize that gproc let you query properties from outside the process but > what would you use for storing the user online friends for example? > Assuming this data will only be accessed from the process itself. Seems like a dictionary of sorts in the process state would be better for that sort of thing. Gproc is mainly a way to "publish" properties about a process that make it easier to find that process, individually or as part of a group. It comes with some bookkeeping overhead, but in most cases where that sort of functionality is useful, I think its definitely fast enough for practical use. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From pablo.platt@REDACTED Wed Feb 10 01:24:04 2010 From: pablo.platt@REDACTED (Pablo Platt) Date: Tue, 9 Feb 2010 16:24:04 -0800 (PST) Subject: [erlang-questions] grpoc for session management In-Reply-To: <4B71DA44.4000602@erlang-solutions.com> References: <50240.1078.qm@web112607.mail.gq1.yahoo.com> <4B71B6EB.80600@erlang-solutions.com> <434070.82665.qm@web112619.mail.gq1.yahoo.com> <4B71DA44.4000602@erlang-solutions.com> Message-ID: <472599.58675.qm@web112618.mail.gq1.yahoo.com> I now understand better when to use gproc. gproc monitors all the processes that have register name/property/counter. Does it make sense to add a callback function and args that gproc will call when the process terminates unexpectedly? Maybe it's just my use case but I have a feeling that usually when you register a process you'll also be interested to know when it dies. gproc already monitors processes so maybe it makes sense. It can be set with 'm' for monitor: reg({m, l, my_callback}, [arg1, arg2]) Thanks ________________________________ From: Ulf Wiger To: Pablo Platt Cc: erlang-questions@REDACTED Sent: Tue, February 9, 2010 11:57:24 PM Subject: Re: [erlang-questions] grpoc for session management Pablo Platt wrote: > In your article you compare the performance of gproc to ETS > and find that gproc is three time slower when storing a property. > What is the reason? Gproc has to store the property, a reverse mapping, and ensure that the gproc server has a monitor on the process. > What will be the performance and memory of gproc compared to storing properties in the process state? Basically, the reverse mapping doubles the memory consumption in the normal case. > I realize that gproc let you query properties from outside the process but > what would you use for storing the user online friends for example? > Assuming this data will only be accessed from the process itself. Seems like a dictionary of sorts in the process state would be better for that sort of thing. Gproc is mainly a way to "publish" properties about a process that make it easier to find that process, individually or as part of a group. It comes with some bookkeeping overhead, but in most cases where that sort of functionality is useful, I think its definitely fast enough for practical use. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From ok@REDACTED Wed Feb 10 02:54:16 2010 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 10 Feb 2010 14:54:16 +1300 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <4B711E93.8030000@erlang-solutions.com> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <4B6FDA63.4060602@erlang-solutions.com> <2E085E87-855D-4C26-983E-46A43E1ED4ED@cs.otago.ac.nz> <4B711E93.8030000@erlang-solutions.com> Message-ID: On Feb 9, 2010, at 9:36 PM, Ulf Wiger wrote: > Richard O'Keefe wrote: >> On Feb 8, 2010, at 10:33 PM, Ulf Wiger wrote: >>> Kostis has alreay mentioned that data races are possible in Erlang. >> I am dusting off my old 'pid_name' proposal from the 90s and turning >> it into an EEP. I'd like to avoid races in the core language. > > Some of the issues in the EEP were also dealt with in my gproc > paper (http://portal.acm.org/citation.cfm?id=1292522, also > http://svn.ulf.wiger.net/gproc/trunk/gproc/doc/erlang07-wiger.pdf). I'm familiar with that paper. gproc and my EEP solve opposite problems. gproc answers the question "given a large number of processes that WANT to be found, how do you do that?" (and a bunch of other questions). My EEP answers the question "given a module with one or more private processes that need to be findable by and only by the interface functions of the module, how do you do _that_?" > I solved the race problem on registration by only allowing a > process to register itself. There is still a race in the sense > that two processes may contend for the same name, or that a > registered process may die before a "registered send" is delivered, > but this is, I think, an unavoidable part of the semantics of > referring to processes by name, combined with dynamic typing > and asynchronous message passing. Let's stick with the old interface for a second or two. start() -> case whereis(server) of undefined -> register(server, spawn(fun () -> loop([]) end)) ; Pid when is_pid(Pid) -> ok end. Now let's move the register/1 call inside the new process. start() -> case whereis(server) of undefined -> spawn(fun () -> register(server, self()), loop([]) end) ; Pid when is_pid(Pid) -> Pid end. In the first version, the caller of start/1 knows that there is a time between the entry to that function and the exit from it when there was a process registered as 'server'. In the second version, the caller does not know that. We fix _that_ by doing start() -> case whereis(server) of undefined -> Client = self(), Secret = make_ref(), Pid = spawn(fun () -> register(server, self()), Client ! Secret, loop([]) end), receive Secret -> Pid end ; Pid when is_pid(Pid) -> Pid end. Now, of course, if two processes both call start/1, one of the new server processes will crash, and its client will be left waiting forever. So now we have to allow for that. start() -> case whereis(server) of undefined -> Client = self(), Secret = make_ref(), spawn(fun() -> case catch register(server, self()) of true -> Client ! {Secret,Pid} loop([]) ; {'EXIT',_} -> Client ! {Secret,undefined} end end), receive {Secret,undefined} -> sleep(500), start() ; {Secret,Pid} when is_pid(Pid) -> Pid end ; Pid when is_pid(Pid) -> Pid end. What am I missing? How does only allowing a process to register itself eliminate the race? The race is a race for access to the registry entry. The thing about pid_name_spawn{,_link}/2 is that (encapsulated) registration done that way doesn't even begin a second process is another registration is under way. There _is_ locking going on in the implementation of the registry already, it's just the classic Java "synchronized doesn't span _two_ operations" bug. We can deal with some of the other issues, like the possibility of a registered process dying inconveniently by programming it so that it WON'T die; anything risky being shoved off onto a new support process (and that way lies supervision, though you need not press it _quite_ that far). But it is far easier to make the registered process stay alive if it can't get forged messages. Which means not using the registry. > On the topic of the process registry, there is also some recent > QuickCheck work that might be of interest. > > Claessen, K., Palka, M., Smallbone, N., Hughes, J., Svensson, H., > Arts, T., and Wiger, U. 2009. Finding race conditions in Erlang with > QuickCheck and PULSE. SIGPLAN Not. 44, 9 (Aug. 2009), 149-160. DOI= http://doi.acm.org/10.1145/1631687.1596574 Note the key sentence: "Our approach is based on property-based testing using QuickCheck ..., in a commercial version for Erlang developed by Quviq AB ..." ^^^^^^^^^^ This is not a whine by an academic about not being able to get stuff free. I do have some research funding, and the department has some "equipment" money. But there is one thing I absolutely totally expect to find at a commercial web site, and that is PRICES. I spent about $200 of billable time searching the http://www.quviq.com/ web site in vain for any hint of their prices. I can only conclude that while QuickCheck for Erlang is commercial and proprietary, it is no longer for sale, otherwise they would be making some kind of effort to sell it. Either that, or the prices are so high that they are worried about scaring customers off. (Yes, I saw the free 30-day trial, but the link is dead.) From steven.charles.davis@REDACTED Wed Feb 10 04:48:42 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Tue, 9 Feb 2010 19:48:42 -0800 (PST) Subject: Teaching Erlang as part of a paper -- advice sought In-Reply-To: <8b9ee55b1002072107o6c4d0e2al6c58b8143300ca87@mail.gmail.com> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <8b9ee55b1002072107o6c4d0e2al6c58b8143300ca87@mail.gmail.com> Message-ID: I'd recommend this book too, even though I can only get the first part of it (free from the Erlang.org website). The only copies of the full book appear to be over $200. I'd really like to get a hold of part 2 of this book at a cost I can afford. Anybody have any ideas where I might go to get it? /s On Feb 7, 11:07?pm, Fred Hebert wrote: > I have found many of the lessons from the 1996 book (Concurrent Programmin > in ERLANG, by Armstrong, Virding, Wikstr?m and Williams) to be pretty good > to teach the fundamentals of some concurrent and distributed computing. If I > recall correctly, the concurrent part showed how to use the basic Erlang > stuff (mailboxes, spawning processes, etc.). ?It showed inter-process > communication through FSMs, the client-server model, etc. From bernie@REDACTED Wed Feb 10 04:59:49 2010 From: bernie@REDACTED (Bernard Duggan) Date: Wed, 10 Feb 2010 14:59:49 +1100 Subject: [erlang-questions] Watching mnesia transactions In-Reply-To: <93df43b61002082349m1cbc77bk5827b00c2a51e337@mail.gmail.com> References: <4B70B48E.7080206@m5net.com> <93df43b61002082349m1cbc77bk5827b00c2a51e337@mail.gmail.com> Message-ID: <4B722F35.1090408@m5net.com> Dan Gudmundsson wrote: > There is no way to get that info today without patching mnesia, > I think a variant of 'mnesia:subscribe' is the best solution. > Thanks Dan, Ulf and H?kan for the answers (even if they weren't exactly what I wanted to hear :)). I've taken a look at the option of a patch to or variant of the mnesia:subscribe system. Basically I can think of two obvious choices: * Add a new event category to subscribe(), in addition to 'system' and {table, ..., ...} - call it 'activity'. When a transaction has finished committing, fire off a message like {activity_complete, ActivityID} to all subscribers. * Add a new event category to subscribe() called 'transaction' (or something) which sends the full set of changes from a transaction, all batched up in a single event, when the transaction finishes committing. That has the downside that in its simplest form you can't filter by tables you're interested in and would probably end up being considerably more complex to implement, so I'm inclined to go with the first option. In both cases, the event would need to be sent at a point where the transaction is still running and holding locks, but where all the changes have been committed and we know the transaction isn't going to restart. It looks like the appropriate place to do that would be as the final step of do_commit() (in mnesia_tm.erl) using an analogous method to mnesia_subscr:report_table_event(). So my question to those learned in this area is: Does this sound like a vaguely workable idea, or am I missing/misunderstanding something fundamental? Cheers, Bernard From jeffm@REDACTED Wed Feb 10 05:10:18 2010 From: jeffm@REDACTED (jm) Date: Wed, 10 Feb 2010 15:10:18 +1100 Subject: [erlang-questions] Re: Teaching Erlang as part of a paper -- advice sought In-Reply-To: References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <8b9ee55b1002072107o6c4d0e2al6c58b8143300ca87@mail.gmail.com> Message-ID: <4B7231AA.3050104@ghostgun.com> Try http://www.booko.com.au/books/isbn/9780135083017 (prices in AUD). or http://www.abebooks.com/servlet/BookDetailsPL?bi=1112606232&searchurl=an%3Darmstrong%26isbn%3D9780135083017%26sts%3Dt%26tn%3DConcurrent%2BProgramming%2Bin%2BErlang%26x%3D46%26y%3D8 If anyone else know of another or better source please post. Jeff. On 10/02/10 2:48 PM, Steve Davis wrote: > I'd recommend this book too, even though I can only get the first part > of it (free from the Erlang.org website). > > The only copies of the full book appear to be over $200. I'd really > like to get a hold of part 2 of this book at a cost I can afford. > Anybody have any ideas where I might go to get it? > > /s > > On Feb 7, 11:07 pm, Fred Hebert wrote: > >> I have found many of the lessons from the 1996 book (Concurrent Programmin >> in ERLANG, by Armstrong, Virding, Wikstr?m and Williams) to be pretty good >> to teach the fundamentals of some concurrent and distributed computing. If I >> recall correctly, the concurrent part showed how to use the basic Erlang >> stuff (mailboxes, spawning processes, etc.). It showed inter-process >> communication through FSMs, the client-server model, etc. >> > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From kagato@REDACTED Wed Feb 10 05:48:24 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Tue, 9 Feb 2010 20:48:24 -0800 Subject: [erlang-questions] Watching mnesia transactions In-Reply-To: <4B722F35.1090408@m5net.com> References: <4B70B48E.7080206@m5net.com> <93df43b61002082349m1cbc77bk5827b00c2a51e337@mail.gmail.com> <4B722F35.1090408@m5net.com> Message-ID: <56EC4583-3E45-470A-94F1-DAE0FB44E981@souja.net> Don't forget that you may have transactions recovering after a failure. I'm unsure exactly what that looks like, but it might actually be easier to go with the second option over the first. On Feb 9, 2010, at 7:59 PM, Bernard Duggan wrote: > Dan Gudmundsson wrote: >> There is no way to get that info today without patching mnesia, >> I think a variant of 'mnesia:subscribe' is the best solution. >> > Thanks Dan, Ulf and H?kan for the answers (even if they weren't exactly > what I wanted to hear :)). > > I've taken a look at the option of a patch to or variant of the > mnesia:subscribe system. Basically I can think of two obvious choices: > > * Add a new event category to subscribe(), in addition to 'system' and > {table, ..., ...} - call it 'activity'. When a transaction has finished > committing, fire off a message like {activity_complete, ActivityID} to > all subscribers. > > * Add a new event category to subscribe() called 'transaction' (or > something) which sends the full set of changes from a transaction, all > batched up in a single event, when the transaction finishes committing. > That has the downside that in its simplest form you can't filter by > tables you're interested in and would probably end up being considerably > more complex to implement, so I'm inclined to go with the first option. > > In both cases, the event would need to be sent at a point where the > transaction is still running and holding locks, but where all the > changes have been committed and we know the transaction isn't going to > restart. It looks like the appropriate place to do that would be as the > final step of do_commit() (in mnesia_tm.erl) using an analogous method > to mnesia_subscr:report_table_event(). > > So my question to those learned in this area is: Does this sound like a > vaguely workable idea, or am I missing/misunderstanding something > fundamental? > > Cheers, > > Bernard > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- Jayson Vantuyl kagato@REDACTED From ok@REDACTED Wed Feb 10 06:07:51 2010 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 10 Feb 2010 18:07:51 +1300 Subject: [erlang-questions] Re: Teaching Erlang as part of a paper -- advice sought In-Reply-To: <4B7231AA.3050104@ghostgun.com> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <8b9ee55b1002072107o6c4d0e2al6c58b8143300ca87@mail.gmail.com> <4B7231AA.3050104@ghostgun.com> Message-ID: Amazon UK claims at http://www.amazon.co.uk/exec/obidos/ASIN/013508301X/ref=nosim/bookie0a-21 to have 2 "new" copies available for about 63 pounds. Considering all the other sites that list it, but say it's unavailable, I rather doubt it. It would be really nice to have this classic available again; if it's not worth Prentice-Hall's time reprinting it, they should give the authors back the copyright and let the full electronic copy be available. In the mean time, I'm looking at a copy of Francesco Cesarini's "Erlang Programming", and so far, so excellent. (I also have a copy of Joe Armstrong's recent book, and that's nice too. More precisely, a student has it and liked it.) From ulf.wiger@REDACTED Wed Feb 10 08:52:07 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 10 Feb 2010 08:52:07 +0100 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <4B6FDA63.4060602@erlang-solutions.com> <2E085E87-855D-4C26-983E-46A43E1ED4ED@cs.otago.ac.nz> <4B711E93.8030000@erlang-solutions.com> Message-ID: <4B7265A7.2010907@erlang-solutions.com> Richard O'Keefe wrote: > > What am I missing? How does only allowing a process to register > itself eliminate the race? The race is a race for access to the > registry entry. There is another race, and that is covered in the PULSE paper. Basically, you cannot implement a process registry in Erlang that has well-defined semantics when more than two processes are involved in the race (or at least that's what it looks like; the paper only covers the two-process case, and discusses some obvious problems if a third process would be involved. The seemingly unsolvable problem is when processes content for a registered name and one or more of them start crashing in the middle of the race. The semantics /as given by the existing registration bifs/ requires the ability to handle process EXITs and the registry within the same critical section, something that cannot be done in Erlang code. So the semantics should change somehow, if nothing else because maintaining a large critical section when extending into many-core is not a good idea. The way to avoid the simple race is to start the process synchronously, e.g. using proc_lib:start_link(...). C.f. gen_server:start_link({local,Name},...). BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From dangud@REDACTED Wed Feb 10 09:01:15 2010 From: dangud@REDACTED (Dan Gudmundsson) Date: Wed, 10 Feb 2010 09:01:15 +0100 Subject: [erlang-questions] Watching mnesia transactions In-Reply-To: <56EC4583-3E45-470A-94F1-DAE0FB44E981@souja.net> References: <4B70B48E.7080206@m5net.com> <93df43b61002082349m1cbc77bk5827b00c2a51e337@mail.gmail.com> <4B722F35.1090408@m5net.com> <56EC4583-3E45-470A-94F1-DAE0FB44E981@souja.net> Message-ID: <93df43b61002100001j2ac95538qee14ed6b5b652438@mail.gmail.com> >> * Add a new event category to subscribe(), in addition to 'system' and >> {table, ..., ...} - call it 'activity'. ?When a transaction has finished >> committing, fire off a message like {activity_complete, ActivityID} to >> all subscribers. >> >> In both cases, the event would need to be sent at a point where the >> transaction is still running and holding locks, but where all the >> changes have been committed and we know the transaction isn't going to >> restart. ?It looks like the appropriate place to do that would be as the >> final step of do_commit() (in mnesia_tm.erl) using an analogous method >> to mnesia_subscr:report_table_event(). >> >> So my question to those learned in this area is: Does this sound like a >> vaguely workable idea, or am I missing/misunderstanding something >> fundamental? That sounds good without putting to much thoughts into it, it is easy to implement, doesn't cause a lot of overhead, I guess dirty writes needs to be thought about as well. It leaves the burden on the user to collect each transactions data though. /Dan From ulf.wiger@REDACTED Wed Feb 10 09:02:46 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 10 Feb 2010 09:02:46 +0100 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: <4B711E93.8030000@erlang-solutions.com> References: <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> <4B6FDA63.4060602@erlang-solutions.com> <2E085E87-855D-4C26-983E-46A43E1ED4ED@cs.otago.ac.nz> <4B711E93.8030000@erlang-solutions.com> Message-ID: <4B726826.8000502@erlang-solutions.com> Ulf Wiger wrote: > > On the topic of the process registry, there is also some recent > QuickCheck work that might be of interest. > > Claessen, K., Palka, M., Smallbone, N., Hughes, J., Svensson, H., Arts, > T., and Wiger, U. 2009. Finding race conditions in Erlang with > QuickCheck and PULSE. SIGPLAN Not. 44, 9 (Aug. 2009), 149-160. DOI= > http://doi.acm.org/10.1145/1631687.1596574 For those of you who don't have an ACM account, I should have mentioned that this paper is available for download from the ProTest publications page: http://www.protest-project.eu/publications.html Specifically: http://www.protest-project.eu/upload/paper/icfp070-claessen.pdf BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From max.lapshin@REDACTED Wed Feb 10 10:40:51 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 10 Feb 2010 12:40:51 +0300 Subject: [erlang-questions] erlang and crc32 In-Reply-To: <20100210093551.GA5838@corelatus.se> References: <20100210093551.GA5838@corelatus.se> Message-ID: On Wed, Feb 10, 2010 at 12:35 PM, Matthias Lang wrote: > If the function "Rapsey" gave you works and it's fast enough, you're > probably happy. Otherwise, you probably want to implement it in C, > perhaps as a NIF. If you're feeling heroic, extending erlang:crc32 to > handle all possible crc32 would be neat. Thank you for explanation. Yes, that code really works, and it seems that best is to contribute to erlang sources. From a.zhuravlev@REDACTED Wed Feb 10 10:54:15 2010 From: a.zhuravlev@REDACTED (Alexander Zhuravlev) Date: Wed, 10 Feb 2010 12:54:15 +0300 Subject: issue with http:request Message-ID: <20100210095415.GB94910@zaa.local> Hello, It looks like there is some issue with http request handling in http:request function or some other subsystem underneath. Here is a test case: Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] 1> inets:start(). ok 2> % this one works as expected 2> http:request(head, {"http://google.com", []}, [{timeout, 100}], []). {error,timeout} 3> URL = [104,116,116,112,58,47,47,227,129,147,227,130,140,230,166,130,227, 3> 129,173,229,189,147,227,129,159,227,129,163,227,129,166,227,130, 3> 139,227,128,130,119,119,119,46,112,97,103,101,46,115,97,110,110, 3> 101,116,46,110,101,46,106,112,47,109,97,121,117,114,105,47,122,121, 3> 111,115,101,105,47,109,97,114,95,51,48,54,46,104,116,109,108]. [104,116,116,112,58,47,47,227,129,147,227,130,140,230,166, 130,227,129,173,229,189,147,227,129,159,227,129,163,227|...] 4> http:request(head, {URL, []}, [{timeout, 100}], []). The latest request hangs indefinitely. Request to the same URL (while being UTF-8 encoded) also hangs: 6> http:request(head, {"http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html", []}, [{timeout, 100}], []). Moreover, http_uri shows that both URLs are valid: 1> http_uri:parse(URL). {http,[], [227,129,147,227,130,140,230,166,130,227,129,173,229,189, 147,227,129,159,227,129,163,227,129,166,227,130|...], 80,"/mayuri/zyosei/mar_306.html",[]} 2> http_uri:parse("http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html"). {http,[], [12371,12428,27010,12397,24403,12383,12387,12390,12427, 12290,119,119,119,46,112,97,103,101,46,115,97,110,110,101, 116,46|...], 80,"/mayuri/zyosei/mar_306.html",[]} Our production system logs the following error to the console (however I do not see it when I run the code in a new local erlang shell), I suppose it is connected to the issue above: =CRASH REPORT==== 10-Feb-2010::12:25:09 === crasher: initial call: httpc_handler:init/1 pid: <0.18577.0> registered_name: [] exception exit: badarg in function gen_tcp:connect/4 in call from httpc_handler:send_first_request/3 in call from httpc_handler:init/1 ancestors: [httpc_handler_sup,httpc_sup,inets_sup,<0.80.0>] messages: [] links: [<0.86.0>] dictionary: [] trap_exit: true status: running heap_size: 233 stack_size: 24 reductions: 104 neighbours: =SUPERVISOR REPORT==== 10-Feb-2010::12:25:09 === Supervisor: {local,httpc_handler_sup} Context: child_terminated Reason: badarg Offender: [{pid,<0.18577.0>}, {name,undefined}, {mfa, {httpc_handler,start_link, [{request,#Ref<0.0.0.79940>,<0.18533.0>,0,http, {[12371,12428,27010,12397,24403,12383,12387, 12390,12427,12290,119,119,119,46,112,97,103, 101,46,115,97,110,110,101,116,46,110,101,46, 106,112], 80}, "/mayuri/zyosei/mar_306.html",[],get, {http_request_h,undefined,"keep-alive", undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,undefined, [12371,12428,27010,12397,24403,12383,12387, 12390,12427,12290,119,119,119,46,112,97, 103,101,46,115,97,110,110,101,116,46,110, 101,46,106,112], undefined,undefined,undefined,undefined, undefined,undefined,undefined,undefined, undefined,[],undefined,undefined,undefined, undefined,"0",undefined,undefined, undefined,undefined,undefined,undefined,[]}, {[],[]}, {http_options,"HTTP/1.1",infinity,true,[], undefined,false,infinity}, [104,116,116,112,58,47,47,12371,12428,27010, 12397,24403,12383,12387,12390,12427,12290,119, 119,119,46,112,97,103,101,46,115,97,110,110, 101,116,46,110,101,46,106,112,47,109,97,121, 117,114,105,47,122,121,111,115,101,105,47,109, 97,114,95,51,48,54,46,104,116,109,108], [],none,[]}, {options, {undefined,[]}, 0,2,5,120000,2,disabled,false,inet,default, default}, httpc_manager]}}, {restart_type,temporary}, {shutdown,4000}, {child_type,worker}] -- Alexander Zhuravlev From als@REDACTED Wed Feb 10 10:46:00 2010 From: als@REDACTED (Anthony Shipman) Date: Wed, 10 Feb 2010 20:46:00 +1100 Subject: On Per-module process registration Message-ID: <201002102046.01066.als@iinet.net.au> I found the pid_name EEP a bit confusing and I'm not sure that it solves the problems that I have. Typically I will have a master gen_server that works with a variable number of slave gen_servers each running the code of the same module. The master wants to send a message to a slave. It can't use a pid since the slave might die and be restarted by its supervisor at any time. So I must synthesise an atom for a name that looks something like '/' and put it into the node's registry. I worry about the overhead of looking up such a name when the registry has 100,000 processes in it. I've thought that it would be nice if the supervisor could take care of sending messages e.g. have supervisor:call_to(ChildID, Msg). The supervisor then becomes the scope for the naming system. But that could be awkward in a non-trivial supervisor tree. Here's an in-between idea. Let's make a registry be a first class object. It will function as a scope for a set of process names. The API would look something like: registry:new() registry:spawn_link(Registry, Name, MFA) registry:send_to(Registry, Name, MFA) registry:call_to(Registry, Name, MFA) registry:cast_to(Registry, Name, MFA) The spawn function would be atomic wrt spawning and registration. The master would create a registry for itself and spawn each slave within its scope. We lose the nice Name!Msg syntax unless something like (Registry, Name) ! Msg or [Registry, Name] ! Msg is defined. The call_to and cast_to are for integration with gen_server et al. Integration with a supervisor tree would take more thought. It might require that the registry (a mutable object) be shared between servers and supervisors. The distinction between a registry and a supervisor could be blurred by giving the registry the ability to restart spawned processes that crash. Maybe we could even have a hierarchy of registries with a process being reached by a path through the registry tree. Another issue is whether a registry could be accessed from more than one node. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From leap@REDACTED Wed Feb 10 11:47:59 2010 From: leap@REDACTED (Michael Turner) Date: Wed, 10 Feb 2010 10:47:59 +0000 Subject: erlang-questions] On Per-module process registration In-Reply-To: <201002102046.01066.als@iinet.net.au> Message-ID: Anthony, I'm not sure I understand either your requirement or the motivation for it, but perhaps the Global Name Registration Facility (global module) could help? http://www.erlang.org/doc/man/global.html It's probably pretty fast even for the single-node case, and appears to have been acceptably optimized for multiple nodes. I only use global:trans/2, and I use that only to serialize access to the regular process registry, which doesn't have anything analogous from what I can see. 'Node' is the only sort of scope concept the global module seems to support; I suppose you could make use of it (logically, anyway) even on a single physical node by running more instances of Erlang as logical nodes. The documentation for the global module is wordy but also a little ambiguous and skimpy on some details (don't you just hate that combination?). It's on my list of chapters to clean up. -michael turner On 2/10/2010, "Anthony Shipman" wrote: >I found the pid_name EEP a bit confusing and I'm not sure that it solves >the problems that I have. Typically I will have a master gen_server >that works with a variable number of slave gen_servers each running >the code of the same module. The master wants to send a message to a >slave. It can't use a pid since the slave might die and be restarted >by its supervisor at any time. So I must synthesise an atom for a name >that looks something like '/' and put it into the node's >registry. I worry about the overhead of looking up such a name when the >registry has 100,000 processes in it. > >I've thought that it would be nice if the supervisor could take care >of sending messages e.g. have supervisor:call_to(ChildID, Msg). The >supervisor then becomes the scope for the naming system. But that could >be awkward in a non-trivial supervisor tree. > >Here's an in-between idea. Let's make a registry be a first class >object. It will function as a scope for a set of process names. The API >would look something like: > > registry:new() > registry:spawn_link(Registry, Name, MFA) > registry:send_to(Registry, Name, MFA) > registry:call_to(Registry, Name, MFA) > registry:cast_to(Registry, Name, MFA) > >The spawn function would be atomic wrt spawning and registration. The >master would create a registry for itself and spawn each slave within >its scope. We lose the nice Name!Msg syntax unless something like > (Registry, Name) ! Msg > or > [Registry, Name] ! Msg >is defined. > >The call_to and cast_to are for integration with gen_server et >al. Integration with a supervisor tree would take more thought. It might >require that the registry (a mutable object) be shared between servers >and supervisors. > >The distinction between a registry and a supervisor could be blurred by >giving the registry the ability to restart spawned processes that crash. > >Maybe we could even have a hierarchy of registries with a process >being reached by a path through the registry tree. > >Another issue is whether a registry could be accessed from more than >one node. > >-- >Anthony Shipman Mamas don't let your babies >als@REDACTED grow up to be outsourced. > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From a.zhuravlev@REDACTED Wed Feb 10 12:29:04 2010 From: a.zhuravlev@REDACTED (Alexander Zhuravlev) Date: Wed, 10 Feb 2010 14:29:04 +0300 Subject: [erlang-bugs] issue with http:request In-Reply-To: References: <20100210095415.GB94910@zaa.local> Message-ID: <4B729880.2050800@gmail.com> On 2/10/10 1:52 PM, Kenji Rikitake wrote: >> 6> http:request(head, {"http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html", []}, [{timeout, 100}], []). > > Can you directly write non-ASCII Unicode letters in the URL like this? > I guess not. If the first part ends with .jp were a domain name, this > wouldn't be a legal one because this should have been encoded with IDN > (International Domain Name) encoding, which is represented in ASCII > only. This sort of domain name cannot be handled by DNS. (BTW this is a > mixed string of Japanese and English letters, FYI.) Yes, I know and too think that the URL is not correct, however erlang http client code (or underlying inets code?) does not handle this case correctly and just crash or hang, regardless of the fact that the function should have returned within 100 ms. It is just a question of correct input handling. From kenji.rikitake@REDACTED Wed Feb 10 12:33:20 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Wed, 10 Feb 2010 20:33:20 +0900 Subject: [erlang-bugs] issue with http:request In-Reply-To: <4B729880.2050800@gmail.com> References: <20100210095415.GB94910@zaa.local> <4B729880.2050800@gmail.com> Message-ID: <20100210113320.GA74641@k2r.org> I understand your problem, and I think that is a part of broader issue of Unicode string handling in Erlang/OTP. Kenji Rikitake In the message <4B729880.2050800@REDACTED> dated Wed, Feb 10, 2010 at 02:28:40PM +0300, Alexander Zhuravlev writes: > On 2/10/10 1:52 PM, Kenji Rikitake wrote: > >> 6> http:request(head, {"http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html", []}, [{timeout, 100}], []). > > > > Can you directly write non-ASCII Unicode letters in the URL like this? > > I guess not. If the first part ends with .jp were a domain name, this > > wouldn't be a legal one because this should have been encoded with IDN > > (International Domain Name) encoding, which is represented in ASCII > > only. This sort of domain name cannot be handled by DNS. (BTW this is a > > mixed string of Japanese and English letters, FYI.) > > Yes, I know and too think that the URL is not correct, however > erlang http client code (or underlying inets code?) does not handle > this case correctly and just crash or hang, regardless of the fact that > the function should have returned within 100 ms. It is just a question > of correct input handling. From matthias@REDACTED Wed Feb 10 10:35:51 2010 From: matthias@REDACTED (Matthias Lang) Date: Wed, 10 Feb 2010 10:35:51 +0100 Subject: [erlang-questions] erlang and crc32 In-Reply-To: References: Message-ID: <20100210093551.GA5838@corelatus.se> Hi, I saw that someone else already gave you code, so I won't. > 1) are there really different flavours of crc32? Yes. There are at least two different CRC32 in common use, the 'ethernet' one and the 'SCTP' one. Erlang appears to provide the ethernet one. (IIRC, the CRC32 used in ATM AAL5 is different again) The wikipedia page about CRCs has a nice table of popular CRCs: http://en.wikipedia.org/wiki/Cyclic_redundancy_check > 2) can I rearrange my data so, that erlang:crc32 or any other default > function will work? I'm not sure. According to the wikipedia table, MPEG-2 uses the IEEE 802.3 CRC32. But I don't know if MPEG-2 is the same thing as what you're working on (MPEG TS). I don't know anything about MPEG. If the function "Rapsey" gave you works and it's fast enough, you're probably happy. Otherwise, you probably want to implement it in C, perhaps as a NIF. If you're feeling heroic, extending erlang:crc32 to handle all possible crc32 would be neat. (Aside: I have an Erlang module which can compute arbitrary CRC4, 6, 8, 16 and 32. I don't want to post it because it's a mess. If someone wants it anyway, mail me.) Matt From a.zhuravlev@REDACTED Wed Feb 10 14:08:51 2010 From: a.zhuravlev@REDACTED (Alexander Zhuravlev) Date: Wed, 10 Feb 2010 16:08:51 +0300 Subject: issue with http:request In-Reply-To: <20100210095415.GB94910@zaa.local> References: <20100210095415.GB94910@zaa.local> Message-ID: <4B72AFE3.1020608@gmail.com> On 2/10/10 12:54 PM, Alexander Zhuravlev wrote: > Hello, > > It looks like there is some issue with http request handling in > http:request function or some other subsystem underneath. > > Here is a test case: > > Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] > > 1> inets:start(). > ok > 2> % this one works as expected > 2> http:request(head, {"http://google.com", []}, [{timeout, 100}], []). > {error,timeout} > 3> URL = [104,116,116,112,58,47,47,227,129,147,227,130,140,230,166,130,227, > 3> 129,173,229,189,147,227,129,159,227,129,163,227,129,166,227,130, > 3> 139,227,128,130,119,119,119,46,112,97,103,101,46,115,97,110,110, > 3> 101,116,46,110,101,46,106,112,47,109,97,121,117,114,105,47,122,121, > 3> 111,115,101,105,47,109,97,114,95,51,48,54,46,104,116,109,108]. > [104,116,116,112,58,47,47,227,129,147,227,130,140,230,166, > 130,227,129,173,229,189,147,227,129,159,227,129,163,227|...] > 4> http:request(head, {URL, []}, [{timeout, 100}], []). > > The latest request hangs indefinitely. > Request to the same URL (while being UTF-8 encoded) also hangs: > > 6> http:request(head, {"http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html", []}, [{timeout, 100}], []). > > Moreover, http_uri shows that both URLs are valid: > > 1> http_uri:parse(URL). > {http,[], [227,129,147,227,130,140,230,166,130,227,129,173,229,189, > 147,227,129,159,227,129,163,227,129,166,227,130|...], > 80,"/mayuri/zyosei/mar_306.html",[]} > > 2> > http_uri:parse("http://??????????www.page.sannet.ne.jp/mayuri/zyosei/mar_306.html"). > {http,[], > [12371,12428,27010,12397,24403,12383,12387,12390,12427, > 12290,119,119,119,46,112,97,103,101,46,115,97,110,110,101, > 116,46|...], 80,"/mayuri/zyosei/mar_306.html",[]} > > > Our production system logs the following error to the console (however I do not see it when I run the > code in a new local erlang shell), I suppose it is connected to the issue above: > > =CRASH REPORT==== 10-Feb-2010::12:25:09 === > crasher: > initial call: httpc_handler:init/1 > pid:<0.18577.0> > registered_name: [] > exception exit: badarg > in function gen_tcp:connect/4 > in call from httpc_handler:send_first_request/3 > in call from httpc_handler:init/1 > ancestors: [httpc_handler_sup,httpc_sup,inets_sup,<0.80.0>] > messages: [] > links: [<0.86.0>] > dictionary: [] > trap_exit: true > status: running > heap_size: 233 > stack_size: 24 > reductions: 104 > neighbours: > > =SUPERVISOR REPORT==== 10-Feb-2010::12:25:09 === > Supervisor: {local,httpc_handler_sup} > Context: child_terminated > Reason: badarg > Offender: [{pid,<0.18577.0>}, > {name,undefined}, > {mfa, > {httpc_handler,start_link, > [{request,#Ref<0.0.0.79940>,<0.18533.0>,0,http, > {[12371,12428,27010,12397,24403,12383,12387, > 12390,12427,12290,119,119,119,46,112,97,103, > 101,46,115,97,110,110,101,116,46,110,101,46, > 106,112], > 80}, > "/mayuri/zyosei/mar_306.html",[],get, > {http_request_h,undefined,"keep-alive", > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,undefined, > [12371,12428,27010,12397,24403,12383,12387, > 12390,12427,12290,119,119,119,46,112,97, > 103,101,46,115,97,110,110,101,116,46,110, > 101,46,106,112], > undefined,undefined,undefined,undefined, > undefined,undefined,undefined,undefined, > undefined,[],undefined,undefined,undefined, > undefined,"0",undefined,undefined, > undefined,undefined,undefined,undefined,[]}, > {[],[]}, > {http_options,"HTTP/1.1",infinity,true,[], > undefined,false,infinity}, > [104,116,116,112,58,47,47,12371,12428,27010, > 12397,24403,12383,12387,12390,12427,12290,119, > 119,119,46,112,97,103,101,46,115,97,110,110, > 101,116,46,110,101,46,106,112,47,109,97,121, > 117,114,105,47,122,121,111,115,101,105,47,109, > 97,114,95,51,48,54,46,104,116,109,108], > [],none,[]}, > {options, > {undefined,[]}, > 0,2,5,120000,2,disabled,false,inet,default, > default}, > httpc_manager]}}, > {restart_type,temporary}, > {shutdown,4000}, > {child_type,worker}] > We have managed to deploy a workaround for the issue with request hanging using a patch from: http://www.erlang.org/cgi-bin/ezmlm-cgi/2/1601 Now the http:request(head, {URL, []}, [{timeout, 5000}], []) function call returns: {error, internal_error} Here is the patch in the unified format: --- httpc_manager.erl 2009-11-10 19:06:40.000000000 +0300 +++ /home/zaa/httpc_manager.erl 2010-02-10 15:22:23.000000000 +0300 @@ -363,6 +363,11 @@ %% Handled in DOWN {noreply, State}; handle_info({'DOWN', _, _, Pid, _}, State) -> + Requests = ets:match(State#state.handler_db, {'$1', Pid, '$2'}), + [begin + httpc_response:send(From, {Id, {error, internal_error}}) end || + [Id, From] <- Requests], + ets:match_delete(State#state.handler_db, {'_', Pid, '_'}), %% If there where any canceled request, handled by the @@ -500,10 +505,31 @@ ets:insert(State#state.handler_db, {Request#request.id, HandlerPid, Request#request.from}); - _ -> %timeout pipelining failed + Error -> %timeout pipelining failed + case Error of + {request_failed, _Reason, Queue} -> + spawn(fun() -> restart_requests(Queue, State) end); + _E -> + ok + end, start_handler(Request, State) end. +restart_requests([], _) -> ok; +restart_requests([undefined | Queue], State) -> + restart_requests(Queue, State); +restart_requests([Request = #request{ from = answer_sent} | Queue], State) -> + restart_requests(Queue, State); +restart_requests([Request | Queue], State) -> + restart_request(Request, State), + restart_requests(Queue, State). + +restart_request(Request, State) -> + ProfileName = State#state.profile_name, + catch ets:delete(State#state.handler_db, Request#request.id), + httpc_manager:request(Request, ProfileName). + + start_handler(Request, State) -> {ok, Pid} = case is_inets_manager() of --- httpc_handler.erl 2009-11-10 19:06:40.000000000 +0300 +++ /home/zaa/httpc_handler.erl 2010-02-10 15:22:23.000000000 +0300 @@ -284,7 +284,7 @@ undefined}}} end; {error, Reason} -> - {reply, {pipline_failed, Reason}, State} + return_error(pipline_failed, Reason, State) end; handle_call(Request, _, #state{session = Session = @@ -337,9 +337,17 @@ Relaxed]}}} end; {error, Reason} -> - {reply, {request_failed, Reason}, State} + return_error(request_failed, Reason, State) end. +return_error(Error, Reason, State) -> + Queue = case State#state.status of + pipeline -> State#state.pipeline; + keep_alive -> State#state.keep_alive; + _ -> [] + end, + {reply, {Error, Reason, [State#state.request | queue:to_list(Queue)]}, State#state{ pipeline = queue:new(), keep_alive = queue:new() }}. + %%-------------------------------------------------------------------- %% Function: handle_cast(Msg, State) -> {noreply, State} | %% {noreply, State, Timeout} | From arun.suresh@REDACTED Wed Feb 10 16:05:52 2010 From: arun.suresh@REDACTED (Arun Suresh) Date: Wed, 10 Feb 2010 20:35:52 +0530 Subject: Supervisor not restarting a "permanent" child Message-ID: <9f4a617f1002100705v78483b8cie69a9bc66932c4fc@mail.gmail.com> Hi I just encountered a situation where my supervisor isnt restarting a child which has been marked as "permanent". The child is itself another supervisor.. the Spec looks like this : {mq_sup, {mq_sup, start_link,[]}, permanent, infinity, supervisor, [mq_sup]}, The supervisor restart strategy is : {one_for_one, 300, 300} >From the sasl logs.. i see that the supervisor had tried restarting the child a couple of times.. and then gave up restarting it.. Was wondering if anybody else has ever been in such a situation. Thanx -Arun From ishwar@REDACTED Wed Feb 10 18:08:05 2010 From: ishwar@REDACTED (Ish Rattan) Date: Wed, 10 Feb 2010 12:08:05 -0500 (EST) Subject: Two confusions?? Message-ID: 1. In socket based erlang code I have seen tcp-options of the form: [binary, {packet,0},..] [binary, {packet,4},..] what is the difference between the two? 2. A C-client sends 4-byte int request (with numeric value N encoded in the 4-bytes), erlang server receives the request (in binary) and prints as: <<0, 0, 0, N>> what is the interpretation here? -ishwar From vasilij.savin@REDACTED Wed Feb 10 18:26:54 2010 From: vasilij.savin@REDACTED (Vasilij Savin) Date: Wed, 10 Feb 2010 18:26:54 +0100 Subject: [erlang-questions] Two confusions?? In-Reply-To: References: Message-ID: Hello, Comments inline. On Wed, Feb 10, 2010 at 6:08 PM, Ish Rattan wrote: > > 1. In socket based erlang code I have seen > tcp-options of the form: > [binary, {packet,0},..] > [binary, {packet,4},..] > > what is the difference between the two? > First pattern matches if second element of tuple is 0, second - if value is 4. > 2. A C-client sends 4-byte int request (with numeric > value N encoded in the 4-bytes), erlang server > receives the request (in binary) and prints as: > <<0, 0, 0, N>> > > what is the interpretation here? > It is somewhere in documentation for sure. Regards, Vasilij Savin From v@REDACTED Wed Feb 10 19:05:40 2010 From: v@REDACTED (Valentin Micic) Date: Wed, 10 Feb 2010 20:05:40 +0200 Subject: [erlang-questions] Two confusions?? In-Reply-To: Message-ID: <20100210180603.128503D0D4E@mail.pharos-avantgard.com> 1) I don't know how to say this, so, I am just going to say it: "It is somewhere in documentation for sure" is not really an answer, I don't think it is productive to make comments like this, even though the answer may just as well be "somewhere in documentation". If you don't know the answer, don't answer it -- there is no pressure whatsoever. 2) What is certainly worse than giving the answer above -- is giving a wrong answer: >> >> 1. In socket based erlang code I have seen >> tcp-options of the form: >> [binary, {packet,0},..] >> [binary, {packet,4},..] >> >> what is the difference between the two? >> > First pattern matches if second element of tuple is 0, > second - if value is 4 This is really *wrong* as it does not answers the question. {packet, 0} indicates that there is no header indicating the length of the packet. {packet, 4} means that the first 4 octets of the header should be used to calculate the length of the packet. In other words, if the receiving socket Rx is configured with {packet, 4} and the sender Tx sends the following packet: <<0,0,0,2,13,14,0,0,0,5,14,15,16,17, 18, 0,0,0,3, 12>> Receiver Rx shall receive two packets: {tcp,#Port<0.101>, <<13,14>>} {tcp,#Port<0.101>, <<5,16,17,18,19>>} Thus leaving <<0,0,0,3, 12>> in a driver's buffer as the packet is not considered complete. Conversely, if the Rx was configured with {packet, 0}, it would have received: {tcp,#Port<0.101>, <<0,0,0,2,13,14,0,0,0,5,14,15,16,17, 18, 0,0,0,3, 12>>} Use {packet, 4} (or 1,2) if you want driver to accumulate the whole packet for you -- bear in mind, however, that packet header is not going to be presented to you as a part of the received data. Hope this clarifies things. V/ -----Original Message----- From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of Vasilij Savin Sent: 10 February 2010 07:27 PM To: Ish Rattan Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] Two confusions?? Hello, Comments inline. On Wed, Feb 10, 2010 at 6:08 PM, Ish Rattan wrote: > > 1. In socket based erlang code I have seen > tcp-options of the form: > [binary, {packet,0},..] > [binary, {packet,4},..] > > what is the difference between the two? > First pattern matches if second element of tuple is 0, second - if value is 4. > 2. A C-client sends 4-byte int request (with numeric > value N encoded in the 4-bytes), erlang server > receives the request (in binary) and prints as: > <<0, 0, 0, N>> > > what is the interpretation here? > It is somewhere in documentation for sure. Regards, Vasilij Savin From freza@REDACTED Wed Feb 10 19:11:21 2010 From: freza@REDACTED (Jachym Holecek) Date: Wed, 10 Feb 2010 19:11:21 +0100 Subject: [erlang-questions] Two confusions?? In-Reply-To: References: Message-ID: <20100210181121.GA8289@hanele> # Ish Rattan 2010-02-10: > 1. In socket based erlang code I have seen tcp-options of the form: > > [binary, {packet, 0}, ..] > [binary, {packet, 4}, ..] > > what is the difference between the two? These affect application-level framing on the TCP stream. Zero gives raw stream (no framing), four prepends each packet (== single invocation of gen_tcp:send/2 on either side of the pipe) with a four-byte big-endian header encoding payload length. See also inet(3) manpage. The rest of your question needs some more context (depends on which of the above options you use and what is it that you're trying to achieve). Regards, -- Jachym From erlang@REDACTED Wed Feb 10 21:29:57 2010 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 10 Feb 2010 21:29:57 +0100 Subject: anybody written a web cache? Message-ID: <9b08084c1002101229y1f5dbf17r9eaa8be3db81bff7@mail.gmail.com> Hello, Has anybody written a simple web cache? What I'd like are: - own policy for time-to-live (ie many (most) web pages come back with idiotic cache control directives - to force page refreshes) - rate limiting (per site) - ie I don't want to annoy sites by requeting too much data in a short time I'm interested in writing some web-aggregation/meshup software - why? - because I'm fed up with all the crap that most sites deliver. I've been looking at ads. for apartments in Stockholm - one of the largest sites which has ads. for apartments is rather slow - if you click on the data for one apartment 134 http GET requests are issued - most are set uncachable. The generated HTML is crap. same true for hotels - try booking a hotel somewhere ... Seems pretty easy to fetch and cache data on apartments for sale, and hotels, extract the *information* content and re-mesh the information. If the individual sites rate-limit queries form my machine we could set up a distributed net to request the data from random hosts :-) Could be a fun project /Joe From mickael.remond@REDACTED Wed Feb 10 21:35:48 2010 From: mickael.remond@REDACTED (=?iso-8859-1?Q?Micka=EBl_R=E9mond?=) Date: Wed, 10 Feb 2010 21:35:48 +0100 Subject: [erlang-questions] anybody written a web cache? In-Reply-To: <9b08084c1002101229y1f5dbf17r9eaa8be3db81bff7@mail.gmail.com> References: <9b08084c1002101229y1f5dbf17r9eaa8be3db81bff7@mail.gmail.com> Message-ID: Hello, We have a small project that we are about to release. This is basically an ETS cache, with a memcached interface for other language implementation that do not talk Erlang. We do not support all the feature you want, but it should be a good basis. -- Micka?l R?mond http://www.process-one.net Le 10 f?vr. 2010 ? 21:29, Joe Armstrong a ?crit : > Hello, > > Has anybody written a simple web cache? > > What I'd like are: > > - own policy for time-to-live (ie many (most) web pages come back > with idiotic > cache control directives - to force page refreshes) > > - rate limiting (per site) - ie I don't want to annoy sites by > requeting too much data in > a short time > > I'm interested in writing some web-aggregation/meshup software - why? > - because I'm fed > up with all the crap that most sites deliver. > > I've been looking at ads. for apartments in Stockholm - one > of the largest > sites which has ads. for apartments is rather slow - if you click on > the data for one apartment > 134 http GET requests are issued - most are set uncachable. The > generated HTML is crap. > same true for hotels - try booking a hotel somewhere ... > > Seems pretty easy to fetch and cache data on apartments for sale, and hotels, > extract the *information* content and re-mesh the information. > > If the individual sites rate-limit queries form my machine we could > set up a distributed > net to request the data from random hosts :-) > > Could be a fun project > > /Joe > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From ok@REDACTED Thu Feb 11 02:29:43 2010 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 11 Feb 2010 14:29:43 +1300 Subject: [erlang-questions] On Per-module process registration In-Reply-To: <201002102046.01066.als@iinet.net.au> References: <201002102046.01066.als@iinet.net.au> Message-ID: <408079F8-7BBC-48D4-BD2D-824E01478155@cs.otago.ac.nz> On Feb 10, 2010, at 10:46 PM, Anthony Shipman wrote: > I found the pid_name EEP a bit confusing and I'm not sure that it > solves > the problems that I have. I will be happy to revise it once I know what is confusing about it. > Typically I will have a master gen_server > that works with a variable number of slave gen_servers each running > the code of the same module. I don't quite understand what you mean here. Since the -pid_name proposal deals with a *static* set of named "encapsulated within modules but shared between processes and automatically appropriately locked pid-valued mutable variables", it _doesn't_ handle a variable number of anythings. The problem it was intended to solve was the problem of code written according to the examples in Erlang books where a module controls one process and registers a name for it so that the module can communicate with that process, but far from any desire for other processes or modules to find it, the possibillity of other processes or modules sending messages to that process creates a vulnerability. > The master wants to send a message to a > slave. It can't use a pid since the slave might die and be restarted > by its supervisor at any time. Why can't the master keep a dictionary of slaves, keyed by whatever it wants, as part of its state? Since the master has to be informed of the slaves' deaths anyway, it can update the dictionary at the same time, no? > So I must synthesise an atom for a name > that looks something like '/' and put it into the > node's > registry. I worry about the overhead of looking up such a name when > the > registry has 100,000 processes in it. The process registry is a hash table. Accesses to it need to be locked. I tried a wee experiment: - create N processes - send K atomic messages to each two ways: not registered, Pid!..., and registers, Name!.... On an Intel Core 2 Duo Macintosh laptop, +S2:2, * send via Pid 4.97 microseconds (N=20k) 4.62 (N=100k) * send via Name 7.06 microseconds (N=20k) 6.92 (N=100k) It looks as though it scales fairly well. The question is what merit you see in unrelated processes being able to easily do exit(whereis('/'), kill). That's what my EEP is about. > > I've thought that it would be nice if the supervisor could take care > of sending messages e.g. have supervisor:call_to(ChildID, Msg). That seems the obvious way to do it. After all, if you're using OTP supervision, each child _has_ an Id in its child_spec(). We have supervisor:terminate_child(SupRef, Id) supervisor:delete_child(SupRef, Id) supervisor:restart_child(SupRef, Id) So how hard could supervisor:send_child(SupRef, Id, Message) be? send_child(Supervisor, Name, Message) -> call(Supervisor, {send_child, Name, Message}). handle_call({send_child, Name, Message}, _From, State) -> case get_child(Name, State) of {value, Child} when is_pid(Child#child.pid) -> Child#child.pid ! Message, {reply, {ok, Message}, State} ; {value, _} -> {reply, {error, not_running}, State} ; _ -> {reply, {error, not_found}, State} end; WARNING: this code has not been tested. Compiled, yes. Tested, no. This seems like such an obvious thing to do that I must be missing something about how supervision is _supposed_ to be used. > The supervisor then becomes the scope for the naming system. > But that could > be awkward in a non-trivial supervisor tree. I think the main question about that would be whether it is in general advisable, and I'd like to stay out of that argument. If I don't understand why send_child/3 isn't there already, I _certainly_ am not competent to argue why send_descendant(Supervisor, [Id1,...,Idn], Message) isn't. > > > Here's an in-between idea. Let's make a registry be a first class > object. It will function as a scope for a set of process names. The > API > would look something like: > > registry:new() > registry:spawn_link(Registry, Name, MFA) > registry:send_to(Registry, Name, MFA) > registry:call_to(Registry, Name, MFA) > registry:cast_to(Registry, Name, MFA) > > The spawn function would be atomic wrt spawning and registration. The > master would create a registry for itself and spawn each slave within > its scope. A supervisor already has a data structure doing this job. It happens to be implemented as a list of #child records, but that's the job it's doing. You can't _find_ the master's registry without asking it, and on encapsulation principles, I can't see the master handing it out to strangers. (I know "Joe Hates OO", but the Law of Demeter seems to apply here.) You might as well ask the master to do the job for you. Just replace "registry" and "Registry" with "supervisor" and "Supervisor", add a few support functions, and you're done. The principal difference between a dynamically created registry like this and a supervisor ould seem to be that a supervisor will try to restart dead children, while a registry will just scratch them off its list. It's already the case that a supervisor can be told not to resurrect specific children. > > The distinction between a registry and a supervisor could be blurred > by > giving the registry the ability to restart spawned processes that > crash. One might as well go all the way and unify dynamic registries and supervisors completely, and call them supervisors. There is one thing that a dynamic registry could do that a supervisor cannot do, and that is to hold unrelated/uncontrolled processes. It looks to me as though writing a dynamic registry module should not be incredibly difficult, given a design; it's just another plain old Erlang module. > > Another issue is whether a registry could be accessed from more than > one node. This of course is heading in completely the opposite direction from my proposal, which is all about _hiding_ processes, not revealing them in interesting and useful ways. Can gproc do any of the things you need? From mononcqc@REDACTED Thu Feb 11 02:47:51 2010 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 10 Feb 2010 20:47:51 -0500 Subject: [erlang-questions] On Per-module process registration In-Reply-To: <408079F8-7BBC-48D4-BD2D-824E01478155@cs.otago.ac.nz> References: <201002102046.01066.als@iinet.net.au> <408079F8-7BBC-48D4-BD2D-824E01478155@cs.otago.ac.nz> Message-ID: <8b9ee55b1002101747g3b3fb909w5e8e07b831ebe1e2@mail.gmail.com> I've been reading the EEP and trying to grasp it, but this very post really made me grasp what you wanted. I must say the supervisor does sound like a good place to place the registry (I've found myself wanting to use this very design quite a few times already.) This works when you want to address a particular part of a group of processes from the outside, but one of the concerns I have with that is that the supervisor's children who need to access the registry to communicate between themselves then need to be aware of the supervisor's presence and the names which are given there. It sounds like an indirect circular dependency Erlang programs could do without. On Wed, Feb 10, 2010 at 8:29 PM, Richard O'Keefe wrote: > > On Feb 10, 2010, at 10:46 PM, Anthony Shipman wrote: > > I found the pid_name EEP a bit confusing and I'm not sure that it solves >> the problems that I have. >> > > I will be happy to revise it once I know what is confusing about it. > > > Typically I will have a master gen_server >> that works with a variable number of slave gen_servers each running >> the code of the same module. >> > > I don't quite understand what you mean here. > > Since the -pid_name proposal deals with a *static* set of named > "encapsulated within modules but shared between processes and > automatically appropriately locked pid-valued mutable variables", > it _doesn't_ handle a variable number of anythings. > > The problem it was intended to solve was the problem of code > written according to the examples in Erlang books where a module > controls one process and registers a name for it so that the > module can communicate with that process, but far from any > desire for other processes or modules to find it, the possibillity > of other processes or modules sending messages to that process > creates a vulnerability. > > > The master wants to send a message to a >> slave. It can't use a pid since the slave might die and be restarted >> by its supervisor at any time. >> > > Why can't the master keep a dictionary of slaves, keyed by whatever > it wants, as part of its state? Since the master has to be informed > of the slaves' deaths anyway, it can update the dictionary at the > same time, no? > > > So I must synthesise an atom for a name >> that looks something like '/' and put it into the node's >> registry. I worry about the overhead of looking up such a name when the >> registry has 100,000 processes in it. >> > > The process registry is a hash table. > Accesses to it need to be locked. > I tried a wee experiment: > - create N processes > - send K atomic messages to each > two ways: not registered, Pid!..., and registers, Name!.... > On an Intel Core 2 Duo Macintosh laptop, +S2:2, > > * send via Pid 4.97 microseconds (N=20k) 4.62 (N=100k) > * send via Name 7.06 microseconds (N=20k) 6.92 (N=100k) > > It looks as though it scales fairly well. > > The question is what merit you see in unrelated > processes being able to easily do > > exit(whereis('/'), kill). > > That's what my EEP is about. > > >> > I've thought that it would be nice if the supervisor could take care >> of sending messages e.g. have supervisor:call_to(ChildID, Msg). >> > > That seems the obvious way to do it. After all, if you're using > OTP supervision, each child _has_ an Id in its child_spec(). > We have > supervisor:terminate_child(SupRef, Id) > supervisor:delete_child(SupRef, Id) > supervisor:restart_child(SupRef, Id) > So how hard could > supervisor:send_child(SupRef, Id, Message) > be? > > send_child(Supervisor, Name, Message) -> > call(Supervisor, {send_child, Name, Message}). > > handle_call({send_child, Name, Message}, _From, State) -> > case get_child(Name, State) > of {value, Child} when is_pid(Child#child.pid) -> > Child#child.pid ! Message, > {reply, {ok, Message}, State} > ; {value, _} -> > {reply, {error, not_running}, State} > ; _ -> > {reply, {error, not_found}, State} > end; > > WARNING: this code has not been tested. > Compiled, yes. Tested, no. > > This seems like such an obvious thing to do that I must be > missing something about how supervision is _supposed_ to be > used. > > > The supervisor then becomes the scope for the naming system. >> > > But that could >> be awkward in a non-trivial supervisor tree. >> > > I think the main question about that would be whether it is > in general advisable, and I'd like to stay out of that > argument. If I don't understand why send_child/3 isn't > there already, I _certainly_ am not competent to argue > why send_descendant(Supervisor, [Id1,...,Idn], Message) isn't. > > >> >> Here's an in-between idea. Let's make a registry be a first class >> object. It will function as a scope for a set of process names. The API >> would look something like: >> >> registry:new() >> registry:spawn_link(Registry, Name, MFA) >> registry:send_to(Registry, Name, MFA) >> registry:call_to(Registry, Name, MFA) >> registry:cast_to(Registry, Name, MFA) >> >> The spawn function would be atomic wrt spawning and registration. The >> master would create a registry for itself and spawn each slave within >> its scope. >> > > A supervisor already has a data structure doing this job. > It happens to be implemented as a list of #child records, > but that's the job it's doing. > > You can't _find_ the master's registry without asking it, > and on encapsulation principles, I can't see the master > handing it out to strangers. (I know "Joe Hates OO", but > the Law of Demeter seems to apply here.) You might as > well ask the master to do the job for you. Just replace > "registry" and "Registry" with "supervisor" and "Supervisor", > add a few support functions, and you're done. > > The principal difference between a dynamically created > registry like this and a supervisor ould seem to be > that a supervisor will try to restart dead children, > while a registry will just scratch them off its list. > It's already the case that a supervisor can be told not > to resurrect specific children. > > >> > The distinction between a registry and a supervisor could be blurred by >> giving the registry the ability to restart spawned processes that crash. >> > > One might as well go all the way and unify dynamic registries and > supervisors completely, and call them supervisors. > > There is one thing that a dynamic registry could do that a > supervisor cannot do, and that is to hold unrelated/uncontrolled > processes. > > It looks to me as though writing a dynamic registry module should > not be incredibly difficult, given a design; it's just another > plain old Erlang module. > > >> > Another issue is whether a registry could be accessed from more than >> one node. >> > > This of course is heading in completely the opposite direction from > my proposal, which is all about _hiding_ processes, not revealing > them in interesting and useful ways. > > Can gproc do any of the things you need? > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ok@REDACTED Thu Feb 11 03:44:03 2010 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 11 Feb 2010 15:44:03 +1300 Subject: [erlang-questions] On Per-module process registration In-Reply-To: <8b9ee55b1002101747g3b3fb909w5e8e07b831ebe1e2@mail.gmail.com> References: <201002102046.01066.als@iinet.net.au> <408079F8-7BBC-48D4-BD2D-824E01478155@cs.otago.ac.nz> <8b9ee55b1002101747g3b3fb909w5e8e07b831ebe1e2@mail.gmail.com> Message-ID: <7AFD1F59-2E49-4687-B8C8-656042018698@cs.otago.ac.nz> On Feb 11, 2010, at 2:47 PM, Fred Hebert wrote: > I've been reading the EEP and trying to grasp it, but this very post > really made me grasp what you wanted. I'm sorry I explained it so badly in the first place. > > This works when you want to address a particular part of a group of > processes from the outside, but one of the concerns I have with that > is that the supervisor's children who need to access the registry to > communicate between themselves then need to be aware of the > supervisor's presence and the names which are given there. It sounds > like an indirect circular dependency Erlang programs could do without. Oh, agreed. But the circularity _exists_. Do it with a dynamically created registry (should such a thing exist), and - the processes have to know about the registry - the registry exists to know about the processes In other contexts I've resorted to Pids = spawn a bunch of new processes, Info = some information derived from them that they need to share, [Pid ! {info,Info} || Pid <- Pids] where the first thing each new process does is receive {info,Info} -> ... For example, set up a grid of processes, then tell each process what its neighbours are (West -> East, but also West <- East). Indirection is the only way we _can_ break cycles in Erlang. Of course cycles are always something to beware of. From jebu.ittiachen@REDACTED Thu Feb 11 08:55:00 2010 From: jebu.ittiachen@REDACTED (Jebu Ittiachen) Date: Thu, 11 Feb 2010 13:25:00 +0530 Subject: erlc returns error with parameterized module having binary comprehension Message-ID: <3e28ae01002102355w533466d6pca0035f377425063@mail.gmail.com> Hi, When compiling the attached file I get the following error $ erlc bug.erl ./bug.erl:none: internal error in expand_module; crash reason: {function_clause, [{sys_expand_pmod,expr, [{b_generate,5, {bin,5, [{bin_element,5, {var,5,'A'}, {integer,5,1}, [integer,{unit,1},unsigned,big]}]}, {bin,5, [{bin_element,5, {integer,5,12345}, {integer,5,8}, [integer,{unit,1},unsigned,big]}]}}, {pmod, ['I'], [{module_info,0},{module_info,1}], [{buggy_fun,0},{module_info,0},{module_info,1}], [{module_info,0},{module_info,1}]}]}, {sys_expand_pmod,lc_quals,2}, {sys_expand_pmod,expr,2}, {sys_expand_pmod,exprs,2}, {sys_expand_pmod,clause,2}, {sys_expand_pmod,clauses,2}, {sys_expand_pmod,function,4}, {sys_expand_pmod,form,2}]} The same works fine when I remove the module parameters. Any idea why this would be happening? -- Regards, Jebu Ittiachen -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.erl Type: application/octet-stream Size: 90 bytes Desc: not available URL: From rvirding@REDACTED Thu Feb 11 10:51:15 2010 From: rvirding@REDACTED (Robert Virding) Date: Thu, 11 Feb 2010 10:51:15 +0100 Subject: An appeal. Fwd: Simon Singh's weird idea that might just work Message-ID: <3dbc6d1c1002110151w6e8872d0mc31920e8847be40d@mail.gmail.com> Sorry for posting something completely out of context on this mailing-list but it is something which I feel is important enough to warrant that. Posting it here is my idea so complaints goto me. Please support it. Robert ---------- Forwarded message ---------- From: Date: 10 February 2010 22:32 Subject: Simon Singh's weird idea that might just work To: rvirding@REDACTED Dear Friends, I?ve had an idea ? an unusual idea, but I think it might just work. As you know, England?s chilling libel laws need to be reformed. One way to help achieve this is for 100,000 people to sign the petition for libel reform before the political parties write their manifestos for the election. We have 17,000 signatures, but we really need 100,000, and we need your help to get there. ?http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlAYDEgEBgALUg%3D%3D My idea My idea is simple: if everyone who has already signed up persuades just one more person each week to sign the petition then we will reach our goal within a month! One person per week is all we need, but please spread the word as much as you can. In fact, if you persuade 10 people to sign up then email me (simon@REDACTED ) and I promise to thank you by printing your name in my next book ? which I will start writing as soon as I have put my own libel case behind me. I cannot say when this will be, but it is a very real promise. My only caveat is that I will limit this to the first thousand people who recruit ten supporters. When persuading your friends remember to tell them: (a) English libel laws have been condemned by the UN Human Rights Committee. (b) These laws gag scientists, bloggers and journalists who want to discuss matters of genuine public interest (and public health!). (c) Our laws give rise to libel tourism, whereby the rich and the powerful (Saudi billionaires, Russian oligarchs and overseas corporations) come to London to sue writers because English libel laws are so hostile to responsible journalism. (In fact, it is exactly because English libel laws have this global impact that we welcome signatories to the petition from around the world.) (d) Vested interests can use their resources to bully and intimidate those who seek to question them. The cost of a libel trial in England is 100 times more expensive than the European average and typically runs to over ?1 million. (e) Three separate ongoing libel cases involve myself and two medical researchers raising concerns about three medical treatments. We face losing ?1 million each. In future, why would anyone else raise similar concerns? If these health matters are not reported, then the public is put at risk. My experience has been sobering. I?ve had to spend ?100,000 to defend my writing and have put my life on hold for almost two years. However, the prospect of reforming our libel laws keeps me cheerful. Thanks so much for your support. We?ve only got one shot at this ? so I hope you can persuade 1 (or maybe 10) friends, family and colleagues to sign. Massive thanks, Simon ?http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlAYDEgEBgALUg%3D%3D The Libel Reform Campaign is a coalition of English PEN, Index on Censorship and Sense About Science. So far, 188 MPs have signed our Parliamentary Early Day Motion calling for libel reform and the Justice Secretary Jack Straw has formed a working party that the Libel Reform Coalition is represented on. Please also considering donating to keep our campaign going: http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlEYDEgEBgALUg%3D%3D -- If you do not want to receive any more newsletters, http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlYYDEgEBgALUg%3D%3D To update your preferences and to unsubscribe visit http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlcYDEgEBgALUg%3D%3D Forward a Message to Someone http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlQYDEgEBgALUg%3D%3D -- Powered by PHPlist, www.phplist.com -- From per@REDACTED Thu Feb 11 11:05:01 2010 From: per@REDACTED (Per Hedeland) Date: Thu, 11 Feb 2010 11:05:01 +0100 (CET) Subject: Dialyzer bug with 'not (boolexpr)' guard Message-ID: <201002111005.o1BA51Cf049896@pluto.hedeland.org> Hi, I believe the code below demonstrates a bug in dialyzer (2.1.0) - it produces the warning: diabug.erl:19: Clause guard cannot succeed. The variable Cs was matched against the type any() for the first test/1 clause, but of course the claim can easily be refuted by calling test/0. (The other 2 test/1 clauses are just there to narrow down the bug.) Thanks --Per Hedeland ------ -module(diabug). -compile(export_all). -record(cs, { children = [], actions = [] }). -define(is_internal(X), ((X#cs.children /= []) or (X#cs.actions /= []))). -define(has_children(X), (X#cs.children /= [])). test() -> test(#cs{}). test(Cs) when not ?is_internal(Cs) -> foo; test(Cs) when not ?has_children(Cs) -> bar; test(Cs) when ?is_internal(Cs) -> baz. ------ From vasilij.savin@REDACTED Thu Feb 11 11:11:59 2010 From: vasilij.savin@REDACTED (Vasilij Savin) Date: Thu, 11 Feb 2010 12:11:59 +0200 Subject: [erlang-questions] Two confusions?? In-Reply-To: <20100210181121.GA8289@hanele> References: <20100210181121.GA8289@hanele> Message-ID: Hej everyone, Just I want to say I am sorry for giving wrong answers. I am still learning Erlang. Regards, Vasilij Savin From erlang@REDACTED Thu Feb 11 11:16:04 2010 From: erlang@REDACTED (Joe Armstrong) Date: Thu, 11 Feb 2010 11:16:04 +0100 Subject: [erlang-questions] An appeal. Fwd: Simon Singh's weird idea that might just work In-Reply-To: <3dbc6d1c1002110151w6e8872d0mc31920e8847be40d@mail.gmail.com> References: <3dbc6d1c1002110151w6e8872d0mc31920e8847be40d@mail.gmail.com> Message-ID: <9b08084c1002110216u37fcfca2ub77eb0b0f89c3961@mail.gmail.com> You're forgiven - the defense of freedom of speech is more important than programming anyway. I've signed up. For those of you who haven't followed Singh's dilemma. Singh was sued for libel for daring to say that certain alternative medicine practices had no scientific validation of their claims - Indeed were I to repeat his claims here - I might be sued. So it seems like that with the support of the English courts nobody anywhere in the world can say that "this is unscientific" without being in danger of being sued for libel. Since I often say "this is unscientific" this is kind of disturbing. /Joe On Thu, Feb 11, 2010 at 10:51 AM, Robert Virding wrote: > Sorry for posting something completely out of context on this > mailing-list but it is something which I feel is important enough to > warrant that. Posting it here is my idea so complaints goto me. > > Please support it. > > Robert > > > ---------- Forwarded message ---------- > From: ? > Date: 10 February 2010 22:32 > Subject: Simon Singh's weird idea that might just work > To: rvirding@REDACTED > > Dear Friends, > > I?ve had an idea ? an unusual idea, but I think it might just > work. > > As you know, England?s chilling libel laws need to be reformed. One > way to help achieve this is for 100,000 people to sign the petition > for libel reform before the political parties write their manifestos > for the election. We have 17,000 signatures, but we really need > 100,000, and we need your help to get there. > > ?http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlAYDEgEBgALUg%3D%3D > > My idea > > My idea is simple: if everyone who has already signed up persuades > just one more person each week to sign the petition then we will reach > our goal within a month! > > One person per week is all we need, but please spread the word as > much as you can. In fact, if you persuade 10 people to sign up then > email me (simon@REDACTED > ) and I promise to thank you by printing your name in my next book > ? which I will start writing as soon as I have put my own libel case > behind me. I cannot say when this will be, but it is a very real > promise. My only caveat is that I will limit this to the first > thousand people who recruit ten supporters. > > When persuading your friends remember to tell them: > > (a) English libel laws have been condemned by the UN Human Rights > Committee. > > (b) These laws gag scientists, bloggers and journalists who want to > discuss matters of genuine public interest (and public health!). > > (c) Our laws give rise to libel tourism, whereby the rich and the > powerful (Saudi billionaires, Russian oligarchs and overseas > corporations) come to London to sue writers because English libel laws > are so hostile to responsible journalism. (In fact, it is exactly > because English libel laws have this global impact that we welcome > signatories to the petition from around the world.) > > (d) Vested interests can use their resources to bully and intimidate > those who seek to question them. The cost of a libel trial in England > is 100 times more expensive than the European average and typically > runs to over ?1 million. > > (e) Three separate ongoing libel cases involve myself and two medical > researchers raising concerns about three medical treatments. We face > losing ?1 million each. In future, why would anyone else raise similar > concerns? If these health matters are not reported, then the public is > put at risk. > > My experience has been sobering. I?ve had to spend ?100,000 to > defend my writing and have put my life on hold for almost two years. > However, the prospect of reforming our libel laws keeps me cheerful. > > Thanks so much for your support. We?ve only got one shot at this > ? so I hope you can persuade 1 (or maybe 10) friends, family and > colleagues to sign. > > Massive thanks, > > Simon > > ?http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlAYDEgEBgALUg%3D%3D > > The Libel Reform Campaign is a coalition of English PEN, Index on > Censorship and Sense About Science. > > So far, 188 MPs have signed our Parliamentary Early Day Motion > calling for libel reform and the Justice Secretary Jack Straw has > formed a working party that the Libel Reform Coalition is represented > on. > > Please also considering donating to keep our campaign going: > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlEYDEgEBgALUg%3D%3D > > > > -- > If you do not want to receive any more newsletters, > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlYYDEgEBgALUg%3D%3D > > To update your preferences and to unsubscribe visit > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlcYDEgEBgALUg%3D%3D > Forward a Message to Someone > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlQYDEgEBgALUg%3D%3D > > > -- > Powered by PHPlist, www.phplist.com -- > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From corticalcomputer@REDACTED Thu Feb 11 11:27:06 2010 From: corticalcomputer@REDACTED (G.S.) Date: Thu, 11 Feb 2010 02:27:06 -0800 Subject: [erlang-questions] An appeal. Fwd: Simon Singh's weird idea that might just work In-Reply-To: <9b08084c1002110216u37fcfca2ub77eb0b0f89c3961@mail.gmail.com> References: <3dbc6d1c1002110151w6e8872d0mc31920e8847be40d@mail.gmail.com> <9b08084c1002110216u37fcfca2ub77eb0b0f89c3961@mail.gmail.com> Message-ID: <2a67d3ff1002110227x27128e42kc6e37e6027a8a82e@mail.gmail.com> So it seems we're going back to the dark ages then. I bet they just can't wait to burn us Scientists... or as they used to call us: heretics. On Thu, Feb 11, 2010 at 2:16 AM, Joe Armstrong wrote: > You're forgiven - the defense of freedom of speech is more important > than programming anyway. > > I've signed up. For those of you who haven't followed Singh's dilemma. > Singh was sued for > libel for daring to say that certain alternative medicine practices > had no scientific validation of their > claims - Indeed were I to repeat his claims here - I might be sued. > > So it seems like that with the support of the English courts nobody > anywhere in the world > can say that "this is unscientific" without being in danger of being > sued for libel. > > Since I often say "this is unscientific" this is kind of disturbing. > > /Joe > > On Thu, Feb 11, 2010 at 10:51 AM, Robert Virding > wrote: > > Sorry for posting something completely out of context on this > > mailing-list but it is something which I feel is important enough to > > warrant that. Posting it here is my idea so complaints goto me. > > > > Please support it. > > > > Robert > > > > > > ---------- Forwarded message ---------- > > From: > > Date: 10 February 2010 22:32 > > Subject: Simon Singh's weird idea that might just work > > To: rvirding@REDACTED > > > > Dear Friends, > > > > I?ve had an idea ? an unusual idea, but I think it might just > > work. > > > > As you know, England?s chilling libel laws need to be reformed. One > > way to help achieve this is for 100,000 people to sign the petition > > for libel reform before the political parties write their manifestos > > for the election. We have 17,000 signatures, but we really need > > 100,000, and we need your help to get there. > > > > > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlAYDEgEBgALUg%3D%3D > > > > My idea > > > > My idea is simple: if everyone who has already signed up persuades > > just one more person each week to sign the petition then we will reach > > our goal within a month! > > > > One person per week is all we need, but please spread the word as > > much as you can. In fact, if you persuade 10 people to sign up then > > email me (simon@REDACTED > > ) and I promise to thank you by printing your name in my next book > > ? which I will start writing as soon as I have put my own libel case > > behind me. I cannot say when this will be, but it is a very real > > promise. My only caveat is that I will limit this to the first > > thousand people who recruit ten supporters. > > > > When persuading your friends remember to tell them: > > > > (a) English libel laws have been condemned by the UN Human Rights > > Committee. > > > > (b) These laws gag scientists, bloggers and journalists who want to > > discuss matters of genuine public interest (and public health!). > > > > (c) Our laws give rise to libel tourism, whereby the rich and the > > powerful (Saudi billionaires, Russian oligarchs and overseas > > corporations) come to London to sue writers because English libel laws > > are so hostile to responsible journalism. (In fact, it is exactly > > because English libel laws have this global impact that we welcome > > signatories to the petition from around the world.) > > > > (d) Vested interests can use their resources to bully and intimidate > > those who seek to question them. The cost of a libel trial in England > > is 100 times more expensive than the European average and typically > > runs to over ?1 million. > > > > (e) Three separate ongoing libel cases involve myself and two medical > > researchers raising concerns about three medical treatments. We face > > losing ?1 million each. In future, why would anyone else raise similar > > concerns? If these health matters are not reported, then the public is > > put at risk. > > > > My experience has been sobering. I?ve had to spend ?100,000 to > > defend my writing and have put my life on hold for almost two years. > > However, the prospect of reforming our libel laws keeps me cheerful. > > > > Thanks so much for your support. We?ve only got one shot at this > > ? so I hope you can persuade 1 (or maybe 10) friends, family and > > colleagues to sign. > > > > Massive thanks, > > > > Simon > > > > > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlAYDEgEBgALUg%3D%3D > > > > The Libel Reform Campaign is a coalition of English PEN, Index on > > Censorship and Sense About Science. > > > > So far, 188 MPs have signed our Parliamentary Early Day Motion > > calling for libel reform and the Justice Secretary Jack Straw has > > formed a working party that the Libel Reform Coalition is represented > > on. > > > > Please also considering donating to keep our campaign going: > > > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlEYDEgEBgALUg%3D%3D > > > > > > > > -- > > If you do not want to receive any more newsletters, > > > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlYYDEgEBgALUg%3D%3D > > > > To update your preferences and to unsubscribe visit > > > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlcYDEgEBgALUg%3D%3D > > Forward a Message to Someone > > > http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlQYDEgEBgALUg%3D%3D > > > > > > -- > > Powered by PHPlist, www.phplist.com -- > > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > See http://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ulf.wiger@REDACTED Thu Feb 11 11:46:34 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 11 Feb 2010 11:46:34 +0100 Subject: new gproc, new feature + move to github Message-ID: <4B73E00A.3090901@erlang-solutions.com> Given the recent discussion about gproc, and my background task of migrating my projects to github, I have committed a new version of gproc: http://svn.ulf.wiger.net/gproc/branches/0912/gproc http://github.com/uwiger/gproc From now on, unless people object, I will update the git version. The new feature in this gproc version is gproc:await(Key, Timeout) -> {Pid, Value} | error(timeout) Currently only for local names, the function waits for a name to be registered and then returns the pid of the registered process. Given that gproc allows processes to register multiple names, this can serve as a simple resource broker. There is also a non-blocking version, gproc:nb_wait(Key) -> Ref. Gproc will send a message, {gproc, Ref, registered, {Key, Pid, Value}} once the name appears. The feature doesn't add any execution overhead to name registration, except when there are processes waiting for the name, in which case there will obviously be a cost for notifying them. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From mazen.harake@REDACTED Thu Feb 11 12:09:14 2010 From: mazen.harake@REDACTED (Mazen Harake) Date: Thu, 11 Feb 2010 11:09:14 +0000 (GMT) Subject: [erlang-questions] Two confusions?? In-Reply-To: <1861079143.21731265886395320.JavaMail.root@zimbra> Message-ID: <253475547.21811265886554900.JavaMail.root@zimbra> Hi Vasilij, I'll tell you a short story about something I learned when I first started using the Internet[s]. IRC was my thing I used to hang in all the programming channels on various servers. Naturally many people would ask questions and as usual on the internet few would answer because they would consider them to be "noob" questions. People would only discuss new ideas or really difficult problems (along with religious ones as well such as editors and what not). Anyway... I noticed after a while a repeating behaviour; if someone asks the most simple question and get 1 single answer and this answer would be *wrong* then immediately 3-4 replies after that would come in with explanations on why it was wrong and how it really was. Sure enough the first person to respond, which was wrong, got a lot of heat but hadn't it been for the simple kind principal of wanting to help the person who asked the question in the first place might not have gotten a clear answer. Also, this comes to mind: http://xkcd.com/386/ Don't worry about it; I believe that this sort of thing actually helps somewhat... well... to some extent at least. Cheers. /Mazen ----- Original Message ----- From: "Vasilij Savin" To: erlang-questions@REDACTED Sent: Thursday, 11 February, 2010 12:11:59 GMT +02:00 Harare / Pretoria Subject: Re: [erlang-questions] Two confusions?? Hej everyone, Just I want to say I am sorry for giving wrong answers. I am still learning Erlang. Regards, Vasilij Savin From pablo.platt@REDACTED Thu Feb 11 14:46:23 2010 From: pablo.platt@REDACTED (Pablo Platt) Date: Thu, 11 Feb 2010 05:46:23 -0800 (PST) Subject: [erlang-questions] new gproc, new feature + move to github In-Reply-To: <4B73E00A.3090901@erlang-solutions.com> References: <4B73E00A.3090901@erlang-solutions.com> Message-ID: <389337.77182.qm@web112619.mail.gq1.yahoo.com> Thank you for moving it to github and adding features. What is the difference between gproc:await and registering a unique name with add_local_name ? ________________________________ From: Ulf Wiger To: erlang-questions@REDACTED Sent: Thu, February 11, 2010 12:46:34 PM Subject: [erlang-questions] new gproc, new feature + move to github Given the recent discussion about gproc, and my background task of migrating my projects to github, I have committed a new version of gproc: http://svn.ulf.wiger.net/gproc/branches/0912/gproc http://github.com/uwiger/gproc >From now on, unless people object, I will update the git version. The new feature in this gproc version is gproc:await(Key, Timeout) -> {Pid, Value} | error(timeout) Currently only for local names, the function waits for a name to be registered and then returns the pid of the registered process. Given that gproc allows processes to register multiple names, this can serve as a simple resource broker. There is also a non-blocking version, gproc:nb_wait(Key) -> Ref. Gproc will send a message, {gproc, Ref, registered, {Key, Pid, Value}} once the name appears. The feature doesn't add any execution overhead to name registration, except when there are processes waiting for the name, in which case there will obviously be a cost for notifying them. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED From pablo.platt@REDACTED Thu Feb 11 14:50:16 2010 From: pablo.platt@REDACTED (Pablo Platt) Date: Thu, 11 Feb 2010 05:50:16 -0800 (PST) Subject: getting the path of an http request as binary Message-ID: <910468.94104.qm@web112617.mail.gq1.yahoo.com> Hi mochiweb uses: gen_tcp:recv(Socket, 0, ?REQUEST_RECV_TIMEOUT) which result with: {ok, {http_request, Method, Path, Version}} where the Path is a list. Is it possible to get the Path as binary without having to convert it? Are there docs about http_binary packet parser in R13B03? Thanks From sverker@REDACTED Thu Feb 11 15:24:07 2010 From: sverker@REDACTED (Sverker Eriksson) Date: Thu, 11 Feb 2010 15:24:07 +0100 Subject: [erlang-questions] getting the path of an http request as binary In-Reply-To: <910468.94104.qm@web112617.mail.gq1.yahoo.com> References: <910468.94104.qm@web112617.mail.gq1.yahoo.com> Message-ID: <4B741307.8050300@erix.ericsson.se> Pablo Platt wrote: > Hi > > mochiweb uses: > gen_tcp:recv(Socket, 0, ?REQUEST_RECV_TIMEOUT) > which result with: > {ok, {http_request, Method, Path, Version}} > where the Path is a list. > > Is it possible to get the Path as binary without having to convert it? > > Socket option {packet, http_bin} > Are there docs about http_binary packet parser in R13B03? > > inet:setopts/2 erlang:decode_packet/3 /Sverker, Erlang/OTP Ericsson From smith.winston.101@REDACTED Thu Feb 11 15:46:18 2010 From: smith.winston.101@REDACTED (Winston Smith) Date: Thu, 11 Feb 2010 09:46:18 -0500 Subject: Values of os:type() on 32/64-bit Windows Message-ID: I don't have access to any Windows machines running Erlang, let alone any 64-bit versions. Does anyone know what the values of os:type() are on Windows platforms? The documentation states that it'll return {win32, nt|windows} (with windows being Windows 95). Is this still the case for 64-bit platforms? Are there any other ways to detect the bitness of the platform? x86-64 vs Itanium? I actually don't care about the Windows version, just the CPU architecture. More specifically, I have a linked in driver and I load it by looking at the platform via os:type() (and on unix, uname -m) to generate a platform-architecture specific directory name, e.g. linux-x86_64 or darwin-i386. I'm really trying to differentiate between Windows i386, Windows x86_64 and Windows Itanium from within Erlang. Many thanks! From leap@REDACTED Thu Feb 11 16:35:24 2010 From: leap@REDACTED (Michael Turner) Date: Thu, 11 Feb 2010 15:35:24 +0000 Subject: Singh-ing the English Libel Law Blues In-Reply-To: <9b08084c1002110216u37fcfca2ub77eb0b0f89c3961@mail.gmail.com> Message-ID: <3i3Tk1Ts.1265902524.0050490.leap@gol.com> Not to defend Simon Singh's intellectual assailants (who, to be sure, disgust me no end), but it appears the *legal* crux of the matter is not in Singh in claiming that chiropractic lacked "scientific validation". Rather, it's in whether Singh was attributing *deceitful motives* to chiropractors when he wrote that chiropractors "happily" (his word) pursue and promote treatments he called "bogus". No, really. Singh claims he didn't mean that chiropractors were happily aware of their own quackery. I find him credible on that count. Just as I find credible the claims of most chiropractors that they are sincere. I've met only two chiropractors who had grave doubts on this score. One of them was still practicing, but miserable. (I think he was just trying to keep up his alimony payments at that point.) The other had given up practice -- in fact, I met him at a Tokyo Skeptics group, if you can believe that. On the other hand, I come more from hacker culture, where "bogus" can even mean simply "doesn't work very well" -- and in which author of the bogus software might actually believe that his "bugs" are "features". I'm not tuned into any particular British nuances for "bogus", perhaps owing to the transatlantic quantum uncertainty of bogons. Not meaning any disrespect to Singh (or Robert Virding, or Joe Armstrong or anyone else who chimes in here), but there are days when I'd like to see a certain senator from Oklahoma charged with libel, and convicted for it, for calling global warming a "hoax". James Inhofe is certainly intelligent enough to know that, in using such a word, he's openly and unabashedly accusing thousands of climatologists (and not a few other scientists collaborating with them) with conspiracy not just to deceive but to defraud taxpayers. And it doesn't matter what you believe about AGW *as a scientific theory* -- calling it a hoax is still libelous. Now, if Inhofe had merely maintained that AGW was "bogus", I might grudgingly say there was no case against him -- if only because I interpret "bogus" a little loosely, because I expect others to do the same, and because I believe in the principle that people are innocent until proven guilty, yes, even when they are politicians. In closing, I'd like to point out that 99% of all software problems are caused by not using Erlang. Or maybe I mean that 99% of all benefits experienced by Erlang users are illusory, that they owe to a placebo effect enhanced by the very weirdness of the language, what with all the usual software conceptual vertebrae being so sharply adjusted by it. Oh, I'm so confused. Well, OK, here's something I can say with total certainty: writing in Erlang has damaged my brain. It has caused me to suffer a stroke. I know this because I now have this highly unusual aphasia where I think every word starting with a capital letter can be given any meaning whatsoever -- but only once. Accordingly, Ericcson will shortly be hearing from my lawyers. I'm reasonable, though. I'm willing to settle out of court for $14 billion. Note that Ericcson can't squirm out of this one by declaring bankruptcy and reorganizing. Because 'E' is a capital letter. yours in atomicity, -michael turner P.S. A signed copy will go to 10,000 volunteer proofreaders if they can find even one typo in my forthcoming book, "The _ Programming Language". On 2/11/2010, "Joe Armstrong" wrote: >You're forgiven - the defense of freedom of speech is more important >than programming anyway. > >I've signed up. For those of you who haven't followed Singh's dilemma. >Singh was sued for >libel for daring to say that certain alternative medicine practices >had no scientific validation of their >claims - Indeed were I to repeat his claims here - I might be sued. > >So it seems like that with the support of the English courts nobody >anywhere in the world >can say that "this is unscientific" without being in danger of being >sued for libel. > >Since I often say "this is unscientific" this is kind of disturbing. > >/Joe > >On Thu, Feb 11, 2010 at 10:51 AM, Robert Virding wrote: >> Sorry for posting something completely out of context on this >> mailing-list but it is something which I feel is important enough to >> warrant that. Posting it here is my idea so complaints goto me. >> >> Please support it. >> >> Robert >> >> >> ---------- Forwarded message ---------- >> From: ? >> Date: 10 February 2010 22:32 >> Subject: Simon Singh's weird idea that might just work >> To: rvirding@REDACTED >> >> Dear Friends, >> >> I?e had an idea ?an unusual idea, but I think it might just >> work. >> >> As you know, England? chilling libel laws need to be reformed. One >> way to help achieve this is for 100,000 people to sign the petition >> for libel reform before the political parties write their manifestos >> for the election. We have 17,000 signatures, but we really need >> 100,000, and we need your help to get there. >> >> ?http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlAYDEgEBgALUg%3D%3D >> >> My idea >> >> My idea is simple: if everyone who has already signed up persuades >> just one more person each week to sign the petition then we will reach >> our goal within a month! >> >> One person per week is all we need, but please spread the word as >> much as you can. In fact, if you persuade 10 people to sign up then >> email me (simon@REDACTED >> ) and I promise to thank you by printing your name in my next book >> ?which I will start writing as soon as I have put my own libel case >> behind me. I cannot say when this will be, but it is a very real >> promise. My only caveat is that I will limit this to the first >> thousand people who recruit ten supporters. >> >> When persuading your friends remember to tell them: >> >> (a) English libel laws have been condemned by the UN Human Rights >> Committee. >> >> (b) These laws gag scientists, bloggers and journalists who want to >> discuss matters of genuine public interest (and public health!). >> >> (c) Our laws give rise to libel tourism, whereby the rich and the >> powerful (Saudi billionaires, Russian oligarchs and overseas >> corporations) come to London to sue writers because English libel laws >> are so hostile to responsible journalism. (In fact, it is exactly >> because English libel laws have this global impact that we welcome >> signatories to the petition from around the world.) >> >> (d) Vested interests can use their resources to bully and intimidate >> those who seek to question them. The cost of a libel trial in England >> is 100 times more expensive than the European average and typically >> runs to over ? million. >> >> (e) Three separate ongoing libel cases involve myself and two medical >> researchers raising concerns about three medical treatments. We face >> losing ? million each. In future, why would anyone else raise similar >> concerns? If these health matters are not reported, then the public is >> put at risk. >> >> My experience has been sobering. I?e had to spend ?00,000 to >> defend my writing and have put my life on hold for almost two years. >> However, the prospect of reforming our libel laws keeps me cheerful. >> >> Thanks so much for your support. We?e only got one shot at this >> ?so I hope you can persuade 1 (or maybe 10) friends, family and >> colleagues to sign. >> >> Massive thanks, >> >> Simon >> >> ?http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlAYDEgEBgALUg%3D%3D >> >> The Libel Reform Campaign is a coalition of English PEN, Index on >> Censorship and Sense About Science. >> >> So far, 188 MPs have signed our Parliamentary Early Day Motion >> calling for libel reform and the Justice Secretary Jack Straw has >> formed a working party that the Libel Reform Coalition is represented >> on. >> >> Please also considering donating to keep our campaign going: >> http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlEYDEgEBgALUg%3D%3D >> >> >> >> -- >> If you do not want to receive any more newsletters, >> http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlYYDEgEBgALUg%3D%3D >> >> To update your preferences and to unsubscribe visit >> http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlcYDEgEBgALUg%3D%3D >> Forward a Message to Someone >> http://libelreform.indiemedium.com/lt.php?id=ZkQFVwkEBlQYDEgEBgALUg%3D%3D >> >> >> -- >> Powered by PHPlist, www.phplist.com -- >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From leap@REDACTED Thu Feb 11 16:41:37 2010 From: leap@REDACTED (Michael Turner) Date: Thu, 11 Feb 2010 15:41:37 +0000 Subject: [erlang-questions] Values of os:type() on 32/64-bit Windows In-Reply-To: Message-ID: <7SKlL2y8.1265902897.3191490.leap@gol.com> On 2/11/2010, "Winston Smith" wrote: >I don't have access to any Windows machines running Erlang, let alone >any 64-bit versions. Does anyone know what the values of os:type() >are on Windows platforms? [snip] I get {win32,nt}. Erlang R13B01 (erts-5.7.2). Running on Windows XP. Hey, at least it didn't core-dump when I asked it. -michael turner From pablo.platt@REDACTED Thu Feb 11 15:42:51 2010 From: pablo.platt@REDACTED (Pablo Platt) Date: Thu, 11 Feb 2010 06:42:51 -0800 (PST) Subject: [erlang-questions] getting the path of an http request as binary In-Reply-To: <4B741307.8050300@erix.ericsson.se> References: <910468.94104.qm@web112617.mail.gq1.yahoo.com> <4B741307.8050300@erix.ericsson.se> Message-ID: <913435.79074.qm@web112602.mail.gq1.yahoo.com> >> Is it possible to get the Path as binary without having to convert it? >Socket option {packet, http_bin} In mochiweb_socket_server/init the BaseOpts have {packet, 0} Which according to the inet docs means that "no packaging is done". What will replacing {packet, 0} with {packet, http_bin}do? I probably can't expect it to just work. ________________________________ From: Sverker Eriksson To: Pablo Platt Cc: erlang-questions@REDACTED Sent: Thu, February 11, 2010 4:24:07 PM Subject: Re: [erlang-questions] getting the path of an http request as binary Pablo Platt wrote: > Hi > > mochiweb uses: > gen_tcp:recv(Socket, 0, ?REQUEST_RECV_TIMEOUT) > which result with: > {ok, {http_request, Method, Path, Version}} > where the Path is a list. > > Is it possible to get the Path as binary without having to convert it? > > Socket option {packet, http_bin} > Are there docs about http_binary packet parser in R13B03? > > inet:setopts/2 erlang:decode_packet/3 /Sverker, Erlang/OTPEricsson ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED From pablo.platt@REDACTED Thu Feb 11 15:50:32 2010 From: pablo.platt@REDACTED (Pablo Platt) Date: Thu, 11 Feb 2010 06:50:32 -0800 (PST) Subject: [erlang-questions] getting the path of an http request as binary Message-ID: <146507.95010.qm@web112608.mail.gq1.yahoo.com> Digging further I found that mochiweb_http:loop/2 set inet:setopts(Socket, [{packet, http}]) So I guess replacing it should work: inet:setopts(Socket, [{packet, http_bin}]) There are probably places where mochiweb expects lists and not binaries but it'll be easy to fix ________________________________ From: Pablo Platt To: Sverker Eriksson Cc: erlang-questions@REDACTED Sent: Thu, February 11, 2010 4:42:51 PM Subject: Re: [erlang-questions] getting the path of an http request as binary >> Is it possible to get the Path as binary without having to convert it? >Socket option {packet, http_bin} In mochiweb_socket_server/init the BaseOpts have {packet, 0} Which according to the inet docs means that "no packaging is done". What will replacing {packet, 0} with {packet, http_bin}do? I probably can't expect it to just work. ________________________________ From: Sverker Eriksson To: Pablo Platt Cc: erlang-questions@REDACTED Sent: Thu, February 11, 2010 4:24:07 PM Subject: Re: [erlang-questions] getting the path of an http request as binary Pablo Platt wrote: > Hi > > mochiweb uses: > gen_tcp:recv(Socket, 0, ?REQUEST_RECV_TIMEOUT) > which result with: > {ok, {http_request, Method, Path, Version}} > where the Path is a list. > > Is it possible to get the Path as binary without having to convert it? > > Socket option {packet, http_bin} > Are there docs about http_binary packet parser in R13B03? > > inet:setopts/2 erlang:decode_packet/3 /Sverker, Erlang/OTP Ericsson ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED From james.hague@REDACTED Thu Feb 11 16:51:06 2010 From: james.hague@REDACTED (James Hague) Date: Thu, 11 Feb 2010 09:51:06 -0600 Subject: [erlang-questions] Values of os:type() on 32/64-bit Windows In-Reply-To: <7SKlL2y8.1265902897.3191490.leap@gol.com> References: <7SKlL2y8.1265902897.3191490.leap@gol.com> Message-ID: > I get {win32,nt}. I get the same result with 64-bit Vista. From enriquecano@REDACTED Thu Feb 11 17:00:18 2010 From: enriquecano@REDACTED (Enrique Cano) Date: Thu, 11 Feb 2010 17:00:18 +0100 Subject: [erlang-questions] Values of os:type() on 32/64-bit Windows In-Reply-To: References: <7SKlL2y8.1265902897.3191490.leap@gol.com> Message-ID: <003601caab33$4fd82e90$ef888bb0$@com> Also the same result ({win32,nt}) with Windows 2008 64bits. >-----Mensaje original----- >De: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] En >nombre de James Hague >Enviado el: jueves, 11 de febrero de 2010 16:51 >Para: erlang-questions@REDACTED >Asunto: Re: [erlang-questions] Values of os:type() on 32/64-bit Windows > >> I get {win32,nt}. > >I get the same result with 64-bit Vista. > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > >__________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base de >firmas de virus 4858 (20100211) __________ > >ESET NOD32 Antivirus ha comprobado este mensaje. > >http://www.eset.com > __________ Informaci?n de ESET NOD32 Antivirus, versi?n de la base de firmas de virus 4858 (20100211) __________ ESET NOD32 Antivirus ha comprobado este mensaje. http://www.eset.com From smith.winston.101@REDACTED Thu Feb 11 17:08:18 2010 From: smith.winston.101@REDACTED (Winston Smith) Date: Thu, 11 Feb 2010 11:08:18 -0500 Subject: [erlang-questions] Values of os:type() on 32/64-bit Windows In-Reply-To: References: <7SKlL2y8.1265902897.3191490.leap@gol.com> Message-ID: On Thu, Feb 11, 2010 at 10:51 AM, James Hague wrote: >> I get {win32,nt}. > > I get the same result with 64-bit Vista. Hmmm ... researching this there seem to be some environment variables that may be set (at least I think in the cmd prompt), for example: os:getenv("PROCESSOR_ARCHITECTURE"). And: os:getenv("PROCESSOR_IDENTIFIER"). Hopefully these will be set for Erlang. Thanks for the feedback! From rvirding@REDACTED Thu Feb 11 17:09:42 2010 From: rvirding@REDACTED (Robert Virding) Date: Thu, 11 Feb 2010 17:09:42 +0100 Subject: [erlang-questions] Two confusions?? In-Reply-To: References: Message-ID: <3dbc6d1c1002110809m2e7ef6f0qd0d5ef532560839d@mail.gmail.com> On 10 February 2010 18:08, Ish Rattan wrote: > > ... > 2. A C-client sends 4-byte int request (with numeric > ? value N encoded in the 4-bytes), erlang server > ? receives the request (in binary) and prints as: > ? <<0, 0, 0, N>> > > what is the interpretation here? The 4 bytes in the binary are the 4 byte int request sent by the client. Socket data is received as a binary containing the bytes sent over the socket (or alternatively as a list of bytes). It is up to the receiver to interpret those bytes, for example as ASCII characters or UTF-8 encoded Unicode characters or ... . In this case the 4 bytes are a big endian integer. A simple way to extract them is to match against the input binary with the pattern <> which does this. Is this what you meant? Robert From ulf.wiger@REDACTED Thu Feb 11 17:51:58 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 11 Feb 2010 17:51:58 +0100 Subject: [erlang-questions] new gproc, new feature + move to github In-Reply-To: <389337.77182.qm@web112619.mail.gq1.yahoo.com> References: <4B73E00A.3090901@erlang-solutions.com> <389337.77182.qm@web112619.mail.gq1.yahoo.com> Message-ID: <4B7435AE.5030303@erlang-solutions.com> Pablo Platt wrote: > Thank you for moving it to github and adding features. > > What is the difference between gproc:await and registering a unique name > with add_local_name ? gproc:await/2 should be compared to gproc:where/1 (or the simpler lookup_local_name/1). The lookup functions will return immediately telling the caller whether the name is currently registered. The await/2 function will block until the name is registered, and then tell the caller which process registered it. BR, Ulf W > > > ------------------------------------------------------------------------ > *From:* Ulf Wiger > *To:* erlang-questions@REDACTED > *Sent:* Thu, February 11, 2010 12:46:34 PM > *Subject:* [erlang-questions] new gproc, new feature + move to github > > > Given the recent discussion about gproc, and my background task > of migrating my projects to github, I have committed a new version > of gproc: > > http://svn.ulf.wiger.net/gproc/branches/0912/gproc > > http://github.com/uwiger/gproc > > From now on, unless people object, I will update the git version. > > > The new feature in this gproc version is > > gproc:await(Key, Timeout) -> {Pid, Value} | error(timeout) > > Currently only for local names, the function waits for a name to be > registered and then returns the pid of the registered process. > Given that gproc allows processes to register multiple names, this can > serve as a simple resource broker. > > There is also a non-blocking version, gproc:nb_wait(Key) -> Ref. > Gproc will send a message, {gproc, Ref, registered, {Key, Pid, Value}} > once the name appears. > > The feature doesn't add any execution overhead to name registration, > except when there are processes waiting for the name, in which case > there will obviously be a cost for notifying them. > > BR, > Ulf W > -- Ulf Wiger > CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd > http://www.erlang-solutions.com > --------------------------------------------------- > > --------------------------------------------------- > > WE'VE CHANGED NAMES! > > Since January 1st 2010 Erlang Training and Consulting Ltd. has become > ERLANG SOLUTIONS LTD. > > www.erlang-solutions.com > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com From ishwar@REDACTED Thu Feb 11 18:20:57 2010 From: ishwar@REDACTED (Ish Rattan) Date: Thu, 11 Feb 2010 12:20:57 -0500 (EST) Subject: [erlang-questions] Two confusions?? In-Reply-To: <3dbc6d1c1002110809m2e7ef6f0qd0d5ef532560839d@mail.gmail.com> References: <3dbc6d1c1002110809m2e7ef6f0qd0d5ef532560839d@mail.gmail.com> Message-ID: On Thu, 11 Feb 2010, Robert Virding wrote: > On 10 February 2010 18:08, Ish Rattan wrote: >> >> ... >> 2. A C-client sends 4-byte int request (with numeric >> ? value N encoded in the 4-bytes), erlang server >> ? receives the request (in binary) and prints as: >> ? <<0, 0, 0, N>> >> >> what is the interpretation here? > > The 4 bytes in the binary are the 4 byte int request sent by the > client. Socket data is received as a binary containing the bytes sent > over the socket (or alternatively as a list of bytes). It is up to the > receiver to interpret those bytes, for example as ASCII characters or > UTF-8 encoded Unicode characters or ... . In this case the 4 bytes are > a big endian integer. A simple way to extract them is to match against > the input binary with the pattern <> which does this. > > Is this what you meant? Thanks for the answer: now the server (computes factorial of N) and wants to send the reply how will the be marshalled for client (expects a 4-byte answer when overflow is not an issue). For me, picture is clean when both server and client are in Erlang because of agreement on {packe, 1|2|4} part, but becomes fuzzy when one of them is in Erlang. -ishwar From yogishb@REDACTED Thu Feb 11 19:53:40 2010 From: yogishb@REDACTED (Yogish Baliga) Date: Thu, 11 Feb 2010 10:53:40 -0800 (PST) Subject: Logging remote shell connect Message-ID: <255239.32173.qm@web112614.mail.gq1.yahoo.com> Hello all, Is it possible to get some kind of notification when someone connects to a shell via remote-shell capability? -- baliga "Point of view is worth 80 IQ points" --Alan Kay http://dudefrommangalore.blogspot.com/ From stondage123@REDACTED Thu Feb 11 21:05:50 2010 From: stondage123@REDACTED (Andrew Stone) Date: Thu, 11 Feb 2010 12:05:50 -0800 (PST) Subject: [erlang-questions] Logging remote shell connect In-Reply-To: <255239.32173.qm@web112614.mail.gq1.yahoo.com> References: <255239.32173.qm@web112614.mail.gq1.yahoo.com> Message-ID: <455204.56395.qm@web35902.mail.mud.yahoo.com> Yes. You can use net_kernel:monitor_nodes(true). The process that makes the call will receive messages of the form {nodeup,Node} when a remote shell attaches (or any other node connection for that matter). See this for details: http://erlang.org/doc/man/net_kernel.html#monitor_nodes-1 -Andrew ----- Original Message ---- From: Yogish Baliga To: Erlang Questions Sent: Thu, February 11, 2010 1:53:40 PM Subject: [erlang-questions] Logging remote shell connect Hello all, Is it possible to get some kind of notification when someone connects to a shell via remote-shell capability? -- baliga "Point of view is worth 80 IQ points" --Alan Kay http://dudefrommangalore.blogspot.com/ From pablo.platt@REDACTED Thu Feb 11 23:46:58 2010 From: pablo.platt@REDACTED (Pablo Platt) Date: Thu, 11 Feb 2010 14:46:58 -0800 (PST) Subject: [erlang-questions] new gproc, new feature + move to github In-Reply-To: <4B7435AE.5030303@erlang-solutions.com> References: <4B73E00A.3090901@erlang-solutions.com> <389337.77182.qm@web112619.mail.gq1.yahoo.com> <4B7435AE.5030303@erlang-solutions.com> Message-ID: <285729.29015.qm@web112616.mail.gq1.yahoo.com> got it. thanks ________________________________ From: Ulf Wiger To: Pablo Platt Cc: erlang-questions@REDACTED Sent: Thu, February 11, 2010 6:51:58 PM Subject: Re: [erlang-questions] new gproc, new feature + move to github Pablo Platt wrote: > Thank you for moving it to github and adding features. > > What is the difference between gproc:await and registering a unique name with add_local_name ? gproc:await/2 should be compared to gproc:where/1 (or the simpler lookup_local_name/1). The lookup functions will return immediately telling the caller whether the name is currently registered. The await/2 function will block until the name is registered, and then tell the caller which process registered it. BR, Ulf W > > > ------------------------------------------------------------------------ > *From:* Ulf Wiger > *To:* erlang-questions@REDACTED > *Sent:* Thu, February 11, 2010 12:46:34 PM > *Subject:* [erlang-questions] new gproc, new feature + move to github > > > Given the recent discussion about gproc, and my background task > of migrating my projects to github, I have committed a new version > of gproc: > > http://svn.ulf.wiger.net/gproc/branches/0912/gproc > > http://github.com/uwiger/gproc > > From now on, unless people object, I will update the git version. > > > The new feature in this gproc version is > > gproc:await(Key, Timeout) -> {Pid, Value} | error(timeout) > > Currently only for local names, the function waits for a name to be > registered and then returns the pid of the registered process. > Given that gproc allows processes to register multiple names, this can > serve as a simple resource broker. > > There is also a non-blocking version, gproc:nb_wait(Key) -> Ref. > Gproc will send a message, {gproc, Ref, registered, {Key, Pid, Value}} > once the name appears. > > The feature doesn't add any execution overhead to name registration, > except when there are processes waiting for the name, in which case > there will obviously be a cost for notifying them. > > BR, > Ulf W > -- Ulf Wiger > CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd > http://www.erlang-solutions.com > --------------------------------------------------- > > --------------------------------------------------- > > WE'VE CHANGED NAMES! > > Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. > > www.erlang-solutions.com > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com From ok@REDACTED Fri Feb 12 01:59:50 2010 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 12 Feb 2010 13:59:50 +1300 Subject: [erlang-questions] An appeal. Fwd: Simon Singh's weird idea that might just work In-Reply-To: <2a67d3ff1002110227x27128e42kc6e37e6027a8a82e@mail.gmail.com> References: <3dbc6d1c1002110151w6e8872d0mc31920e8847be40d@mail.gmail.com> <9b08084c1002110216u37fcfca2ub77eb0b0f89c3961@mail.gmail.com> <2a67d3ff1002110227x27128e42kc6e37e6027a8a82e@mail.gmail.com> Message-ID: <2FCB55A3-5025-4CDE-BAD6-72E93079CCA0@cs.otago.ac.nz> On Feb 11, 2010, at 11:27 PM, G.S. wrote: > So it seems we're going back to the dark ages then. I bet they just > can't > wait to burn us Scientists... or as they used to call us: heretics. No, it's not about burning or heretics; it has nothing to do with beliefs. It's about money and power; about not posing a threat to the rich. The report (http://libelreform.org/our-report) puts it plainly: "English libel law is more about making money than saving a reputation". I've signed up. From OK@REDACTED Fri Feb 12 05:34:52 2010 From: OK@REDACTED (Richard O'Keefe) Date: Fri, 12 Feb 2010 17:34:52 +1300 Subject: A style question Message-ID: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> I've been looking at some Erlang code that's full of stuff like F = fun() -> ... mnesia:transaction(F) My preferred style for this would be mnesia:transaction(fun () -> .... end) which I think a Smalltalk or Ruby programmer would also prefer. But is this just prejudice on my part, or is there a reason why inserting an opaque name like "F" is a good idea? From ttmrichter@REDACTED Fri Feb 12 05:39:27 2010 From: ttmrichter@REDACTED (Michael Richter) Date: Fri, 12 Feb 2010 12:39:27 +0800 Subject: [erlang-questions] A style question In-Reply-To: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> Message-ID: Only thing I can think of is that if the same fun is used in more than one place in the function (or has potential to be) it's better to have the label. Aside from that I've got nothing. On 12 February 2010 12:34, Richard O'Keefe wrote: > I've been looking at some Erlang code that's full of stuff like > > F = fun() -> ... > mnesia:transaction(F) > > My preferred style for this would be > > mnesia:transaction(fun () -> > .... > end) > > which I think a Smalltalk or Ruby programmer would also prefer. > But is this just prejudice on my part, or is there a reason why > inserting an opaque name like "F" is a good idea? > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From dale@REDACTED Fri Feb 12 05:46:56 2010 From: dale@REDACTED (Dale Harvey) Date: Fri, 12 Feb 2010 04:46:56 +0000 Subject: [erlang-questions] A style question In-Reply-To: References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> Message-ID: by default the emacs erlang mode will indent the anon function from the end of the fun() -> line mnesia:transaction(fun() -> ... some code here ... end), this takes up 27 of your 80 characters, whereas F = fun() -> is only 12, thats the main reason I stopped doing it. On 12 February 2010 04:39, Michael Richter wrote: > Only thing I can think of is that if the same fun is used in more than one > place in the function (or has potential to be) it's better to have the > label. Aside from that I've got nothing. > > On 12 February 2010 12:34, Richard O'Keefe wrote: > > > I've been looking at some Erlang code that's full of stuff like > > > > F = fun() -> ... > > mnesia:transaction(F) > > > > My preferred style for this would be > > > > mnesia:transaction(fun () -> > > .... > > end) > > > > which I think a Smalltalk or Ruby programmer would also prefer. > > But is this just prejudice on my part, or is there a reason why > > inserting an opaque name like "F" is a good idea? > > > > > > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > See http://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > > > From OK@REDACTED Fri Feb 12 05:51:46 2010 From: OK@REDACTED (Richard O'Keefe) Date: Fri, 12 Feb 2010 17:51:46 +1300 Subject: [erlang-questions] A style question In-Reply-To: References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> Message-ID: <9B0110AA-713C-4EFA-96EA-9869DADA2938@cs.otago.ac.nz> On Feb 12, 2010, at 5:39 PM, Michael Richter wrote: > Only thing I can think of is that if the same fun is used in more > than one place in the function (or has potential to be) it's better > to have the label. Aside from that I've got nothing. No, that doesn't apply. In each case, the function name F is used once and only once. In that case, I think that instead of doing F = fun () -> ... end, mnesia:transaction(F), ... mnesia:transaction(F) it would be better to do Transaction = mnesia_transaction(fun () -> ... end, Transaction(), ... Transaction() so that there's no possibility of calling F _without_ the transaction safely wrapped around it. The code is supposed to come from an expert, who clearly knows amongst other things a whole lot more about MochiWeb than I do. I just wondered what I wasn't seeing. From OK@REDACTED Fri Feb 12 05:57:38 2010 From: OK@REDACTED (Richard O'Keefe) Date: Fri, 12 Feb 2010 17:57:38 +1300 Subject: [erlang-questions] A style question In-Reply-To: References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> Message-ID: <378EAA84-FB83-4E42-B547-A29A07C78D1B@cs.otago.ac.nz> On Feb 12, 2010, at 5:46 PM, Dale Harvey wrote: > by default the emacs erlang mode will indent the anon function from > the end of the fun() -> line > > mnesia:transaction(fun() -> > ... some code here ... > end), > > this takes up 27 of your 80 characters, whereas F = fun() -> is only > 12, thats the main reason I stopped doing it. That sounds like an excellent reason not to use Emacs. I have always found Emacs' indentation to be horrible, for every language I've tried. Emacs with automatic indentation turned off is a better-than-decent editor. The indentation style I would use here just takes 4 columns, not 12. From ulf.wiger@REDACTED Fri Feb 12 07:05:52 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 12 Feb 2010 07:05:52 +0100 Subject: SV: [erlang-questions] A style question Message-ID: There is an alternative that actually has a distinct advantage: mnesia:activity( transaction, fun my_transaction_fun/0) The advantage is that when tracing, you get much more readable output. A disadvantage is that you forego the pleasure of inheriting the environment. Note also the use of mnesia:activity/2 rather than transaction/1. It has much better semantics, and is more flexible. BR, Ulf W Ulf Wiger CTO, Erlang Solutions, Ltd. -- originalmedd. -- ?mne: [erlang-questions] A style question Fr?n: "Richard O'Keefe" Datum: 2010.02.12 05.37 I've been looking at some Erlang code that's full of stuff like F = fun() -> ... mnesia:transaction(F) My preferred style for this would be mnesia:transaction(fun () -> .... end) which I think a Smalltalk or Ruby programmer would also prefer. But is this just prejudice on my part, or is there a reason why inserting an opaque name like "F" is a good idea? ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From kaykay.unique@REDACTED Fri Feb 12 09:18:41 2010 From: kaykay.unique@REDACTED (Kay Kay) Date: Fri, 12 Feb 2010 00:18:41 -0800 Subject: reverse engineering beam files / obfuscation ? Message-ID: <4B750EE1.7010302@gmail.com> If I were to release a commercial erlang based app , with compiled beam files, would it be possible to reverse engineer it . If that were the case - any possible suggestions to prevent / obfuscate the same. -- K K. From bflatmaj7th@REDACTED Fri Feb 12 10:18:41 2010 From: bflatmaj7th@REDACTED (Richard Andrews) Date: Fri, 12 Feb 2010 20:18:41 +1100 Subject: [erlang-questions] A style question In-Reply-To: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> Message-ID: <7702c0611002120118m3b135a52gab74a9218732547c@mail.gmail.com> On Fri, Feb 12, 2010 at 3:34 PM, Richard O'Keefe wrote: > I've been looking at some Erlang code that's full of stuff like > > ? ? ? ?F = fun() -> ... > ? ? ? ?mnesia:transaction(F) > > My preferred style for this would be > > ? ? ? ?mnesia:transaction(fun () -> > ? ? ? ? ? ?.... > ? ? ? ?end) > > which I think a Smalltalk or Ruby programmer would also prefer. > But is this just prejudice on my part, or is there a reason why > inserting an opaque name like "F" is a good idea? Ignoring the mnesia-specific part... Clarity. One of my mantras of coding is: "if it's not obviously right then it's probably wrong". I find the former preferable when fun() is large or bulky. Inline fun can make it unclear what the code is supposed to do. The other reason I use the former is to give the fun a useful name which (again) makes the code operation/goals clearer (ie. code==documentation). From enewhuis@REDACTED Fri Feb 12 14:00:23 2010 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 12 Feb 2010 07:00:23 -0600 Subject: [erlang-questions] A style question In-Reply-To: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> Message-ID: <828298AC-FD89-4606-9FCF-1CB3131D7DA0@gmail.com> Martin Fowler would probably say that F is a temporary variable and, as such, is unwanted because it slows down refactoring. I tend to agree with him. This is especially true in Erlang when attempting to quickly merge code segments that secretly share a common temporary name but for different purposes. Hilarity ensues as one reaches for search/replace. On the other hand if there were more powerful visual debugging features then I wouldn't consistently break this sage advice by leaving temporary variables around from commented-out print statements. On Feb 11, 2010, at 10:34 PM, Richard O'Keefe wrote: > I've been looking at some Erlang code that's full of stuff like > > F = fun() -> ... > mnesia:transaction(F) > > My preferred style for this would be > > mnesia:transaction(fun () -> > .... > end) > > which I think a Smalltalk or Ruby programmer would also prefer. > But is this just prejudice on my part, or is there a reason why > inserting an opaque name like "F" is a good idea? > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From mononcqc@REDACTED Fri Feb 12 14:24:35 2010 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 12 Feb 2010 08:24:35 -0500 Subject: [erlang-questions] A style question In-Reply-To: References: Message-ID: <8b9ee55b1002120524x53fc2302n269ceea7e8ee8af1@mail.gmail.com> Wouldn't using mnesia:activity/2 otherwise mean you've got to wrap every transaction in a try ... catch yourself though? Is that considered an annoyance or a wanted behaviour (outside of any gen_*)? On Fri, Feb 12, 2010 at 1:05 AM, Ulf Wiger wrote: > There is an alternative that actually has a distinct advantage: > > mnesia:activity( > transaction, > fun my_transaction_fun/0) > > The advantage is that when tracing, you get much more readable output. A > disadvantage is that you forego the pleasure of inheriting the environment. > > Note also the use of mnesia:activity/2 rather than transaction/1. It has > much better semantics, and is more flexible. > > BR, > Ulf W > > Ulf Wiger > CTO, Erlang Solutions, Ltd. > > --------------------------------------------------- > > WE'VE CHANGED NAMES! > > Since January 1st 2010 Erlang Training and Consulting Ltd. has become > ERLANG SOLUTIONS LTD. > > www.erlang-solutions.com > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From enewhuis@REDACTED Fri Feb 12 14:29:53 2010 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 12 Feb 2010 07:29:53 -0600 Subject: Erlang Idioms - A Pattern for an Erlang Programming Team Message-ID: So one of the first new applications we created in our new Erlang ecosystem was a thing called idioms. This is where the team puts all the common time-saving programming idioms they find. It is a combination of useful small functions that should some day find themselves a part of some open standard, a set of the typical macros (LET, IF, etc.), and some common imports (lists, string, etc.). It works out well. Developers list idioms in their applications' .app file and include idioms.hrl in their modules. Easy. And some parts of the code tends to look similar regardless of who is doing the coding. Its really all about communication. I wonder if others have done something similar and would care to share or are already aware of something like this or have suggestions on how such sharing could be enabled. From attila.r.nohl@REDACTED Fri Feb 12 15:55:45 2010 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Fri, 12 Feb 2010 15:55:45 +0100 Subject: [erlang-questions] Erlang Idioms - A Pattern for an Erlang Programming Team In-Reply-To: References: Message-ID: <401d3ba31002120655g140e51e8ra5f6f316ee0f4fb5@mail.gmail.com> 2010/2/12, Eric Newhuis : [...] > It is a combination of useful small functions that should some day find > themselves a part of some open standard, a set of the typical macros (LET, > IF, etc.), and some common imports (lists, string, etc.). I bet you have something like lists:flatten(io_lib:format(Format, Parameters)) somewhere in that library :-) [...] > I wonder if others have done something similar and would care to share or > are already aware of something like this or have suggestions on how such > sharing could be enabled. I think it would be useful if there were some "extended distribution" to OTP that would contain libraries like the one you've created. The big problem would be that most major Erlang projects already have some libraries on their own and of course they wouldn't pick this new "extended distribution" up. From dmercer@REDACTED Fri Feb 12 16:02:34 2010 From: dmercer@REDACTED (David Mercer) Date: Fri, 12 Feb 2010 09:02:34 -0600 Subject: [erlang-questions] A style question In-Reply-To: <378EAA84-FB83-4E42-B547-A29A07C78D1B@cs.otago.ac.nz> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <378EAA84-FB83-4E42-B547-A29A07C78D1B@cs.otago.ac.nz> Message-ID: <2DAC64391C8841E49F96643C47DBBD07@SSI.CORP> > But is this just prejudice on my part, or is there a reason why inserting > an opaque name like "F" is a good idea? I might assign a value to a variable for documentation purposes. In this specific example, though, the name "F" seems to fail as a description of purpose, so it probably doesn't fall into that category. Suppose, however, that it were something like UpdateTheFebblebrokker = fun() -> ... Mnesia:transaction(UpdateTheFeeblebrokker) Then it might server as a form documentation, written with the optimistic assumption that the compiler will optimize the assignment away. > The indentation style I would use here just takes 4 columns, not 12. I would love to hear about different indentation styles, and specifically yours. I find properly indenting Erlang to be the most difficult part of the language. Cheers, David From bgustavsson@REDACTED Fri Feb 12 16:11:29 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 12 Feb 2010 16:11:29 +0100 Subject: [erlang-questions] A style question In-Reply-To: <2DAC64391C8841E49F96643C47DBBD07@SSI.CORP> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <378EAA84-FB83-4E42-B547-A29A07C78D1B@cs.otago.ac.nz> <2DAC64391C8841E49F96643C47DBBD07@SSI.CORP> Message-ID: <6672d0161002120711u3f7d6b54mbb67d0aacd9b1dab@mail.gmail.com> On Fri, Feb 12, 2010 at 4:02 PM, David Mercer wrote: > ? ? ? ?UpdateTheFebblebrokker = fun() -> ... > ? ? ? ?Mnesia:transaction(UpdateTheFeeblebrokker) > > Then it might server as a form documentation, written with the optimistic > assumption that the compiler will optimize the assignment away. It will. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From toby@REDACTED Fri Feb 12 16:37:18 2010 From: toby@REDACTED (Toby Thain) Date: Fri, 12 Feb 2010 10:37:18 -0500 Subject: [erlang-questions] Re: Singh-ing the English Libel Law Blues In-Reply-To: <3i3Tk1Ts.1265902524.0050490.leap@gol.com> References: <3i3Tk1Ts.1265902524.0050490.leap@gol.com> Message-ID: <2B093712-801C-460A-A470-D6E36F5DDF1A@telegraphics.com.au> On 11-Feb-10, at 10:35 AM, Michael Turner wrote: > > Not to defend Simon Singh's intellectual assailants (who, to be sure, > disgust me no end), but it appears the *legal* crux of the matter > is not > in Singh in claiming that chiropractic lacked "scientific validation". > Rather, it's in whether Singh was attributing *deceitful motives* to > chiropractors when he wrote that chiropractors "happily" (his word) > pursue and promote treatments he called "bogus". No, really. > ... > On the other hand, I come more from hacker culture, where "bogus" can > even mean simply "doesn't work very well" -- and in which author of > the bogus software might actually believe that his "bugs" are > "features". I'm not tuned into any particular British nuances for > "bogus", The word isn't British. My etymology has it originating in Ohio in early 19th C. In my experience it's barely known to British English speakers, and where recognised, seen as an Americanism. --Toby > perhaps owing to the transatlantic quantum uncertainty of > bogons. > ... > -michael turner > > P.S. A signed copy will go to 10,000 volunteer proofreaders if > they can > find even one typo in my forthcoming book, "The _ Programming > Language". > > > On 2/11/2010, "Joe Armstrong" wrote: > >> You're forgiven - the defense of freedom of speech is more important >> than programming anyway. >> >> I've signed up. For those of you who haven't followed Singh's >> dilemma. >> Singh was sued for >> libel for daring to say that certain alternative medicine practices >> had no scientific validation of their >> claims - Indeed were I to repeat his claims here - I might be sued. >> >> So it seems like that with the support of the English courts nobody >> anywhere in the world >> can say that "this is unscientific" without being in danger of being >> sued for libel. >> >> Since I often say "this is unscientific" this is kind of disturbing. >> >> /Joe >> >> On Thu, Feb 11, 2010 at 10:51 AM, Robert Virding >> wrote: >>> Sorry for posting something completely out of context on this >>> mailing-list but it is something which I feel is important enough to >>> warrant that. Posting it here is my idea so complaints goto me. >>> >>> Please support it. >>> >>> Robert >>> >>> >>> ---------- Forwarded message ---------- >>> From: ? >>> Date: 10 February 2010 22:32 >>> Subject: Simon Singh's weird idea that might just work >>> To: rvirding@REDACTED >>> >>> Dear Friends, >>> >>> I?e had an idea ?an unusual idea, but I think it >>> might just >>> work. >>> >>> As you know, England? chilling libel laws need to be >>> reformed. One >>> way to help achieve this is for 100,000 people to sign the petition >>> for libel reform before the political parties write their manifestos >>> for the election. We have 17,000 signatures, but we really need >>> 100,000, and we need your help to get there. >>> >>> ?http://libelreform.indiemedium.com/lt.php? >>> id=ZkQFVwkEBlAYDEgEBgALUg%3D%3D >>> >>> My idea >>> >>> My idea is simple: if everyone who has already signed up persuades >>> just one more person each week to sign the petition then we will >>> reach >>> our goal within a month! ... From ulf.wiger@REDACTED Fri Feb 12 18:35:48 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 12 Feb 2010 18:35:48 +0100 Subject: [erlang-questions] A style question In-Reply-To: <8b9ee55b1002120524x53fc2302n269ceea7e8ee8af1@mail.gmail.com> References: <8b9ee55b1002120524x53fc2302n269ceea7e8ee8af1@mail.gmail.com> Message-ID: <4B759174.5030705@erlang-solutions.com> Fred Hebert wrote: > Wouldn't using mnesia:activity/2 otherwise mean you've got to wrap every > transaction in a try ... catch yourself though? Is that considered an > annoyance or a wanted behaviour (outside of any gen_*)? Whether it is an annoyance or not depends on what you consider the sensible default. In my experience, most programs that run mnesia transactions have no clever recourse if the transaction aborts, so an exception would then be a good default. It is not difficult to make that wrapper in one place: transaction(F) -> transaction(transaction, F). transaction(Type, F) -> try {atomic, mnesia:activity(Type, F)} catch exit:Reason -> {aborted, Reason} end. Why would this be better than using mnesia:transaction/1, you might ask. There is an important difference between the two. mnesia:transaction/1 will always use mnesia.erl as a callback module, ignoring any setting of the 'access_module' environment variable. mnesia:activity/2, on the other hand, will check this and use any custom callback module you may have selected as system default. One such access module is mnesia_frag. Using mnesia:activity/2, you could potentially fragment your table at a later time, having it be transparent to the program. BR, Ulf W > On Fri, Feb 12, 2010 at 1:05 AM, Ulf Wiger > > > wrote: > > There is an alternative that actually has a distinct advantage: > > mnesia:activity( > transaction, > fun my_transaction_fun/0) > > The advantage is that when tracing, you get much more readable > output. A disadvantage is that you forego the pleasure of inheriting > the environment. > > Note also the use of mnesia:activity/2 rather than transaction/1. It > has much better semantics, and is more flexible. > > BR, > Ulf W > > Ulf Wiger > CTO, Erlang Solutions, Ltd. > > --------------------------------------------------- > > WE'VE CHANGED NAMES! > > Since January 1st 2010 Erlang Training and Consulting Ltd. has > become ERLANG SOLUTIONS LTD. > > www.erlang-solutions.com > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From chandrashekhar.mullaparthi@REDACTED Fri Feb 12 20:44:02 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Fri, 12 Feb 2010 19:44:02 +0000 Subject: [erlang-questions] reverse engineering beam files / obfuscation ? In-Reply-To: <4B750EE1.7010302@gmail.com> References: <4B750EE1.7010302@gmail.com> Message-ID: On 12 February 2010 08:18, Kay Kay wrote: > If I were to release a commercial erlang based app , with compiled beam > files, would it be possible to reverse engineer it . If that were the case - > any possible suggestions to prevent / obfuscate the same. Depends on how you produce your beam files. See options related to 'debug_info' in http://www.erlang.org/doc/man/compile.html cheers Chandru From ishwar@REDACTED Fri Feb 12 21:03:02 2010 From: ishwar@REDACTED (Ish Rattan) Date: Fri, 12 Feb 2010 15:03:02 -0500 (EST) Subject: One more question? Message-ID: Erlang server gets message from non-Erlang client as: <<0,0,0,10,72,101,108,108,111,46,46>> (numeric 10 in 4-bytes followed by "hello..") how to extract the pieces? -ishwar From erlangy@REDACTED Fri Feb 12 21:32:06 2010 From: erlangy@REDACTED (Michael) Date: Fri, 12 Feb 2010 12:32:06 -0800 Subject: [erlang-questions] One more question? In-Reply-To: References: Message-ID: <20100212203206.GA5805@delora.autosys.us> On Fri, Feb 12, 2010 at 03:03:02PM -0500, Ish Rattan wrote: > > Erlang server gets message from non-Erlang client as: > <<0,0,0,10,72,101,108,108,111,46,46>> > (numeric 10 in 4-bytes followed by "hello..") > > how to extract the pieces? > > -ishwar ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Also see Programming Examples in docs. This should work if you can be assured that the first 4 bytes are always before the message. 1> <> = <<0,0,0,10,72,101,108,108,111,46,46>>. 2> Msg. <<"Hello..">> 3> -- Michael McDaniel Portland, Oregon, USA http://trip.autosys.us http://putitgetit.com From erlangy@REDACTED Fri Feb 12 21:38:21 2010 From: erlangy@REDACTED (Michael) Date: Fri, 12 Feb 2010 12:38:21 -0800 Subject: [erlang-questions] One more question? In-Reply-To: <20100212203206.GA5805@delora.autosys.us> References: <20100212203206.GA5805@delora.autosys.us> Message-ID: <20100212203821.GB5805@delora.autosys.us> On Fri, Feb 12, 2010 at 12:32:06PM -0800, Michael wrote: > On Fri, Feb 12, 2010 at 03:03:02PM -0500, Ish Rattan wrote: > > > > Erlang server gets message from non-Erlang client as: > > <<0,0,0,10,72,101,108,108,111,46,46>> > > (numeric 10 in 4-bytes followed by "hello..") > > > > how to extract the pieces? > > > > -ishwar > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Also see Programming Examples in docs. > > This should work if you can be assured that the first 4 bytes > are always before the message. > > 1> <> = <<0,0,0,10,72,101,108,108,111,46,46>>. > 2> Msg. > <<"Hello..">> > 3> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ or, another way to "slice the baloney" ... 3> [_,_,_,_ | Rest] = binary_to_list( <<0,0,0,10,72,101,108,108,111,46,46>> ). [0,0,0,10,72,101,108,108,111,46,46] 4> Rest. "Hello.." 5> ~Michael From rvirding@REDACTED Sat Feb 13 00:32:40 2010 From: rvirding@REDACTED (Robert Virding) Date: Sat, 13 Feb 2010 00:32:40 +0100 Subject: [erlang-questions] reverse engineering beam files / obfuscation ? In-Reply-To: <4B750EE1.7010302@gmail.com> References: <4B750EE1.7010302@gmail.com> Message-ID: <3dbc6d1c1002121532g249ce6f3t72aaae5a4714b84d@mail.gmail.com> Just as much as it is possible to reverse engineer any machine code. You need time, patience, and an exact knowledge of how the compiler works and how the machine is defined. A game developers conference a few years ago there was a presentation of how it could be done, even on how you could get past encrypted object files. No, this was not a "how to" lecture but more an example of the difficulties in trying to protect your game. Robert On 12 February 2010 09:18, Kay Kay wrote: > If I were to release a commercial erlang based app , with compiled beam > files, would it be possible to reverse engineer it . If that were the case - > any possible suggestions to prevent / obfuscate the same. > > -- > ?K K. > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From enewhuis@REDACTED Sat Feb 13 00:56:33 2010 From: enewhuis@REDACTED (Eric Newhuis) Date: Fri, 12 Feb 2010 17:56:33 -0600 Subject: [erlang-questions] Erlang Idioms - A Pattern for an Erlang Programming Team In-Reply-To: <401d3ba31002120655g140e51e8ra5f6f316ee0f4fb5@mail.gmail.com> References: <401d3ba31002120655g140e51e8ra5f6f316ee0f4fb5@mail.gmail.com> Message-ID: <20D90B86-3D59-4FE9-A61F-3BD2274D6303@gmail.com> Ah! Not yet but I do have the T-shirt. :) Maybe the idioms should tweet whenever a new one is hatched. On Feb 12, 2010, at 8:55 AM, Attila Rajmund Nohl wrote: > 2010/2/12, Eric Newhuis : > [...] >> It is a combination of useful small functions that should some day find >> themselves a part of some open standard, a set of the typical macros (LET, >> IF, etc.), and some common imports (lists, string, etc.). > > I bet you have something like lists:flatten(io_lib:format(Format, > Parameters)) somewhere in that library :-) > > [...] >> I wonder if others have done something similar and would care to share or >> are already aware of something like this or have suggestions on how such >> sharing could be enabled. > > I think it would be useful if there were some "extended distribution" > to OTP that would contain libraries like the one you've created. The > big problem would be that most major Erlang projects already have some > libraries on their own and of course they wouldn't pick this new > "extended distribution" up. > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From doug.fort@REDACTED Sat Feb 13 01:12:16 2010 From: doug.fort@REDACTED (Doug Fort) Date: Fri, 12 Feb 2010 19:12:16 -0500 Subject: [erlang-questions] Erlang Idioms - A Pattern for an Erlang Programming Team In-Reply-To: <20D90B86-3D59-4FE9-A61F-3BD2274D6303@gmail.com> References: <401d3ba31002120655g140e51e8ra5f6f316ee0f4fb5@mail.gmail.com> <20D90B86-3D59-4FE9-A61F-3BD2274D6303@gmail.com> Message-ID: <5db086ad1002121612l73c538e5x55861870522c0f5d@mail.gmail.com> Could be a book, or at least a conference presentation. James O. Coplien's books on C and C++ styles and idioms were very influential. On Fri, Feb 12, 2010 at 6:56 PM, Eric Newhuis wrote: > Ah! ?Not yet but I do have the T-shirt. ?:) > > Maybe the idioms should tweet whenever a new one is hatched. > > On Feb 12, 2010, at 8:55 AM, Attila Rajmund Nohl wrote: > >> 2010/2/12, Eric Newhuis : >> [...] >>> It is a combination of useful small functions that should some day find >>> themselves a part of some open standard, a set of the typical macros (LET, >>> IF, etc.), and some common imports (lists, string, etc.). >> >> I bet you have something like lists:flatten(io_lib:format(Format, >> Parameters)) somewhere in that library :-) >> >> [...] >>> I wonder if others have done something similar and would care to share or >>> are already aware of something like this or have suggestions on how such >>> sharing could be enabled. >> >> I think it would be useful if there were some "extended distribution" >> to OTP that would contain libraries like the one you've created. The >> big problem would be that most major Erlang projects already have some >> libraries on their own and of course they wouldn't pick this new >> "extended distribution" up. >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > -- Doug Fort, Consulting Programmer http://www.dougfort.com From steven.charles.davis@REDACTED Sat Feb 13 01:59:01 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 12 Feb 2010 16:59:01 -0800 (PST) Subject: Erlang Idioms - A Pattern for an Erlang Programming Team In-Reply-To: References: Message-ID: If I were to contribute one idiom, it would be that encoding all text as binaries improves your programs enormously. While it may appear troublesome to type <<"hello">> rather than "hello", the rewards in later manipulation is extreme. "Strings are just lists of integers" runs into irreconcilable problems when you consider that [0,1,2,3,4,5] could be a "string", should you decide to define a character encoding such that "s" = 0, "t" = 1, "i" = 2, etc. Matching on text presented as lists quickly leads to code bloat and headaches in the parts of your code that detect and manipulate text. I have found that when rigorously sticking to text encoded as binaries in my programs, it leads to far cleaner, shorter and more understandable functions. I would go as far as to say that the combination of: the re module + binary matching + binary text ...make Erlang far *superior* in text manipulation than any other language I have ever used (caveat: that's quite a few languages but by no means all). I have found this true even when coding for text-based protocols such as http. It has even led me to consider whether the reason why http became ubiquitous is because it removes the the ambiguity of the string concept in most (all?) languages, because in http everything is text and thus you don't have to figure out which values are text and which are not. Regards, /s On Feb 12, 7:29?am, Eric Newhuis wrote: > This is where the team puts all the common time-saving programming idioms they find. From steven.charles.davis@REDACTED Sat Feb 13 02:25:36 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 12 Feb 2010 17:25:36 -0800 (PST) Subject: reverse engineering beam files / obfuscation ? In-Reply-To: <4B750EE1.7010302@gmail.com> References: <4B750EE1.7010302@gmail.com> Message-ID: <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> Hi Kay, Just offering the thought that an effective obfuscation would be one where the effort required to decode it would be about equal to, or greater than, the effort required to write the code from scratch. Beam isn't easy if, as Chandru pointed out, you remove debug_info from the compile. Your code would be, I believe, considerably "safer" in Erlang than other bytecode-interpreted languages such as Java/C#. However, a long discussion about the value of open source could follow the above comments... but I digress. Regards, /s On Feb 12, 2:18?am, Kay Kay wrote: > If I were to release a commercial erlang based app , with compiled beam > files, would it be possible to reverse engineer it . If that were the > case - any possible suggestions to prevent / obfuscate the same. From leap@REDACTED Sat Feb 13 06:10:02 2010 From: leap@REDACTED (Michael Turner) Date: Sat, 13 Feb 2010 05:10:02 +0000 Subject: [erlang-questions] Re: reverse engineering beam files / obfuscation ? In-Reply-To: <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> Message-ID: But ... decompiling BEAM code just gives you Erlang source code, right? Which is read fluently by, what, only about 0.02% of software engineers? How much more obfuscation could you ask for? ;-) -michael turner On 2/13/2010, "Steve Davis" wrote: >Hi Kay, > >Just offering the thought that an effective obfuscation would be one >where the effort required to decode it would be about equal to, or >greater than, the effort required to write the code from scratch. > >Beam isn't easy if, as Chandru pointed out, you remove debug_info from >the compile. Your code would be, I believe, considerably "safer" in >Erlang than other bytecode-interpreted languages such as Java/C#. > >However, a long discussion about the value of open source could follow >the above comments... but I digress. > >Regards, >/s > >On Feb 12, 2:18?am, Kay Kay wrote: >> If I were to release a commercial erlang based app , with compiled beam >> files, would it be possible to reverse engineer it . If that were the >> case - any possible suggestions to prevent / obfuscate the same. > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From kagato@REDACTED Sat Feb 13 06:10:19 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Fri, 12 Feb 2010 21:10:19 -0800 Subject: [erlang-questions] One more question? In-Reply-To: References: Message-ID: <5F9647C8-0644-4BA4-B15D-D0FC9CF2F6F5@souja.net> If you receive it via a streaming port, you can also use {packet,4} as an option, which will automatically break the binaries into appropriate lengths. Also, one of the more unusual (but awesome) bits of binary pattern matching is something like this: > <> Interestingly, you can also do it like this, to match chunks in a large binary: > <> On Feb 12, 2010, at 12:03 PM, Ish Rattan wrote: > > Erlang server gets message from non-Erlang client as: > <<0,0,0,10,72,101,108,108,111,46,46>> > (numeric 10 in 4-bytes followed by "hello..") > > how to extract the pieces? > > -ishwar > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- Jayson Vantuyl kagato@REDACTED From kenji.rikitake@REDACTED Sat Feb 13 06:51:49 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sat, 13 Feb 2010 14:51:49 +0900 Subject: [erlang-questions] Re: Erlang Idioms - A Pattern for an Erlang Programming Team In-Reply-To: References: Message-ID: <20100213055149.GA18023@k2r.org> In the message dated Fri, Feb 12, 2010 at 04:58:37PM -0800, Steve Davis writes: > While it may appear troublesome to type <<"hello">> rather than > "hello", the rewards in later manipulation is extreme. This generally only works for ASCII strings, though I agree with the idea. Erlang's Unicode representation of strings introduces a complication in this matter. http://erlang.org/doc/man/unicode.html Note that my skills on UTF-8 is limited yet; I stay away from using non-ASCII characters in my own code (and let the others treated as they are as possible). Japanese have at least three more traditional coding systems than UTF-8 and I still don't know how I handle them properly without conversion. I live in EUC-JP on my FreeBSD systems, in Shift-JIS on the Microsoft systems (MS-DOS and Windows), and in ISO-2022-JP over the email. Conversion between UTF-8 and those codes are often poorly implemented. (e.g., GNU Emacs 22 and 23) Quite a few modern application handle all of these encodings, but that doesn't necessarily mean I can mix them up. I don't demand Erlang/OTP to deal with all iconv matters anyway; expanding ASCII+ISO-8859-1 into UTF-8/16/32 has already introduced a lot of problems to solve, though I appreciate the move because without that an I18N application for Erlang would not be practically possible. > I have found this true even when coding for text-based protocols such > as http. [...] Quite a few Internet protocols are based on text. See RFC5321 and RFC5322 for Internet message exchange format, including email. It's not just HTTP; HTTP is rather a late comer. Just my JPY 2 worth. Regards, Kenji Rikitake From als@REDACTED Sat Feb 13 06:44:58 2010 From: als@REDACTED (Anthony Shipman) Date: Sat, 13 Feb 2010 16:44:58 +1100 Subject: [erlang-questions] On Per-module process registration In-Reply-To: <408079F8-7BBC-48D4-BD2D-824E01478155@cs.otago.ac.nz> References: <201002102046.01066.als@iinet.net.au> <408079F8-7BBC-48D4-BD2D-824E01478155@cs.otago.ac.nz> Message-ID: <201002131644.59004.als@iinet.net.au> On Thu, 11 Feb 2010 12:29:43 pm Richard O'Keefe wrote: > The problem it was intended to solve was the problem of code > written according to the examples in Erlang books where a module > controls one process and registers a name for it so that the > module can communicate with that process, but far from any > desire for other processes or modules to find it, the possibillity > of other processes or modules sending messages to that process > creates a vulnerability. I find that these sorts of processes are in the minority, at least in the systems I work on. > > > The master wants to send a message to a > > slave. It can't use a pid since the slave might die and be restarted > > by its supervisor at any time. > > Why can't the master keep a dictionary of slaves, keyed by whatever > it wants, as part of its state? Since the master has to be informed > of the slaves' deaths anyway, it can update the dictionary at the > same time, no? That's what I have done so far. But it creates problems. The OTP system is strongly biased towards using supervisors. For example, you can't do OTP code updates on a process that is not reachable from the OTP supervisor. It's a lot of code to implement for what should be a common design pattern. > > The question is what merit you see in unrelated > processes being able to easily do > > exit(whereis('/'), kill). > > That's what my EEP is about. It's probably not a good idea most of the time. But on the other hand if I wanted to test crash recovery or be able to kill something that's gone into an infinite loop it might be useful. The interior of an Erlang system is assumed to be a fairly benign trustworthy environment. If I can replace the code of a module at run-time then that's a bigger security risk than sending stray messages or killing processes. I'm not convinced that it what it addresses is a big enough problem. > > One might as well go all the way and unify dynamic registries and > supervisors completely, and call them supervisors. > > There is one thing that a dynamic registry could do that a > supervisor cannot do, and that is to hold unrelated/uncontrolled > processes. > > It looks to me as though writing a dynamic registry module should > not be incredibly difficult, given a design; it's just another > plain old Erlang module. I have implemented my own kinds of registry. What I don't have is the ability to atomically spawn and register a process. Perhaps just adding the ability to spawn a process in a paused state and then unpause it later would solve that problem. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From als@REDACTED Sat Feb 13 07:03:08 2010 From: als@REDACTED (Anthony Shipman) Date: Sat, 13 Feb 2010 17:03:08 +1100 Subject: [erlang-questions] A style question In-Reply-To: <2DAC64391C8841E49F96643C47DBBD07@SSI.CORP> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <378EAA84-FB83-4E42-B547-A29A07C78D1B@cs.otago.ac.nz> <2DAC64391C8841E49F96643C47DBBD07@SSI.CORP> Message-ID: <201002131703.08643.als@iinet.net.au> On Sat, 13 Feb 2010 02:02:34 am David Mercer wrote: > > The indentation style I would use here just takes 4 columns, not 12. > > I would love to hear about different indentation styles, and specifically > yours. ?I find properly indenting Erlang to be the most difficult part of > the language. > > Cheers, > > David The way the emacs mode double indents case expressions is a nuisance. It leads to code sprawling all across the page. When you combine that with the ....................(........ ........ arrangement, reading code becomes a drunkard's walk across the page. It makes it harder to quickly scan the code looking for where this or that happens. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From kaykay.unique@REDACTED Sat Feb 13 09:43:41 2010 From: kaykay.unique@REDACTED (Kay Kay) Date: Sat, 13 Feb 2010 00:43:41 -0800 Subject: [erlang-questions] Re: reverse engineering beam files / obfuscation ? In-Reply-To: <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> References: <4B750EE1.7010302@gmail.com> <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> Message-ID: <4B76663D.4090009@gmail.com> Thanks everyone for replying to this thread. That comparison between the JVM bytecodes and erlang beam-s is definitely comforting. But I was just worried from an IP perspective entirely reverse engineered altogether. From a commercialization perspective , are there any licensing restrictions to be aware , if there were a commercial app on top of the Erlang system ? On 02/12/2010 05:25 PM, Steve Davis wrote: > Hi Kay, > > Just offering the thought that an effective obfuscation would be one > where the effort required to decode it would be about equal to, or > greater than, the effort required to write the code from scratch. > > Beam isn't easy if, as Chandru pointed out, you remove debug_info from > the compile. Your code would be, I believe, considerably "safer" in > Erlang than other bytecode-interpreted languages such as Java/C#. > > However, a long discussion about the value of open source could follow > the above comments... but I digress. > > Regards, > /s > > On Feb 12, 2:18 am, Kay Kay wrote: > >> If I were to release a commercial erlang based app , with compiled beam >> files, would it be possible to reverse engineer it . If that were the >> case - any possible suggestions to prevent / obfuscate the same. >> > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From steven.charles.davis@REDACTED Sat Feb 13 10:50:51 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 13 Feb 2010 01:50:51 -0800 (PST) Subject: Erlang Idioms - A Pattern for an Erlang Programming Team In-Reply-To: <20100213055149.GA18023@k2r.org> References: <20100213055149.GA18023@k2r.org> Message-ID: <423b201b-f303-4ce6-bdde-6cf6c01950a3@b7g2000yqd.googlegroups.com> Hi Kenji, Yes indeed! The choice of character encoding is a matter that goes beyond text manipulation. The idiom I use works when you already know what character encoding you are dealing with. As for dealing with different character encodings, I have been experimenting with the use of tuple records defined as: -record(text, {bin, charset = utf8, lang = 'us-en'}). Kind regards, Steve On Feb 12, 11:51?pm, Kenji Rikitake wrote: > In the message > dated Fri, Feb 12, 2010 at 04:58:37PM -0800, > > Steve Davis writes: > > While it may appear troublesome to type <<"hello">> rather than > > "hello", the rewards in later manipulation is extreme. > > This generally only works for ASCII strings, though I agree with the idea. > > Erlang's Unicode representation of strings introduces a complication in > this matter.http://erlang.org/doc/man/unicode.html > From steven.charles.davis@REDACTED Sat Feb 13 11:04:30 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 13 Feb 2010 02:04:30 -0800 (PST) Subject: One more question? In-Reply-To: <5F9647C8-0644-4BA4-B15D-D0FC9CF2F6F5@souja.net> References: <5F9647C8-0644-4BA4-B15D-D0FC9CF2F6F5@souja.net> Message-ID: <41cf4e1e-530d-4839-aea3-ecf17b2ef2a6@q16g2000yqq.googlegroups.com> "Awesome" is indeed how I would describe binary matching in Erlang. I first discovered the full beauty of it when I was faced with decoding UDP packets from a rather idiosynchratic protocol. Breaking out the bitflags and integer values of the header of these packets turned out to be as simple as: decode(<>) -> ..... As well as being highly efficient, the Erlang code adds semantic value by allowing you to directly name things for what they are without a bunch of preamble/enforced declarations. /s On Feb 12, 11:10?pm, Jayson Vantuyl wrote: > If you receive it via a streaming port, you can also use {packet,4} as an option, which will automatically break the binaries into appropriate lengths. > > Also, one of the more unusual (but awesome) bits of binary pattern matching is something like this: > > > <> > > Interestingly, you can also do it like this, to match chunks in a large binary: > > > <> > > On Feb 12, 2010, at 12:03 PM, Ish Rattan wrote: > > > > > Erlang server gets message from non-Erlang client as: > > <<0,0,0,10,72,101,108,108,111,46,46>> > > (numeric 10 in 4-bytes followed by "hello..") > > > how to extract the pieces? > > > -ishwar > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > Seehttp://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED > > -- > Jayson Vantuyl > kag...@REDACTED > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > Seehttp://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED From sgolovan@REDACTED Sat Feb 13 11:47:32 2010 From: sgolovan@REDACTED (Sergei Golovan) Date: Sat, 13 Feb 2010 13:47:32 +0300 Subject: Jinterface and GCJ 4.4 Message-ID: Hi! While trying to enable jinterface for Debian Erlang package I've tried to build it using a few Java compilers available in Debian. What I've found is that most of the compilers either build jinterface fine (OpenJDK-6) or don't pass JDK 1.5 test in configure (GCJ-4.3 or older). But GCJ 4.4 passes this test but fails to build jinterface because it has String(int[], int, int) constructor unimplemented. I've added an additional check for this to configure.in (see attachment) but wonder which would be the correct long term solution. If it's the only problem with GCJ then may be it'd be better not to use String(int[], int, int) at all? Cheers! -- Sergei Golovan -------------- next part -------------- A non-text attachment was scrubbed... Name: java.patch Type: application/octet-stream Size: 1494 bytes Desc: not available URL: From ulf.wiger@REDACTED Sat Feb 13 15:42:22 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sat, 13 Feb 2010 15:42:22 +0100 Subject: [erlang-questions] On Per-module process registration In-Reply-To: <201002131644.59004.als@iinet.net.au> References: <201002102046.01066.als@iinet.net.au> <408079F8-7BBC-48D4-BD2D-824E01478155@cs.otago.ac.nz> <201002131644.59004.als@iinet.net.au> Message-ID: <4B76BA4E.8030508@erlang-solutions.com> Anthony Shipman wrote: > I have implemented my own kinds of registry. What I don't have is the > ability to atomically spawn and register a process. Perhaps just > adding the ability to spawn a process in a paused state and then > unpause it later would solve that problem. Like this? -module(hib). -export([sp/0,init/0]). sp() -> spawn(fun() -> erlang:hibernate(?MODULE,init,[]) end). init() -> io:fwrite("ho!~n", []). 1> P=hib:sp(). <0.58.0> 2> timer:sleep(3000), P ! hi. ho! hi BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From enewhuis@REDACTED Sat Feb 13 18:22:34 2010 From: enewhuis@REDACTED (Eric Newhuis) Date: Sat, 13 Feb 2010 11:22:34 -0600 Subject: Exponential Backoff Idiom Message-ID: <99C8FCB2-A2DA-4A2D-9952-BDCD9966D6C0@gmail.com> Has anyone a better version of this they'd like to share? The trouble with this approach is that Fun cannot block. Maybe there is an entirely better way to express this so it works as a mix-in concept whether or not Fun has its own receive loop. I wrote this expecting it would not. backoff(N, Multiplier, Max, Fun, Acc) -> case Fun(Acc) of {continue, Acc2} -> receive after N -> discover(?IF(N < Max, N*Multiplier, Max)) end; {ok, Acc2} -> Acc2 end. From enewhuis@REDACTED Sat Feb 13 18:24:30 2010 From: enewhuis@REDACTED (Eric Newhuis) Date: Sat, 13 Feb 2010 11:24:30 -0600 Subject: Exponential Backoff Idiom In-Reply-To: <99C8FCB2-A2DA-4A2D-9952-BDCD9966D6C0@gmail.com> References: <99C8FCB2-A2DA-4A2D-9952-BDCD9966D6C0@gmail.com> Message-ID: <51A1D691-1E92-409A-B0EB-477203FDCCFE@gmail.com> Sorry for that. This is what I intended to post: > backoff(N, Multiplier, Max, Fun, Acc) -> > case Fun(Acc) of > {continue, Acc2} -> > receive > after > N -> > backoff(?IF(N < Max, N*Multiplier, Max)) > end; > {ok, Acc2} -> > Acc2 > end. On Feb 13, 2010, at 11:22 AM, Eric Newhuis wrote: > Has anyone a better version of this they'd like to share? The trouble with this approach is that Fun cannot block. Maybe there is an entirely better way to express this so it works as a mix-in concept whether or not Fun has its own receive loop. I wrote this expecting it would not. > > backoff(N, Multiplier, Max, Fun, Acc) -> > case Fun(Acc) of > {continue, Acc2} -> > receive > after > N -> > discover(?IF(N < Max, N*Multiplier, Max)) > end; > {ok, Acc2} -> > Acc2 > end. > From max.lapshin@REDACTED Sat Feb 13 19:27:41 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 13 Feb 2010 21:27:41 +0300 Subject: PATH to erts/bin under Windows Message-ID: Is it possible to ask author of windows package to add erts-5.N.N/bin to user PATH under windows? Currently it is required to add long path by hands. From andrew@REDACTED Sat Feb 13 19:45:16 2010 From: andrew@REDACTED (Andrew Thompson) Date: Sat, 13 Feb 2010 13:45:16 -0500 Subject: [erlang-questions] Re: Erlang Idioms - A Pattern for an Erlang Programming Team In-Reply-To: <423b201b-f303-4ce6-bdde-6cf6c01950a3@b7g2000yqd.googlegroups.com> References: <20100213055149.GA18023@k2r.org> <423b201b-f303-4ce6-bdde-6cf6c01950a3@b7g2000yqd.googlegroups.com> Message-ID: <20100213184516.GB5380@hijacked.us> On Sat, Feb 13, 2010 at 01:50:51AM -0800, Steve Davis wrote: > Hi Kenji, > > Yes indeed! The choice of character encoding is a matter that goes > beyond text manipulation. > > The idiom I use works when you already know what character encoding > you are dealing with. > > As for dealing with different character encodings, I have been > experimenting with the use of tuple records defined as: > -record(text, {bin, charset = utf8, lang = 'us-en'}). > I'd also echo Steve's recommendation on using binaries to hold textual data. When writing my SMTP toolkit in erlang I was running into extreme memory usage when decoding large MIME emails using lists - switching to binaries (and writing some helper functions for working with bitstrings) made the code faster, cleaner and use a LOT less memory. When dealing with the encoding problem, I've been using the iconv port I yanked out of jungerl and tweaked a little - I simply translate everything to utf-8 if its not already (or its not ASCII) and don't worry about it anymore. Another great benefit of binaries is how you can create sub binaries without using any extra memory so chopping up large inputs into their component parts (as long as you don't need to modify them) is effectively free from a memory standpoint. I really wonder why EEP9 (in some modified form - given the advent of the re module) hasn't made it into the OTP release. Andrew From vances@REDACTED Sat Feb 13 19:55:42 2010 From: vances@REDACTED (Vance Shipley) Date: Sat, 13 Feb 2010 13:55:42 -0500 Subject: [erlang-questions] A style question In-Reply-To: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> Message-ID: <20100213185542.GL13976@h216-235-12-174.host.egate.net> In my personal style I only use an inline fun() when it is short enough to fit on one line: case mnesia:transaction(fun() -> mnesia:all_keys(funky) end) of {atomic, Keys} -> ... {aborted, Reason} -> ... end Otherwise seperating the transaction logic itself from the transaction result handling is more clear. -Vance On Fri, Feb 12, 2010 at 05:34:52PM +1300, Richard O'Keefe wrote: } My preferred style for this would be } } mnesia:transaction(fun () -> } .... } end) -- -Vance From kagato@REDACTED Sat Feb 13 22:39:15 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Sat, 13 Feb 2010 13:39:15 -0800 Subject: [erlang-questions] A style question In-Reply-To: <20100213185542.GL13976@h216-235-12-174.host.egate.net> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <20100213185542.GL13976@h216-235-12-174.host.egate.net> Message-ID: <8F5B020D-DD34-4191-BB09-3F2DA377AABF@souja.net> I've always felt that "fun some_func/2" is underused. In the case of Mnesia, it's easy enough to do: > mnesia:transaction( fun actual_worker_fun/0 ) I also find this to be nicer for the purposes of documentation, static analysis, debugging, and readability. On Feb 13, 2010, at 10:55 AM, Vance Shipley wrote: > In my personal style I only use an inline fun() when it is > short enough to fit on one line: > > case mnesia:transaction(fun() -> mnesia:all_keys(funky) end) of > {atomic, Keys} -> > ... > {aborted, Reason} -> > ... > end > > Otherwise seperating the transaction logic itself from the > transaction result handling is more clear. > > -Vance > > On Fri, Feb 12, 2010 at 05:34:52PM +1300, Richard O'Keefe wrote: > } My preferred style for this would be > } > } mnesia:transaction(fun () -> > } .... > } end) > > -- > -Vance > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- Jayson Vantuyl kagato@REDACTED From jeedward@REDACTED Sun Feb 14 00:57:18 2010 From: jeedward@REDACTED (John Edward) Date: Sat, 13 Feb 2010 15:57:18 -0800 (PST) Subject: Draft paper submission deadline is extended: MULTICONF-10, Orlando, USA Message-ID: <463460.96282.qm@web45914.mail.sp1.yahoo.com> It would be highly appreciated if you could share this announcement with your colleagues, students and individuals whose research is in computer science, computer engineering, information science and related areas. Draft paper submission deadline is extended: MULTICONF-10, Orlando, USA The 2010 multi-conference (MULTICONF-10) (website: http://www.promoteresearch.org) will be held during July 12-14, 2010 in Orlando, Florida, USA. The primary goal of MULTICONF is to promote research and developmental activities in computer science, information technology, control engineering, and related fields. Another goal is to promote the dissemination of research to a multidisciplinary audience and to facilitate communication among researchers, developers, practitioners in different fields.The following conferences are planned to be organized as part of MULTICONF-10. * International Conference on Artificial Intelligence and Pattern Recognition (AIPR-10) * International Conference on Automation, Robotics and Control Systems (ARCS-10) * International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-10) * International Conference on Computer Communications and Networks (CCN-10) * International Conference on Enterprise Information Systems and Web Technologies (EISWT-10) * International Conference on High Performance Computing Systems (HPCS-10) * International Conference on Information Security and Privacy (ISP-10) * International Conference on Image and Video Processing and Computer Vision (IVPCV-10) * International Conference on Software Engineering Theory and Practice (SETP-10) * International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-10) MULTICONF-10 will be held at Imperial Swan Hotel and Suites. It is a full-service resort that puts you in the middle of the fun! Located 1/2 block south of the famed International Drive, the hotel is just minutes from great entertainment like Walt Disney World? Resort, Universal Studios and Sea World Orlando. Guests can enjoy free scheduled transportation to these theme parks, as well as spacious accommodations, outdoor pools and on-site dining ? all situated on 10 tropically landscaped acres. Here, guests can experience a full-service resort with discount hotel pricing in Orlando. Please see the website http://www.promoteresearch.org for more details. Sincerely John Edward From vances@REDACTED Sun Feb 14 04:19:24 2010 From: vances@REDACTED (Vance Shipley) Date: Sat, 13 Feb 2010 22:19:24 -0500 Subject: Change node name in mnesia Message-ID: <20100214031924.GM13976@h216-235-12-174.host.egate.net> I used the example in the Mnesia User's Guide to backup and transform a database from a long node name to a short one. That all seemed to go smoothly enough but now I'm noticing these strange records in my tables: {log_header,dcl_log,"1.0","4.4.10",'foo@REDACTED',{1266,113437,587068}}, I discovered this using mnesia:foldl/3. Is this normal or have I messed things up? -- -Vance From silent_vendetta@REDACTED Sun Feb 14 04:17:32 2010 From: silent_vendetta@REDACTED (Chris Hicks) Date: Sat, 13 Feb 2010 19:17:32 -0800 Subject: EMACS for Erlang problems Message-ID: I am running Windows 7 and am looking to get into programming in Erlang. I downloaded the latest release of both Erlang and EMACS, installed them both and verified that both started up correctly. I am using the _emacs file in the appropriate folder that looks like the following: (setq load-path (cons "C:/Program Files(x86)/erl5.7.4/lib/tools-2.6.5/emacs" load-path))(setq erlang-root-dir "C:/Program Files(x86)/erl5.7.4")(setq exec-path (cons "C:/Program Files(x86)/erl5.7.4/bin" exec-path))(require 'erlang-start) Using that file generates an error message when starting up emacs that erlang-start can not be loaded. Any help would be great as I can't find an answer to this problem. _________________________________________________________________ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/201469228/direct/01/ From kaykay.unique@REDACTED Sun Feb 14 06:10:29 2010 From: kaykay.unique@REDACTED (Kay Kay) Date: Sat, 13 Feb 2010 21:10:29 -0800 Subject: Sequential I/O access for large files in Erlang Message-ID: <4B7785C5.6030504@gmail.com> For a particular use case of mine - I need to be dealing with some bulk text i/o (medium sized multiple files of ~50 MB each ). While looking for some best solutions , came across this blog here at - http://concise-software.blogspot.com/2008/09/blazing-fast-concurrent-text-io-in.html . I am using - 5.7.4 beam emulator (on ubuntu) at the moment. I am trying to get some opinions on some of the recommended options , w.r.t this, that the community would suggest. Thanks. From bgustavsson@REDACTED Sun Feb 14 08:33:48 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sun, 14 Feb 2010 08:33:48 +0100 Subject: [erlang-questions] Sequential I/O access for large files in Erlang In-Reply-To: <4B7785C5.6030504@gmail.com> References: <4B7785C5.6030504@gmail.com> Message-ID: <6672d0161002132333t16c6ea70q344c6902c4da4bad@mail.gmail.com> On Sun, Feb 14, 2010 at 6:10 AM, Kay Kay wrote: > For a particular use case of mine - I need to be dealing with some bulk text > i/o ?(medium sized multiple files of ~50 MB each ). > > While looking for some best solutions , came across this blog here at - > ?http://concise-software.blogspot.com/2008/09/blazing-fast-concurrent-text-io-in.html > . Since that blog post was written, the file:read_line/1 function has been added. See: http://www.erlang.org/doc/man/file.html#read_line-1 file:read_line/1 (if used properly as described in the documentation) will speed up reading of lines from text files. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kaykay.unique@REDACTED Sun Feb 14 11:51:27 2010 From: kaykay.unique@REDACTED (Kay Kay) Date: Sun, 14 Feb 2010 02:51:27 -0800 Subject: illegal guard expression: filelib:is_dir(H) Message-ID: <4B77D5AF.5000106@gmail.com> I have a function along the following lines do_process_elements([], _) -> []; do_process_elements([H | _], Fn) -> if filelib:is_dir(H) -> process_directory(H, Fn); true -> process_file(H, Fn) end. When I compile - I get the following error, where the line number refers to - filelib:is_dir(H) function. ./test.erl:23: illegal guard expression Given that filelib:is_dir(H) returns true / false - I thought this would fit in here as a predicate. What could be going wrong ? From kostis@REDACTED Sun Feb 14 12:01:22 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Sun, 14 Feb 2010 13:01:22 +0200 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: <4B77D5AF.5000106@gmail.com> References: <4B77D5AF.5000106@gmail.com> Message-ID: <4B77D802.4090509@cs.ntua.gr> Kay Kay wrote: > I have a function along the following lines > > do_process_elements([], _) -> []; > do_process_elements([H | _], Fn) -> > if > filelib:is_dir(H) -> > process_directory(H, Fn); > true -> > process_file(H, Fn) > end. > > > When I compile - I get the following error, where the line number > refers to - filelib:is_dir(H) function. > > ./test.erl:23: illegal guard expression > > Given that filelib:is_dir(H) returns true / false - I thought this > would fit in here as a predicate. What could be going wrong ? The if construct in Erlang is very restrictive w.r.t. what it can be used with. Do not use it. Use case instead: do_process_elements([], _) -> []; do_process_elements([H | _], Fn) -> case filelib:is_dir(H) of true -> process_directory(H, Fn); false -> process_file(H, Fn) end. Kostis From kagato@REDACTED Sun Feb 14 12:09:10 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Sun, 14 Feb 2010 03:09:10 -0800 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: <4B77D5AF.5000106@gmail.com> References: <4B77D5AF.5000106@gmail.com> Message-ID: <13BD4AB9-0C8D-4D04-88E8-F868A7070EEB@souja.net> Oddly, in Erlang, "if" only accepts expressions that are valid in guards. This usually means special builtin functions that are normally used to make pattern matching more precise. Because pattern matching must be fast, most function calls are forbidden. For this reason, you'll usually see a case (or a try) statement where you'd expect an "if". To make thing even more confusing, "if" is most useful when you have a number of unrelated comparisons (limited to guards) that should be checked until one is true. Most other languages would use a chain of if-elsif-else statements or even a case statement. E.g. "case filelib:is_dir(H) of true -> ...; false -> ... end" To top it off, you could save that expression in a variable and that could work, but would still be confusing. E.g. "F = filelib:is_dir(H), if F == true -> ...; true -> ... end" This is all a but backwards and probably more confusing than it has a right to be. That said, you should probably read the section of the Erlang manual about guards. Once you grok them, they're powerfully useful. Until then, just remember that "if" is for guards only, and you probably want a case (or try) statement. Good luck! Sent from my iPhone On Feb 14, 2010, at 2:51 AM, Kay Kay wrote: > I have a function along the following lines > > do_process_elements([], _) -> []; > do_process_elements([H | _], Fn) -> > if > filelib:is_dir(H) -> > process_directory(H, Fn); > true -> > process_file(H, Fn) > end. > > > When I compile - I get the following error, where the line number > refers to - filelib:is_dir(H) function. > > ./test.erl:23: illegal guard expression > > Given that filelib:is_dir(H) returns true / false - I thought this > would fit in here as a predicate. What could be going wrong ? > > > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From kagato@REDACTED Sun Feb 14 12:11:43 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Sun, 14 Feb 2010 03:11:43 -0800 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: <13BD4AB9-0C8D-4D04-88E8-F868A7070EEB@souja.net> References: <4B77D5AF.5000106@gmail.com> <13BD4AB9-0C8D-4D04-88E8-F868A7070EEB@souja.net> Message-ID: Oops, put that first example after the second (not the third) paragraph. That's what I get for mailing from my phone. :( Sent from my iPhone On Feb 14, 2010, at 3:09 AM, Jayson Vantuyl wrote: > Oddly, in Erlang, "if" only accepts expressions that are valid in > guards. This usually means special builtin functions that are > normally used to make pattern matching more precise. Because pattern > matching must be fast, most function calls are forbidden. > > For this reason, you'll usually see a case (or a try) statement > where you'd expect an "if". > > To make thing even more confusing, "if" is most useful when you have > a number of unrelated comparisons (limited to guards) that should be > checked until one is true. Most other languages would use a chain of > if-elsif-else statements or even a case statement. E.g. "case > filelib:is_dir(H) of true -> ...; false -> ... end" > > To top it off, you could save that expression in a variable and that > could work, but would still be confusing. E.g. "F = filelib:is_dir > (H), if F == true -> ...; true -> ... end" > > This is all a but backwards and probably more confusing than it has > a right to be. That said, you should probably read the section of > the Erlang manual about guards. Once you grok them, they're > powerfully useful. Until then, just remember that "if" is for guards > only, and you probably want a case (or try) statement. > > Good luck! > > Sent from my iPhone > > On Feb 14, 2010, at 2:51 AM, Kay Kay wrote: > >> I have a function along the following lines >> >> do_process_elements([], _) -> []; >> do_process_elements([H | _], Fn) -> >> if >> filelib:is_dir(H) -> >> process_directory(H, Fn); >> true -> >> process_file(H, Fn) >> end. >> >> >> When I compile - I get the following error, where the line number >> refers to - filelib:is_dir(H) function. >> >> ./test.erl:23: illegal guard expression >> >> Given that filelib:is_dir(H) returns true / false - I thought this >> would fit in here as a predicate. What could be going wrong ? >> >> >> >> >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From leap@REDACTED Sun Feb 14 12:44:42 2010 From: leap@REDACTED (Michael Turner) Date: Sun, 14 Feb 2010 11:44:42 +0000 Subject: [erlang-questions] On Per-module process registration In-Reply-To: <4B76BA4E.8030508@erlang-solutions.com> Message-ID: If I'm not mistaken (I'm such a noob, I probably am) ..... Assuming it's the process's responsibility to register itself, you can get some of the "atomic spawn registered" effect with proc_lib:start. Pass the name under which to register the new process, among other things, and write the proc's module so that no other process gets told of the new process's self() until its self() is registered under that name. Since proc_lib:start is synchronous, nothing else can know the new process's Pid until proc_lib:start returns. So no other process can register it. UNLESS -- the new process sends its self() to another process during its own startup, but before it has registered itself. Well, then, like the doctor said: if it hurts when you do that, don't do that. Until then, the process can effectively register itself without concern that any other process will register it under a different name. Of course, there's still the problem that some other process might already be registered under the same name. Arguably, though, that situation represents an issue with the logic of how your app uses the registry in the first place. The registry being a kind of global namespace, you obviously can't really be safe without enforcing some kind of global discipline on the code. One way or another, you've got to serialize modifications to the registry. Lacking any way to do this that's specific to the registry, I use global:trans/2, even though it's a lock wrapper for the *multi-node* process namespace -- which is not even of interest to me at this point. % This is re-hacked from other code I'm using, not even re-compiled, % so caveat emptor: a_new_proc_named (L) -> global:trans ( {L,self()}, fun() -> case whereis(L) of undefined -> Pid = spawn (this_module, i_gotta_be_me, [[]]), register (L, Pid), Pid; Pid -> .... % error case end end). % w/2 args, defaults to infinite retry, locks all nodes? I don't know if I'm doing this right, though, especially with that first argument to trans/2 -- trans depends on set_lock/3 and I don't really get how that works. Not to mention that I let it default to infinite retries (presumably spinning on an atom L already registered, in hopes it'll be liberated someday.) Even if this is OK, I'm sure there are better ways. Probably one that uses set_lock/3 directly. But like it says in the book(s), using the registry has potential for creating bottlenecks. Even if you had some some new BIF like atomic_spawn_registered, *that* could become a bottleneck. For that matter, consider the deadlock potential of my proposed proc_lib:start approach, above. When you have concurrency *and* globally accessible resources, there's no substitute for being very careful. -michael turner On 2/13/2010, "Ulf Wiger" wrote: >Anthony Shipman wrote: >> I have implemented my own kinds of registry. What I don't have is the >> ability to atomically spawn and register a process. Perhaps just >> adding the ability to spawn a process in a paused state and then >> unpause it later would solve that problem. > >Like this? > > >-module(hib). >-export([sp/0,init/0]). > >sp() -> > spawn(fun() -> > erlang:hibernate(?MODULE,init,[]) > end). > >init() -> > io:fwrite("ho!~n", []). > > > > >1> P=hib:sp(). ><0.58.0> >2> timer:sleep(3000), P ! hi. >ho! >hi > > >BR, >Ulf W > >-- >Ulf Wiger >CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd >http://www.erlang-solutions.com >--------------------------------------------------- > >--------------------------------------------------- > >WE'VE CHANGED NAMES! > >Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. > >www.erlang-solutions.com > > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From leap@REDACTED Sun Feb 14 13:07:09 2010 From: leap@REDACTED (Michael Turner) Date: Sun, 14 Feb 2010 12:07:09 +0000 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: <13BD4AB9-0C8D-4D04-88E8-F868A7070EEB@souja.net> Message-ID: Could be worse, y'know. At least Erlang "if" guards are checked in the order written. Dijkstra introduced the term "guard" using if ... syntax as well, but if more than one guard was true, one of the guarded statements was selected "non-deterministically" -- at least if you believe Wikipedia. http://en.wikipedia.org/wiki/Guarded_Command_Language On the whole, I'd prefer the guards at Guantanamo. -michael turner On 2/14/2010, "Jayson Vantuyl" wrote: >Oddly, in Erlang, "if" only accepts expressions that are valid in >guards. This usually means special builtin functions that are normally >used to make pattern matching more precise. Because pattern matching >must be fast, most function calls are forbidden. > >For this reason, you'll usually see a case (or a try) statement where >you'd expect an "if". > >To make thing even more confusing, "if" is most useful when you have a >number of unrelated comparisons (limited to guards) that should be >checked until one is true. Most other languages would use a chain of >if-elsif-else statements or even a case statement. E.g. "case >filelib:is_dir(H) of true -> ...; false -> ... end" > >To top it off, you could save that expression in a variable and that >could work, but would still be confusing. E.g. "F = filelib:is_dir(H), >if F == true -> ...; true -> ... end" > >This is all a but backwards and probably more confusing than it has a >right to be. That said, you should probably read the section of the >Erlang manual about guards. Once you grok them, they're powerfully >useful. Until then, just remember that "if" is for guards only, and >you probably want a case (or try) statement. > >Good luck! > >Sent from my iPhone > >On Feb 14, 2010, at 2:51 AM, Kay Kay wrote: > >> I have a function along the following lines >> >> do_process_elements([], _) -> []; >> do_process_elements([H | _], Fn) -> >> if >> filelib:is_dir(H) -> >> process_directory(H, Fn); >> true -> >> process_file(H, Fn) >> end. >> >> >> When I compile - I get the following error, where the line number >> refers to - filelib:is_dir(H) function. >> >> ./test.erl:23: illegal guard expression >> >> Given that filelib:is_dir(H) returns true / false - I thought this >> would fit in here as a predicate. What could be going wrong ? >> >> >> >> >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From rapsey@REDACTED Sun Feb 14 20:33:38 2010 From: rapsey@REDACTED (Rapsey) Date: Sun, 14 Feb 2010 20:33:38 +0100 Subject: [Erlyaws-list] Runing Both Apache and YAWS on Port 80 In-Reply-To: References: Message-ID: <97619b171002141133n72a54228of031e8d903aae18@mail.gmail.com> I would put nginx or haproxy on port 80 and configure it to proxy requests to yaws/apache depending on the domain. Sergek On Sun, Feb 14, 2010 at 4:21 PM, Hank Knight wrote: > Hello, > > I would like to run both Apache and YAWS on port 80. > > Using virtual hosts, this website should use YAWS > http://yaws.example.com/ > > While this one should be run by Apache: > http://apache.example.com/ > > Maybe YAWS could be setup to run on port 80 and Apache could run on > port 8888 and then setup a proxy to run Apache, based on virtual host > settings? > > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Erlyaws-list mailing list > Erlyaws-list@REDACTED > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > From kaykay.unique@REDACTED Sun Feb 14 22:38:04 2010 From: kaykay.unique@REDACTED (Kay Kay) Date: Sun, 14 Feb 2010 13:38:04 -0800 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: <4B77D802.4090509@cs.ntua.gr> References: <4B77D5AF.5000106@gmail.com> <4B77D802.4090509@cs.ntua.gr> Message-ID: <4B786D3C.509@gmail.com> On 02/14/2010 03:01 AM, Kostis Sagonas wrote: > Kay Kay wrote: >> I have a function along the following lines >> >> do_process_elements([], _) -> []; >> do_process_elements([H | _], Fn) -> >> if >> filelib:is_dir(H) -> >> process_directory(H, Fn); >> true -> >> process_file(H, Fn) >> end. >> >> >> When I compile - I get the following error, where the line number >> refers to - filelib:is_dir(H) function. >> >> ./test.erl:23: illegal guard expression >> >> Given that filelib:is_dir(H) returns true / false - I thought this >> would fit in here as a predicate. What could be going wrong ? > > The if construct in Erlang is very restrictive w.r.t. what it can be > used with. Do not use it. Use case instead: > > do_process_elements([], _) -> []; > do_process_elements([H | _], Fn) -> > case filelib:is_dir(H) of > true -> > process_directory(H, Fn); > false -> > process_file(H, Fn) > end. > > Kostis Thanks for the clarification. From a runtime cost - would this be any different ( in terms of time/space complexity) from adding another rule to do the same . (eg, as given below ? ) . do_process_unixfile(true, H, Fn) -> process_directory(H, Fn); do_process_unixfile(false, H, Fn) -> process_file(H, Fn). do_process_elements([], _) -> []; do_process_elements([H | _], Fn) -> do_process_unixfile( filelib:is_dir(H), H, Fn). I find the latter 'purely' functional and amenable for optimization, than the former , which comes to me as a 'procedural' construct. Is there any document / guide to refer to , for best practices with Erlang for cases like this ? From OK@REDACTED Mon Feb 15 00:48:25 2010 From: OK@REDACTED (Richard O'Keefe) Date: Mon, 15 Feb 2010 12:48:25 +1300 Subject: SV: [erlang-questions] A style question In-Reply-To: References: Message-ID: <27C31081-0593-4A1D-8503-EF24D1834C71@CS.OTAGO.AC.NZ> On Feb 12, 2010, at 7:05 PM, Ulf Wiger wrote: > There is an alternative that actually has a distinct advantage: > > mnesia:activity( > transaction, > fun my_transaction_fun/0) > > The advantage is that when tracing, you get much more readable output. I see. There is a big disadvantage that nothing actually stops my_transaction_fun/0 being called when it is *not* in a transaction. The great thing about mnesia:transaction(fun () -> ... end or mnesia:activity(transaction, fun () -> ... end is that the ... code is visibly and necessarily inside a transaction. I wonder whether there could be a way to get the best of both worlds? I take your point about tracing, but is there any reason why a function name displayed in tracing _has_ to be a real function name? Could there be some way of attaching a name to a fun for tracing purposes? Maybe something like mnesia:activity(transaction, fun:my_transaction () -> ... end This is not, and isn't intended to become, and EEP. There's probably a much better way to do it. From OK@REDACTED Mon Feb 15 01:29:11 2010 From: OK@REDACTED (Richard O'Keefe) Date: Mon, 15 Feb 2010 13:29:11 +1300 Subject: [erlang-questions] A style question In-Reply-To: <7702c0611002120118m3b135a52gab74a9218732547c@mail.gmail.com> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <7702c0611002120118m3b135a52gab74a9218732547c@mail.gmail.com> Message-ID: <65F3EF94-362B-41CD-A9D9-363C4D5D46F0@cs.otago.ac.nz> The topic is F = fun (...) -> ... end, foo(..., F) vs foo(..., fun (...) -> ... end On Feb 12, 2010, at 10:18 PM, Richard Andrews wrote: > Clarity. One of my mantras of coding is: "if it's not obviously right > then it's probably wrong". We definitely agree about that, which is why I prefer the second one. Advantages of the second approach include but are not limited to: - it is immediately obvious that this is the only place the function can be called - it is immediately obvious by looking up (just as one does for code in an 'if' or 'case' or 'receive') what governs the execution of this code These things are not "obviously right" in the separated version. > > I find the former preferable when fun() is large or bulky. Inline fun > can make it unclear what the code is supposed to do. We are agreed that "large or bulky" code can be unclear. In specific cases, we might disagree about _which_ chunks of code should be moved. > > The other reason I use the former is to give the fun a useful name > which (again) makes the code operation/goals clearer (ie. > code==documentation). I would rather read your code than the code that made me ask this question, because the function name was invariably "F" or something equally unhelpful. Coming from a Smalltalk background where you write things like 1 to: n do: [:i | ... loop body ... ] it's not clear to me that _any_ name would be more useful than a well chosen comment, but I think we probably agree that "well-chosen" is more important than whether it's a named function or an inline one with a comment. It's probably time to draw this thread to an end. You and Ulf Wiger have given me something to think about. From ok@REDACTED Mon Feb 15 02:00:21 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 15 Feb 2010 14:00:21 +1300 Subject: [erlang-questions] Erlang Idioms - A Pattern for an Erlang Programming Team In-Reply-To: <5db086ad1002121612l73c538e5x55861870522c0f5d@mail.gmail.com> References: <401d3ba31002120655g140e51e8ra5f6f316ee0f4fb5@mail.gmail.com> <20D90B86-3D59-4FE9-A61F-3BD2274D6303@gmail.com> <5db086ad1002121612l73c538e5x55861870522c0f5d@mail.gmail.com> Message-ID: <94EEEB1B-2349-4653-A5B6-3A812DB27774@cs.otago.ac.nz> I note that the classic Smalltalk IDE has a panel for code snippets you're likely to use often. To start with, why not put what you have up on a web page? Add some counters to see how many people visit and how many people download what, and then you have some nice statistics for a conference presentation. From ok@REDACTED Mon Feb 15 02:15:58 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 15 Feb 2010 14:15:58 +1300 Subject: [erlang-questions] Re: reverse engineering beam files / obfuscation ? In-Reply-To: <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> References: <4B750EE1.7010302@gmail.com> <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> Message-ID: <08D49313-584D-469C-8242-5CA2B306ADCE@cs.otago.ac.nz> Quintus faced this issue many years ago now. There is _nothing_ you can do to stop a sufficiently determined cracker. Here's an anecdote. (1) The Quintus emulator was shipped as an executable binary with (a) most but not all of the C symbols stripped (b) many but not all of the atoms used in the Prolog system clobbered (things users were _supposed_ to be able to mention were preserved, everything else smashed). (c) we had a special in-house-ONLY tool for restoring the smashed names. (2) Full *and* demo versions of Quintus Prolog were handed out after the purchaser signed a contract saying, amongst other things, that they would not disassemble the system. (3) One organisation that got a free demo copy of Quintus Prolog was a large software company with a Prolog of their own. (Fair enough, we had a demo copy of their system at one time.) (4) They attempted to publish in a conference a paper detailing implementation techniques that were used, to the best of our knowledge, only in Quintus Prolog. Judging from what some of the people from that company had said previously, they had not then been using these techniques themselves. (5) We informed the conference, and the paper was not published. The need to disassemble MC68020 instructions hadn't stopped them. A contract saying they wouldn't reverse engineer hadn't stopped them. At least if it's in the contract the crackers will KNOW they are doing something wrong, not just difficult. From yoursurrogategod@REDACTED Mon Feb 15 02:40:22 2010 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Sun, 14 Feb 2010 17:40:22 -0800 (PST) Subject: Issues with compiling R13B03 In-Reply-To: <293b4141-e64f-4601-889f-a59e4451fe7c@k35g2000yqb.googlegroups.com> References: <293b4141-e64f-4601-889f-a59e4451fe7c@k35g2000yqb.googlegroups.com> Message-ID: <97339c21-681a-429c-a015-09346ae8d43f@v20g2000prb.googlegroups.com> I'm still having this issue. For some reason it compiles fine on my laptop. I compared the outputs of the configure scripts and they're virtually the same (I used diff to accomplish this.) I just want to have a sanity check if someone has seen this problem before. I'll be happy to post the configure script outputs if someone wants to see it for themselves. From ok@REDACTED Mon Feb 15 03:06:10 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 15 Feb 2010 15:06:10 +1300 Subject: [erlang-questions] A style question In-Reply-To: <8F5B020D-DD34-4191-BB09-3F2DA377AABF@souja.net> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <20100213185542.GL13976@h216-235-12-174.host.egate.net> <8F5B020D-DD34-4191-BB09-3F2DA377AABF@souja.net> Message-ID: <3EF6BC55-C8E3-4ED4-8DB3-187B7925EAFF@cs.otago.ac.nz> On Feb 14, 2010, at 10:39 AM, Jayson Vantuyl wrote: > I've always felt that "fun some_func/2" is underused. It's a good thing to use _if_ you already have some_func/2 and don't need to pass it any arguments. We have agreement on a number of points. (1) If you introduce a name for a function that is passed to a higher order operation, it should be a meaningful name, not just "F" or "f" or anything like that. (2) If you already want to name a function for some other reason, use fun F/N to refer to it rather than fun (X,...) -> F(X,...) end. (3) If the code would be bulky, _something_ has to move out and it might as well be the 'fun'. (4) Having 'fun (..) -> end' available means we don't have to export things just so they can be called, and having 'fun F/N' available means the same; exporting stuff we'd rather not is no longer an issue. (5) If there is information in the surrounding clause that needs to be passed in, one level of 'fun' to capture that seems to be necessary, but it need not be the _whole_ of the computation; you can hand the information off to something with a name and a comment. I think we're now pretty much down to the "personal judgement" level. From ok@REDACTED Mon Feb 15 03:18:50 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 15 Feb 2010 15:18:50 +1300 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: <4B77D5AF.5000106@gmail.com> References: <4B77D5AF.5000106@gmail.com> Message-ID: <3E373B4B-F801-40C4-BC2F-1E94F22980A3@cs.otago.ac.nz> On Feb 14, 2010, at 11:51 PM, Kay Kay wrote: > I have a function along the following lines > > do_process_elements([], _) -> []; > do_process_elements([H | _], Fn) -> > if > filelib:is_dir(H) -> > process_directory(H, Fn); > true -> > process_file(H, Fn) > end. > > > When I compile - I get the following error, where the line number > refers to - filelib:is_dir(H) function. > > ./test.erl:23: illegal guard expression > > Given that filelib:is_dir(H) returns true / false - I thought this > would fit in here as a predicate. What could be going wrong ? Guards are NOT expressions. They are in a special mini-language that allows only a small fixed set of guard functions and tests. Amongst other things, guards are not allowed to have side effects. This is explained in Erlang books and the Erlang reference manual. In this case, the answer is simple: do_process_elements([H|T], Fn) -> case filelib:is_dir(H) of true -> process_directory(H, Fn) ; false -> process_file(H, Fn) end. We had a thread about this last year. One point in that thread was that very often you think of something as having two outcomes and map it to a Boolean, but *really* there are more outcomes, so you should be using a 'case' anyway. This is a perfect example of that. There are some issues with filelib. For example, file_lib:is_file(F) is true when F is a file or a directory. If that hasn't led to mistakes, I'll be surprised. If you look for a "file", there are at least four outcomes: - there is a file system binding for that name and it is a directory - there is a file system binding for that name and it is a regular file - there is a file system binding for that name and it is something else (character special, block special, symbolic link, named pipe, door, ...) [PS: can anyone explain to me, as to a very small child, what a Solaris "door" is?] - there is no file system binding for that name and of course with symbolic links there is the issue of whether you want to see them or not. For the sake of argument, one simple interface might be filelib2:file_type(FileName) -> directory regular other missing You should probably be using something like do_process_elements([H|T], Fn) -> case filelib2:file_type(H) of directory -> process_directory(H, Fn) ; regular -> process_file(H, Fn) ; other -> process_other(H, Fn) ; missing -> process_missing(H, Fn) end. I have come to regard attempts to use 'if' with user-defined tests as a "code smell". They're not always misguided, but they indicate an underlying problem often enough that I am now _glad_ that 'if' doesn't allow them. From ok@REDACTED Mon Feb 15 03:26:13 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 15 Feb 2010 15:26:13 +1300 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: References: Message-ID: On Feb 15, 2010, at 1:07 AM, Michael Turner wrote: > > Could be worse, y'know. At least Erlang "if" guards are checked in > the order written. Dijkstra introduced the term "guard" using if ... > syntax as well, but if more than one guard was true, one of the > guarded > statements was selected "non-deterministically" -- at least if you > believe Wikipedia. > > http://en.wikipedia.org/wiki/Guarded_Command_Language > > On the whole, I'd prefer the guards at Guantanamo. Dijkstra's guarded command language goes with a semantics and a >>design method<< in which you write non-overlapping guards unless you have >>demonstrated<< that in case of overlap it really does not matter which statement you pick. The classic example is if X <= Y -> Max := Y [] Y <= X -> Max := X fi where (a) if X = Y then it really does not matter which assignment you choose (b) conventional practice introduces an entirely artificial asymmetry between the two cases (c) in more complicated cases, it is easier to reason about each choice because, amongst other things, the condition under which this choice is _explicit_, it's not "this and not that and not the other and not some other thing". Like Erlang's 'if' and 'case', the execution of guards in Dijkstra's notation is not allowed to have side effects. So you can't tell what order the guards were tested in except in cases where you've demonstrated that you don't care. The reference to Guantanamo is, um, hyperbolic, to put it mildly. From kagato@REDACTED Mon Feb 15 03:35:42 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Sun, 14 Feb 2010 18:35:42 -0800 Subject: [erlang-questions] A style question In-Reply-To: <3EF6BC55-C8E3-4ED4-8DB3-187B7925EAFF@cs.otago.ac.nz> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <20100213185542.GL13976@h216-235-12-174.host.egate.net> <8F5B020D-DD34-4191-BB09-3F2DA377AABF@souja.net> <3EF6BC55-C8E3-4ED4-8DB3-187B7925EAFF@cs.otago.ac.nz> Message-ID: With respect to exports (#4), I just tested it with R13B, it doesn't appear that you have to export a fun to reference it. Specifically, this works for me: > -module(u). > -export ([test/0]). > > test() -> > F = fun test2/0, > F(). > > test2() -> > ok. That said, I think point #5 is an important one, although maybe not for the reason you do. I've noticed that some people have gaps in their knowledge of Erlang. "fun somefunc/N" seems to be one of them. Capturing surrounding variables is another one. As for point #3, I don't know of many times I would consider "fun () -> .. end" to be anything but bulky. Then again, Ruby and Python may have me spoiled in that respect. Of course, that is definitely a matter of personal preference. On Feb 14, 2010, at 6:06 PM, Richard O'Keefe wrote: > > On Feb 14, 2010, at 10:39 AM, Jayson Vantuyl wrote: > >> I've always felt that "fun some_func/2" is underused. > > It's a good thing to use _if_ you already have some_func/2 and > don't need to pass it any arguments. > > We have agreement on a number of points. > > (1) If you introduce a name for a function that is passed to > a higher order operation, it should be a meaningful name, > not just "F" or "f" or anything like that. > > (2) If you already want to name a function for some other reason, > use fun F/N to refer to it rather than fun (X,...) -> F(X,...) end. > > (3) If the code would be bulky, _something_ has to move out and > it might as well be the 'fun'. > > (4) Having 'fun (..) -> end' available means we don't have to > export things just so they can be called, and having > 'fun F/N' available means the same; exporting stuff we'd > rather not is no longer an issue. > > (5) If there is information in the surrounding clause that needs to > be passed in, one level of 'fun' to capture that seems to be > necessary, but it need not be the _whole_ of the computation; > you can hand the information off to something with a name and > a comment. > > I think we're now pretty much down to the "personal judgement" > level. > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- Jayson Vantuyl kagato@REDACTED From jim@REDACTED Mon Feb 15 04:01:31 2010 From: jim@REDACTED (Jim Larson) Date: Sun, 14 Feb 2010 19:01:31 -0800 Subject: [erlang-questions] Teaching Erlang as part of a paper -- advice sought In-Reply-To: Your message of "Mon, 08 Feb 2010 12:14:45 +1300." <8C0499EA-478E-4995-814C-57B6E189FBD1@cs.otago.ac.nz> Message-ID: <201002150301.o1F31VTx004382@krumkake.jetcafe.org> In message <8C0499EA-478E-4995-814C-57B6E189FBD1@REDACTED> you write: >Here there is a dispute between me and one of the other lecturers >in the department, who will not be involved in this paper, at least >not this year. I want the students to start learning about >concurrent programming in a language in which data races (at least >data races not involving external resources) are simply impossible. >He thinks they should (a) learn what a data race looks like the hard >way early on and (b) learn not be be afraid of data races, because >the low level locking code on x86-64 Linux apparently has a benign >data race. A data race can certainly be modeled in Erlang, even in a motivated way, by implementing the equivalent of a mutable cell that responds to a simple "get" and "set" protocol. With more sophistication, one could model subtle properties of multiprocessor cache memory, e.g. by introducing an "optimization" to the above mutable cell in a distributed Erlang instance by adding local cache processes. This could give students a great understanding of concurrency that will help them even when programming C++ or Java in the future - the understanding that even simple memory accesses can be complicated, but their behavior can be understood in terms of distributed events and messages between them. Jim From leap@REDACTED Mon Feb 15 06:40:19 2010 From: leap@REDACTED (Michael Turner) Date: Mon, 15 Feb 2010 05:40:19 +0000 Subject: [erlang-questions] A style question In-Reply-To: <3EF6BC55-C8E3-4ED4-8DB3-187B7925EAFF@cs.otago.ac.nz> Message-ID: Richard wrote: >I think we're now pretty much down to the "personal judgement" >level. In some ways, that's where it started. For example, you characterized F as "opaque". Fair enough, but it's at least allusive in the right ways. From middle school algebra onward, my math teachers were saying highly idiomatic things like, "let f be a function that ....." It wasn't even until my calculus classes, IIRC, that they finally let g be a function too. Imagine g's impatience! And who can look at a *capital* F without slight jolt of adrenaline about the possibility of failure? Nothing concentrates the mind like an F in the morning. So when I read F = fun () -> .... some_call (..., F, ...) the fact that it's F (and not, say, U or K) actually helps a bit. After all, the idea of passing functions to functions remains a little weird after all these years. (Lambda might be the ultimate opcode, but the ultimate of anything will be less accessible almost by definition.) I like it when code has clues about where I need to think a little harder than usual. Code like the above makes me think, "Ah, that's right, some_call takes a function in *that* argument position. Thanks for the reminder. OK, so what does the function do?" And the answer is directly above. How about some more descriptive name than F? Possibly. Maybe desirably, in most cases. But one programmer might think some name other than F was more evocative, where another might find that same name confusing; in such cases, the fun code itself might be the best expression of meaning. And, of course, the whole thing is easier to indent prettily. I'll allow that this all sounds like a pile of petty rationalizations, but that's what idioms are, in natural languages and artifical ones like algebra and Erlang: an expressive little flock of compromises flying in close formation. What I often do is get something working in the form above, THEN get rid of the F, put the whole lambda expression into the argument list and twiddle around with the indentation until it looks right to me. After all, baking the cake is hard, but if you get the decoration wrong, you can always just scrape the frosting layer off and try again. And how do you really know you've gotten it wrong, anyway? Beauty is in the eye of the beholder. I do like your idea of some_call (..., fun:fname() -> ... end, ....) for better trace info (and some self-documentation), though it would probably be syntactically more consistent and easier to parse for both human and machine if you had a blank instead of the colon. An EEP? Maybe for now, it would be better just to cobble up a BIF that supplies the debugger a name for the fun, to call in the body of the fun, throwing an exception if it was called in a named fun. (If that's possible; I don't know the relevant compiler/BEAM internals.) If it can work somehow, and people like it (it seems they should), then your more flavorful idea is waiting in the wings. At which point, we'll probably see some people writing hair-tearingly stupid code like this: some_call (..., fun F() -> ... end, ....) Because when fun is first class, the fun never ends. -michael turner On 2/15/2010, "Richard O'Keefe" wrote: > >On Feb 14, 2010, at 10:39 AM, Jayson Vantuyl wrote: > >> I've always felt that "fun some_func/2" is underused. > >It's a good thing to use _if_ you already have some_func/2 and >don't need to pass it any arguments. > >We have agreement on a number of points. > >(1) If you introduce a name for a function that is passed to > a higher order operation, it should be a meaningful name, > not just "F" or "f" or anything like that. > >(2) If you already want to name a function for some other reason, > use fun F/N to refer to it rather than fun (X,...) -> F(X,...) end. > >(3) If the code would be bulky, _something_ has to move out and > it might as well be the 'fun'. > >(4) Having 'fun (..) -> end' available means we don't have to > export things just so they can be called, and having > 'fun F/N' available means the same; exporting stuff we'd > rather not is no longer an issue. > >(5) If there is information in the surrounding clause that needs to > be passed in, one level of 'fun' to capture that seems to be > necessary, but it need not be the _whole_ of the computation; > you can hand the information off to something with a name and > a comment. > >I think we're now pretty much down to the "personal judgement" >level. > > > > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ok@REDACTED Mon Feb 15 06:54:44 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 15 Feb 2010 18:54:44 +1300 Subject: [erlang-questions] A style question In-Reply-To: References: Message-ID: <016380AA-E289-4643-977C-A3A45B811B64@cs.otago.ac.nz> On Feb 15, 2010, at 6:40 PM, Michael Turner wrote: > > Richard wrote: >> I think we're now pretty much down to the "personal judgement" >> level. > > In some ways, that's where it started. For example, you > characterized F > as "opaque". Fair enough, but it's at least allusive in the right > ways. It's about as helpful as calling a number N or an atom A. I don't know what "middle school" is, but you'll often find f, g, h used as function names, which only leaves 23 letters of the alphabet. I'm pretty sure I met that at high school. > > So when I read > > F = fun () -> .... > some_call (..., F, ...) > > the fact that it's F (and not, say, U or K) actually helps a bit. > After > all, the idea of passing functions to functions remains a little weird > after all these years. Fortran has allowed functions to be passed to functions for over fifty years. In my first programming classes, using Algol, we were shown procedures passed to procedures in about lesson 3. (Because it was a numerical analysis class, and integration is an N.A. topic.) > Code like the above makes me think, "Ah, that's right, some_call takes > a function in *that* argument position. The function in question has only one parameter. What's to be reminded of? And I fail to see how "F" is a better indication of function-ness than 'fun'. > > And, of course, the whole thing is easier to indent prettily. Not with decent tools. > > From leap@REDACTED Mon Feb 15 07:59:21 2010 From: leap@REDACTED (Michael Turner) Date: Mon, 15 Feb 2010 06:59:21 +0000 Subject: [erlang-questions] A style question In-Reply-To: <016380AA-E289-4643-977C-A3A45B811B64@cs.otago.ac.nz> Message-ID: I wrote: >> ... For example, you [Richard] characterized F >> as "opaque". Fair enough, but it's at least allusive in the right >> ways. Richard replied: >It's about as helpful as calling a number N or an atom A. In the case of N, at least, it actually *can* be a little helpful. Quick, which is idiomatic in C: for (n = 0; n < i; ++n) or for (i = 0; i < n; ++i) And why do you think your choice became the idiom? >I don't know what "middle school" is, but you'll often find >f, g, h used as function names, which only leaves 23 letters >of the alphabet. I'm pretty sure I met that at high school. About g and so on: I was attempting humor. Always a risky business. And I thought "middle school" was more universally understood by native English speakers than "junior high school." Clearly I'm wrong there. >Fortran has allowed functions to be passed to functions for over >fifty years..... Not the point. I discovered this fact about Fortran early on, and delighted in it. But passing of functions to functions is relatively infrequent in most non-lambda-supporting languages. I've met people who have been programming in C for years without learning how to write the declaration for pointer to function, and who were faintly in awe of me that I could do it with my eyes closed. >The function in question has only one parameter. >What's to be reminded of? And I fail to see how "F" is a better >indication of function-ness than 'fun'. I see it as better in some ways, worse in some others, and in certain repeated patterns, better for *some* people, if that's what they've gotten used to. So much so that they'll even use the pattern where it's less applicable, as when passing a function argument to a single-argument function. Look, in a sense, programming languages are a user-interface issue (the language is your interface to the processor-memory switch and ultimately to something happening at the level of electrons and holes in doped silicon crystal lattices). People's judgments of user interface issues often come down to what they think is "intuitive". Studies of what's intuitive in user interfaces have come up with a shrug: the intuitive is what's familiar to you, period. You write enough code with funs directly supplied as arguments, and look at enough code like that, and it's more familiar to you. So you think that's "intuitively obvious" way. But I'll probably have to write the keyword 'fun' in Erlang 500 more times before I'll fully quell my mind's natural impulse to read it as the English word "fun". It's a mild distraction, but a little bit of cognitive load each time. In some ways, I wish the designers of Erlang chosen "function", or even "lambda". I've been living in Japan almost 15 years, and I still do things wrong because I'm following intuitions developed from the 38 years before I came here to live. There's so much in almost everything we do that's little more than a matter of what we're used to seeing and doing. >> And, of course, the whole thing is easier to indent prettily. > >Not with decent tools. Not everyone has those, Richard. Just recently, there was a thread here about how Emacs gets it wrong. But most Erlang hackers use Emacs anyway, I bet. I use vim. Vim gets it wrong, too. But vim is basically vi, which is, well, intuitively obvious to me. Maybe I'm crippled by a whole adult lifetime of editing habits. (Maybe I can sue Bill Joy for damaging my productivity? I hear he has a lot of money.) -michael turner From raimo+erlang-questions@REDACTED Mon Feb 15 08:45:06 2010 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Mon, 15 Feb 2010 08:45:06 +0100 Subject: [erlang-questions] Jinterface and GCJ 4.4 In-Reply-To: References: Message-ID: <20100215074506.GA5691@erix.ericsson.se> On Sat, Feb 13, 2010 at 01:47:32PM +0300, Sergei Golovan wrote: > Hi! > > While trying to enable jinterface for Debian Erlang package I've tried > to build it using a few Java compilers available in Debian. What I've > found is that most of the compilers either build jinterface fine > (OpenJDK-6) or don't pass JDK 1.5 test in configure (GCJ-4.3 or > older). But GCJ 4.4 passes this test but fails to build jinterface > because it has String(int[], int, int) constructor unimplemented. I've > added an additional check for this to configure.in (see attachment) > but wonder which would be the correct long term solution. If it's the > only problem with GCJ then may be it'd be better not to use > String(int[], int, int) at all? We know of no actual problems with GJC. When stepping up the requirements for Jinterface to JDK 1.5 we just chose a configure test for a new feature in Sun JDK 1.5 that we started to use, and that is a new iterator syntax. We test here at OTP with Sun JDK and IBM Java and have not (yet) made an effort to try GJC, but if it supports the new iterator syntax perhaps someone should look into how much rewriting is needed to make Jinterface build by not using the String(int[], int, int) constructor. If Jinterface would build and run with GJC we should start testing it... > > Cheers! > -- > Sergei Golovan > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From leap@REDACTED Mon Feb 15 08:58:58 2010 From: leap@REDACTED (Michael Turner) Date: Mon, 15 Feb 2010 07:58:58 +0000 Subject: [erlang-questions] A style question In-Reply-To: Message-ID: <2uny0Zml.1266220738.7715470.leap@gol.com> Jayson wrote: >I've noticed that some people have gaps in their knowledge of > Erlang. "fun somefunc/N" seems to be one of them. Maybe in part because it's not easy to find? I'd been using Erlang funs for a while before needing fun f/n for something. To my surprise I found myself quite frustrated trying to determine that syntax. For a while, I even resorted to fun()->f(...) end as a workaround. I knew such a thing *had* to be possible in Erlang. But the syntax isn't covered in the index entries under "fun" in Armstrong's book, and there isn't even a freestanding index entry for "fun" in Cesarini & Thompson. I can't remember how I learned it finally. I guess I found it somewhere, or maybe it was just trial and error. It certainly wasn't from the reference manual http://ftp.sunet.se/pub/lang/erlang/doc/reference_manual/expressions.html#id2272623 where it's an inconspicous afterthought instead of being summarized upfront, right at the beginning. If I got there, I must have been turned back by what seemed like very categorical and exclusive language in the first paragraph: "A fun expression begins with the keyword fun and ends with the keyword end. Between them should be a function declaration, similar to a regular function declaration, except that no function name is specified." Even if you get to the entry for "fun expressions" in C&T (p.192), it seems their sense of the term "fun expression" is a fun that's nameless. Formally, I'd say that fun f/n is a fun expression, the simplest kind, in much the same sense that 1 is an arithmetic expression. Anybody who can't see 1 that way isn't cut out to be a progammer. Neither of the two books has an appendix for a semi-formal grammar of Erlang, in BNF style, nor does there seem to be such a thing in the reference manual. Need I say how important such touchstone material can be, as both reference and serendipitous learning resource, for seasoned programmers? I was an experienced programmer already when I took my first course requiring Pascal (1978?), so I just flipped to the appendix with the BNF, noted Pascal's differences from what I knew of Algol in about an afternoon, and was reasonably fluent in almost the entire language within days. I must have learned half of C by browsing the syntax summary in K&R, running across interesting cases, and thinking, "You can *say* that? Hm, let's see what it means." In the case of learning Erlang fun f/n, just having a syntax chart would have helped me find the syntax more quickly. Suggestion for tutorials: gently introduce funs using fun f/n *first*, then (quickly) bring in the fun () -> ... end syntax. Suggestion for new books and future editions of existing ones, and for the online reference manual: give people an appendix with the syntax of Erlang. Somebody who really knows Erlang internals might be able hack an auto-generator for a readable PDF within a day. (I wouldn't know, I've never strayed into the relevant parts of the compiler.) -michael turner On 2/15/2010, "Jayson Vantuyl" wrote: >With respect to exports (#4), I just tested it with R13B, it doesn't appear that you have to export a fun to reference it. Specifically, this works for me: > >> -module(u). >> -export ([test/0]). >> >> test() -> >> F = fun test2/0, >> F(). >> >> test2() -> >> ok. > >That said, I think point #5 is an important one, although maybe not for the reason you do. I've noticed that some people have gaps in their knowledge of Erlang. "fun somefunc/N" seems to be one of them. Capturing surrounding variables is another one. > >As for point #3, I don't know of many times I would consider "fun () -> ... end" to be anything but bulky. Then again, Ruby and Python may have me spoiled in that respect. Of course, that is definitely a matter of personal preference. > >On Feb 14, 2010, at 6:06 PM, Richard O'Keefe wrote: > >> >> On Feb 14, 2010, at 10:39 AM, Jayson Vantuyl wrote: >> >>> I've always felt that "fun some_func/2" is underused. >> >> It's a good thing to use _if_ you already have some_func/2 and >> don't need to pass it any arguments. >> >> We have agreement on a number of points. >> >> (1) If you introduce a name for a function that is passed to >> a higher order operation, it should be a meaningful name, >> not just "F" or "f" or anything like that. >> >> (2) If you already want to name a function for some other reason, >> use fun F/N to refer to it rather than fun (X,...) -> F(X,...) end. >> >> (3) If the code would be bulky, _something_ has to move out and >> it might as well be the 'fun'. >> >> (4) Having 'fun (..) -> end' available means we don't have to >> export things just so they can be called, and having >> 'fun F/N' available means the same; exporting stuff we'd >> rather not is no longer an issue. >> >> (5) If there is information in the surrounding clause that needs to >> be passed in, one level of 'fun' to capture that seems to be >> necessary, but it need not be the _whole_ of the computation; >> you can hand the information off to something with a name and >> a comment. >> >> I think we're now pretty much down to the "personal judgement" >> level. >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> > >-- >Jayson Vantuyl >kagato@REDACTED > > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From kaykay.unique@REDACTED Mon Feb 15 08:59:31 2010 From: kaykay.unique@REDACTED (Kay Kay) Date: Sun, 14 Feb 2010 23:59:31 -0800 Subject: file:read_line - conflicting return values' syntax - no case clause matching eof exception Message-ID: <4B78FEE3.5020903@gmail.com> As per the documentation here - http://ftp.sunet.se/pub/lang/erlang/doc/man/file.html#read_line-1 , the syntax reads as - read_line(IoDevice) -> {ok, Data} | eof | {error, Reason} Given the ambiguity in the return values of the function , I am unsure how to handle it. do_read_file(IoDevice, InData, Accum) -> case file:read_line(IoDevice) of {'ok', Data} -> do_read_file(IoDevice, Data, lists:append(Accum, InData)); { 'eof' } -> Accum end. I wrote this function to use the same, but I am getting - "** exception error: no case clause matching eof" . What is the best way to handle the same ? From erlangy@REDACTED Mon Feb 15 09:22:40 2010 From: erlangy@REDACTED (Michael McDaniel) Date: Mon, 15 Feb 2010 00:22:40 -0800 Subject: [erlang-questions] file:read_line - conflicting return values' syntax - no case clause matching eof exception In-Reply-To: <4B78FEE3.5020903@gmail.com> References: <4B78FEE3.5020903@gmail.com> Message-ID: <20100215082240.GB5805@delora.autosys.us> On Sun, Feb 14, 2010 at 11:59:31PM -0800, Kay Kay wrote: > As per the documentation here - > > http://ftp.sunet.se/pub/lang/erlang/doc/man/file.html#read_line-1 , > the syntax reads as - > > read_line(IoDevice) -> {ok, Data} | eof | {error, Reason} > > Given the ambiguity in the return values of the function , I am unsure > how to handle it. > > > > do_read_file(IoDevice, InData, Accum) -> > case file:read_line(IoDevice) of > {'ok', Data} -> > do_read_file(IoDevice, Data, lists:append(Accum, InData)); > { 'eof' } -> > Accum > end. > > > I wrote this function to use the same, but I am getting - "** exception > error: no case clause matching eof" . > > What is the best way to handle the same ? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Note that eof is not a tuple (which is the general case when using a single atom), so check the single atom eof in a clause case ... {ok, Data} -> ... eof -> ... {error, Err} -> ... end ~M > > From kostis@REDACTED Mon Feb 15 09:24:17 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Mon, 15 Feb 2010 10:24:17 +0200 Subject: [erlang-questions] file:read_line - conflicting return values' syntax - no case clause matching eof exception In-Reply-To: <4B78FEE3.5020903@gmail.com> References: <4B78FEE3.5020903@gmail.com> Message-ID: <4B7904B1.1060508@cs.ntua.gr> Kay Kay wrote: > As per the documentation here - > > http://ftp.sunet.se/pub/lang/erlang/doc/man/file.html#read_line-1 , > the syntax reads as - > > read_line(IoDevice) -> {ok, Data} | eof | {error, Reason} > > Given the ambiguity in the return values of the function , I am unsure > how to handle it. Ambiguity? Which ambiguity? The return values {ok, Data} and {error, Reason} are pairs (2-tuples) which are distinguished by a different atom in the 1st position. The third return value is an *atom*. Do not wrap it in { } and make it a one-element tuple instead... Kostis > do_read_file(IoDevice, InData, Accum) -> > case file:read_line(IoDevice) of > {'ok', Data} -> > do_read_file(IoDevice, Data, lists:append(Accum, InData)); > { 'eof' } -> > Accum > end. > > > I wrote this function to use the same, but I am getting - "** exception > error: no case clause matching eof" . > > What is the best way to handle the same ? From luismarianoguerra@REDACTED Mon Feb 15 11:06:01 2010 From: luismarianoguerra@REDACTED (Mariano Guerra) Date: Mon, 15 Feb 2010 11:06:01 +0100 Subject: [erlang-questions] A style question In-Reply-To: <2uny0Zml.1266220738.7715470.leap@gol.com> References: <2uny0Zml.1266220738.7715470.leap@gol.com> Message-ID: On Mon, Feb 15, 2010 at 8:58 AM, Michael Turner wrote: > Jayson wrote: > Neither of the two books has an appendix for a semi-formal grammar of > Erlang, in BNF style, nor does there seem to be such a thing in the > reference manual. ?Need I say how important such touchstone material can > be, as both reference and serendipitous learning resource, for seasoned > programmers? ?I was an experienced programmer already when I took my > first course requiring Pascal (1978?), so I just flipped to the appendix > with the BNF, noted Pascal's differences from what I knew of Algol in > about an afternoon, and was reasonably fluent in almost the entire > language within days. ?I must have learned half of C by browsing the > syntax summary in K&R, running across interesting cases, and thinking, > "You can *say* that? ?Hm, let's see what it means." ?In the case of > learning Erlang fun f/n, just having a syntax chart would have helped me > find the syntax more quickly. maybe this can help, i dont know if it is complte or up to date but it is a start. http://github.com/erlang/otp/blob/ba3758531a0b6dc6797457279e1ce0f99d282d20/lib/parsetools/src/esyntax.yrl From erlang@REDACTED Mon Feb 15 12:05:20 2010 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 15 Feb 2010 12:05:20 +0100 Subject: [erlang-questions] A style question In-Reply-To: <2DAC64391C8841E49F96643C47DBBD07@SSI.CORP> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <378EAA84-FB83-4E42-B547-A29A07C78D1B@cs.otago.ac.nz> <2DAC64391C8841E49F96643C47DBBD07@SSI.CORP> Message-ID: <9b08084c1002150305k35da61a9q511510bcdf22ea0e@mail.gmail.com> On Fri, Feb 12, 2010 at 4:02 PM, David Mercer wrote: >> But is this just prejudice on my part, or is there a reason why inserting >> an opaque name like "F" is a good idea? > > I might assign a value to a variable for documentation purposes. ?In this > specific example, though, the name "F" seems to fail as a description of > purpose, so it probably doesn't fall into that category. ?Suppose, however, > that it were something like > > ? ? ? ?UpdateTheFebblebrokker = fun() -> ... > ? ? ? ?Mnesia:transaction(UpdateTheFeeblebrokker) Oh no not another HorrendouslyLongVariableNameThatCluttersUpTheCodeSoCantSeeTheCode I started programming when punched cards had 80 columns. Long variable names would have made the cards lighter, by might need more cards, making it more difficult to transport the program from the punched card machines to the computer room. << then a mere four hour wait to see if your program compiled >> It was written in the scrolls, by the old ones, possible by the great Daniel D.McCracken himself, that I,J,K,N were always integers, R was real and so on. Having written about 100K lines of FORTRAN (blessed be it's memory) these rules are firmly etched into the base of my spine, wherefrom the control of my fingers eminates. In Erlang this is still true but F is always a function H and T are alway the head and tail of a list. and L something is always a list. T is not a tuple (of course, because it's the tail of a list, silly) I hate long variable name because they clutter up the code. So I use "abbreviated camel variables + comments" %% UTF = UpdateTheFebblerokker UTF = fun() -> ... Mnesia:transaction(UTF) "UpdateTheFebblerokker" has 21 characters. So the first version uses 2*21 (42) characters to communicate the name. The second version uses 21 + 3 * 3 (30) characters to communicate the name. So my version is 12/42 (29%) more abstract). The amount of work my brain has to do to understand this is 29% less. If you reused the name twice then the gain would be 3*21 :: 21 + 4*3 = 63::33 (48% more abstract) You'd also need a comment explain what a Febblerokker is. I think it's some kind of DoppleKlonkerSubWogiLuple but this is from memory, it's a long time since I worked with this kind of stuff. Cheers /Joe > > Then it might server as a form documentation, written with the optimistic > assumption that the compiler will optimize the assignment away. > >> The indentation style I would use here just takes 4 columns, not 12. > > I would love to hear about different indentation styles, and specifically > yours. ?I find properly indenting Erlang to be the most difficult part of > the language. > > Cheers, > > David > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ajuttner.list@REDACTED Mon Feb 15 12:20:09 2010 From: ajuttner.list@REDACTED (Alpar Juttner) Date: Mon, 15 Feb 2010 12:20:09 +0100 Subject: [erlang-questions] Re: reverse engineering beam files / obfuscation ? In-Reply-To: <08D49313-584D-469C-8242-5CA2B306ADCE@cs.otago.ac.nz> References: <4B750EE1.7010302@gmail.com> <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> <08D49313-584D-469C-8242-5CA2B306ADCE@cs.otago.ac.nz> Message-ID: <1266232809.3115.403.camel@piko.site> Sorry, but I can't understand the story. I understand that you had a secret idea implemented in Quintus, but it has never been published. Someone else was about to publish the same idea. They had a copy of Quintus but not the its source. You assumed the idea was taken from Quintus, thus you precluded them from publishing the idea. But could you _prove_ somehow that they stole the idea from Quintus or did you just suspect it? If it was just a suspicion, you'd better not be so proud of this story. In addition, review of a paper is normally done by an independent reviewer, who must handle the paper confidentially. How did you get a copy of the paper under review? Regards, Alpar On Mon, 2010-02-15 at 14:15 +1300, Richard O'Keefe wrote: > Quintus faced this issue many years ago now. > > There is _nothing_ you can do to stop a sufficiently determined > cracker. Here's an anecdote. > > (1) The Quintus emulator was shipped as an executable binary with > (a) most but not all of the C symbols stripped > (b) many but not all of the atoms used in the Prolog system > clobbered (things users were _supposed_ to be able to mention > were preserved, everything else smashed). > (c) we had a special in-house-ONLY tool for restoring the smashed > names. > (2) Full *and* demo versions of Quintus Prolog were handed out after the > purchaser signed a contract saying, amongst other things, that they > would not disassemble the system. > (3) One organisation that got a free demo copy of Quintus Prolog was a > large software company with a Prolog of their own. (Fair enough, > we had a demo copy of their system at one time.) > (4) They attempted to publish in a conference a paper detailing > implementation techniques that were used, to the best of our > knowledge, > only in Quintus Prolog. Judging from what some of the people > from that > company had said previously, they had not then been using these > techniques themselves. > (5) We informed the conference, and the paper was not published. > > The need to disassemble MC68020 instructions hadn't stopped them. > A contract saying they wouldn't reverse engineer hadn't stopped them. > > At least if it's in the contract the crackers will KNOW they are > doing something wrong, not just difficult. > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From hans.bolinder@REDACTED Mon Feb 15 13:05:25 2010 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 15 Feb 2010 13:05:25 +0100 Subject: [erlang-questions] erlc returns error with parameterized module having binary comprehension In-Reply-To: <3e28ae01002102355w533466d6pca0035f377425063@mail.gmail.com> References: <3e28ae01002102355w533466d6pca0035f377425063@mail.gmail.com> Message-ID: <19321.14469.966473.183653@ornendil.du.uab.ericsson.se> ["jebu@REDACTED" ]: > When compiling the attached file I get the following error > crash reason: {function_clause, > [{sys_expand_pmod,expr, > [{b_generate,5, It seems to be a bug in the compiler. We'll fix it in the upcoming release. Thanks for reporting the problem. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From masklinn@REDACTED Mon Feb 15 12:34:15 2010 From: masklinn@REDACTED (Masklinn) Date: Mon, 15 Feb 2010 12:34:15 +0100 Subject: [erlang-questions] A style question In-Reply-To: <9b08084c1002150305k35da61a9q511510bcdf22ea0e@mail.gmail.com> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <378EAA84-FB83-4E42-B547-A29A07C78D1B@cs.otago.ac.nz> <2DAC64391C8841E49F96643C47DBBD07@SSI.CORP> <9b08084c1002150305k35da61a9q511510bcdf22ea0e@mail.gmail.com> Message-ID: <07362BE3-99AB-47CD-9833-F08AD9D05322@masklinn.net> On 15 Feb 2010, at 12:05 , Joe Armstrong wrote: > > I hate long variable name because they clutter up the code. > So I use "abbreviated camel variables + comments" > > %% UTF = UpdateTheFebblerokker > UTF = fun() -> ... > Mnesia:transaction(UTF) > > "UpdateTheFebblerokker" has 21 characters. So the first version uses > 2*21 (42) characters to communicate the > name. > > The second version uses 21 + 3 * 3 (30) characters to communicate the name. > So my version is 12/42 (29%) more abstract). > > The amount of work my brain has to do to understand this is 29% less. > If you reused the name > twice then the gain would be 3*21 :: 21 + 4*3 = 63::33 (48% more abstract) Except in that case my brain would very likely understand the wrong thing. What "UTF" tells me is "Unicode Transformation Format", not "UpdateTheFeeblerokker". And I'd be left wondering what the hell the lambda has to do with unicode. Yeah unreadable names don't matter when you already know what they mean. In fact you should use the first 3 hex characters of the sha1 of the corresponding source code, it would be almost as unclear and wouldn't even require the effort of looking for 3 meaningless characters. C7D? Perfectly cromulent variable name, and just as abstract as your version. From kagato@REDACTED Mon Feb 15 14:01:12 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Mon, 15 Feb 2010 05:01:12 -0800 Subject: [erlang-questions] A style question In-Reply-To: <2uny0Zml.1266220738.7715470.leap@gol.com> References: <2uny0Zml.1266220738.7715470.leap@gol.com> Message-ID: <38698055-4DB8-44C6-A2E0-0B99639E2331@souja.net> While we're at it, there are tons of dusty corners that people miss. There's the occasionally useful but wholly unknown syntax for multiple clauses in an anonymous fun: F = fun (true) -> ok; (false) -> failed end. Or for that matter, using guards on anonymous funs (needed it once in an unusual list comprehension). Or all of the oddness you can do with binary pattern matching: <>. Or pattern matching using ++. Or matchspecs in general. Or the fiendishly undersupported bits like inet_res, binary comprehensions, parse tranforms, parameterized modules, -extends, etc. I like to believe that there will come a day that all of these things are documented clearly. Until then, I guess we'll have to document these things through cryptic rambling on the mailing list. :( Sent from my iPhone On Feb 14, 2010, at 11:58 PM, "Michael Turner" wrote: > Jayson wrote: >> I've noticed that some people have gaps in their knowledge of >> Erlang. "fun somefunc/N" seems to be one of them. > > Maybe in part because it's not easy to find? > > I'd been using Erlang funs for a while before needing fun f/n for > something. To my surprise I found myself quite frustrated trying to > determine that syntax. For a while, I even resorted to fun()->f(...) > end as a workaround. > > I knew such a thing *had* to be possible in Erlang. But the syntax > isn't covered in the index entries under "fun" in Armstrong's book, > and there isn't even a freestanding index entry for "fun" in Cesarini > & Thompson. I can't remember how I learned it finally. I guess I > found it somewhere, or maybe it was just trial and error. It > certainly > wasn't from the reference manual > > http://ftp.sunet.se/pub/lang/erlang/doc/reference_manual/expressions.html#id2272623 > > where it's an inconspicous afterthought instead of being summarized > upfront, right at the beginning. If I got there, I must have been > turned back by what seemed like very categorical and exclusive > language > in the first paragraph: > > "A fun expression begins with the keyword fun and ends with the > keyword > end. Between them should be a function declaration, similar to a > regular > function declaration, except that no function name is specified." > > Even if you get to the entry for "fun expressions" in C&T (p.192), it > seems their sense of the term "fun expression" is a fun that's > nameless. > > Formally, I'd say that > > fun f/n > > is a fun expression, the simplest kind, in much the same sense that > 1 is > an arithmetic expression. Anybody who can't see 1 that way isn't cut > out to be a progammer. > > Neither of the two books has an appendix for a semi-formal grammar of > Erlang, in BNF style, nor does there seem to be such a thing in the > reference manual. Need I say how important such touchstone material > can > be, as both reference and serendipitous learning resource, for > seasoned > programmers? I was an experienced programmer already when I took my > first course requiring Pascal (1978?), so I just flipped to the > appendix > with the BNF, noted Pascal's differences from what I knew of Algol in > about an afternoon, and was reasonably fluent in almost the entire > language within days. I must have learned half of C by browsing the > syntax summary in K&R, running across interesting cases, and thinking, > "You can *say* that? Hm, let's see what it means." In the case of > learning Erlang fun f/n, just having a syntax chart would have > helped me > find the syntax more quickly. > > > Suggestion for tutorials: gently introduce funs using fun f/n *first*, > then (quickly) bring in the fun () -> ... end syntax. > > Suggestion for new books and future editions of existing ones, and for > the online reference manual: give people an appendix with the syntax > of > Erlang. Somebody who really knows Erlang internals might be able hack > an auto-generator for a readable PDF within a day. (I wouldn't know, > I've never strayed into the relevant parts of the compiler.) > > -michael turner > > On 2/15/2010, "Jayson Vantuyl" wrote: > >> With respect to exports (#4), I just tested it with R13B, it >> doesn't appear that you have to export a fun to reference it. >> Specifically, this works for me: >> >>> -module(u). >>> -export ([test/0]). >>> >>> test() -> >>> F = fun test2/0, >>> F(). >>> >>> test2() -> >>> ok. >> >> That said, I think point #5 is an important one, although maybe not >> for the reason you do. I've noticed that some people have gaps in >> their knowledge of Erlang. "fun somefunc/N" seems to be one of >> them. Capturing surrounding variables is another one. >> >> As for point #3, I don't know of many times I would consider "fun >> () -> ... end" to be anything but bulky. Then again, Ruby and >> Python may have me spoiled in that respect. Of course, that is >> definitely a matter of personal preference. >> >> On Feb 14, 2010, at 6:06 PM, Richard O'Keefe wrote: >> >>> >>> On Feb 14, 2010, at 10:39 AM, Jayson Vantuyl wrote: >>> >>>> I've always felt that "fun some_func/2" is underused. >>> >>> It's a good thing to use _if_ you already have some_func/2 and >>> don't need to pass it any arguments. >>> >>> We have agreement on a number of points. >>> >>> (1) If you introduce a name for a function that is passed to >>> a higher order operation, it should be a meaningful name, >>> not just "F" or "f" or anything like that. >>> >>> (2) If you already want to name a function for some other reason, >>> use fun F/N to refer to it rather than fun (X,...) -> F(X,...) >>> end. >>> >>> (3) If the code would be bulky, _something_ has to move out and >>> it might as well be the 'fun'. >>> >>> (4) Having 'fun (..) -> end' available means we don't have to >>> export things just so they can be called, and having >>> 'fun F/N' available means the same; exporting stuff we'd >>> rather not is no longer an issue. >>> >>> (5) If there is information in the surrounding clause that needs to >>> be passed in, one level of 'fun' to capture that seems to be >>> necessary, but it need not be the _whole_ of the computation; >>> you can hand the information off to something with a name and >>> a comment. >>> >>> I think we're now pretty much down to the "personal judgement" >>> level. >>> >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >> >> -- >> Jayson Vantuyl >> kagato@REDACTED >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From gliptak@REDACTED Mon Feb 15 14:01:45 2010 From: gliptak@REDACTED (=?ISO-8859-1?B?R+Fib3IgTGlwdOFr?=) Date: Mon, 15 Feb 2010 08:01:45 -0500 Subject: [erlang-questions] Re: jinterface.jar in the Maven repository? In-Reply-To: <3c64b6c31002081747v53050be4qb17b432c5422c0b2@mail.gmail.com> References: <3c64b6c31002021752k3fe9564cnf94e2885ecaf44a9@mail.gmail.com> <20100205085519.GA29445@erix.ericsson.se> <3c64b6c31002051432q78abb48emafe623c67c3d02f9@mail.gmail.com> <944da41d1002060643y3c1f7754u3d22ff7e88d88963@mail.gmail.com> <3c64b6c31002081747v53050be4qb17b432c5422c0b2@mail.gmail.com> Message-ID: <3c64b6c31002150501k190ca392lbf40da62d82c8a32@mail.gmail.com> jinterface 1.5.2 is available in the Maven2 repo: http://repo2.maven.org/maven2/org/erlang/otp/jinterface/1.5.2/ On Mon, Feb 8, 2010 at 20:47, G?bor Lipt?k wrote: > I uploaded a snapshot to: > > http://oss.sonatype.org/content/repositories/snapshots/org/erlang/otp/jinterface/1.5.1-SNAPSHOT/ > > Waiting for project admins to learn how to proceed with a released version. > > On Sat, Feb 6, 2010 at 09:43, Alex Arnon wrote: >> >> +1 indeed!!! >> >> In my project ('jports' on Google Code, warning - Work In Progress :) ), I >> am forced to instruct the user to copy java_src directly to a jinterface >> artifact, due to the license. This is inconvenient and breaks the common >> expectation that a Maven project should be one-click-buildable anywhere. >> >> >> On Sat, Feb 6, 2010 at 7:10 AM, Jayson Vantuyl wrote: >> >> > +1 >> > >> > On Feb 5, 2010, at 2:32 PM, G?bor Lipt?k wrote: >> > >> > > In order to make Java/Erlang projects easier to develop and package, >> > > "official" jinterface.jar could be uploaded to Maven and uses as a >> > > dependency for Java builds. >> > > >> > > Here is a description on the process: >> > > >> > > https://docs.sonatype.com/display/NX/OSS+Repository+Hosting >> > > >> > > this would require participation from domain/project owners. I would >> > > be >> > > happy to facilitate the process and prepare Maven related artifacts >> > needed. >> > > >> > > Is there an interest in this? >> > > >> > > Thank you >> > >> > -- >> > Jayson Vantuyl >> > kagato@REDACTED >> > >> > >> > ________________________________________________________________ >> > erlang-questions (at) erlang.org mailing list. >> > See http://www.erlang.org/faq.html >> > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> > >> > > > From attila.r.nohl@REDACTED Mon Feb 15 14:14:13 2010 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 15 Feb 2010 14:14:13 +0100 Subject: [erlang-questions] A style question In-Reply-To: <38698055-4DB8-44C6-A2E0-0B99639E2331@souja.net> References: <2uny0Zml.1266220738.7715470.leap@gol.com> <38698055-4DB8-44C6-A2E0-0B99639E2331@souja.net> Message-ID: <401d3ba31002150514q1e388acfx9ba564a0c3e8d40b@mail.gmail.com> 2010/2/15, Jayson Vantuyl : > While we're at it, there are tons of dusty corners that people miss. > > There's the occasionally useful but wholly unknown syntax for multiple > clauses in an anonymous fun: > > F = fun > (true) -> ok; > (false) -> failed > end. This is damn useful for e.g. lists:filter()... [...] > Or pattern matching using ++. Or matchspecs in general. I always thought that given their highly cryptic syntax, matchspecs are not designed for human consumption. From rtrlists@REDACTED Mon Feb 15 14:19:36 2010 From: rtrlists@REDACTED (Robert Raschke) Date: Mon, 15 Feb 2010 13:19:36 +0000 Subject: [erlang-questions] A style question In-Reply-To: <38698055-4DB8-44C6-A2E0-0B99639E2331@souja.net> References: <2uny0Zml.1266220738.7715470.leap@gol.com> <38698055-4DB8-44C6-A2E0-0B99639E2331@souja.net> Message-ID: <6a3ae47e1002150519k3ae5b1e8nb4a79eafceaa7b67@mail.gmail.com> I'm not sure where you get your documentation from, but ... getting the below links took me about 10 minutes! On Mon, Feb 15, 2010 at 1:01 PM, Jayson Vantuyl wrote: > While we're at it, there are tons of dusty corners that people miss. > > There's the occasionally useful but wholly unknown syntax for multiple > clauses in an anonymous fun: > > F = fun > (true) -> ok; > (false) -> failed > end. > > http://www.erlang.org/doc/reference_manual/expressions.html#id2272623 > Or for that matter, using guards on anonymous funs (needed it once in an > unusual list comprehension). > > See same section above. > Or all of the oddness you can do with binary pattern matching: > <>. > > http://www.erlang.org/doc/reference_manual/expressions.html#id2272040 and http://www.erlang.org/doc/programming_examples/bit_syntax.html > Or pattern matching using ++. Or matchspecs in general. > http://www.erlang.org/doc/reference_manual/expressions.html#id2270161 and http://www.erlang.org/doc/apps/erts/match_spec.html > Or the fiendishly undersupported bits like inet_res, binary comprehensions, > parse tranforms, parameterized modules, -extends, etc. > > Binary comprehensions: http://www.erlang.org/doc/reference_manual/expressions.html#id2273560 > I like to believe that there will come a day that all of these things are > documented clearly. Until then, I guess we'll have to document these things > through cryptic rambling on the mailing list. :( > > Sent from my iPhone > > > From leap@REDACTED Mon Feb 15 14:36:13 2010 From: leap@REDACTED (Michael Turner) Date: Mon, 15 Feb 2010 13:36:13 +0000 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: Message-ID: >The reference to Guantanamo is, um, hyperbolic, to put it mildly. I plead guilty to Argument by Reference to Wikipedia. (A mitigating circumstance: I was once told by a friend that he'd heard Dijkstra say, haughtily, at a conference in Asilomar, "'Run a program'?! Why, I haven't *run* a program in years!" Well of course not. How silly. Why run programs when you can be proving them correct instead?) -michael turner On 2/15/2010, "Richard O'Keefe" wrote: > >On Feb 15, 2010, at 1:07 AM, Michael Turner wrote: > >> >> Could be worse, y'know. At least Erlang "if" guards are checked in >> the order written. Dijkstra introduced the term "guard" using if ... >> syntax as well, but if more than one guard was true, one of the >> guarded >> statements was selected "non-deterministically" -- at least if you >> believe Wikipedia. >> >> http://en.wikipedia.org/wiki/Guarded_Command_Language >> >> On the whole, I'd prefer the guards at Guantanamo. > >Dijkstra's guarded command language goes with a semantics and >a >>design method<< in which you write non-overlapping guards >unless you have >>demonstrated<< that in case of overlap it >really does not matter which statement you pick. > >The classic example is > if X <= Y -> Max := Y > [] Y <= X -> Max := X > fi >where >(a) if X = Y then it really does not matter which assignment you choose >(b) conventional practice introduces an entirely artificial > asymmetry between the two cases >(c) in more complicated cases, it is easier to reason about each > choice because, amongst other things, the condition under which > this choice is _explicit_, it's not "this and not that and not > the other and not some other thing". > >Like Erlang's 'if' and 'case', the execution of guards in Dijkstra's >notation is not allowed to have side effects. So you can't tell >what order the guards were tested in except in cases where you've >demonstrated that you don't care. > >The reference to Guantanamo is, um, hyperbolic, to put it mildly. > > From leap@REDACTED Mon Feb 15 14:58:40 2010 From: leap@REDACTED (Michael Turner) Date: Mon, 15 Feb 2010 13:58:40 +0000 Subject: [erlang-questions] A style question In-Reply-To: Message-ID: Thank you, Mariano. I've *read* that Erlang is a small language. (Viewed as a language, to be sure, not as a platform -- in which respect it's clearly industrial-strength and somewhat sprawling.) I was also starting to *feel* that Erlang was a small language. But now I can finally *see* that it's small. And that's encouraging. Nothing wrong with small. Most beautiful languages are small. -michael On 2/15/2010, "Mariano Guerra" wrote: >maybe this can help, i dont know if it is complte or up to date but it >is a start. > >http://github.com/erlang/otp/blob/ba3758531a0b6dc6797457279e1ce0f99d282d20/lib/parsetools/src/esyntax.yrl > From john.hughes@REDACTED Mon Feb 15 21:15:53 2010 From: john.hughes@REDACTED (John Hughes) Date: Mon, 15 Feb 2010 21:15:53 +0100 Subject: [erlang-questions] Re: reverse engineering beam files / obfuscation ? In-Reply-To: <4B76663D.4090009@gmail.com> References: <4B750EE1.7010302@gmail.com> <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> <4B76663D.4090009@gmail.com> Message-ID: <7E8419DC76B34F2CA44F32CC4D99B72C@JohnsTablet2009> Hi Kay, You need to be careful to turn off the Erlang trace facilities for your code, which can otherwise reveal your algorithms. This isn't trivial to do right, but neither is it impossible. John ----- Original Message ----- From: "Kay Kay" To: Sent: Saturday, February 13, 2010 9:43 AM Subject: Re: [erlang-questions] Re: reverse engineering beam files / obfuscation ? > Thanks everyone for replying to this thread. That comparison between the > JVM bytecodes and erlang beam-s is definitely comforting. But I was just > worried from an IP perspective entirely reverse engineered altogether. > > From a commercialization perspective , are there any licensing > restrictions to be aware , if there were a commercial app on top of the > Erlang system ? > > > On 02/12/2010 05:25 PM, Steve Davis wrote: >> Hi Kay, >> >> Just offering the thought that an effective obfuscation would be one >> where the effort required to decode it would be about equal to, or >> greater than, the effort required to write the code from scratch. >> >> Beam isn't easy if, as Chandru pointed out, you remove debug_info from >> the compile. Your code would be, I believe, considerably "safer" in >> Erlang than other bytecode-interpreted languages such as Java/C#. >> >> However, a long discussion about the value of open source could follow >> the above comments... but I digress. >> >> Regards, >> /s >> >> On Feb 12, 2:18 am, Kay Kay wrote: >> >>> If I were to release a commercial erlang based app , with compiled beam >>> files, would it be possible to reverse engineer it . If that were the >>> case - any possible suggestions to prevent / obfuscate the same. >>> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From kagato@REDACTED Mon Feb 15 23:01:49 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Mon, 15 Feb 2010 14:01:49 -0800 Subject: [erlang-questions] A style question In-Reply-To: <6a3ae47e1002150519k3ae5b1e8nb4a79eafceaa7b67@mail.gmail.com> References: <2uny0Zml.1266220738.7715470.leap@gol.com> <38698055-4DB8-44C6-A2E0-0B99639E2331@souja.net> <6a3ae47e1002150519k3ae5b1e8nb4a79eafceaa7b67@mail.gmail.com> Message-ID: Oh, you can get links. It's just that you need to know these things are there. The average person that dives into the docs doesn't always find these little corners. There are qualities of good documentation beyond mere existence. Sent from my iPhone On Feb 15, 2010, at 5:19 AM, Robert Raschke wrote: > I'm not sure where you get your documentation from, but ... getting > the > below links took me about 10 minutes! > > On Mon, Feb 15, 2010 at 1:01 PM, Jayson Vantuyl > wrote: > >> While we're at it, there are tons of dusty corners that people miss. >> >> There's the occasionally useful but wholly unknown syntax for >> multiple >> clauses in an anonymous fun: >> >> F = fun >> (true) -> ok; >> (false) -> failed >> end. >> >> http://www.erlang.org/doc/reference_manual/expressions.html#id2272623 > > > >> Or for that matter, using guards on anonymous funs (needed it once >> in an >> unusual list comprehension). >> >> See same section above. > > > >> Or all of the oddness you can do with binary pattern matching: >> <>. >> >> > http://www.erlang.org/doc/reference_manual/expressions.html#id2272040 > and > http://www.erlang.org/doc/programming_examples/bit_syntax.html > > > >> Or pattern matching using ++. Or matchspecs in general. >> > > http://www.erlang.org/doc/reference_manual/expressions.html#id2270161 > and > http://www.erlang.org/doc/apps/erts/match_spec.html > > > >> Or the fiendishly undersupported bits like inet_res, binary >> comprehensions, >> parse tranforms, parameterized modules, -extends, etc. >> >> > Binary comprehensions: > http://www.erlang.org/doc/reference_manual/expressions.html#id2273560 > > > >> I like to believe that there will come a day that all of these >> things are >> documented clearly. Until then, I guess we'll have to document >> these things >> through cryptic rambling on the mailing list. :( >> >> Sent from my iPhone >> >> >> From ok@REDACTED Tue Feb 16 00:21:12 2010 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 16 Feb 2010 12:21:12 +1300 Subject: [erlang-questions] file:read_line - conflicting return values' syntax - no case clause matching eof exception In-Reply-To: <4B78FEE3.5020903@gmail.com> References: <4B78FEE3.5020903@gmail.com> Message-ID: On Feb 15, 2010, at 8:59 PM, Kay Kay wrote: > As per the documentation here - > > http://ftp.sunet.se/pub/lang/erlang/doc/man/file.html#read_line-1 , > the syntax reads as - > > read_line(IoDevice) -> {ok, Data} | eof | {error, Reason} > > Given the ambiguity in the return values of the function , I am > unsure how to handle it. > What ambiguity? All goes well: you get {ok,Data}. Normal end of file: you get eof. Some problem: you get {error,Reason}. > > > do_read_file(IoDevice, InData, Accum) -> > case file:read_line(IoDevice) of > {'ok', Data} -> > do_read_file(IoDevice, Data, lists:append(Accum, InData)); > { 'eof' } -> --------- The description says eof, not {eof}. > > Accum > end. > > > I wrote this function to use the same, but I am getting - "** > exception error: no case clause matching eof" . > > What is the best way to handle the same ? By writing a pattern that matches eof, not {eof}. > > > From OK@REDACTED Tue Feb 16 03:44:00 2010 From: OK@REDACTED (Richard O'Keefe) Date: Tue, 16 Feb 2010 15:44:00 +1300 Subject: [erlang-questions] A style question In-Reply-To: <9b08084c1002150305k35da61a9q511510bcdf22ea0e@mail.gmail.com> References: <0DC4E6FE-3676-4BD9-B568-2265DF0CDBF7@CS.OTAGO.AC.NZ> <378EAA84-FB83-4E42-B547-A29A07C78D1B@cs.otago.ac.nz> <2DAC64391C8841E49F96643C47DBBD07@SSI.CORP> <9b08084c1002150305k35da61a9q511510bcdf22ea0e@mail.gmail.com> Message-ID: On Feb 16, 2010, at 12:05 AM, Joe Armstrong wrote: > It was written in the scrolls, by the old ones, possible by the great > Daniel D.McCracken himself, > that I,J,K,N were always integers, R was real and so on. The classic Fortran "INteger letters" rule: if it begins with I-N it's integer, A-H or O-Z it's real (=float), and if you want any other type you must declare it. I knew a generation of programmers who were scarred by IBM 1130 Fortran, which restricted identifiers to 5 letters+digits. > > Having written about 100K lines of FORTRAN (blessed be it's memory) Fortran is alive and well, and contains a fairly clean "structured programming" sublanguage. It's quite a decent language for writing number-crunching code. > I hate long variable name because they clutter up the code. > So I use "abbreviated camel variables + comments" > > %% UTF = UpdateTheFebblerokker > UTF = fun() -> ... > Mnesia:transaction(UTF) > > "UpdateTheFebblerokker" has 21 characters. So the first version uses > 2*21 (42) characters to communicate the > name. > > The second version uses 21 + 3 * 3 (30) characters to communicate > the name. > So my version is 12/42 (29%) more abstract). If we use the inline version with a comment, mnesia:transaction(fun () -> % Update the febblerokker ... end it's even more concise. And there is no acronym puzzle for the reader to solve. (Doesn't UTF mean "Unicode Transmission Format" or something? Did I read that right or was it a reference to UHT milk or UFOs?) Do you read UTF aloud as you-tee-eff or, to avoid confusion, do you read it aloud as update-the-febblerokker? When someone else reads the comment, do they not go looking for the binding of UpdateTheFebblerokker to find out what it is that the comment is saying UTF is equal to? I would! > > You'd also need a comment explain what a Febblerokker is. I think it's > some kind of > DoppleKlonkerSubWogiLuple but this is from memory, it's a long time > since I worked with this kind of > stuff. You have not explained why this is an an improvement on the inline style, which allows a comment of whatever length you require, in grammatical (choose your natural language here) with references as needed, and _doesn't_ introduce PFTHRTS. (Puzzles For The Hapless Reader To Solve.) Let's try a concrete example, from the Erlang/OTP sources. mnesia_open({table_exist,Name},_Nodes,_RecName,_Attr,_Type,clear) -> ?vtrace("[mnesia] database ~p already exists; clear content", [Name]), Pattern = '_', F = fun() -> Recs = mnesia:match_object(Name,Pattern,read), lists:foreach(fun(Rec) -> mnesia:delete_object(Name,Rec,write) end, Recs), Recs end, case mnesia:transaction(F) of {aborted,Reason} -> exit({aborted,Reason}); {atomic,_} -> {mnesia,Name} end; Try it another way: mnesia_open({table_exist,Name}, _Nodes, _Record, _Attr, _Type, clear) -> ?vtrace("[mnesia] database ~p already exists; clear content", [Name]), case mnesia:transaction(fun () -> %% find all records in table Name and delete them. Recs = mnesia:match_object(Name, '_', read), _ = [mnesia:delete_object(Name, Rec, write) || Rec <- Recs], Recs end of {aborted,Reason} -> exit({aborted,Reason}) ; {atomic,_} -> {mnesia,Name} end. (I'm so ignorant about Mnesia that I'd have used mnesia:clear_table(Name) to empty out a table.) What have we lost by eliminating the name "F"? After all, no such name was used in the call to lists:foreach/2, where due to the unfortunate argument order of lists:foreach/2, it would have been useful. In fact for me, having the fun in place suddenly made it possible for me to see that there was no point in having it return Recs. So now I can write it as mnesia_open({table_exist,Name}, _Nodes, _Record, _Attr, _Type, clear) -> ?vtrace("[mnesia] database ~p already exists; clear content", [Name]), case mnesia:transaction(fun () -> %% find all records in table Name and delete them. Recs = mnesia:match_object(Name, '_', read), _ = [mnesia:delete_object(Name, Rec, write) || Rec <- Recs], ok % THIS LINE CHANGED end of {aborted,Reason} -> exit({aborted,Reason}) ; {atomic,_} -> {mnesia,Name} end. Previously I found that hard to see because the 'fun' and the mnesia:transaction were *disconnnected*. From ok@REDACTED Tue Feb 16 03:56:16 2010 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 16 Feb 2010 15:56:16 +1300 Subject: [erlang-questions] Re: reverse engineering beam files / obfuscation ? In-Reply-To: <1266232809.3115.403.camel@piko.site> References: <4B750EE1.7010302@gmail.com> <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> <08D49313-584D-469C-8242-5CA2B306ADCE@cs.otago.ac.nz> <1266232809.3115.403.camel@piko.site> Message-ID: On Feb 16, 2010, at 12:20 AM, Alpar Juttner wrote: > Sorry, but I can't understand the story. We got the paper because as the then experts on the WAM, we were sent a copy for review. When we communicated our suspicions, the big company in question did not protest, did not challenge our suspicions, but backed down in a hurry. What would you think? It was not a matter of *one* idea, but of about six. They might well have reinvented one of them, but all six? Nor was this the first time that someone had stolen intellectual property from people associated with Quintus. Large chunks of C Prolog were stolen, contrary to the licence, by a European company and incorporated in their product. I was the (then) independent assessor who demonstrated the fact of the theft beyond reasonable doubt. > But could you _prove_ somehow that they stole the idea from Quintus or > did you just suspect it? If it was just a suspicion, you'd better > not be > so proud of this story. We could have proved it to the ordinary standard of proof for a civil case, but given the very nasty legal experience Edinburgh had with the first lot of thieves, and the fact that the thieves this time had much bigger pockets than us, we didn't choose to go that route. We simply said, "all of these ideas are in our product, none of them has appeared in print before, you had a copy of our product, show reason to believe that you invented them independently." And they did not even try. What would *you* think? In any case, who said I or anyone else was PROUD of the story? It happened? I'm ASHAMED that we were so scared of the legal system that we didn't take stronger action. > > In addition, review of a paper is normally done by an independent > reviewer, who must handle the paper confidentially. How did you get a > copy of the paper under review? Why are you so keen to blame the victims? From ok@REDACTED Tue Feb 16 05:08:44 2010 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 16 Feb 2010 17:08:44 +1300 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: References: Message-ID: On Feb 16, 2010, at 2:36 AM, Michael Turner wrote: > >> The reference to Guantanamo is, um, hyperbolic, to put it mildly. > > I plead guilty to Argument by Reference to Wikipedia. > > (A mitigating circumstance: I was once told by a friend that he'd > heard > Dijkstra say, haughtily, at a conference in Asilomar, "'Run a > program'?! Why, I haven't *run* a program in years!" Well of course > not. How silly. Why run programs when you can be proving them > correct > instead?) Let's see, you have a second-hand report of *part* of a conversation, and you base your judgement on that? What had the other person said to him? What was the conversation about? How do you know that the next sentence wasn't "I've often had a computer carry out my plan" or something of the sort? I've just been reading an article in CACM which is simultaneously inspiring and deeply saddening. The article is about Coverity. The inspiring part is that they've built a wonderful tool for checking C code. The deeply saddening part is the refusal of many people to believe that their grossly nonstandard code is anything but perfectly legal C. One example sticks in my mind: int a[2], b; /* context: sizeof (int) is 4. */ memset(a, 0, 12); Coverity pointed out the bug. The customer said "no no, your tool is broken, I *meant* that because a and b are side by side." The fact that the C standard explicitly denies any relationship between the addresses of a and b, and that there have been (and for all I know may still be) compilers that sorted globals, putting the small ones first so it had a fighting chance of being able to address most of them with a single register, which compilers would have guaranteed that a and b were NOT adjacent, all of this was of no importance to the customer. He had RUN his program, you see, so he KNEW it was right. If you want to quote Dijkstra, quote this: I would therefore like to posit that computing's central challenge, "How not to make a mess of it," has not been met. On the contrary, most of our systems are much more complicated than can be considered healthy, and are too messy and chaotic to be used in comfort and confidence. The average customer of the computing industry has been served so poorly that he expects his system to crash all the time, and we witness a massive worldwide distribution of bug-ridden software for which we should be deeply ashamed. By the way, this doesn't contradict Armstrong's "Let it crash" dictum. Joe is talking about _components_ hidden inside a system crashing. Erlang *systems* aren't supposed to crash, which is why Francesco Cesarini and Simon Thompson stress early on in their wonderful book that processes should be watched by some other process. Whether Dijkstra personally ever ran a program or not (and he devised the implementation techniques at the heart of Java), his _notation_ deserves a reasoned responds on its own merits for what it is, not what it might be imagined to be. From als@REDACTED Tue Feb 16 11:19:46 2010 From: als@REDACTED (Anthony Shipman) Date: Tue, 16 Feb 2010 21:19:46 +1100 Subject: [erlang-questions] A style question In-Reply-To: References: <2uny0Zml.1266220738.7715470.leap@gol.com> <6a3ae47e1002150519k3ae5b1e8nb4a79eafceaa7b67@mail.gmail.com> Message-ID: <201002162119.46397.als@iinet.net.au> On Tue, 16 Feb 2010 09:01:49 am Jayson Vantuyl wrote: > Oh, you can get links. ?It's just that you need to know these things ? > are there. The average person that dives into the docs doesn't always ? > find these little corners. ?There are qualities of good documentation ? > beyond mere existence. I find it useful to read through the reference manual first before diving anywhere. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From leap@REDACTED Tue Feb 16 11:27:22 2010 From: leap@REDACTED (Michael Turner) Date: Tue, 16 Feb 2010 10:27:22 +0000 Subject: syntax summary as documentation key (was re style) In-Reply-To: Message-ID: On 2/15/2010, "Jayson Vantuyl" wrote: >... The average person that dives into the docs doesn't always >find these little corners. There are qualities of good documentation >beyond mere existence. Indeed. Not to harp on a recent point, but this is why I like having an appendix for a syntax summary. It's not the Lives of the Saints in all their gory detail, but it does give you line-of-sight to all the stations of the cross. (To use a metaphor that probably falls flat if you've seldom been inside a Catholic church.) In the ranking of "table of contents", "index", and "syntax summary", I'd say "syntax summary" runs a close third behind "index"-- though it's almost useless without an index in which every almost every grammar symbol, terminal and non-terminal, is listed. (Talking about books here; hyperlinking can do the job, too, of course.) -michael From thomasl_erlang@REDACTED Tue Feb 16 10:29:16 2010 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 16 Feb 2010 01:29:16 -0800 (PST) Subject: [erlang-questions] Re: reverse engineering beam files / obfuscation ? In-Reply-To: <1266232809.3115.403.camel@piko.site> References: <4B750EE1.7010302@gmail.com> <8cba9e2e-5865-4be8-8a1f-9085964c8929@h2g2000yqj.googlegroups.com> <08D49313-584D-469C-8242-5CA2B306ADCE@cs.otago.ac.nz> <1266232809.3115.403.camel@piko.site> Message-ID: <445780.77480.qm@web111404.mail.gq1.yahoo.com> ----- Original Message ---- > From: Alpar Juttner > > In addition, review of a paper is normally done by an independent > reviewer, who must handle the paper confidentially. How did you get a > copy of the paper under review? In some fields, the pond isn't that large. In my experience, papers are usually reviewed by one's competitors. What other real experts in the topic are there? Best, Thomas From leap@REDACTED Tue Feb 16 11:54:25 2010 From: leap@REDACTED (Michael Turner) Date: Tue, 16 Feb 2010 10:54:25 +0000 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: Message-ID: > He had RUN his program, you see, so he KNEW it was right. Richard, look, I've run across the same mentality - it was while porting some C code, where my boss said it had worked on a couple other platforms, so stop foot-dragging, Michael and move on. In a meeting with five other people. But I knew C and its limits, I knew a bad stack crash zone when I saw one, and I can smell bogus assumptions about C type sizes and alignments from 50 paces. That code got fixed. We couldn't ship without it working. He lost some face over it. It's not formal correctness VERSUS Real Man Programmers with Grease on Their Hands. I think the problem is that formal correctness got oversold on unrealistic merits alone, and after the dashed expectations, nobody got in there and sold a practical and credible bill of goods with more modest goals. I mean, look at Peter Deutsch -- his dissertation was about the Stanford Pascal Verifier, but he ended up being sort of anti-formalism about programming by the mid-1970s, and the exodus continued long after his departure. He loved programming. The formal correctness people didn't give him much to help him love it even more. Quite the contrary, at that point. So he moved on. (And his advisor? I think contributing to the SPV with Deutsch was the last thing Richard Karp did in programming language semantics. He had a good nose for where you can get results.) Things don't happen in the real world until somebody makes the sale. And if you screw up the first sale, especially in technology, it can be a lo-o-ong time before the idea has a second chance. The friend of mine I quoted earlier sold his boss on the idea of letting him go to that Asilomar conference co-starring Edsger Dijkstra by arguing that knowledge of formal semantics and tools would help their company be competitive. He came back without any tools to recommend and with a dislike of most of what he saw there, especially the attitudes. I'm sure you're experienced with the phenomenon of something in computer science being oversold on unproven merits. You mention Prolog quite a lot, for one thing. Hey, don't get me wrong, I've got nothing against Prolog. The only reason I'm not elbows-deep into ECLiPSe right now is that Erlang soaks up most of the time I have available for hacking. But you know what happened. -michael On 2/16/2010, "Richard O'Keefe" wrote: > >On Feb 16, 2010, at 2:36 AM, Michael Turner wrote: > >> >>> The reference to Guantanamo is, um, hyperbolic, to put it mildly. >> >> I plead guilty to Argument by Reference to Wikipedia. >> >> (A mitigating circumstance: I was once told by a friend that he'd >> heard >> Dijkstra say, haughtily, at a conference in Asilomar, "'Run a >> program'?! Why, I haven't *run* a program in years!" Well of course >> not. How silly. Why run programs when you can be proving them >> correct >> instead?) > >Let's see, you have a second-hand report of *part* of a conversation, >and you base your judgement on that? What had the other person said >to him? What was the conversation about? How do you know that the >next sentence wasn't "I've often had a computer carry out my plan" >or something of the sort? > >I've just been reading an article in CACM which is simultaneously >inspiring and deeply saddening. The article is about Coverity. >The inspiring part is that they've built a wonderful tool for >checking C code. The deeply saddening part is the refusal of many >people to believe that their grossly nonstandard code is anything >but perfectly legal C. One example sticks in my mind: > > int a[2], b; > /* context: sizeof (int) is 4. */ > memset(a, 0, 12); > >Coverity pointed out the bug. The customer said "no no, your tool >is broken, I *meant* that because a and b are side by side." >The fact that the C standard explicitly denies any relationship >between the addresses of a and b, and that there have been (and >for all I know may still be) compilers that sorted globals, >putting the small ones first so it had a fighting chance of >being able to address most of them with a single register, which >compilers would have guaranteed that a and b were NOT adjacent, >all of this was of no importance to the customer. > >He had RUN his program, you see, so he KNEW it was right. > >If you want to quote Dijkstra, quote this: > > I would therefore like to posit that computing's > central challenge, "How not to make a mess of it," > has not been met. On the contrary, most of our > systems are much more complicated than can be > considered healthy, and are too messy and chaotic > to be used in comfort and confidence. The average > customer of the computing industry has been served > so poorly that he expects his system to crash all > the time, and we witness a massive worldwide > distribution of bug-ridden software for which we > should be deeply ashamed. >By the way, this doesn't contradict Armstrong's "Let it crash" >dictum. Joe is talking about _components_ hidden inside a >system crashing. Erlang *systems* aren't supposed to crash, >which is why Francesco Cesarini and Simon Thompson stress >early on in their wonderful book that processes should be >watched by some other process. > >Whether Dijkstra personally ever ran a program or not (and he >devised the implementation techniques at the heart of Java), >his _notation_ deserves a reasoned responds on its own merits >for what it is, not what it might be imagined to be. > > > From leap@REDACTED Tue Feb 16 12:07:13 2010 From: leap@REDACTED (Michael Turner) Date: Tue, 16 Feb 2010 11:07:13 +0000 Subject: a style question In-Reply-To: <201002162119.46397.als@iinet.net.au> Message-ID: On 2/16/2010, "Anthony Shipman" wrote: [snip] >I find it useful to read through the reference manual first before diving >anywhere. Reference manuals are typically huge, Erlang/OTP's is no exception, and we don't all have photographic memories and the patience of Job. There's a reason why, for four decades now, I've been hearing "Don't try to learn ___ from *that* book -- it's a *reference* manual." There's something to be said for reading the *summaries* of each *chapter* of reference manuals, I'll give you that. In fact, doing something like that is what sold me on trying out Erlang in the first place. But retention, not to speak of comprehension and usefulness, is quite another thing. -michael turner From leap@REDACTED Tue Feb 16 12:18:15 2010 From: leap@REDACTED (Michael Turner) Date: Tue, 16 Feb 2010 11:18:15 +0000 Subject: [erlang-questions] Re: reverse engineering beam files / obfuscation ? In-Reply-To: <445780.77480.qm@web111404.mail.gq1.yahoo.com> Message-ID: <9zg8nISi.1266319095.6641780.leap@gol.com> On 2/16/2010, "Thomas Lindgren" wrote: >In some fields, the pond isn't that large. In my experience, >papers are usually reviewed by one's competitors. By the same token, in some specialties it's often by one's close buddies. A friend of mine used to talk about "getting published in beer-reviewed journals." He got tenure at Columbia in part by not doing it too much. (He didn't like beer, as I remember. A professional handicap that he's managed to overcome somehow.) -michael turner On 2/16/2010, "Thomas Lindgren" wrote: > > > > >----- Original Message ---- >> From: Alpar Juttner >> >> In addition, review of a paper is normally done by an independent >> reviewer, who must handle the paper confidentially. How did you get a >> copy of the paper under review? > > >In some fields, the pond isn't that large. In my experience, papers are usually reviewed by one's competitors. What other real experts in the topic are there? > >Best, >Thomas > > > > > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From kagato@REDACTED Tue Feb 16 12:34:45 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Tue, 16 Feb 2010 03:34:45 -0800 Subject: Missing The Point Of Documentation In-Reply-To: <201002162119.46397.als@iinet.net.au> References: <2uny0Zml.1266220738.7715470.leap@gol.com> <6a3ae47e1002150519k3ae5b1e8nb4a79eafceaa7b67@mail.gmail.com> <201002162119.46397.als@iinet.net.au> Message-ID: <5AEF5681-83E1-4380-8D0A-244741194909@souja.net> Unless I'm grossly misreading your intent, I think that your response indicates the exact opposite to what you intended. You seem to suggest that the reference manual is where people should start. This is dead wrong. Most people (even many good programmers) are not this way. Documentation is just like user interface. The best examples never put completeness before usability. This is the reason that each Erlang application has a Users Guide (for usability), and a Reference (for completeness). A fundamental problem with the Erlang docs is that they are very much organized in a way that fits the invisible architecture underlying the system, as opposed to being a helpful framework for communicating the intent of the design. Someone has already noted the misleading language about anonymous funs that obscures the later reference to using the fun keyword to reference a non-anonymous function. That's how this thread got started. The issue is deeper, though. Consider the information necessary to divine the relationship between erts, kernel, stdlib, sasl, proc_lib, gen_*, and everything else. This is jumbled throughout a few guides and references in a way that is wholly incomprehensible to a novice. Perhaps Erlang users (and FP users in general) are self-selecting to be more "reference manual" oriented. I'm like this. I love nothing more than to go into wizard mode and pore over references until I understand the arcane secrets of a technology. I just know that we can do better. Go read the docs for Python and Django. They're better, by a longshot. Heck, compare the oldest docs on erlang.org to the newest ones. The direction to go is clear. So, I'll take your smarmy RTFM, and raise you a STFU. The whole point is that learning some of this is harder than it needs to be. I don't care if the information exists, it needs to be easier to get. Impeding the cry for better documentation is a bad idea. Don't be that guy. See Wheaton's Law. Sent from my iPhone On Feb 16, 2010, at 2:19 AM, Anthony Shipman wrote: > On Tue, 16 Feb 2010 09:01:49 am Jayson Vantuyl wrote: >> Oh, you can get links. It's just that you need to know these things >> are there. The average person that dives into the docs doesn't always >> find these little corners. There are qualities of good documentation >> beyond mere existence. > > I find it useful to read through the reference manual first before > diving > anywhere. > > -- > Anthony Shipman Mamas don't let your babies > als@REDACTED grow up to be outsourced. > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From attila.r.nohl@REDACTED Tue Feb 16 12:47:10 2010 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 16 Feb 2010 12:47:10 +0100 Subject: [erlang-questions] Re: a style question In-Reply-To: References: <201002162119.46397.als@iinet.net.au> Message-ID: <401d3ba31002160347m558cb840pbaccdf1e71096db3@mail.gmail.com> 2010/2/16, Michael Turner : > > > On 2/16/2010, "Anthony Shipman" wrote: > > [snip] >>I find it useful to read through the reference manual first before diving >>anywhere. > > Reference manuals are typically huge, Erlang/OTP's is no exception, Somehow my problem with the Erlang reference manual was always that it's not huge enough. I mean, pattern matching is a very important part of the language, but the pattern matching chapter contains five lines of text plus six lines of example at http://www.erlang.org/doc/reference_manual/patterns.html. Helpfully it contains links to the patterns expressions, but I think that a lot more example would be really useful. From leap@REDACTED Tue Feb 16 13:49:27 2010 From: leap@REDACTED (Michael Turner) Date: Tue, 16 Feb 2010 12:49:27 +0000 Subject: various documentation topics now In-Reply-To: <401d3ba31002160347m558cb840pbaccdf1e71096db3@mail.gmail.com> Message-ID: On 2/16/2010, "Attila Rajmund Nohl" wrote: >2010/2/16, Michael Turner : >> Reference manuals are typically huge, Erlang/OTP's is no exception, > >Somehow my problem with the Erlang reference manual was always that >it's not huge enough. [snip] I'm reminded of the anecdote about the film editor who somehow made a "director's cut" release more interesting -- and thus *seem* shorter -- than the original theater release, by adding some cuts back in and rearranging things a little, actually increasing the running time by 20 minutes in the process. But whatever we do, let's not blame the fine folk at Ericsson. The documentation has only been up at github for little while now. And Erlang obviously has a lot more Europe penetration than in the (native) English speaking world, aside from being a small minority programming language anyway. So there's a shortage of people who can really fix it up nicely on a volunteer basis, and probably not much internal financing for the job within Ericsson. I know that I should spend less time on this list and more on contributing documentation patches -- typo fixes first, then more detailed contributions as my knowledge of Erlang improves and people at Ericsson trust that I can improve things. Every day, I see something. Apart from that, well ... what Jayson said. (But, um, terrestrially rather than ballistically.) He's right. Good docs are an important gateway to a language. Erlang has taken an odd path to open source, one that perhaps means that a lot of somewhat undercooked draft documentation has tumbled out into public view. And it's been a relatively small and localized community, making documentation not quite so important for a while. I mean, I can't believe I'm on a mailing list where a few co-architects of the language are fairly regular contributors. It's like back when you'd get Dennis Ritchie (in person!) copping to having screwed up bitfields on comp.lang.c in the early 80s. I like it. You probably do too. But you have to admit, ultimately, Erlang won't succeed without a education/communications strategy as scalable as the language itself. Better reference materials will be an absolutely essential part of that story. -michael turner From dale@REDACTED Tue Feb 16 14:10:58 2010 From: dale@REDACTED (Dale Harvey) Date: Tue, 16 Feb 2010 13:10:58 +0000 Subject: [erlang-questions] Re: various documentation topics now In-Reply-To: References: <401d3ba31002160347m558cb840pbaccdf1e71096db3@mail.gmail.com> Message-ID: I think the community has done pretty well with learning tools, we have http://learnyousomeerlang.com/ http://erlangforsceptics.com/book/ http://erldocs.com/R13B03/ http://www.trapexit.org/ http://erlangquicktips.heroku.com/ A few of us are in the middle of building a site that organises these resources. Along with plenty of people blogging about erlang (dukes of erl etc), I think we are doing pretty well. There are still lots of gaps around this information, a lot of the otp and application stuff can still be mystical, but the gap is getting filled up. and the books do a great job of more comprehensive learning Dale On 16 February 2010 12:49, Michael Turner wrote: > > On 2/16/2010, "Attila Rajmund Nohl" wrote: > > >2010/2/16, Michael Turner : > > >> Reference manuals are typically huge, Erlang/OTP's is no exception, > > > >Somehow my problem with the Erlang reference manual was always that > >it's not huge enough. > [snip] > > I'm reminded of the anecdote about the film editor who somehow made a > "director's cut" release more interesting -- and thus *seem* shorter > -- than the original theater release, by adding some cuts back in and > rearranging things a little, actually increasing the running time by 20 > minutes in the process. > > But whatever we do, let's not blame the fine folk at Ericsson. The > documentation has only been up at github for little while now. And > Erlang obviously has a lot more Europe penetration than in the (native) > English speaking world, aside from being a small minority programming > language anyway. So there's a shortage of people who can really fix it > up nicely on a volunteer basis, and probably not much internal financing > for the job within Ericsson. > > I know that I should spend less time on this list and more on > contributing documentation patches -- typo fixes first, then more > detailed contributions as my knowledge of Erlang improves and people at > Ericsson trust that I can improve things. Every day, I see something. > > Apart from that, well ... what Jayson said. (But, um, terrestrially > rather than ballistically.) He's right. Good docs are an important > gateway to a language. Erlang has taken an odd path to open source, one > that perhaps means that a lot of somewhat undercooked draft > documentation has tumbled out into public view. And it's been a > relatively small and localized community, making documentation not quite > so important for a while. I mean, I can't believe I'm on a mailing > list where a few co-architects of the language are fairly regular > contributors. It's like back when you'd get Dennis Ritchie (in > person!) copping to having screwed up bitfields on comp.lang.c in the > early 80s. I like it. You probably do too. But you have to admit, > ultimately, Erlang won't succeed without a education/communications > strategy as scalable as the language itself. Better reference materials > will be an absolutely essential part of that story. > > -michael turner > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From leap@REDACTED Tue Feb 16 15:39:02 2010 From: leap@REDACTED (Michael Turner) Date: Tue, 16 Feb 2010 14:39:02 +0000 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: Message-ID: On 2/16/2010, "Tony Finch" wrote: >On Tue, 16 Feb 2010, Michael Turner wrote: >> >> It's not formal correctness VERSUS Real Man Programmers with Grease on >> Their Hands. I think the problem is that formal correctness got >> oversold on unrealistic merits alone, and after the dashed expectations, >> nobody got in there and sold a practical and credible bill of goods with >> more modest goals. > >The state of the art has come along way since those days, and Coverity is >a state of the art static checker. Before dismissing Richard's complaints, >go and read the litany of stupidity they have suffered from their >customers. > >http://cacm.acm.org/magazines/2010/2/69354-a-few-billion-lines-of-code-later/fulltext I'm not sure how you interpreted what I wrote as "dismissing Richard's complaints" (if that's what you intended by the above), but at the halfway point of the above essay, I'm certainly mystified by your "litany of stupidity" comment about Coverity's users. Yes, the account you point me to shows that they were dealing at times with some very junior people or insular programming cultures or overmanaged hierarchies with staffers feeling like powerless, disaffected nodes. But if you've spent time at any significant number of companies (one of the few benefits of an otherwise tattered resume like mine), you'll find worse. (Just in case any of you are wondering why I don't program professionally anymore.) They also describe themselves (*twice*) as "naive" in their product planning strategy and marketing, in the introductory section, and confess that a bug in their system -- as basic as parsing filesystem paths -- did caused the execution of an "rm -rf *" on one customer's system. To the extent that it's an indictment, it's not so much pointing at the stupdity of Coverity customers as the sloppiness (or perhaps spinelessness) of compiler vendors, who you'd think would know better.[*] Though of course, the paranoia of the customer's lawyers also gets its due. [**] With humility like this, Edsger Dijkstra might have made a much more serious dent, in his time. So I find myself impressed not so much by any advances in "the state of the art" here as by the pragmatism of the authors. There's no snooty, "well, if people only used *my* formally-gem-like programming language with its implicit methodology, things would be *so* much better." Real life isn't about some utopian Point Z. It's about getting from Point A to Point B, only to realize you might have it all wrong about Point C. [***] I think if there's a lesson from Coverity's experience at all, it's that, with a little more humility and practicality on the part of the programming language semantics community back in the 1970s, the business value of what they were talking about might have been appreciated early on, and the kind of thing Coverity does would be a lot easier, both to write and to use. As it was, by early 80s, I found couldn't talk about ideas like limiting the semantics of special purpose languages for applications like VLSI CAD to make it easier to develop formally "correct by construction" designs without noticing everybody in the room cringing. (At least at UC Berkeley.) -michael turner [*] Sample line: "Unfortunately, the creativity of compiler writers means that despite two decades of work [on the Edison Design Group (EDG) C/C++ front-end], EDG still regularly meets defeat when trying to parse real-world large code bases." [**] Read starting from "Can we get customer source code? Almost always, no." [***] See, for example, the early history of Erlang. From leap@REDACTED Tue Feb 16 15:57:10 2010 From: leap@REDACTED (Michael Turner) Date: Tue, 16 Feb 2010 14:57:10 +0000 Subject: [erlang-questions] Re: various documentation topics now In-Reply-To: Message-ID: On 2/16/2010, "Dale Harvey" wrote: >I think the community has done pretty well with learning tools, we have [snip] True, but a bit of non sequiter for this discussion, which is mainly about Ericsson Official at this point. And that's a target that all of the sources you mention will need to track from release to release. Tutorials necessarily scratch the surface, or at least they don't dig very deep, and when you really get going you need to dig deep sometimes. It's nice that there's a lot of introductory material now, but diversity of sources spreads effort thinly sometimes, where concentration might be better. Trapexit? Yeah, well, maybe I had a bad initial experience: I got all excited about the pretty diagrams for the neural network example ostensibly worked through there. When I tried to do it, I found that it wasn't even finished, was missing parts of the code. Contacting the author got me nowhere. Asking on this list got me nowhere. That's time out of my life I can't get back. It makes Erlang look cool, I suppose, to feature a neural network developed in a fairly polished tutorial style. But certain kinds of intellectual lip-gloss are hardly better than intentional deception. I reported the problem, but nobody bothered to even take the page down. Maybe I should have done it. -michael turner >On 16 February 2010 12:49, Michael Turner wrote: > >> >> On 2/16/2010, "Attila Rajmund Nohl" wrote: >> >> >2010/2/16, Michael Turner : >> >> >> Reference manuals are typically huge, Erlang/OTP's is no exception, >> > >> >Somehow my problem with the Erlang reference manual was always that >> >it's not huge enough. >> [snip] >> >> I'm reminded of the anecdote about the film editor who somehow made a >> "director's cut" release more interesting -- and thus *seem* shorter >> -- than the original theater release, by adding some cuts back in and >> rearranging things a little, actually increasing the running time by 20 >> minutes in the process. >> >> But whatever we do, let's not blame the fine folk at Ericsson. The >> documentation has only been up at github for little while now. And >> Erlang obviously has a lot more Europe penetration than in the (native) >> English speaking world, aside from being a small minority programming >> language anyway. So there's a shortage of people who can really fix it >> up nicely on a volunteer basis, and probably not much internal financing >> for the job within Ericsson. >> >> I know that I should spend less time on this list and more on >> contributing documentation patches -- typo fixes first, then more >> detailed contributions as my knowledge of Erlang improves and people at >> Ericsson trust that I can improve things. Every day, I see something. >> >> Apart from that, well ... what Jayson said. (But, um, terrestrially >> rather than ballistically.) He's right. Good docs are an important >> gateway to a language. Erlang has taken an odd path to open source, one >> that perhaps means that a lot of somewhat undercooked draft >> documentation has tumbled out into public view. And it's been a >> relatively small and localized community, making documentation not quite >> so important for a while. I mean, I can't believe I'm on a mailing >> list where a few co-architects of the language are fairly regular >> contributors. It's like back when you'd get Dennis Ritchie (in >> person!) copping to having screwed up bitfields on comp.lang.c in the >> early 80s. I like it. You probably do too. But you have to admit, >> ultimately, Erlang won't succeed without a education/communications >> strategy as scalable as the language itself. Better reference materials >> will be an absolutely essential part of that story. >> >> -michael turner >> >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > > From setori88@REDACTED Tue Feb 16 16:00:12 2010 From: setori88@REDACTED (stewart) Date: Tue, 16 Feb 2010 07:00:12 -0800 (PST) Subject: custom behaviour Message-ID: Dear all I would like to create a custom erlang behaviour ------------------ gen_gist.erl --------------- -module(gen_gist). -export([behaviour_info/1]). behaviour_info(callbacks) -> [{foo,0}]; behaviour_info(_Other) -> undefined. -----------------end gen_gist.erl ------------- ----------------- rtree.erl ------------------- -module(rtree). -behaviour(gen_gist). -export([foo/0]). foo() -> ok. ---------------- end rtree.erl --------------- now when i run (rebar) i get : "src/rtree.erl:2: Warning: behaviour gen_gist undefined" I have tried doing "erlc rtree.erl -pa ." but still to no avail. Please help. Kind regards Stewart From dizzyd@REDACTED Tue Feb 16 16:08:32 2010 From: dizzyd@REDACTED (Dave Smith) Date: Tue, 16 Feb 2010 08:08:32 -0700 Subject: [erlang-questions] custom behaviour In-Reply-To: References: Message-ID: Sorry I wasn't clearer on twitter. If the behaviour is in the same directory as the dependent modules add this to your rebar.config: {erl_first_files, ["src/gen_gist.erl"]}. That will ensure that gen_gist is compiled first and available in the ebin/ path. D. On Tue, Feb 16, 2010 at 8:00 AM, stewart wrote: > Dear all > > I would like to create a custom erlang behaviour > > ------------------ gen_gist.erl --------------- > -module(gen_gist). > > -export([behaviour_info/1]). > > behaviour_info(callbacks) -> > ? ?[{foo,0}]; > behaviour_info(_Other) -> > ? ?undefined. > > -----------------end gen_gist.erl ------------- > > ----------------- rtree.erl ------------------- > -module(rtree). > -behaviour(gen_gist). > > -export([foo/0]). > > foo() -> > ? ?ok. > ---------------- end rtree.erl --------------- > now when i run (rebar) i get : > "src/rtree.erl:2: Warning: behaviour gen_gist undefined" > > I have tried doing "erlc rtree.erl -pa ." but still to no avail. > > Please help. > > Kind regards > Stewart > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From vinoski@REDACTED Tue Feb 16 16:08:52 2010 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 16 Feb 2010 10:08:52 -0500 Subject: [erlang-questions] custom behaviour In-Reply-To: References: Message-ID: <65b2728e1002160708u19d7ed2dhb0edf802ed3ca426@mail.gmail.com> On Tue, Feb 16, 2010 at 10:00 AM, stewart wrote: > Dear all > > I would like to create a custom erlang behaviour > > ------------------ gen_gist.erl --------------- > -module(gen_gist). > > -export([behaviour_info/1]). > > behaviour_info(callbacks) -> > [{foo,0}]; > behaviour_info(_Other) -> > undefined. > > -----------------end gen_gist.erl ------------- > > ----------------- rtree.erl ------------------- > -module(rtree). > -behaviour(gen_gist). > > -export([foo/0]). > > foo() -> > ok. > ---------------- end rtree.erl --------------- > now when i run (rebar) i get : > "src/rtree.erl:2: Warning: behaviour gen_gist undefined" > > I have tried doing "erlc rtree.erl -pa ." but still to no avail. > You're almost on the right path, no pun intended. :-) Your -pa option needs to point to where the beam file for the gen_gist behavior is located, not to where the source file is located. --steve From setori88@REDACTED Tue Feb 16 16:48:40 2010 From: setori88@REDACTED (stewart mackenzie) Date: Tue, 16 Feb 2010 15:48:40 +0000 Subject: [erlang-questions] custom behaviour In-Reply-To: <65b2728e1002160708u19d7ed2dhb0edf802ed3ca426@mail.gmail.com> References: <65b2728e1002160708u19d7ed2dhb0edf802ed3ca426@mail.gmail.com> Message-ID: Steve that worked! (with a sharp sounding slap to the forehead) but Dizzy, this is what my rebar.config file looks like: {erl_first_files,["src/gen_gist.erl"]}. {erl_opts, [debug_info, fail_on_warning]}. and I still get the warning. src/rtree.erl:2: Warning: behaviour gen_gist undefined make: *** [all] Error 1 * the behaviour is in the same directory as the dependent module. * i used rebar to create the otp standard file structure for the project thanks for your responsive help. Ill have a look at rebar src to see if there is a bug on thursday Stewart From thomasl_erlang@REDACTED Tue Feb 16 16:06:04 2010 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Tue, 16 Feb 2010 07:06:04 -0800 (PST) Subject: [erlang-questions] Re: reverse engineering beam files / obfuscation ? In-Reply-To: <9zg8nISi.1266319095.6641780.leap@gol.com> References: <9zg8nISi.1266319095.6641780.leap@gol.com> Message-ID: <82854.47618.qm@web111409.mail.gq1.yahoo.com> ----- Original Message ---- > From: Michael Turner > > On 2/16/2010, "Thomas Lindgren" wrote: > >In some fields, the pond isn't that large. In my experience, > >papers are usually reviewed by one's competitors. > > By the same token, in some specialties it's often by one's close > buddies. A friend of mine used to talk about "getting published in > beer-reviewed journals." He got tenure at Columbia in part by not > doing it too much. (He didn't like beer, as I remember. A > professional handicap that he's managed to overcome somehow.) Ah yes, I'm afraid I mostly saw the antagonistic part at that time and in that field (logic programming, as it happens). But you can see why it's sometimes fairly natural that competitors end up reviewing each other's work? Best, Thomas From hknight555@REDACTED Tue Feb 16 18:55:06 2010 From: hknight555@REDACTED (Hank Knight) Date: Tue, 16 Feb 2010 13:55:06 -0400 Subject: Distributed File System Powered by Erlang Message-ID: Imagine the power of a distributed file system powered by Erlang. Something like GlusterFS or The Google File System but build on Erlang. Has this been done? What would the performance implications be? Regards, Hank From sarvar.muminov@REDACTED Tue Feb 16 19:13:08 2010 From: sarvar.muminov@REDACTED (Sarvar Muminov) Date: Tue, 16 Feb 2010 13:13:08 -0500 Subject: need some help with erlang Message-ID: <374b57571002161013u58edc8a1n4fddb51d57526def@mail.gmail.com> I wrote this small db emulator to store the data in a hash. I used "write" function to write data to the hash. But when I try to add some data with key, value, It didn't work. I suppose I made some mistake in the code, but I can't figure out the problem :) -module(db_server). -export([start/0, init/1, write/2, read/1]). start() -> register(server, spawn(db_server, init, [dict:new()])). init(Records) -> receive {add, Key, Value} -> dict:store(Key, Value, Records), {ok, Key, Value}; {show, Key} -> case dict:find(Key, Records) of {ok, Value} -> Value; error -> {error, no_such_value} end; {delete, Key} -> dict:erase(Key, Records), ok end, init(Records). write(Key, Value) -> server ! {add, Key, Value}. read(Key) -> server ! {show, Key}. From dale@REDACTED Tue Feb 16 19:39:47 2010 From: dale@REDACTED (Dale Harvey) Date: Tue, 16 Feb 2010 18:39:47 +0000 Subject: [erlang-questions] need some help with erlang In-Reply-To: <374b57571002161013u58edc8a1n4fddb51d57526def@mail.gmail.com> References: <374b57571002161013u58edc8a1n4fddb51d57526def@mail.gmail.com> Message-ID: a few things wrong with this On 16 February 2010 18:13, Sarvar Muminov wrote: > I wrote this small db emulator to store the data in a hash. > I used "write" function to write data to the hash. But when I try to add > some data with key, value, It didn't work. > I suppose I made some mistake in the code, but I can't figure out the > problem :) > > -module(db_server). > > -export([start/0, init/1, write/2, read/1]). > > start() -> > register(server, spawn(db_server, init, [dict:new()])). > > init(Records) -> > receive > {add, Key, Value} -> > dict:store(Key, Value, Records), > {ok, Key, Value}; > {show, Key} -> > When you compile you should get warning that a term is constructed and never used, you arent doing anything with it, you can io:format it out, typically you would send the server your own pid with self() so it can send the value back > case dict:find(Key, Records) of > {ok, Value} -> Value; > error -> {error, no_such_value} > end; > {delete, Key} -> > dict:erase(Key, Records), > ok > end, > You are calling the loop function with the same variable it as passed in, which was dict:new(), so it will always be a new (empty) dict, when you modify the dict you need to call it with the new version > init(Records). > > write(Key, Value) -> > server ! {add, Key, Value}. > > read(Key) -> > server ! {show, Key}. > From wde@REDACTED Tue Feb 16 19:42:14 2010 From: wde@REDACTED (wde) Date: Tue, 16 Feb 2010 19:42:14 +0100 Subject: [erlang-questions] need some help with erlang Message-ID: <20100216184218.02B1870000B0@msfrf2322.sfr.fr> a simple example : -module(db_server). -export([start/0, init/1, write/2, read/1]). start() -> register(server, spawn(db_server, init, [dict:new()])). init(Records) -> receive {From,{add, Key, Value}} -> NewRecords = dict:store(Key, Value, Records), From ! {self(),{ok, Key, Value}}, init(NewRecords); {From,{show, Key} }-> Resp = case dict:find(Key, Records) of {ok, Value} -> Value; error -> {error, no_such_value} end, From ! {self(),Resp}, init(Records); {From,{delete, Key}} -> NewRecords = dict:erase(Key, Records), From ! {self(),ok}, init(NewRecords) end. write(Key, Value) -> server ! {self(),{add, Key, Value}}, receive {_From,Msg} -> Msg after 2000 -> ok end. read(Key) -> server ! {self(),{show, Key}}, receive {_From,Msg} -> Msg after 2000 -> ok end. >I wrote this small db emulator to store the data in a hash. >I used "write" function to write data to the hash. But when I try to add >some data with key, value, It didn't work. >I suppose I made some mistake in the code, but I can't figure out the >problem :) > >-module(db_server). > >-export([start/0, init/1, write/2, read/1]). > >start() -> > register(server, spawn(db_server, init, [dict:new()])). > >init(Records) -> > receive > {add, Key, Value} -> > dict:store(Key, Value, Records), > {ok, Key, Value}; > {show, Key} -> > case dict:find(Key, Records) of > {ok, Value} -> Value; > error -> {error, no_such_value} > end; > {delete, Key} -> > dict:erase(Key, Records), > ok > end, > init(Records). > >write(Key, Value) -> > server ! {add, Key, Value}. > >read(Key) -> > server ! {show, Key}. > From doug.fort@REDACTED Tue Feb 16 19:43:42 2010 From: doug.fort@REDACTED (Doug Fort) Date: Tue, 16 Feb 2010 13:43:42 -0500 Subject: [erlang-questions] need some help with erlang In-Reply-To: <374b57571002161013u58edc8a1n4fddb51d57526def@mail.gmail.com> References: <374b57571002161013u58edc8a1n4fddb51d57526def@mail.gmail.com> Message-ID: <5db086ad1002161043h24273c8y63ed28cf249db3dc@mail.gmail.com> On Tue, Feb 16, 2010 at 1:13 PM, Sarvar Muminov wrote: > I wrote this small db emulator to store the data in a hash. > I used "write" function to write data to the hash. But when I try to add > some data with key, value, It didn't work. > I suppose I made some mistake in the code, but I can't figure out the > problem :) > > -module(db_server). > > -export([start/0, init/1, write/2, read/1]). > > start() -> > ? ?register(server, spawn(db_server, init, [dict:new()])). > > init(Records) -> > ? ?receive > ? ? ? ?{add, Key, Value} -> > ? ? ? ? ? ?dict:store(Key, Value, Records), > ? ? ? ? ? ?{ok, Key, Value}; > ? ? ? ?{show, Key} -> > ? ? ? ? ? ?case dict:find(Key, Records) of > ? ? ? ? ? ? ? ?{ok, Value} -> Value; > ? ? ? ? ? ? ? ?error -> {error, no_such_value} > ? ? ? ? ? ?end; > ? ? ? ?{delete, Key} -> > ? ? ? ? ? ?dict:erase(Key, Records), > ? ? ? ? ? ?ok > ? ?end, > ? ?init(Records). > > write(Key, Value) -> > ? ?server ! {add, Key, Value}. > > read(Key) -> > ? ?server ! {show, Key}. > Hi Sarvar, You are discovering a key point of functional programming. Immutability. dict:new() does not create an object as java or python would. It creates an immutable data structure. When you call dict:store(Key, Value, Records), the return value is a new instance of the data structure. The data structure 'Records' has not been changed. So you need to do something like Records1 = dict:store(Key, Value, Records), and then pass Records1 to init on you next loop. -- Doug Fort, Consulting Programmer http://www.dougfort.com From dawid.figiel@REDACTED Tue Feb 16 19:48:18 2010 From: dawid.figiel@REDACTED (Dawid Figiel) Date: Tue, 16 Feb 2010 18:48:18 +0000 (GMT) Subject: [erlang-questions] need some help with erlang In-Reply-To: Message-ID: <63041131.40501266346098379.JavaMail.root@zimbra> ----- Original Message ----- From: "Dale Harvey" To: "Sarvar Muminov" Cc: erlang-questions@REDACTED Sent: Tuesday, February 16, 2010 6:39:47 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: [erlang-questions] need some help with erlang a few things wrong with this On 16 February 2010 18:13, Sarvar Muminov wrote: > I wrote this small db emulator to store the data in a hash. > I used "write" function to write data to the hash. But when I try to add > some data with key, value, It didn't work. > I suppose I made some mistake in the code, but I can't figure out the > problem :) > > -module(db_server). > > -export([start/0, init/1, write/2, read/1]). > > start() -> > register(server, spawn(db_server, init, [dict:new()])). > > init(Records) -> > receive > {add, Key, Value} -> > dict:store(Key, Value, Records), > {ok, Key, Value}; > {show, Key} -> > When you compile you should get warning that a term is constructed and never used, you arent doing anything with it, you can io:format it out, typically you would send the server your own pid with self() so it can send the value back > case dict:find(Key, Records) of > {ok, Value} -> Value; > error -> {error, no_such_value} > end; > {delete, Key} -> > dict:erase(Key, Records), > ok > end, > You are calling the loop function with the same variable it as passed in, which was dict:new(), so it will always be a new (empty) dict, when you modify the dict you need to call it with the new version > init(Records). > > write(Key, Value) -> > server ! {add, Key, Value}. > > read(Key) -> > server ! {show, Key}. > Hi Dale:) I have fixed your example, see below: -module(db_server). -export([start/0, init/1, write/2, read/1, delete/1]). start() -> register(server, spawn(db_server, init, [dict:new()])). init(Records) -> receive {add, Pid, Key, Value} -> RecordsNew = dict:store(Key, Value, Records), Pid ! {ok, Key, Value}, init(RecordsNew); {show, Pid, Key} -> case dict:find(Key, Records) of {ok, Value} -> Pid ! {ok, Value}; error -> Pid ! {error, no_such_value} end, init(Records); {delete, Pid, Key} -> RecordsNew = dict:erase(Key, Records), Pid ! {ok, ok}, init(RecordsNew) end. write(Key, Value) -> server ! {add, self(), Key, Value}, receive Res -> Res end. read(Key) -> server ! {show, self(), Key}, receive Res -> Res end. delete(Key) -> server ! {delete, self(), Key}, receive Res -> Res end. Remember also that the return value is always the last value in the function. In the previous version it was i.e {add, Key, Value} Very nice example to understand basic in erlang:) -- best, Dawid Figiel From dawid.figiel@REDACTED Tue Feb 16 19:55:43 2010 From: dawid.figiel@REDACTED (Dawid Figiel) Date: Tue, 16 Feb 2010 18:55:43 +0000 (GMT) Subject: [erlang-questions] need some help with erlang In-Reply-To: <63041131.40501266346098379.JavaMail.root@zimbra> Message-ID: <1144716947.40621266346543956.JavaMail.root@zimbra> ----- Original Message ----- From: "Dawid Figiel" To: "Dale Harvey" Cc: erlang-questions@REDACTED, "Sarvar Muminov" Sent: Tuesday, February 16, 2010 6:48:18 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: [erlang-questions] need some help with erlang ----- Original Message ----- From: "Dale Harvey" To: "Sarvar Muminov" Cc: erlang-questions@REDACTED Sent: Tuesday, February 16, 2010 6:39:47 PM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: [erlang-questions] need some help with erlang a few things wrong with this On 16 February 2010 18:13, Sarvar Muminov wrote: > I wrote this small db emulator to store the data in a hash. > I used "write" function to write data to the hash. But when I try to add > some data with key, value, It didn't work. > I suppose I made some mistake in the code, but I can't figure out the > problem :) > > -module(db_server). > > -export([start/0, init/1, write/2, read/1]). > > start() -> > register(server, spawn(db_server, init, [dict:new()])). > > init(Records) -> > receive > {add, Key, Value} -> > dict:store(Key, Value, Records), > {ok, Key, Value}; > {show, Key} -> > When you compile you should get warning that a term is constructed and never used, you arent doing anything with it, you can io:format it out, typically you would send the server your own pid with self() so it can send the value back > case dict:find(Key, Records) of > {ok, Value} -> Value; > error -> {error, no_such_value} > end; > {delete, Key} -> > dict:erase(Key, Records), > ok > end, > You are calling the loop function with the same variable it as passed in, which was dict:new(), so it will always be a new (empty) dict, when you modify the dict you need to call it with the new version > init(Records). > > write(Key, Value) -> > server ! {add, Key, Value}. > > read(Key) -> > server ! {show, Key}. > Hi Dale:) I have fixed your example, see below: -module(db_server). -export([start/0, init/1, write/2, read/1, delete/1]). start() -> register(server, spawn(db_server, init, [dict:new()])). init(Records) -> receive {add, Pid, Key, Value} -> RecordsNew = dict:store(Key, Value, Records), Pid ! {ok, Key, Value}, init(RecordsNew); {show, Pid, Key} -> case dict:find(Key, Records) of {ok, Value} -> Pid ! {ok, Value}; error -> Pid ! {error, no_such_value} end, init(Records); {delete, Pid, Key} -> RecordsNew = dict:erase(Key, Records), Pid ! {ok, ok}, init(RecordsNew) end. write(Key, Value) -> server ! {add, self(), Key, Value}, receive Res -> Res end. read(Key) -> server ! {show, self(), Key}, receive Res -> Res end. delete(Key) -> server ! {delete, self(), Key}, receive Res -> Res end. Remember also that the return value is always the last value in the function. In the previous version it was i.e {add, Key, Value} Very nice example to understand basic in erlang:) -- best, Dawid Figiel Sorry I was answering Sarvar, not Dale ;) But regards to all. -- best, Dawid Figiel www.erlang-solutions.com From daveb@REDACTED Tue Feb 16 21:22:41 2010 From: daveb@REDACTED (Dave Bryson) Date: Tue, 16 Feb 2010 14:22:41 -0600 Subject: Erlang WebSocket Client Message-ID: <4804C7FC-B8B6-4E02-964E-EB203FB4A9AA@miceda.org> For those interested in WebSockets, I've implemented a pure Erlang WebSocket client for calling WebSocket enabled servers from your Erlang code. You can find more info here: http://github.com/davebryson/erlang_websocket/blob/master/README.textile The code defines a 'websocket_client' behaviour you implement to create your client. The behaviour is designed to follow the WebSocket API. Dave From clist@REDACTED Tue Feb 16 22:50:37 2010 From: clist@REDACTED (Angel) Date: Tue, 16 Feb 2010 22:50:37 +0100 Subject: [erlang-questions] Distributed File System Powered by Erlang In-Reply-To: References: Message-ID: <201002162250.37437.clist@uah.es> On Martes, 16 de Febrero de 2010 18:55:06 Hank Knight escribi?: > Imagine the power of a distributed file system powered by Erlang. > Something like GlusterFS or The Google File System but build on > Erlang. Has this been done? What would the performance implications > be? Ive been playing with glusterfs and hacked a bit some modules. Clearly async dispatching becomes a bit messed up in C and whereas most access to data and filesystem ops use pointers i think average times are dominated by network latencies, so in this case erlang could be a win and more manageable than glusterfs will ever be. Ive considering a erlang server for glusterfs replicating module by module every xlator that glusterfs has, but i have not spare time by now. tehere are several FUSE/erlang projects on github, so experimetation is not hard. A fuse frontend to scalaris or a dynamo alike is very interesting... /angel > > Regards, > Hank > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > Most people know C is not so high level.... ...Everybody else just got assembler overdose From dizzyd@REDACTED Tue Feb 16 23:19:10 2010 From: dizzyd@REDACTED (Dave Smith) Date: Tue, 16 Feb 2010 15:19:10 -0700 Subject: [erlang-questions] custom behaviour In-Reply-To: References: <65b2728e1002160708u19d7ed2dhb0edf802ed3ca426@mail.gmail.com> Message-ID: There was a bug in rebar. This is now fixed and should function as expected. You can either rebuild from source or download the pre-built binary at: http://bitbucket.org/basho/rebar/downloads/rebar Thanks for the simplified test case. :) D. On Tue, Feb 16, 2010 at 8:48 AM, stewart mackenzie wrote: > Steve that worked! (with a sharp sounding slap to the forehead) > but Dizzy, this is what my rebar.config file looks like: > {erl_first_files,["src/gen_gist.erl"]}. > {erl_opts, [debug_info, fail_on_warning]}. > and I still get the warning. > src/rtree.erl:2: Warning: behaviour gen_gist undefined > make: *** [all] Error 1 > * the behaviour is in the same directory as the dependent module. > * i used rebar to create the otp standard file structure for the project > thanks for your responsive help. > Ill have a look at rebar src to see if there is a bug on thursday > Stewart > From ishwar@REDACTED Tue Feb 16 23:36:35 2010 From: ishwar@REDACTED (Ish Rattan) Date: Tue, 16 Feb 2010 17:36:35 -0500 (EST) Subject: Simple question?? Message-ID: The follwoing modules: -module(t1). -export([print_it/1]). print_it(N) -> Fac = fac(N), io:format("fac of ~p is ~p~n", [N, Fac]). fac(1) -> 1; fac(N) -> N*fac(N-1). when executed as: t1:print_it(5). produces: ** exception error: undefined function t1:prin_it/1 What is the reason? -ishwar From dale@REDACTED Tue Feb 16 23:48:27 2010 From: dale@REDACTED (Dale Harvey) Date: Tue, 16 Feb 2010 22:48:27 +0000 Subject: [erlang-questions] Simple question?? In-Reply-To: References: Message-ID: On 16 February 2010 22:36, Ish Rattan wrote: > The follwoing modules: > > -module(t1). > -export([print_it/1]). > > print_it(N) -> > Fac = fac(N), > io:format("fac of ~p is ~p~n", [N, Fac]). > > fac(1) -> 1; > fac(N) -> N*fac(N-1). > > when executed as: > t1:print_it(5). > produces: > ** exception error: undefined function t1:prin_it/1 > > you typed t1:prin_it(9) in the shell instead of t1:print_it(9) > What is the reason? > > -ishwar > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ishwar@REDACTED Tue Feb 16 23:47:01 2010 From: ishwar@REDACTED (Ish Rattan) Date: Tue, 16 Feb 2010 17:47:01 -0500 (EST) Subject: [erlang-questions] Simple question?? In-Reply-To: References: Message-ID: On Tue, 16 Feb 2010, Dale Harvey wrote: > On 16 February 2010 22:36, Ish Rattan wrote: > > you typed t1:prin_it(9) in the shell instead of t1:print_it(9) > Egg is on my face :-( Thanks for taking the time (I did stare at it for some time). -ishwar From tony@REDACTED Wed Feb 17 00:02:16 2010 From: tony@REDACTED (Tony Arcieri) Date: Tue, 16 Feb 2010 16:02:16 -0700 Subject: [erlang-questions] Distributed File System Powered by Erlang In-Reply-To: References: Message-ID: I'd like to see an Erlang implementation of Tahoe LAFS: http://allmydata.org/trac/tahoe-lafs On Tue, Feb 16, 2010 at 10:55 AM, Hank Knight wrote: > Imagine the power of a distributed file system powered by Erlang. > Something like GlusterFS or The Google File System but build on > Erlang. Has this been done? What would the performance implications > be? > > Regards, > Hank > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > -- Tony Arcieri Medioh! A Kudelski Brand From ok@REDACTED Wed Feb 17 03:14:07 2010 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 17 Feb 2010 15:14:07 +1300 Subject: [erlang-questions] illegal guard expression: filelib:is_dir(H) In-Reply-To: References: Message-ID: <9CA303F2-34D2-4B42-92CC-4D07FC5668D1@cs.otago.ac.nz> On Feb 16, 2010, at 11:54 PM, Michael Turner wrote: > >> He had RUN his program, you see, so he KNEW it was right. > > Richard, look, I've run across the same mentality - it was while > porting > some C code, where my boss said it had worked on a couple other > platforms, so stop foot-dragging, Michael and move on. Remember, this has nothing to do with formal methods whatever. I had a student here once who screamed long and loud about the fact that I had given him 6/10 for a programming assignment. I said Look, the C compiler tells you there is a problem here. Using that problem, I can create this one-line legal test file that makes your program crash. That means your program doesn't work. He would not, no, I think he honestly COULD not, understand this. As far as he was concerned, The C compiler produces an executable file. I don't care what it says along the way. The program runs all MY test cases. I don't care about yours. My program *WORKS* and it can only be deliberate malevolence on your part that makes you withhold full marks. He had RUN his program, you see, so he KNEW it was right, whatever the C compiler or anyone else's tests or opinions said. By the way, it's extremely unfair to tar Dijkstra with the brush of program verification. He was one of the first people to say you couldn't expect to write a program and then verify it. What he argued for was "deriving the program and its proof hand-in-hand", which is not an airy-fairy formal methods idea, but something I've found to be a seriously practical way to approach hard problems. The notion of "proof" he had in mind was very much a human being doing the thinking, not mechanical verification. Right now I have a program where I'm having some trouble, and the whole problem is that I can't show it's right because I don't have a clear idea of what "right" means. If I *did* have a notion of what "right" means, then I could use that to tell me what to do. Running a program and hacking on it until it stops being obviously buggy can be a way of avoiding thought. If Dijkstra did ever say what you said someone said he said, then he _might_ for example have meant that by writing programs in his unimplemented notation he had resisted the temptation to let hacking serve in place of understanding what he was doing. A lot of programming is highly repetitive work, using a stack of known solutions over and over again. For that kind of thing, testing can serve as a defence against typing errors. *Some* programming tasks involve solving novel problems, and "rote" work can be incredibly ineffective for this. (Dijkstra gave the example of binary search as a tiny chunk of code that's much harder to get right than you might think.) Protocols are one of those things that are incredibly hard to get right. (There's a reason why there's a "Dijkstra Prize in Distributed Programming.") Reasoning very very carefully about them using any formal methods and checkers you can get your hands on pays off, because fixing them by hacking can be extremely hard. For a lovely example of how >not< to design protocols, see http://www.lightbluetouchpaper.org/2010/02/11/chip-and-pin-is-broken/ Does anyone have a good elementary introduction to how to design protocols between processes? I know about _testing_ them using things like SPIN and NuSMV and I'm learning about testing them using QuickCheck. But how do you *think* about designing them? I guess what I'm asking for is "A Discipline of Protocols". > > with five other people. But I knew C and its limits, I knew a bad > stack > crash zone when I saw one, and I can smell bogus assumptions about C > type sizes and alignments from 50 paces. That code got fixed. We > couldn't ship without it working. He lost some face over it. > > It's not formal correctness VERSUS Real Man Programmers with Grease on > Their Hands. I think the problem is that formal correctness got > oversold on unrealistic merits alone, and after the dashed > expectations, > nobody got in there and sold a practical and credible bill of goods > with > more modest goals. > > I mean, look at Peter Deutsch -- his dissertation was about the > Stanford > Pascal Verifier, but he ended up being sort of anti-formalism about > programming by the mid-1970s, and the exodus continued long after his > departure. He loved programming. The formal correctness people > didn't > give him much to help him love it even more. Quite the contrary, at > that point. So he moved on. (And his advisor? I think > contributing to > the SPV with Deutsch was the last thing Richard Karp did in > programming > language semantics. He had a good nose for where you can get > results.) > > Things don't happen in the real world until somebody makes the sale. > And if you screw up the first sale, especially in technology, it can > be > a lo-o-ong time before the idea has a second chance. The friend of > mine I quoted earlier sold his boss on the idea of letting him go to > that Asilomar conference co-starring Edsger Dijkstra by arguing that > knowledge of formal semantics and tools would help their company be > competitive. He came back without any tools to recommend and with a > dislike of most of what he saw there, especially the attitudes. > > I'm sure you're experienced with the phenomenon of something in > computer science being oversold on unproven merits. You mention > Prolog > quite a lot, for one thing. Hey, don't get me wrong, I've got nothing > against Prolog. The only reason I'm not elbows-deep into ECLiPSe > right > now is that Erlang soaks up most of the time I have available for > hacking. But you know what happened. > > -michael > > > > On 2/16/2010, "Richard O'Keefe" wrote: > >> >> On Feb 16, 2010, at 2:36 AM, Michael Turner wrote: >> >>> >>>> The reference to Guantanamo is, um, hyperbolic, to put it mildly. >>> >>> I plead guilty to Argument by Reference to Wikipedia. >>> >>> (A mitigating circumstance: I was once told by a friend that he'd >>> heard >>> Dijkstra say, haughtily, at a conference in Asilomar, "'Run a >>> program'?! Why, I haven't *run* a program in years!" Well of >>> course >>> not. How silly. Why run programs when you can be proving them >>> correct >>> instead?) >> >> Let's see, you have a second-hand report of *part* of a conversation, >> and you base your judgement on that? What had the other person said >> to him? What was the conversation about? How do you know that the >> next sentence wasn't "I've often had a computer carry out my plan" >> or something of the sort? >> >> I've just been reading an article in CACM which is simultaneously >> inspiring and deeply saddening. The article is about Coverity. >> The inspiring part is that they've built a wonderful tool for >> checking C code. The deeply saddening part is the refusal of many >> people to believe that their grossly nonstandard code is anything >> but perfectly legal C. One example sticks in my mind: >> >> int a[2], b; >> /* context: sizeof (int) is 4. */ >> memset(a, 0, 12); >> >> Coverity pointed out the bug. The customer said "no no, your tool >> is broken, I *meant* that because a and b are side by side." >> The fact that the C standard explicitly denies any relationship >> between the addresses of a and b, and that there have been (and >> for all I know may still be) compilers that sorted globals, >> putting the small ones first so it had a fighting chance of >> being able to address most of them with a single register, which >> compilers would have guaranteed that a and b were NOT adjacent, >> all of this was of no importance to the customer. >> >> He had RUN his program, you see, so he KNEW it was right. >> >> If you want to quote Dijkstra, quote this: >> >> I would therefore like to posit that computing's >> central challenge, "How not to make a mess of it," >> has not been met. On the contrary, most of our >> systems are much more complicated than can be >> considered healthy, and are too messy and chaotic >> to be used in comfort and confidence. The average >> customer of the computing industry has been served >> so poorly that he expects his system to crash all >> the time, and we witness a massive worldwide >> distribution of bug-ridden software for which we >> should be deeply ashamed. >> By the way, this doesn't contradict Armstrong's "Let it crash" >> dictum. Joe is talking about _components_ hidden inside a >> system crashing. Erlang *systems* aren't supposed to crash, >> which is why Francesco Cesarini and Simon Thompson stress >> early on in their wonderful book that processes should be >> watched by some other process. >> >> Whether Dijkstra personally ever ran a program or not (and he >> devised the implementation techniques at the heart of Java), >> his _notation_ deserves a reasoned responds on its own merits >> for what it is, not what it might be imagined to be. >> >> >> > From mjtruog@REDACTED Wed Feb 17 04:15:10 2010 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 16 Feb 2010 19:15:10 -0800 Subject: [erlang-questions] Distributed File System Powered by Erlang In-Reply-To: References: Message-ID: <4B7B5F3E.3040804@gmail.com> Why not just use Scalaris? http://code.google.com/p/scalaris/ The encryption in tahoe-lafs could be avoided if the network is separate and the incoming traffic is controlled. Tony Arcieri wrote: > I'd like to see an Erlang implementation of Tahoe LAFS: > > http://allmydata.org/trac/tahoe-lafs > > On Tue, Feb 16, 2010 at 10:55 AM, Hank Knight wrote: > > >> Imagine the power of a distributed file system powered by Erlang. >> Something like GlusterFS or The Google File System but build on >> Erlang. Has this been done? What would the performance implications >> be? >> >> Regards, >> Hank >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> >> > > > From acton@REDACTED Wed Feb 17 05:08:50 2010 From: acton@REDACTED (Brian Acton) Date: Tue, 16 Feb 2010 20:08:50 -0800 Subject: upgrading from R12 to R13 in a heterogeneous fashion Message-ID: <7a9fe0201002162008u22ba17f4i116ff63754153a41@mail.gmail.com> Hi guys, We are currently running an 8 node cluster running R12. We are wanting to get all the bug fixes and performance improvements from R13 (not to mention better support). We've been advised in the past that we shouldn't run a heterogeneous cluster with a mix of R12 and R13 as it is potentially unstable. I'm wondering if anyone has any advice on the matter and if it is OK for us to run a heterogeneous environment (even if it is for a short duration (like 24 hours) ). I'm also wondering if there are any specific gotchas or caveats that we should be aware of as we go down this path. Thanks! --b From zerthurd@REDACTED Wed Feb 17 05:33:55 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Wed, 17 Feb 2010 10:33:55 +0600 Subject: [erlang-questions] How to interpret lambda stacktrace? Message-ID: Hello Sometime I have writing code with nested lambda-functions and list-comprehensions. If this code contains, I have such stacktraces in crash report: exception exit: {function_clause, [{asg_alt,'-amm_handle_ev/3-fun-5-', [undefined,#Fun, pass]}, {asg_alt,'-amm_handle_ev/3-lc$^3/1-3-',2}, {asg_alt,'-amm_handle_ev/3-lc$^3/1-3-',2}, {asg_alt,amm_handle_ev,3}, {asg_pd,state_ready,2}, {gen_fsm,handle_msg,7}, {proc_lib,init_p_do_apply,3}]} Is there any way to understand which of lambda crashes? So, when function contains '-lc$' I can say that this is list-comprehension function, '/3' - arity of top function, but what means '^3/1-3-' and '-fun-5-' ? Is this values has some relation with order of its definition or not? Thank you -- Maxim Treskin From bob@REDACTED Wed Feb 17 05:51:54 2010 From: bob@REDACTED (Bob Ippolito) Date: Tue, 16 Feb 2010 23:51:54 -0500 Subject: [erlang-questions] upgrading from R12 to R13 in a heterogeneous fashion In-Reply-To: <7a9fe0201002162008u22ba17f4i116ff63754153a41@mail.gmail.com> References: <7a9fe0201002162008u22ba17f4i116ff63754153a41@mail.gmail.com> Message-ID: <6a36e7291002162051q3a631b5cncbd12e9cf1028e2a@mail.gmail.com> You'll find that anonymous funs compiled at a shell probably won't work across versions, but when we've had heterogeneous clusters we haven't had any major issues... although most of our nodes don't do a lot of erlang messaging. On Tue, Feb 16, 2010 at 11:08 PM, Brian Acton wrote: > Hi guys, > > We are currently running an 8 node cluster running R12. We are wanting to > get all the bug fixes and performance improvements from R13 (not to mention > better support). We've been advised in the past that we shouldn't run a > heterogeneous cluster with a mix of R12 and R13 as it is potentially > unstable. > > I'm wondering if anyone has any advice on the matter and if it is OK for us > to run a heterogeneous environment (even if it is for a short duration (like > 24 hours) ). I'm also wondering if there are any specific gotchas or caveats > that we should be aware of as we go down this path. > > Thanks! > > --b > From wde@REDACTED Wed Feb 17 05:28:00 2010 From: wde@REDACTED (wde) Date: Wed, 17 Feb 2010 05:28:00 +0100 Subject: [erlang-questions] Mnesia, disk_log and dets Message-ID: <20100217042757.B0D6B7000088@msfrf2217.sfr.fr> hello, I'm reading the source code of Mnesia to understand how things work :+) If I have understood correctly, for "disc_copies" tables, data are written to disc by using the "disk_log" module. For "disc_only_copies" tables, Mnesia uses "dets". What not use the same disk backend ? Thank you for your help. From leap@REDACTED Wed Feb 17 06:09:39 2010 From: leap@REDACTED (Michael Turner) Date: Wed, 17 Feb 2010 05:09:39 +0000 Subject: [erlang-questions] Missing The Point Of Documentation In-Reply-To: <5AEF5681-83E1-4380-8D0A-244741194909@souja.net> Message-ID: On 2/16/2010, "Jayson Vantuyl" wrote: [snip] >A fundamental problem with the Erlang docs is that they are very much >organized in a way that fits the invisible architecture underlying the >system, as opposed to being a helpful framework for communicating the >intent of the design. [snip] Yes, it's truly annoying. Quick: arriving with fresh eyes, where would you expect stdlib to be documented? Erlang/OTP System Documentation Basic Applications Database Applications Operation & Maintenance Applications Object Request Broker & IDL Applications Interface and Communication Applications Tool Applications Applications Applications (OK, I made up that last one.) You chose "Erlang/OTP System Documentation", right? Bzzt! Fool! It's under "Basic Applications". (Whatever *that's* supposed to mean.) I can't tell you how many times I've wanted to learn something about some Erlang standard library function, only to get lost online trying to find where the standard library is actually written up. What does "Applications" mean in the above TOC? Well, it mostly means "libraries", actually, not "applications". Until you get to Tool Applications, which are applications (sort of) because they are more like programs to run. Oh, except that the last entry in the sub-TOC for Tool Applications is ... "tools". Implying that everything listed above it (appmon, common_test, etc.) is not a tool? Well, that's been the pattern so far in the TOC: Applications are actually Libraries. Someone once said, "A foolish consistency is the hobgoblin of small minds," and I agree. But there's also such a thing as foolish INconsistency. And this manual organization exemplifies it. How about the following, instead? Erlang/OTP Guide Standard Libraries Database & Maintenance ORB & IDL Interfaces & Communications Tools This is also wrong, I'm sure. (Maybe ORB & IDL go under "Interfaces & Communications"? Among other problems.) But I think it's better. You might say, "Well, here's what you're *supposed* to think when you're looking at the top-level TOC for the Reference Manual," offering some explanation. And there might actually be some method to this madness, for all I know. But my eyes would glaze over immediately, and at the end of your spiel I'd reply, "Well, thank you very much, but why is *that* different from every other reference manual I've ever read and why aren't readers told at the beginning how *this* manual will be organized differently?" -michael turner From tony@REDACTED Wed Feb 17 06:50:42 2010 From: tony@REDACTED (Tony Arcieri) Date: Tue, 16 Feb 2010 22:50:42 -0700 Subject: [erlang-questions] Distributed File System Powered by Erlang In-Reply-To: <4B7B5F3E.3040804@gmail.com> References: <4B7B5F3E.3040804@gmail.com> Message-ID: On Tue, Feb 16, 2010 at 8:15 PM, Michael Truog wrote: > Why not just use Scalaris? > http://code.google.com/p/scalaris/ > > The encryption in tahoe-lafs could be avoided if the network is separate > and the incoming traffic is controlled. > Tahoe is nice in comparatively uncontrolled environments where others may be privy to network communication between nodes (e.g. EC2). It could very well make a good free alternative to Amazon's Elastic Block Store. -- Tony Arcieri Medioh! A Kudelski Brand From dave@REDACTED Wed Feb 17 06:35:15 2010 From: dave@REDACTED (Dave Peticolas) Date: Tue, 16 Feb 2010 21:35:15 -0800 Subject: [erlang-questions] Missing The Point Of Documentation In-Reply-To: References: Message-ID: <4B7B8013.70003@krondo.com> Michael Turner wrote: > > On 2/16/2010, "Jayson Vantuyl" wrote: > [snip] >> A fundamental problem with the Erlang docs is that they are very much >> organized in a way that fits the invisible architecture underlying the >> system, as opposed to being a helpful framework for communicating the >> intent of the design. > [snip] > > Yes, it's truly annoying. > > Quick: arriving with fresh eyes, where would you expect stdlib to be > documented? > > Erlang/OTP System Documentation > Basic Applications > Database Applications > Operation & Maintenance Applications > Object Request Broker & IDL Applications > Interface and Communication Applications > Tool Applications > Applications Applications > > (OK, I made up that last one.) > > You chose "Erlang/OTP System Documentation", right? Bzzt! Fool! > It's under "Basic Applications". (Whatever *that's* supposed to > mean.) > > I can't tell you how many times I've wanted to learn something about > some Erlang standard library function, only to get lost online trying to > find where the standard library is actually written up. > > What does "Applications" mean in the above TOC? Well, it mostly means > "libraries", actually, not "applications". Until you get to Tool > Applications, which are applications (sort of) because they are more > like programs to run. Oh, except that the last entry in the sub-TOC for > Tool Applications is ... "tools". Implying that everything listed > above it (appmon, common_test, etc.) is not a tool? Well, that's been > the pattern so far in the TOC: Applications are actually Libraries. > > Someone once said, "A foolish consistency is the hobgoblin of small > minds," and I agree. But there's also such a thing as foolish > INconsistency. And this manual organization exemplifies it. > > > How about the following, instead? > > Erlang/OTP Guide > Standard Libraries > Database & Maintenance > ORB & IDL > Interfaces & Communications > Tools > > This is also wrong, I'm sure. (Maybe ORB & IDL go under "Interfaces & > Communications"? Among other problems.) But I think it's better. > > You might say, "Well, here's what you're *supposed* to think when > you're looking at the top-level TOC for the Reference Manual," > offering some explanation. And there might actually be some method to > this madness, for all I know. But my eyes would glaze over immediately, > and at the end of your spiel I'd reply, "Well, thank you very much, > but why is *that* different from every other reference manual I've ever > read and why aren't readers told at the beginning how *this* manual > will be organized differently?" > > -michael turner I think a global module index, like the one for the built-in Python modules, would be useful, both for quickly finding the module you already know the name of, and for browsing to see just what is available: http://docs.python.org/modindex.html Python also provides a more structured view of the same set: http://docs.python.org/library Which is still easier than the Erlang version because the tree is already fully expanded so you can search in the page. But I always end up going to the global index. dave From ulf.wiger@REDACTED Wed Feb 17 07:39:48 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 17 Feb 2010 07:39:48 +0100 Subject: [erlang-questions] Mnesia, disk_log and dets In-Reply-To: <20100217042757.B0D6B7000088@msfrf2217.sfr.fr> References: <20100217042757.B0D6B7000088@msfrf2217.sfr.fr> Message-ID: <4B7B8F34.2070207@erlang-solutions.com> wde wrote: > hello, > > I'm reading the source code of Mnesia to understand how things work > :+) If I have understood correctly, for "disc_copies" tables, data > are written to disc by using the "disk_log" module. For > "disc_only_copies" tables, Mnesia uses "dets". > > What not use the same disk backend ? Originally, they did use the same back-end, but it turned out, from experimentation, that dumping the entire table using disk_log was /much/ faster than writing out the individual changes into a dets file. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From bob@REDACTED Wed Feb 17 07:40:10 2010 From: bob@REDACTED (Bob Ippolito) Date: Wed, 17 Feb 2010 01:40:10 -0500 Subject: [erlang-questions] Missing The Point Of Documentation In-Reply-To: <4B7B8013.70003@krondo.com> References: <4B7B8013.70003@krondo.com> Message-ID: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> On Wed, Feb 17, 2010 at 12:35 AM, Dave Peticolas wrote: > I think a global module index, like the one for the built-in > Python modules, would be useful, both for quickly finding the > module you already know the name of, and for browsing to see > just what is available: > > ?http://docs.python.org/modindex.html http://erlang.org/doc/man_index.html It's the "Modules" hyperlink in the left frame of the docs. To be fair, it's not that obvious to find, someone actually had to show it to me... before that I had previously navigated through the applications to find modules. The biggest problem with the Erlang module index is that it has no context whatsoever about what the modules do (other than the semi-arbitrary application they belong to), so if you don't know at least part of the name already you won't be able to search for the module you want on that page. -bob From kenneth.lundin@REDACTED Wed Feb 17 08:10:10 2010 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 17 Feb 2010 08:10:10 +0100 Subject: [erlang-questions] upgrading from R12 to R13 in a heterogeneous fashion In-Reply-To: <7a9fe0201002162008u22ba17f4i116ff63754153a41@mail.gmail.com> References: <7a9fe0201002162008u22ba17f4i116ff63754153a41@mail.gmail.com> Message-ID: The compatibility between major releases is intended just for the case when a cluster is upgraded in service node by node. It will probably work well for many applications to run a heterogeneous cluster in steady state as well but the general recommendation is to upgrade to the same version of Erlang on every node as fast as possible. This applies if you are using the Erlang distribution between the nodes. If you have invented your own communication between the nodes it is up to your solution if it is important to have the same version of Erlang on every node. /Kenneth Erlang/OTP, Ericsson On Wed, Feb 17, 2010 at 5:08 AM, Brian Acton wrote: > Hi guys, > > We are currently running an 8 node cluster running R12. We are wanting to > get all the bug fixes and performance improvements from R13 (not to mention > better support). We've been advised in the past that we shouldn't run a > heterogeneous cluster with a mix of R12 and R13 as it is potentially > unstable. > > I'm wondering if anyone has any advice on the matter and if it is OK for us > to run a heterogeneous environment (even if it is for a short duration (like > 24 hours) ). I'm also wondering if there are any specific gotchas or caveats > that we should be aware of as we go down this path. > > Thanks! > > --b > From wde@REDACTED Wed Feb 17 08:38:11 2010 From: wde@REDACTED (wde) Date: Wed, 17 Feb 2010 08:38:11 +0100 Subject: [erlang-questions] Mnesia, disk_log and dets Message-ID: <20100217073815.513F67000095@msfrf2208.sfr.fr> ok thank you. With Mnesiaex we can have our own storage backend for the new "external_copies" type. But instead of specifying a new copy type, I'm currently trying to understand how I can integrate a wrapper module like "mnesia_disc_backend" that handle all disc access (for disc_copies and disc_only_copies) , and do the same thing for the "ram_copy" type, by using a "mnesia_ram_backend" module. The idea is to offer more flexibility and easily change the backend for ram and disc I/O. Do you think I'm wasting my time or that there is no interest for something like that ? >wde wrote: >> hello, >> >> I'm reading the source code of Mnesia to understand how things work >> :+) If I have understood correctly, for "disc_copies" tables, data >> are written to disc by using the "disk_log" module. For >> "disc_only_copies" tables, Mnesia uses "dets". >> >> What not use the same disk backend ? > >Originally, they did use the same back-end, but it turned out, >from experimentation, that dumping the entire table using disk_log >was /much/ faster than writing out the individual changes into >a dets file. > >BR, >Ulf W >-- >Ulf Wiger >CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd >http://www.erlang-solutions.com >--------------------------------------------------- > >--------------------------------------------------- > >WE'VE CHANGED NAMES! > >Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. > >www.erlang-solutions.com > > From waterding@REDACTED Wed Feb 17 10:34:02 2010 From: waterding@REDACTED (Aeolus) Date: Wed, 17 Feb 2010 10:34:02 +0100 Subject: [erlang-questions] Common_Test generate xml? Message-ID: Hello people, We have been using common test to perform testing. My question is that does Common Test (ct) support generating XML (xUNIT tool readable) format result files. Our purpose is to reuse some xUnit(junit) result analyzing tools to help us read those results or maybe do some graphic stuff as well. The user guide didn't mention this. //Chengwei From peppe@REDACTED Wed Feb 17 11:10:40 2010 From: peppe@REDACTED (Peter Andersson) Date: Wed, 17 Feb 2010 11:10:40 +0100 Subject: [erlang-questions] Common_Test generate xml? In-Reply-To: References: Message-ID: <4B7BC0A0.6050001@erix.ericsson.se> Hi, No Common Test only generates logs on html format. It's on the todo-list to use events as base for an alternative logging mechanism, and implement a logger handler/plugin for xml. This job hasn't started yet though, so it'll be a while before it's finished. If it's only the progress and results (and not also the IO printouts) you're after, you can install your own event handler which translates events to xml if you want. Read about event handling in the user's guide. /Peter Erlang/OTP, Ericsson AB Aeolus wrote: > Hello people, > > We have been using common test to perform testing. My question is that > does Common Test (ct) support generating XML (xUNIT tool readable) > format result files. Our purpose is to reuse some xUnit(junit) result > analyzing tools to help us read those results or maybe do some graphic > stuff as well. The user guide didn't mention this. > > > //Chengwei > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From leap@REDACTED Wed Feb 17 11:27:47 2010 From: leap@REDACTED (Michael Turner) Date: Wed, 17 Feb 2010 10:27:47 +0000 Subject: yet more ranting about Erlang docs In-Reply-To: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> Message-ID: On 2/17/2010, "Bob Ippolito" wrote: >On Wed, Feb 17, 2010 at 12:35 AM, Dave Peticolas wrote: >> I think a global module index, like the one for the built-in >> Python modules, would be useful, both for quickly finding the >> module you already know the name of, and for browsing to see >> just what is available: >> >> http://docs.python.org/modindex.html > >http://erlang.org/doc/man_index.html > >It's the "Modules" hyperlink in the left frame of the docs. In the left frame of what pages? Only at http://erlang.org/docs? I wondered where this page was linked from (who knows? maybe some place that was intuitively obvious? you can't rule it out), so I clicked on "Up". Dead link. (The link next to it is labeled "Erlang", which at that point is like being in San Francisco and seeing a sign saying, "California".) And when you get to the module list, it describes itself not as a module list, but as "Manual Page Index". Not exactly the same thing. There are some navigation, nomenclature and comprehension issues here. >To be fair, it's not that obvious to find, I've run across it before. But you shouldn't have to "run across" it. It should be linked from sidebars on every page. (And not all pages have a handy sidebar. E.g., the otherwise-relatively-helpful Applications list, for some reason: http://erlang.org/doc/applications.html.) Side-rant: Why isn't there a search box on EVERY PAGE? >The biggest problem with the Erlang module index is that it has no >context whatsoever about what the modules do (other than the >semi-arbitrary application they belong to), so if you don't know at >least part of the name already you won't be able to search for the >module you want on that page. "Semi-arbitrary application" -- well, OK, maybe Erlang/OTP defines the term "application" somewhere, carrying a sense with which I'm not familiar, somehow justifying the description of certain libraries as applications? Ah, here it is: http://erlang.org/doc/man/STDLIB_app.html "In OTP, application denotes a component implementing some specific functionality, that can be started and stopped as a unit, and which can be re-used in other systems as well." OK, fine. C&S p.264 provide a roughly equivalent definition. So in what sense dpes STDLIB conform to these definitions? Here's what we get from the reference manual: ---- APPLICATION STDLIB APPLICATION SUMMARY The STDLIB Application DESCRIPTION The STDLIB is mandatory in the sense that the minimal system based on Erlang/OTP consists of Kernel and STDLIB. The STDLIB application contains no services. ---- "No services" meaning that there's nothing to stop and start? If so, why call STDLIB an "application" even in the Erlang sense? It's bizarre enough to me that even Kernel is called an "application," but I *can* bend my brain around it. A library that just sits there, though? I find myself wondering if there was a time, back when Ericsson was trying to commercialize Erlang, when some marketing airhead went nuts trying to get the word "application" used everywhere, perhaps because when he talked to Erlang programmers they all sounded dangerously theoretical to him. Why, with STDLIB and some other libraries suddenly reclassified as "applications," he could talk about how the number of applications written in Erlang was growing by leaps and bounds! Cool languages attract smart programmers, and Erlang is cool. But as the saying goes, you only get one chance to make a first impression. How many smart programmers, drawn in by the buzz about Erlang, land at www.erlang.org, browse a little, feel puzzled by the strange use of terms, end up frustrated by difficulties in navigation, then maybe bookmark it but never really come back? -michael turner From waterding@REDACTED Wed Feb 17 11:29:30 2010 From: waterding@REDACTED (Aeolus) Date: Wed, 17 Feb 2010 11:29:30 +0100 Subject: [erlang-questions] Common_Test generate xml? In-Reply-To: <4B7BC0A0.6050001@erix.ericsson.se> References: <4B7BC0A0.6050001@erix.ericsson.se> Message-ID: On Wed, Feb 17, 2010 at 11:10 AM, Peter Andersson wrote: > Hi, > > No Common Test only generates logs on html format. It's on the todo-list > to use events as base for an alternative logging mechanism, and > implement a logger handler/plugin for xml. This job hasn't started yet > though, so it'll be a while before it's finished. > Good : Confirmed non existing and will be introduced. Bad: not at this moment. > If it's only the progress and results (and not also the IO printouts) > you're after, you can install your own event handler which translates > events to xml if you want. Read about event handling in the user's guide. > Errr, we need the IO printouts, imagine you have thousands of testcase, people just skip passed ones and only look into those failed ones which should have the print outs from the testcase. Hope CT event handler could grap the output in some way. //Chengwei > ?/Peter > > Erlang/OTP, Ericsson AB > > Aeolus wrote: >> Hello people, >> >> We have been using common test to perform testing. My question is that >> does Common Test (ct) support generating XML (xUNIT tool readable) >> format result files. Our purpose is to reuse some xUnit(junit) result >> analyzing tools to help us read those results or maybe do some graphic >> stuff as well. The user guide didn't mention this. >> >> >> //Chengwei >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > > From dawid.figiel@REDACTED Wed Feb 17 11:50:22 2010 From: dawid.figiel@REDACTED (Dawid Figiel) Date: Wed, 17 Feb 2010 10:50:22 +0000 (GMT) Subject: [erlang-questions] Mnesia, disk_log and dets In-Reply-To: <709665252.42201266403536891.JavaMail.root@zimbra> Message-ID: <279217678.42231266403822273.JavaMail.root@zimbra> Hi, Ulf knows probably everything about mnesia, I know it rather as a common user, but your ideas seems to be interesting. I would like to have database with mnesia API, but more efficient and more powerful backend... also more flexible and extend-able. I was playing with Mnesiaex but I've had some issues with dependencies and TC (Tokyo Cabinet) was chosen. ?? Anyway subject is interesting especially from the efficiency point of view. I'm looking forward to seeing your results :) -- rgs, Dawid Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com ----- Original Message ----- From: "wde" To: "Ulf Wiger" Cc: "erlang-questions" Sent: Wednesday, February 17, 2010 7:38:11 AM GMT +00:00 GMT Britain, Ireland, Portugal Subject: Re: Re: [erlang-questions] Mnesia, disk_log and dets ok thank you. With Mnesiaex we can have our own storage backend for the ?new "external_copies" type. But instead of specifying a new copy type, I'm currently trying to understand how I can integrate a wrapper module like "mnesia_disc_backend" that handle all disc access (for disc_copies and disc_only_copies) , and do the same thing for the "ram_copy" type, by using a "mnesia_ram_backend" module. The idea is to offer more flexibility and easily change the backend for ram and disc I/O. Do you think I'm wasting my time or that there is no interest for something like that ? >wde wrote: >> hello, >> >> I'm reading the source code of Mnesia to understand how things work >> :+) If I have understood correctly, for "disc_copies" tables, data >> are written to disc by using the "disk_log" module. For >> "disc_only_copies" tables, Mnesia uses "dets". >> >> What not use the same disk backend ? > >Originally, they did use the same back-end, but it turned out, >from experimentation, that dumping the entire table using disk_log >was /much/ faster than writing out the individual changes into >a dets file. > >BR, >Ulf W >-- >Ulf Wiger >CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd >http://www.erlang-solutions.com >--------------------------------------------------- > >--------------------------------------------------- > >WE'VE CHANGED NAMES! > >Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. > >www.erlang-solutions.com > > ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED From Antonio.Musumeci@REDACTED Wed Feb 17 15:11:36 2010 From: Antonio.Musumeci@REDACTED (Musumeci, Antonio S) Date: Wed, 17 Feb 2010 09:11:36 -0500 Subject: Ports and their owners Message-ID: <01489E237C2C8F45AF7898E135F48E8001DA64CD84@NYWEXMBX2129.msad.ms.com> Given: 1) Port ! {self(), {command, Data}} syntax will fail with badsig if the self() is not the port owner. 2) port_command(Port, Data) does not do this and allows any process to send messages to the port 3) ports have owners Question: Why is it (or am I missing how to do it) that I'm unable from the port side to find out who is sending the incoming message? It appears that there was this original intent to lock down the port but with port_command that was thrown away without the ability to be sure who's sending you the data so as it implement one's own security measures. If this is in fact true does anyone have suggestions on securing ports? Thanks. -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. From dale@REDACTED Wed Feb 17 15:56:15 2010 From: dale@REDACTED (Dale Harvey) Date: Wed, 17 Feb 2010 14:56:15 +0000 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> Message-ID: the otp team are working on a site with a global side search navigation http://demo.erlang.org/erldoc?q=test&x=0&y=0 and (again) for a purely function reference http://erldocs.com/R13B03/stdlib/lists.html?search=lists:a&i=0#all/2 also has a global side search I dont think anything outside Erickson official is non sequiter, while most language have some form of standards bodies, the tools / tutorials surrounding them are often community driven, rubys community in particular is great at this. I recommend learners to either buy the orielly / joes book, or visit http://learnyousomeerlang.com/content well before visiting erlang.org, while these learning/documentation tool might be missed by people visiting erlang.org there is no reason for them not to become the defacto tools, Bjorn / Erickson are doing a great job accepting patches and changes and it looks like lots of work is going into the new site, and I see no reason to think that Erickson wouldnt link out to great tutorials and tools if the community produced them, in fact the new site looks like that is an aim. Cheers Dale On 17 February 2010 10:27, Michael Turner wrote: > > > On 2/17/2010, "Bob Ippolito" wrote: > > >On Wed, Feb 17, 2010 at 12:35 AM, Dave Peticolas wrote: > >> I think a global module index, like the one for the built-in > >> Python modules, would be useful, both for quickly finding the > >> module you already know the name of, and for browsing to see > >> just what is available: > >> > >> http://docs.python.org/modindex.html > > > >http://erlang.org/doc/man_index.html > > > >It's the "Modules" hyperlink in the left frame of the docs. > > In the left frame of what pages? Only at http://erlang.org/docs? > > I wondered where this page was linked from (who knows? maybe some place > that was intuitively obvious? you can't rule it out), so I clicked on > "Up". > > Dead link. > > (The link next to it is labeled "Erlang", which at that point is like > being in San Francisco and seeing a sign saying, "California".) > > And when you get to the module list, it describes itself not as a module > list, but as "Manual Page Index". Not exactly the same thing. > > There are some navigation, nomenclature and comprehension issues here. > > >To be fair, it's not that obvious to find, > > I've run across it before. But you shouldn't have to "run across" > it. It should be linked from sidebars on every page. (And not all > pages have a handy sidebar. E.g., the otherwise-relatively-helpful > Applications list, for some reason: > http://erlang.org/doc/applications.html.) > > Side-rant: Why isn't there a search box on EVERY PAGE? > > >The biggest problem with the Erlang module index is that it has no > >context whatsoever about what the modules do (other than the > >semi-arbitrary application they belong to), so if you don't know at > >least part of the name already you won't be able to search for the > >module you want on that page. > > "Semi-arbitrary application" -- well, OK, maybe Erlang/OTP defines the > term "application" somewhere, carrying a sense with which I'm not > familiar, somehow justifying the description of certain libraries as > applications? > > Ah, here it is: http://erlang.org/doc/man/STDLIB_app.html > > "In OTP, application denotes a component implementing some specific > functionality, that can be started and stopped as a unit, and which can > be re-used in other systems as well." > > OK, fine. C&S p.264 provide a roughly equivalent definition. So in what > sense dpes STDLIB conform to these definitions? Here's what we get > from the reference manual: > > ---- > APPLICATION > > STDLIB > > APPLICATION SUMMARY > > The STDLIB Application > > DESCRIPTION > > The STDLIB is mandatory in the sense that the minimal system based on > Erlang/OTP consists of Kernel and STDLIB. The STDLIB application > contains no services. > ---- > > "No services" meaning that there's nothing to stop and start? If so, > why call STDLIB an "application" even in the Erlang sense? It's > bizarre enough to me that even Kernel is called an "application," but > I *can* bend my brain around it. A library that just sits there, though? > > I find myself wondering if there was a time, back when Ericsson was > trying to commercialize Erlang, when some marketing airhead went nuts > trying to get the word "application" used everywhere, perhaps because > when he talked to Erlang programmers they all sounded dangerously > theoretical to him. Why, with STDLIB and some other libraries suddenly > reclassified as "applications," he could talk about how the number of > applications written in Erlang was growing by leaps and bounds! > > Cool languages attract smart programmers, and Erlang is cool. But as the > saying goes, you only get one chance to make a first impression. How > many smart programmers, drawn in by the buzz about Erlang, land at > www.erlang.org, browse a little, feel puzzled by the strange use of > terms, end up frustrated by difficulties in navigation, then maybe > bookmark it but never really come back? > > -michael turner > > > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From rvirding@REDACTED Wed Feb 17 16:02:51 2010 From: rvirding@REDACTED (Robert Virding) Date: Wed, 17 Feb 2010 16:02:51 +0100 Subject: [erlang-questions] Ports and their owners In-Reply-To: <01489E237C2C8F45AF7898E135F48E8001DA64CD84@NYWEXMBX2129.msad.ms.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64CD84@NYWEXMBX2129.msad.ms.com> Message-ID: <3dbc6d1c1002170702o8941550l2f6b53d5daabcc5@mail.gmail.com> The original port communication mechanism is the purely message based one. It was designed to follow the standard erlang process communication mechanism as closely as possible, which is why the sender must include its own pid in the message. The security of communicating with a port would then be at the same level as process communication. Erlang was never really designed to be secure *within* a node and it is basically impossible to protect yourself internally. IIRC port_command was added to bypass the need to communicate via the port owner process. For what exactly what reason I can't remember. Personally I have always felt that the pure message passing is much cleaner and better fits into the rest of Erlang. Robert On 17 February 2010 15:11, Musumeci, Antonio S wrote: > Given: > > 1) Port ! {self(), {command, Data}} syntax will fail with badsig if the self() is not the port owner. > 2) port_command(Port, Data) does not do this and allows any process to send messages to the port > 3) ports have owners > > Question: > > Why is it (or am I missing how to do it) that I'm unable from the port side to find out who is sending the incoming message? It appears that there was this original intent to lock down the port but with port_command that was thrown away without the ability to be sure who's sending you the data so as it implement one's own security measures. > > If this is in fact true does anyone have suggestions on securing ports? > > Thanks. > > > -------------------------------------------------------------------------- > NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. > From rvirding@REDACTED Wed Feb 17 16:18:25 2010 From: rvirding@REDACTED (Robert Virding) Date: Wed, 17 Feb 2010 16:18:25 +0100 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> Message-ID: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> Without getting into the discussion how difficult, or not, it is to navigate the Erlang docs one source of the problem is that all the standard OTP libraries are proper Applications. So when when the documentation is organised around "applications", in one sense, it is being entirely logical and consistent. Of course, until you are more experienced and groked this it can be very confusing and difficult to find things. Robert From Antonio.Musumeci@REDACTED Wed Feb 17 16:22:51 2010 From: Antonio.Musumeci@REDACTED (Musumeci, Antonio S) Date: Wed, 17 Feb 2010 10:22:51 -0500 Subject: [erlang-questions] Ports and their owners In-Reply-To: <3dbc6d1c1002170702o8941550l2f6b53d5daabcc5@mail.gmail.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64CD84@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170702o8941550l2f6b53d5daabcc5@mail.gmail.com> Message-ID: <01489E237C2C8F45AF7898E135F48E8001DA64CDD0@NYWEXMBX2129.msad.ms.com> >From a language / VM perspective it should be quite simple to include the sender as part of the message. At this point it may not be possible to add without major breakage but it's very unfortunate that was not the initial design. I agree the original pure message passing syntax is cleaner... though as the docs say otherwise. Perhaps open_port/2 could be expanded to take an argument limiting messages to only those from the owner. I've not tracked down the entire flow of port_command but it looks like do_port_command in erts/emulator/beam/erl_bif_port.c takes a Process* which I'm assuming is the data structure representing the process calling port_command... If so it can error if that option was set and the Process->id is not that of the port's owner. -----Original Message----- From: Robert Virding [mailto:rvirding@REDACTED] Sent: Wednesday, February 17, 2010 10:03 AM To: Musumeci, Antonio S (IT) Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] Ports and their owners The original port communication mechanism is the purely message based one. It was designed to follow the standard erlang process communication mechanism as closely as possible, which is why the sender must include its own pid in the message. The security of communicating with a port would then be at the same level as process communication. Erlang was never really designed to be secure *within* a node and it is basically impossible to protect yourself internally. IIRC port_command was added to bypass the need to communicate via the port owner process. For what exactly what reason I can't remember. Personally I have always felt that the pure message passing is much cleaner and better fits into the rest of Erlang. Robert On 17 February 2010 15:11, Musumeci, Antonio S wrote: > Given: > > 1) Port ! {self(), {command, Data}} syntax will fail with badsig if the self() is not the port owner. > 2) port_command(Port, Data) does not do this and allows any process to > send messages to the port > 3) ports have owners > > Question: > > Why is it (or am I missing how to do it) that I'm unable from the port side to find out who is sending the incoming message? It appears that there was this original intent to lock down the port but with port_command that was thrown away without the ability to be sure who's sending you the data so as it implement one's own security measures. > > If this is in fact true does anyone have suggestions on securing ports? > > Thanks. > > > ---------------------------------------------------------------------- > ---- > NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. > -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. From dave@REDACTED Wed Feb 17 16:35:44 2010 From: dave@REDACTED (Dave Peticolas) Date: Wed, 17 Feb 2010 07:35:44 -0800 Subject: [erlang-questions] Missing The Point Of Documentation In-Reply-To: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> References: <4B7B8013.70003@krondo.com> <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> Message-ID: <4B7C0CD0.7070608@krondo.com> Bob Ippolito wrote: > On Wed, Feb 17, 2010 at 12:35 AM, Dave Peticolas wrote: >> I think a global module index, like the one for the built-in >> Python modules, would be useful, both for quickly finding the >> module you already know the name of, and for browsing to see >> just what is available: >> >> http://docs.python.org/modindex.html > > http://erlang.org/doc/man_index.html > > It's the "Modules" hyperlink in the left frame of the docs. Ah! > To be fair, it's not that obvious to find, someone actually had to > show it to me... before that I had previously navigated through the > applications to find modules. Thanks for showing it to others :) > The biggest problem with the Erlang module index is that it has no > context whatsoever about what the modules do (other than the > semi-arbitrary application they belong to), so if you don't know at > least part of the name already you won't be able to search for the > module you want on that page. > > -bob > From rvirding@REDACTED Wed Feb 17 16:37:07 2010 From: rvirding@REDACTED (Robert Virding) Date: Wed, 17 Feb 2010 16:37:07 +0100 Subject: [erlang-questions] Ports and their owners In-Reply-To: <01489E237C2C8F45AF7898E135F48E8001DA64CDD0@NYWEXMBX2129.msad.ms.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64CD84@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170702o8941550l2f6b53d5daabcc5@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64CDD0@NYWEXMBX2129.msad.ms.com> Message-ID: <3dbc6d1c1002170737h30744638q8df8347b21759dcc@mail.gmail.com> On 17 February 2010 16:22, Musumeci, Antonio S wrote: > From a language / VM perspective it should be quite simple to include the sender as part of the message. At this point it may not be possible to add without major breakage but it's very unfortunate that was not the initial design. Hehehe, it *was* included in the original design but we removed it. We felt that it was much more versatile to have the sender include the "from" field. "From" can be any term which identifies the sender and is it not always the pid or even needed. As I mentioned internal security was not a problem. Robert From Antonio.Musumeci@REDACTED Wed Feb 17 16:47:47 2010 From: Antonio.Musumeci@REDACTED (Musumeci, Antonio S) Date: Wed, 17 Feb 2010 10:47:47 -0500 Subject: [erlang-questions] Ports and their owners In-Reply-To: <3dbc6d1c1002170737h30744638q8df8347b21759dcc@mail.gmail.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64CD84@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170702o8941550l2f6b53d5daabcc5@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64CDD0@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170737h30744638q8df8347b21759dcc@mail.gmail.com> Message-ID: <01489E237C2C8F45AF7898E135F48E8001DA64CDEE@NYWEXMBX2129.msad.ms.com> Yeah... Unfortunately for what I'm doing we'd like security within the node due to running arbitrary modules, cnodes and ports. I've already began work on providing a filtering mechanism for RPC and net_kernel:spawn by moving spawn into rex and adding an optional filter callback which all calls go through. This would at least allow sandboxing the spawning of arbitrary processes to some extent. I'll be posting that to erlang-patches sometime this week. After that I'll take a shot at adding the open_port option I mentioned. -----Original Message----- From: Robert Virding [mailto:rvirding@REDACTED] Sent: Wednesday, February 17, 2010 10:37 AM To: Musumeci, Antonio S (IT) Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] Ports and their owners On 17 February 2010 16:22, Musumeci, Antonio S wrote: > From a language / VM perspective it should be quite simple to include the sender as part of the message. At this point it may not be possible to add without major breakage but it's very unfortunate that was not the initial design. Hehehe, it *was* included in the original design but we removed it. We felt that it was much more versatile to have the sender include the "from" field. "From" can be any term which identifies the sender and is it not always the pid or even needed. As I mentioned internal security was not a problem. Robert -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. From rvirding@REDACTED Wed Feb 17 16:49:21 2010 From: rvirding@REDACTED (Robert Virding) Date: Wed, 17 Feb 2010 16:49:21 +0100 Subject: [erlang-questions] How to interpret lambda stacktrace? In-Reply-To: References: Message-ID: <3dbc6d1c1002170749n51ef641apb8e7633085118c8c@mail.gmail.com> The first part of the name, -amm_handle_ev/3- in your case is the function name/arity in which the fun or comprehension is defined. Then: - for a fun this is followed by -fun- and the index of the fun within the defining function. So "-fun-5-" means the fifth fun within the function, as a whole. - for a comprehension it is "-lc$^" and the index of the comprehension within the module. It can be either "lc", "blc" or "lbc" depending on type of comprehension. The "$^" has no significance as such. These are basically just funny names which are most likely unique. Two important points: - NO this naming is not defined anywhere, it is purely internal. - NO there is no guarantee that it won't be changed in the future. So use it for info but be warned. Robert On 17 February 2010 05:33, Maxim Treskin wrote: > Hello > > Sometime I have writing code with nested lambda-functions and > list-comprehensions. > If this code contains, I have such stacktraces in crash report: > > ? ?exception exit: {function_clause, > ? ? ? ? ? ? ? ? ? ? ? ?[{asg_alt,'-amm_handle_ev/3-fun-5-', > ? ? ? ? ? ? ? ? ? ? ? ? ? ? [undefined,#Fun, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?pass]}, > ? ? ? ? ? ? ? ? ? ? ? ? {asg_alt,'-amm_handle_ev/3-lc$^3/1-3-',2}, > ? ? ? ? ? ? ? ? ? ? ? ? {asg_alt,'-amm_handle_ev/3-lc$^3/1-3-',2}, > ? ? ? ? ? ? ? ? ? ? ? ? {asg_alt,amm_handle_ev,3}, > ? ? ? ? ? ? ? ? ? ? ? ? {asg_pd,state_ready,2}, > ? ? ? ? ? ? ? ? ? ? ? ? {gen_fsm,handle_msg,7}, > ? ? ? ? ? ? ? ? ? ? ? ? {proc_lib,init_p_do_apply,3}]} > > Is there any way to understand which of lambda crashes? So, when > function contains '-lc$' I can say that this is list-comprehension > function, '/3' - ?arity of top function, but what means '^3/1-3-' and > '-fun-5-' ? Is this values has some relation with order of its > definition or not? > > Thank you > > -- > Maxim Treskin > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From leap@REDACTED Wed Feb 17 16:52:48 2010 From: leap@REDACTED (Michael Turner) Date: Wed, 17 Feb 2010 15:52:48 +0000 Subject: What about making sense? In-Reply-To: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> Message-ID: On 2/17/2010, "Robert Virding" wrote: >Without getting into the discussion how difficult, or not, it is to >navigate the Erlang docs one source of the problem is that all the >standard OTP libraries are proper Applications. People should think of the trigonometric functions as part of the STDLIB Application, just because gen_server is grouped in with them, in stdlib? What sense does this make? > So when when the >documentation is organised around "applications", in one sense, it is >being entirely logical and consistent. Of course, until you are more >experienced and groked this it can be very confusing and difficult to >find things. But in the meantime, conceptual/terminological confusion impedes the learner, whenever he/she needs to resort to the Reference Manual. Given that Erlang already poses quite a learning curve for some, this will reduce the rate at which people become "more experienced and grok this", and for that matter, it will reduce the number of people who even want to get that far with Erlang. What sense does this make? What goal does this serve? The goal of making it easier to autogenerate the documentation? Well, I remember the days when we humans did a lot of things to make life easier for the system. As I recall, it involved punching a lot of cards. -michael turner From rvirding@REDACTED Wed Feb 17 16:53:20 2010 From: rvirding@REDACTED (Robert Virding) Date: Wed, 17 Feb 2010 16:53:20 +0100 Subject: [erlang-questions] Ports and their owners In-Reply-To: <01489E237C2C8F45AF7898E135F48E8001DA64CDEE@NYWEXMBX2129.msad.ms.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64CD84@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170702o8941550l2f6b53d5daabcc5@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64CDD0@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170737h30744638q8df8347b21759dcc@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64CDEE@NYWEXMBX2129.msad.ms.com> Message-ID: <3dbc6d1c1002170753h1bc47aaau7376dd98ce46ef41@mail.gmail.com> On 17 February 2010 16:47, Musumeci, Antonio S wrote: > Yeah... Unfortunately for what I'm doing we'd like security within the node due to running arbitrary modules, cnodes and ports. I've already began work on providing a filtering mechanism for RPC and net_kernel:spawn by moving spawn into rex and adding an optional filter callback which all calls go through. This would at least allow sandboxing the spawning of arbitrary processes to some extent. I'll be posting that to erlang-patches sometime this week. After that I'll take a shot at adding the open_port option I mentioned. > Another soultion would be to NOT use the standard erlang distribution but do it all yourself over tcp. This way you could get full control of what is run within a node and limit what a node is allowed to do. A bit more work maybe and not as transparent but more control. Robert From zerthurd@REDACTED Wed Feb 17 17:04:42 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Wed, 17 Feb 2010 22:04:42 +0600 Subject: [erlang-questions] How to interpret lambda stacktrace? In-Reply-To: <3dbc6d1c1002170749n51ef641apb8e7633085118c8c@mail.gmail.com> References: <3dbc6d1c1002170749n51ef641apb8e7633085118c8c@mail.gmail.com> Message-ID: Thank you very much, Robert! On 17 February 2010 21:49, Robert Virding wrote: > The first part of the name, -amm_handle_ev/3- in your case is the > function name/arity in which the fun or comprehension is defined. > Then: > > - for a fun this is followed by -fun- and the index of the fun within > the defining function. So "-fun-5-" means the fifth fun within the > function, as a whole. > > - for a comprehension it is "-lc$^" and the index of the comprehension > within the module. It can be either "lc", "blc" or "lbc" depending on > type of comprehension. The "$^" has no significance as such. > > These are basically just funny names which are most likely unique. Two > important points: > > - NO this naming is not defined anywhere, it is purely internal. > - NO there is no guarantee that it won't be changed in the future. > > So use it for info but be warned. > > Robert > > On 17 February 2010 05:33, Maxim Treskin wrote: >> Hello >> >> Sometime I have writing code with nested lambda-functions and >> list-comprehensions. >> If this code contains, I have such stacktraces in crash report: >> >> ? ?exception exit: {function_clause, >> ? ? ? ? ? ? ? ? ? ? ? ?[{asg_alt,'-amm_handle_ev/3-fun-5-', >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? [undefined,#Fun, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?pass]}, >> ? ? ? ? ? ? ? ? ? ? ? ? {asg_alt,'-amm_handle_ev/3-lc$^3/1-3-',2}, >> ? ? ? ? ? ? ? ? ? ? ? ? {asg_alt,'-amm_handle_ev/3-lc$^3/1-3-',2}, >> ? ? ? ? ? ? ? ? ? ? ? ? {asg_alt,amm_handle_ev,3}, >> ? ? ? ? ? ? ? ? ? ? ? ? {asg_pd,state_ready,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? {gen_fsm,handle_msg,7}, >> ? ? ? ? ? ? ? ? ? ? ? ? {proc_lib,init_p_do_apply,3}]} >> >> Is there any way to understand which of lambda crashes? So, when >> function contains '-lc$' I can say that this is list-comprehension >> function, '/3' - ?arity of top function, but what means '^3/1-3-' and >> '-fun-5-' ? Is this values has some relation with order of its >> definition or not? >> >> Thank you >> >> -- >> Maxim Treskin >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > -- Maxim Treskin From rtrlists@REDACTED Wed Feb 17 17:40:51 2010 From: rtrlists@REDACTED (Robert Raschke) Date: Wed, 17 Feb 2010 16:40:51 +0000 Subject: [erlang-questions] What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> Message-ID: <6a3ae47e1002170840u3bf70160lb49b17e09ed05d5f@mail.gmail.com> On Wed, Feb 17, 2010 at 3:52 PM, Michael Turner wrote: > > So when when the > >documentation is organised around "applications", in one sense, it is > >being entirely logical and consistent. Of course, until you are more > >experienced and groked this it can be very confusing and difficult to > >find things. > > But in the meantime, conceptual/terminological confusion impedes the > learner, whenever he/she needs to resort to the Reference Manual. Given > that Erlang already poses quite a learning curve for some, this will > reduce the rate at which people become "more experienced and grok > this", and for that matter, it will reduce the number of people who > even want to get that far with Erlang. > Learning Erlang _requires_ you to be open to new concepts and terminology. Erlang is not Java. Erlang is not C. The terminology is explained quite well in the Erlang documentation. But effort on the side of the learner is actually mandatory. This effort lies in reading the documentation and experimenting with the system to cement your understanding of the text. None of the programming language manuals I know are didactic texts. Well, saying that, I've just remembered the original Smalltalk books; they're pretty fine. This does not mean we should not strive for great documentation. But simply stating that the current set is not good enough won't change that. You don't get quality that way. If you, or someone you know, can help with rearranging the existing documentation such that it becomes qualitatively better, then please pitch in. I'm sure your efforts would be welcomed. I know that I am no good at writing documentation, but then I am also pretty happy with the status quo ... Robby From aleksey@REDACTED Wed Feb 17 17:43:24 2010 From: aleksey@REDACTED (Aleksey Yeschenko) Date: Wed, 17 Feb 2010 18:43:24 +0200 Subject: An NIF example (libiconv binding) Message-ID: <5c6f8a091002170843sd3fb34cm7516086283498706@mail.gmail.com> There aren't many NIF examples, so I've created one: http://github.com/iamaleksey/iconverl It's a simple libiconv wrapper - it uses the latest NIF api (though not ErlNifResourceType for the descriptors, yet). Please fork it if you have something to add. From Antonio.Musumeci@REDACTED Wed Feb 17 17:07:28 2010 From: Antonio.Musumeci@REDACTED (Musumeci, Antonio S) Date: Wed, 17 Feb 2010 11:07:28 -0500 Subject: [erlang-questions] Ports and their owners In-Reply-To: <3dbc6d1c1002170753h1bc47aaau7376dd98ce46ef41@mail.gmail.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64CD84@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170702o8941550l2f6b53d5daabcc5@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64CDD0@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170737h30744638q8df8347b21759dcc@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64CDEE@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170753h1bc47aaau7376dd98ce46ef41@mail.gmail.com> Message-ID: <01489E237C2C8F45AF7898E135F48E8001DA64CE04@NYWEXMBX2129.msad.ms.com> Sure. But we'd like to take advantage of as much of the built in functionality as possible. The less native features we use the more overhead and fewer reasons we have of using erlang. These changes are fairly simple, generic and don't change default behavior and so we hope could be accepted into the main tree. -----Original Message----- From: Robert Virding [mailto:rvirding@REDACTED] Sent: Wednesday, February 17, 2010 10:53 AM To: Musumeci, Antonio S (IT) Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] Ports and their owners On 17 February 2010 16:47, Musumeci, Antonio S wrote: > Yeah... Unfortunately for what I'm doing we'd like security within the node due to running arbitrary modules, cnodes and ports. I've already began work on providing a filtering mechanism for RPC and net_kernel:spawn by moving spawn into rex and adding an optional filter callback which all calls go through. This would at least allow sandboxing the spawning of arbitrary processes to some extent. I'll be posting that to erlang-patches sometime this week. After that I'll take a shot at adding the open_port option I mentioned. > Another soultion would be to NOT use the standard erlang distribution but do it all yourself over tcp. This way you could get full control of what is run within a node and limit what a node is allowed to do. A bit more work maybe and not as transparent but more control. Robert -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. From wde@REDACTED Wed Feb 17 18:13:34 2010 From: wde@REDACTED (wde) Date: Wed, 17 Feb 2010 18:13:34 +0100 Subject: [erlang-questions] Mnesia, disk_log and dets Message-ID: <20100217171338.CDF3070000B7@msfrf2319.sfr.fr> thank you for your feedback. >Hi, > >Ulf knows probably everything about mnesia, I know it rather as a common user, but your ideas seems to be interesting. I would like to have database with mnesia API, but more efficient and more powerful backend... also more flexible and extend-able. I was playing with Mnesiaex but I've had some issues with dependencies and TC (Tokyo Cabinet) was chosen. >?? >Anyway subject is interesting especially from the efficiency point of view. I'm looking forward to seeing your results :) > >-- >rgs, > >Dawid > >Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd >http://www.erlang-solutions.com > > >----- Original Message ----- >From: "wde" >To: "Ulf Wiger" >Cc: "erlang-questions" >Sent: Wednesday, February 17, 2010 7:38:11 AM GMT +00:00 GMT Britain, Ireland, Portugal >Subject: Re: Re: [erlang-questions] Mnesia, disk_log and dets > >ok thank you. > >With Mnesiaex we can have our own storage backend for the ?new "external_copies" type. > >But instead of specifying a new copy type, I'm currently trying to understand how I can integrate a wrapper module >like "mnesia_disc_backend" that handle all disc access (for disc_copies and disc_only_copies) , and do the same thing for the "ram_copy" type, by using a "mnesia_ram_backend" module. > >The idea is to offer more flexibility and easily change the backend for ram and disc I/O. > > >Do you think I'm wasting my time or that there is no interest for something like that ? > > > > > > > > > > > > >>wde wrote: >>> hello, >>> >>> I'm reading the source code of Mnesia to understand how things work >>> :+) If I have understood correctly, for "disc_copies" tables, data >>> are written to disc by using the "disk_log" module. For >>> "disc_only_copies" tables, Mnesia uses "dets". >>> >>> What not use the same disk backend ? >> >>Originally, they did use the same back-end, but it turned out, >>from experimentation, that dumping the entire table using disk_log >>was /much/ faster than writing out the individual changes into >>a dets file. >> >>BR, >>Ulf W >>-- >>Ulf Wiger >>CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd >>http://www.erlang-solutions.com >>--------------------------------------------------- >> >>--------------------------------------------------- >> >>WE'VE CHANGED NAMES! >> >>Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. >> >>www.erlang-solutions.com >> >> > > > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED From sverker@REDACTED Wed Feb 17 18:59:15 2010 From: sverker@REDACTED (Sverker Eriksson) Date: Wed, 17 Feb 2010 18:59:15 +0100 Subject: [erlang-questions] An NIF example (libiconv binding) In-Reply-To: <5c6f8a091002170843sd3fb34cm7516086283498706@mail.gmail.com> References: <5c6f8a091002170843sd3fb34cm7516086283498706@mail.gmail.com> Message-ID: <4B7C2E73.3080602@erix.ericsson.se> Aleksey Yeschenko wrote: > There aren't many NIF examples, so I've created one: > http://github.com/iamaleksey/iconverl > It's a simple libiconv wrapper - it uses the latest NIF api (though > not ErlNifResourceType for the descriptors, yet). > Please fork it if you have something to add Nice! Would be neat with ErlNifResourceType though. Safer and simpler usage as you can skip "close". The garbage collector will take care of that. /Sverker, Erlang/OTP Ericsson From ulf.wiger@REDACTED Wed Feb 17 22:00:43 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 17 Feb 2010 22:00:43 +0100 Subject: [erlang-questions] Mnesia, disk_log and dets In-Reply-To: <20100217073815.513F67000095@msfrf2208.sfr.fr> References: <20100217073815.513F67000095@msfrf2208.sfr.fr> Message-ID: <4B7C58FB.1060108@erlang-solutions.com> wde wrote: > ok thank you. > > With Mnesiaex we can have our own storage backend for the new > "external_copies" type. > > But instead of specifying a new copy type, I'm currently trying to > understand how I can integrate a wrapper module like > "mnesia_disc_backend" that handle all disc access (for disc_copies > and disc_only_copies) , and do the same thing for the "ram_copy" > type, by using a "mnesia_ram_backend" module. > > The idea is to offer more flexibility and easily change the backend > for ram and disc I/O. > > > Do you think I'm wasting my time or that there is no interest for > something like that ? The external_copies concept originated in my rdbms contrib, so it would be silly of me to deny that I at least at one time thought this was a good idea. Two table types I experimented with at the time was a log table and a read-only file system. I don't think that mnesiaex copied the idea of hooking into the table creation operation in mnesia_schema, which allowed the external copy callback to verify custom table properties (such as mount point for the read-only file system). One point of playing with these two tables was that I wanted to experiment with types that had semantics that differed significantly from those of sets and bags. One thing to be very mindful of is that the callbacks for external copies must be error-free. Any crash in these operations will cause a mnesia core dump. This is the only sensible thing to do, as the callback modules are called /after/ commit, i.e. the point of no return as far as consistency is concerned. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From ulf.wiger@REDACTED Wed Feb 17 22:05:05 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Wed, 17 Feb 2010 22:05:05 +0100 Subject: [erlang-questions] Ports and their owners In-Reply-To: <3dbc6d1c1002170702o8941550l2f6b53d5daabcc5@mail.gmail.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64CD84@NYWEXMBX2129.msad.ms.com> <3dbc6d1c1002170702o8941550l2f6b53d5daabcc5@mail.gmail.com> Message-ID: <4B7C5A01.7050102@erlang-solutions.com> Robert Virding wrote: > IIRC port_command was added to bypass the need to communicate via the > port owner process. For what exactly what reason I can't remember. I can. It was for performance, pure and simple. Back in those days, term copying between processes was not quite as well optimized as today, and the computers were slower too (I believe that we were using 400 MHz UltraSPARCS in the AXD 301 then). That extra message just to go via the port owner meant significant overhead, and we were sending lots of messages through the port. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From erlang@REDACTED Wed Feb 17 22:37:16 2010 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 17 Feb 2010 22:37:16 +0100 Subject: [erlang-questions] What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> Message-ID: <9b08084c1002171337k575496f1x282aa58380e16a50@mail.gmail.com> I think the problem with reorganising the documentation is basically one of time and money. The documentation that we have today was originally produced to satisfy the internal needs of Ericsson. It was intended to be used together with courses and on-site mentoring. OTP itself was designed for a specific project, the AXD-301. The gen_servers, etc. were designed to be used in "large projects". A lot of the call-backs (for example, code_change, etc.) are irrelevant (and confusing) for small projects. It was never the intention to design these as a "one-size-fits-all" solution for all problems. The intention was that every individual project would design their own set of generic methods that were customised to their own internal needs. We put hooks in the system to customise virtually everything - people would write their own error_handlers etc. the problem is that nobody ever does this, and many people just use behaviours in ways they were never designed to be used. Section 16.1 of my Erlang book is titled "The road to the Generic Server" - the section starts "This is the most important section in the entire book, so read it one, read it twice, read it 100 times - just make sure the message sinks in". This section develops an (almost) gen_server starting with a very simple server and then applying 4 transformations to the original to arrive at something pretty near to the gen_server. If you've understood this, then understanding the OTP documentation should be easy. But even better, you should be able to custom build you own behaviours. Back to the documentation problem. Funding a massive reorganisation of the OTP documentation within Ericsson is currently inconceivable - this is because the documentation is basically good enough for our internal use. We want to spend time on things that generate revenue, not documentation. We are in no-mans land here. The problem is too big to do it with small amounts of voluntary effort, and nobody is prepared to fund a professional rewrite. The few people who potentially could do the reorganisation are pretty busy with other stuff. What I would like to see is a big push on the books front. Frasse/Simon and I have done the spade work with an "adequate" description of the language and libraries. What we are lacking are books describing the major applications. Can somebody please write books about: - couchDB (in preparation) - ejabberd - rabbitMQ - mnesia - OTP - mochiweb - scalaris/riak Or a book with one chapter devoted to each (mail Dave Thomas if you want a publisher :-) Since all the OTP documentation is nicely tagged up in XML it might be possible to make a sub-language to assemble the existing documentation into a different structure, with a better organisation. Most of the real Erlang "experts" (ie those who make a living out of the Erlang programs they write) - just don't have time to write improved documentation - nor does it pay - the products are far more profitable (the Guys at Klarna, for example, know enough to do this but it is far more profitable for them to hack Erlang - and anyway their company is doubling in size every year - or something daft) Right now I'd like to see more application books - so get you pens out. /Joe On Wed, Feb 17, 2010 at 4:52 PM, Michael Turner wrote: > > > On 2/17/2010, "Robert Virding" wrote: > >>Without getting into the discussion how difficult, or not, it is to >>navigate the Erlang docs one source of the problem is that all the >>standard OTP libraries are proper Applications. > > People should think of the trigonometric functions as part of the STDLIB > Application, just because gen_server is grouped in with them, in stdlib? > > What sense does this make? > >> So when when the >>documentation is organised around "applications", in one sense, it is >>being entirely logical and consistent. Of course, until you are more >>experienced and groked this it can be very confusing and difficult to >>find things. > > But in the meantime, conceptual/terminological confusion impedes the > learner, whenever he/she needs to resort to the Reference Manual. ?Given > that Erlang already poses quite a learning curve for some, this will > reduce the rate at which people become "more experienced and grok > this", and for that matter, it will reduce the number of people who > even want to get that far with Erlang. > > What sense does this make? > > What goal does this serve? > > The goal of making it easier to autogenerate the documentation? > > Well, I remember the days when we humans did a lot of things to make life > easier for the system. ?As I recall, it involved punching a lot of cards. > > > -michael turner > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From gleber.p@REDACTED Wed Feb 17 23:06:34 2010 From: gleber.p@REDACTED (Gleb Peregud) Date: Wed, 17 Feb 2010 23:06:34 +0100 Subject: Integer endianness in binaries Message-ID: <14f0e3621002171406n4a34f44ch9b99e5e6cb6a9011@mail.gmail.com> Hello. These [0,0,0,0,0,0,0,1] = [ X || <> <= <<1>> ]. [0,0,0,0,0,0,1,0] = [ X || <> <= <<2>> ]. [0,0,0,0,0,0,1,1] = [ X || <> <= <<3>> ]. [0,0,0,0,1,1,1,1,0,0,0,0,0,0,0,0] = [ X || <> <= <<15:2/little-integer-unit:8>> ]. are true and does not fail. But this: > [0,0,0,1,1,1,1,0,0,0,0,0,0,0] = [ X || <> <= <<15:2/little-integer-unit:7>> ]. ** exception error: no match of right hand side value [0,0,0,0,1,1,1,1,0,0,0,0,0,0] fails with given badmatch. Why is it so? Am I missing something? Shouldn't <<15:2/little-integer-unit:7>> be the same as <<15:7, 0:7>> ? Instead it is equal to <<15:8, 0:6>>. Best regards, Gleb -- Gleb Peregud Green Elephant Labs From g@REDACTED Wed Feb 17 23:12:44 2010 From: g@REDACTED (Garrett Smith) Date: Wed, 17 Feb 2010 16:12:44 -0600 Subject: [erlang-questions] Missing The Point Of Documentation In-Reply-To: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> References: <4B7B8013.70003@krondo.com> <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> Message-ID: On Wed, Feb 17, 2010 at 12:40 AM, Bob Ippolito wrote: > On Wed, Feb 17, 2010 at 12:35 AM, Dave Peticolas wrote: >> I think a global module index, like the one for the built-in >> Python modules, would be useful, both for quickly finding the >> module you already know the name of, and for browsing to see >> just what is available: >> >> ?http://docs.python.org/modindex.html > > http://erlang.org/doc/man_index.html > > It's the "Modules" hyperlink in the left frame of the docs. I've switched over to using: http://erldocs.com for reference lookups. This is almost as fast/convenient as auto-complete in Emacs with distel that I could never quite get working. Garrett From erlang@REDACTED Wed Feb 17 23:25:57 2010 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 17 Feb 2010 23:25:57 +0100 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> Message-ID: <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> On Wed, Feb 17, 2010 at 11:27 AM, Michael Turner wrote: > > > On 2/17/2010, "Bob Ippolito" wrote: > >>On Wed, Feb 17, 2010 at 12:35 AM, Dave Peticolas wrote: >>> I think a global module index, like the one for the built-in >>> Python modules, would be useful, both for quickly finding the >>> module you already know the name of, and for browsing to see >>> just what is available: >>> >>> http://docs.python.org/modindex.html >> >>http://erlang.org/doc/man_index.html >> >>It's the "Modules" hyperlink in the left frame of the docs. > > In the left frame of what pages? ?Only at http://erlang.org/docs? > > I wondered where this page was linked from (who knows? maybe some place > that was intuitively obvious? you can't rule it out), so I clicked on > "Up". > > Dead link. > > (The link next to it is labeled "Erlang", which at that point is like > being in San Francisco and seeing a sign saying, "California".) > > And when you get to the module list, it describes itself not as a module > list, but as "Manual Page Index". ?Not exactly the same thing. > > There are some navigation, nomenclature and comprehension issues here. > >>To be fair, it's not that obvious to find, > > I've run across it before. ?But you shouldn't have to "run across" > it. ?It should be linked from sidebars on every page. ?(And not all > pages have a handy sidebar. ?E.g., the otherwise-relatively-helpful > Applications list, for some reason: > http://erlang.org/doc/applications.html.) > > Side-rant: Why isn't there a search box on EVERY PAGE? Because the code that generated the web site didn't add a search box. The entire site is automatically generated from a large number of XML files. This set of files started off as SGML has migrated to XML and has been formatted via LaTeX and FOP. When we make a new site, or new formatting we try to be very careful not to break old stuff and to phase out stuff that is not used and phase in new stuff - this takes a while. Not having search boxes everywhere - like dead links - is a bug (or a symptom of an underlying problem). About 18 months ago all the documentation was marked up in SGML and not released. The last 18 months efforts was as follows: - change the markup to XML - the PDF generator from LaTeX to FOP - piff up the HTML Subject to the condition "don't break the documention system" So now it's published and gitted and in XML and we can start polishing the rendering engines - adding searches or whatever. Taking out internal SGML and turning it into XML without breaking everything has been top priority - not rendering. > >>The biggest problem with the Erlang module index is that it has no >>context whatsoever about what the modules do (other than the >>semi-arbitrary application they belong to), so if you don't know at >>least part of the name already you won't be able to search for the >>module you want on that page. > > "Semi-arbitrary application" -- well, OK, maybe Erlang/OTP defines the > term "application" somewhere, carrying a sense with which I'm not > familiar, somehow justifying the description of certain libraries as > applications? > > Ah, here it is: http://erlang.org/doc/man/STDLIB_app.html > > "In OTP, application denotes a component implementing some specific > functionality, that can be started and stopped as a unit, and which can > be re-used in other systems as well." > > OK, fine. ?C&S p.264 provide a roughly equivalent definition. So in what > sense dpes STDLIB conform to these definitions? ?Here's what we get > from the reference manual: > > ---- > APPLICATION > > STDLIB > > APPLICATION SUMMARY > > The STDLIB Application > > DESCRIPTION > > The STDLIB is mandatory in the sense that the minimal system based on > Erlang/OTP consists of Kernel and STDLIB. The STDLIB application > contains no services. > ---- > > "No services" meaning that there's nothing to stop and start? ?If so, > why call STDLIB an "application" even in the Erlang sense? ?It's > bizarre enough to me that even Kernel is called an "application," but > I *can* bend my brain around it. ?A library that just sits there, though? > > I find myself wondering if there was a time, back when Ericsson was > trying to commercialize Erlang, when some marketing airhead went nuts > trying to get the word "application" used everywhere, perhaps because > when he talked to Erlang programmers they all sounded dangerously > theoretical to him. Marketing airhead - no. The only marketing people just tried to sell Erlang - they had no influence on the terminology. "Application" was just a name for a "directory with stuff in it" that obeyed certain principles. Things inside an application could be started and stopped, code in an application could be changed and so on. Most applications were active (things like databases, web servers etc) - some were pure code (stdlib) - the pure code directories (about 5% of the total) were anomalies - so we shoe-horned them into applications - to make everything consistent. A bit silly because you can't stop and start a library, but you can code_change it :-) ?Why, with STDLIB and some other libraries suddenly > reclassified as "applications," he could talk about how the number of > applications written in Erlang was growing by leaps and bounds! > > Cool languages attract smart programmers, and Erlang is cool. ?But as the > saying goes, you only get one chance to make a first impression. ?How > many smart programmers, drawn in by the buzz about Erlang, land at > www.erlang.org, browse a little, feel puzzled by the strange use of > terms, end up frustrated by difficulties in navigation, then maybe > bookmark it but never really come back? No idea - personally I find most language websites pretty incomprehensible - I have never found leaning any new language a pain-free process - I have spent most of my working life staring at strange error messages wondering what they mean. If you're put off by strange terms, lousy documentation, incorrect examples, code that doesn't work, explanations that are plain wrong and idiotic specifications you shouldn't be a programmer. In my book a "smart programmer" is one who despite these minor obstacles can figure out how things work. Would you hire a "smart programmer" who rejected a language because the documentation was crap? One sign of a smart programmer is that they recognize that the documentation *is* crap. If I found a programmer who said "this documentation is great" I would be really suspicious - don't hire this guy :-) Sounds like you're a smart programmer, having found the odd inconsequential wart in our otherwise incomparably magnificent documentation. Cheers /Joe > > -michael turner > > > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From kiszl@REDACTED Wed Feb 17 23:56:18 2010 From: kiszl@REDACTED (Zoltan Lajos Kis) Date: Wed, 17 Feb 2010 23:56:18 +0100 Subject: [erlang-questions] Integer endianness in binaries In-Reply-To: <14f0e3621002171406n4a34f44ch9b99e5e6cb6a9011@mail.gmail.com> References: <14f0e3621002171406n4a34f44ch9b99e5e6cb6a9011@mail.gmail.com> Message-ID: <4B7C7412.5090603@tmit.bme.hu> Hi, I think <<15:2/little-integer-unit:7>> simply means: represent integer "15" on 14 (2x7) bits, using little endianness (it does not differ from <<15:14/little-integer-unit:1>>, <<15:1/little-integer-unit:14>> or <<15:7/little-integer-unit:2>>). With 14 bits your first (lower) byte will be complete, but the second (higher) byte will only have 6 bits. 15 can be represented on the lower byte alone, hence the result: 00001111 000000. Note that the bits missing from the last byte are the higher ones; e.g. <<513:10/little-integer-unit:1>> is 00000001 10, while <<1025:10/little-integer-unit:1>> is 00000001 00 as 1024 is not representable on 10 bits. Z. Gleb Peregud wrote: > Hello. > > These > > [0,0,0,0,0,0,0,1] = [ X || <> <= <<1>> ]. > [0,0,0,0,0,0,1,0] = [ X || <> <= <<2>> ]. > [0,0,0,0,0,0,1,1] = [ X || <> <= <<3>> ]. > [0,0,0,0,1,1,1,1,0,0,0,0,0,0,0,0] = [ X || <> <= > <<15:2/little-integer-unit:8>> ]. > > are true and does not fail. But this: > > >> [0,0,0,1,1,1,1,0,0,0,0,0,0,0] = [ X || <> <= <<15:2/little-integer-unit:7>> ]. >> > ** exception error: no match of right hand side value > [0,0,0,0,1,1,1,1,0,0,0,0,0,0] > > fails with given badmatch. Why is it so? Am I missing something? > Shouldn't <<15:2/little-integer-unit:7>> be the same as <<15:7, 0:7>> > ? Instead it is equal to <<15:8, 0:6>>. > > Best regards, > Gleb > > -- > Gleb Peregud > Green Elephant Labs > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From g@REDACTED Thu Feb 18 00:50:24 2010 From: g@REDACTED (Garrett Smith) Date: Wed, 17 Feb 2010 17:50:24 -0600 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> Message-ID: On Wed, Feb 17, 2010 at 4:25 PM, Joe Armstrong wrote: > Sounds like you're a smart programmer, having found the odd > inconsequential wart in our otherwise incomparably magnificent documentation. I actually agree -- I find the core docs at erlang.org to be excellent. Consider, by comparison, .NET documentation from Microsoft. Say what you will about Microsoft (to yourself please, I'm sure we've all heard it before ;) but they are one of only a handful of companies with the resources to build a platform with very deep documentation and outstanding tools. And, IMO, the .NET docs are practically unusable. Weird that you can execute at a high level and still not be that helpful. And there's the Java docs from Sun. Very good, IMO, but not really that useful, at least by themselves. I'm with Joe -- the solution is more books. Erlang is way to deep a technology/ecosystem to be properly covered in, what, a handful of books to date? Personally, I'm looking forward to the final copy of OTP in Action from Manning. The authors have delved into the "Tao of OTP applications" and, based on the early copy I have, do a good job of filling in pieces that are missing in the online docs. They also get into tooling, which is part of the equation. I also think this is a function of the relative commercial success, or lack thereof, of Erlang applications. Java, C#, PHP, Ruby, etc. have lots of good books because companies are paying developers to use those languages. Hopefully Erlang will move in that direction, but until it does, I think it's reasonable that Erlang developers suck it up and do their best with what's available. Garrett From kagato@REDACTED Thu Feb 18 00:59:05 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Wed, 17 Feb 2010 15:59:05 -0800 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> Message-ID: <2534B0C9-8C10-4A47-BC6F-B4FC82C7188C@souja.net> >> Side-rant: Why isn't there a search box on EVERY PAGE? > > Because the code that generated the web site didn't add a search > box. You are clearly not an interface architect. Considering that this is a serious impediment to learning Erlang (and even using it as we collect more scattered functionality), it should be a priority, and it appears to be one on the erldocs site. The subsequent text seems to indicate that there is limited time and resources to improve docs. That's actually a pretty acceptable answer. > Marketing airhead - no. The only marketing people just tried to sell > Erlang - they had no influence on the terminology. No marketechture. Good thing, that. > "Application" was just a name for a "directory with stuff in it" that > obeyed certain principles. Things inside an application could be > started and stopped, code in an application could be changed and so > on. Most applications were active (things like databases, web servers > etc) - some were pure code (stdlib) - the pure code directories (about > 5% of the total) were anomalies - so we shoe-horned them into > applications - to make everything consistent. A bit silly because > you can't stop and start a library, but you can code_change it :-) The unhelpful thing about terms like "application" and "server" is that everybody seems to think that they are imbued with certain purposes. In this respect, I don't envy you, ask most of this terminology wasn't pinned down when Erlang started using them anyway. Just for clarification, I think the above indicates that "Applications" are a packaging and deployment concept, not a program architecture concept. In other words, at deployment, you deal in these applications; but at runtime, those applications aren't visible. This is confusing in that the term has been co-opted to by the application framework (i.e. the OTP application module), which uses the same name, but has an entirely different purpose (i.e. managing components at runtime). There is some correspondence, but not enough. As if that weren't bad enough, the term has been co-opted AGAIN for the grouping of documentation. This is problematic because the term is now used in three different ways, with each one not being an exact mapping of any of the others. This is extra confusing because, in tiny programs, you actually can have one "deployment" application, one "runtime" application, and one "documentation" application--each with the same name. The metadata for them is also mingled together, even though the individual tools are largely agnostic to the bits they don't use. This makes for some nonintuitive behaviors and a confusing workflow. Of course, it's only when you grow a project (to the size of OTP, for example) that the holes in the conceptualization start to show. "Applications" at runtime (i.e. what you see in appmon), everything seem to be fine. This appears to be the original concept, and seems to be well-factored. Still, it's pretty clear that Erlang's documentation and deployment systems need to be revamped to make this less confusing. Unfortunately, the deployment stuff seems to have critical mass outside of Ericsson, with things like rebar. These projects don't have much inclination to support the existing deployment stuff, so it is unlikely that Ericsson will ever adopt their work. The center of mass for documentation is still at Ericsson. Unfortunately, without a real concern for fixing the overall structure of the documentation, I don't expect to see too much for a while. I don't think that books will help in that respect. They will only make the information necessary to use Erlang more confusing, decentralized, and contradictory. Understanding a language is usually something to do before investing in a book. There's just no excuse for keeping the barrier to entry artificially high. It might seem laughably obvious that someone who isn't willing to pay the money for a good Erlang book has nothing to contribute. This is not true. They taught me Java in college, and I learned Python because the docs were free on the Internet. Guess which one has served me better? Or, more pessimistically, look at the horror that is PHP. Do you think it's been successful because of the books? And don't rely on arguments of technological superiority. If Facebook can be built largely on PHP, that's enough to indicate that we should be trying harder to compete. > No idea - personally I find most language websites pretty > incomprehensible - I have never found leaning any new language > a pain-free process - I have spent most of my working life staring > at strange error messages wondering what they mean. > > If you're put off by strange terms, lousy documentation, incorrect > examples, code that doesn't work, explanations that are plain wrong > and idiotic specifications you shouldn't be a programmer. Wrong. If you're put off by these things, perhaps you shouldn't be a language designer, but there is absolutely no reason that things need to stay difficult. Not every good programmer should have to climb the mountain "because it's there". Putting in a tunnel has a number of benefits, as we can all get started on different mountains that have never been climbed before. > In my book a "smart programmer" is one who despite these minor > obstacles can figure out how things work. I can figure this out. It wastes a lot of my time doing it. > Would you hire a "smart programmer" who rejected a language > because the documentation was crap? I'm still here, right? Look, smart programmers don't need to spend all of their days wrestling with minutia and mundane tasks because their tools are too ill documented and obtuse (which prevents easily developing better tools as well). Smart Programmers don't reject a language because the documentation is crap. They might do so because the people behind the language refuse to make it better. Don't be that guy. See Wheaton's Law. > One sign of a smart programmer is that they recognize that the > documentation *is* crap. Sure. And yet they often go to the documentation first, rather than the source. This is because sometimes you need example code, lists of expected return values, etc. without having to pore through fourteen pages of code. This whole thing got started because of nuances of guards. In this situation, the documentation was less than stellar, and they probably would have had to dig through C to figure this one out. This is not a winning strategy. > If I found a programmer who said "this documentation is great" > I would be really suspicious - don't hire this guy :-) Agreed there. > Sounds like you're a smart programmer, having found the odd > inconsequential wart in our otherwise incomparably magnificent documentation. I applaud your humor, but I'm deadly serious about this. While limited resources are perhaps the best reason for the documentation not being better, please do not trivialize the importance of documentation. Smart Programmers might be identifiable by the ability to succeed despite the documentation. That does not mean that we should deprive them of the unenviable task of being supported by junior programmers (who will *always* read *only* the docs). Perhaps if you had a few of those to work with, they could provide the resources necessary to do things like improve the documentation. I bet they'd do it cheaper than smart programmers. Better yet, they might build their resume until they accidentally become Smart Programmers by osmosis. I'm building businesses on Erlang. My house payment and the food on my family's table is based on this decision. I did it because Erlang has promise, gets a number of things right, and is reasonably open. I did it because Erlang makes some important things easier than Java, Ruby, or Python. I do not want to have to spend my days doing everything by myself because Erlang has a "learning cliff" instead of a "learning curve". I want to be able to scale my programming teams, as well as my programs. Since I'm not an Ericsson employee, I (perhaps ironically) have to be a little more vigilant about shepherding that investment. Please, don't try to justify crap, and don't try to classify anyone who wants it to be better as some sort of mediocre programmer. Just say: * It takes time and money. * Our customers mission critical needs are always our top priority. * When we can make it better, we want to and we will. * We accept patches. Better yet, see if you can find someone in the community that has an idea for a way to organize the docs that makes sense, and then figure out how to roll the information in the old docs into the new ones. Heck, if you want to be really crazy, try re-imagining the structure of your deployment "applications", documentation "applications", and runtime "applications" into something coherent. I think that this is where we need to go, but if we don't know where we're going, we'll never get there. -- Jayson Vantuyl kagato@REDACTED From ulf.wiger@REDACTED Thu Feb 18 01:30:56 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 18 Feb 2010 01:30:56 +0100 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <2534B0C9-8C10-4A47-BC6F-B4FC82C7188C@souja.net> References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> <2534B0C9-8C10-4A47-BC6F-B4FC82C7188C@souja.net> Message-ID: <4B7C8A40.5050306@erlang-solutions.com> Jayson Vantuyl wrote: > > Unfortunately, the deployment stuff seems to have critical mass > outside of Ericsson, with things like rebar. These projects don't > have much inclination to support the existing deployment stuff, so it > is unlikely that Ericsson will ever adopt their work. Actually, rebar makes heavy use of reltool, so there is little conflict there. >> Would you hire a "smart programmer" who rejected a language because >> the documentation was crap? > I'm still here, right? Look, smart programmers don't need to spend > all of their days wrestling with minutia and mundane tasks because > their tools are too ill documented and obtuse (which prevents easily > developing better tools as well). Smart Programmers don't reject a > language because the documentation is crap. They might do so because > the people behind the language refuse to make it better. Don't be > that guy. See Wheaton's Law. In fairness to Joe, he did list a number of things done by the OTP team lately to improve the documentation build chain, and make it open so that the documentation can be improved by the community just like the OTP code now can. > While limited resources are perhaps the best reason for the > documentation not being better, please do not trivialize the > importance of documentation. Again, I'd like to point out Joe's track record. Far from trivializing the importance of documentation he has repeatedly stressed the importance of it. Also, the fact that Joe has authored two of the three existing books on Erlang could also be taken as a hint that he values the written word. > Just say: > > * It takes time and money. * Our customers mission critical needs are > always our top priority. * When we can make it better, we want to and > we will. * We accept patches. I thought this was pretty much the main point that Joe tried to make in the first part of his email. > Better yet, see if you can find someone in the community that has an > idea for a way to organize the docs that makes sense, and then figure > out how to roll the information in the old docs into the new ones. The vital first step needed to enable this was to make the documentation sources and tool chain open. This has now happened. Let's see if that (considerable) effort pays off. It is likely to take a little time, though. > Heck, if you want to be really crazy, try re-imagining the structure > of your deployment "applications", documentation "applications", and > runtime "applications" into something coherent. I think that this is > where we need to go, but if we don't know where we're going, we'll > never get there. Since this seems to be "defend Joe day" (uhm, night), I could also point out that Joe posted a message on this list a while ago where he did /exactly that/. He received criticism by people who felt that the existing framework actually works well and does not need a complete overhaul. I didn't weigh in on that discussion, but am also of the opinion that OTP's application and release framework is for the most part excellent and deserves gradual improvemets rather than dismissal. Some of the names may have been a bit confusing in retrospect, but I think accepting that (small) obstacle in the learning process is a fairly small price to pay. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From jeraymond@REDACTED Thu Feb 18 02:37:55 2010 From: jeraymond@REDACTED (Jeremy Raymond) Date: Wed, 17 Feb 2010 20:37:55 -0500 Subject: [erlang-questions] Missing The Point Of Documentation In-Reply-To: References: <4B7B8013.70003@krondo.com> <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> Message-ID: <59da11981002171737p14d30915k26d4caa6b4a51660@mail.gmail.com> Wow, erldocs is nice. On Wed, Feb 17, 2010 at 5:12 PM, Garrett Smith wrote: > On Wed, Feb 17, 2010 at 12:40 AM, Bob Ippolito wrote: > > On Wed, Feb 17, 2010 at 12:35 AM, Dave Peticolas > wrote: > >> I think a global module index, like the one for the built-in > >> Python modules, would be useful, both for quickly finding the > >> module you already know the name of, and for browsing to see > >> just what is available: > >> > >> http://docs.python.org/modindex.html > > > > http://erlang.org/doc/man_index.html > > > > It's the "Modules" hyperlink in the left frame of the docs. > > I've switched over to using: > > http://erldocs.com > > for reference lookups. This is almost as fast/convenient as > auto-complete in Emacs with distel that I could never quite get > working. > > Garrett > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ttmrichter@REDACTED Thu Feb 18 03:19:09 2010 From: ttmrichter@REDACTED (Michael Richter) Date: Thu, 18 Feb 2010 10:19:09 +0800 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> Message-ID: On 18 February 2010 06:25, Joe Armstrong wrote: > If you're put off by strange terms, lousy documentation, incorrect > examples, code that doesn't work, explanations that are plain wrong > and idiotic specifications you shouldn't be a programmer. > Joe, I'm sorry, but this is likely the single most nonsensical thing I've heard in a long time. It pains me in particular to say this given how much I've enjoyed most everything else I've seen from you, starting with your book. The reason all of this stuff exists is precisely because your so-called "smart programmers" *tolerate* it (and in the worst cases actively *advocate * it!). Why did I put "scare quotes" around the term "smart programmers"? Because I don't find it particularly smart to tolerate (or advocate) practices which drain everybody's productivity time and time and time again. I used to be an avid user of Ruby. I've pretty much back-burnered it * precisely* because of the dire documentation or, rather, more precisely, because of the attitude toward documentation in the Ruby community. (I don't consider "Use the Source, Luser!" to be documentation.) Every time I tried to do anything non-trivial in Ruby I was faced with productivity-draining exercises in frustration as one document said X, another document said Y and the source, when you finally took the plunge, said A, B and C instead. (For today. Tomorrow it might say B, C and D.) I would find myself increasingly working on things other than my problem domain when I really wanted to work on my problem domain. The documentation for Erlang is not great but so far I've not seen the "the source is the documentation" attitude that I've seen from the Ruby camp. There's more professionalism coming out of Ericcson than there is coming from the hobby hackers who make 90%+ of the Ruby camp. Please don't start advocating a Ruby-style approach to docs. It would really hurt to see Erlang go down that path. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. From kenji.rikitake@REDACTED Thu Feb 18 04:11:41 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Thu, 18 Feb 2010 12:11:41 +0900 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> Message-ID: <20100218031141.GA35934@k2r.org> In the message dated Thu, Feb 18, 2010 at 10:18:45AM +0800, Michael Richter writes: > The documentation for Erlang is not great but so far I've not seen the "the > source is the documentation" attitude that I've seen from the Ruby camp. > There's more professionalism coming out of Ericcson than there is coming > from the hobby hackers who make 90%+ of the Ruby camp. Please don't start > advocating a Ruby-style approach to docs. It would really hurt to see > Erlang go down that path. Agreed. One of the big differences between Linux and *BSD is the online manual (shown by man command). *BSD documentation available from the man command is much more consistent and precise. And that's the exact reason why I do not want to convert my FreeBSD systems into something Linux. In my personal impression, Python online docs do fairly well and a bit better than Erlang. Erlang docs are cryptic but tolerable; at least the doc writers try to maintain the consistency as Michael said above. On the other hand, the requirement for how to describe a language has to be changed, as time goes by, as the language itself and the usage changes and evolves. I think we need even more books, as Joe wrote. One of the old examples I should note is that the uselessness of K&R book for C language now; for example, when the 2nd edition came out in late 1980s, there was not much attention on secure programming. Harbison and Steele's "C: A Reference Manual" serves in a much better way. I no longer recommend K&R to C learners. I see only two major books lately on Erlang (Joe's and Francesco-and-Simon's), but even within these two books the interpretation and description of the basic of Erlang completely differ. And I think this difference is a very good thing. I've already preordered two more books about Erlang, and I hope more books will show up. And remember the borders between the books and the online docs are disappearing, as more books are going electronic. Just my 2 JPY worth, Kenji Rikitake From fritchie@REDACTED Thu Feb 18 06:15:42 2010 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 17 Feb 2010 23:15:42 -0600 Subject: Hidden garbage collection triggers? Message-ID: <97340.1266470142@snookles.snookles.com> So, what causes garbage collection? As a longtime Erlang coder, I'm aware of the usual suspects. But I've got a single process that's been running for *hours* that appears to be spending over 99% of its time in garbage collection. It should've finished in a minute or less. I haven't been playing with spawn_opt() or triggering GC manually or changing VM defaults: just using plain R13B03 on a Linux 4-core Opteron box with 8GB RAM, with the defaults, SMP-wise. The VM's OS process size is less than 1GB, with nothing else substantial running on the machine. The process is doing a mostly-sequential read of a file, using fold-style code via fold_a_file() below. That func will read a "hunk", then read a "hunk member" blob, convert the blob to an Erlang term, and prepend to an accumulator list. The hunks are less than 100 bytes each, the "hunk members" in this case are also less than 100 bytes each. The total file size is roughly 300 MBytes. Other than using file:pread() to read the file's data and an optimization kludge using the process dictionary to make file:pread() less painful, there's nothing weird... ... except that the process is GC'ing waaaaay too frequently. One VM scheduler is at 100% CPU consumption. Did I mention it has been running for hours instead of the less-than-one-minute that I expected? According to the backtrace I've got (see below, part 1), the accumulator list is currently about 869,145 elements long. That's far too short to bother the garbage collector very often. When I use process_info(), I see things like this: (foo@REDACTED)108> process_info(pid(0,24664,0)). [{current_function,{prim_file,transform_ldata,1}}, {initial_call,{erlang,apply,2}}, {status,runnable}, {message_queue_len,0}, {messages,[]}, {links,[#Port<0.21682>]}, {dictionary,[{pread_loop,0}, {fold_off,94176412}, {fold_seq,112}]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.144.0>}, {total_heap_size,47828850}, {heap_size,47828850}, {stack_size,65}, {reductions,104258262}, {garbage_collection,[{fullsweep_after,65535},{minor_gcs,0}]}, {suspending,[]}] The minor_gcs count is usually zero, occasionally I see a one. But it's GC'ing madly, 493 out of a sampled 500 milliseconds. (foo@REDACTED)97> {erlang:system_monitor(self(), [{long_gc, 50}, {large_heap, 10*1024*1024}]), timer:sleep(500), erlang:system_monitor(undefined)}. {undefined,ok, {<0.2057.2>,[{large_heap,10485760},{long_gc,50}]}} (foo@REDACTED)98> flush(). Shell got {monitor,<5095.24664.0>,long_gc, [{timeout,243}, {old_heap_block_size,38263080}, {heap_block_size,5135590}, {mbuf_size,0}, {stack_size,66}, {old_heap_size,26134369}, {heap_size,197}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,38263080}, {heap_block_size,5135590}, {mbuf_size,0}, {stack_size,66}, {old_heap_size,26134369}, {heap_size,197}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,38263080}, {heap_block_size,5135590}, {mbuf_size,0}, {stack_size,66}, {old_heap_size,26134369}, {heap_size,367}]} Shell got {monitor,<5095.24664.0>,long_gc, [{timeout,248}, {old_heap_block_size,0}, {heap_block_size,38263080}, {mbuf_size,0}, {stack_size,66}, {old_heap_size,0}, {heap_size,26134894}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,0}, {heap_block_size,38263080}, {mbuf_size,0}, {stack_size,66}, {old_heap_size,0}, {heap_size,26134894}]} ok One tantalizing clue: I almost never see a process dictionary entry for 'pread_hack'. Which suggests that the GC is mostly?/always? happening during my_pread_miss(), which is the only place where the 'pread_hack' key is erased? Badly mangled example code is below, part II. If any readers have managed to read this far and have any thoughts, I'd be grateful. Meanwhile, I'll go review the VM's code.... -Scott --- snip --- snip --- snip --- snip --- snip --- snip --- snip --- =proc:<0.24664.0> State: Scheduled Spawned as: erlang:apply/2 Spawned by: <0.159.0> Started: Wed Feb 17 17:52:42 2010 Message queue length: 1 Message queue: [{#Port<0.21682>,{data,[6,<<16 bytes>>|<<4352 bytes>>]}}] Number of heap fragments: 0 Heap fragment data: 0 Link list: [] Dictionary: [{fold_seq,112},{fold_off,54396731},{pread_loop,0}] Reductions: 100582510 Stack+heap: 6419485 OldHeap: 47828850 Heap unused: 6418334 OldHeap unused: 47828850 Stack dump: Program counter: 0x00002aaaac842dd8 (prim_file:drv_get_response/1 + 72) CP: 0x0000000000000000 (invalid) arity = 0 0x00002aab1fac0f18 Return addr 0x00002aaaac83f708 (prim_file:pread/3 + 560) y(0) [] y(1) #Port<0.21682> 0x00002aab1fac0f30 Return addr 0x00002aaaadeedba0 (gc_by_the_zillions:my_pread_miss/3 + 784) 0x00002aab1fac0f38 Return addr 0x00002aaaadeecc78 (gc_by_the_zillions:my_pread2/4 + 2152) y(0) [] y(1) [] y(2) 54397789 y(3) {file_descriptor,prim_file,{#Port<0.21682>,32}} y(4) [] 0x00002aab1fac0f68 Return addr 0x00002aaaadee2830 (gc_by_the_zillions:read_hunk_summ_ll_middle/3 + 480) y(0) <<4352 bytes>> y(1) [] y(2) [] y(3) 256 y(4) [] y(5) [] y(6) [] 0x00002aab1fac0fa8 Return addr 0x00002aaaadee6968 (gc_by_the_zillions:fold_a_file/6 + 176) y(0) 54397789 y(1) {file_descriptor,prim_file,{#Port<0.21682>,32}} y(2) [] 0x00002aab1fac0fc8 Return addr 0x00002aaaadef3de0 (gc_by_the_zillions:'-fold2/5-fun-0-'/5 + 936) y(0) [] y(1) [] y(2) [] y(3) [] y(4) [] y(5) {wb,869145,[{eee,tab2_ch18_b2,2,21979760,<<4 bytes>>,7742,110,[<<51 bytes>>,[<<59 bytes>>],[]]},{eee,tab2_ch18_b2,2,21979650,<<4 bytes>>,7742,110,[<<51 bytes>>,[<<59 bytes>>],[]]},{eee,tab2_ch3_b2,2,21485970,<<4 bytes>>,7742,110,[<<51 bytes>>,[<<59 bytes>>],[]]},...backtrace won't print everything... --- snip --- snip --- snip --- snip --- snip --- snip --- snip --- -module(gc_by_the_zillions). -define(MY_PREAD_MODEST_READAHEAD_BYTES, 4096). -define(MAX_HUNK_HEADER_BYTES, 256). -export([bummer/0]). -record(wb, { count = 0, ts = [] }). %% This code as been edited for brevity, some vars renamed, some %% constants changed (if the number looks weird, it's intentionally %% fake), and some functions (harmless, I hope) are omitted. It %% probably won't compile, I haven't tried to. bummer() -> Fun = fun(#hunk_summ{seq = SeqNum, off = Offset} = _H, _FH, _WB) when SeqNum == OldSeqNum, Offset < OldOffset -> {{{new_offset, OldOffset}}}; (#hunk_summ{seq = SeqNum, off = Offset} = _H, _FH, WB) when {SeqNum, Offset} >= {StopSeqNum, StopOffset} -> WB; % ignore later hunks (#hunk_summ{type = ?LOCAL_RECORD_TYPENUM, u_len = [_BLen]} = H, FH, #wb{count = Count, ts = Ts} = WB) -> UBlob = read_hunk_member_ll(FH, H, not_checksum, 1), T = binary_to_term(UBlob), WB#wb{count = Count + 1, ts = [T|Ts]}; (_H, _FH, WB) -> WB % ignore this hunk end, {ok, FH} = file:open("blar", [read]), fold_a_file(FH, 99888777, 7, 12, Fun, #wb{}). fold_a_file(FH, LogSize, SeqNum, Offset, Fun, Acc) -> case read_hunk_summ_ll(FH, Offset) of {ok, H} -> H2 = H#hunk_summ{seq = SeqNum, off = Offset}, put(fold_seq, SeqNum), % Visibility from the outside world, e.g. put(fold_off, Offset), % process_info(Pid, dictionary). {Acc2, NewOff} = case Fun(H2, FH, Acc) of {{{new_offset, NewO}}} -> {Acc, NewO}; Aa -> {Aa, H2#hunk_summ.off + H2#hunk_summ.len} end, if NewOff >= LogSize -> Acc2; true -> fold_a_file(FH, LogSize, SeqNum, NewOff, Fun, Acc2) end; {bof, NewOffset} -> fold_a_file(FH, LogSize, SeqNum, NewOffset, Fun, Acc); eof -> Acc; Err -> throw(Err) end. read_hunk_summ_ll(FH, Offset) -> my_pread_start(), read_hunk_summ_ll(FH, Offset, 0). read_hunk_summ_ll(FH, Offset, HunkLenHint) -> my_pread_start(), read_hunk_summ_ll_middle(FH, Offset, HunkLenHint). read_hunk_summ_ll_middle(FH, Offset, HunkLenHint) -> ReadAheadBytes = HunkLenHint + ?MY_PREAD_MODEST_READAHEAD_BYTES, read_hunk_summ_ll2(my_pread(FH, Offset, ?MAX_HUNK_HEADER_BYTES, ReadAheadBytes), FH, Offset). read_hunk_summ_ll2({ok, Bin}, FH, Offset) -> Hdr = hunk_header_v1(), case Bin of <> when Foo == Hdr -> % !@#$! compiler warning <<_:4/binary, HunkLen:32, LenBinT:32, TypeNum:32, Rest/binary>> = Bin, HdrLen = omitted_fun___len(Hdr), First_off = HdrLen + 9982372 + LenBinT, if LenBinT > size(Rest) -> %% Some arithmetic, then... read_hunk_summ_ll_middle(FH, Offset, First_off); true -> <> = Rest, {Xs, Ys, Zs} = binary_to_term(BinT), {ok, #hunk_summ{len = HunkLen, type = TypeNum, ys = Ys, zs = Zs, xs = Xs, first_off = First_off}} end; _X -> {error, bad_hunk_header, _X} end; read_hunk_summ_ll2(Result, _FH, _Offset) -> Result. % eof, {error, loop_broken}, ... hunk_header_v1() -> <<"Mumble">>. %% I'm not particularly proud of this code, but it's much more %% effective than calling file:pread() to march through reading a %% big file (e.g. 100MB) via file:pread(FH, Offset, Bytes) where %% Bytes is something really small, like 120. my_pread_start() -> put(pread_loop, 0). my_pread(FH, Offset, Len, LenExtra) when Len >= 0 -> case get(pread_loop) of N when N < 5 -> my_pread2(FH, Offset, Len, LenExtra); _ -> {error, loop_broken} end; my_pread(FH, Offset, Len, LenExtra) when Len < 0 -> my_pread(FH, Offset, 0, LenExtra). my_pread2(FH, Offset, Len, LenExtra) -> case get(pread_hack) of {FH, _BinOff, eof} -> my_pread_miss(FH, Offset, Len + LenExtra), case get(pread_hack) of % This Offset is probably not the old one. {_, _, eof} -> eof; % Avoid infinite loop: new offset is also at/past eof. _ -> my_pread(FH, Offset, Len, 0) end; {FH, BinOff, {ok, Bin}} -> BinLen = size(Bin), if Offset >= BinOff andalso Offset+Len =< BinOff+BinLen -> PrefixLen = Offset - BinOff, <<_:PrefixLen/binary, B:Len/binary, _/binary>> = Bin, {ok, B}; true -> case my_pread_miss(FH, Offset, Len + LenExtra) of {ok, Bin} when is_binary(Bin) -> BinSize = size(Bin), if BinSize >= Len -> <> = Bin, {ok, Bin2}; BinSize < Len -> {ok, Bin}; true -> {ok, Bin} end; Err -> Err end end; undefined -> my_pread_miss(FH, Offset, Len + LenExtra), my_pread(FH, Offset, Len, 0); {OtherFH, _, _} when OtherFH /= FH -> my_pread_miss(FH, Offset, Len + LenExtra), my_pread(FH, Offset, Len, 0); {_, _, Res} -> Res end. my_pread_miss(FH, Offset, Len) -> erase(pread_hack), AheadLen = 0, HackLen = AheadLen + Len, X = file:pread(FH, Offset, HackLen), put(pread_hack, {FH, Offset, X}), X. --- snip --- snip --- snip --- snip --- snip --- snip --- snip --- ... back when the process was younger, the GCs were "only" 150-160 milliseconds each time. Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,0}, {heap_block_size,24488375}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,0}, {heap_size,20020492}]} Shell got {monitor,<5095.24664.0>,long_gc, [{timeout,149}, {old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20020455}, {heap_size,201}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20020455}, {heap_size,201}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20020455}, {heap_size,371}]} Shell got {monitor,<5095.24664.0>,long_gc, [{timeout,159}, {old_heap_block_size,0}, {heap_block_size,24488375}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,0}, {heap_size,20020984}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,0}, {heap_block_size,24488375}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,0}, {heap_size,20020984}]} Shell got {monitor,<5095.24664.0>,long_gc, [{timeout,150}, {old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20020947}, {heap_size,201}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20020947}, {heap_size,201}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20020947}, {heap_size,371}]} Shell got {monitor,<5095.24664.0>,long_gc, [{timeout,159}, {old_heap_block_size,0}, {heap_block_size,24488375}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,0}, {heap_size,20021476}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,0}, {heap_block_size,24488375}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,0}, {heap_size,20021476}]} Shell got {monitor,<5095.24664.0>,long_gc, [{timeout,149}, {old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20021439}, {heap_size,201}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20021439}, {heap_size,201}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20021439}, {heap_size,371}]} Shell got {monitor,<5095.24664.0>,long_gc, [{timeout,158}, {old_heap_block_size,0}, {heap_block_size,24488375}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,0}, {heap_size,20021968}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,0}, {heap_block_size,24488375}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,0}, {heap_size,20021968}]} Shell got {monitor,<5095.24664.0>,long_gc, [{timeout,148}, {old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20021931}, {heap_size,201}]} Shell got {monitor,<5095.24664.0>,large_heap, [{old_heap_block_size,30610465}, {heap_block_size,4108475}, {mbuf_size,0}, {stack_size,64}, {old_heap_size,20021931}, {heap_size,201}]} From ttmrichter@REDACTED Thu Feb 18 06:16:08 2010 From: ttmrichter@REDACTED (Michael Richter) Date: Thu, 18 Feb 2010 13:16:08 +0800 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <20100218031141.GA35934@k2r.org> References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> <20100218031141.GA35934@k2r.org> Message-ID: On 18 February 2010 11:11, Kenji Rikitake wrote: > I see only two major books lately on Erlang (Joe's and > Francesco-and-Simon's), but even within these two books the > interpretation and description of the basic of Erlang completely differ. > And I think this difference is a very good thing. I've already > preordered two more books about Erlang, and I hope more books will show > up. > There is a reason why I own hardcopy of both books despite the difficulties and expense involved in getting them to me. Both books have been (and still are) valuable sources of thinking The Erlang Way for me. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. From ok@REDACTED Thu Feb 18 06:32:59 2010 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 18 Feb 2010 18:32:59 +1300 Subject: -define Message-ID: I've been trying out a weak pretty-printer for Erlang. (By "weak" I mean that it takes care of indentation but does not do anything about line breaking.) It's supposed to be something I can build into my text editor. When I tried feeding other people's Erlang code into it, I ran into some problems. I was aware that when you write -define(LHS, RHS). the stuff in RHS did not have to be bracket balanced, so that -define(LP, (). -define(RP, )). are OK. What I was *not* aware of was that there doesn't even have to be a closing right parenthesis at all. -module(ick). -export([ick/0]). -define(ICK, {1}. ick() -> ?ICK. The Erlang compiler is perfectly happy with this. There are several occurrences of this in the Erlang/OTP sources, but there doesn't seem to be any reason why. From leap@REDACTED Thu Feb 18 07:07:44 2010 From: leap@REDACTED (Michael Turner) Date: Thu, 18 Feb 2010 06:07:44 +0000 Subject: Yet more about making sense In-Reply-To: <6a3ae47e1002170840u3bf70160lb49b17e09ed05d5f@mail.gmail.com> Message-ID: > Learning Erlang _requires_ you to be open to new concepts and > terminology. Erlang is not Java. Erlang is not C. Yes, but when the documentation uses *old* terminology (we all know what "stdlib" implies from learning other languages), evoking *old* concepts, it's going to confuse people. Everybody already knows what a library is. Most of Erlang stdlib actually matches those preconceptions. But the reference manual itself says that stdlib has no services, so stdlib doesn't even conform to the reference manual's own definition of application. Tell me there's even ONE good thing about that picture. Really. Go ahead. Defend it. What's good about it? I'm open to the idea of "application" meaning something more abstract in Erlang. But you know what? You don't get to that until over halfway through C&R, where they define what an *OTP* application is, then say that the word "application" will henceforth mean that. I don't know at what point it's introduced in Joe's book -- "application" doesn't even have a freestanding index entry. I'm open to new terminology and new concepts. I'm not very open to people failing to clearly *re*-define terms that have more usual senses, well before they are used routinely, as they are in the Reference Manual TOC. And I started using the Reference Manual long before I ran across definitions of the term "application" in the OTP sense, in the books. So why would it occur to me to look under "Basic Applications" if I was trying to get information about a string function? > The terminology is explained quite well in the Erlang documentation. IF you can find those explanations. IF they are indexed properly. IF they are introduce in the right order. > But effort on the side of the learner is actually mandatory. Actually, it's not. Most learners of Erlang aren't learning it for their job. Most are learning it out of personal interest. It's not mandatory for me to use Erlang for what I'm interested in. The more poorly the documentation is organized, the more likely it is I'll switch to another language. I can hardly be alone in this. There'd be no job listings today for Python or Perl if it wasn't for people taking those language up out of personal interest. > This effort lies in reading the documentation and experimenting > with the system to cement your understanding of the text. You're explaining how to learn a programming language to someone who's written non-trivial code in over half a dozen languages, one with decades of experience. What those decades of experience are telling me is: Erlang's documentation needs some serious work. > None of the programming language manuals I know are didactic > texts. Well, saying that, I've just remembered the original > Smalltalk books; they're pretty fine. Probably because they realized that good writing is part of the sale. Go click the link for the STDLIB pdf. Start reading. It has a *one-line* introduction. Then it dives straight into some small module, chosen in no particular order, full of typos, and so obscure that it was used for years without being included. If you defocus your eyes, that PDF *looks* like the chapter of a properly organized book. But it's not. > This does not mean we should not strive for great documentation. > But simply stating that the current set is not good enough won't > change that. I didn't "simply state that it's not good enough." I've pointed out very specific problems. I find very specific problems almost everywhere I look in the Reference Manual. > You don't get quality that way. If you, or someone you know, > can help with rearranging the existing documentation such that > it becomes qualitatively better, then please pitch in. I'm going to. But look, put yourself in my position. Let's say you've gotten interested in the very powerful programming language Frob. You've learned some of it, which hasn't been so hard because you had already learned Lisp, Prolog, Smalltalk, Python and Perl, and the tutorials aren't half-bad (excellent in places). But the TOC for the reference manual (which you're already starting to need after only a few weeks, because the books and tutorials necessarily skim some subjects) just seems unnecessarily newbie-hostile. You point out that Frob/OTP Introduction Standard Library Progamming Tools OTP Administration or something like that, would be a better top-level TOC organization, in part because it avoids repeated use of a *redefined technical term* ("library") in the headings. Because, you see, in Frob parlance, you "library" actual means what most programmers mean by the term "database". But you don't learn distinction that until halfway through Frob Programming and Programming Frob, the major titles on the subject. One of those books doesn't even have the term in its index. And let's say you that, after making this suggestion, you mostly meet objections like, "The Frob docs are great! Hats off to the authors!" "There are lots of good books and tutorials now!" "Don't you know how to learn a difficult programming language? You need to have an open mind and it takes work!" "The present Reference Manual TOC is perfectly consistent within our own conceptual framework." How would you feel? I think you'd be feeling how I feel right now. Admittedly, some other people have said some more sensible things than the above. And in that, there's some hope. I've done a lot of programming in my life. I've also done a lot of proofreading and editing, helping people produce whole books in some cases. (Very recently, I've done editing on books for free, on projects I like.) I've published articles on a number of topics. And I like Erlang, I even submitted a patch to make it build on a problematic platform (well, Kenji had to shepherd it the rest of the way through), and that took me days of narrowing down the location in the code because the bug trashed the stack, forcing me to "binary search" the cause with printfs instead of using the debugger. I'm willing to help on the documention. I think I've got the chops, both as as an editor and as a programmer. I'm willing to do for free. But one thing I don't do: I don't try to help people suffering from a see-no-evil attitude. That's just the road to burnout. -michael turner From mats.westin@REDACTED Thu Feb 18 08:23:23 2010 From: mats.westin@REDACTED (Mats) Date: Thu, 18 Feb 2010 08:23:23 +0100 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <20100218031141.GA35934@k2r.org> References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <9b08084c1002171425y232da7aerb237c71ee2a16d10@mail.gmail.com> <20100218031141.GA35934@k2r.org> Message-ID: If we are going to change things for the better, we need to take a look at the MySQL documentation[1]. It has a excellent feedback system on every page. (user comments). This will make the documentation better really fast, compared to static html. /Mats [1] http://dev.mysql.com/doc/refman/5.5/en/select.html From humaira.surve@REDACTED Thu Feb 18 09:21:59 2010 From: humaira.surve@REDACTED (Humaira Surve) Date: Thu, 18 Feb 2010 10:21:59 +0200 Subject: Newbie - eldap and threads Message-ID: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> Hi, I've recently began playing around with erlang and come from a java background. I was quite impressed by the eldap library and its general simplicity to use. I have a question though. If one opens a single connection and binds, but has multiple clients sending requests through this one connection, is there a possiblity of thread-related issues. What guarantees that a client gets the correct response or that a response is not over-written by more than one simultaneous request? I have looked through the eldap code and noticed that a single connection uses a TCP file descriptor. Assistance/explanations would really be appreciated. If you know of a useful, simple tutorial I'd appreciate that to. Regards, Humaira From clist@REDACTED Thu Feb 18 09:52:13 2010 From: clist@REDACTED (Angel Alvarez) Date: Thu, 18 Feb 2010 09:52:13 +0100 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <20100218031141.GA35934@k2r.org> Message-ID: <201002180952.13285.clist@uah.es> El Jueves, 18 de Febrero de 2010 08:23:23 Mats escribi?: > If we are going to change things for the better, we need to take a look at > the MySQL documentation[1]. It has a excellent feedback system on every > page. (user comments). > This will make the documentation better really fast, compared to static > html. > > /Mats > > [1] http://dev.mysql.com/doc/refman/5.5/en/select.html > Maybe we could pick a good collaborative tool and spread the work bettween many people... i think the current way (code -> XML -> docs?) is not so flexible for this approach... A community edition for the docs would allow OTP people to keep maintaining the old style docs and relaying on them while, a more open and fresh edition would grow up over the time with collaborations from great erlang people and many comments, and addenda from the plain users base. Ive seen many people blogging about diferent aspects of erlang and some of them writing good introductory materials for the language. Its just matter of organize the workforce in a more productive way.. /Angel -- No imprima este correo si no es necesario. El medio ambiente est? en nuestras manos. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Nunca pude estudiar derecho... (El jorobado de Notredame). From wde@REDACTED Thu Feb 18 10:41:55 2010 From: wde@REDACTED (wde) Date: Thu, 18 Feb 2010 10:41:55 +0100 Subject: [erlang-questions] Mnesia, disk_log and dets Message-ID: <20100218094155.6E4E7700009F@msfrf2118.sfr.fr> are there other documents about mnesia internals, other than those : http://www.erlang.org/~hakan/ ? >wde wrote: >> ok thank you. >> >> With Mnesiaex we can have our own storage backend for the new >> "external_copies" type. >> >> But instead of specifying a new copy type, I'm currently trying to >> understand how I can integrate a wrapper module like >> "mnesia_disc_backend" that handle all disc access (for disc_copies >> and disc_only_copies) , and do the same thing for the "ram_copy" >> type, by using a "mnesia_ram_backend" module. >> >> The idea is to offer more flexibility and easily change the backend >> for ram and disc I/O. >> >> >> Do you think I'm wasting my time or that there is no interest for >> something like that ? > >The external_copies concept originated in my rdbms contrib, so >it would be silly of me to deny that I at least at one time thought >this was a good idea. Two table types I experimented with at the >time was a log table and a read-only file system. I don't think that >mnesiaex copied the idea of hooking into the table creation operation >in mnesia_schema, which allowed the external copy callback to verify >custom table properties (such as mount point for the read-only file >system). One point of playing with these two tables was that I >wanted to experiment with types that had semantics that differed >significantly from those of sets and bags. > >One thing to be very mindful of is that the callbacks for external >copies must be error-free. Any crash in these operations will cause >a mnesia core dump. This is the only sensible thing to do, as the >callback modules are called /after/ commit, i.e. the point of no >return as far as consistency is concerned. > >BR, >Ulf W >-- >Ulf Wiger >CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd >http://www.erlang-solutions.com >--------------------------------------------------- > >--------------------------------------------------- > >WE'VE CHANGED NAMES! > >Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. > >www.erlang-solutions.com > > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From rvirding@REDACTED Thu Feb 18 11:49:38 2010 From: rvirding@REDACTED (Robert Virding) Date: Thu, 18 Feb 2010 11:49:38 +0100 Subject: [erlang-questions] -define In-Reply-To: References: Message-ID: <3dbc6d1c1002180249j7530b42dl197da5e68f546722@mail.gmail.com> There is a simple reason for this: sheer laziness by the original writer of the epp module, me. Now I suppose it is difficult to change because of backwards compatibility. The problem is compounded byt the feature that macro expansions don't have to be complete erlang expressions so sometimes you can't tell the macro definition is over until you hit the '.' . Robert On 18 February 2010 06:32, Richard O'Keefe wrote: > I've been trying out a weak pretty-printer for Erlang. > (By "weak" I mean that it takes care of indentation but > does not do anything about line breaking.) ?It's supposed > to be something I can build into my text editor. > > When I tried feeding other people's Erlang code into it, > I ran into some problems. > > I was aware that when you write > > ? ? ? ?-define(LHS, RHS). > > the stuff in RHS did not have to be bracket balanced, so > that > ? ? ? ?-define(LP, (). > ? ? ? ?-define(RP, )). > > are OK. > What I was *not* aware of was that there doesn't even have > to be a closing right parenthesis at all. > > -module(ick). > -export([ick/0]). > -define(ICK, {1}. > > ick() -> ?ICK. > > The Erlang compiler is perfectly happy with this. > There are several occurrences of this in the Erlang/OTP sources, > but there doesn't seem to be any reason why. > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ulf.wiger@REDACTED Thu Feb 18 12:01:29 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 18 Feb 2010 11:01:29 +0000 (GMT) Subject: [erlang-questions] -define In-Reply-To: <3dbc6d1c1002180249j7530b42dl197da5e68f546722@mail.gmail.com> Message-ID: <464573922.48461266490889430.JavaMail.root@zimbra> ----- "Robert Virding" wrote: > There is a simple reason for this: sheer laziness by the original > writer of the epp module, me. Now I suppose it is difficult to change > because of backwards compatibility. The problem is compounded byt the > feature that macro expansions don't have to be complete erlang > expressions so sometimes you can't tell the macro definition is over > until you hit the '.' . Well, if you look at the source in epp.erl, it doesn't seem to be that difficult to change: macro_expansion([{')',_Lp},{dot,_Ld}]) -> []; macro_expansion([{dot,_Ld}]) -> []; %Be nice, allow no right paren! macro_expansion([T|Ts]) -> [T|macro_expansion(Ts)]. It ought to be enough to delete the line with the "Be nice" comment, or perhaps modify it to signal an error instead. BR, Ulf W > > Robert > > On 18 February 2010 06:32, Richard O'Keefe wrote: > > I've been trying out a weak pretty-printer for Erlang. > > (By "weak" I mean that it takes care of indentation but > > does not do anything about line breaking.) ?It's supposed > > to be something I can build into my text editor. > > > > When I tried feeding other people's Erlang code into it, > > I ran into some problems. > > > > I was aware that when you write > > > > ? ? ? ?-define(LHS, RHS). > > > > the stuff in RHS did not have to be bracket balanced, so > > that > > ? ? ? ?-define(LP, (). > > ? ? ? ?-define(RP, )). > > > > are OK. > > What I was *not* aware of was that there doesn't even have > > to be a closing right parenthesis at all. > > > > -module(ick). > > -export([ick/0]). > > -define(ICK, {1}. > > > > ick() -> ?ICK. > > > > The Erlang compiler is perfectly happy with this. > > There are several occurrences of this in the Erlang/OTP sources, > > but there doesn't seem to be any reason why. > > > > > > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > See http://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED -- Ulf Wiger CTO, Erlang Training & Consulting Ltd. http://www.erlang-consulting.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From leap@REDACTED Thu Feb 18 11:55:11 2010 From: leap@REDACTED (Michael Turner) Date: Thu, 18 Feb 2010 10:55:11 +0000 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <201002180952.13285.clist@uah.es> Message-ID: On 2/18/2010, "Angel Alvarez" wrote: [snipping interesting proposal by Mats] >Maybe we could pick a good collaborative tool and spread the > work bettween many people... > >i think the current way (code -> XML -> docs?) is not so >flexible for this approach... Yeah, I know. At the moment, on my way to trying to patch some docs, I'm watching something called megaco take forever to build. I have no interest at all in megaco. It's not remotely relevant to my immediate problem. I'm just rebuilding everything from scratch because a "make release_docs" failed, saying it didn't have something called "docb_transform", which (I had to figure out) is written in Erlang. I'm hoping that rebuilding everything gets docb_transform installed in the right place. But the dependencies of components on tools getting moved to the right places aren't reliable in the Erlang build system, in my experience. OK, the clean build's done. I try "make release_docs" again. And again, I get: docb_transform: command not found *Sigh*. I just want to start submitting patches to fix some of those typos in the docs .... [Bangs head against edge of desk.] >A community edition for the docs would allow OTP people to >keep maintaining the old style docs and relaying on them >while, a more open and fresh edition would grow up over >the time with collaborations from great erlang people and >many comments, and addenda from the plain users base. I like the idea. But basically, Ericsson owns Erlang/OTP in every meaningful sense of the term. They just let us look at, and dink around with, their code. They don't even release their test suites, and without those, nobody can realistically hope to take an independent direction with the system. Whatever the community does on Ericsson reference material, it *must* be reflected back into their codebase, for the foreseeable future, otherwise you'll have a fork that's steadily growing incompatible with the Ericsson base reality. And Joe lays it out pretty clearly: unless a customer of Ericsson's is paying for it, there's no funding within the company for anything sweeping. So we can't count on much help from that quarter. >Ive seen many people blogging about diferent aspects of erlang >and some of them writing good introductory materials for the >language. Its just matter of organize the workforce in a more >productive way.. I agree. I don't know what the right solution is. For now, maybe the best we can hope for is to get better handholding, sometimes, for working within the existing framework -michael turner From clist@REDACTED Thu Feb 18 12:40:14 2010 From: clist@REDACTED (Angel Alvarez) Date: Thu, 18 Feb 2010 12:40:14 +0100 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: Message-ID: <201002181240.14756.clist@uah.es> El Jueves, 18 de Febrero de 2010 Michael Turner escribi?: > > On 2/18/2010, "Angel Alvarez" wrote: > > [snipping interesting proposal by Mats] > >Maybe we could pick a good collaborative tool and spread the > > work bettween many people... > > > >i think the current way (code -> XML -> docs?) is not so > >flexible for this approach... > > Yeah, I know. At the moment, on my way to trying to patch some docs, > I'm watching something called megaco take forever to build. I have no > interest at all in megaco. It's not remotely relevant to my immediate > problem. I'm just rebuilding everything from scratch because a "make > release_docs" failed, saying it didn't have something called > "docb_transform", which (I had to figure out) is written in Erlang. > I'm hoping that rebuilding everything gets docb_transform installed in > the right place. But the dependencies of components on tools getting > moved to the right places aren't reliable in the Erlang build system, > in my experience. > > OK, the clean build's done. I try "make release_docs" again. And > again, I get: > > docb_transform: command not found > > *Sigh*. I just want to start submitting patches to fix some of those > typos in the docs .... [Bangs head against edge of desk.] > > >A community edition for the docs would allow OTP people to > >keep maintaining the old style docs and relaying on them > >while, a more open and fresh edition would grow up over > >the time with collaborations from great erlang people and > >many comments, and addenda from the plain users base. > > I like the idea. But basically, Ericsson owns Erlang/OTP in every > meaningful sense of the term. They just let us look at, and dink around > with, their code. They don't even release their test suites, and > without those, nobody can realistically hope to take an independent > direction with the system. Whatever the community does on Ericsson > reference material, it *must* be reflected back into their codebase, for > the foreseeable future, otherwise you'll have a fork that's steadily > growing incompatible with the Ericsson base reality. And Joe lays it > out pretty clearly: unless a customer of Ericsson's is paying for it, > there's no funding within the company for anything sweeping. So we > can't count on much help from that quarter. > > >Ive seen many people blogging about diferent aspects of erlang > >and some of them writing good introductory materials for the > >language. Its just matter of organize the workforce in a more > >productive way.. > > I agree. I don't know what the right solution is. For now, maybe the > best we can hope for is to get better handholding, sometimes, for > working within the existing framework > > -michael turner > > > Well, So we maybe two main problems ahead 1) A more friendly way to the OTP docs *Just plain* no more not less, maybe some improvements on the final part of the toolchain will acomplish it. In other words IMHO we need a far better docs site predating PHP and the like 2) A discutible docs overhaul, as same people want to clarify or just evolve terms like aplications, stdlib and so on... Number 1 is clearly needed to spread erlang and grow a good community of users and developers. Number 2 reflects the nature of change erlang is taking as more and more areas outside telcos embrace erlang and many isolated groups start making foundation in parallel to the main concept so has to be taken and led by the OTP team when they they find time and resources... -- No imprima este correo si no es necesario. El medio ambiente est? en nuestras manos. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Artista -- (internet) --> Usuario final. As? los artistas cobran m?s y dicen menos paridas sobre lo que creen que es la pirater?a. From leap@REDACTED Thu Feb 18 15:00:47 2010 From: leap@REDACTED (Michael Turner) Date: Thu, 18 Feb 2010 14:00:47 +0000 Subject: Need Apache FOP to build *any* docs? Message-ID: I don't have Apache fop on my system. It builds PDFs and I don't need those. However, I do want preview generated HTML before submitting patches, at least. ./otp_build autoconf tells me that the documentation can't be built, because fop is missing. I've been crossing my fingers and hoping this doesn't mean what I'm afraid it means. But *is* fop a dependency for building the html from the xml? -michael turner From dizzyd@REDACTED Thu Feb 18 15:04:10 2010 From: dizzyd@REDACTED (Dave Smith) Date: Thu, 18 Feb 2010 07:04:10 -0700 Subject: [erlang-questions] An NIF example (libiconv binding) In-Reply-To: <4B7C2E73.3080602@erix.ericsson.se> References: <5c6f8a091002170843sd3fb34cm7516086283498706@mail.gmail.com> <4B7C2E73.3080602@erix.ericsson.se> Message-ID: A big thanks to the OTP team for the ErlNifResourceType! :) Indeed, the NIF API is really quite nice now and once it has a way to send messages to other processes, I think most of the ports I wrote will be better done as NIFs (since I typically hand off to other threads for processing). Keep it up OTP team! :) D. On Wed, Feb 17, 2010 at 10:59 AM, Sverker Eriksson wrote: > Aleksey Yeschenko wrote: >> >> There aren't many NIF examples, so I've created one: >> http://github.com/iamaleksey/iconverl >> It's a simple libiconv wrapper - it uses the latest NIF api (though >> not ?ErlNifResourceType ?for the descriptors, yet). >> Please fork it if you have something to add > > Nice! > > Would be neat with ErlNifResourceType though. Safer and simpler usage as you > can skip "close". The garbage collector will take care of that. > > /Sverker, Erlang/OTP Ericsson > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From bgustavsson@REDACTED Thu Feb 18 15:08:04 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Thu, 18 Feb 2010 15:08:04 +0100 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <201002180952.13285.clist@uah.es> Message-ID: <6672d0161002180608k6338922bk280baa2fe180a2b0@mail.gmail.com> On Thu, Feb 18, 2010 at 11:55 AM, Michael Turner wrote: > Yeah, I know. ?At the moment, on my way to trying to patch some docs, > I'm watching something called megaco take forever to build. ?I have no > interest at all in megaco. ?It's not remotely relevant to my immediate > problem. ?I'm just rebuilding everything from scratch because a "make > release_docs" failed, saying it didn't have something called > "docb_transform", which (I had to figure out) is written in Erlang. > I'm hoping that rebuilding everything gets docb_transform installed in > the right place. Which version do you try to build? R13B03 or the latest on the ccase/r13b04_dev branch in git repository? Building in the git repository should now work. The description is here: http://wiki.github.com/erlang/otp/documentation >?But the dependencies of components on tools getting > moved to the right places aren't reliable in the Erlang build system, > in my experience. That's it because we have always used Clearcase and Clearmake, that handle most dependencies automatically. We will starting working on updating the Makefiles to have the necessary dependencies. (Patches accepted.) > I like the idea. ?But basically, Ericsson owns Erlang/OTP in every > meaningful sense of the term. ?They just let us look at, and dink around > with, their code. ?They don't even release their test suites, and > without those, nobody can realistically hope to take an independent > direction with the system. We are gradually adding the test suites to the git repository. There are now test suites for more than 20 applications (including erts, kernel, stdlib, compiler) and more to come. They will also be included in the R13B04 source release. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From nesrait@REDACTED Thu Feb 18 15:10:55 2010 From: nesrait@REDACTED (=?ISO-8859-1?Q?Davide_Marqu=EAs?=) Date: Thu, 18 Feb 2010 14:10:55 +0000 Subject: [erlang-questions] Missing The Point Of Documentation In-Reply-To: <59da11981002171737p14d30915k26d4caa6b4a51660@mail.gmail.com> References: <4B7B8013.70003@krondo.com> <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <59da11981002171737p14d30915k26d4caa6b4a51660@mail.gmail.com> Message-ID: <523869a71002180610q28788fa7k6fe731d23cc7a7be@mail.gmail.com> Hi all, We can quickly access a module's page using keyword bookmarks: On firefox: http://weblog.hypotheticalabs.com/?p=289 On chrome: http://nitin.wlkr.net/2009/01/bookmark-keywords-in-google-chrome.html P.S. - congrats to the erldocs authors! :) Cheers, Davide On Thu, Feb 18, 2010 at 1:37 AM, Jeremy Raymond wrote: > Wow, erldocs is nice. > > On Wed, Feb 17, 2010 at 5:12 PM, Garrett Smith wrote: > > > On Wed, Feb 17, 2010 at 12:40 AM, Bob Ippolito wrote: > > > On Wed, Feb 17, 2010 at 12:35 AM, Dave Peticolas > > wrote: > > >> I think a global module index, like the one for the built-in > > >> Python modules, would be useful, both for quickly finding the > > >> module you already know the name of, and for browsing to see > > >> just what is available: > > >> > > >> http://docs.python.org/modindex.html > > > > > > http://erlang.org/doc/man_index.html > > > > > > It's the "Modules" hyperlink in the left frame of the docs. > > > > I've switched over to using: > > > > http://erldocs.com > > > > for reference lookups. This is almost as fast/convenient as > > auto-complete in Emacs with distel that I could never quite get > > working. > > > > Garrett > > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > See http://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > > > From dizzyd@REDACTED Thu Feb 18 15:32:37 2010 From: dizzyd@REDACTED (Dave Smith) Date: Thu, 18 Feb 2010 07:32:37 -0700 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <201002180952.13285.clist@uah.es> Message-ID: On Thu, Feb 18, 2010 at 3:55 AM, Michael Turner wrote: > > I like the idea. ?But basically, Ericsson owns Erlang/OTP in every > meaningful sense of the term. ?They just let us look at, and dink around > with, their code. ?They don't even release their test suites, and > without those, nobody can realistically hope to take an independent > direction with the system. ?Whatever the community does on Ericsson > reference material, it *must* be reflected back into their codebase, for > the foreseeable future, otherwise you'll have a fork that's steadily > growing incompatible with the Ericsson base reality. ?And Joe lays it > out pretty clearly: unless a customer of Ericsson's is paying for it, > there's no funding within the company for anything sweeping. ?So we > can't count on much help from that quarter. You seem to have a lot of angst, friend. From my perspective, Ericsson is making significant, observable progress towards opening up their development process. In the past 6 months, they've made more progress towards opening up the Erlang/OTP codebase than Sun did with Java in 6 YEARS. When I look at the quality of the Erlang VM (esp. considering the complexity it hides) compared to say, Ruby or Python's VM, I'm very glad that we have paid professionals maintaining it -- it makes it POSSIBLE for me to use in a production environment without having to worry about patching/debugging the VM 99.9% of the time. I'm tired of the trolling that people do about the Ericsson development process. It's clear to me, an outsider, that they're making good faith efforts to involve more people without sacrificing the quality of the VM (and platform). It's easy to take for granted the overall quality of Erlang/OTP and forget that attaining such quality is very, very expensive. The truth is, you REALLY don't want Ericsson to just toss the VM over the wall without growing these processes properly. If they did that we'd wind up with a balkanized community and code base with a declining quality factor -- see the X instances of the Ruby VM for reference. So to the Erlang/OTP team, I say "Well done!". Thanks for taking the difficult step of opening up and please keep it up. I'm extremely excited by the public contributions that have been making their way into the mainline for B04. Growing a community is hard, particularly for a piece of software as complex as the Erlang VM/platform -- but you're doing it successfully it would seem. To the people who having nothing to do but rant about Ericsson's "control", I say put your money where you mouth is. Write your own Erlang VM if you feel you need more control. After all, it's just code. Life is short. Make the most of it. D. From james.hague@REDACTED Thu Feb 18 15:49:59 2010 From: james.hague@REDACTED (James Hague) Date: Thu, 18 Feb 2010 08:49:59 -0600 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <201002180952.13285.clist@uah.es> Message-ID: I find the Erlang documentation to be on par with the documentation for other languages. Some things are great, some not so great. The Python docs, for example, are so confusing to navigate that I usually just google for whatever I'm looking for, because I can't find things using the table of contents, index, and built-in search. Perhaps the most visible change I'd make to the Erlang docs is to change "stdlib" to "Standard Library" and move it to the top level of the contents, not beneath "Basic Applications." When I was a beginner, most of my trouble stemmed from how the standard library was actually implemented and not so much the docs. Why is "lists" plural, but not "dict"? Why are there so many overlapping modules about dictionaries/sets/trees? Why is all the match_spec stuff inside of the ets module, which obscures the simplicity of ets tables? Why are specialty modules like erl_tar mixed in with more fundamental modules? And so on. We all know this :) James From leap@REDACTED Thu Feb 18 16:03:35 2010 From: leap@REDACTED (Michael Turner) Date: Thu, 18 Feb 2010 15:03:35 +0000 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: Message-ID: On 2/18/2010, "Dave Smith" wrote: >You seem to have a lot of angst, friend. From my perspective, Ericsson >is making significant, observable progress towards opening up their >development process. In the past 6 months, they've made more progress >towards opening up the Erlang/OTP codebase than Sun did with Java in 6 >YEARS. I haven't been watching. I think it was at some point well *over* six months ago when I wrote to someone at Ericsson to ask why there were no test suites in the release. He replied to the effect that they couldn't even consider it, since there were so many different platforms to test on first, so it would be a very long time before we'd see any. This struck me as odd thinking, especially from an open source point of view. After all, if you want to get a lot of coverage for your test suites on a variety of platforms, well, why not *release them*, so that people who run on various platforms can help? I'm glad to hear that things have improved since that exchange (which left me a little dispirited). But maybe it changed in part because people express some "angst" sometimes? As someone who is in business for himself, let me tell you: if I didn't get some bitter doses of "angst" now and again from unhappy customers, it would probably signal doom up ahead. It would mean that people had given up even on criticizing what I have to offer. > When I look at the quality of the Erlang VM (esp. considering >the complexity it hides) compared to say, Ruby or Python's VM, I'm >very glad that we have paid professionals maintaining it .... [snip several paragraphs about the VM and dev/maintencance process]. I don't disagree. But, um, weren't we talking about the Reference Manual, not the VM? And I think Joe has just said (if not in quite so many words) they *don't* have a professional maintaining that. It shows. Hence this discussion. -michael turner From kostis@REDACTED Thu Feb 18 16:14:22 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 18 Feb 2010 17:14:22 +0200 Subject: [erlang-questions] -define In-Reply-To: References: Message-ID: <4B7D594E.1010001@cs.ntua.gr> Richard O'Keefe wrote: > I've been trying out a weak pretty-printer for Erlang. > (By "weak" I mean that it takes care of indentation but > does not do anything about line breaking.) It's supposed > to be something I can build into my text editor. > > When I tried feeding other people's Erlang code into it, > I ran into some problems. > > I was aware that when you write > > -define(LHS, RHS). > > the stuff in RHS did not have to be bracket balanced, so > that > -define(LP, (). > -define(RP, )). > > are OK. > What I was *not* aware of was that there doesn't even have > to be a closing right parenthesis at all. > > -module(ick). > -export([ick/0]). > -define(ICK, {1}. > > ick() -> ?ICK. > > The Erlang compiler is perfectly happy with this. > There are several occurrences of this in the Erlang/OTP sources, > but there doesn't seem to be any reason why. I want to add my support to Richard's mail (and share his justified frustration) about the Erlang preprocessor. It should really be fixed so that it does not break the principle of least astonishment from what people (perhaps naively) expect from using other preprocessors like C's. The situation is currently very problematic for any sort of tool that wants to process Erlang source code. For example, tidier (*) that uses the epp_dodger module of the syntax_tools application, has trouble in some -defines which are considered OK by epp but not by epp_dodger. The most common one is those that have commas in what Richard calls their RHS, as in: -define(test(X), X =/= 42, X =/= 54, X =/= 666). I really do not like this -- and epp_dodger seems to agree with me. Allowing the above to be written even without the right parenthesis is even more problematic. I do not buy Robert's comments about "this being difficult to change because of backwards compatibility", as I have trouble imagining a -define that _really_ needs to be without a right parenthesis. Even if some existing code does not compile anymore, the fix is just adding a right parenthesis that should have been there in the first place! We should not stop being afraid of doing such changes as they are clear improvements both for the language, the various tools for it, and for the community in general. At least judging from Ulf's mail, there is a very simple fix to this problem, and I urge the OTP team to try this proposed change and include it in R14. Perhaps Richard can help by sending a list of -defines in Erlang/OTP that are without right parentheses to at least see if there is some legitimate reason for them to be without. Kostis (*) http://tidier.softlab.ntua.gr/ From jarrod@REDACTED Thu Feb 18 16:21:26 2010 From: jarrod@REDACTED (Jarrod Roberson) Date: Thu, 18 Feb 2010 10:21:26 -0500 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: Message-ID: I have both the books, I find what I need the most is concrete non-trival examples of implemenations. I think more well written Books is what we need. But we don't need any more referenence style books, that is what the online docs are for reference. What I really benefit from as having to self teach myself Erlang and OTP is good solid best practices examples what are explained WHY they do what they do. I am coming from mainly a Java and Python with Twisted background. I think OTP really replaces what Twisted does x 1000 but I can't get my head around how to do the idiom mapping to OTP. I have gotten lots of positive feedback on questions about how to do things in a more functional way with my main Erlang project from this list and to a much lesser extent StackOverflow. I have pre-ordered the OTP book from Amazon, I am hoping it helps cover some of the implemenation holes that the existing books have. -- Jarrod Roberson 678.551.2852 From kenneth.lundin@REDACTED Thu Feb 18 17:31:26 2010 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 18 Feb 2010 17:31:26 +0100 Subject: [erlang-questions] Need Apache FOP to build *any* docs? In-Reply-To: References: Message-ID: FOP is only needed for the PDF generation. The build support for building the docs is very new and I think both the html and PDFs are built in the same step. We will to refine this. /Kenneth Erlang/OTP Ericsson. On Thu, Feb 18, 2010 at 3:00 PM, Michael Turner wrote: > > I don't have Apache fop on my system. ?It builds PDFs and I don't need > those. However, I do want preview generated HTML before submitting > patches, at least. > > ?./otp_build autoconf > > tells me that the documentation can't be built, because fop is missing. > I've been crossing my fingers and hoping this doesn't mean what I'm > afraid it means. ?But *is* fop a dependency for building the html from > the xml? > > -michael turner > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From chandrashekhar.mullaparthi@REDACTED Thu Feb 18 18:10:53 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Thu, 18 Feb 2010 17:10:53 +0000 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> Message-ID: Hi, On 18 February 2010 08:21, Humaira Surve wrote: > > Hi, > > I've recently began playing around with erlang and come from a java > background. > > I was quite impressed by the eldap library and its general simplicity to > use. I have a question though. > If one opens a single connection and binds, but has multiple clients sending > requests through this one connection, > is there a possiblity of thread-related issues. Not really. All requests are multiplexed on to the same connection. > > What guarantees that a client gets the correct response or that a response > is not over-written by more than one simultaneous request? > I have looked through the eldap code and noticed that a single connection > uses a TCP file descriptor. See the source in eldap_fsm:send_command/3. I've added comments. send_command(Command, From, S) -> %% Assign a unique id for this request which is the messageID in the LDAP request ??? Id = bump_id(S), %% Build the request ??? {Name, Request} = gen_req(Command), ??? Message = #'LDAPMessage'{messageID? = Id, ??? ?? ??? ????? protocolOp = {Name, Request}}, ??? log2("~p~n",[{Name, Request}], S), %% Do ASN.1 encoding ??? {ok, Bytes} = asn1rt:encode('ELDAPv3', 'LDAPMessage', Message), %% Send the request on the socket ??? ok = gen_tcp:send(S#eldap.fd, Bytes), %% Start a timer ??? Timer = erlang:start_timer(?CMD_TIMEOUT, self(), {cmd_timeout, Id}), %% Store the mapping from unique id to 'From' which is a reference to the calling process ??? New_dict = dict:store(Id, [{Timer, From, Name}], S#eldap.dict), ??? {ok, S#eldap{id = Id, ??? ?? ? dict = New_dict}}. When a response is received, the LDAP server will include the messageID in the response. The eldap_fsm process looks up its state and retrieves the reference to the calling process (assuming the request has not timed out), and sends the response out.? This is handled in eldap_fsm:recvd_packet/2 cheers Chandru From vladdu55@REDACTED Thu Feb 18 19:33:25 2010 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 18 Feb 2010 19:33:25 +0100 Subject: [erlang-questions] -define In-Reply-To: <4B7D594E.1010001@cs.ntua.gr> References: <4B7D594E.1010001@cs.ntua.gr> Message-ID: <95be1d3b1002181033q1a111fdbh5cf1565803b08edc@mail.gmail.com> On Thu, Feb 18, 2010 at 16:14, Kostis Sagonas wrote: > We should not stop being afraid of doing such changes as they are clear > improvements both for the language, the various tools for it, and for the > community in general. I would like to be even bolder than that and suggest that a "-strict" option is added for the preprocessor that makes it reject macros that are not well formed. This would be off by default, emitting a warning and later it would be made on by default (possible to revert to the old style with --no-strict). regards, Vlad From rvirding@REDACTED Thu Feb 18 20:37:14 2010 From: rvirding@REDACTED (Robert Virding) Date: Thu, 18 Feb 2010 20:37:14 +0100 Subject: [erlang-questions] -define In-Reply-To: <464573922.48461266490889430.JavaMail.root@zimbra> References: <3dbc6d1c1002180249j7530b42dl197da5e68f546722@mail.gmail.com> <464573922.48461266490889430.JavaMail.root@zimbra> Message-ID: <3dbc6d1c1002181137m6527d380x60a4d17905f82cef@mail.gmail.com> On 18 February 2010 12:01, Ulf Wiger wrote: > > Well, if you look at the source in epp.erl, it doesn't seem to > be that difficult to change: > > macro_expansion([{')',_Lp},{dot,_Ld}]) -> []; > macro_expansion([{dot,_Ld}]) -> []; %Be nice, allow no right paren! > macro_expansion([T|Ts]) -> ? ?[T|macro_expansion(Ts)]. > > It ought to be enough to delete the line with the "Be nice" comment, > or perhaps modify it to signal an error instead. There is more to it than that because if it had been that easy even I would have done it. My guess is that it had something to do with the error handling if there was an error. Now there will never be an error there. Robert From rvirding@REDACTED Thu Feb 18 21:07:23 2010 From: rvirding@REDACTED (Robert Virding) Date: Thu, 18 Feb 2010 21:07:23 +0100 Subject: [erlang-questions] -define In-Reply-To: <4B7D594E.1010001@cs.ntua.gr> References: <4B7D594E.1010001@cs.ntua.gr> Message-ID: <3dbc6d1c1002181207s15b85769v724e6d0d98a3f266@mail.gmail.com> On 18 February 2010 16:14, Kostis Sagonas wrote: > > The situation is currently very problematic for any sort of tool that wants > to process Erlang source code. For example, tidier (*) that uses the > epp_dodger module of the syntax_tools application, has trouble in some > -defines which are considered OK by epp but not by epp_dodger. The most > common one is those that have commas in what Richard calls their RHS, as in: > > ? ? ? ?-define(test(X), X =/= 42, X =/= 54, X =/= 666). > > I really do not like this -- and epp_dodger seems to agree with me. Allowing > the above to be written even without the right parenthesis is even more > problematic. Well, if you want to be really strict then epp_dodger is buggy as it is not compatible with epp which it aims to be. It is a completely different matter to what epp should do. For epp you have to decide whether you are going to allow anything on the RHS upto the ending '.', maybe with a ')', or not. It was decided to allow *anything* which means that your example is perfectly legal. Saying that you allow anything *except* open ',' as above and forcing a grouping just for that case would be very strange and I think lead to even more confusion. You have to pick one or the other. > I do not buy Robert's comments about "this being difficult to change because > of backwards compatibility", as I have trouble imagining a -define that > _really_ needs to be without a right parenthesis. ?Even if some existing > code does not compile anymore, the fix is just adding a right parenthesis > that should have been there in the first place! It is a backwards incompatible change. You have suddenly made a change which may break old legal code. This is really no difference to making a syntax change in the language. In this case it doesn't really matter how justified and right the change is. > We should not stop being afraid of doing such changes as they are clear > improvements both for the language, the various tools for it, and for the > community in general. Oh, I agree but I have also had the pack after me for suggesting backwards incompatible changes so I am prepared. I don't see the problem, you just change your code. :-) >> At least judging from Ulf's mail, there is a very simple fix to this > problem, and I urge the OTP team to try this proposed change and include it > in R14. ?Perhaps Richard can help by sending a list of -defines in > Erlang/OTP that are without right parentheses to at least see if there is > some legitimate reason for them to be without. There was more to it than that. It's not the code in OTP which is the problem, the OTP group can fix that easily enough between releases, the real problem is user code. It is probably easier to fix the tools. Robert From zubairq@REDACTED Thu Feb 18 21:40:18 2010 From: zubairq@REDACTED (Zubair Quraishi) Date: Thu, 18 Feb 2010 21:40:18 +0100 Subject: Will parameterized modules become an official part of Erlang? Message-ID: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> I ask this as I have noticed some Open Source projects have started to use parameterized modules extensively in their code, so it would be useful to know if parameterized modules will become official, or if they will be removed from Erlang. Thanks Zubair From kenneth.lundin@REDACTED Thu Feb 18 22:27:07 2010 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 18 Feb 2010 22:27:07 +0100 Subject: [erlang-questions] What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> Message-ID: On Wed, Feb 17, 2010 at 4:52 PM, Michael Turner wrote: > > > On 2/17/2010, "Robert Virding" wrote: > >>Without getting into the discussion how difficult, or not, it is to >>navigate the Erlang docs one source of the problem is that all the >>standard OTP libraries are proper Applications. > > People should think of the trigonometric functions as part of the STDLIB > Application, just because gen_server is grouped in with them, in stdlib? > > What sense does this make? I agree with you in that the documentation can be improved with better descriptions and more examples and guidelines. There is also need for good search facilities. We are working on both and we are releasing the complete documentation sources plus support to build the doc. The purpose with this is to make it possible for the community to help us improve the docs. I don't agree at all when you criticise the organization in : Toplevel System documentation plus all the "applications". Already on the introduction page at top-level (http://erlang.org/doc) it says "Erlang/OTP is divided into a number of OTP applications. An application normally contains Erlang modules. Some OTP applications, such as the C interface erl_interface, are written in other languages and have no Erlang modules. " As everything is organized as "applications" in the source code tree and applications actually are groups of modules which are released and upgraded together it makes perfect sense to structure the documentation the same way. An application can be a service that can be started and stopped or it can be a library of passive modules with functions it does not matter. The important thing is that an application is the smallest unit we handle when it comes to deliverables. We always provide a complete new version of a full application including documentation when we release binary patches. The documentation is treated the same way as code and is released together with the code to assure that you always have the documentation corresponding to the code. Our experience is that this is a very efficient way to handle documentation. We have no intention to change this. The documentation can and will be improved anyway. STDLIB and Kernel are unfortunately 2 basic (core) applications with a very mixed content. The criterias for what's in Kernel and what's in STDLIB are unclear , we have discussed to reorganize them some day but it has not been important enough to do it. It will also introduce potential incompatibilities. Regarding the name "application" I think it is somewhat unfortunate since everyone has an own idea about what an application is in general. For example in Ericsson an "application" is a complete product sold to end users. In Erlang it is a group of modules handled together, possibly started as a service. I think you have to blame Joe for naming it "application". > >> So when when the >>documentation is organised around "applications", in one sense, it is >>being entirely logical and consistent. Of course, until you are more >>experienced and groked this it can be very confusing and difficult to >>find things. > > But in the meantime, conceptual/terminological confusion impedes the > learner, whenever he/she needs to resort to the Reference Manual. ?Given > that Erlang already poses quite a learning curve for some, this will > reduce the rate at which people become "more experienced and grok > this", and for that matter, it will reduce the number of people who > even want to get that far with Erlang. I don't really understand what you mean are the conceptual/terminological confusions except maybe application. > > What sense does this make? > > What goal does this serve? > > The goal of making it easier to autogenerate the documentation? I don't understand what you mean here. Most of the documentation 95% is handwritten. We strongly believe in single source and many generated presentations but this has no negative impact on the actual documentation. > > Well, I remember the days when we humans did a lot of things to make life > easier for the system. ?As I recall, it involved punching a lot of cards. > > > -michael turner > /Kenneth, Erlang/OTP Ericsson > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ok@REDACTED Thu Feb 18 23:31:27 2010 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 19 Feb 2010 11:31:27 +1300 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <201002180952.13285.clist@uah.es> References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <20100218031141.GA35934@k2r.org> <201002180952.13285.clist@uah.es> Message-ID: <5711E3A3-9268-45B7-AFE5-8259FFFAFF4D@cs.otago.ac.nz> Quite by coincidence, I happened to download Scalaris recently. It looks like an interesting and useful body of code, but it really is a textbook example of what's wrong with the JavaDoc Way of documentation. The installation process gives you a directory full to overflowing with html files, every one of them displaying neatly as a screen full of, well, nothing useful. This criticism does not apply at all to the architecture diagrams, which I found very helpful. But that's not Edoc. One thing this drove home to me is how many things we need to know about a component other than "here is a module here is a function". Things about the environment. For example, there's a Java interface for Scalaris and there's a Ruby interface, but what exactly is the *Erlang* interface? It may be quite obvious to someone who has ever used any DHT from Erlang, but as someone who hasn't, it's not obvious to me, and it's not something about the code per se. > From ok@REDACTED Thu Feb 18 23:56:16 2010 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 19 Feb 2010 11:56:16 +1300 Subject: [erlang-questions] -define In-Reply-To: <3dbc6d1c1002180249j7530b42dl197da5e68f546722@mail.gmail.com> References: <3dbc6d1c1002180249j7530b42dl197da5e68f546722@mail.gmail.com> Message-ID: <8B4C9BE5-032C-4964-B985-6BBC3948E149@cs.otago.ac.nz> On Feb 18, 2010, at 11:49 PM, Robert Virding wrote: > There is a simple reason for this: sheer laziness by the original > writer of the epp module, me. Now I suppose it is difficult to change > because of backwards compatibility. The problem is compounded byt the > feature that macro expansions don't have to be complete erlang > expressions so sometimes you can't tell the macro definition is over > until you hit the '.' . > The problem is that if -define(foo, bar. defines {{?foo}} to mean {{bar}} and -define(foo, bar]. defines {{?foo}} to mean {{bar]}} we'd expect that -define(foo, bar). would define {{?foo}} to mean {{bar)}}. But it doesn't. The problem here is inconsistency: the right hand of a -define is everything to the dot except when it isn't. As it happens, in the 1.5 million lines of Erlang code that I examined, there were about 3 occurrences of -define without a closing ); it was trivial to add a ) without breaking anything; and with those exceptions they were all bracket balanced. The on-line reference manual, section 7.2, http://www.erlang.org/doc/reference_manual/macros.html#id2274714 says "A macro is defined the following way: -define(Const, Replacement). -define(Func(Var1,...,VarN), Replacement)." and there's no hint that the final ) is optional. So I don't think it _would_ be difficult to enforce this. A good step would be to have a warning message from the preprocessor when a -define has no right parenthesis before the closing dot. > From ok@REDACTED Fri Feb 19 00:01:06 2010 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 19 Feb 2010 12:01:06 +1300 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <6672d0161002180608k6338922bk280baa2fe180a2b0@mail.gmail.com> References: <201002180952.13285.clist@uah.es> <6672d0161002180608k6338922bk280baa2fe180a2b0@mail.gmail.com> Message-ID: <8FAD0E19-D2CF-48F9-9E7A-89B04035666B@cs.otago.ac.nz> On Feb 19, 2010, at 3:08 AM, Bj?rn Gustavsson wrote: > That's it because we have always used Clearcase and Clearmake, > that handle most dependencies automatically. We will starting > working on updating the Makefiles to have the necessary > dependencies. (Patches accepted.) That reminds me of the article from Coverity in CACM. Has anyone run the Erlang VM sources through Coverity? (It's open source: could be _anyone_ with a Coverity licence, doesn't have to be Ericsson.) From ok@REDACTED Fri Feb 19 00:14:32 2010 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 19 Feb 2010 12:14:32 +1300 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <6672d0161002180608k6338922bk280baa2fe180a2b0@mail.gmail.com> References: <201002180952.13285.clist@uah.es> <6672d0161002180608k6338922bk280baa2fe180a2b0@mail.gmail.com> Message-ID: On Feb 19, 2010, at 3:08 AM, Bj?rn Gustavsson wrote: > Building in the git repository should now work. The description > is here: > > http://wiki.github.com/erlang/otp/documentation The first word in the body text of that page is wrong. English has a large class of verbs called "phrasal verbs". For example, John set the printer up. NP V(P) NP P John set up the printer. NP V(P) P NP The printer setup was wrong. When you glue the verb and the particle together, as in "setup", you create a noun. When you want a verb, you have to write the two words separately. So Setup the environment just like it was done previously. Set ERL_TOP the environment variable: should be Set the environment up just like before. Set the environment variable ERL_TOP: Actually, the heading "Documentation" would probably be better as Making the documentation Then as described in the README file. Shortly: "shortly" means "in a short time". s/Shortly/Briefly/ and release the necessary files. What does it mean to "release" a file? Unlock it? > From dale@REDACTED Fri Feb 19 00:42:54 2010 From: dale@REDACTED (Dale Harvey) Date: Thu, 18 Feb 2010 23:42:54 +0000 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <201002180952.13285.clist@uah.es> <6672d0161002180608k6338922bk280baa2fe180a2b0@mail.gmail.com> Message-ID: 2010/2/18 Richard O'Keefe > > On Feb 19, 2010, at 3:08 AM, Bj?rn Gustavsson wrote: > >> Building in the git repository should now work. The description >> is here: >> >> http://wiki.github.com/erlang/otp/documentation >> > > The first word in the body text of that page is wrong. > > English has a large class of verbs called "phrasal verbs". > For example, > John set the printer up. NP V(P) NP P > John set up the printer. NP V(P) P NP > The printer setup was wrong. > When you glue the verb and the particle together, as in "setup", > you create a noun. When you want a verb, you have to write the > two words separately. So > > Setup the environment just like it was done previously. > > Set ERL_TOP the environment variable: > > should be > > Set the environment up just like before. > Set the environment variable ERL_TOP: > > Actually, the heading "Documentation" would probably be better as > > Making the documentation > > Then > > as described in the README file. Shortly: > > "shortly" means "in a short time". s/Shortly/Briefly/ > > and release the necessary files. > > What does it mean to "release" a file? Unlock it? > > > I believe you can directly edit the wiki http://github.com/erlang/otp/wikis/documentation/edit > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ok@REDACTED Fri Feb 19 00:54:23 2010 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 19 Feb 2010 12:54:23 +1300 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <201002180952.13285.clist@uah.es> <6672d0161002180608k6338922bk280baa2fe180a2b0@mail.gmail.com> Message-ID: On Feb 19, 2010, at 12:42 PM, Dale Harvey wrote: > > I believe you can directly edit the wiki > > http://github.com/erlang/otp/wikis/documentation/edit When I click on that link, it says "Log in (Pricing and Signup)". Pricing? Sounds scary. From ulf.wiger@REDACTED Fri Feb 19 00:56:29 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Fri, 19 Feb 2010 00:56:29 +0100 Subject: [erlang-questions] -define In-Reply-To: <3dbc6d1c1002181207s15b85769v724e6d0d98a3f266@mail.gmail.com> References: <4B7D594E.1010001@cs.ntua.gr> <3dbc6d1c1002181207s15b85769v724e6d0d98a3f266@mail.gmail.com> Message-ID: <4B7DD3AD.7050503@erlang-solutions.com> Robert Virding wrote: > > It is a backwards incompatible change. You have suddenly made a > change which may break old legal code. This is really no difference > to making a syntax change in the language. In this case it doesn't > really matter how justified and right the change is. There are different kinds of breakage though. This change would cause a compilation error, which is common to begin with (at least when I'm programming), of a sort that is unlikely to hit you unless you're doing something very weird and "clever", and has a very simple fix. This is very different from a change that modifies runtime semantics in a subtle way. >> We should not stop being afraid of doing such changes as they are >> clear improvements both for the language, the various tools for it, >> and for the community in general. > > Oh, I agree but I have also had the pack after me for suggesting > backwards incompatible changes so I am prepared. I know. I even remember hounding you at times, and at least once even for making a change that /was/ BW compatible, but twice as slow as the original code (albeit adnmittedly more elegant). :) BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From dale@REDACTED Fri Feb 19 00:59:58 2010 From: dale@REDACTED (Dale Harvey) Date: Thu, 18 Feb 2010 23:59:58 +0000 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <201002180952.13285.clist@uah.es> <6672d0161002180608k6338922bk280baa2fe180a2b0@mail.gmail.com> Message-ID: On 18 February 2010 23:54, Richard O'Keefe wrote: > > On Feb 19, 2010, at 12:42 PM, Dale Harvey wrote: > >> >> I believe you can directly edit the wiki >> >> http://github.com/erlang/otp/wikis/documentation/edit >> > > When I click on that link, it says "Log in (Pricing and Signup)". > Pricing? Sounds scary. > > Its not that scary, they just dont want people anonymously editing it, signing up is free From wallentin.dahlberg@REDACTED Fri Feb 19 01:20:17 2010 From: wallentin.dahlberg@REDACTED (Wallentin Dahlberg) Date: Fri, 19 Feb 2010 01:20:17 +0100 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: References: <201002180952.13285.clist@uah.es> <6672d0161002180608k6338922bk280baa2fe180a2b0@mail.gmail.com> Message-ID: I think the person(s) who wrote most of the documentation to which you refer means well and all but his native language is Swedish. Feel free to correct the language on the GitHub Wiki. // Bj?rn-Egil Den 19 februari 2010 00.14 skrev Richard O'Keefe : > > On Feb 19, 2010, at 3:08 AM, Bj?rn Gustavsson wrote: > >> Building in the git repository should now work. The description >> is here: >> >> http://wiki.github.com/erlang/otp/documentation >> > > The first word in the body text of that page is wrong. > > English has a large class of verbs called "phrasal verbs". > For example, > John set the printer up. NP V(P) NP P > John set up the printer. NP V(P) P NP > The printer setup was wrong. > When you glue the verb and the particle together, as in "setup", > you create a noun. When you want a verb, you have to write the > two words separately. So > > Setup the environment just like it was done previously. > > Set ERL_TOP the environment variable: > > should be > > Set the environment up just like before. > Set the environment variable ERL_TOP: > > Actually, the heading "Documentation" would probably be better as > > Making the documentation > > Then > > as described in the README file. Shortly: > > "shortly" means "in a short time". s/Shortly/Briefly/ > > and release the necessary files. > > What does it mean to "release" a file? Unlock it? > > > >> > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From steven.charles.davis@REDACTED Fri Feb 19 02:38:38 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Thu, 18 Feb 2010 17:38:38 -0800 (PST) Subject: Will parameterized modules become an official part of Erlang? In-Reply-To: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> Message-ID: <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> I have found that the more I have used parameterized modules... the less I use parameterized modules. If you get what I'm saying. Regards, /s On Feb 18, 2:40?pm, Zubair Quraishi wrote: > I ask this as I have noticed some Open Source projects have started to use > parameterized modules extensively in their code, so it would be useful to > know if parameterized modules will become official, or if they will be > removed from Erlang. > > Thanks > Zubair From kagato@REDACTED Thu Feb 18 09:38:34 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Thu, 18 Feb 2010 00:38:34 -0800 Subject: rpc:call/4 Message-ID: I've encountered unexpected behavior when doing rpc:call/4 to a remote node and the remote code has an exception. The "error case" seems to be {badrpc,Reason}, with reason completely unspecified. Oddly, I get the following behavior: erlang:exit(X) gives {badrpc, {'EXIT',X}. erlang:raise(X) gives {badrpc, {'EXIT',X,StackTrace}. erlang:throw(X) gives X. The first two are pretty reasonable. The third one is a bit odd. In a number of places, the rpc:call infrastructure seems to use the archaic: > case catch .... of ... end. In modern code, I would assume this would be the more expressive: > try ... of ... catch ... end. What is the expected behavior (the docs are a bit vague)? -- Jayson Vantuyl kagato@REDACTED From bile@REDACTED Fri Feb 19 05:22:23 2010 From: bile@REDACTED (bile@REDACTED) Date: Thu, 18 Feb 2010 23:22:23 -0500 Subject: [erlang-questions] rpc:call/4 In-Reply-To: References: Message-ID: <20100218232223.30d0a781@landofbile.com> May be an oversight or a relic. It's due to rpc:handle_call_call doing a catch apply. Since catch throw gives back whatever was thrown and not {'EXIT',_} all it can do is pass it back as a normal result. While it'd be nice in this case to use the newer try catch behavior it'd not be backward compatible. Though it'd probably lead some to find that their RPCs had been failing. And if it were changed... what would the first element of the tuple be? 'EXIT' like exit and error or something like 'THROW'. It'd be nice if it were 'EXIT', 'ERROR', and 'THROW'. That's even more incompatible however. On Thu, 18 Feb 2010 00:38:34 -0800 Jayson Vantuyl wrote: > I've encountered unexpected behavior when doing rpc:call/4 to a > remote node and the remote code has an exception. > > The "error case" seems to be {badrpc,Reason}, with reason completely > unspecified. Oddly, I get the following behavior: > > erlang:exit(X) gives {badrpc, {'EXIT',X}. > erlang:raise(X) gives {badrpc, {'EXIT',X,StackTrace}. > erlang:throw(X) gives X. > > The first two are pretty reasonable. The third one is a bit odd. > > In a number of places, the rpc:call infrastructure seems to use the > archaic: > > > case catch .... of ... end. > > In modern code, I would assume this would be the more expressive: > > > try ... of ... catch ... end. > > What is the expected behavior (the docs are a bit vague)? > From tsuraan@REDACTED Fri Feb 19 07:10:50 2010 From: tsuraan@REDACTED (tsuraan) Date: Fri, 19 Feb 2010 00:10:50 -0600 Subject: Keyword documentation Message-ID: <84fb38e31002182210s183e3209w449e2693a975e4f2@mail.gmail.com> Is there a list somewhere of what erlang's keywords/reserved words are, and what they do? I just found the other day that query is a reserved word, which appears to be something archaic. cond is another reserved word, whose purpose I can't find, but it seems promising. I'm sure there's a doc somewhere with erlang's keywords and their meanings, but I'm not having any luck finding it. From dale@REDACTED Fri Feb 19 07:16:58 2010 From: dale@REDACTED (Dale Harvey) Date: Fri, 19 Feb 2010 06:16:58 +0000 Subject: [erlang-questions] Keyword documentation In-Reply-To: <84fb38e31002182210s183e3209w449e2693a975e4f2@mail.gmail.com> References: <84fb38e31002182210s183e3209w449e2693a975e4f2@mail.gmail.com> Message-ID: The following are reserved words in Erlang: after and andalso band begin bnot bor bsl bsr bxor case catch cond div end fun if let not of or orelse query receive rem try when xor from http://www.erlang.org/doc/reference_manual/introduction.html On 19 February 2010 06:10, tsuraan wrote: > Is there a list somewhere of what erlang's keywords/reserved words > are, and what they do? I just found the other day that query is a > reserved word, which appears to be something archaic. cond is another > reserved word, whose purpose I can't find, but it seems promising. > I'm sure there's a doc somewhere with erlang's keywords and their > meanings, but I'm not having any luck finding it. > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From leap@REDACTED Fri Feb 19 07:29:12 2010 From: leap@REDACTED (Michael Turner) Date: Fri, 19 Feb 2010 06:29:12 +0000 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: Message-ID: On 2/18/2010, "Richard O'Keefe" wrote: > >On Feb 19, 2010, at 12:42 PM, Dale Harvey wrote: >> >> I believe you can directly edit the wiki >> >> http://github.com/erlang/otp/wikis/documentation/edit > >When I click on that link, it says "Log in (Pricing and Signup)". >Pricing? Sounds scary. I'd say this was bad user interface design, but maybe they make more money this way. That eye-of-the-beholder thing again. Does it sound even scarier to say that $0.00 is a *degenerate case* of "Pricing"? That's what I'm paying as a "collaborator". ("Co-conspirator" membership costs extra.) Let's hope the rate doesn't suddenly go up on us. I just fixed the grammar problem Dale mentioned, plus a few others, all very minor to be sure (e.g., "Shortly" -> "Briefly", punctuation, etc.) The instructions should be a little more helpful now. If not, tell me, or you can go ahead and fix them yourself as a github "collaborator". It's in Yet Another Wiki Format, unfortunately, and my pop-up killer also kills the Preview, but I find it usable enough. There remains the problem (for me) that I'd like to have SKIP files specifically for PDF generation, or some other way to short-circuit their creation. But that's not an issue for the github wiki. -michael turner From leap@REDACTED Fri Feb 19 07:43:44 2010 From: leap@REDACTED (Michael Turner) Date: Fri, 19 Feb 2010 06:43:44 +0000 Subject: github on building docs - richard's suggestions, not dale's In-Reply-To: Message-ID: Oops, I credited Dale for fixups suggested by Richard. Sorry, Richard. "Making/Building the Documentation" would be a better article title, but I only know MediaWiki and PMWiki markup, so I'm not sure how go about changing that. -michael turner From leap@REDACTED Fri Feb 19 08:10:41 2010 From: leap@REDACTED (Michael Turner) Date: Fri, 19 Feb 2010 07:10:41 +0000 Subject: [erlang-questions] What about making sense? In-Reply-To: Message-ID: <3hhIDDR1.1266563441.7439020.leap@gol.com> Kenneth Lundin writes: "As everything is organized as "applications" in the source code tree and applications actually are groups of modules which are released and upgraded together it makes perfect sense to structure the documentation the same way." If in fact it makes perfect sense, why have so many smart people found it so confusing? Calling a generic library an application makes no sense at all to me. One *applies* library functions to practical problems, in the process of building software, typically resulting in *programs* that are applications. Erlang/OTP's use of "application" to mean all these different things bears no relation to its use by the overwhelming majority of software engineers. If you don't believe me, try testing your TOC out on real learners. Give two different groups of programmers different TOCs, one perhaps as I have suggested, the other as it currently exists. Ask them, "which link would you click first, to try to find stdlib, the Erlang Standard Library?" Is it so hard to predict the result? With yours, they won't click Basic Applications, because stdlib is not an application in any ordinary sense they know. Categorizing it as a Basic Application wont' make "perfect sense" to them, in fact, will make no sense at all to them. "Application" in the Erlang/OTP sense is something most experienced programmers must learn, and be reminded of (especially since in OTP it's usually something you can start and stop, but in other cases just a regular Erlang library, and in yet other cases, not even that. And if I'm to believe the much more experienced Jayson, "application" actually has *even more* different meanings in Erlang/OTP.) Please don't pretend there's no difficulty here. Forthright admissions, early and often, that Erlang uses "application" in a highly unusual sense (*senses*, actually) would go a long way toward helping mere mortals get used to it. Saying there's no real problem sounds, well ... just what kind of attitude is conveyed by a sentiment like "Words mean what we say they mean, and if you couldn't easily find *where* we defined, precisely and completely, what they mean, that's not our problem"? Would you want someone with that attitude working on documentation YOU were trying to understand? -michael turner On 2/18/2010, "Kenneth Lundin" wrote: >On Wed, Feb 17, 2010 at 4:52 PM, Michael Turner wrote: >> >> >> On 2/17/2010, "Robert Virding" wrote: >> >>>Without getting into the discussion how difficult, or not, it is to >>>navigate the Erlang docs one source of the problem is that all the >>>standard OTP libraries are proper Applications. >> >> People should think of the trigonometric functions as part of the STDLIB >> Application, just because gen_server is grouped in with them, in stdlib? >> >> What sense does this make? > >I agree with you in that the documentation can be improved with better >descriptions and more examples and guidelines. There is also need for >good search facilities. We are working on both and we are releasing >the complete documentation sources plus support to build the doc. The >purpose with this is to make it possible for the community to help us >improve the docs. > >I don't agree at all when you criticise the organization in : >Toplevel System documentation plus all the "applications". >Already on the introduction page at top-level (http://erlang.org/doc) it says >"Erlang/OTP is divided into a number of OTP applications. An >application normally contains Erlang modules. Some OTP applications, >such as the C interface erl_interface, are written in other languages >and have no Erlang modules. " > >As everything is organized as "applications" in the source code tree >and applications actually are >groups of modules which are released and upgraded together it makes >perfect sense to structure the >documentation the same way. > >An application can be a service that can be started and stopped or it >can be a library of passive modules with functions it does not matter. >The important thing is that an application is the smallest unit we >handle when it comes to deliverables. We always provide a complete new >version of a full application including documentation when we release >binary patches. >The documentation is treated the same way as code and is released >together with the code to assure >that you always have the documentation corresponding to the code. > >Our experience is that this is a very efficient way to handle >documentation. We have no intention to change this. The documentation >can and will be improved anyway. > >STDLIB and Kernel are unfortunately 2 basic (core) applications with a >very mixed content. >The criterias for what's in Kernel and what's in STDLIB are unclear , >we have discussed to >reorganize them some day but it has not been important enough to do >it. It will also introduce >potential incompatibilities. > >Regarding the name "application" I think it is somewhat unfortunate >since everyone has an own idea >about what an application is in general. For example in Ericsson an >"application" is a complete product sold to end users. In Erlang it is >a group of modules handled together, possibly started as a service. I >think you have to blame Joe for naming it "application". >> >>> So when when the >>>documentation is organised around "applications", in one sense, it is >>>being entirely logical and consistent. Of course, until you are more >>>experienced and groked this it can be very confusing and difficult to >>>find things. >> >> But in the meantime, conceptual/terminological confusion impedes the >> learner, whenever he/she needs to resort to the Reference Manual. ?Given >> that Erlang already poses quite a learning curve for some, this will >> reduce the rate at which people become "more experienced and grok >> this", and for that matter, it will reduce the number of people who >> even want to get that far with Erlang. > >I don't really understand what you mean are the >conceptual/terminological confusions except maybe >application. > >> >> What sense does this make? >> >> What goal does this serve? >> >> The goal of making it easier to autogenerate the documentation? > >I don't understand what you mean here. Most of the documentation 95% >is handwritten. >We strongly believe in single source and many generated presentations >but this has no negative >impact on the actual documentation. > > >> >> Well, I remember the days when we humans did a lot of things to make life >> easier for the system. ?As I recall, it involved punching a lot of cards. >> >> >> -michael turner >> >/Kenneth, Erlang/OTP Ericsson >> >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > From leap@REDACTED Fri Feb 19 08:16:32 2010 From: leap@REDACTED (Michael Turner) Date: Fri, 19 Feb 2010 07:16:32 +0000 Subject: Coverity, ClearMake, Erlang VM In-Reply-To: <8FAD0E19-D2CF-48F9-9E7A-89B04035666B@cs.otago.ac.nz> Message-ID: On 2/18/2010, "Richard O'Keefe" wrote: > >On Feb 19, 2010, at 3:08 AM, Björn Gustavsson wrote: >> That's it because we have always used Clearcase and Clearmake, >> that handle most dependencies automatically. We will starting >> working on updating the Makefiles to have the necessary >> dependencies. (Patches accepted.) > >That reminds me of the article from Coverity in CACM. With the important difference that the CACM article mentioned people who thought that ClearCase Make was how all makes work; obviously, Erlang/OTP people know better. >Has anyone run the Erlang VM sources through Coverity? >(It's open source: could be _anyone_ with a Coverity licence, >doesn't have to be Ericsson.) It would probably help to first know what the allowable combinations of conditional compilation flags were, just to avoid spurious reports. In the one patch I submitted, it seemed it was for code that hadn't actually compiled in almost a decade, and which will probably never be compiled again. -michael turner From erlang@REDACTED Fri Feb 19 08:40:51 2010 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 19 Feb 2010 08:40:51 +0100 Subject: [erlang-questions] What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> Message-ID: <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> On Thu, Feb 18, 2010 at 10:27 PM, Kenneth Lundin wrote: > On Wed, Feb 17, 2010 at 4:52 PM, Michael Turner wrote: >> >> >> On 2/17/2010, "Robert Virding" wrote: >> >>>Without getting into the discussion how difficult, or not, it is to >>>navigate the Erlang docs one source of the problem is that all the >>>standard OTP libraries are proper Applications. >> >> People should think of the trigonometric functions as part of the STDLIB >> Application, just because gen_server is grouped in with them, in stdlib? >> >> What sense does this make? > > I agree with you in that the documentation can be improved with better > descriptions and more examples and guidelines. There is also need for > good search facilities. We are working on both and we are releasing > the complete documentation sources plus support to build the doc. The > purpose with this is to make it possible for the community to help us > improve the docs. > > I don't agree at all when you criticise the organization in : > Toplevel System documentation plus all the "applications". > Already on the introduction page at top-level (http://erlang.org/doc) it says > "Erlang/OTP is divided into a number of OTP applications. An > application normally contains Erlang modules. Some OTP applications, > such as the C interface erl_interface, are written in other languages > and have no Erlang modules. " > > As everything is organized as "applications" in the source code tree > and applications actually are > groups of modules which are released and upgraded together it makes > perfect sense to structure the > documentation the same way. > > An application can be a service that can be started and stopped or it > can be a library of passive modules with functions it does not matter. > The important thing is that an application is the smallest unit we > handle when it comes to deliverables. We always provide a complete new > version of a full application including documentation when we release > binary patches. > The documentation is treated the same way as code and is released > together with the code to assure > that you always have the documentation corresponding to the code. > > Our experience is that this is a very efficient way to handle > documentation. We have no intention to change this. The documentation > can and will be improved anyway. > > STDLIB and Kernel are unfortunately 2 basic (core) applications with a > very mixed content. > The criterias for what's in Kernel and what's in STDLIB ?are unclear , > we have discussed to > reorganize them some day but it has not been important enough to do > it. It will also introduce > potential incompatibilities. > > Regarding the name "application" I think it is somewhat unfortunate > since everyone has an own idea > about what an application is in general. For example in Ericsson an > "application" is a complete product sold to end users. In Erlang it is > a group of modules handled together, possibly started as a service. I > think you have to blame Joe for naming it "application". I'm guilty - but we had to give these "things" a name so we could talk about them. We could have called them glurks - "a glurk is a ..." but this would be crazy. The nice thing about natural language is that the meaning of a word is context dependent - so in the Erlang context Application means "...". Now were Erlang to become wildly popular, to the point where everybody lived breathed and dreamed Erlang dreams, then the Erlang use of the world Application would become the de. facto. standard and any other uses of the world would be viewed suspect. Another bad word is "lists" - the things we call lists are not lists, they are *stacks* if T is a stack then [H|T] is a new stack formed by pushing H onto the stack. Stack is a much better word than list. "Kenneth - get your guys to stop what they're doing and change all the use of the word stack to lists - and change all the modules that use the world lists - from now on lists are stacks." "Sorry Joe, we have a problem, the guys don't stacken to what I say" Sure there are problems with the terminology - did I say "problems" "Sorry Guv I meant 'issues', "Did you mean 'challenges?'" "Nnnn nnno .. 'Opportunities' /Joe >> >>> So when when the >>>documentation is organised around "applications", in one sense, it is >>>being entirely logical and consistent. Of course, until you are more >>>experienced and groked this it can be very confusing and difficult to >>>find things. >> >> But in the meantime, conceptual/terminological confusion impedes the >> learner, whenever he/she needs to resort to the Reference Manual. ?Given >> that Erlang already poses quite a learning curve for some, this will >> reduce the rate at which people become "more experienced and grok >> this", and for that matter, it will reduce the number of people who >> even want to get that far with Erlang. > > I don't really understand what you mean are the > conceptual/terminological confusions except maybe > application. > >> >> What sense does this make? >> >> What goal does this serve? >> >> The goal of making it easier to autogenerate the documentation? > > I don't understand what you mean here. Most of the documentation 95% > is handwritten. > We strongly believe in single source and many generated presentations > but this has no negative > impact on the actual documentation. > > >> >> Well, I remember the days when we humans did a lot of things to make life >> easier for the system. ?As I recall, it involved punching a lot of cards. >> >> >> -michael turner >> > /Kenneth, Erlang/OTP Ericsson >> >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From martti.kuparinen@REDACTED Fri Feb 19 08:33:40 2010 From: martti.kuparinen@REDACTED (Martti Kuparinen) Date: Fri, 19 Feb 2010 09:33:40 +0200 Subject: Errors reported by valgrind Message-ID: <4B7E3ED4.1080700@iki.fi> Hi, I'm using 64-bit Ubuntu 9.10 and I downloaded R13B03 and compiled it with CFLAGS="-g" LDFLAGS="-g" ./configure --prefix=/tmp/otp13b3 --enable-threads --enable-smp-support --enable-kernel-poll --enable-hipe --enable-megaco-flex-scanner-lineno --enable-megaco-reentrant-flex-scanner --enable-dynamic-ssl-lib--enable-shared-zlib make Next I wanted to see what valgrind 3.5.0 thinks so I executed cd bin/x86_64-unknown-linux-gnu export BINDIR=`pwd` valgrind --trace-children=yes --verbose --leak-check=full \ --show-reachable=yes --track-origins=yes --malloc-fill=AB \ --free-fill=CD \ ./erlexec q(). ==24653== LEAK SUMMARY: ==24653== definitely lost: 57,344 bytes in 7 blocks ==24653== indirectly lost: 0 bytes in 0 blocks ==24653== possibly lost: 2,108,608 bytes in 15 blocks ==24653== still reachable: 9,001,366 bytes in 89 blocks ==24653== suppressed: 0 bytes in 0 blocks ==24653== ==24653== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 4 from 4) I also executed valgrind --trace-children=yes --verbose --tool=helgrind \ ./erlexec q(). ==24733== ERROR SUMMARY: 754 errors from 97 contexts (suppressed: 13211 from 190) Most of those were "Possible data race during write of size X" and "Thread #X: lock order ... violated" kind of errors. Anyone else getting similar results? Should I file a problem report (where?) or is this mail enough? Martti From humaira.surve@REDACTED Fri Feb 19 09:17:16 2010 From: humaira.surve@REDACTED (Humaira) Date: Fri, 19 Feb 2010 10:17:16 +0200 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> Message-ID: <1266567436.4073.6.camel@humaira-laptop> Hi Chandru, Thanks for the very useful information. I noticed that I have a different version of eldap than you are referring to. Where would one find the gen_fsm version? Is there a commonly used repository or is it the version from ejabberd? I looked through the version on GitHub and it is not the gen_fsm version. Thanks, Humaira On Thu, 2010-02-18 at 17:10 +0000, Chandru wrote: > Hi, > > On 18 February 2010 08:21, Humaira Surve wrote: > > > > Hi, > > > > I've recently began playing around with erlang and come from a java > > background. > > > > I was quite impressed by the eldap library and its general simplicity to > > use. I have a question though. > > If one opens a single connection and binds, but has multiple clients sending > > requests through this one connection, > > is there a possiblity of thread-related issues. > > Not really. All requests are multiplexed on to the same connection. > > > > > What guarantees that a client gets the correct response or that a response > > is not over-written by more than one simultaneous request? > > I have looked through the eldap code and noticed that a single connection > > uses a TCP file descriptor. > > See the source in eldap_fsm:send_command/3. I've added comments. > > send_command(Command, From, S) -> > %% Assign a unique id for this request which is the messageID in > the LDAP request > Id = bump_id(S), > > %% Build the request > {Name, Request} = gen_req(Command), > Message = #'LDAPMessage'{messageID = Id, > protocolOp = {Name, Request}}, > log2("~p~n",[{Name, Request}], S), > > %% Do ASN.1 encoding > {ok, Bytes} = asn1rt:encode('ELDAPv3', 'LDAPMessage', Message), > > %% Send the request on the socket > ok = gen_tcp:send(S#eldap.fd, Bytes), > > %% Start a timer > Timer = erlang:start_timer(?CMD_TIMEOUT, self(), {cmd_timeout, Id}), > > %% Store the mapping from unique id to 'From' which is a > reference to the calling process > New_dict = dict:store(Id, [{Timer, From, Name}], S#eldap.dict), > > {ok, S#eldap{id = Id, > dict = New_dict}}. > > When a response is received, the LDAP server will include the > messageID in the response. The eldap_fsm process looks up its state > and retrieves the reference to the calling process (assuming the > request has not timed out), and sends the response out. This is > handled in eldap_fsm:recvd_packet/2 > > cheers > Chandru From ttmrichter@REDACTED Fri Feb 19 09:30:16 2010 From: ttmrichter@REDACTED (Michael Richter) Date: Fri, 19 Feb 2010 16:30:16 +0800 Subject: [erlang-questions] What about making sense? In-Reply-To: <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> Message-ID: I think we have a lot of cross-talk going on here. Item: Some people believe that the Erlang docs as they are interfere with comprehension, partially because of inconsistent and unusual use of terminology. Item: Some people see no problem with the docs as they are. The truth lies somewhere in the middle, I believe. The docs are nowhere near as dire as some of the more vociferous commentators are portraying them. Are they ideal? No. Are they even good? Not really. They are about average for this industry (which is a condemnation of the industry's standards, not of the writers). They are, however, adequate. *As references*. If you already know what it is you're looking for (or should be looking for) the docs as they stand are more than adequate. What they are terrible for is learning tools. This is a problem in general for Erlang, partially because it's a relatively new tool on the scene (the public scene, that is -- I know it's been around for ages inside Ericcson) and partially because it's a small community around it with only a very small number of grognards who know it all. On the learning front now we have two great tools (*Programming Erlang* and *Erlang Programming*) with a third on the way (*Erlang and OTP in Action*) for tutorial introductions. These first two have been great for my picking up Erlang, for example, but now another barrier has crossed my path. There's no documentation in between the "Erlang for Complete Newbs" stuff and the "Reminders for the Grognards" stuff. I think that is the failing of Erlang documentation at this point. It's not in tutorial-level information -- there's plenty of that and of very high quality indeed (courtesy of Armstrong and Cesarini & Thompson). There's more of it on the way. It's not in the reference-level information. What's there isn't ideal nor is it ideally organized but it's OK. Better than some languages, worse than others. What's missing is information like overviews of the available libraries (or "applications" in Erlang-speak), what they do and a general idea of how to use them. What's missing is good sample code for these "applications". Use case scenarios. Where they are well-applied. Where they are not so well applied. There is a great deal of stuff in the Erlang/OTP distribution. Here's a list of it: - appmon-2.1.10.2/ - asn1-1.6.12/ - common_test-1.4.6/ - compiler-4.6.4/ - cosEvent-2.1.7/ - cosEventDomain-1.1.7/ - cosFileTransfer-1.1.9/ - cosNotification-1.1.12/ - cosProperty-1.1.10/ - cosTime-1.1.7/ - cosTransactions-1.2.8/ - crypto-1.6.3/ - debugger-3.2.1/ - dialyzer-2.1.0/ - docbuilder-0.9.8.6/ - edoc-0.7.6.5/ - erl_docgen-0.1/ - erl_interface-3.6.4/ - erts-5.7.4/ - et-1.3.3/ - eunit-2.1.4/ - gs-1.5.11/ - hipe-3.7.4/ - ic-4.2.23/ - inets-5.2/ - inviso-0.6.1/ - jinterface-1.5.2/ - kernel-2.13.4/ - megaco-3.13/ - mnesia-4.4.12/ - observer-0.9.8.1/ - odbc-2.10.6/ - orber-3.6.14/ - os_mon-2.2.4/ - otp_mibs-1.0.6/ - parsetools-2.0.1/ - percept-0.8.3/ - pman-2.7.1/ - public_key-0.4/ - reltool-0.5.2/ - runtime_tools-1.8.2/ - sasl-2.1.8/ - snmp-4.15/ - ssh-1.1.7/ - ssl-3.10.7/ - stdlib-1.16.4/ - syntax_tools-1.6.4/ - test_server-3.3.5/ - toolbar-1.4.1/ - tools-2.6.5/ - tv-2.1.4.4/ - typer-0.1.7.3/ - webtool-0.8.5/ - wx-0.98.4/ - xmerl-1.2.3/ That is a pretty intimidating list for a newcomer to be faced with and there really isn't a good overview of what each is, where each might be applicable and how they interact with each other. (No, a list on the left pane doesn't qualify as guidance!) Grognards who have been working with Erlang since forever, I think, are forgetting that newcomers to Erlang are faced with a lot of hurdles all at once. Newcomers are often faced with their first functional language. They're faced with their first actor-based concurrency model. They're faced with an unfamiliar syntax that even old-timers have to admit can be opaque and a bit strange. They're faced with libraries--Oops! "Applications"!-- that don't play well together (edoc vs. typer vs. dialyzer for example). They're faced with all of this and get little to no guidance short of community legend and lore to navigate through it. I can see how this can be frustrating and how it can lead to the increasing levels of heat showing up in this thread. Unfortunately the heat is now doing nothing but getting people on each side riled up, feeling embattled and digging in as a result. I'd like to ask for two things to help calm this down: 1. Grognards, please try and understand the position of a complete newcomer. Imagine, for a moment, that you haven't been working with Erlang for years. Look at the documentation that exists as if it were your first time. Look at that list of "applications", the unusual terminology, the language that is pretty much unlike anything else out there in common use and ask (and answer) yourself honestly: is this sufficient for learning? Is this helpful to a newcomer to the language? If, as I expect, you answer "no" to these questions, ask yourself also what needs to change to make these helpful and sufficient and, more importantly, what processes can be put in place to speed along development of such tools by bringing in community input. 2. Newbies (like me), please also try to understand the position the grognards are in. Like you they are hired to be (or have made businesses to be) productive with code. They're developers and not technical writers. Further the fruits of their labour are being given you at no (fiscal) cost. It is a bit unseemly to harshly criticize their (from their employers' perspective) non-productive labour when they, too, face the real world of software development with unrealistic schedules and deadlines, moving requirements and feature creep. Be thankful for what is there already and perhaps have a little patience as the rest gets released and the processes get ironed out to have community input. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. From chandrashekhar.mullaparthi@REDACTED Fri Feb 19 09:57:01 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Fri, 19 Feb 2010 08:57:01 +0000 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <1266567436.4073.6.camel@humaira-laptop> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266567436.4073.6.camel@humaira-laptop> Message-ID: On 19 February 2010 08:17, Humaira wrote: > > Hi Chandru, > > Thanks for the very useful information. I noticed that I have a > different version of eldap than you are referring to. Where would one > find the gen_fsm version? Is there a commonly used repository or is it > the version from ejabberd? I'm not sure. The version I have was written by Tobbe (Torbj?rn T?rnkvist) in 2000! If he reads this maybe he can tell us where to find it. If not, I can send it to you. cheers Chandru From chandrashekhar.mullaparthi@REDACTED Fri Feb 19 10:03:43 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Fri, 19 Feb 2010 09:03:43 +0000 Subject: [erlang-questions] What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> Message-ID: On 19 February 2010 08:30, Michael Richter wrote: > I think we have a lot of cross-talk going on here. > > Item: Some people believe that the Erlang docs as they are interfere with > comprehension, partially because of inconsistent and unusual use of > terminology. > > Item: Some people see no problem with the docs as they are. > > The truth lies somewhere in the middle, I believe. > > The docs are nowhere near as dire as some of the more vociferous > commentators are portraying them. ?Are they ideal? ?No. ?Are they even good? > ?Not really. ?They are about average for this industry (which is a > condemnation of the industry's standards, not of the writers). ?They are, > however, adequate. ?*As references*. ?If you already know what it is you're > looking for (or should be looking for) the docs as they stand are more than > adequate. I agree. >From the GNU Texinfo manual. Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. ?Dick Brandon Maybe this should be included in the OTP documentation. cheers Chandru From clist@REDACTED Fri Feb 19 10:22:29 2010 From: clist@REDACTED (Angel Alvarez) Date: Fri, 19 Feb 2010 10:22:29 +0100 Subject: [erlang-questions] yet more ranting about Erlang docs In-Reply-To: <5711E3A3-9268-45B7-AFE5-8259FFFAFF4D@cs.otago.ac.nz> References: <6a36e7291002162240lb5bca10t861f673c975d05a6@mail.gmail.com> <201002180952.13285.clist@uah.es> <5711E3A3-9268-45B7-AFE5-8259FFFAFF4D@cs.otago.ac.nz> Message-ID: <201002191022.29312.clist@uah.es> El Jueves, 18 de Febrero de 2010 23:31:27 Richard O'Keefe escribi?: > Quite by coincidence, I happened to download Scalaris recently. > It looks like an interesting and useful body of code, but it > really is a textbook example of what's wrong with the JavaDoc > Way of documentation. The installation process gives you a > directory full to overflowing with html files, every one of them > displaying neatly as a screen full of, well, nothing useful. > > This criticism does not apply at all to the architecture > diagrams, which I found very helpful. But that's not Edoc. > > One thing this drove home to me is how many things we need > to know about a component other than "here is a module here > is a function". Things about the environment. For example, > there's a Java interface for Scalaris and there's a Ruby > interface, but what exactly is the *Erlang* interface? It may > be quite obvious to someone who has ever used any DHT from > Erlang, but as someone who hasn't, it's not obvious to me, and > it's not something about the code per se. > > Still Mochiweb, Scalaris and others tend to be more useful snipets of code+ docs that the erlang docs site on some areas. Thereis a no man's land between the joe, and francesco books and the offcial docs making the whole thing a kind of bermude's triangle where you risk sinking when you try to match some thing form one to the other. Still a think there are many things on the docs that dont need close interventions of the otp people leaveing them free to focus on the code where the community can focus on the look n feel. Let's look the recent iconv snipet on erl_nif and "erl resource's" stuff, how releases will take to appear something like this on the "programming examples" users guide? Community can care of this better than OTP and far better than spreading knoledge here and there on the blogosphere... Even a wiki thing half-closed to a little amount of people covering some of you is more productive provided that we bare users can interact easily on the lists.. I have no prior expereince but on the PHP stuff but it got me some years to even think reading a php book because i didnt need such a thing being very proficient on the php docs site... -- Este correo no tiene dibujos. Las formas extra?as en la pantalla son letras. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Artista -- (internet) --> Usuario final. As? los artistas cobran m?s y dicen menos paridas sobre lo que creen que es la pirater?a. From vinayakapawar@REDACTED Fri Feb 19 10:26:33 2010 From: vinayakapawar@REDACTED (Vinayak Pawar) Date: Fri, 19 Feb 2010 14:56:33 +0530 Subject: [erlang-questions] rpc:call/4 In-Reply-To: References: Message-ID: <23237d041002190126k7b6e5f7o99f9a0d57ac5c7d4@mail.gmail.com> erlang:throw is mainly intended for doing non-local returns from function instead of error handling. Hence that bit odd rpc:call behaviour? Regards, Vinayak On Thu, Feb 18, 2010 at 2:08 PM, Jayson Vantuyl wrote: > I've encountered unexpected behavior when doing rpc:call/4 to a remote node > and the remote code has an exception. > > The "error case" seems to be {badrpc,Reason}, with reason completely > unspecified. Oddly, I get the following behavior: > > erlang:exit(X) gives {badrpc, {'EXIT',X}. > erlang:raise(X) gives {badrpc, {'EXIT',X,StackTrace}. > erlang:throw(X) gives X. > > The first two are pretty reasonable. The third one is a bit odd. > > In a number of places, the rpc:call infrastructure seems to use the > archaic: > > > case catch .... of ... end. > > In modern code, I would assume this would be the more expressive: > > > try ... of ... catch ... end. > > What is the expected behavior (the docs are a bit vague)? > > -- > Jayson Vantuyl > kagato@REDACTED > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From humaira.surve@REDACTED Fri Feb 19 10:34:01 2010 From: humaira.surve@REDACTED (Humaira) Date: Fri, 19 Feb 2010 11:34:01 +0200 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266567436.4073.6.camel@humaira-laptop> Message-ID: <1266572041.4073.8.camel@humaira-laptop> If possible, please forward me the code. On Fri, 2010-02-19 at 08:57 +0000, Chandru wrote: > On 19 February 2010 08:17, Humaira wrote: > > > > Hi Chandru, > > > > Thanks for the very useful information. I noticed that I have a > > different version of eldap than you are referring to. Where would one > > find the gen_fsm version? Is there a commonly used repository or is it > > the version from ejabberd? > > I'm not sure. The version I have was written by Tobbe (Torbj?rn > T?rnkvist) in 2000! If he reads this maybe he can tell us where to > find it. If not, I can send it to you. > > cheers > Chandru From kagato@REDACTED Fri Feb 19 11:09:02 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Fri, 19 Feb 2010 02:09:02 -0800 Subject: [erlang-questions] rpc:call/4 In-Reply-To: <23237d041002190126k7b6e5f7o99f9a0d57ac5c7d4@mail.gmail.com> References: <23237d041002190126k7b6e5f7o99f9a0d57ac5c7d4@mail.gmail.com> Message-ID: <1E3CE98C-0381-4876-A1E5-02303ABD7AF6@souja.net> Is this true? I mean, exit / error / throw has always been a very weird division to me. I can't say that I completely understand what the breakdown is, although I usually know which one I should use. Generally, throw is used as a form of high-level flow control, exit is for when you explicitly intend to exit a process, and error is for when you have an error (which defaults to terminating the process, but can be caught if it's expected). I can't imagine that the case catch is the right way to do it. The behavior is undocumented, and I really can't imagine that we should rely on it. As much as I love stability, I think it's safe to say that it's reasonable to expect people to update their code to run on updated versions of Erlang. This is why we deprecate things and have release notes. I can't imagine this to be any more disruptive than, say, deprecating the re module. As a member of the Erlang community, I really don't think we should go this direction: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4273532 That said, I'd love to hear from someone at Ericsson whether they think this is a bug. From the documentation, I think so. Intuitively I also feel that it's bad because it means that you can't distinguish between a throw and a return value if you use rpc:call. This is really a bad design bug in any rpc mechanism that wants to be event remotely transparent. I understand that when rpc was written, this was the only tool available. Times have changed. Is it worth my time to submit a patch? For that matter, I'd be interested in just eliminating this idiom from the whole of OTP. I don't think it's ever justified anymore. Of course, a crude check shows 2082 occurrences. That would be a pretty big patch. Then again, 370 of them are in tests, so that might be a good place to start... On Feb 19, 2010, at 1:26 AM, Vinayak Pawar wrote: > erlang:throw is mainly intended for doing non-local returns from function > instead of error handling. Hence that bit odd rpc:call behaviour? > > Regards, > Vinayak > > On Thu, Feb 18, 2010 at 2:08 PM, Jayson Vantuyl wrote: > >> I've encountered unexpected behavior when doing rpc:call/4 to a remote node >> and the remote code has an exception. >> >> The "error case" seems to be {badrpc,Reason}, with reason completely >> unspecified. Oddly, I get the following behavior: >> >> erlang:exit(X) gives {badrpc, {'EXIT',X}. >> erlang:raise(X) gives {badrpc, {'EXIT',X,StackTrace}. >> erlang:throw(X) gives X. >> >> The first two are pretty reasonable. The third one is a bit odd. >> >> In a number of places, the rpc:call infrastructure seems to use the >> archaic: >> >>> case catch .... of ... end. >> >> In modern code, I would assume this would be the more expressive: >> >>> try ... of ... catch ... end. >> >> What is the expected behavior (the docs are a bit vague)? >> >> -- >> Jayson Vantuyl >> kagato@REDACTED >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> -- Jayson Vantuyl kagato@REDACTED From chandrashekhar.mullaparthi@REDACTED Fri Feb 19 11:17:43 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Fri, 19 Feb 2010 10:17:43 +0000 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <1266572041.4073.8.camel@humaira-laptop> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266567436.4073.6.camel@humaira-laptop> <1266572041.4073.8.camel@humaira-laptop> Message-ID: Here it is. A correction to my previous statement - I think Sean Hinde modified Tobbe's code to use gen_fsm instead. regards, Chandru On 19 February 2010 09:34, Humaira wrote: > If possible, please forward me the code. > > On Fri, 2010-02-19 at 08:57 +0000, Chandru wrote: >> On 19 February 2010 08:17, Humaira wrote: >> > >> > Hi Chandru, >> > >> > Thanks for the very useful information. I noticed that I have a >> > different version of eldap than you are referring to. Where would one >> > find the gen_fsm version? Is there a commonly used repository or is it >> > the version from ejabberd? >> >> I'm not sure. The version I have was written by Tobbe (Torbj?rn >> T?rnkvist) in 2000! If he reads this maybe he can tell us where to >> find it. If not, I can send it to you. >> >> cheers >> Chandru > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: eldap.tar.gz Type: application/x-gzip Size: 26040 bytes Desc: not available URL: From bgustavsson@REDACTED Fri Feb 19 13:10:08 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 19 Feb 2010 13:10:08 +0100 Subject: [erlang-questions] rpc:call/4 In-Reply-To: <1E3CE98C-0381-4876-A1E5-02303ABD7AF6@souja.net> References: <23237d041002190126k7b6e5f7o99f9a0d57ac5c7d4@mail.gmail.com> <1E3CE98C-0381-4876-A1E5-02303ABD7AF6@souja.net> Message-ID: <6672d0161002190410l66165bf0recac7be5e2fcc8d0@mail.gmail.com> On Fri, Feb 19, 2010 at 11:09 AM, Jayson Vantuyl wrote: > Is it worth my time to submit a patch? I would say yes, and good time would be now so that it has a chance to be included in R14. But we can't guarantee that we will include any patch until we have seen it. We will need to evaluate whether there are backward compatibility issues or other problems. >For that matter, I'd be interested in just eliminating this idiom from the whole of OTP. > I don't think it's ever justified anymore. Of course, a crude check shows 2082 occurrences. That would be a pretty big patch. Then again, 370 of them are in tests, so that might be a good place to start... For that kind of clean-up, I suggest that you have at least one commit per application, and probably also separate commits for test cases and changes in applications. For applications, it could further help to separate internal uses of of old-style "catch" inside modules and other uses that may be noticeable by outside callers. The purpose of all this is to help us (and everyone else who is interested) to review the changes, and to allow us include the safe changes first before all other changes have been cleared. And good commit messages, that explain why the change should be included always helps. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kagato@REDACTED Fri Feb 19 13:12:51 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Fri, 19 Feb 2010 04:12:51 -0800 Subject: [erlang-questions] rpc:call/4 In-Reply-To: <6672d0161002190410l66165bf0recac7be5e2fcc8d0@mail.gmail.com> References: <23237d041002190126k7b6e5f7o99f9a0d57ac5c7d4@mail.gmail.com> <1E3CE98C-0381-4876-A1E5-02303ABD7AF6@souja.net> <6672d0161002190410l66165bf0recac7be5e2fcc8d0@mail.gmail.com> Message-ID: <898D40AF-D0E0-4546-81A9-36C3D374A7CC@souja.net> I'll try to have a patch for the initial case (rpc:call/4) today. Thanks, On Feb 19, 2010, at 4:10 AM, Bj?rn Gustavsson wrote: > On Fri, Feb 19, 2010 at 11:09 AM, Jayson Vantuyl wrote: > >> Is it worth my time to submit a patch? > > I would say yes, and good time would be now so that it has a chance > to be included in R14. > > But we can't guarantee that we will include any patch until we have seen > it. We will need to evaluate whether there are backward compatibility issues > or other problems. > >> For that matter, I'd be interested in just eliminating this idiom from the whole of OTP. >> I don't think it's ever justified anymore. Of course, a crude check shows 2082 occurrences. That would be a pretty big patch. Then again, 370 of them are in tests, so that might be a good place to start... > > For that kind of clean-up, I suggest that you have at least one commit > per application, > and probably also separate commits for test cases and changes in applications. > For applications, it could further help to separate internal uses of > of old-style "catch" > inside modules and other uses that may be noticeable by outside callers. > > The purpose of all this is to help us (and everyone else who is interested) to > review the changes, and to allow us include the safe changes first before all > other changes have been cleared. > > And good commit messages, that explain why the change should be included > always helps. > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -- Jayson Vantuyl kagato@REDACTED From rvirding@REDACTED Fri Feb 19 13:12:44 2010 From: rvirding@REDACTED (Robert Virding) Date: Fri, 19 Feb 2010 13:12:44 +0100 Subject: [erlang-questions] rpc:call/4 In-Reply-To: <1E3CE98C-0381-4876-A1E5-02303ABD7AF6@souja.net> References: <23237d041002190126k7b6e5f7o99f9a0d57ac5c7d4@mail.gmail.com> <1E3CE98C-0381-4876-A1E5-02303ABD7AF6@souja.net> Message-ID: <3dbc6d1c1002190412r71916f82jac2f8637a50f5c56@mail.gmail.com> On 19 February 2010 11:09, Jayson Vantuyl wrote: > Is this true? > > I mean, exit / error / throw has always been a very weird division to me. ?I can't say that I completely understand what the breakdown is, although I usually know which one I should use. ?Generally, throw is used as a form of high-level flow control, exit is for when you explicitly intend to exit a process, and error is for when you have an error (which defaults to terminating the process, but can be caught if it's expected). This is the generally accepted way of using them and I feel a good way of indicating what you mean. Throw is for non-local returns. About exit, which has no stacktrace, and error, which does. Originally, there was only exit without the stacktrace and at that time internal errors did not generate stacktraces. Then internal errors got stacktraces (a Big Win) but exit still didn't. Then later instead of changing exit to have stacktraces error was added. This, I feel, was a bad choice. So now there were two different ways of signaling a desire to exit/error with basically exactly the same semantics. Catch is older than try, from the time there was only exit and throw. We decided that it would both catch both exits and non-local returns (throw) and it would pass thrown values through unmarked and wrap an exit value with {'EXIT',...}. It is a feature that you can fake exit values, but as it very easy to program around this if you want to be safe we never felt that this was a problem. When try came along the separation into 3 different classes was perpetuated. Unfortunately being able to catch throws, while being very practical, I feel confused the issue of when to use what by equating a throw with exit/error. Erlang:raise/3 adds to this confusion because with it you can "raise" a throw which sounds strange if you mean it be a non-local return. > I can't imagine that the case catch is the right way to do it. ?The behavior is undocumented, and I really can't imagine that we should rely on it. As the behaviour of catch is documented I assume you mean rpc here. Robert From kagato@REDACTED Fri Feb 19 13:15:32 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Fri, 19 Feb 2010 04:15:32 -0800 Subject: [erlang-questions] rpc:call/4 In-Reply-To: <3dbc6d1c1002190412r71916f82jac2f8637a50f5c56@mail.gmail.com> References: <23237d041002190126k7b6e5f7o99f9a0d57ac5c7d4@mail.gmail.com> <1E3CE98C-0381-4876-A1E5-02303ABD7AF6@souja.net> <3dbc6d1c1002190412r71916f82jac2f8637a50f5c56@mail.gmail.com> Message-ID: <1CF0A9D5-3B34-41E0-85C5-1D80C7DC7147@souja.net> > As the behaviour of catch is documented I assume you mean rpc here. Yes, rpc. -- Jayson Vantuyl kagato@REDACTED From leap@REDACTED Fri Feb 19 14:23:25 2010 From: leap@REDACTED (Michael Turner) Date: Fri, 19 Feb 2010 13:23:25 +0000 Subject: [erlang-questions] What about making sense? In-Reply-To: <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> Message-ID: Well, it seems I was wrong about a marketing *origin* for the use of the term "application" in Erlang/OTP. But now that I know that "OTP application" is the basic unit of *sales and support* for Erlang/OTP, it certainly makes sense that marketing imperatives would perpetuate the use of the term, even if some elements of Erlang/OTP sold under that rubric don't actually conform to Erlang/OTP's own definition of "application". At this point, I guess it would just cause customer confusion (at some not very technical level, of course) to say something like this: "Well, sorry, but a few of the things we've been selling to you all along aren't actually applications, even in our own terms, but rather just libraries. But there's no loss of functionality in describing these things in more conventional terms. There's actually a slight gain in programmer educability, if you care about that. You're still getting all the same things. Which you were happy enough with, up to the present day, right?" No, somebody on the customer side would make an issue of it, a bargaining point. That's just how business people are: always looking for leverage in negotiations, present and future. I've experienced worse. I remember once having the term "rapid prototyping" expunged from a presentation I'd prepared. The explanation was that the key person with the most signature authority in the presentation's intended audience had once been sold on a "rapid prototyping" project that ended up taking 3 years and 20 programmers to complete. "But," I spluttered, "that's not rapid prototyping!" Guess what? It didn't matter. They couldn't afford to spook the guy. They substituted some other term. I've also seen better: A telecom network management software company I worked for under contract a few times used the blanket term "services package" for its software products So, for example, their whiz-bang super-buzzword-compliant persistent object store was called OSP - Object Services Package. Pretty vague term, perhaps, but at least not actually wrong. After all, it was a batch of software tools and middleware with a C++ API for objects stored in the RDBMS of the customer's choice. It was a package of library functions, and it had server software and interfaces that you started and stopped. At that critically-important-but-maddeningly-ignorant bureaucratic level where people in corporations sign for purchases they don't understand, the word "services" sounded mighty good, especially when all wrapped up in a "package." As for "objects", well, they're all over these magazine covers, y'see, so nobody's going to get fired for following that crowd. -michael turner On 2/19/2010, "Joe Armstrong" wrote: >On Thu, Feb 18, 2010 at 10:27 PM, Kenneth Lundin > wrote: >> On Wed, Feb 17, 2010 at 4:52 PM, Michael Turner wrote: >>> >>> >>> On 2/17/2010, "Robert Virding" wrote: >>> >>>>Without getting into the discussion how difficult, or not, it is to >>>>navigate the Erlang docs one source of the problem is that all the >>>>standard OTP libraries are proper Applications. >>> >>> People should think of the trigonometric functions as part of the STDLIB >>> Application, just because gen_server is grouped in with them, in stdlib? >>> >>> What sense does this make? >> >> I agree with you in that the documentation can be improved with better >> descriptions and more examples and guidelines. There is also need for >> good search facilities. We are working on both and we are releasing >> the complete documentation sources plus support to build the doc. The >> purpose with this is to make it possible for the community to help us >> improve the docs. >> >> I don't agree at all when you criticise the organization in : >> Toplevel System documentation plus all the "applications". >> Already on the introduction page at top-level (http://erlang.org/doc) it says >> "Erlang/OTP is divided into a number of OTP applications. An >> application normally contains Erlang modules. Some OTP applications, >> such as the C interface erl_interface, are written in other languages >> and have no Erlang modules. " >> >> As everything is organized as "applications" in the source code tree >> and applications actually are >> groups of modules which are released and upgraded together it makes >> perfect sense to structure the >> documentation the same way. >> >> An application can be a service that can be started and stopped or it >> can be a library of passive modules with functions it does not matter. >> The important thing is that an application is the smallest unit we >> handle when it comes to deliverables. We always provide a complete new >> version of a full application including documentation when we release >> binary patches. >> The documentation is treated the same way as code and is released >> together with the code to assure >> that you always have the documentation corresponding to the code. >> >> Our experience is that this is a very efficient way to handle >> documentation. We have no intention to change this. The documentation >> can and will be improved anyway. >> >> STDLIB and Kernel are unfortunately 2 basic (core) applications with a >> very mixed content. >> The criterias for what's in Kernel and what's in STDLIB ?are unclear , >> we have discussed to >> reorganize them some day but it has not been important enough to do >> it. It will also introduce >> potential incompatibilities. >> >> Regarding the name "application" I think it is somewhat unfortunate >> since everyone has an own idea >> about what an application is in general. For example in Ericsson an >> "application" is a complete product sold to end users. In Erlang it is >> a group of modules handled together, possibly started as a service. I >> think you have to blame Joe for naming it "application". > >I'm guilty - but we had to give these "things" a name so we could talk >about them. We could have called them glurks - "a glurk is a ..." but >this would be crazy. The nice thing about natural language is that the >meaning of a word is context dependent - so in the Erlang context >Application means "...". Now were Erlang to become wildly popular, to >the point where everybody lived breathed and dreamed Erlang dreams, >then the Erlang use of the world Application would become the de. >facto. standard and any other uses of the world would be viewed >suspect. > >Another bad word is "lists" - the things we call lists are not lists, they >are *stacks* if T is a stack then [H|T] is a new stack formed by pushing >H onto the stack. > >Stack is a much better word than list. > >"Kenneth - get your guys to stop what they're doing and change >all the use of the word stack to lists - and change all the modules >that use the world lists - from now on lists are stacks." > >"Sorry Joe, we have a problem, >the guys don't stacken to what I say" > >Sure there are problems with the terminology - did I say "problems" > >"Sorry Guv I meant 'issues', >"Did you mean 'challenges?'" >"Nnnn nnno .. 'Opportunities' > >/Joe > > > >>> >>>> So when when the >>>>documentation is organised around "applications", in one sense, it is >>>>being entirely logical and consistent. Of course, until you are more >>>>experienced and groked this it can be very confusing and difficult to >>>>find things. >>> >>> But in the meantime, conceptual/terminological confusion impedes the >>> learner, whenever he/she needs to resort to the Reference Manual. ?Given >>> that Erlang already poses quite a learning curve for some, this will >>> reduce the rate at which people become "more experienced and grok >>> this", and for that matter, it will reduce the number of people who >>> even want to get that far with Erlang. >> >> I don't really understand what you mean are the >> conceptual/terminological confusions except maybe >> application. >> >>> >>> What sense does this make? >>> >>> What goal does this serve? >>> >>> The goal of making it easier to autogenerate the documentation? >> >> I don't understand what you mean here. Most of the documentation 95% >> is handwritten. >> We strongly believe in single source and many generated presentations >> but this has no negative >> impact on the actual documentation. >> >> >>> >>> Well, I remember the days when we humans did a lot of things to make life >>> easier for the system. ?As I recall, it involved punching a lot of cards. >>> >>> >>> -michael turner >>> >> /Kenneth, Erlang/OTP Ericsson >>> >>> >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >>> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > From steven.charles.davis@REDACTED Fri Feb 19 14:41:18 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 19 Feb 2010 05:41:18 -0800 (PST) Subject: What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> Message-ID: <61481cf5-0218-4a49-a884-c503fbb5550b@g11g2000yqe.googlegroups.com> My 2c. On Feb 18, 3:27?pm, Kenneth Lundin wrote: > Most of the documentation 95% is handwritten. And as a result of this fact, nearly all of the documentation (over 95%) is of unusually high quality. It is definitely inconvenient when you are looking for something very specific, as it can be hard to search quickly - you often find that you have to know where you want to go before you know where you want to go. On the other hand, to provide that kind of search-ability adequately would likely mean adding a level of hand-written indexing/metadata to the entire body of documentation. I imagine that would be an highly laborious and non-trivial effort - so I'm not surprised that nobody has yet taken that on. There is a side-benefit of the current state of the docs: When searching for a particular thing, I quite often find myself reading about something entirely different, which I may not otherwise have read, and that improves my general education about erlang and the capabilities (and constraints) of the otp platform. /s From steven.charles.davis@REDACTED Fri Feb 19 15:04:41 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 19 Feb 2010 06:04:41 -0800 (PST) Subject: What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> Message-ID: <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> I somewhat disagree with this analysis... On Feb 19, 2:30?am, Michael Richter wrote: > I think that is the failing of Erlang documentation at this point. ?It's not > in tutorial-level information -- there's plenty of that and of very high > quality indeed (courtesy of Armstrong and Cesarini & Thompson). ?There's > more of it on the way. ?It's not in the reference-level information. ?What's > there isn't ideal nor is it ideally organized but it's OK. ?Better than some > languages, worse than others. ?What's missing is information like overviews > of the available libraries (or "applications" in Erlang-speak), what they do > and a general idea of how to use them. If you start at the front page of the existing docs and follow the advice given in those very first paragraphs, you won't go far wrong. http://www.erlang.org/doc/ If you actually read the docs sequentially, front to back, they absolutely *do* make a coherent whole. If you choose to read things in a different order, then you will miss something and probably get confused. However, there's no real need to skip around as the docs provided are not verbose and are rarely ambiguous. /s From Antonio.Musumeci@REDACTED Fri Feb 19 15:49:42 2010 From: Antonio.Musumeci@REDACTED (Musumeci, Antonio S) Date: Fri, 19 Feb 2010 09:49:42 -0500 Subject: net_kernel:handle_call Message-ID: <01489E237C2C8F45AF7898E135F48E8001DA64D146@NYWEXMBX2129.msad.ms.com> Is it intentional that there is no catch all function declaration in net_kernel for handle_call? gen_server:call(net_kernel, blah). or gen_server:call({net_kernel,remoteNode}, blah). will cause it to exit. It's handled fine in the case of casts however. -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. From dmercer@REDACTED Fri Feb 19 16:00:13 2010 From: dmercer@REDACTED (David Mercer) Date: Fri, 19 Feb 2010 09:00:13 -0600 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> Message-ID: On February 18, Steve Davis wrote: > I have found that the more I have used parameterized modules... the > less I use parameterized modules. > > If you get what I'm saying. I do not. Can you please explain? Thank-you. David From max.lapshin@REDACTED Fri Feb 19 16:08:26 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 19 Feb 2010 18:08:26 +0300 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> Message-ID: For example if some module is parameterized, you cannot access its functions without calling new() So it looks like if you have either instance method of objects, either class method, not both of them. From ttmrichter@REDACTED Fri Feb 19 16:33:44 2010 From: ttmrichter@REDACTED (Michael Richter) Date: Fri, 19 Feb 2010 23:33:44 +0800 Subject: [erlang-questions] Re: What about making sense? In-Reply-To: <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> Message-ID: On 19 February 2010 22:04, Steve Davis wrote: > I somewhat disagree with this analysis... > > On Feb 19, 2:30 am, Michael Richter wrote: > > I think that is the failing of Erlang documentation at this point. It's > not > > in tutorial-level information -- there's plenty of that and of very high > > quality indeed (courtesy of Armstrong and Cesarini & Thompson). There's > > more of it on the way. It's not in the reference-level information. > What's > > there isn't ideal nor is it ideally organized but it's OK. Better than > some > > languages, worse than others. What's missing is information like > overviews > > of the available libraries (or "applications" in Erlang-speak), what they > do > > and a general idea of how to use them. > > If you start at the front page of the existing docs and follow the > advice given in those very first paragraphs, you won't go far wrong. > > http://www.erlang.org/doc/ I do not see anything there which gives guidance on how to use dialyzer, edoc and typer together in the same source file. On the subtle, vaguely incompatible differences in notation between these three. Did I miss something? > If you actually read the docs sequentially, front to back, they > absolutely *do* make a coherent whole. > I respectfully disagree. I humbly submit further that you are not doing what I suggested by looking at the existing docs with a newb's eyes. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. From erlang@REDACTED Fri Feb 19 16:41:50 2010 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 19 Feb 2010 16:41:50 +0100 Subject: [erlang-questions] What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> Message-ID: <9b08084c1002190741h77dc491x5f659b343061d736@mail.gmail.com> On Fri, Feb 19, 2010 at 9:30 AM, Michael Richter wrote: > I think we have a lot of cross-talk going on here. > Item: Some people believe that the Erlang docs as they are interfere with > comprehension, partially because of inconsistent and unusual use of > terminology. > Item: Some people see no problem with the docs as they are. > The truth lies somewhere in the middle, I believe. > The docs are nowhere near as dire as some of the more vociferous > commentators are portraying them. ?Are they ideal? ?No. ?Are they even good? > ?Not really. ?They are about average for this industry (which is a > condemnation of the industry's standards, not of the writers). ?They are, > however, adequate. ?As references. ?If you already know what it is you're > looking for (or should be looking for) the docs as they stand are more than > adequate. > What they are terrible for is learning tools. ?This is a problem in general > for Erlang, partially because it's a relatively new tool on the scene (the > public scene, that is -- I know it's been around for ages inside Ericcson) > and partially because it's a small community around it with only a very > small number of grognards who know it all. Correct - the OTP documentation was designed for a target audience of internal Ericssomn folk who has already been on a course, and who could stop me or Uffe or Robert, Klacke etc. in the corridor and ask us a question > On the learning front now we have two great tools (Programming Erlang?and > Erlang Programming) with a third on the way (Erlang and OTP in Action) for > tutorial introductions. ?These first two have been great for my picking up > Erlang, for example, but now another barrier has crossed my path. ?There's > no documentation in between the "Erlang for Complete Newbs" stuff and the > "Reminders for the Grognards" stuff. Great - the books were designed for beginners - my target audience were "folk who were proficient in Java and had no exposure to FPLs" In fact we got some tame Java programmers to read few sample chapters before deciding the final level of complexity. So far no surprises - the OTP documentaion and books meet *exactly* the requirements we had when we started the projects. What's happing now is a shift in the requirements. I'd like to ask some pointed questions, the results will influene what happens next. Can anybody point me to a good free survey site - I want to ask questions and get a histogram of the replies. If we can first find out *what* you want we can then figure out *how* to achieve it. The first question is about books. I can think of the following titles: 1) Real beginner - lower level than the Prag or O'reilly books, chatty tone 2) Theory - a theory of concurrency oriented programming - why share-nothing agent programming is good. Design patterns. distributed algorithms. How does leadership election work, DHTs etc academic in tone. 3) How to books - take one subsystem and document all the nitty gritty stuff. Candidates - mnesia - yaws - ejabberd - asn1 - [you name it] 4) How to book, with emphasis on setup. Lots of details where to fetch, how to compile etc. (not generic - with sections for Ubuntu, OS-X and windows 7) one chapter/per topic - ejabberd - mochiweb - scalaris - nitrogen - [you name it] 6) Case studies (business) Not sure if this is even possible. I'm thinking the business case behind sucessfull Erlang companies. What they did and why (technical stuff) This is the book I'd want to read - but much is still commercially sensitive 7) case studies (technical) How was X built and why? Give the history. What worked, what failed. Basically interviews with the lead developers of each X For X in yaws ejabberd [you name it] 8) Other [you name it] Comments 4) and 7) seem to be the easiest to produce - just decide on the chapters (please suggest topics) and recruit one volunteer per chapter (no problem with domain experts here) and an editor and some reviewers. 3) is pretty difficult - very few people know everything about a particular sub-system - and even if they do might not want to spend thousands of hours documenting it - sales would be small anyway (I suspect) 1) and 2) are possible 7) might make a nice web site - need not be a book I'll put these question on a survey site, so people can vote, if somebody can suggest one - or can we do this on the main erlang site??? Cheers /Joe > I think that is the failing of Erlang documentation at this point. ?It's not > in tutorial-level information -- there's plenty of that and of very high > quality indeed (courtesy of Armstrong and Cesarini & Thompson). ?There's > more of it on the way. ?It's not in the reference-level information. ?What's > there isn't ideal nor is it ideally organized but it's OK. ?Better than some > languages, worse than others. ?What's missing is information like overviews > of the available libraries (or "applications" in Erlang-speak), what they do > and a general idea of how to use them. ?What's missing is good sample code > for these "applications". ?Use case scenarios. ?Where they are well-applied. > ?Where they are not so well applied. ?There is a great deal of stuff in the > Erlang/OTP distribution. ?Here's a list of it: > > appmon-2.1.10.2/ > asn1-1.6.12/ > common_test-1.4.6/ > compiler-4.6.4/ > cosEvent-2.1.7/ > cosEventDomain-1.1.7/ > cosFileTransfer-1.1.9/ > cosNotification-1.1.12/ > cosProperty-1.1.10/ > cosTime-1.1.7/ > cosTransactions-1.2.8/ > crypto-1.6.3/ > debugger-3.2.1/ > dialyzer-2.1.0/ > docbuilder-0.9.8.6/ > edoc-0.7.6.5/ > erl_docgen-0.1/ > erl_interface-3.6.4/ > erts-5.7.4/ > et-1.3.3/ > eunit-2.1.4/ > gs-1.5.11/ > hipe-3.7.4/ > ic-4.2.23/ > inets-5.2/ > inviso-0.6.1/ > jinterface-1.5.2/ > kernel-2.13.4/ > megaco-3.13/ > mnesia-4.4.12/ > observer-0.9.8.1/ > odbc-2.10.6/ > orber-3.6.14/ > os_mon-2.2.4/ > otp_mibs-1.0.6/ > parsetools-2.0.1/ > percept-0.8.3/ > pman-2.7.1/ > public_key-0.4/ > reltool-0.5.2/ > runtime_tools-1.8.2/ > sasl-2.1.8/ > snmp-4.15/ > ssh-1.1.7/ > ssl-3.10.7/ > stdlib-1.16.4/ > syntax_tools-1.6.4/ > test_server-3.3.5/ > toolbar-1.4.1/ > tools-2.6.5/ > tv-2.1.4.4/ > typer-0.1.7.3/ > webtool-0.8.5/ > wx-0.98.4/ > xmerl-1.2.3/ > > That is a pretty intimidating list for a newcomer to be faced with and there > really isn't a good overview of what each is, where each might be applicable > and how they interact with each other. ?(No, a list on the left pane doesn't > qualify as guidance!) ?Grognards who have been working with Erlang since > forever, I think, are forgetting that newcomers to Erlang are faced with a > lot of hurdles all at once. ?Newcomers are often faced with their first > functional language. ?They're faced with their first actor-based concurrency > model. ?They're faced with an unfamiliar syntax that even old-timers have to > admit can be opaque and a bit strange. ?They're faced with libraries--Oops! > ?"Applications"!-- that don't play well together (edoc vs. typer vs. > dialyzer for example). ?They're faced with all of this and get little to no > guidance short of community legend and lore to navigate through it. > I can see how this can be frustrating and how it can lead to the increasing > levels of heat showing up in this thread. ?Unfortunately the heat is now > doing nothing but getting people on each side riled up, feeling embattled > and digging in as a result. ?I'd like to ask for two things to help calm > this down: > > Grognards, please try and understand the position of a complete newcomer. > ?Imagine, for a moment, that you haven't been working with Erlang for years. > ?Look at the documentation that exists as if it were your first time. ?Look > at that list of "applications", the unusual terminology, the language that > is pretty much unlike anything else out there in common use and ask (and > answer) yourself honestly: is this sufficient for learning? ?Is this helpful > to a newcomer to the language? ?If, as I expect, you answer "no" to these > questions, ask yourself also what needs to change to make these helpful and > sufficient and, more importantly, what processes can be put in place to > speed along development of such tools by bringing in community input. > Newbies (like me), please also try to understand the position the grognards > are in. ?Like you they are hired to be (or have made businesses to be) > productive with code. ?They're developers and not technical writers. > ?Further the fruits of their labour are being given you at no (fiscal) cost. > ?It is a bit unseemly to harshly criticize their (from their employers' > perspective) non-productive labour when they, too, face the real world of > software development with unrealistic schedules and deadlines, moving > requirements and feature creep. ?Be thankful for what is there already and > perhaps have a little patience as the rest gets released and the processes > get ironed out to have community input. > > -- > "Perhaps people don't believe this, but throughout all of the discussions of > entering China our focus has really been what's best for the Chinese people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. > From erlang@REDACTED Fri Feb 19 16:57:34 2010 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 19 Feb 2010 16:57:34 +0100 Subject: [erlang-questions] Re: What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> Message-ID: <9b08084c1002190757o3a4c2bc0s89cc07b8fafe2af0@mail.gmail.com> On Fri, Feb 19, 2010 at 4:33 PM, Michael Richter wrote: > On 19 February 2010 22:04, Steve Davis wrote: > >> I somewhat disagree with this analysis... >> >> On Feb 19, 2:30 am, Michael Richter wrote: >> > I think that is the failing of Erlang documentation at this point. ?It's >> not >> > in tutorial-level information -- there's plenty of that and of very high >> > quality indeed (courtesy of Armstrong and Cesarini & Thompson). ?There's >> > more of it on the way. ?It's not in the reference-level information. >> ?What's >> > there isn't ideal nor is it ideally organized but it's OK. ?Better than >> some >> > languages, worse than others. ?What's missing is information like >> overviews >> > of the available libraries (or "applications" in Erlang-speak), what they >> do >> > and a general idea of how to use them. >> >> If you start at the front page of the existing docs and follow the >> advice given in those very first paragraphs, you won't go far wrong. >> >> http://www.erlang.org/doc/ > > > I do not see anything there which gives guidance on how to use dialyzer, > edoc and typer together in the same source file. ?On the subtle, vaguely > incompatible differences in notation between these three. ?Did I miss > something? No - you are absolutely correct. The dialyzer, edoc etc. are fine tools used individually - but they do not play together well. Nor do inline @spec etc in the erlang code play well with other tools. We are aware of this, and if you search the erlang list you'll find several postings about this. I've been struggling to define "best practise" for unit-testing, dialyzing, edocing etc. ie try and throw every tool at your code, but progress is slow. It will be fixed in the goodness of time - who knows as I write this some brave soul might download edoc and see to it that it uses the same type parser as the dialyser and see to it that this is up-to-date with the main parser. The trouble is that making (say) edoc consistent with the dialyzer might break a lot of legacy edoc code - which upsets people. The trouble is fundamental in nature. If you make A and B and A and B are small rather useful tools, then A and B will attract users and become big valuable tools. At this stage you might notice an overlap in what A and B do - this would not be noticed when A and B were small. Bringing A into line with B could break legacy A code, and vice versa. This is basically the problem with the entire documentation. We have legacy XML annotations that are used in a tiny tiny fraction of the code. But complete out-phasing means manually checking stuff that hasn't been touched for year. Bringing stuff into line *without breaking the old stuff* is very difficult. All I can say is that we are aware of the problem and are trying to fix it. /Joe > > >> If you actually read the docs sequentially, front to back, they >> absolutely *do* make a coherent whole. >> > > I respectfully disagree. ?I humbly submit further that you are not doing > what I suggested by looking at the existing docs with a newb's eyes. > > -- > "Perhaps people don't believe this, but throughout all of the discussions of > entering China our focus has really been what's best for the Chinese people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. > From rtrlists@REDACTED Fri Feb 19 17:07:46 2010 From: rtrlists@REDACTED (Robert Raschke) Date: Fri, 19 Feb 2010 16:07:46 +0000 Subject: [erlang-questions] net_kernel:handle_call In-Reply-To: <01489E237C2C8F45AF7898E135F48E8001DA64D146@NYWEXMBX2129.msad.ms.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64D146@NYWEXMBX2129.msad.ms.com> Message-ID: <6a3ae47e1002190807i6ffffc52x50f34aaa3e3947c2@mail.gmail.com> Hello Antonio, On Fri, Feb 19, 2010 at 2:49 PM, Musumeci, Antonio S < Antonio.Musumeci@REDACTED> wrote: > Is it intentional that there is no catch all function declaration in > net_kernel for handle_call? > > gen_server:call(net_kernel, blah). > > or > > gen_server:call({net_kernel,remoteNode}, blah). > > will cause it to exit. > > It's handled fine in the case of casts however. > > It is very common for gen_server code to have a handle_cast(_, State) -> {noreply,State}. if no cast requests are actually implemented, because having no handle_cast/2 at all leads to a compiler warning for the missing callback. You'll see the same done for other "unimplemented" gen_server callback functions like code_change/3 or handle_info/2. And as you are not meant to use gen_server:call/3 directly, but through a proper interface function you provide as part of your server implementation, most handle_call/3 implementation only have clauses for actually implemented requests. Robby From zerthurd@REDACTED Fri Feb 19 17:23:00 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Fri, 19 Feb 2010 22:23:00 +0600 Subject: [erlang-questions] aes-128-cbc decryption in erlang Message-ID: Hello What is erlang crypto analog of following comand? openssl enc -d -aes-128-cbc -pass env:KEY -in file.ssl -out file.txt There is function aes_cbc_128_decrypt which takes Key, IVec and encoded data, but how I can get an IVec? crypto:aes_cbc_ivec returns some IVec, but when it passed to aes_cbc_128_decrypt I have wrong output of decoded data. May be I doing something wrong? -- Maxim Treskin From Antonio.Musumeci@REDACTED Fri Feb 19 17:23:08 2010 From: Antonio.Musumeci@REDACTED (Musumeci, Antonio S) Date: Fri, 19 Feb 2010 11:23:08 -0500 Subject: [erlang-questions] net_kernel:handle_call In-Reply-To: <6a3ae47e1002190807i6ffffc52x50f34aaa3e3947c2@mail.gmail.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64D146@NYWEXMBX2129.msad.ms.com> <6a3ae47e1002190807i6ffffc52x50f34aaa3e3947c2@mail.gmail.com> Message-ID: <01489E237C2C8F45AF7898E135F48E8001DA64D18E@NYWEXMBX2129.msad.ms.com> Seems like a rather dangerous paradigm even if the general pattern for dealing with errors is to exit and restart. While not directly comparable... in other languages when you ask for an invalid service (method, function, etc) the caller not the called errors. I understand the point about cast but handle_info works the same way too. Additionally to what I said above it seems inconsistent. ________________________________ From: Robert Raschke [mailto:rtrlists@REDACTED] Sent: Friday, February 19, 2010 11:08 AM To: Musumeci, Antonio S (IT) Cc: erlang-questions@REDACTED Subject: Re: [erlang-questions] net_kernel:handle_call Hello Antonio, On Fri, Feb 19, 2010 at 2:49 PM, Musumeci, Antonio S > wrote: Is it intentional that there is no catch all function declaration in net_kernel for handle_call? gen_server:call(net_kernel, blah). or gen_server:call({net_kernel,remoteNode}, blah). will cause it to exit. It's handled fine in the case of casts however. It is very common for gen_server code to have a handle_cast(_, State) -> {noreply,State}. if no cast requests are actually implemented, because having no handle_cast/2 at all leads to a compiler warning for the missing callback. You'll see the same done for other "unimplemented" gen_server callback functions like code_change/3 or handle_info/2. And as you are not meant to use gen_server:call/3 directly, but through a proper interface function you provide as part of your server implementation, most handle_call/3 implementation only have clauses for actually implemented requests. Robby -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. From tsuraan@REDACTED Fri Feb 19 17:46:21 2010 From: tsuraan@REDACTED (tsuraan) Date: Fri, 19 Feb 2010 10:46:21 -0600 Subject: [erlang-questions] Keyword documentation In-Reply-To: References: <84fb38e31002182210s183e3209w449e2693a975e4f2@mail.gmail.com> Message-ID: <84fb38e31002190846q35ca157fm80f5a01f00878693@mail.gmail.com> > The following are reserved words in Erlang: Ok, so assuming no definitive list of what they do exists, I guess I'll start one :) These are either from the top of my head, or http://erlang.org/doc/reference_manual/expressions.html . Any corrections, completions, clarifications are welcome. > after Sets the timeout in a receive block > and boolean logic "and" > andalso short-circuiting "and" > band bitwise "and" > begin Start a block, used for grouping expresssions (no idea what use it is) > bnot > bor bitwise "not" and "or" > bsl > bsr Shift bits left and right > bxor bitwise "xor" > case Beginning of a case statement, sort of like C's switch statement > catch Trap an error, converting it into the tuple {'EXIT', ...}. If no error occurs, the result of the wrapped function is returned. Also used in the try statement. > cond ? > div integer division > end Complete a statement (fun, case, try, etc). > fun Begin an anonymous function > if Erlang's crazy if statement. > let ? > not Logical "not" > of Goes between value of case statement and guard clauses > or Logical "or" > orelse Short-circuiting "or" > query Obsolete, something about mneosyne? > receive used to get the next message from the process mailbox > rem Remainder from integer division (modulus) > try New way to trap errors, used with catch and ends with end > when Start a guard sequence for receive, function declaration, others? > xor Logical xor From rtrlists@REDACTED Fri Feb 19 18:33:36 2010 From: rtrlists@REDACTED (Robert Raschke) Date: Fri, 19 Feb 2010 17:33:36 +0000 Subject: Overlong wait in receive after Message-ID: <6a3ae47e1002190933haec817j7258ae66b00dbc1a@mail.gmail.com> Hi, has anyone encountered spurious overlong waits using receive ... after? That is, the code says "after 1000 ->" but it's way longer than 1 second before it gets there. My code starts a Java jinterface node, the Java code creates the node, creates an mbox, and waits a minute for a message to appear and sends one back. The Erlang code starts the Java as a port program, and starts sending ok messages to the registered mbox of the Java program spaced 1 second apart. My logging indicates that the sending of the messages is actually spaced somewhere between 5 and 12 seconds apart! This is on a Windows 2003 Server running R12B-5. In Erlang (started with -sname "erl@REDACTED") this is roughly what's happening (apologies for typos): run() -> Node_Name = "foo@REDACTED", Mbox = {box, list_to_atom(Node_Name)}, Port_Pid = spawn_link(?MODULE, run_port_program, [Node_Name, atom_to_list(erlang:get_cookie())]), {ok, Java_Pid} = shake_hands(Mbox, 0). shake_hands(Mbox, N) when N < 50 -> error_logger:info_report([{module, ?MODULE}, {handshake, N}, {mbox, Mbox}]), Mbox ! {self(), ok}, receive {ok, Pid} -> {ok, Pid} after 1000 -> error_logger:error_report([{module, ?MODULE}, {'handshake timeout', N}]), shake_hands(Mbox, N+1) end; shake_hands(_Mbox, N) when N >= 50 -> timeout. run_port_program(Node_Name, Cookie) -> Cmd = lists:flatten(["java MyCode \"", Node_Name, "\" \"", Cookie, "\""]), P = open_port({spawn, Cmd}, [stream, {line, 100}, exit_status]), loop(P, Node_Name, [], []). loop(Port, Name, Response, Line) -> %% handle the messages coming from Java's stdout ... And the Java bit is doing: String node_name = args[0]; String cookie = args[1]; OtpNode node = new OtpNode(node_name, cookie); OtpMbox mbox = node.createMbox("box"); OtpErlangTuple msg = (OtpErlangTuple) mbox.receive(60000); And my log contains entries where the time between the 'handshake' and the 'handhsake timeout' is somewhere between 5 and 12 seconds! Most of the times the Java mbox.receive(60000) ends up timing out, after which, suddenly, the log messages end up being 1 second spaced! All extremely puzzling. To me it looks like something on the machine is interfering with low-level comms. But that is currently just a hunch. Any pointers or ideas on where to go hunting are greatly appreciated. I'll probably try to create a standalone setup next, to see if I can find some minimal code to exhibit this behaviour. Thanks, Robby From caio.ariede@REDACTED Fri Feb 19 19:10:43 2010 From: caio.ariede@REDACTED (caio ariede) Date: Fri, 19 Feb 2010 16:10:43 -0200 Subject: [erlang-questions] Keyword documentation In-Reply-To: <84fb38e31002190846q35ca157fm80f5a01f00878693@mail.gmail.com> References: <84fb38e31002182210s183e3209w449e2693a975e4f2@mail.gmail.com> <84fb38e31002190846q35ca157fm80f5a01f00878693@mail.gmail.com> Message-ID: <6a9ba5691002191010m56a63f43ob8006b98a642e121@mail.gmail.com> What does "cond" and "let" do? Caio Ariede http://caioariede.com/ On Fri, Feb 19, 2010 at 2:46 PM, tsuraan wrote: > > The following are reserved words in Erlang: > > Ok, so assuming no definitive list of what they do exists, I guess > I'll start one :) These are either from the top of my head, or > http://erlang.org/doc/reference_manual/expressions.html . Any > corrections, completions, clarifications are welcome. > > > after > Sets the timeout in a receive block > > > and > boolean logic "and" > > > andalso > short-circuiting "and" > > > band > bitwise "and" > > > begin > Start a block, used for grouping expresssions (no idea what use it is) > > > bnot > > bor > bitwise "not" and "or" > > > bsl > > bsr > Shift bits left and right > > > bxor > bitwise "xor" > > > case > Beginning of a case statement, sort of like C's switch statement > > > catch > Trap an error, converting it into the tuple {'EXIT', ...}. If no > error occurs, the result of the wrapped function is returned. Also > used in the try statement. > > > cond > ? > > > div > integer division > > > end > Complete a statement (fun, case, try, etc). > > > fun > Begin an anonymous function > > > if > Erlang's crazy if statement. > > > let > ? > > > not > Logical "not" > > > of > Goes between value of case statement and guard clauses > > > or > Logical "or" > > > orelse > Short-circuiting "or" > > > query > Obsolete, something about mneosyne? > > > receive > used to get the next message from the process mailbox > > > rem > Remainder from integer division (modulus) > > > try > New way to trap errors, used with catch and ends with end > > > when > Start a guard sequence for receive, function declaration, others? > > > xor > Logical xor > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From jay@REDACTED Fri Feb 19 19:12:25 2010 From: jay@REDACTED (Jay Nelson) Date: Fri, 19 Feb 2010 10:12:25 -0800 Subject: [erlang-questions] Keyword documentation Message-ID: <3AD2DE1C-66A3-4FE0-BD06-4CA0BF4C65A1@duomark.com> tsuraan wrote: > begin Start a block, used for grouping expresssions (no idea what use it is) --------------------- Most common uses I've found are in list comprehensions: [ X || X <- List, begin FooVal = foo(X), ... complex test using FooVal more than once ... end ]. [ begin FooVal = foo(X), ... complex expression using FooVal more than once ... end || X <- List ]. It lets you introduce temporary variables in places where the context makes it difficult to reference them. I do this for documentation purposes sometimes (see R.O.K.s previous objection to F local fun var), and when a call to an expensive function needs to occur more than once in a decision process. Also works in binary comprehensions: << << X >> || << X >> <= Binary, begin FooVal = foo(X), ... end >>. << <<(begin FooVal = foo(X), ... end)>> || << X >> <= Binary >>. The parens are necessary because the expression in the binary constructor has to be evaluated and returned as a valid element before the binary construction can occur. The value of a begin ... end construct is the value of the last statement. jay From rickard@REDACTED Fri Feb 19 19:57:33 2010 From: rickard@REDACTED (Rickard Green) Date: Fri, 19 Feb 2010 19:57:33 +0100 Subject: [erlang-questions] Errors reported by valgrind In-Reply-To: <4B7E3ED4.1080700@iki.fi> References: <4B7E3ED4.1080700@iki.fi> Message-ID: <10d7e35f1002191057n2a6de1c2xa16cdccb58adee85@mail.gmail.com> There are at least two things confusing valgrind memcheck; our own inline assembler implementations of atomics and our own memory allocators. You want to build an emulator of TYPE "valgrind" as described in the "How to Build a Debug Enabled Erlang RunTime System" section of http://github.com/erlang/otp/blob/ccase/r13b04_dev/INSTALL.md . This is how our daily valgrind tests are built. Run it as "$ERL_TOP/bin/cerl -valgrind". In this emulator we have disabled or replaced things that confuses valgrind memcheck. You will probably get a bunch of warnings anyhow. Typically driver binaries potentially lost which are false positives. Unfortunately our valgrind suppression file isn't publicly available and cannot be used with an unmodified valgrind. Hopefully a suppressions file that can be used will show up in git some time in the future. Helgrind is not possible to use since some of our own locking mechanisms that valgrind don't know about cannot easily be replaced. It is on our todo-list to make it possible to use helgrind, but I cannot promise you when this will be done. We have our own lock-checker tool that gets enabled when you debug compile the emulator. It cannot detect all errors that helgrind can, but it detects misuse of our internal thread interface and lock order violations. Regards, Rickard Green, Erlang/OTP, Ericsson AB 2010/2/19 Martti Kuparinen : > Hi, > > I'm using 64-bit Ubuntu 9.10 and I downloaded R13B03 and compiled it with > > > CFLAGS="-g" LDFLAGS="-g" ./configure --prefix=/tmp/otp13b3 --enable-threads > --enable-smp-support --enable-kernel-poll --enable-hipe > --enable-megaco-flex-scanner-lineno --enable-megaco-reentrant-flex-scanner > --enable-dynamic-ssl-lib--enable-shared-zlib > make > > > Next I wanted to see what valgrind 3.5.0 thinks so I executed > > > cd bin/x86_64-unknown-linux-gnu > export BINDIR=`pwd` > > valgrind --trace-children=yes --verbose --leak-check=full \ > --show-reachable=yes --track-origins=yes --malloc-fill=AB \ > --free-fill=CD \ > ./erlexec > q(). > > ==24653== LEAK SUMMARY: > ==24653== definitely lost: 57,344 bytes in 7 blocks > ==24653== indirectly lost: 0 bytes in 0 blocks > ==24653== possibly lost: 2,108,608 bytes in 15 blocks > ==24653== still reachable: 9,001,366 bytes in 89 blocks > ==24653== suppressed: 0 bytes in 0 blocks > ==24653== > ==24653== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 4 from 4) > > > I also executed > > > valgrind --trace-children=yes --verbose --tool=helgrind \ > ./erlexec > q(). > > ==24733== ERROR SUMMARY: 754 errors from 97 contexts (suppressed: 13211 from > 190) > > > Most of those were "Possible data race during write of size X" and "Thread > #X: lock order ... violated" kind of errors. > > Anyone else getting similar results? Should I file a problem report (where?) > or is this mail enough? > > Martti > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From tsuraan@REDACTED Fri Feb 19 20:23:56 2010 From: tsuraan@REDACTED (tsuraan) Date: Fri, 19 Feb 2010 13:23:56 -0600 Subject: [erlang-questions] Keyword documentation In-Reply-To: <3AD2DE1C-66A3-4FE0-BD06-4CA0BF4C65A1@duomark.com> References: <3AD2DE1C-66A3-4FE0-BD06-4CA0BF4C65A1@duomark.com> Message-ID: <84fb38e31002191123v4b5f1356p592e05e0cd587a00@mail.gmail.com> > Most common uses I've found are in list comprehensions: > > [ X || X <- List, begin FooVal = foo(X), ... complex test using > FooVal more than once ... end ]. > > [ begin > FooVal = foo(X), > ... complex expression using FooVal more than once ... > end || X <- List ]. > > > > It lets you introduce temporary variables in places where the context > makes it difficult to reference them. > I do this for documentation purposes sometimes (see R.O.K.s previous > objection to F local fun var), and when a call to an expensive > function needs to occur more than once in a decision process. > > > Also works in binary comprehensions: > > << << X >> || << X >> <= Binary, begin FooVal = foo(X), ... end >>. > > << <<(begin FooVal = foo(X), ... end)>> || << X >> <= Binary >>. > > The parens are necessary because the expression in the binary > constructor has to be evaluated and returned as a valid element > before the binary construction can occur. That's some crazy stuff. I never would have thought of doing that, but now that I've seen it... Thanks a ton! From geoffrey.biggs@REDACTED Fri Feb 19 20:25:08 2010 From: geoffrey.biggs@REDACTED (Geoff Biggs) Date: Sat, 20 Feb 2010 04:25:08 +0900 Subject: [erlang-questions] What about making sense? In-Reply-To: <9b08084c1002190741h77dc491x5f659b343061d736@mail.gmail.com> References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <9b08084c1002190741h77dc491x5f659b343061d736@mail.gmail.com> Message-ID: <1266607508.3182.1360880645@webmail.messagingengine.com> 8) A cookbook (I don't think any of the other options adequately covers this). The recipes books that O'Reilly produces for several languages are so immensely useful. Examples: http://www.amazon.com/Python-Cookbook-Alex-Martelli/dp/0596007973 http://www.amazon.com/Perl-Cookbook-Tom-Christiansen/dp/1565922433 Geoff On Fri, 19 Feb 2010 16:41 +0100, "Joe Armstrong" wrote: > I'd like to ask some pointed questions, the results will influene what > happens > next. > > Can anybody point me to a good free survey site - I want to ask questions > and get a histogram of the replies. If we can first find out *what* you > want > we can then figure out *how* to achieve it. > > The first question is about books. I can think of the following titles: > > 1) Real beginner - lower level than the Prag or O'reilly books, > chatty > tone > > 2) Theory - a theory of concurrency oriented programming - why > share-nothing agent programming is good. Design patterns. > distributed algorithms. How does leadership election work, DHTs > etc > academic in tone. > > 3) How to books - take one subsystem and document all the nitty > gritty stuff. > Candidates > > - mnesia > - yaws > - ejabberd > - asn1 > - [you name it] > > 4) How to book, with emphasis on setup. Lots of details > where to fetch, how to compile etc. > > (not generic - with sections for Ubuntu, OS-X and windows 7) > > one chapter/per topic > > - ejabberd > - mochiweb > - scalaris > - nitrogen > - [you name it] > > 6) Case studies (business) > Not sure if this is even possible. > I'm thinking the business case behind sucessfull Erlang > companies. > What they did and why (technical stuff) > This is the book I'd want to read - but much is still > commercially sensitive > > 7) case studies (technical) > How was X built and why? Give the history. What worked, what > failed. > Basically interviews with the lead developers of each X > > For X in > yaws > ejabberd > [you name it] > > 8) Other > [you name it] > > Comments > > 4) and 7) seem to be the easiest to produce - just decide on the > chapters > (please suggest topics) and recruit one volunteer per chapter (no > problem with domain experts here) and an editor and some reviewers. > > 3) is pretty difficult - very few people know everything about a > particular > sub-system - and even if they do might not want to spend thousands of > hours documenting it - sales would be small anyway (I suspect) > > 1) and 2) are possible > > 7) might make a nice web site - need not be a book > > I'll put these question on a survey site, so people can vote, if somebody > can suggest one - or can we do this on the main erlang site??? > > Cheers > > /Joe From erlangy@REDACTED Fri Feb 19 20:55:22 2010 From: erlangy@REDACTED (Michael) Date: Fri, 19 Feb 2010 11:55:22 -0800 Subject: [erlang-questions] Overlong wait in receive after In-Reply-To: <6a3ae47e1002190933haec817j7258ae66b00dbc1a@mail.gmail.com> References: <6a3ae47e1002190933haec817j7258ae66b00dbc1a@mail.gmail.com> Message-ID: <20100219195522.GH5805@delora.autosys.us> On Fri, Feb 19, 2010 at 05:33:36PM +0000, Robert Raschke wrote: > Hi, > > has anyone encountered spurious overlong waits using receive ... after? That > is, the code says "after 1000 ->" but it's way longer than 1 second before > it gets there. > > My code starts a Java jinterface node, the Java code creates the node, > creates an mbox, and waits a minute for a message to appear and sends one > back. > > The Erlang code starts the Java as a port program, and starts sending ok > messages to the registered mbox of the Java program spaced 1 second apart. > My logging indicates that the sending of the messages is actually spaced > somewhere between 5 and 12 seconds apart! > > This is on a Windows 2003 Server running R12B-5. > > In Erlang (started with -sname "erl@REDACTED") this is roughly what's > happening (apologies for typos): > > run() -> > Node_Name = "foo@REDACTED", > Mbox = {box, list_to_atom(Node_Name)}, > Port_Pid = spawn_link(?MODULE, run_port_program, [Node_Name, > atom_to_list(erlang:get_cookie())]), > {ok, Java_Pid} = shake_hands(Mbox, 0). > > shake_hands(Mbox, N) when N < 50 -> > error_logger:info_report([{module, ?MODULE}, {handshake, N}, {mbox, > Mbox}]), > Mbox ! {self(), ok}, > receive > {ok, Pid} -> > {ok, Pid} > after 1000 -> > error_logger:error_report([{module, ?MODULE}, {'handshake timeout', > N}]), > shake_hands(Mbox, N+1) > end; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Seems likely that messages other than {ok, Pid} are coming in and growing the message queue. try adding a catchall to check ... > receive > {ok, Pid} -> > {ok, Pid} ; _Other -> io:fwrite("Catchall: ~p~n", [_Other]) > after 1000 -> then, presuming it's junk, you can just throw the spurious msgs out ~Michael > > Thanks, > Robby -- Michael McDaniel Portland, Oregon, USA http://trip.autosys.us http://putitgetit.com From kenji.rikitake@REDACTED Sat Feb 20 00:21:02 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sat, 20 Feb 2010 08:21:02 +0900 Subject: [erlang-questions] aes-128-cbc decryption in erlang In-Reply-To: References: Message-ID: <20100219232102.GA73961@k2r.org> The first value of IV must be given before the decryption starts. The man entry of "openssl enc" says the first IV will be given from the password. See the -iv option of OpenSSL. And the aes_cbc_ivec usage example is available in lib/ssh/src/ssh_transport.erl Regards, Kenji Rikitake In the message dated Fri, Feb 19, 2010 at 10:22:36PM +0600, Maxim Treskin writes: > What is erlang crypto analog of following comand? > > openssl enc -d -aes-128-cbc -pass env:KEY -in file.ssl -out file.txt > > There is function aes_cbc_128_decrypt which takes Key, IVec and > encoded data, but how I can get an IVec? > crypto:aes_cbc_ivec returns some IVec, but when it passed to > aes_cbc_128_decrypt I have wrong output of decoded data. May be I > doing something wrong? From vances@REDACTED Sat Feb 20 00:39:00 2010 From: vances@REDACTED (Vance Shipley) Date: Fri, 19 Feb 2010 18:39:00 -0500 Subject: [erlang-questions] aes-128-cbc decryption in erlang In-Reply-To: References: Message-ID: <20100219233900.GF1482@h216-235-12-174.host.egate.net> Maxim, For an example of it's use you could look at the milenage module from the 3Gdb HSS project: http://www.3gdb.org/doc/ http://code.google.com/p/hss/source/browse/trunk/src/milenage.erl -- -Vance On Fri, Feb 19, 2010 at 10:23:00PM +0600, Maxim Treskin wrote: } There is function aes_cbc_128_decrypt which takes Key, IVec and } encoded data, but how I can get an IVec? From tuncer.ayaz@REDACTED Sat Feb 20 00:49:10 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 20 Feb 2010 00:49:10 +0100 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266567436.4073.6.camel@humaira-laptop> <1266572041.4073.8.camel@humaira-laptop> Message-ID: <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> On Fri, Feb 19, 2010 at 11:17 AM, Chandru wrote: > Here it is. A correction to my previous statement - I think Sean Hinde > modified Tobbe's code to use gen_fsm instead. Tobbe's version including Sean's changes is available at http://github.com/etnt/eldap From kaykay.unique@REDACTED Sat Feb 20 05:18:44 2010 From: kaykay.unique@REDACTED (Kay Kay) Date: Fri, 19 Feb 2010 20:18:44 -0800 Subject: Information Theory encoding algorithms library in erlang Message-ID: <4B7F62A4.7070201@gmail.com> I am looking for some implementations of encoding algorithms ( huffmann etc. ) in erlang. Of course - using google / koders.com to figure out the bits and pieces , but curious to see if anybody has a repository / resource suggestion as a starting point for the same. I have the material that covers the appropriate theory but looking for specific implementations regarding the same. Thanks for the help. From leap@REDACTED Sat Feb 20 05:49:31 2010 From: leap@REDACTED (Michael Turner) Date: Sat, 20 Feb 2010 04:49:31 +0000 Subject: book ideas (was re making sense) In-Reply-To: <1266607508.3182.1360880645@webmail.messagingengine.com> Message-ID: On 2/19/2010, "Geoff Biggs" wrote: >8) A cookbook (I don't think any of the other options adequately covers >this). The recipes books that O'Reilly produces for several languages >are so immensely useful. I second that. There's a very useful level of conceptual granularity that's "coarser" than that of "idiom", but still neither concretely specific to an application domain nor quite as abstract as "software pattern". Cookbooks cover that ground. This book might be an easy one, since it's already mostly written, just scattered around in other work. Joe's idea of business case studies (#6), I'd love that. But it's hard to get sources unmuzzled. There might be a way to make it book-length anyway. It seems the main business case for Erlang/OTP is robust scalability. It's "insurance against becoming an overnight success," in a way. So wherever the Erlang-specific material is still a little thin, you could fill it out with cases where Erlang might have come in handy. If you look at some recent sudden successes on the Web, they were basically unintentional. - The ability of Myspace users to inject scripting onto their pages was unintended (it could even have been construed as a kind of security hole) but it really helped make Myspace take off, when users discovered it and started decorating their pages with animations. - Facebook was supposed to be a closed, elite, Ivy league club -- but it turned out everyone wanted to join that elite club. It was ingenious marketing by accident. - Twitter was limited to 140-character messages not by design but by SMS protocols -- and this turned out to be a feature, in a way, not a bug. "Brevity is the soul of wit" met another nostrum: "If you can't make something good, make something short." It made wit shine while diminishing dullness. You just can't know whether you have the Next Big Thing. Even if you do have it, you could fumble it, and somebody else might be hot on your heels, having burned through less capital than you did before you stumbled across your accidental (and all-too-easily-emulated) success. So write it in Erlang/OTP, just in case. -michael turner >On Fri, 19 Feb 2010 16:41 +0100, "Joe Armstrong" >wrote: >> I'd like to ask some pointed questions, the results will influene what >> happens >> next. >> >> Can anybody point me to a good free survey site - I want to ask questions >> and get a histogram of the replies. If we can first find out *what* you >> want >> we can then figure out *how* to achieve it. >> >> The first question is about books. I can think of the following titles: >> >> 1) Real beginner - lower level than the Prag or O'reilly books, >> chatty >> tone >> >> 2) Theory - a theory of concurrency oriented programming - why >> share-nothing agent programming is good. Design patterns. >> distributed algorithms. How does leadership election work, DHTs >> etc >> academic in tone. >> >> 3) How to books - take one subsystem and document all the nitty >> gritty stuff. >> Candidates >> >> - mnesia >> - yaws >> - ejabberd >> - asn1 >> - [you name it] >> >> 4) How to book, with emphasis on setup. Lots of details >> where to fetch, how to compile etc. >> >> (not generic - with sections for Ubuntu, OS-X and windows 7) >> >> one chapter/per topic >> >> - ejabberd >> - mochiweb >> - scalaris >> - nitrogen >> - [you name it] >> >> 6) Case studies (business) >> Not sure if this is even possible. >> I'm thinking the business case behind sucessfull Erlang >> companies. >> What they did and why (technical stuff) >> This is the book I'd want to read - but much is still >> commercially sensitive >> >> 7) case studies (technical) >> How was X built and why? Give the history. What worked, what >> failed. >> Basically interviews with the lead developers of each X >> >> For X in >> yaws >> ejabberd >> [you name it] >> >> 8) Other >> [you name it] >> >> Comments >> >> 4) and 7) seem to be the easiest to produce - just decide on the >> chapters >> (please suggest topics) and recruit one volunteer per chapter (no >> problem with domain experts here) and an editor and some reviewers. >> >> 3) is pretty difficult - very few people know everything about a >> particular >> sub-system - and even if they do might not want to spend thousands of >> hours documenting it - sales would be small anyway (I suspect) >> >> 1) and 2) are possible >> >> 7) might make a nice web site - need not be a book >> >> I'll put these question on a survey site, so people can vote, if somebody >> can suggest one - or can we do this on the main erlang site??? >> >> Cheers >> >> /Joe > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From leap@REDACTED Sat Feb 20 09:50:52 2010 From: leap@REDACTED (Michael Turner) Date: Sat, 20 Feb 2010 08:50:52 +0000 Subject: reserved word guaranteed to be atom if single-quoted? Message-ID: Recently somebody tripped over "query" as a reserved word in Erlang, and wondered what it was, and whether there were other reserved words that were similarly obscure. And I've been tinkering with a style of argument passing where one might write the_frob ({of, This_thing}, {within, That_other_thing}, ....) as a kind of poor man's syntactic sugar for the folks I'm writing my code for (who aren't programmers, much less Erlang programmers, just algorithm-specifiers). Of course, the Erlang parser complains about my "of". Experiment shows that single-quoting seems to work, e.g., Erlang accepts {'of', 'query'}. But it doesn't return quite what I'd expect from the shell. I get back {'of', 'query'} where I expected {of, query} although I think this because some output pretty-printing metarule is being applied here, like "output stuff in a way that's also acceptable for input, to the extent reasonable." Certainly atom_to_list('of') reports what I *did* expect from the Erlang shell: "of", i.e., without the single quotes. I'd like to submit a patch to the relevant part of the Data Types section of the User's Manual, which currently reads as follows: ---- An atom is a literal, a constant with name. An atom should be enclosed in single quotes (') if it does not begin with a lower-case letter or if it contains other characters than alphanumeric characters, underscore (_), or @. ---- That seems incomplete to me. I'd like to add, "or if it's an Erlang reserved word", with a link to the list of reserved words. It doesn't make sense to me that this single-quoting of reserved words would ever fail in some future version, but I thought I'd ask, just to be sure. -michael turner From kenneth.lundin@REDACTED Sat Feb 20 11:20:04 2010 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Sat, 20 Feb 2010 11:20:04 +0100 Subject: [erlang-questions] reserved word guaranteed to be atom if single-quoted? In-Reply-To: References: Message-ID: On Sat, Feb 20, 2010 at 9:50 AM, Michael Turner wrote: ... > I'd like to submit a patch to the relevant part of the Data Types > section of the User's Manual, which currently reads as follows: > > ---- > An atom is a literal, a constant with name. An atom should be enclosed in > single quotes (') if it does not begin with a lower-case letter or if > it contains other characters than alphanumeric characters, underscore > (_), or @. > ---- > > That seems incomplete to me. ?I'd like to add, "or if it's an Erlang > reserved word", with a link to the list of reserved words. ?It doesn't > make sense to me that this single-quoting of reserved words would ever > fail in some future version, but I thought I'd ask, just to be sure. > You are correct , if you want an atom with the same name as a reserved word you have to enclose it in single quotes. This will always work. > -michael turner > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > /Kenneth Erlang/OTP Ericsson From bgustavsson@REDACTED Sat Feb 20 11:39:27 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sat, 20 Feb 2010 11:39:27 +0100 Subject: Patch approval statistics for R13B04 Message-ID: <6672d0161002200239n40266c5ayd3b942e7c747a5d@mail.gmail.com> Now that R13B04 is feature-frozen, I can present some statistics about the patches we have received. In the git repository, there are commits from 32 persons from outside the Erlang/OTP group in the ccase/r13b04_dev branch (i.e. to be included in R13B04). Manually counting through the "What's cooking" emails sent to the erlang-patches mailing list, I got the following statistics: Number of patches included in R13B04: 51 Total number of dropped patches: 7 Stalled patches: 5 Of the dropped patches, 4 pointed out bugs and misfeatures that we chose to address in a different way. One dropped patch updated a deprecated module. Two patches were dropped because we found serious issues and the authors didn't submit revised patches. Note that of the 51 approved patches, several went through one more revisions by their authors to make them OTP worthy before we approved them. Statistics can never predict the future, but it seems that patches of good quality (OTP worthy) will have a good chance to be included in future OTP releases. Note that we never approve or reject unseen patches. An idea that seems good when explained in an email could turn out to have issues when run through our test suites, and conversely, an idea that seemed bad maybe seemed bad only because we didn't fully understand it. So instead of writing an email beforehand explaining what your patch will do, I suggest that you put the effort into a good commit message that contains a good description of the problem and/or use case, and a rationale to justify the way you chose to solve it. That information will speed up the reviewing process, and more importantly, it will help anyone 5 years from now to understand why the **** the change was made. Thanks to everyone that have sent us patches so far. I am looking forward to receiving many more good patches. -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kenji.rikitake@REDACTED Sat Feb 20 13:18:53 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sat, 20 Feb 2010 21:18:53 +0900 Subject: [erlang-questions] Patch approval statistics for R13B04 In-Reply-To: <6672d0161002200239n40266c5ayd3b942e7c747a5d@mail.gmail.com> References: <6672d0161002200239n40266c5ayd3b942e7c747a5d@mail.gmail.com> Message-ID: <20100220121853.GA85528@k2r.org> I appreciate Bjorn and all the Erlang/OTP Team members for their hard work to review the patches for R13B04, including those of FreeBSD port patch contributors. The whole process taught me the power of distributed source code management system and how it could be used wisely and productively. Kenji Rikitake From chandrashekhar.mullaparthi@REDACTED Sat Feb 20 14:01:30 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Sat, 20 Feb 2010 13:01:30 +0000 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266567436.4073.6.camel@humaira-laptop> <1266572041.4073.8.camel@humaira-laptop> <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> Message-ID: On 19 February 2010 23:49, Tuncer Ayaz wrote: > On Fri, Feb 19, 2010 at 11:17 AM, Chandru > wrote: >> Here it is. A correction to my previous statement - I think Sean Hinde >> modified Tobbe's code to use gen_fsm instead. > > Tobbe's version including Sean's changes is available at > http://github.com/etnt/eldap > I just checked, and it doesn't have the changes made by Sean. cheers Chandru From tuncer.ayaz@REDACTED Sat Feb 20 14:08:11 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 20 Feb 2010 14:08:11 +0100 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266567436.4073.6.camel@humaira-laptop> <1266572041.4073.8.camel@humaira-laptop> <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> Message-ID: <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> On Sat, Feb 20, 2010 at 2:01 PM, Chandru wrote: > On 19 February 2010 23:49, Tuncer Ayaz wrote: >> On Fri, Feb 19, 2010 at 11:17 AM, Chandru >> wrote: >>> Here it is. A correction to my previous statement - I think Sean Hinde >>> modified Tobbe's code to use gen_fsm instead. >> >> Tobbe's version including Sean's changes is available at >> http://github.com/etnt/eldap >> > > I just checked, and it doesn't have the changes made by Sean. http://github.com/etnt/eldap/raw/master/test/eldap_fsm.erl seemed to be what you were looking for. Interesting. From steven.charles.davis@REDACTED Sat Feb 20 14:44:49 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 20 Feb 2010 07:44:49 -0600 Subject: [erlang-questions] Re: What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> Message-ID: <4B7FE751.5080908@gmail.com> Hi Michael, I certainly respect your position, and as with many such discussions, I can only give my own experience. I do remember reasonably clearly being a newb. Actually, it wasn't that long ago (2008)! I remember starting by reading the Getting started section, and then going through the Erlang reference manual and programming examples. I also remember having to re-read a good deal of the OTP stuff before I truly "got it". When I started with C, many years ago, I managed to get by with two additional books. When I started with Java (even in the era of Java 1.1) I was forced to read about 20+ additional (and highly verbose) books beyond the documentation. When I started with Erlang, it found it sufficient to buy just one book (Joe's book) in addition to the docs - and the docs remain my primary reference. I am not saying there is no room for improvement in the docs; for example, finding something quickly can indeed be a pain (though frequently, it is not). When you do find what you need the manner in which it is written is almost always highly concise and accurate (though not always). The flaws in the docs currently are really more at the level of inconvenience than fatal flaws. It is certainly possible that I really have "lost touch", or that I'm just comparing the pain of Java-world to the relief of learning/using Erlang. But that's not my call to make. One enormous benefit of Erlang/OTP as a platform for me is that it covers so much (not all!) of the functional space requirements we face as application developers without any required reliance on third party software (and having to read/cope with all the documentation you need for those also). Best regards, Steve Michael Richter wrote: > > I respectfully disagree. I humbly submit further that you are not doing > what I suggested by looking at the existing docs with a newb's eyes. > From steven.charles.davis@REDACTED Sat Feb 20 14:56:55 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 20 Feb 2010 07:56:55 -0600 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> Message-ID: <4B7FEA27.1020008@gmail.com> Hi David, Most of the parameterized modules I have written have evolved in my code to become un-parameterized modules; either by evolving into standard functional modules where the additional arguments are passed in, or gen_servers where the state is maintained in the process. In these cases, my experience of having parameterized modules in my code has convinced me to remove them as the application codebase matured. The few remaining parameterized modules that I use also use the process dictionary in addition and so are side-effect monsters waiting to happen. I currently expect that these remaining parameterized modules will also disappear in due course into gen_server processes. As a result of this experience, my opinion on parameterized modules is that currently that I really shouldn't use them and that, in the end, my code is probably better off without them. Regards, Steve David Mercer wrote: > On February 18, Steve Davis wrote: >> I have found that the more I have used parameterized modules... the >> less I use parameterized modules. >> >> If you get what I'm saying. > > I do not. Can you please explain? Thank-you. > > David > > From tuncer.ayaz@REDACTED Sat Feb 20 15:37:08 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 20 Feb 2010 15:37:08 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> Message-ID: <4ac8254d1002200637y2b28cd5bi8bacf4875d89609d@mail.gmail.com> On Fri, Feb 19, 2010 at 4:08 PM, Max Lapshin wrote: > For example if some module is parameterized, you cannot access its > functions without calling new() If you really have to or want to do so you could "work around" that by calling the exported fun with a dummy 1st param. From tuncer.ayaz@REDACTED Sat Feb 20 16:14:56 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sat, 20 Feb 2010 16:14:56 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <4B7FEA27.1020008@gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> <4B7FEA27.1020008@gmail.com> Message-ID: <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> On Sat, Feb 20, 2010 at 2:56 PM, Steve Davis wrote: > Hi David, > > Most of the parameterized modules I have written have evolved in my code to > become un-parameterized modules; either by evolving into standard functional > modules where the additional arguments are passed in, or gen_servers where > the state is maintained in the process. In these cases, my experience of > having parameterized modules in my code has convinced me to remove them as > the application codebase matured. > > The few remaining parameterized modules that I use also use the process > dictionary in addition and so are side-effect monsters waiting to happen. I > currently expect that these remaining parameterized modules will also > disappear in due course into gen_server processes. > > As a result of this experience, my opinion on parameterized modules is that > currently that I really shouldn't use them and that, in the end, my code is > probably better off without them. Richard's paper http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf reveals the rationale behind param'ed modules. From g@REDACTED Sat Feb 20 18:19:14 2010 From: g@REDACTED (Garrett Smith) Date: Sat, 20 Feb 2010 11:19:14 -0600 Subject: [erlang-questions] Re: book ideas (was re making sense) In-Reply-To: References: <1266607508.3182.1360880645@webmail.messagingengine.com> Message-ID: On Fri, Feb 19, 2010 at 10:49 PM, Michael Turner wrote: > > > On 2/19/2010, "Geoff Biggs" wrote: > >>8) A cookbook (I don't think any of the other options adequately covers >>this). The recipes books that O'Reilly produces for several languages >>are so immensely useful. > > I second that. ?There's a very useful level of conceptual granularity > that's "coarser" than that of "idiom", but still neither concretely > specific to an application domain nor quite as abstract as "software > pattern". ?Cookbooks cover that ground. ?This book might be an easy > one, since it's already mostly written, just scattered around in other > work. I'd love to see a software architecture "patterns" book that uses OTP - as much as possible anyway - as the illustration/implementation layer. This would not be a "functional patterns" (in contract to OO), but rather these elements: - Concurrency with message passing - Process definition/scoping (e.g. server behaviors) - Supervision and fault tolerance - System composition and management in OTP (i.e. applications and releases) This is the stuff one needs to thoroughly understand to build a non-trivial system in Erlang. I've found it challenging to piece this information together with the available online resources, lists, books, etc. I'm not a huge UML guy, but UML does provide a basic vocabulary for thinking about and communicating various aspects of a software system. I probably ever only use < 5% of the stuff, but even with that, it's very helpful to used a shared modeling language. A patterns book like this would codify a simple notation for modeling/describing Erlang/OTP systems, which would be a big benefit, IMO. The payoff for such a book is that it'd highlight how and why Erlang/OTP is well suited for highly concurrent, fault tolerant systems. The case studies show that anecdotally, but a good patterns book would provide the all important sign posts to help developers realize the goodness. Garrett From zerthurd@REDACTED Sat Feb 20 18:33:58 2010 From: zerthurd@REDACTED (Maxim Treskin) Date: Sat, 20 Feb 2010 23:33:58 +0600 Subject: [erlang-questions] aes-128-cbc decryption in erlang In-Reply-To: <20100219233900.GF1482@h216-235-12-174.host.egate.net> References: <20100219233900.GF1482@h216-235-12-174.host.egate.net> Message-ID: Hello I wrote function which encodes/decodes arbitrary text using specified Key and IVec: aes_dec() -> Key = <<"ABCDEFGHIJKLMNOPQRSTUVWXYZ123456">>, IVec = <<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>>, Text = <<"gdfgertehgrfcnyeyuyrfghhhhhdtest">>, Enc = crypto:aes_cbc_128_encrypt(Key, IVec, Text), Res = crypto:aes_cbc_128_decrypt(Key, IVec, Enc), io:format("Res: ~s~n", [binary_to_list(Res)]). Result of function is: 1> cr_util:aes_dec(). ?QRSTUVWXYZ123456gdfgertehgrfcnyeyuyrfghhhhhdtest ok It is really unexpected for me. Can you help me? Thank you On 20 February 2010 05:39, Vance Shipley wrote: > Maxim, > > For an example of it's use you could look at the milenage > module from the 3Gdb HSS project: > > ? ? ? ?http://www.3gdb.org/doc/ > ? http://code.google.com/p/hss/source/browse/trunk/src/milenage.erl > > -- > ? ? ? ?-Vance > > On Fri, Feb 19, 2010 at 10:23:00PM +0600, Maxim Treskin wrote: > } ?There is function aes_cbc_128_decrypt which takes Key, IVec and > } ?encoded data, but how I can get an IVec? > -- Maxim Treskin From erlang@REDACTED Sat Feb 20 19:02:13 2010 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 20 Feb 2010 19:02:13 +0100 Subject: [erlang-questions] Re: What about making sense? In-Reply-To: <4B7FE751.5080908@gmail.com> References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> <4B7FE751.5080908@gmail.com> Message-ID: <9b08084c1002201002k1ffc01e9k676b01727588586b@mail.gmail.com> I've been thinking about documentation/books for years now. One thing that documentation and books does not capture is the order in which we write a program. A book with a code example presents the final result of a process. Not how we arrived at the result. When I write *any* process I always start with something like: loop(...) -> receive Any -> io:format("got:~p~n",[Any]), loop(...) end. it's always the same. I then run the program and see what messages arrive at the receive loop. I then add patterns that match the messages that arrive. As I develop the program I work in small steps - adding one message at a time and testing as I go. When I'm ready and the program is developed I might remove the "Any -> ..." bit. Seeing the final result give no clues as to the order in which things were done. Each micro step can have a deal of thinking behind it. Can this be described in words at all? - I doubt it. I really like Utube videos that explain how to do things in some domain. You can stop and replay them. A video with a detailed commentary seems then best way to do this. This is why teaching is better than reading a book - when I teach I live code and the students see each step. When you read this there should be no typos, but as I type it I make mistakes which I then correct, but you don't see this. The beginner sees the finished result - not the process - and can be frighted off by the thought that "I can't do this: the result is so perfect - I make loads of mistakes" - that's because they don't see the mistakes. When I wrote my Erlang book, Dave Thomas was my editor, he sent me long detailed comments. A single paragraph could elicit a food of response. His comments had spelling errors, seeing him make spelling errors elated me. I was overjoyed - the great Dave Thomas, best selling author, could make spelling errors, he was human like me. He said in some mail "we employ proof readers to fix stuff like this" - joy unbounded. Books - and printed documentation - no matter how good - cannot illustrate process - *the exact order in which I did things any why* - teaching is the ultimate answer. The students can see the order and *ask questions* (so we can change the order). Second best are videos - but you can't ask questions. Third are books. Fourth is documentation. Fifth is the code. I greatly sympathises with those who say "I can't understand documentation". Documentation is written for those who already understand - and is no a vehicle for understanding itself. "Read the code Luke" is even worse - even If I could understand the code (which can sometimes be *extremely* difficult) I have not idea at all what it is *supposed* to do only what it does. I consider this unprofessional. The work is not finished until the code is written, proved correct, documented, and the courses given and the knowledge passed on for future generations. This is beyond state-of-the-art (especially the proved correct bit) So If you *really* want to learn, try things in this order: 1) go on a course 2) watch a video 3) read a book 4) read the documentaion 5) read some code My kids go to school to learn stuff - I wouldn't just chuck a program listing at them and expect them to understand it. /Joe On Sat, Feb 20, 2010 at 2:44 PM, Steve Davis wrote: > Hi Michael, > > I certainly respect your position, and as with many such discussions, I can > only give my own experience. > > I do remember reasonably clearly being a newb. Actually, it wasn't that long > ago (2008)! I remember starting by reading the Getting started section, and > then going through the Erlang reference manual and programming examples. I > also remember having to re-read a good deal of the OTP stuff before I truly > "got it". > > When I started with C, many years ago, I managed to get by with two > additional books. When I started with Java (even in the era of Java 1.1) I > was forced to read about 20+ additional (and highly verbose) books beyond > the documentation. When I started with Erlang, it found it sufficient to buy > just one book (Joe's book) in addition to the docs - and the docs remain my > primary reference. > > I am not saying there is no room for improvement in the docs; for example, > finding something quickly can indeed be a pain (though frequently, it is > not). When you do find what you need the manner in which it is written is > almost always highly concise and accurate (though not always). The flaws in > the docs currently are really more at the level of inconvenience than fatal > flaws. > > It is certainly possible that I really have "lost touch", or that I'm just > comparing the pain of Java-world to the relief of learning/using Erlang. But > that's not my call to make. > > One enormous benefit of Erlang/OTP as a platform for me is that it covers so > much (not all!) of the functional space requirements we face as application > developers without any required reliance on third party software (and having > to read/cope with all the documentation you need for those also). > > Best regards, > Steve > > > Michael Richter wrote: >> >> I respectfully disagree. ?I humbly submit further that you are not doing >> what I suggested by looking at the existing docs with a newb's eyes. >> > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From clist@REDACTED Sat Feb 20 19:21:07 2010 From: clist@REDACTED (Angel) Date: Sat, 20 Feb 2010 19:21:07 +0100 Subject: [erlang-questions] What about making sense? In-Reply-To: <3hhIDDR1.1266563441.7439020.leap@gol.com> References: <3hhIDDR1.1266563441.7439020.leap@gol.com> Message-ID: <201002201921.07839.clist@uah.es> On Viernes, 19 de Febrero de 2010 08:10:41 Michael Turner escribi?: > Kenneth Lundin writes: > "As everything is organized as "applications" in the source code tree > and applications actually are groups of modules which are released and > upgraded together it makes perfect sense to structure the documentation > the same way." > > If in fact it makes perfect sense, why have so many smart people found it > so confusing? Admitely, it takes a few reads of the entire docs, to start making your mind around the applications concept, specially for newbies... In fact you spect to find some kind of runtime ala Java but you end noticeing that erlang has a sort of ecosystem where you have truly living creatures and not just libraries of clases and functions... IMHO you'll get the whole picture when you start seeing the erlang dist as a tiny OS on top of your OS. > > Calling a generic library an application makes no sense at all to me. > One *applies* library functions to practical problems, in the process of > building software, typically resulting in *programs* that are > applications. Erlang/OTP's use of "application" to mean all these > different things bears no relation to its use by the overwhelming > majority of software engineers. > > If you don't believe me, try testing your TOC out on real learners. > Give two different groups of programmers different TOCs, one perhaps as > I have suggested, the other as it currently exists. Ask them, "which > link would you click first, to try to find stdlib, the Erlang Standard > Library?" > > Is it so hard to predict the result? With yours, they won't click Basic > Applications, because stdlib is not an application in any ordinary sense > they know. Categorizing it as a Basic Application wont' make "perfect > sense" to them, in fact, will make no sense at all to them. > "Application" in the Erlang/OTP sense is something most experienced > programmers must learn, and be reminded of (especially since in OTP > it's usually something you can start and stop, but in other cases just > a regular Erlang library, and in yet other cases, not even that. And if > I'm to believe the much more experienced Jayson, "application" > actually has *even more* different meanings in Erlang/OTP.) > > Please don't pretend there's no difficulty here. Forthright > admissions, early and often, that Erlang uses "application" in a > highly unusual sense (*senses*, actually) would go a long way toward > helping mere mortals get used to it. Still when you begin mastering a bit the whole picture you find a enourmous gap between the management of and erlang applications and a classic OS application. Packaging and integration poses a real challenge when you leave the safe asumptions of the "embedded" smells erlang has. > > Saying there's no real problem sounds, well ... just what kind of > attitude is conveyed by a sentiment like "Words mean what we say they > mean, and if you couldn't easily find *where* we defined, precisely and > completely, what they mean, that's not our problem"? > > Would you want someone with that attitude working on documentation YOU > were trying to understand? Maybe there are funny people and like to scare poor newbies up to death! :-) > > -michael turner > > On 2/18/2010, "Kenneth Lundin" wrote: > >On Wed, Feb 17, 2010 at 4:52 PM, Michael Turner wrote: > >> On 2/17/2010, "Robert Virding" wrote: > >>>Without getting into the discussion how difficult, or not, it is to > >>>navigate the Erlang docs one source of the problem is that all the > >>>standard OTP libraries are proper Applications. > >> > >> People should think of the trigonometric functions as part of the STDLIB > >> Application, just because gen_server is grouped in with them, in stdlib? > >> > >> What sense does this make? > > > >I agree with you in that the documentation can be improved with better > >descriptions and more examples and guidelines. There is also need for > >good search facilities. We are working on both and we are releasing > >the complete documentation sources plus support to build the doc. The > >purpose with this is to make it possible for the community to help us > >improve the docs. > > > >I don't agree at all when you criticise the organization in : > >Toplevel System documentation plus all the "applications". > >Already on the introduction page at top-level (http://erlang.org/doc) it > > says "Erlang/OTP is divided into a number of OTP applications. An > >application normally contains Erlang modules. Some OTP applications, > >such as the C interface erl_interface, are written in other languages > >and have no Erlang modules. " > > > >As everything is organized as "applications" in the source code tree > >and applications actually are > >groups of modules which are released and upgraded together it makes > >perfect sense to structure the > >documentation the same way. > > > >An application can be a service that can be started and stopped or it > >can be a library of passive modules with functions it does not matter. > >The important thing is that an application is the smallest unit we > >handle when it comes to deliverables. We always provide a complete new > >version of a full application including documentation when we release > >binary patches. > >The documentation is treated the same way as code and is released > >together with the code to assure > >that you always have the documentation corresponding to the code. > > > >Our experience is that this is a very efficient way to handle > >documentation. We have no intention to change this. The documentation > >can and will be improved anyway. > > > >STDLIB and Kernel are unfortunately 2 basic (core) applications with a > >very mixed content. > >The criterias for what's in Kernel and what's in STDLIB are unclear , > >we have discussed to > >reorganize them some day but it has not been important enough to do > >it. It will also introduce > >potential incompatibilities. > > > >Regarding the name "application" I think it is somewhat unfortunate > >since everyone has an own idea > >about what an application is in general. For example in Ericsson an > >"application" is a complete product sold to end users. In Erlang it is > >a group of modules handled together, possibly started as a service. I > >think you have to blame Joe for naming it "application". > > > >>> So when when the > >>>documentation is organised around "applications", in one sense, it is > >>>being entirely logical and consistent. Of course, until you are more > >>>experienced and groked this it can be very confusing and difficult to > >>>find things. > >> > >> But in the meantime, conceptual/terminological confusion impedes the > >> learner, whenever he/she needs to resort to the Reference Manual. ?Given > >> that Erlang already poses quite a learning curve for some, this will > >> reduce the rate at which people become "more experienced and grok > >> this", and for that matter, it will reduce the number of people who > >> even want to get that far with Erlang. > > > >I don't really understand what you mean are the > >conceptual/terminological confusions except maybe > >application. > > > >> What sense does this make? > >> > >> What goal does this serve? > >> > >> The goal of making it easier to autogenerate the documentation? > > > >I don't understand what you mean here. Most of the documentation 95% > >is handwritten. > >We strongly believe in single source and many generated presentations > >but this has no negative > >impact on the actual documentation. > > > >> Well, I remember the days when we humans did a lot of things to make > >> life easier for the system. ?As I recall, it involved punching a lot of > >> cards. > >> > >> > >> -michael turner > > > >/Kenneth, Erlang/OTP Ericsson > > > >> ________________________________________________________________ > >> erlang-questions (at) erlang.org mailing list. > >> See http://www.erlang.org/faq.html > >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > Most people know C is not so high level.... ...Everybody else just got assembler overdose From steven.charles.davis@REDACTED Sat Feb 20 23:32:07 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 20 Feb 2010 14:32:07 -0800 (PST) Subject: Will parameterized modules become an official part of Erlang? In-Reply-To: <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> Message-ID: <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> Hi Tuncer, Yep, I have read that paper. I think that was where I first learned how to use parameterized modules. I'm just saying that in practice, I am personally using them less and less. regs, /s On Feb 20, 9:14?am, Tuncer Ayaz wrote: > On Sat, Feb 20, 2010 at 2:56 PM, Steve Davis > > > > > > wrote: > > Hi David, > > > Most of the parameterized modules I have written have evolved in my code to > > become un-parameterized modules; either by evolving into standard functional > > modules where the additional arguments are passed in, or gen_servers where > > the state is maintained in the process. In these cases, my experience of > > having parameterized modules in my code has convinced me to remove them as > > the application codebase matured. > > > The few remaining parameterized modules that I use also use the process > > dictionary in addition and so are side-effect monsters waiting to happen. I > > currently expect that these remaining parameterized modules will also > > disappear in due course into gen_server processes. > > > As a result of this experience, my opinion on parameterized modules is that > > currently that I really shouldn't use them and that, in the end, my code is > > probably better off without them. > > Richard's paperhttp://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf > reveals the rationale behind param'ed modules. > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > Seehttp://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED From tuncer.ayaz@REDACTED Sun Feb 21 02:38:46 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 21 Feb 2010 02:38:46 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> Message-ID: <4ac8254d1002201738s260cecdcoebd794b26d84229f@mail.gmail.com> On Sat, Feb 20, 2010 at 11:32 PM, Steve Davis wrote: > Hi Tuncer, > > Yep, I have read that paper. I think that was where I first learned > how to use parameterized modules. > > I'm just saying that in practice, I am personally using them less and > less. I do think that experimental implies that a feature and its current implementation are being tested and may be replaced or removed. Parameterized modules, -extends and package support are IIRC all experimental and it's good because it gives us a way to avoid accidentally introducing features that look good on paper and not being able to change/remove them later on. So having a discussion about parameterized modules is a good thing. If it wasn't for great features like bit syntax and bit string/list comprehension I would be tempted to say "less syntax with more power instead of more syntax with less power in each". > On Feb 20, 9:14?am, Tuncer Ayaz wrote: >> On Sat, Feb 20, 2010 at 2:56 PM, Steve Davis >> >> >> >> >> >> wrote: >> > Hi David, >> >> > Most of the parameterized modules I have written have evolved in my code to >> > become un-parameterized modules; either by evolving into standard functional >> > modules where the additional arguments are passed in, or gen_servers where >> > the state is maintained in the process. In these cases, my experience of >> > having parameterized modules in my code has convinced me to remove them as >> > the application codebase matured. >> >> > The few remaining parameterized modules that I use also use the process >> > dictionary in addition and so are side-effect monsters waiting to happen. I >> > currently expect that these remaining parameterized modules will also >> > disappear in due course into gen_server processes. >> >> > As a result of this experience, my opinion on parameterized modules is that >> > currently that I really shouldn't use them and that, in the end, my code is >> > probably better off without them. >> >> Richard's paperhttp://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf >> reveals the rationale behind param'ed modules. >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> Seehttp://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From kenji.rikitake@REDACTED Sun Feb 21 04:46:02 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 21 Feb 2010 12:46:02 +0900 Subject: [erlang-questions] aes-128-cbc decryption in erlang In-Reply-To: References: <20100219233900.GF1482@h216-235-12-174.host.egate.net> Message-ID: <20100221034602.GA96536@k2r.org> For aes_cbc_128_*/3 functions, The length of Key must be 128 bits. The Key below has 32 bytes aka 256 bits. Kenji Rikitake In the message dated Sat, Feb 20, 2010 at 11:33:34PM +0600, Maxim Treskin writes: > aes_dec() -> > Key = <<"ABCDEFGHIJKLMNOPQRSTUVWXYZ123456">>, > IVec = <<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>>, > Text = <<"gdfgertehgrfcnyeyuyrfghhhhhdtest">>, > Enc = crypto:aes_cbc_128_encrypt(Key, IVec, Text), > Res = crypto:aes_cbc_128_decrypt(Key, IVec, Enc), > io:format("Res: ~s~n", [binary_to_list(Res)]). From bflatmaj7th@REDACTED Sun Feb 21 05:11:12 2010 From: bflatmaj7th@REDACTED (Richard Andrews) Date: Sun, 21 Feb 2010 15:11:12 +1100 Subject: [erlang-questions] aes-128-cbc decryption in erlang In-Reply-To: References: <20100219233900.GF1482@h216-235-12-174.host.egate.net> Message-ID: <7702c0611002202011r27995f74s90e48cf3568c0766@mail.gmail.com> On Sun, Feb 21, 2010 at 4:33 AM, Maxim Treskin wrote: > aes_dec() -> > ? ?Key = <<"ABCDEFGHIJKLMNOPQRSTUVWXYZ123456">>, > ? ?IVec = <<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0>>, > ? ?Text = <<"gdfgertehgrfcnyeyuyrfghhhhhdtest">>, > ? ?Enc = crypto:aes_cbc_128_encrypt(Key, IVec, Text), > ? ?Res = crypto:aes_cbc_128_decrypt(Key, IVec, Enc), > ? ?io:format("Res: ~s~n", [binary_to_list(Res)]). ... > 1> cr_util:aes_dec(). > ?QRSTUVWXYZ123456gdfgertehgrfcnyeyuyrfghhhhhdtest > ok > > It is really unexpected for me. Can you help me? Maybe for a 128-bit cipher you should use a 128-bit key. From kagato@REDACTED Sun Feb 21 06:27:46 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Sat, 20 Feb 2010 21:27:46 -0800 Subject: Comments in Config Files (i.e. file:consult/1) Message-ID: I use file:consult/1 to load in some configuration. It seems that, as far as I can tell, that it handles comments (using %) just fine. However, I don't see this in the docs anywhere. Is this intended behavior? Is it guaranteed not to change? Should I add it to the docs? Thanks, -- Jayson Vantuyl kagato@REDACTED From jay@REDACTED Sun Feb 21 05:35:51 2010 From: jay@REDACTED (Jay Nelson) Date: Sat, 20 Feb 2010 20:35:51 -0800 Subject: Patch approval statistics for R13B04 Message-ID: <06C755BB-CED1-4D67-944F-1EAA3CDB5952@duomark.com> I second the commendations for Bjorn and the rest of the OTP team. I think it is a great step forward for erlang to be open and easily accessible by developers around the world. I expect a lot of the people who have managed thus far with patched versions of releases will be able to contribute their patches to the benefit of the community and simplify their own support in the process. jay From vlm@REDACTED Sun Feb 21 07:02:36 2010 From: vlm@REDACTED (Lev Walkin) Date: Sat, 20 Feb 2010 22:02:36 -0800 Subject: github:jacknyfe/mcd: a client to memcached Message-ID: <30B00EC1-691D-46AC-AFB9-01A8C0B4DD5D@lionet.info> Jumping on the bandwagon of Erlang memcached clients (there are a few already), here's our contribution: http://github.com/jacknyfe/mcd This is a client to a text-based memcached protocol, written in Erlang (does not require a linked-in drivers and such). -- vlm From leap@REDACTED Sun Feb 21 10:03:34 2010 From: leap@REDACTED (Michael Turner) Date: Sun, 21 Feb 2010 09:03:34 +0000 Subject: book ideas In-Reply-To: Message-ID: Not to get More Meta Than Thou, but Garrett's point here about the usefulness of a Patterns-directed treatment of Erlang has a useful generalization: most people are coming to Erlang *from somewhere*, and it's inefficient to not consider their world of origin when explaining where they've arrived with Erlang. Software patterns were largely motivated by the desire for a common vocabulary for talking about recurring practices in coding and structuring programs. Because software patterns aren't language-specific, and are now much better known than a decade ago, you could use them to structure an "aerial view" tour of Erlang/OTP and realistically hope to gain a fairly wide audience. More concretely, someone could write, say, Erlang for the Java Programmer. The narrative might largely recapitulate the typical tutorial presentation order for Java, while developing an understanding of Erlang in terms of similarities and differences between the two languages, their standard libraries and tools, and the architectural choices typically made in writing programs. There's also room, I believe, for a bits&bytes/nuts&bolts bottom-up treatment. Because of how my brain works (or perhaps because of how it doesn't), I often need things to be very concrete. When I was first learning C++, for example, I found myself deeply suspicious of most explanations of member function calls (AKA "method dispatch" in some other OO languages). It wasn't until I could read a member function invocation as a C expression evaluating to a function reference that I felt I truly understood. (Reading Cfront output was helpful in this.) I could compare C++'s way with how I'd "faked" OO myself in other contexts, pre-C++, and to how Smalltalk did method dispatch, which I understood pretty well from studying its VM. The audience for some slim volume about The Architecture of the Erlang VM might be relatively small, but nevertheless influential all out of proportion to its numbers. -michael turner On 2/20/2010, "Garrett Smith" wrote: >On Fri, Feb 19, 2010 at 10:49 PM, Michael Turner wrote: >> >> >> On 2/19/2010, "Geoff Biggs" wrote: >> >>>8) A cookbook (I don't think any of the other options adequately covers >>>this). The recipes books that O'Reilly produces for several languages >>>are so immensely useful. >> >> I second that. ?There's a very useful level of conceptual granularity >> that's "coarser" than that of "idiom", but still neither concretely >> specific to an application domain nor quite as abstract as "software >> pattern". ?Cookbooks cover that ground. ?This book might be an easy >> one, since it's already mostly written, just scattered around in other >> work. > >I'd love to see a software architecture "patterns" book that uses OTP >- as much as possible anyway - as the illustration/implementation >layer. This would not be a "functional patterns" (in contract to OO), >but rather these elements: > >- Concurrency with message passing >- Process definition/scoping (e.g. server behaviors) >- Supervision and fault tolerance >- System composition and management in OTP (i.e. applications and releases) > >This is the stuff one needs to thoroughly understand to build a >non-trivial system in Erlang. I've found it challenging to piece this >information together with the available online resources, lists, >books, etc. > >I'm not a huge UML guy, but UML does provide a basic vocabulary for >thinking about and communicating various aspects of a software system. >I probably ever only use < 5% of the stuff, but even with that, it's >very helpful to used a shared modeling language. A patterns book like >this would codify a simple notation for modeling/describing Erlang/OTP >systems, which would be a big benefit, IMO. > >The payoff for such a book is that it'd highlight how and why >Erlang/OTP is well suited for highly concurrent, fault tolerant >systems. The case studies show that anecdotally, but a good patterns >book would provide the all important sign posts to help developers >realize the goodness. > >Garrett > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From roberto@REDACTED Sun Feb 21 11:11:58 2010 From: roberto@REDACTED (Roberto Ostinelli) Date: Sun, 21 Feb 2010 11:11:58 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> Message-ID: 2010/2/20 Steve Davis Hi Tuncer, Yep, I have read that paper. I think that was where I first learned how to use parameterized modules. I'm just saying that in practice, I am personally using them less and less. regs, /s my $0.02: i find parametrized modules particularly useful in callbacks functions exposed to external programmers. using them, you can pass something pretty close to an object, with its values and methods, reducing the need for these programmers to know the deep magic of your library. all about code usability, and personal taste, i guess. r. From zubairq@REDACTED Sun Feb 21 12:12:55 2010 From: zubairq@REDACTED (Zubair Quraishi) Date: Sun, 21 Feb 2010 12:12:55 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> Message-ID: <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> What I originally wanted to know though is whether there is a chnace they will be "removed" from the language, as I'm only going to use features that are here to stay. On Sun, Feb 21, 2010 at 11:11 AM, Roberto Ostinelli wrote: > 2010/2/20 Steve Davis > > Hi Tuncer, > > Yep, I have read that paper. I think that was where I first learned > how to use parameterized modules. > > I'm just saying that in practice, I am personally using them less and > less. > > regs, > /s > > my $0.02: > > i find parametrized modules particularly useful in callbacks functions > exposed to external programmers. using them, you can pass something pretty > close to an object, with its values and methods, reducing the need for > these > programmers to know the deep magic of your library. > > all about code usability, and personal taste, i guess. > > r. > From rapsey@REDACTED Sun Feb 21 12:25:31 2010 From: rapsey@REDACTED (Rapsey) Date: Sun, 21 Feb 2010 12:25:31 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> Message-ID: <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> Not a large chance of that. It's used in a number of libraries including OTP internally. Sergej On Sun, Feb 21, 2010 at 12:12 PM, Zubair Quraishi wrote: > What I originally wanted to know though is whether there is a chnace they > will be "removed" from the language, as I'm only going to use features that > are here to stay. > > On Sun, Feb 21, 2010 at 11:11 AM, Roberto Ostinelli >wrote: > > > 2010/2/20 Steve Davis > > > > Hi Tuncer, > > > > Yep, I have read that paper. I think that was where I first learned > > how to use parameterized modules. > > > > I'm just saying that in practice, I am personally using them less and > > less. > > > > regs, > > /s > > > > my $0.02: > > > > i find parametrized modules particularly useful in callbacks functions > > exposed to external programmers. using them, you can pass something > pretty > > close to an object, with its values and methods, reducing the need for > > these > > programmers to know the deep magic of your library. > > > > all about code usability, and personal taste, i guess. > > > > r. > > > From zubairq@REDACTED Sun Feb 21 12:48:55 2010 From: zubairq@REDACTED (Zubair Quraishi) Date: Sun, 21 Feb 2010 12:48:55 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> Message-ID: <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> I disagree because the fact that parameterised modules are used only "internally" in OTP tells me that they "could" be removed. I say this because removing parameterised modules would not break any client libraries for OTP, as the internals of OTP could just be changed. Is there anyone from Ericcson who could shed light on this, or is it simply a "risk" to use parameterised modules? On Sun, Feb 21, 2010 at 12:25 PM, Rapsey wrote: > Not a large chance of that. It's used in a number of libraries including > OTP > internally. > > > Sergej > > On Sun, Feb 21, 2010 at 12:12 PM, Zubair Quraishi > wrote: > > > What I originally wanted to know though is whether there is a chnace they > > will be "removed" from the language, as I'm only going to use features > that > > are here to stay. > > > > On Sun, Feb 21, 2010 at 11:11 AM, Roberto Ostinelli > >wrote: > > > > > 2010/2/20 Steve Davis > > > > > > Hi Tuncer, > > > > > > Yep, I have read that paper. I think that was where I first learned > > > how to use parameterized modules. > > > > > > I'm just saying that in practice, I am personally using them less > and > > > less. > > > > > > regs, > > > /s > > > > > > my $0.02: > > > > > > i find parametrized modules particularly useful in callbacks functions > > > exposed to external programmers. using them, you can pass something > > pretty > > > close to an object, with its values and methods, reducing the need for > > > these > > > programmers to know the deep magic of your library. > > > > > > all about code usability, and personal taste, i guess. > > > > > > r. > > > > > > From leap@REDACTED Sun Feb 21 14:20:39 2010 From: leap@REDACTED (Michael Turner) Date: Sun, 21 Feb 2010 13:20:39 +0000 Subject: A sender() BIF? Message-ID: <4JyGEm7n.1266758439.0683540.leap@gol.com> It's conventional for certain purposes to make the first term of a message tuple be the sender, where the receiver needs to know. Recently, I started wondering: why isn't the appropriate sender already available within each receive scope, via a BIF (or even via some special variable)? I haven't found any BIF like this, so far. Nor do I see any way to write it as an Erlang function or macro, though I'm guessing this might be possible. Does the idea of sender() violate encapsulation in some meaningful way? As matters stand, a module just has to take it on faith that a Pid identified as sender in a message actually *is* the sender. So, if anything, the current arrangement seems to be a source not only of code verbosity, but (admittedly minor) risk of error as well. -michael turner From dizzyd@REDACTED Sun Feb 21 14:46:38 2010 From: dizzyd@REDACTED (Dave Smith) Date: Sun, 21 Feb 2010 06:46:38 -0700 Subject: [erlang-questions] A sender() BIF? In-Reply-To: <4JyGEm7n.1266758439.0683540.leap@gol.com> References: <4JyGEm7n.1266758439.0683540.leap@gol.com> Message-ID: I don't believe the VM tracks the origin of messages, so adding this BIF would likely necessitate a bunch of changes within the VM to do the proper accounting. What's more, the distributed Erlang subsystem (and protocol) would (probably) need to be changed to support this implicit parameter. I'm not sure how one would would deal with older instances of VMs that aren't including the sender; the BIF would probably need to be able to support 'undefined' return value, which means your code also has to do checking...blech. Given that we have to copy the contents of a message when we send it, including an additional parameter such as the sender on every message seems (to me) a bit inefficient -- esp since there are plenty of situations where you don't care about the sender. The current setup of using convention to include the sender is simpler, more efficient and backwards compatible. Furthermore, even if the VM included the sender, you could only trust that for messages from within the local node. I.e. any distributed erlang node could fake the sender, so if you're interested in this for security/robustness reasons, it would only be useful within a local VM. My $0.02. D. On Sun, Feb 21, 2010 at 6:20 AM, Michael Turner wrote: > > It's conventional for certain purposes to make the first term of a > message tuple be the sender, where the receiver needs to know. > Recently, I started wondering: why isn't the appropriate sender already > available within each receive scope, via a BIF (or even via some special > variable)? > > I haven't found any BIF like this, so far. ?Nor do I see any way to > write it as an Erlang function or macro, though I'm guessing this might > be possible. > > Does the idea of sender() violate encapsulation in some meaningful way? > As matters stand, a module just has to take it on faith that a Pid > identified as sender in a message actually *is* the sender. ?So, if > anything, the current arrangement seems to be a source not only of code > verbosity, but (admittedly minor) risk of error as well. > > -michael turner > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From erlang@REDACTED Sun Feb 21 16:21:10 2010 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 21 Feb 2010 16:21:10 +0100 Subject: [erlang-questions] Information Theory encoding algorithms library in erlang In-Reply-To: <4B7F62A4.7070201@gmail.com> References: <4B7F62A4.7070201@gmail.com> Message-ID: <9b08084c1002210721x25735dbbk924070dccd0495d3@mail.gmail.com> I'm not aware of a single collection of several such algorithms though I have seen huffman etc in Erlang. Huffman was used in some paper to illustrate use of Erlang bit fields. I implemented gamma encoding at: http://github.com/joearms/elib1/blob/master/lib/src/elib1_gamma.erl This was taken straight out of Witten, Moffat and Bells's book "Managing Gigabytes" - this book is BTW - an excellent source for compression algorithms. It would be nice to implement all the compression algorithms in MG and put them into a single library. Erlang bit field matching makes this kind of code pretty simple - it would be very nice to see reference implementations in Erlang (and of error correction codes, fountain codes anyone :-) Cheers /Joe On Sat, Feb 20, 2010 at 5:18 AM, Kay Kay wrote: > I am looking for some implementations of encoding algorithms ( huffmann etc. > ) in erlang. Of course - using google / koders.com to figure out the bits > and pieces , but curious to see if anybody has a repository / resource > suggestion as a starting point for the same. I have the material that covers > the appropriate theory but looking for specific implementations regarding > the same. ?Thanks for the help. > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ulf.wiger@REDACTED Sun Feb 21 18:18:26 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sun, 21 Feb 2010 18:18:26 +0100 Subject: [erlang-questions] Comments in Config Files (i.e. file:consult/1) In-Reply-To: References: Message-ID: <4B816AE2.3010404@erlang-solutions.com> Jayson Vantuyl wrote: > I use file:consult/1 to load in some configuration. It seems that, > as far as I can tell, that it handles comments (using %) just fine. > However, I don't see this in the docs anywhere. Is this intended > behavior? Is it guaranteed not to change? Should I add it to the > docs? It is sort of implied... All functions that operate on text and convert to erlang terms (the shell, io:read, file:consult, file:eval, file:script, etc.) all rely on the erlang tokenizer and parser, which handle whitespace and comments. It would be a lot of extra work, and highly undesireable, to introduce a term parser that does /not/ handle comments, and from experience I know that some large projects mandate comments (such as e.g. copyright blurbs) in input files for file:consult. So don't worry about it changing in the future, and I agree that the documentation could be a bit less terse on this subject. :) BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From gordon@REDACTED Sun Feb 21 18:28:55 2010 From: gordon@REDACTED (Gordon Guthrie) Date: Sun, 21 Feb 2010 17:28:55 +0000 Subject: [erlang-questions] Comments in Config Files (i.e. file:consult/1) In-Reply-To: <4B816AE2.3010404@erlang-solutions.com> References: <4B816AE2.3010404@erlang-solutions.com> Message-ID: Jason wrote: >> I use file:consult/1 to load in some configuration. Don't forget to add the magic line at the start of your config files: %%-*-erlang-*- which means that when you open them in emacs erlang-mode kicks in and they indent/colourise correctly :) Gordon On 21 February 2010 17:18, Ulf Wiger wrote: > Jayson Vantuyl wrote: >> >> I use file:consult/1 to load in some configuration. ?It seems that, >> as far as I can tell, that it handles comments (using %) just fine. >> However, I don't see this in the docs anywhere. ?Is this intended >> behavior? ?Is it guaranteed not to change? ?Should I add it to the >> docs? > > It is sort of implied... All functions that operate on text > and convert to erlang terms (the shell, io:read, file:consult, > file:eval, file:script, etc.) all rely on the erlang tokenizer > and parser, which handle whitespace and comments. > > It would be a lot of extra work, and highly undesireable, to > introduce a term parser that does /not/ handle comments, and > from experience I know that some large projects mandate comments > (such as e.g. copyright blurbs) in input files for file:consult. > > So don't worry about it changing in the future, and I agree that > the documentation could be a bit less terse on this subject. :) > > BR, > Ulf W > -- > Ulf Wiger > CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd > http://www.erlang-solutions.com > --------------------------------------------------- > > --------------------------------------------------- > > WE'VE CHANGED NAMES! > > Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG > SOLUTIONS LTD. > > www.erlang-solutions.com > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ok@REDACTED Sun Feb 21 23:04:33 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 22 Feb 2010 11:04:33 +1300 Subject: Coverity, ClearMake, Erlang VM In-Reply-To: References: Message-ID: On Feb 19, 2010, at 8:16 PM, Michael Turner wrote: > > > On 2/18/2010, "Richard O'Keefe" wrote: > >> >> On Feb 19, 2010, at 3:08 AM, Björn Gustavsson wrote: >>> That's it because we have always used Clearcase and Clearmake, >>> that handle most dependencies automatically. We will starting >>> working on updating the Makefiles to have the necessary >>> dependencies. (Patches accepted.) >> >> That reminds me of the article from Coverity in CACM. > > With the important difference that the CACM article mentioned people > who > thought that ClearCase Make was how all makes work; obviously, > Erlang/OTP people know better. If anyone thought I was in any way slighting or criticising the Erlang/OTP team there, please accept my apologies. All I actually meant was "at this moment, ANY mention of Clearmake, no matter what, reminds me of the Coverity article, just due to the co-occurrence of the name. Having been reminded of Coverity, and the fact that the US government supported the processing of millions of lines of open source code by Coverity, ..." From vances@REDACTED Sun Feb 21 23:13:52 2010 From: vances@REDACTED (Vance Shipley) Date: Sun, 21 Feb 2010 17:13:52 -0500 Subject: [erlang-questions] net_kernel:handle_call In-Reply-To: <01489E237C2C8F45AF7898E135F48E8001DA64D18E@NYWEXMBX2129.msad.ms.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64D146@NYWEXMBX2129.msad.ms.com> <6a3ae47e1002190807i6ffffc52x50f34aaa3e3947c2@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64D18E@NYWEXMBX2129.msad.ms.com> Message-ID: <20100221221347.GA85605@h216-235-12-174.host.egate.net> On Fri, Feb 19, 2010 at 11:23:08AM -0500, Musumeci, Antonio S wrote: } While not directly comparable... in other languages when you ask } for an invalid service (method, function, etc) the caller not the } called errors. The proper thing to do when a server receives an incorrect call depends on the relationship between the server and the client. The Erlang way of handling programming errors is to fail immediately and leave a stack trace pointing directly at the problem so that someone can fix the code. So if your client and server are two parts of a single program you would want to have no clause to handle an unknown call. On the other hand if the server repesents a service access point and the client is a user of that service from another program you would want to guard against it's errors. I use the following: %% @spec (SAP, Request) -> ok %% SAP = Name | {Name,Node} | {global,GlobalName} | pid() %% Node = atom() %% GlobalName = term() %% Request = term() %% %% @doc Public API function for a service request. %% call(SAP, Request) -> case gen_server:call(SAP, Request) of {ok, Result} -> Result; {error, Reason} -> exit(Reason) end. %% @spec (Request, From, State) -> Result %% Request = term() %% From = {pid(), Tag} %% State = term() %% @doc Private callback to handle a request sent with call/2. %% handle_call(Request, _, State) -> ... {reply, {ok, Result}, State}; handle_call(Other, _, State) -> {reply, {error, badarg}, State}. I have in the past used something like this: handle_call(Other, {Pid, _Tag}, State) -> exit(Pid, badarg), {noreply, State}. ... however I've come to find the former more appropriate. -- -Vance From ok@REDACTED Sun Feb 21 23:32:53 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 22 Feb 2010 11:32:53 +1300 Subject: [erlang-questions] What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> Message-ID: On Feb 19, 2010, at 9:30 PM, Michael Richter wrote: [much that I agree with] Let me say that I love Erlang and greatly respect those who have developed it, and that I have met with nothing but kindness. As I haven't paid a single farthing for the Erlang documentation, I should start by saying that as reference material, it works well. But the only way I ever discovered stdlib was by expanding every item in the navbar until I found it. And that's despite knowing that the bundle in question was called 'stdlib'. I have found the hardcopy manuals a great resource because my approach to any book-like material is to try to read it cover to cover. There's a very different problem for someone trying to read online stuff, and it's basically an information retrieval problem. Here's an example. I just stumbled across the 'slave' module. If I had been looking for it I would not have looked for 'slave'; I would have been looking for "create remote node". Here's another aspect. For some reason the click-on-a-lot-of- nested-folder-icons interface seems to have crossed from Windows into the real world (:-). But a rigid hierarchical tree is NOT a good model for documentation. For example, if I want to read about "database applications", I really really want ETS, DETS, ms_transform, and a bunch of other things to be visible at the same time, not just odbc and mnesia. A hierarchical structure is legitimate for printed material, where you don't want a lot of duplication. But in a hypertext system, it's much less useful. Reverting to 'slave', the description for the 'slave' module never actually defines what a slave node IS. We learn that - a slave node dies when the master dies - a slave node needs to have the same Erlang distribution in the same place as the master but what OTHER differences are there between slave nodes and other nodes. For example, if I have two nodes A and B in a cluster and node B creates a slave C, can A talk directly to C? When is it better to create a node as a slave than otherwise? When is it worse? This is what I have against the JavaDoc way, now faithfully copied by Erlang programmers who wouldn't dream of copying Java. It strongly encourages a focus on *part* of the documentation. A useful part, but *only* part. In fact, precisely the part that you might be able to figure out for yourself by reading the code. A good guideline for anyone working on Erlang documentation, whether in the core Erlang/OTP team or elsewhere, is to constantly ask the question "what do programmers need to know about using this module that they WOULDN'T be able to find out by reading the code." The documentation for ms_transform, which I also stumbled over by accident one day, is actually pretty good that way. It tells you what it's _for_, why it's useful, with examples of how to use it. From bile@REDACTED Sun Feb 21 23:43:02 2010 From: bile@REDACTED (bile@REDACTED) Date: Sun, 21 Feb 2010 17:43:02 -0500 Subject: [erlang-questions] net_kernel:handle_call In-Reply-To: <20100221221347.GA85605@h216-235-12-174.host.egate.net> References: <01489E237C2C8F45AF7898E135F48E8001DA64D146@NYWEXMBX2129.msad.ms.com> <6a3ae47e1002190807i6ffffc52x50f34aaa3e3947c2@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64D18E@NYWEXMBX2129.msad.ms.com> <20100221221347.GA85605@h216-235-12-174.host.egate.net> Message-ID: <20100221174302.26e5c0b9@landofbile.com> Your example is fine... but doesn't represent what is happening here. Your code would cause the client to error... net_kernel, the server, is dying in this case. We are talking about a major component of the system which will bring down the entire system if you happen to send it a message it doesn't understand. Kernel_sup is setup to die should any of it's children die and that brings down BEAM. rex is in the same pool of services yet it just ignores the messages and refuses to reply. As do others. Behaviors are inconsistent and in some cases contradictory. Like rex having a public stop function that due to being configured in kernel_sup as permanent leads to the entire system going down should you stop it. And this for an ultimately optional component. Don't reply or reply with an error, crash or ignore. They have different strengths and weaknesses... but pick a paradigm and use it consistency. Generally you want general components to be flexible and stable. Currently some of these base services are neither. I've submitted some patches to clean up a few of these inconsistencies but I've yet to hear any comments on them. On Sun, 21 Feb 2010 17:13:52 -0500 Vance Shipley wrote: > On Fri, Feb 19, 2010 at 11:23:08AM -0500, Musumeci, Antonio S wrote: > } While not directly comparable... in other languages when you ask > } for an invalid service (method, function, etc) the caller not the > } called errors. > > The proper thing to do when a server receives an incorrect > call depends on the relationship between the server and the > client. > > The Erlang way of handling programming errors is to fail > immediately and leave a stack trace pointing directly at > the problem so that someone can fix the code. So if your > client and server are two parts of a single program you would > want to have no clause to handle an unknown call. > > On the other hand if the server repesents a service access > point and the client is a user of that service from another > program you would want to guard against it's errors. I use > the following: > > %% @spec (SAP, Request) -> ok > %% SAP = Name | {Name,Node} | {global,GlobalName} | pid() > %% Node = atom() > %% GlobalName = term() > %% Request = term() > %% > %% @doc Public API function for a service request. > %% > call(SAP, Request) -> > case gen_server:call(SAP, Request) of > {ok, Result} -> > Result; > {error, Reason} -> > exit(Reason) > end. > > %% @spec (Request, From, State) -> Result > %% Request = term() > %% From = {pid(), Tag} > %% State = term() > %% @doc Private callback to handle a request sent with call/2. > %% > handle_call(Request, _, State) -> > ... > {reply, {ok, Result}, State}; > handle_call(Other, _, State) -> > {reply, {error, badarg}, State}. > > > I have in the past used something like this: > > handle_call(Other, {Pid, _Tag}, State) -> > exit(Pid, badarg), > {noreply, State}. > > ... however I've come to find the former more appropriate. > From ok@REDACTED Mon Feb 22 00:14:26 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 22 Feb 2010 12:14:26 +1300 Subject: [erlang-questions] Re: What about making sense? In-Reply-To: <9b08084c1002190757o3a4c2bc0s89cc07b8fafe2af0@mail.gmail.com> References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> <9b08084c1002190757o3a4c2bc0s89cc07b8fafe2af0@mail.gmail.com> Message-ID: On Feb 20, 2010, at 4:57 AM, Joe Armstrong wrote: > > This is basically the problem with the entire documentation. We have > legacy > XML annotations that are used in a tiny tiny fraction of the code. > But complete > out-phasing means manually checking stuff that hasn't been touched > for year. Presumably this is why the Erlang/OTP sources were still crammed full of old-style 'catch' expressions the last time I looked. Nasty little paradox: the better something works, the less likely it'll be improved. From ok@REDACTED Mon Feb 22 00:37:05 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 22 Feb 2010 12:37:05 +1300 Subject: [erlang-questions] reserved word guaranteed to be atom if single-quoted? In-Reply-To: References: Message-ID: On Feb 20, 2010, at 9:50 PM, Michael Turner wrote: > And I've been tinkering with a style of argument passing where one > might > write > > the_frob ({of, This_thing}, {within, That_other_thing}, ....) > > as a kind of poor man's syntactic sugar for the folks I'm writing my > code for (who aren't programmers, much less Erlang programmers, just > algorithm-specifiers). (1) I have previously written about adapting Paul Lyons' "split procedure names" to Erlang, where this would appear as the frob of(This_Thing) within(That_Other_Thing) > Of course, the Erlang parser complains about my > "of". (2) New keywords have been added to Erlang over time. There is no reason to believe that we have the final set yet. It would be nice if Erlang code could be "future-proofed". One approach (which I've tried in a tokeniser, and seems to work tolerably well) is that - an identifier *immediately* followed by '(' is always a plain function name - an identifier preceded by one of ( [ { , | ; -> = and followed by one of ) ] } , | ; -> = end is always a plain atom even if it would otherwise be a keyword. (3) As things stand, it's not just Erlang *source code* that can be invalidated by additions to the language. It's Erlang *data* that might be saved in text files or sent a machine running version X to another running version Y where Y > X. With this revision to the "when is it a keyword" rule, there would never be any need to quote identifier-like atoms, no invalidation of old data, and no need to change the output code. From nem@REDACTED Mon Feb 22 01:02:17 2010 From: nem@REDACTED (Geoff Cant) Date: Sun, 21 Feb 2010 16:02:17 -0800 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> (Zubair Quraishi's message of "Sun, 21 Feb 2010 12:48:55 +0100") References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <93334c63-6c1d-4b5d-ba57-20b2265cc8f2@q21g2000yqm.googlegroups.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> Message-ID: Zubair Quraishi writes: > I disagree because the fact that parameterised modules are used only > "internally" in OTP tells me that they "could" be removed. I say this > because removing parameterised modules would not break any client libraries > for OTP, as the internals of OTP could just be changed. > > Is there anyone from Ericcson who could shed light on this, or is it simply > a "risk" to use parameterised modules? > > On Sun, Feb 21, 2010 at 12:25 PM, Rapsey wrote: > >> Not a large chance of that. It's used in a number of libraries including >> OTP >> internally. The only use of parameterized modules in OTP is in the test suites, and most of these appear to simply be testing that various tools can cope with parameterized modules: lib/compiler/test/pmod_SUITE_data/pmod_basic.erl:-module(pmod_basic, [Props]). lib/stdlib/test/dict_test_lib.erl:-module(dict_test_lib, [Mod,Equal]). lib/stdlib/test/epp_SUITE_data/pmod.erl:-module(pmod, [Props]). lib/stdlib/test/erl_eval_helper.erl:-module(erl_eval_helper, [Base]). lib/stdlib/test/erl_expand_records_SUITE.erl: Test = <<"-module(param, [A, B]). lib/stdlib/test/erl_expand_records_SUITE.erl: Test = <<"-module(guard, [A, B]). lib/stdlib/test/erl_lint_SUITE.erl: Abstr = <<"-module(lint_test, [A, B]). lib/stdlib/test/erl_pp_SUITE.erl: ?line ok = pp_forms(<<"-module(m.p, [A,B]). ">>), lib/stdlib/test/erl_pp_SUITE.erl: ?line ok = pp_forms(<<"-module(m, [Aafjlksfjdlsjflsdfjlsdjflkdsfjlk," lib/stdlib/test/sets_test_lib.erl:-module(sets_test_lib, [Mod,Equal]). lib/stdlib/test/shell_SUITE.erl: Contents = <<"-module(parameterized, [A]). " lib/tools/test/xref_SUITE.erl: Test = <<"-module(param, [A, B]). We still have time to ditch them :) Parameterized modules seem to be mainly useful as a way of having the compiler pass around what would otherwise be a state argument (module callback data) for you. Given that the result is still functional, you still have to return {Result, UpdatedParamModule} if you want to alter any of the module parameters, I don't see it improving existing gen_server style callback APIs. Code that needs to update module parameters is in fact less readable than if a state record had been used as there's no syntax for selectively updating parameters. Module parameters are simply hidden function arguments. To me, this reduces the readability of the code as there's now another place to look for data that will affect function behaviour. Another problem with them is that there's no support for pattern matching the module parameters as there is for function arguments. The main use of parameterized modules I've seen in the wild is the mochiweb_request module. While this use of parameterized modules does slightly improve client code by shortening mochiweb_request:Method(Req, Args) to Req:Method(Args), it does make the code less grepable for uses of mochiweb_request unless you follow the convention of always calling the request module 'Req'. The mochiweb_request term (object?) does need to go through certain state transitions such as reading the request body. Unfortunately the API doesn't return an updated mochiweb_request, it uses the process dictionary to memoize this. The resulting term/object is now process-specific and behaves surprisingly differently to regular erlang opaque data structures when passed between processes. The API doesn't seem to be better for having used parameterized modules. If the API did return an updated module, the mochiweb_request code would be littered with calls to ?MODULE:new(Arg, Arg, Arg, UpdatedArg, Arg) and the client could would have all the {Result, UpdatedReq} = Req:Method(Args) code that a regular gen_server style callback interface has. I would gladly reconsider my somewhat harshly critical position on parameterized modules if shown a clear example of how their use improves the readability or expressiveness of code. Until then I would urge that they didn't become an official part of the Erlang language. Cheers, -- Geoff Cant, Erlang curmudgeon and OTP-fundamentalist. From ok@REDACTED Mon Feb 22 01:10:45 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 22 Feb 2010 13:10:45 +1300 Subject: [erlang-questions] Re: What about making sense? In-Reply-To: <9b08084c1002201002k1ffc01e9k676b01727588586b@mail.gmail.com> References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> <4B7FE751.5080908@gmail.com> <9b08084c1002201002k1ffc01e9k676b01727588586b@mail.gmail.com> Message-ID: On Feb 21, 2010, at 7:02 AM, Joe Armstrong wrote: > I've been thinking about documentation/books for years now. > > One thing that documentation and books does not capture is the order > in > which we write a program. > > A book with a code example presents the final result of a process. Not > how we arrived at the result. My PhD time at Edinburgh overlapped with Martin Feather. http://delivery.acm.org/10.1145/360000/357154/p1-feather.pdf?key1=357154&key2=1839976621&coll=GUIDE&dl=GUIDE&CFID=77105502&CFTOKEN=60303561 A System for Assisting Transformation MARTIN S. FEATHER ACM Transactions on Programming Languages and Systems, Vol. 4, No. 1, January 1982, Pages 1-20. The idea here was to specify a program in two pieces: (a) a high level specification (b) a transformation script that turned it into something more efficient One idea was that if you changed the high level specification you should be able to reuse most of the transformation script. Another idea was that people should read the high level specification and the script rather than the lower level code. However, that started with a correct specification. About the same time Ehud Shapiro came up with the idea of declarative debugging, including the notion of creating a program by debugging an empty program. (This is _LONG_ before Fowler & co came along.) There are also links with the Bird-Meertens school (which itself links back to Dijkstra's "Discipline of Programming") of "calculating programs from specifications". > > When I write *any* process I always start with something like: > > loop(...) -> > receive > Any -> io:format("got:~p~n",[Any]), > loop(...) > end. > > it's always the same. I then run the program and see what messages > arrive at the receive loop. I then add patterns that match the > messages > that arrive. > > As I develop the program I work in small steps - adding one message > at a time > and testing as I go. When I'm ready and the program is developed I > might > remove the "Any -> ..." bit. > > Seeing the final result give no clues as to the order in which > things were > done. Each micro step can have a deal of thinking behind it. Xerox PARC used to have a slogan, "A program is not a listing". (By which they meant "a program is a database", hence the Smalltalk and Interlisp IDEs.) A program is, it would appear, a _temporal_ database, and the _transitions_ are as much deserving of record and comment as the _states_. > > Can this be described in words at all? - I doubt it. I really like > Utube videos > that explain how to do things in some domain. You can stop and > replay them. > A video with a detailed commentary seems then best way to do this. But (a) they are much MUCH more costly for people on the other side of the world to access than text. Downloading a single one-hour lecture from the SICP series showed up on my department's budget and was raised at a departmental meeting as an issue. And (b) they are painfully SLOW to watch. Don't forget (c): what the presenter saw as an issue that needed explaining might be obvious to some viewers, while what a viewer has serious trouble with might be obvious to the presenter. Imagine, for example, someone presenting an Erlang chat system and labouring over details of Erlang syntax while taking mnesia for granted. > Books - and printed documentation - no matter how good - cannot > illustrate > process - *the exact order in which I did things any why* Books _can_ illustrate process, although not perhaps at the micro-level of keystrokes. They can certainly show a series of versions with commentary. > > > I greatly sympathises with those who say "I can't understand > documentation". Documentation is written for those who already > understand - and is no a vehicle for understanding itself. On the other hand, I *did* learn Unix V7 from the manuals and nothing else, and Ada 81 (and up to Ada 95) from the LRM and nothing else. For some kinds of material, books can do very well indeed. > > > "Read the code Luke" is even worse - even If I could understand the > code > (which can sometimes be *extremely* difficult) I have not idea at all > what it is *supposed* to do only what it does. I consider this > unprofessional. It's not without interest that Squeak, the open source incarnation of Smalltalk-80, where the "read the source" slogan found an early home, now nags people with red "THIS CLASS HAS NO COMMENT" warnings. > Aside from the books, which are really good, I think the "greatest" piece of Erlang documentation is the "OTP Design Principles Users Guide". It's certainly the most critical to read, which is why it's a pity that it's not really obvious in the on-line documents. It's not mentioned at all in http://www.erlang.org/doc/ for example, and I've have listed it near the language reference. From ok@REDACTED Mon Feb 22 01:51:52 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 22 Feb 2010 13:51:52 +1300 Subject: [erlang-questions] A sender() BIF? In-Reply-To: <4JyGEm7n.1266758439.0683540.leap@gol.com> References: <4JyGEm7n.1266758439.0683540.leap@gol.com> Message-ID: On Feb 22, 2010, at 2:20 AM, Michael Turner wrote: > > It's conventional for certain purposes to make the first term of a > message tuple be the sender, where the receiver needs to know.\ Hmm. I've always put the 'tag' first, for readability. I find receive {ok,Pid,Data} -> ... much more readable than receive {Pid,ok,Data} -> > > Recently, I started wondering: why isn't the appropriate sender > already > available within each receive scope, via a BIF (or even via some > special > variable)? One reason is "because it's not needed", and another has to be "because the reply address isn't always the sender address". Imagine some sort of load balancing scheme Client 1 Server 1 ... Router ... Client m Server n where the router receives messages from clients and redirects them to servers, and the servers send their replies straight back to the clients. Also, consider that sending a message to a process on another node doesn't _always_ result in a proxy stub for the sending process materialising on the other node. > Does the idea of sender() violate encapsulation in some meaningful > way? > As matters stand, a module just has to take it on faith that a Pid > identified as sender in a message actually *is* the sender. What it has to take on faith is that the Pid in a message identifies the right process to *reply* to, which is different. Consider the following scenario: Self = self(), My_Helper_Pid = spawn(fun () -> do some long computation, Other_Process ! {proceed_with,Self,Data} end), ... receive {response,Other_Process,Result} -> ... If Other_Process relied on sender(), it would send the message to the wrong process. Having learned about Unix IPC and sockets before Erlang, it took me a while to appreciate the fact that the ONLY information a process has about a message is the information right there in the message, which is precisely the information the sender chose to divulge. From rvirding@REDACTED Mon Feb 22 02:25:10 2010 From: rvirding@REDACTED (Robert Virding) Date: Mon, 22 Feb 2010 02:25:10 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> Message-ID: <3dbc6d1c1002211725r3dc235d9g9985ce7bd229b900@mail.gmail.com> I would like to extend the question to two other things which have been "experimental" for a while now without being decided or having proper documentation: - the -extends attribute - packages The trouble is that they are "there" but it is not defined what they do and you can't turn them off so it is easy to get bitten by them and not really understand what has happened. And how do they interact? Yes, I do know of the papers describing two of them but no one can say it is obvious that you look there for Erlang documentation. To start the discussion rolling here are my opinions on the three listed in order of *decreasing* approval/interest or increasing disapproval: - Paramterised modules - I can live with these but don't really see the point yet. - Extends: sub-moduling? - Packages: a hierarchical peg in a flat hole, I just don't think its fits. Comments? Robert From mononcqc@REDACTED Mon Feb 22 03:32:45 2010 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 21 Feb 2010 21:32:45 -0500 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <3dbc6d1c1002211725r3dc235d9g9985ce7bd229b900@mail.gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <3dbc6d1c1002211725r3dc235d9g9985ce7bd229b900@mail.gmail.com> Message-ID: <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> My opinion on parametrized modules was formulated in this stackoverflow post: http://stackoverflow.com/questions/2291155/what-alternatives-are-there-to-parameterised-modules-in-erlang/2291394#2291394-- I won't say much more on this. I don't have much of a problem with -extend() myself, though. It permits a very flat inheritance to modules, which can sometimes be useful. The overriding rules are simple (if it's the same function, it replaces it, otherwise, it looks in the extended module), there can only be one extended module at once, etc. It's useful when you want to add specificity on top of another module without wanting to redefine everything else. I guess the simplest example could be about a module made to work on a deck of cards: depending if they are UNO cards, regular cards or let's say Pok?mon cards, the functions to initiate a deck or to verify its integrity will vary from implementation to implementation, but will remain similar for everything else (shuffle, distribute, add/remove cards, etc). One of the downsides I see is that the dispatch seems to be made at runtime (module_info/0 returns no information about extended modules' functions), which means that the extended module's internal representation might change, provoking errors in the extender without much warning. It's a breach of encapsulation to some extent. It's easy to argue that a callback module with a behavior would be much more appropriate. Not only does it solve the problem mentioned in the previous paragraph (the behavior needs to be compiled itself, there are fewer ambiguities, etc.), but it is consequent with the development concepts proposed by the OTP framework. On Sun, Feb 21, 2010 at 8:25 PM, Robert Virding wrote: > I would like to extend the question to two other things which have > been "experimental" for a while now without being decided or having > proper documentation: > > - the -extends attribute > - packages > > The trouble is that they are "there" but it is not defined what they > do and you can't turn them off so it is easy to get bitten by them and > not really understand what has happened. And how do they interact? > Yes, I do know of the papers describing two of them but no one can say > it is obvious that you look there for Erlang documentation. > > To start the discussion rolling here are my opinions on the three > listed in order of *decreasing* approval/interest or increasing > disapproval: > > - Paramterised modules - I can live with these but don't really see > the point yet. > - Extends: sub-moduling? > - Packages: a hierarchical peg in a flat hole, I just don't think its fits. > > Comments? > > Robert > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From ok@REDACTED Mon Feb 22 04:30:47 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 22 Feb 2010 16:30:47 +1300 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <3dbc6d1c1002211725r3dc235d9g9985ce7bd229b900@mail.gmail.com> <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> Message-ID: <7DD72550-0106-4EEA-BDA3-1027548799CC@cs.otago.ac.nz> There are potential uses for parametric modules other than what Erlang currently has, and the _way_ Erlang does parametric modules is one of several alternatives. For example, one way of thinking about configuration is that a configuration is basically a function that computes a set of modules given a set of modules, and that an update is a "minimal" re-evaluation of this function when some of its inputs change. (This is very like the distribution/build system that was done for MESA.) In Ada and ML there are things that map from modules to modules (Ada generic packages, ML functors), but the things they compute are *modules*, not run-time values. In the present scheme, modules and parametric modules are so different that I find it confusing to call them by the same name. From andrew@REDACTED Mon Feb 22 04:43:11 2010 From: andrew@REDACTED (Andrew Thompson) Date: Sun, 21 Feb 2010 22:43:11 -0500 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> References: <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <3dbc6d1c1002211725r3dc235d9g9985ce7bd229b900@mail.gmail.com> <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> Message-ID: <20100222034311.GG8518@hijacked.us> Personally I'd list them in this order (of increasing dislike): * -extends - this one doesn't really affect you unless you're using it yourself - the end user doesn't have to care (although writing a behaviour is probably just as good). * packages - these can affect you if you're using a library that someone decided to use packages in but you can probably think of them as just modules with dots in the name. * parameterized modules - these are the ones that really screw with the end user. I had a real headache when I first tried to use them in mochiweb. Basicially since I wouldn't use any of them in any of my projects I mainly look at them from the point of view of the inconvienience when I try to use someone else's code that uses them. Andrew From leap@REDACTED Mon Feb 22 08:53:57 2010 From: leap@REDACTED (Michael Turner) Date: Mon, 22 Feb 2010 07:53:57 +0000 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <20100222034311.GG8518@hijacked.us> Message-ID: <2Y2a7Kqp.1266825237.7685460.leap@gol.com> I have no opinion on any of these (extends, packages, parameterized modules) at the moment. I'm wondering, however: perhaps it would be wise if, in the future, these sorts of experimental extensions were announced and supplied *only* if they came with refactoring tools for reverting the code, so that people who committed strongly to the use of such a feature could always back out later, if the idea dead-ends? I looked briefly at parameterized modules, but I got cold feet when I noticed they weren't officially supported. If there were some way to use them with the confidence that, if dropped, one could automatically transform code that uses them into something that doesn't use them, with little loss of legibility and no new errors introduced, I probably would have been more inclined to experiment. And you want a lot of experimenters, to inform and support any keep/drop decision. -michael turner On 2/22/2010, "Andrew Thompson" wrote: >Personally I'd list them in this order (of increasing dislike): > >* -extends - this one doesn't really affect you unless you're using it > yourself - the end user doesn't have to care (although writing a > behaviour is probably just as good). >* packages - these can affect you if you're using a library that someone > decided to use packages in but you can probably think of them as just > modules with dots in the name. >* parameterized modules - these are the ones that really screw with the > end user. I had a real headache when I first tried to use them in > mochiweb. > >Basicially since I wouldn't use any of them in any of my projects I >mainly look at them from the point of view of the inconvienience when I >try to use someone else's code that uses them. > >Andrew > >________________________________________________________________ >erlang-questions (at) erlang.org mailing list. >See http://www.erlang.org/faq.html >To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From pieter.rijken@REDACTED Mon Feb 22 10:28:45 2010 From: pieter.rijken@REDACTED (pietje) Date: Mon, 22 Feb 2010 01:28:45 -0800 (PST) Subject: parametrized modules and unit testing Message-ID: <62c07b1e-96cb-4ef8-b0e8-704312af9890@c16g2000yqd.googlegroups.com> I'm quite new to Erlang and probably don't understand fully some of the concepts. I want to write unit tests (using eunit) for a module without being dependent on the implementation of other modules that it uses. Suppose I have 2 modules, say ma and mb, and that module ma uses (imports) module mb. I'm trying to figure out in Erlang how to write unit tests for module ma that do not depend on the particular implementation of functions in module mb. The idea is that I want to be able to change the behaviour of functions in mobule mb while at the same time keeping the API unchanged in such a way that the unit tests for module ma do not change. In Java I was used to solving this using dependency injection techniques (using the factory pattern and mocked objects). Up till now in Erlang I was using parametrized modules to this end by passing a module as one of the parameters. But considering the discussion in other threads, I'm looking for alternatives. Does anyone have suggestions or explain how this is normally done in Erlang? many thanks, pieter From vladdu55@REDACTED Mon Feb 22 10:52:27 2010 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 22 Feb 2010 10:52:27 +0100 Subject: [erlang-questions] parametrized modules and unit testing In-Reply-To: <62c07b1e-96cb-4ef8-b0e8-704312af9890@c16g2000yqd.googlegroups.com> References: <62c07b1e-96cb-4ef8-b0e8-704312af9890@c16g2000yqd.googlegroups.com> Message-ID: <95be1d3b1002220152l60ca4bbcjb25159c37ab5c043@mail.gmail.com> On Mon, Feb 22, 2010 at 10:28, pietje wrote: > Suppose I have 2 modules, say ma and mb, and that module ma uses > (imports) module mb. > I'm trying to figure out in Erlang how to write unit tests for module > ma that do not depend on the particular > implementation of functions in module mb. Hi, One simple way is to use conditional compilation; in ma use -ifdef(TEST). -include_lib("eunit/include/eunit.hrl"). -define(MB, mock_mb). -else. -define(MB, mb). -endif. and make all calls to mb via ?MB. (Of course, you'll have to implement a mock_mb module). A more advanced way would be to have a central mock server where you can register a fun for each mocked function (in any module) and use error_handler:undefined_function to use these registered funs instead of the real ones. This is quite complex to implement, though. best regards, Vlad From hynek@REDACTED Mon Feb 22 11:58:10 2010 From: hynek@REDACTED (Hynek Vychodil) Date: Mon, 22 Feb 2010 11:58:10 +0100 Subject: [erlang-questions] Sequential I/O access for large files in Erlang In-Reply-To: <4B7785C5.6030504@gmail.com> References: <4B7785C5.6030504@gmail.com> Message-ID: <4d08db371002220258y50576fb3n19f5bd20091aaabb@mail.gmail.com> If you want really fast IO you can use approach shown there http://shootout.alioth.debian.org/u64q/program.php?test=regexdna&lang=hipe&id=6 But don't forgot add -noinput parameter to erl. I have mentioned it in mine contribution, it worked for a while and #6 version was there in top list with ~60s, but they broke it without any warning. I have long message exchange with Isaac Gouy https://alioth.debian.org/tracker/index.php?func=detail&aid=312099 before they accept it. It worked but they changed it again. I have found it just now but I'm fed up with this arrogant moron and I will not waste mine time trying fix it again. On Sun, Feb 14, 2010 at 6:10 AM, Kay Kay wrote: > For a particular use case of mine - I need to be dealing with some bulk text > i/o ?(medium sized multiple files of ~50 MB each ). > > While looking for some best solutions , came across this blog here at - > ?http://concise-software.blogspot.com/2008/09/blazing-fast-concurrent-text-io-in.html > . > > I am using - 5.7.4 beam emulator (on ubuntu) at the moment. I am trying to > get some opinions on some of the recommended options , w.r.t this, that the > community would suggest. Thanks. > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero! Try GoodData now for free: www.gooddata.com From bengt.kleberg@REDACTED Mon Feb 22 12:08:36 2010 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 22 Feb 2010 12:08:36 +0100 Subject: [erlang-questions] Sequential I/O access for large files in Erlang In-Reply-To: <4d08db371002220258y50576fb3n19f5bd20091aaabb@mail.gmail.com> References: <4B7785C5.6030504@gmail.com> <4d08db371002220258y50576fb3n19f5bd20091aaabb@mail.gmail.com> Message-ID: <1266836916.5021.17.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Greetings, As an alternative to Isaac you could try to contact Brent Fulgham. When I was working with the Shootout many years ago that helped for a while. bengt On Mon, 2010-02-22 at 11:58 +0100, Hynek Vychodil wrote: > If you want really fast IO you can use approach shown there > http://shootout.alioth.debian.org/u64q/program.php?test=regexdna?=hipe&id=6 > > But don't forgot add -noinput parameter to erl. I have mentioned it in > mine contribution, it worked for a while and #6 version was there in > top list with ~60s, but they broke it without any warning. I have long > message exchange with Isaac Gouy > https://alioth.debian.org/tracker/index.php?func=detail&aid=312099 > before they accept it. It worked but they changed it again. I have > found it just now but I'm fed up with this arrogant moron and I will > not waste mine time trying fix it again. > > On Sun, Feb 14, 2010 at 6:10 AM, Kay Kay wrote: > > For a particular use case of mine - I need to be dealing with some bulk text > > i/o (medium sized multiple files of ~50 MB each ). > > > > While looking for some best solutions , came across this blog here at - > > http://concise-software.blogspot.com/2008/09/blazing-fast-concurrent-text-io-in.html > > . > > > > I am using - 5.7.4 beam emulator (on ubuntu) at the moment. I am trying to > > get some opinions on some of the recommended options , w.r.t this, that the > > community would suggest. Thanks. > > > > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > See http://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > > > > > From kenrobinsonster@REDACTED Mon Feb 22 13:18:13 2010 From: kenrobinsonster@REDACTED (Ken Robinson) Date: Mon, 22 Feb 2010 22:18:13 +1000 Subject: [erlang-questions] parametrized modules and unit testing In-Reply-To: <95be1d3b1002220152l60ca4bbcjb25159c37ab5c043@mail.gmail.com> References: <62c07b1e-96cb-4ef8-b0e8-704312af9890@c16g2000yqd.googlegroups.com> <95be1d3b1002220152l60ca4bbcjb25159c37ab5c043@mail.gmail.com> Message-ID: Hi, I've not used this module but it appears to give the behavior you want. http://frihjul.net/emock regards, Ken. On Mon, Feb 22, 2010 at 7:52 PM, Vlad Dumitrescu wrote: > On Mon, Feb 22, 2010 at 10:28, pietje wrote: >> Suppose I have 2 modules, say ma and mb, and that module ma uses >> (imports) module mb. >> I'm trying to figure out in Erlang how to write unit tests for module >> ma that do not depend on the particular >> implementation of functions in module mb. > > Hi, > > One simple way is to use conditional compilation; in ma use > > -ifdef(TEST). > ? ?-include_lib("eunit/include/eunit.hrl"). > ? ?-define(MB, mock_mb). > -else. > ? ?-define(MB, mb). > -endif. > > and make all calls to mb via ?MB. (Of course, you'll have to implement > a mock_mb module). > > > A more advanced way would be to have a central mock server where you > can register a fun for each mocked function (in any module) and use > error_handler:undefined_function to use these registered funs instead > of the real ones. This is quite complex to implement, though. > > best regards, > Vlad > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From jeedward@REDACTED Mon Feb 22 12:39:01 2010 From: jeedward@REDACTED (John Edward) Date: Mon, 22 Feb 2010 03:39:01 -0800 (PST) Subject: Call for papers: MULTICONF-10, Orlando, USA, July 2010 Message-ID: <258826.73950.qm@web45901.mail.sp1.yahoo.com> It would be highly appreciated if you could share this announcement with your colleagues, students and individuals whose research is in computer science, computer engineering, information science and related areas. Call for papers: MULTICONF-10, Orlando, USA, July 2010 The 2010 multi-conference (MULTICONF-10) (website: http://www.PromoteResearch.org ) will be held during July 12-14, 2010 in Orlando, Florida, USA. The primary goal of MULTICONF is to promote research and developmental activities in computer science, information technology, control engineering, and related fields. Another goal is to promote the dissemination of research to a multidisciplinary audience and to facilitate communication among researchers, developers, practitioners in different fields. The following conferences are planned to be organized as part of MULTICONF-10. ? International Conference on Artificial Intelligence and Pattern Recognition (AIPR-10) ? International Conference on Automation, Robotics and Control Systems (ARCS-10) ? International Conference on Bioinformatics, Computational Biology, Genomics and Chemoinformatics (BCBGC-10) ? International Conference on Computer Communications and Networks (CCN-10) ? International Conference on Enterprise Information Systems and Web Technologies (EISWT-10) ? International Conference on High Performance Computing Systems (HPCS-10) ? International Conference on Information Security and Privacy (ISP-10) ? International Conference on Image and Video Processing and Computer Vision (IVPCV-10) ? International Conference on Software Engineering Theory and Practice (SETP-10) ? International Conference on Theoretical and Mathematical Foundations of Computer Science (TMFCS-10) MULTICONF-10 will be held at Imperial Swan Hotel and Suites. It is a full-service resort that puts you in the middle of the fun! Located 1/2 block south of the famed International Drive, the hotel is just minutes from great entertainment like Walt Disney World? Resort, Universal Studios and Sea World Orlando. Guests can enjoy free scheduled transportation to these theme parks, as well as spacious accommodations, outdoor pools and on-site dining ? all situated on 10 tropically landscaped acres. Here, guests can experience a full-service resort with discount hotel pricing in Orlando. Please see the website http://www.PromoteResearch.org for more details. Sincerely John Edward From tuncer.ayaz@REDACTED Mon Feb 22 14:09:51 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Mon, 22 Feb 2010 14:09:51 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <20100222034311.GG8518@hijacked.us> References: <4B7FEA27.1020008@gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <3dbc6d1c1002211725r3dc235d9g9985ce7bd229b900@mail.gmail.com> <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> <20100222034311.GG8518@hijacked.us> Message-ID: <4ac8254d1002220509k227c20aax84efd9f570845a16@mail.gmail.com> On Mon, Feb 22, 2010 at 4:43 AM, Andrew Thompson wrote: > Personally I'd list them in this order (of increasing dislike): > > * -extends - this one doesn't really affect you unless you're using it > ?yourself - the end user doesn't have to care (although writing a > ?behaviour is probably just as good). > * packages - these can affect you if you're using a library that someone > ?decided to use packages in but you can probably think of them as just > ?modules with dots in the name. > * parameterized modules - these are the ones that really screw with the > ?end user. I had a real headache when I first tried to use them in > ?mochiweb. If you want an alternative to Mochiweb or Misultin that doesn't use procdict, parmods and is also packaged as an OTP app have a look at http://frihjul.net/iserve. It is maintained by Christian Sunesson at http://github.com/noss/iserve. > Basicially since I wouldn't use any of them in any of my projects I > mainly look at them from the point of view of the inconvienience when I > try to use someone else's code that uses them. From pieter.rijken@REDACTED Mon Feb 22 14:13:34 2010 From: pieter.rijken@REDACTED (pietje) Date: Mon, 22 Feb 2010 05:13:34 -0800 (PST) Subject: parametrized modules and unit testing In-Reply-To: <95be1d3b1002220152l60ca4bbcjb25159c37ab5c043@mail.gmail.com> References: <62c07b1e-96cb-4ef8-b0e8-704312af9890@c16g2000yqd.googlegroups.com> <95be1d3b1002220152l60ca4bbcjb25159c37ab5c043@mail.gmail.com> Message-ID: Hi, Thanks for the suggestion. It seems to meet the needs. I'm planning to have MB defined as: -define(MB, ?MODULE) enabling me to add internal functions that act as callbacks. This also fits nicely with eunit. pieter P.S. Still I would like to have something like a factory pattern, but that's not what I asked for :-) On Feb 22, 10:52?am, Vlad Dumitrescu wrote: > On Mon, Feb 22, 2010 at 10:28, pietje wrote: > > Suppose I have 2 modules, say ma and mb, and that module ma uses > > (imports) module mb. > > I'm trying to figure out in Erlang how to write unit tests for module > > ma that do not depend on the particular > > implementation of functions in module mb. > > Hi, > > One simple way is to use conditional compilation; in ma use > > -ifdef(TEST). > ? ? -include_lib("eunit/include/eunit.hrl"). > ? ? -define(MB, mock_mb). > -else. > ? ? -define(MB, mb). > -endif. > > and make all calls to mb via ?MB. (Of course, you'll have to implement > a mock_mb module). > > A more advanced way would be to have a central mock server where you > can register a fun for each mocked function (in any module) and use > error_handler:undefined_function to use these registered funs instead > of the real ones. This is quite complex to implement, though. > > best regards, > Vlad > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > Seehttp://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED From pieter.rijken@REDACTED Mon Feb 22 14:14:35 2010 From: pieter.rijken@REDACTED (pietje) Date: Mon, 22 Feb 2010 05:14:35 -0800 (PST) Subject: parametrized modules and unit testing In-Reply-To: References: <62c07b1e-96cb-4ef8-b0e8-704312af9890@c16g2000yqd.googlegroups.com> <95be1d3b1002220152l60ca4bbcjb25159c37ab5c043@mail.gmail.com> Message-ID: Hi, Thanks for this alternative. I'll keep it in mind for the more complex modules I have. pieter On Feb 22, 1:18?pm, Ken Robinson wrote: > Hi, > I've not used this module but it appears to give the behavior you want.http://frihjul.net/emock > > regards, > Ken. > > > > On Mon, Feb 22, 2010 at 7:52 PM, Vlad Dumitrescu wrote: > > On Mon, Feb 22, 2010 at 10:28, pietje wrote: > >> Suppose I have 2 modules, say ma and mb, and that module ma uses > >> (imports) module mb. > >> I'm trying to figure out in Erlang how to write unit tests for module > >> ma that do not depend on the particular > >> implementation of functions in module mb. > > > Hi, > > > One simple way is to use conditional compilation; in ma use > > > -ifdef(TEST). > > ? ?-include_lib("eunit/include/eunit.hrl"). > > ? ?-define(MB, mock_mb). > > -else. > > ? ?-define(MB, mb). > > -endif. > > > and make all calls to mb via ?MB. (Of course, you'll have to implement > > a mock_mb module). > > > A more advanced way would be to have a central mock server where you > > can register a fun for each mocked function (in any module) and use > > error_handler:undefined_function to use these registered funs instead > > of the real ones. This is quite complex to implement, though. > > > best regards, > > Vlad > > > ________________________________________________________________ > > erlang-questions (at) erlang.org mailing list. > > Seehttp://www.erlang.org/faq.html > > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > Seehttp://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED From rtrlists@REDACTED Mon Feb 22 14:31:57 2010 From: rtrlists@REDACTED (Robert Raschke) Date: Mon, 22 Feb 2010 13:31:57 +0000 Subject: [erlang-questions] Overlong wait in receive after In-Reply-To: <20100219195522.GH5805@delora.autosys.us> References: <6a3ae47e1002190933haec817j7258ae66b00dbc1a@mail.gmail.com> <20100219195522.GH5805@delora.autosys.us> Message-ID: <6a3ae47e1002220531w4ee1ed31v1d9ab465b1695d05@mail.gmail.com> On Fri, Feb 19, 2010 at 7:55 PM, Michael wrote: > On Fri, Feb 19, 2010 at 05:33:36PM +0000, Robert Raschke wrote: > > Hi, > > > > has anyone encountered spurious overlong waits using receive ... after? > That > > is, the code says "after 1000 ->" but it's way longer than 1 second > before > > it gets there. > > > > My code starts a Java jinterface node, the Java code creates the node, > > creates an mbox, and waits a minute for a message to appear and sends one > > back. > > > > The Erlang code starts the Java as a port program, and starts sending ok > > messages to the registered mbox of the Java program spaced 1 second > apart. > > My logging indicates that the sending of the messages is actually spaced > > somewhere between 5 and 12 seconds apart! > > > > This is on a Windows 2003 Server running R12B-5. > > > > In Erlang (started with -sname "erl@REDACTED") this is roughly what's > > happening (apologies for typos): > > > > run() -> > > Node_Name = "foo@REDACTED", > > Mbox = {box, list_to_atom(Node_Name)}, > > Port_Pid = spawn_link(?MODULE, run_port_program, [Node_Name, > > atom_to_list(erlang:get_cookie())]), > > {ok, Java_Pid} = shake_hands(Mbox, 0). > > > > shake_hands(Mbox, N) when N < 50 -> > > error_logger:info_report([{module, ?MODULE}, {handshake, N}, {mbox, > > Mbox}]), > > Mbox ! {self(), ok}, > > receive > > {ok, Pid} -> > > {ok, Pid} > > after 1000 -> > > error_logger:error_report([{module, ?MODULE}, {'handshake > timeout', > > N}]), > > shake_hands(Mbox, N+1) > > end; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Seems likely that messages other than {ok, Pid} are coming in > and growing the message queue. > > try adding a catchall to check ... > > > > receive > > {ok, Pid} -> > > {ok, Pid} > > > ; _Other -> io:fwrite("Catchall: ~p~n", [_Other]) > > > > after 1000 -> > > > then, presuming it's junk, you can just throw the spurious msgs out > > > ~Michael > > I am currently trying to narrow down where the time is going, and I have a feeling that it is actually delaying on the send operation, not the receive. I've got some more extended logging out to the installation but will have to wait until I hear back. Incidentally, I have just received another report of this sequence failing at a different location. SW was in place for several months and after the weekend is now exhibiting the same timeout behaviour. Slight additional bit of info is that it looks like epmd.exe is killed spuriously, but not consistently. Is anyone out there aware of any MS patches, virus DB updates, etc. that may be suddenly impacting Erlang communications? Thanks for any pointers, Robby From ulf.wiger@REDACTED Mon Feb 22 14:58:44 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Mon, 22 Feb 2010 14:58:44 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <3dbc6d1c1002211725r3dc235d9g9985ce7bd229b900@mail.gmail.com> <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> Message-ID: <4B828D94.60504@erlang-solutions.com> The -extend() function ought to fit perfectly for defining mnesia activity callbacks. The mnesia_access behaviour has a daunting number of functions. Most of the time, when I feel the need for a mnesia_access callback, there are only a few functions that I feel the need to extend (or at least, that's how one would like to start out). Interestingly, there is no module called mnesia_access. The default callback module is mnesia. I assume this is a bit tricky to change after so many years, but a first step could be to move all the callback functions out of mnesia.erl and into mnesia_access.erl, then keep mapping functions in mnesia.erl, to serve those who have hard-coded mnesia as their activity callback. This would allow people like me to write an activity callback that extends mnesia_activity using the -extend() attribute. BR, Ulf W Fred Hebert wrote: > > I don't have much of a problem with -extend() myself, though. It permits a > very flat inheritance to modules, which can sometimes be useful. The > overriding rules are simple (if it's the same function, it replaces it, > otherwise, it looks in the extended module), there can only be one extended > module at once, etc. > > It's useful when you want to add specificity on top of another module > without wanting to redefine everything else. I guess the simplest example > could be about a module made to work on a deck of cards: depending if they > are UNO cards, regular cards or let's say Pok?mon cards, the functions to > initiate a deck or to verify its integrity will vary from implementation to > implementation, but will remain similar for everything else (shuffle, > distribute, add/remove cards, etc). > > One of the downsides I see is that the dispatch seems to be made at runtime > (module_info/0 returns no information about extended modules' functions), > which means that the extended module's internal representation might change, > provoking errors in the extender without much warning. It's a breach of > encapsulation to some extent. -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From Andrei.Keis@REDACTED Mon Feb 22 15:24:20 2010 From: Andrei.Keis@REDACTED (Keis, Andrei) Date: Mon, 22 Feb 2010 09:24:20 -0500 Subject: [erlang-questions] A sender() BIF? In-Reply-To: References: <4JyGEm7n.1266758439.0683540.leap@gol.com> Message-ID: <33A39648E8D6FF438E3907E5396598E001C11278EC@NYWEXMBX2128.msad.ms.com> I think the focus here should be on remote node authentication (and network identity of the sender process) rather than reply pid, which is part of the message data. If we focus on remote node authentication vm help is needed. There are two ways to implement authentication - message level, and I can add security context as a field in the message similar to 'reply-to', or when establishing link. Having security context per message requires implementing custom protocols and will not cover built-ins. On the other hand, for transport level security it is possible to implement some sort of pluggable security exit when link is established (replace cookie system with Kerberos for example), so vm will know network identity of the remote side. It is easy to do, but this info is lost in the receive loop. For example, if it is possible to extend the syntax of receive: receive { ... } from { Princ } -> ... vm should know where this message is coming from, and Princ can unify with anonymous, local, or { krb, ... } and so on. If I care, I will include this in the loop, if not, just omit the 'from' from the loop and it is backward compatible. > -----Original Message----- > From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] > On Behalf Of Richard O'Keefe > Sent: Sunday, February 21, 2010 7:52 PM > To: Michael Turner > Cc: erlang-questions@REDACTED > Subject: Re: [erlang-questions] A sender() BIF? > > > On Feb 22, 2010, at 2:20 AM, Michael Turner wrote: > > > > > It's conventional for certain purposes to make the first term of a > > message tuple be the sender, where the receiver needs to know.\ > > Hmm. I've always put the 'tag' first, for readability. > I find > receive {ok,Pid,Data} -> ... > much more readable than > receive {Pid,ok,Data} -> > > > > > Recently, I started wondering: why isn't the appropriate sender > > already > > available within each receive scope, via a BIF (or even via some > > special > > variable)? > > One reason is "because it's not needed", and another has to be > "because the reply address isn't always the sender address". > > Imagine some sort of load balancing scheme > > Client 1 Server 1 > ... Router ... > Client m Server n > > where the router receives messages from clients and redirects them > to servers, and the servers send their replies straight back to > the clients. > > Also, consider that sending a message to a process on another node > doesn't _always_ result in a proxy stub for the sending process > materialising on the other node. > > > Does the idea of sender() violate encapsulation in some meaningful > > way? > > As matters stand, a module just has to take it on faith that a Pid > > identified as sender in a message actually *is* the sender. > > What it has to take on faith is that the Pid in a message > identifies the right process to *reply* to, which is different. > > Consider the following scenario: > > Self = self(), > My_Helper_Pid = spawn(fun () -> > do some long computation, > Other_Process ! {proceed_with,Self,Data} > end), > ... > receive {response,Other_Process,Result} -> ... > > If Other_Process relied on sender(), it would send the message > to the wrong process. > > Having learned about Unix IPC and sockets before Erlang, it took > me a while to appreciate the fact that the ONLY information a > process has about a message is the information right there in the > message, which is precisely the information the sender chose to > divulge. > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. From dmercer@REDACTED Mon Feb 22 16:05:43 2010 From: dmercer@REDACTED (David Mercer) Date: Mon, 22 Feb 2010 09:05:43 -0600 Subject: [erlang-questions] Re: What about making sense? In-Reply-To: <9b08084c1002201002k1ffc01e9k676b01727588586b@mail.gmail.com> References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> <4B7FE751.5080908@gmail.com> <9b08084c1002201002k1ffc01e9k676b01727588586b@mail.gmail.com> Message-ID: <1CF972F18EE046D78FDC8B1BB3D8A78B@SSI.CORP> On Saturday, February 20, 2010, Joe Armstrong wrote: > When I write *any* process I always start with something like: > > loop(...) -> > receive > Any -> io:format("got:~p~n",[Any]), > loop(...) > end. Out of curiosity, why do you start with that and not: -behaviour(gen_server). init(_) -> {ok, []}. handle_info(Info, State) -> io:format("got:~p~n",[Info]), {noreply, State}. Obviously, the semantics are different and all, but I'd have thought if I were creating a process, I may as well make it a gen-server process so I don't have to retrofit it into that framework later. Cheers, David From vances@REDACTED Mon Feb 22 16:21:26 2010 From: vances@REDACTED (Vance Shipley) Date: Mon, 22 Feb 2010 10:21:26 -0500 Subject: [erlang-questions] net_kernel:handle_call In-Reply-To: <20100221174302.26e5c0b9@landofbile.com> References: <01489E237C2C8F45AF7898E135F48E8001DA64D146@NYWEXMBX2129.msad.ms.com> <6a3ae47e1002190807i6ffffc52x50f34aaa3e3947c2@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64D18E@NYWEXMBX2129.msad.ms.com> <20100221221347.GA85605@h216-235-12-174.host.egate.net> <20100221174302.26e5c0b9@landofbile.com> Message-ID: <20100222152126.GD85605@h216-235-12-174.host.egate.net> The documented interface to net_kernel does not define a direct use of gen_server:call/2 or a direct message passing interface. The client and server sides of the program are implemented in the same module. If the net_kernel server receives a message other than one it expects it is a programming error. On Sun, Feb 21, 2010 at 05:43:02PM -0500, bile@REDACTED wrote: } Your example is fine... but doesn't represent what is happening here. } Your code would cause the client to error... net_kernel, the server, is } dying in this case. We are talking about a major component of the } system which will bring down the entire system if you happen to send it } a message it doesn't understand. -- -Vance From attila.r.nohl@REDACTED Mon Feb 22 17:15:27 2010 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 22 Feb 2010 17:15:27 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <3dbc6d1c1002211725r3dc235d9g9985ce7bd229b900@mail.gmail.com> <8b9ee55b1002211832s7844c7fbv95dd3fd4d3ea6b38@mail.gmail.com> Message-ID: <401d3ba31002220815y3f7a932dw2f504ba8cf752db5@mail.gmail.com> 2010/2/22, Fred Hebert : [...] > I don't have much of a problem with -extend() myself, though. It permits a > very flat inheritance to modules, which can sometimes be useful. The > overriding rules are simple (if it's the same function, it replaces it, > otherwise, it looks in the extended module), there can only be one extended > module at once, etc. Ah, I should have known about this years ago, this could have save a lot of one liners or included source files for me... [...] > It's easy to argue that a callback module with a behavior would be much more > appropriate. Not only does it solve the problem mentioned in the previous > paragraph (the behavior needs to be compiled itself, there are fewer > ambiguities, etc.), but it is consequent with the development concepts > proposed by the OTP framework. I have a behaviour that's implemented in 19 modules. In 18 of the 19 modules one of the two functions in the behaviour simply returns ok. Granted, the function is a one liner (actually two, to adhere to our coding conventions), but with the additional stuff (documentation comments, export directives) it's 10 lines in each 18 files, so it's quite much unnecessary code... From dmercer@REDACTED Mon Feb 22 17:30:40 2010 From: dmercer@REDACTED (David Mercer) Date: Mon, 22 Feb 2010 10:30:40 -0600 Subject: [erlang-questions] reserved word guaranteed to be atom if single-quoted? In-Reply-To: References: Message-ID: <200F18BD65804F35B0B535A2C8D12DA3@SSI.CORP> On Sunday, February 21, 2010, Richard O'Keefe wrote: > (2) New keywords have been added to Erlang over time. > There is no reason to believe that we have the final set yet. > It would be nice if Erlang code could be "future-proofed". > One approach (which I've tried in a tokeniser, and seems to > work tolerably well) is that > - an identifier *immediately* followed by '(' is always a > plain function name > - an identifier preceded by one of > ( [ { , | ; -> = > and followed by one of > ) ] } , | ; -> = end > is always a plain atom even if it would otherwise be a keyword. If you're willing to go beyond just tweaking the lexer, you could use parsing logic like the following: When a keyword is reached, assume it is an atom. If parsing fails, back off to the last keyword which was assumed to be an atom and change your assumption to a keyword. Continue. The opposite logic also works (and also might be more efficient): When a keyword is reached, assume it is a keyword... This works with all reserved words except (I think) "catch", which can be indistinguishable from a function call. One solution to this might be to make catch a BIF as well. That being said, I know my proposed solution is more complicated than it looks, since it requires backtracking into the lexer, and may well complicate error messages somewhat. My first logic is probably less efficient (since most uses of reserved words are for their keyword meaning), but would likely result in better error messages (since the last error in that case will be based on the keyword interpretation). On the other hand, it could really screw up your error message if there was an earlier keyword correctly interpreted as an atom, which got reversed on review... Maybe ROK's approach is better. It just requires spaces after reserved words before parentheses, and prohibits spaces between invoked function names and their arguments. I.e., "frob (Arg)" would not be future-proof, since "frob" could later be declared a reserved word; "frob(Arg)" would be OK. Done rambling. Cheers, David From Antonio.Musumeci@REDACTED Mon Feb 22 18:14:26 2010 From: Antonio.Musumeci@REDACTED (Musumeci, Antonio S) Date: Mon, 22 Feb 2010 12:14:26 -0500 Subject: [erlang-questions] net_kernel:handle_call In-Reply-To: <20100222152126.GD85605@h216-235-12-174.host.egate.net> References: <01489E237C2C8F45AF7898E135F48E8001DA64D146@NYWEXMBX2129.msad.ms.com> <6a3ae47e1002190807i6ffffc52x50f34aaa3e3947c2@mail.gmail.com> <01489E237C2C8F45AF7898E135F48E8001DA64D18E@NYWEXMBX2129.msad.ms.com> <20100221221347.GA85605@h216-235-12-174.host.egate.net> <20100221174302.26e5c0b9@landofbile.com> <20100222152126.GD85605@h216-235-12-174.host.egate.net> Message-ID: <01489E237C2C8F45AF7898E135F48E8001FA72D65F@NYWEXMBX2129.msad.ms.com> I understand that. Others are the same however they are designed *not* to fail when sent spurious messages. Rex just doesn't reply for example. Erroring on the side of the client who made the mistake seems a lot more reasonable than killing the entire VM. There is a certain expectation of trust within the VM... Allowing anyone to just crash the entire system however seems excessive. -----Original Message----- From: Vance Shipley [mailto:vances@REDACTED] Sent: Monday, February 22, 2010 10:21 AM To: bile@REDACTED Cc: Musumeci, Antonio S (IT); Robert Raschke; erlang-questions@REDACTED Subject: Re: [erlang-questions] net_kernel:handle_call The documented interface to net_kernel does not define a direct use of gen_server:call/2 or a direct message passing interface. The client and server sides of the program are implemented in the same module. If the net_kernel server receives a message other than one it expects it is a programming error. On Sun, Feb 21, 2010 at 05:43:02PM -0500, bile@REDACTED wrote: } Your example is fine... but doesn't represent what is happening here. } Your code would cause the client to error... net_kernel, the server, is } dying in this case. We are talking about a major component of the } system which will bring down the entire system if you happen to send it } a message it doesn't understand. -- -Vance -------------------------------------------------------------------------- NOTICE: If received in error, please destroy, and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error. We may monitor and store emails to the extent permitted by applicable law. From g@REDACTED Mon Feb 22 18:36:14 2010 From: g@REDACTED (Garrett Smith) Date: Mon, 22 Feb 2010 11:36:14 -0600 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> Message-ID: On Sun, Feb 21, 2010 at 6:02 PM, Geoff Cant wrote: > Zubair Quraishi writes: > >> I disagree because the fact that parameterised modules are used only >> "internally" in OTP tells me that they "could" be removed. I say this >> because removing parameterised modules would not break any client libraries >> for OTP, as the internals of OTP could just be changed. >> >> Is there anyone from Ericcson who could shed light on this, or is it simply >> a "risk" to use parameterised modules? >> >> On Sun, Feb 21, 2010 at 12:25 PM, Rapsey wrote: >> >>> Not a large chance of that. It's used in a number of libraries including >>> OTP >>> internally. -snip- > We still have time to ditch them :) +1 I think the concept is fine, but if they take off they're going to bifurcate Erlang APIs into traditional API modules that take explicit process refs/state and this other breed that somehow gets by without them. Yuck! IMO, this meme (coupling state and behavior) is way too fundamental to have two major variants in a language. Garrett From zeno490@REDACTED Mon Feb 22 19:57:47 2010 From: zeno490@REDACTED (Nicholas Frechette) Date: Mon, 22 Feb 2010 13:57:47 -0500 Subject: Fwd: [erlang-questions] Re: What about making sense? In-Reply-To: References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> <4B7FE751.5080908@gmail.com> <9b08084c1002201002k1ffc01e9k676b01727588586b@mail.gmail.com> <1CF972F18EE046D78FDC8B1BB3D8A78B@SSI.CORP> Message-ID: ---------- Forwarded message ---------- From: Nicholas Frechette Date: Mon, Feb 22, 2010 at 1:56 PM Subject: Re: [erlang-questions] Re: What about making sense? To: David Mercer And here is perfect proof of why, in most cases, I object to pattern books and patterns in general: because most of the time, you don't need them. I write C++ for a living and it pains (physically and mentally, as I have to live every day with that code) me to see how abused the Singleton pattern is abused. (Probably, _The_ most abused pattern) When that book on OO patterns hit the world a few years back, I was doing Java and boy did people love that book. Pretty soon they were being used everywhere, and in far too many cases, they were being used where they shouldn't have been. It is a human/programmer mistake to always try to generalize everything when in reality, if you just need to get something done knowing well the scope of things, a simple approach would be best. Unfortunately, we all have a tendency to over plan and attempt to plan for everything that could conceptually happen in the foreseeable future. (I for one am guilty of this) Please, do not write an erlang pattern book, ever. We already have sufficient erlang patterns as it is, everything else can be worked up from there. Give a man a hammer, and he'll soon see nails everywhere. Do not get me mistaken, patterns are useful, just overly abused (as in the example below where the behavior always starts simple and in using a pattern, it over complicates things very quickly). Joe's book is fantastic and together with the online documentation for the various erlang patterns, it is sufficient imo. I started using erlang 6 months ago and am writing production software with it as I write this. Armed with Joe's book and the online documentation is more than one needs. Neither perfect, together sufficient. 2cents to be taken with grain of salt. On Mon, Feb 22, 2010 at 10:05 AM, David Mercer wrote: > On Saturday, February 20, 2010, Joe Armstrong wrote: > > > When I write *any* process I always start with something like: > > > > loop(...) -> > > receive > > Any -> io:format("got:~p~n",[Any]), > > loop(...) > > end. > > Out of curiosity, why do you start with that and not: > > -behaviour(gen_server). > > init(_) -> {ok, []}. > > handle_info(Info, State) -> > io:format("got:~p~n",[Info]), > {noreply, State}. > > Obviously, the semantics are different and all, but I'd have thought if I > were creating a process, I may as well make it a gen-server process so I > don't have to retrofit it into that framework later. > > Cheers, > > David > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From mikpe@REDACTED Mon Feb 22 20:15:35 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 22 Feb 2010 20:15:35 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <4B7FEA27.1020008@gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> Message-ID: <19330.55255.20059.563095@pilspetsen.it.uu.se> Garrett Smith writes: > > We still have time to ditch them :) > > +1 > > I think the concept is fine, but if they take off they're going to > bifurcate Erlang APIs into traditional API modules that take explicit > process refs/state and this other breed that somehow gets by without > them. Yuck! > > IMO, this meme (coupling state and behavior) is way too fundamental to > have two major variants in a language. The parameters in parametrized modules are no more about state than the free variables in function closures ('fun' expressions) are. From nem@REDACTED Mon Feb 22 20:27:40 2010 From: nem@REDACTED (Geoff Cant) Date: Mon, 22 Feb 2010 11:27:40 -0800 Subject: Programmatically starting a remote shell Message-ID: Hi all, I have something of an odd request - I want to start a remote shell programmatically from an escript. The escript will calculate the local and remote nodenames, setup distribution correctly and so on, but then it needs to start a remote shell and wait until the remote shell exits before the escript exits. I've had a bit of a look through the otp source but the only reference to remote shells I could find was deep in init.erl. Can someone give me a recipe or even just pointers on where to look? Cheers, -- Geoff Cant From g@REDACTED Mon Feb 22 21:05:06 2010 From: g@REDACTED (Garrett Smith) Date: Mon, 22 Feb 2010 14:05:06 -0600 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <19330.55255.20059.563095@pilspetsen.it.uu.se> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> Message-ID: On Mon, Feb 22, 2010 at 1:15 PM, Mikael Pettersson wrote: > Garrett Smith writes: > ?> > We still have time to ditch them :) > ?> > ?> +1 > ?> > ?> I think the concept is fine, but if they take off they're going to > ?> bifurcate Erlang APIs into traditional API modules that take explicit > ?> process refs/state and this other breed that somehow gets by without > ?> them. Yuck! > ?> > ?> IMO, this meme (coupling state and behavior) is way too fundamental to > ?> have two major variants in a language. > > The parameters in parametrized modules are no more about state than > the free variables in function closures ('fun' expressions) are. > Okay. Throw in the fact that you can call functions on a module that have access to these arguments and you have a coupling between these argument values and functionality. Sorry if "state" wasn't pedantic enough for you. My point is that this pattern is handled adequately without needing parameterized modules and to have two approaches for something this fundamental in a language is bad. I've observed practiced Erlang developers look sideways at mochiweb's Req:respond(...), look confused for a moment, and then conclude that it must be this unofficial feature called parameterized modules. What's the point of this? It's not unlike stumbling on the use of the process dictionary: "ah, *that's* how they're doing it!" IMO, this should be avoided wherever possible - and it's very avoidable in the case of parameterized modules. (Btw, I'm not even remotely slamming mochiweb here. It just happens to be the premiere example of this feature.) Garrett From kagato@REDACTED Mon Feb 22 21:19:44 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Mon, 22 Feb 2010 12:19:44 -0800 Subject: [erlang-questions] Programmatically starting a remote shell In-Reply-To: References: Message-ID: <988961A3-043E-47E1-B7A0-5F1942E6B9EB@souja.net> I know that you can do it from the command-line with -remsh , but that doesn't so much help from an escript. On Feb 22, 2010, at 11:27 AM, Geoff Cant wrote: > > Hi all, I have something of an odd request - I want to start a remote > shell programmatically from an escript. The escript will calculate the > local and remote nodenames, setup distribution correctly and so on, but > then it needs to start a remote shell and wait until the remote shell > exits before the escript exits. > > I've had a bit of a look through the otp source but the only reference > to remote shells I could find was deep in init.erl. Can someone give me > a recipe or even just pointers on where to look? > > Cheers, > -- > Geoff Cant > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- Jayson Vantuyl kagato@REDACTED From mevans@REDACTED Mon Feb 22 22:05:52 2010 From: mevans@REDACTED (Evans, Matthew) Date: Mon, 22 Feb 2010 16:05:52 -0500 Subject: Mnesia Crash Dump Message-ID: Hi, I have an mnesia core dump on a distributed Linux platform. The core appeared when I did an mnesia:start(). I'm wondering if mnesia didn't shutdown cleanly after the node was rebooted last. We have a Linux initrd script set at run-level 6 that attempts to do an mnesia:stop() via the erl_call utility. Maybe this failed or timed-out? What is the appropriate way to shutdown mnesia on a reboot of the node? Salient portions of the mnesia dump are below, the complete dump is available upon request (it's 153KB in size and I'd rather not fill-up all your inboxes). I guess I'd like to know how things got into this state, and what we can do to prevent it. Any suggestions would be helpful Many Thanks Matt {version,"4.4.11"}, {schema, {'EXIT', {badarg, [{ets,match_object,[schema,'_']}, {ets,tab2list,1}, {mnesia_lib,mkcore,1}, {mnesia_lib,fatal,2}, {mnesia_sp,init_proc,4}, {proc_lib,init_p_do_apply,3}]}}}, {gvar, {'EXIT', {badarg, [{ets,match_object,[mnesia_gvar,'_']}, {ets,tab2list,1}, {mnesia_lib,mkcore,1}, {mnesia_lib,fatal,2}, {mnesia_sp,init_proc,4}, {proc_lib,init_p_do_apply,3}]}}}, {master_nodes,[]}, ...... {workers, {'EXIT', {function_clause, [{mnesia_lib,workers,[{timeout,2000}]}, {mnesia_lib,mkcore,1}, {mnesia_lib,fatal,2}, {mnesia_sp,init_proc,4}, {proc_lib,init_p_do_apply,3}]}}}, {locking_procs, {'EXIT', {function_clause, [{mnesia_lib,locking_procs, [{'EXIT', {aborted, {badarg, [{mnesia_locker,get_held_locks,0}, {mnesia,system_info,1}, {mnesia_lib,mkcore,1}, {mnesia_lib,fatal,2}, {mnesia_sp,init_proc,4}, {proc_lib,init_p_do_apply,3}]}}}]}, {mnesia_lib,mkcore,1}, {mnesia_lib,fatal,2}, {mnesia_sp,init_proc,4}, {proc_lib,init_p_do_apply,3}]}}}, {held_locks, {'EXIT', {aborted, {badarg, [{mnesia_locker,get_held_locks,0}, {mnesia,system_info,1}, {mnesia_lib,mkcore,1}, {mnesia_lib,fatal,2}, {mnesia_sp,init_proc,4}, {proc_lib,init_p_do_apply,3}]}}}}, {lock_queue, {'EXIT', {aborted, {badarg, [{mnesia_locker,get_lock_queue,0}, {mnesia,system_info,1}, {mnesia_lib,mkcore,1}, {mnesia_lib,fatal,2}, {mnesia_sp,init_proc,4}, {proc_lib,init_p_do_apply,3}]}}}}, From fritchie@REDACTED Mon Feb 22 22:29:38 2010 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Mon, 22 Feb 2010 15:29:38 -0600 Subject: busy_dist_port: Who's seeing it? (Heh, who's bothered to look?) Message-ID: <26780.1266874178@snookles.snookles.com> In my searches of the erlang-questions postings that I've archived since 2003, there are zero messages that mention the 'busy_dist_port' phenomenon. See docs for erlang:system_monitor() for how to subscribe to 'busy_dist_port' and other VM events, such as long garbage collection pauses. I'll be sending a patch to erlang-patches shortly that would change the ERTS_DE_BUSY_LIMIT constant to something configurable. I'm very curious if anyone has other experience with 'busy_dist_port' events that play havoc with latencies in an inter-node-communication-heavy environment. Background: Say that I've got two Erlang nodes, running reasonably-modern multi-core x86_64 bit CPUs. There are two Erlang processes on each node, communicating with each other. Node foo@REDACTED "the net" Node foo@REDACTED ---------- ---------- <- one TCP connection -> Proc A Proc X Proc B Proc Y Proc C Proc Z ... many more ... many more Buried within the VM is a hardcoded constant called ERTS_DE_BUSY_LIMIT that limits the number of bytes that may be queued for the Erlang communication TCP socket between nodes. (More specifically, the Erlang port responsible for all communication between foo@REDACTED and foo@REDACTED). It's hardcoded at 128KB. I've got an app where something like this happens on Proc A: 1. receive hunks of data over time, buffering it in its private state 2. wait for some event (e.g. file:sync(), some event from the 'net) 3. send all the data over to Proc X via gen_server:cast(), one hunk per cast call. My problem is that the problem is that step #3 may have several megabytes of data to send to Proc X. Each time the 128KB limit is hit, Proc A is de-scheduled via by a 'busy_dist_port' event. It isn't runnable again until the distribution port is no longer busy. This causes really weird latency problems when the outside world, e.g. proc P on node bar@REDACTED, tries a synchronous gen_server:call() to Proc A. Huge variations of latency (jitter), sometimes many seconds worth (and *very* unpredictable). Bogus timeouts make Proc P very unhappy. Proc P is a "policeman", and if the policeman notices bad behavior, then it Calls Upon The Law and then Smites The Rogue Proc A For Unseemly (In)Activity That Looks Quite Like A Crash(*). But what if Proc A sent all the hunks to Proc B using only one gen_server:cast()? That doesn't solve much: if Proc A and Proc B are doing the same thing, then a single > 128KB cast by Proc A will still block Proc B's cast. Things only get likely with more procs sending to the same node. -Scott (*) For verily, the scriptures tell us, in an asynchronous network, you cannot tell the difference between a crashed peer and a merely very slow peer. From erlang@REDACTED Mon Feb 22 22:46:49 2010 From: erlang@REDACTED (Joe Armstrong) Date: Mon, 22 Feb 2010 22:46:49 +0100 Subject: [erlang-questions] Re: What about making sense? In-Reply-To: <1CF972F18EE046D78FDC8B1BB3D8A78B@SSI.CORP> References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> <4B7FE751.5080908@gmail.com> <9b08084c1002201002k1ffc01e9k676b01727588586b@mail.gmail.com> <1CF972F18EE046D78FDC8B1BB3D8A78B@SSI.CORP> Message-ID: <9b08084c1002221346u4486b603kf1f77628fd962087@mail.gmail.com> On Mon, Feb 22, 2010 at 4:05 PM, David Mercer wrote: > On Saturday, February 20, 2010, Joe Armstrong wrote: > >> When I write *any* process I always start with something like: >> >> loop(...) -> >> ? ? receive >> ? ? ? ? ?Any -> io:format("got:~p~n",[Any]), >> ? ? ? ? ?loop(...) >> ? ?end. > > Out of curiosity, why do you start with that and not: > > ? ? ? ?-behaviour(gen_server). > > ? ? ? ?init(_) -> {ok, []}. > > ? ? ? ?handle_info(Info, State) -> > ? ? ? ? ? ? ? ?io:format("got:~p~n",[Info]), > ? ? ? ? ? ? ? ?{noreply, State}. > > Obviously, the semantics are different and all, but I'd have thought if I > were creating a process, I may as well make it a gen-server process so I > don't have to retrofit it into that framework later. For most programs there is no later. Most of what I write is never used. In solving problems I try to identify "the most difficult part of the problem" and then solve it. I usually start by writing pure erlang code, with only calls to pure libraries (lists, sets etc) with no complex callback structure - then I see what patterns emerge, and then abstract *if necessary* introducing abstractions as I go along. Starting with gen_server pre-supposes that I want all the goodies offered by gen_server (code_change etc. calls and casts). Usually I only need global name registration and a simple RPC. I'm also trying to find new and useful abstractions, the process for doing this seems to be write raw erlang code - abstract and then generalise. So I usually start with raw Erlang mess around a bit and see what patterns emerge. When I start a new problem I have no idea what structures will emerge, so I absorb myself in the problem, and then let my subconscious get to work. Then I just wait and see what comes out when I start typing. Often really beautiful structures emerge from just typing in some solution to a problem (any solution) and then re-arranging the code until it looks pretty. If the code were every to make it into production code I'd then re-write it and fit it into more standard forms or invent custom abstractions if the standard forms were inappropriate. /Joe > > Cheers, > > David > > From jan@REDACTED Mon Feb 22 23:27:24 2010 From: jan@REDACTED (Jan Lehnardt) Date: Mon, 22 Feb 2010 14:27:24 -0800 (PST) Subject: Patch approval statistics for R13B04 In-Reply-To: <6672d0161002200239n40266c5ayd3b942e7c747a5d@mail.gmail.com> References: <6672d0161002200239n40266c5ayd3b942e7c747a5d@mail.gmail.com> Message-ID: <0d4516a7-7977-4f48-9b3b-725123760174@g28g2000prb.googlegroups.com> Bj?rn and Team, a big shout out from the CouchDB team on your open source work! Great job and keep it up! Cheers Jan -- On Feb 20, 2:39?am, Bj?rn Gustavsson wrote: > Now that R13B04 is feature-frozen, I can present > some statistics about the patches we have received. > > In the git repository, there are commits from 32 persons > from outside the Erlang/OTP group in the ccase/r13b04_dev > branch (i.e. to be included in R13B04). > > Manually counting through the "What's cooking" emails > sent to the erlang-patches mailing list, I got the following > statistics: > > Number of patches included in R13B04: 51 > Total number of dropped patches: 7 > Stalled patches: 5 > > Of the dropped patches, 4 pointed out bugs and > misfeatures that we chose to address in a different way. > One dropped patch updated a deprecated module. > > Two patches were dropped because we found > serious issues and the authors didn't submit > revised patches. > > Note that of the 51 approved patches, several went > through one more revisions by their authors to make > them OTP worthy before we approved them. > > Statistics can never predict the future, but it > seems that patches of good quality (OTP worthy) > will have a good chance to be included in future > OTP releases. > > Note that we never approve or reject unseen > patches. An idea that seems good when > explained in an email could turn out to have > issues when run through our test suites, > and conversely, an idea that seemed > bad maybe seemed bad only because > we didn't fully understand it. > > So instead of writing an email beforehand > explaining what your patch will do, I suggest that you > put the effort into a good commit message > that contains a good description of the problem > and/or use case, and a rationale to justify > the way you chose to solve it. That information > will speed up the reviewing process, and more > importantly, it will help anyone 5 years from > now to understand why the **** the change was > made. > > Thanks to everyone that have sent us patches > so far. I am looking forward to receiving many > more good patches. > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > Seehttp://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED From mikpe@REDACTED Mon Feb 22 23:53:05 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 22 Feb 2010 23:53:05 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <4ac8254d1002200714x28c69343jba5f6eaf9305fa08@mail.gmail.com> <94712d94-60ec-4d19-8854-1edca243cf85@u9g2000yqb.googlegroups.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> Message-ID: <19331.2769.995187.686294@pilspetsen.it.uu.se> Garrett Smith writes: > On Mon, Feb 22, 2010 at 1:15 PM, Mikael Pettersson wrote: > > Garrett Smith writes: > > ?> > We still have time to ditch them :) > > ?> > > ?> +1 > > ?> > > ?> I think the concept is fine, but if they take off they're going to > > ?> bifurcate Erlang APIs into traditional API modules that take explicit > > ?> process refs/state and this other breed that somehow gets by without > > ?> them. Yuck! > > ?> > > ?> IMO, this meme (coupling state and behavior) is way too fundamental to > > ?> have two major variants in a language. > > > > The parameters in parametrized modules are no more about state than > > the free variables in function closures ('fun' expressions) are. > > > > Okay. > > Throw in the fact that you can call functions on a module that have > access to these arguments and you have a coupling between these > argument values and functionality. Sorry if "state" wasn't pedantic > enough for you. I mentioned fun expressions for a reason, namely that they are pretty much the same as parametrized modules. Both constructs instantiate free variables at runtime, resulting in new first-class runtime values. They only differ in scope: one wraps a single anonymous function, the other wraps an entire module's worth of functions. By criticizing this coupling in the case of parametrized modules, you're effectively also criticizing fun expressions with free variables, aka lambdas, one of the cornerstones of functional programming. > My point is that this pattern is handled adequately without needing > parameterized modules and to have two approaches for something this > fundamental in a language is bad. I've observed practiced Erlang > developers look sideways at mochiweb's Req:respond(...), look confused > for a moment, and then conclude that it must be this unofficial > feature called parameterized modules. What's the point of this? It's > not unlike stumbling on the use of the process dictionary: "ah, > *that's* how they're doing it!" IMO, this should be avoided wherever > possible - and it's very avoidable in the case of parameterized > modules. I don't know that 'this pattern' and 'this fundamental' refer to, but mochiweb/OTP/gen_server/etc are just libraries. They use the Erlang language but do not define it. They can invent whatever APIs they like, however sane or insane, clear or confusing, old-fashined or bleeding-edge. You're not required to use them, and if sufficiently many agree with you better APIs will be created and the bad ones will die. End of problem. From bob@REDACTED Tue Feb 23 00:19:00 2010 From: bob@REDACTED (Bob Ippolito) Date: Mon, 22 Feb 2010 15:19:00 -0800 Subject: [JOB] Mochi Media, Inc. hiring in San Francisco, CA! Message-ID: <6a36e7291002221519w4533efdcy343e599c195688f9@mail.gmail.com> Mochi Media, Inc. is hiring immediately for several positions in San Francisco, CA to help grow our game platform empire. The Platform Engineer position involves writing a lot of Erlang code including work with mochiweb and Riak, so if you're interested you should definitely drop us a line here: http://www.mochimedia.com/jobs.html More general information about Mochi Media is at http://www.mochimedia.com/ and if you'd like to speak to a human immediately you can email me at bob@REDACTED -- I'm CTO and cofounder so I'd be more than happy to answer any questions that you may have :) -bob From g@REDACTED Tue Feb 23 00:35:29 2010 From: g@REDACTED (Garrett Smith) Date: Mon, 22 Feb 2010 17:35:29 -0600 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <19331.2769.995187.686294@pilspetsen.it.uu.se> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> <19331.2769.995187.686294@pilspetsen.it.uu.se> Message-ID: On Mon, Feb 22, 2010 at 4:53 PM, Mikael Pettersson wrote: > Garrett Smith writes: > ?> On Mon, Feb 22, 2010 at 1:15 PM, Mikael Pettersson wrote: > ?> > Garrett Smith writes: > ?> > ?> > We still have time to ditch them :) > ?> > ?> > ?> > ?> +1 > ?> > ?> > ?> > ?> I think the concept is fine, but if they take off they're going to > ?> > ?> bifurcate Erlang APIs into traditional API modules that take explicit > ?> > ?> process refs/state and this other breed that somehow gets by without > ?> > ?> them. Yuck! > ?> > ?> > ?> > ?> IMO, this meme (coupling state and behavior) is way too fundamental to > ?> > ?> have two major variants in a language. > ?> > > ?> > The parameters in parametrized modules are no more about state than > ?> > the free variables in function closures ('fun' expressions) are. > ?> > > ?> > ?> Okay. > ?> > ?> Throw in the fact that you can call functions on a module that have > ?> access to these arguments and you have a coupling between these > ?> argument values and functionality. Sorry if "state" wasn't pedantic > ?> enough for you. > > I mentioned fun expressions for a reason, namely that they are pretty > much the same as parametrized modules. Both constructs instantiate > free variables at runtime, resulting in new first-class runtime values. > They only differ in scope: one wraps a single anonymous function, the > other wraps an entire module's worth of functions. Good point. > By criticizing this coupling in the case of parametrized modules, > you're effectively also criticizing fun expressions with free variables, > aka lambdas, one of the cornerstones of functional programming. I'm not criticizing it in principle. I have personally chosen to not use parameterized modules primarily because they make my APIs look different from the rest of the OTP apps. Secondarily, I'm not a fan of the "free variables" they hide. And I haven't needed to. > ?> My point is that this pattern is handled adequately without needing > ?> parameterized modules and to have two approaches for something this > ?> fundamental in a language is bad. I've observed practiced Erlang > ?> developers look sideways at mochiweb's Req:respond(...), look confused > ?> for a moment, and then conclude that it must be this unofficial > ?> feature called parameterized modules. What's the point of this? It's > ?> not unlike stumbling on the use of the process dictionary: "ah, > ?> *that's* how they're doing it!" IMO, this should be avoided wherever > ?> possible - and it's very avoidable in the case of parameterized > ?> modules. > > I don't know that 'this pattern' and 'this fundamental' refer to, but > mochiweb/OTP/gen_server/etc are just libraries. They use the Erlang > language but do not define it. They can invent whatever APIs they like, > however sane or insane, clear or confusing, old-fashined or bleeding-edge. > You're not required to use them, and if sufficiently many agree with you > better APIs will be created and the bad ones will die. End of problem. > APIs die? Gosh I've seen not a few, really bad ones, live on and on. You may then be more comfortable with the range of naming and API "conventions" used in Erlang than I am. IMO, it makes it difficult to design an Erlang API because, at times, there's no clear/obvious cue from Erlang/OTP. It also makes it hard to remember things. There've been a few rants lately here on this topic. Of course, this is true of any language/framework/platform - it's impossible to tightly control every aspect of its evolution. This isn't even necessarily a problem. But the more "ways of doing something" there are in a system, the harder it is to learn that system, generally. I recognize this is not a universal, incontrovertible opinion :) Some developers prefer flexibility and like more language features. I tend to prefer fewer features/options provided I can get the job done. Garrett From rvirding@REDACTED Tue Feb 23 01:14:11 2010 From: rvirding@REDACTED (Robert Virding) Date: Tue, 23 Feb 2010 01:14:11 +0100 Subject: [erlang-questions] reserved word guaranteed to be atom if single-quoted? In-Reply-To: <200F18BD65804F35B0B535A2C8D12DA3@SSI.CORP> References: <200F18BD65804F35B0B535A2C8D12DA3@SSI.CORP> Message-ID: <3dbc6d1c1002221614he6e641bia7276a8ed860863@mail.gmail.com> On 22 February 2010 17:30, David Mercer wrote: > On Sunday, February 21, 2010, Richard O'Keefe wrote: > ... > > If you're willing to go beyond just tweaking the lexer, you could use > parsing logic like the following: > > ? ? ? ?When a keyword is reached, assume it is an atom. ?If parsing fails, > ? ? ? ?back off to the last keyword which was assumed to be an atom and > ? ? ? ?change your assumption to a keyword. ?Continue. > > The opposite logic also works (and also might be more efficient): > > ? ? ? ?When a keyword is reached, assume it is a keyword... > > This works with all reserved words except (I think) "catch", which can be > indistinguishable from a function call. ?One solution to this might be to > make catch a BIF as well. This is pretty much how prolog does it, except that prolog doesn't have reserved words but operators instead. In some places you first try and parse the input assuming the operator is an operator but if that doesn't work you backtrack and try again assuming it is a normal atom. However, this does not require backtracking in the lexer, it is all done in the parser. The lexer just returns an atom and it is the parser which recognises that this atom may actually be an operator and tries both cases. It is simpler in a way and more versatile but means the parser most likely cannot be automatically generated by a parser generator like yeec. If this can be done please let me know. Translating this to work with reserved words shouldn't pose any problems. Though you might a get weird results on old code if you add a new reserved word. Robert >> That being said, I know my proposed solution is more complicated than it > looks, since it requires backtracking into the lexer, and may well > complicate error messages somewhat. ?My first logic is probably less > efficient (since most uses of reserved words are for their keyword meaning), > but would likely result in better error messages (since the last error in > that case will be based on the keyword interpretation). ?On the other hand, > it could really screw up your error message if there was an earlier keyword > correctly interpreted as an atom, which got reversed on review... > > Maybe ROK's approach is better. ?It just requires spaces after reserved > words before parentheses, and prohibits spaces between invoked function > names and their arguments. ?I.e., "frob (Arg)" would not be future-proof, > since "frob" could later be declared a reserved word; "frob(Arg)" would be > OK. > > Done rambling. ?Cheers, > > David From tony@REDACTED Tue Feb 23 01:41:29 2010 From: tony@REDACTED (Tony Arcieri) Date: Mon, 22 Feb 2010 17:41:29 -0700 Subject: [erlang-questions] reserved word guaranteed to be atom if single-quoted? In-Reply-To: References: Message-ID: I've been surprised what strange places single quoted atoms work. Things like module names and record names. It's pretty spiffy. On Sat, Feb 20, 2010 at 1:50 AM, Michael Turner wrote: > Recently somebody tripped over "query" as a reserved word in Erlang, > and wondered what it was, and whether there were other reserved words > that were similarly obscure. > > And I've been tinkering with a style of argument passing where one might > write > > the_frob ({of, This_thing}, {within, That_other_thing}, ....) > > as a kind of poor man's syntactic sugar for the folks I'm writing my > code for (who aren't programmers, much less Erlang programmers, just > algorithm-specifiers). Of course, the Erlang parser complains about my > "of". > > Experiment shows that single-quoting seems to work, e.g., Erlang accepts > > {'of', 'query'}. > > But it doesn't return quite what I'd expect from the shell. I get back > > {'of', 'query'} > > where I expected > > {of, query} > > although I think this because some output pretty-printing metarule is > being applied here, like "output stuff in a way that's also acceptable > for input, to the extent reasonable." Certainly > > atom_to_list('of') > > reports what I *did* expect from the Erlang shell: "of", i.e., without > the single quotes. > > I'd like to submit a patch to the relevant part of the Data Types > section of the User's Manual, which currently reads as follows: > > ---- > An atom is a literal, a constant with name. An atom should be enclosed in > single quotes (') if it does not begin with a lower-case letter or if > it contains other characters than alphanumeric characters, underscore > (_), or @. > ---- > > That seems incomplete to me. I'd like to add, "or if it's an Erlang > reserved word", with a link to the list of reserved words. It doesn't > make sense to me that this single-quoting of reserved words would ever > fail in some future version, but I thought I'd ask, just to be sure. > > -michael turner > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > -- Tony Arcieri Medioh! A Kudelski Brand From igouy2@REDACTED Tue Feb 23 01:32:12 2010 From: igouy2@REDACTED (Isaac Gouy) Date: Mon, 22 Feb 2010 16:32:12 -0800 (PST) Subject: [erlang-questions] Sequential I/O access for large files in Erlang Message-ID: <682872.24444.qm@web65607.mail.ac4.yahoo.com> On Mon, 2010-02-22 at 11:58 +0100, Hynek Vychodil wrote: > If you want really fast IO you can use approach shown there > http://shootout.alioth.debian.org/u64q/program.php?test=regexdna?=hipe&id=6 > But don't forgot add -noinput parameter to erl. I have mentioned it in > mine contribution, it worked for a while and #6 version was there in > top list with ~60s, but they broke it without any warning. I have long > message exchange with Isaac Gouy > https://alioth.debian.org/tracker/index.php?func=detail&aid=312099 > before they accept it. It worked but they changed it again. I have > found it just now but I'm fed up with this arrogant moron and I will > not waste mine time trying fix it again. For anyone who is more interested in getting bugs fixed than venting personal abuse - when you see what you think is a bug, report a bug - http://shootout.alioth.debian.org/help.php#reportbugs From kaykay.unique@REDACTED Tue Feb 23 02:22:05 2010 From: kaykay.unique@REDACTED (Kay Kay) Date: Mon, 22 Feb 2010 17:22:05 -0800 Subject: [erlang-questions] Information Theory encoding algorithms library in erlang In-Reply-To: <9b08084c1002210721x25735dbbk924070dccd0495d3@mail.gmail.com> References: <4B7F62A4.7070201@gmail.com> <9b08084c1002210721x25735dbbk924070dccd0495d3@mail.gmail.com> Message-ID: <4B832DBD.4000007@gmail.com> On 2/21/10 7:21 AM, Joe Armstrong wrote: > I'm not aware of a single collection of several such algorithms though > I have seen > huffman etc in Erlang. > > Huffman was used in some paper to illustrate use of Erlang bit fields. > > I implemented gamma encoding at: > > http://github.com/joearms/elib1/blob/master/lib/src/elib1_gamma.erl > > This was taken straight out of Witten, Moffat and Bells's book > "Managing Gigabytes" > - this book is BTW - an excellent source for compression algorithms. > Thanks for the github link and the reference. Call it coincidence or not - this is one of the reference books that I am looking at implementing libraries and started the thread in the first place. > It would be nice > to implement all the compression algorithms in MG and put them into a > single library. > > Will do , once I get a working version. May be - I will put one up in github for peer review, once completed. > Erlang bit field matching makes this kind of code pretty simple - it > would be very nice > to see reference implementations in Erlang (and of error correction > codes, fountain codes anyone :-) > > Cheers > > /Joe > > > > On Sat, Feb 20, 2010 at 5:18 AM, Kay Kay wrote: > >> I am looking for some implementations of encoding algorithms ( huffmann etc. >> ) in erlang. Of course - using google / koders.com to figure out the bits >> and pieces , but curious to see if anybody has a repository / resource >> suggestion as a starting point for the same. I have the material that covers >> the appropriate theory but looking for specific implementations regarding >> the same. Thanks for the help. >> >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> >> From ok@REDACTED Tue Feb 23 02:54:38 2010 From: ok@REDACTED (Richard O'Keefe) Date: Tue, 23 Feb 2010 14:54:38 +1300 Subject: [erlang-questions] A sender() BIF? In-Reply-To: <33A39648E8D6FF438E3907E5396598E001C11278EC@NYWEXMBX2128.msad.ms.com> References: <4JyGEm7n.1266758439.0683540.leap@gol.com> <33A39648E8D6FF438E3907E5396598E001C11278EC@NYWEXMBX2128.msad.ms.com> Message-ID: <3B2D56CF-C766-4453-A4FE-858C0CC425D8@cs.otago.ac.nz> On Feb 23, 2010, at 3:24 AM, Keis, Andrei wrote: > I think the focus here should be on remote node authentication (and > network identity of the sender process) rather than reply pid, which > is part of the message data. Remote node authentication is the responsibility of the Erlang distribution protocol, though. If two nodes are connected, they trust each other. One of the recurring topics in this mailing list is that if you don't physically control the nodes in the network that are connecting to each other, you shouldn't be using the standard Erlang distribution protocol but should be rolling your own. And authentication is part of that. Given the existence of the 'rpc' module, if node N (aughty) wants to send something to node V (ictim), and the process on node V that N wants to attack is suspicious of foreign messages, all N has to do is create an agent on V and have _it_ send the message. What good will it do to know the "network identity of the sender process" in that case? In fact we have at least three ways that nodes might communicate: (little or no security) The built-in Erlang distribution protocol. Appropriate when you have physical control of the machines and the network linking them. (moderate security) Erlang distribution running over some other substrate such as SSL. (more security) Specific IP connections to specific ports using custom protocols with appropriate authentication. I don't think it is appropriate to hack on the fundamental machinery used within a node or trusted cluster (plain Erlang message passing) to satisfy the needs of less trusting applications. Not because there is anything wrong with security, but because once you are "in" with the Erlang distribution protocol, you are _totally_ in, and that's not how to get good security. > From dgud@REDACTED Tue Feb 23 08:30:52 2010 From: dgud@REDACTED (Dan Gudmundsson) Date: Tue, 23 Feb 2010 08:30:52 +0100 Subject: [erlang-questions] Mnesia Crash Dump In-Reply-To: References: Message-ID: <93df43b61002222330y31a9d279r46ab758d186f4582@mail.gmail.com> It seems that (all?) most of mnesia have stopped, since the ets tables are deleted, strange. You can send it to me, and I'll take a quick look at it. /Dan On Mon, Feb 22, 2010 at 10:05 PM, Evans, Matthew wrote: > Hi, > > I have an mnesia core dump on a distributed Linux platform. The core appeared when I did an mnesia:start(). > > I'm wondering if mnesia didn't shutdown cleanly after the node was rebooted last. We have a Linux initrd script set at run-level 6 that attempts to do an mnesia:stop() via the erl_call utility. Maybe this failed or timed-out? What is the appropriate way to shutdown mnesia on a reboot of the node? > > Salient portions of the mnesia dump are below, the complete dump is available upon request (it's 153KB in size and I'd rather not fill-up all your inboxes). I guess I'd like to know how things got into this state, and what we can do to prevent it. > > Any suggestions would be helpful > > Many Thanks > > Matt > > > > > {version,"4.4.11"}, > ?{schema, > ? ? {'EXIT', > ? ? ? ? {badarg, > ? ? ? ? ? ? [{ets,match_object,[schema,'_']}, > ? ? ? ? ? ? ?{ets,tab2list,1}, > ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, > ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, > ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, > ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}, > ?{gvar, > ? ? {'EXIT', > ? ? ? ? {badarg, > ? ? ? ? ? ? [{ets,match_object,[mnesia_gvar,'_']}, > ? ? ? ? ? ? ?{ets,tab2list,1}, > ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, > ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, > ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, > ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}, > ?{master_nodes,[]}, > > ...... > > > {workers, > ? ? {'EXIT', > ? ? ? ? {function_clause, > ? ? ? ? ? ? [{mnesia_lib,workers,[{timeout,2000}]}, > ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, > ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, > ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, > ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}, > ?{locking_procs, > ? ? {'EXIT', > ? ? ? ? {function_clause, > ? ? ? ? ? ? [{mnesia_lib,locking_procs, > ? ? ? ? ? ? ? ? ?[{'EXIT', > ? ? ? ? ? ? ? ? ? ? ? {aborted, > ? ? ? ? ? ? ? ? ? ? ? ? ? {badarg, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{mnesia_locker,get_held_locks,0}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{mnesia,system_info,1}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}]}, > ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, > ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, > ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, > ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}, > ?{held_locks, > ? ? {'EXIT', > ? ? ? ? {aborted, > ? ? ? ? ? ? {badarg, > ? ? ? ? ? ? ? ? [{mnesia_locker,get_held_locks,0}, > ? ? ? ? ? ? ? ? ?{mnesia,system_info,1}, > ? ? ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, > ? ? ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, > ? ? ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, > ? ? ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}}, > ?{lock_queue, > ? ? {'EXIT', > ? ? ? ? {aborted, > ? ? ? ? ? ? {badarg, > ? ? ? ? ? ? ? ? [{mnesia_locker,get_lock_queue,0}, > ? ? ? ? ? ? ? ? ?{mnesia,system_info,1}, > ? ? ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, > ? ? ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, > ? ? ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, > ? ? ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}}, > > > From micha-1@REDACTED Tue Feb 23 08:56:04 2010 From: micha-1@REDACTED (michael) Date: Tue, 23 Feb 2010 08:56:04 +0100 Subject: reading from named pipe Message-ID: <201002230856.04374.micha-1@fantasymail.de> When trying to open a named pipe ( allocated with mkfifo under linux) I get the error: {error,eisdir} How do I open such a pipe? The error message is somehow imprecise (or just wrong?): the file is not a directory. cheers Michael From chandrashekhar.mullaparthi@REDACTED Tue Feb 23 10:47:39 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Tue, 23 Feb 2010 09:47:39 +0000 Subject: [erlang-questions] Mnesia Crash Dump In-Reply-To: <93df43b61002222330y31a9d279r46ab758d186f4582@mail.gmail.com> References: <93df43b61002222330y31a9d279r46ab758d186f4582@mail.gmail.com> Message-ID: Hi Dan, On 23 February 2010 07:30, Dan Gudmundsson wrote: > It seems that (all?) most of mnesia have stopped, since the ets tables > are deleted, strange. I had a look at the crash dump. It looks like the schema was changed on one of the nodes in isolation (new schema created), so this node crashed at startup because schema cookies didn't match. cheers Chandru > > You can send it to me, and I'll take a quick look at it. > > /Dan > > On Mon, Feb 22, 2010 at 10:05 PM, Evans, Matthew wrote: >> Hi, >> >> I have an mnesia core dump on a distributed Linux platform. The core appeared when I did an mnesia:start(). >> >> I'm wondering if mnesia didn't shutdown cleanly after the node was rebooted last. We have a Linux initrd script set at run-level 6 that attempts to do an mnesia:stop() via the erl_call utility. Maybe this failed or timed-out? What is the appropriate way to shutdown mnesia on a reboot of the node? >> >> Salient portions of the mnesia dump are below, the complete dump is available upon request (it's 153KB in size and I'd rather not fill-up all your inboxes). I guess I'd like to know how things got into this state, and what we can do to prevent it. >> >> Any suggestions would be helpful >> >> Many Thanks >> >> Matt >> >> >> >> >> {version,"4.4.11"}, >> ?{schema, >> ? ? {'EXIT', >> ? ? ? ? {badarg, >> ? ? ? ? ? ? [{ets,match_object,[schema,'_']}, >> ? ? ? ? ? ? ?{ets,tab2list,1}, >> ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, >> ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, >> ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, >> ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}, >> ?{gvar, >> ? ? {'EXIT', >> ? ? ? ? {badarg, >> ? ? ? ? ? ? [{ets,match_object,[mnesia_gvar,'_']}, >> ? ? ? ? ? ? ?{ets,tab2list,1}, >> ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, >> ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, >> ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, >> ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}, >> ?{master_nodes,[]}, >> >> ...... >> >> >> {workers, >> ? ? {'EXIT', >> ? ? ? ? {function_clause, >> ? ? ? ? ? ? [{mnesia_lib,workers,[{timeout,2000}]}, >> ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, >> ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, >> ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, >> ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}, >> ?{locking_procs, >> ? ? {'EXIT', >> ? ? ? ? {function_clause, >> ? ? ? ? ? ? [{mnesia_lib,locking_procs, >> ? ? ? ? ? ? ? ? ?[{'EXIT', >> ? ? ? ? ? ? ? ? ? ? ? {aborted, >> ? ? ? ? ? ? ? ? ? ? ? ? ? {badarg, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? [{mnesia_locker,get_held_locks,0}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{mnesia,system_info,1}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}]}, >> ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, >> ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, >> ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, >> ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}, >> ?{held_locks, >> ? ? {'EXIT', >> ? ? ? ? {aborted, >> ? ? ? ? ? ? {badarg, >> ? ? ? ? ? ? ? ? [{mnesia_locker,get_held_locks,0}, >> ? ? ? ? ? ? ? ? ?{mnesia,system_info,1}, >> ? ? ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, >> ? ? ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, >> ? ? ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, >> ? ? ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}}, >> ?{lock_queue, >> ? ? {'EXIT', >> ? ? ? ? {aborted, >> ? ? ? ? ? ? {badarg, >> ? ? ? ? ? ? ? ? [{mnesia_locker,get_lock_queue,0}, >> ? ? ? ? ? ? ? ? ?{mnesia,system_info,1}, >> ? ? ? ? ? ? ? ? ?{mnesia_lib,mkcore,1}, >> ? ? ? ? ? ? ? ? ?{mnesia_lib,fatal,2}, >> ? ? ? ? ? ? ? ? ?{mnesia_sp,init_proc,4}, >> ? ? ? ? ? ? ? ? ?{proc_lib,init_p_do_apply,3}]}}}}, >> >> >> > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From bengt.kleberg@REDACTED Tue Feb 23 11:02:41 2010 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 23 Feb 2010 11:02:41 +0100 Subject: [erlang-questions] reading from named pipe In-Reply-To: <201002230856.04374.micha-1@fantasymail.de> References: <201002230856.04374.micha-1@fantasymail.de> Message-ID: <1266919361.4820.8.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Greetings, To my knowledge it is not possible to open a named pipe directly. There might be a port program that ca do it for you. bengt On Tue, 2010-02-23 at 08:56 +0100, michael wrote: > When trying to open a named pipe ( allocated with mkfifo under linux) I get the > error: > {error,eisdir} > > How do I open such a pipe? > > The error message is somehow imprecise (or just wrong?): the file is not a > directory. > > cheers > Michael > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From john.hughes@REDACTED Tue Feb 23 11:31:08 2010 From: john.hughes@REDACTED (John Hughes) Date: Tue, 23 Feb 2010 11:31:08 +0100 Subject: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> <19331.2769.995187.686294@pilspetsen.it.uu.se> Message-ID: <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> We use parameterised modules occasionally in the internals of QuickCheck. The reason is that we need to supply a call-back module implementing a behaviour to a generic module like gen_server or gen_fsm, and the callback module needs access to parameters that aren't fixed. So we use a parameterised call-back module and pass that to the generic one. This is the same kind of example that motivated Richard Carlsson's paper in the first place... and there isn't any other good way of solving the problem. Making the parameterised module into a gen_server instead, which has been suggested, isn't a good solution in this case because it's not reentrant--you can then only have one "instance" of the parameterised module at a time. What if you need more? Taking parameterised modules out of the language would cause us significant pain. John On Mon, Feb 22, 2010 at 4:53 PM, Mikael Pettersson wrote: > Garrett Smith writes: > > On Mon, Feb 22, 2010 at 1:15 PM, Mikael Pettersson > > wrote: > > > Garrett Smith writes: > > > > > We still have time to ditch them :) > > > > > > > > +1 > > > > > > > > I think the concept is fine, but if they take off they're going to > > > > bifurcate Erlang APIs into traditional API modules that take > > > > explicit > > > > process refs/state and this other breed that somehow gets by without > > > > them. Yuck! > > > > > > > > IMO, this meme (coupling state and behavior) is way too fundamental > > > > to > > > > have two major variants in a language. > > > > > > The parameters in parametrized modules are no more about state than > > > the free variables in function closures ('fun' expressions) are. > > > > > > > Okay. > > > > Throw in the fact that you can call functions on a module that have > > access to these arguments and you have a coupling between these > > argument values and functionality. Sorry if "state" wasn't pedantic > > enough for you. > > I mentioned fun expressions for a reason, namely that they are pretty > much the same as parametrized modules. Both constructs instantiate > free variables at runtime, resulting in new first-class runtime values. > They only differ in scope: one wraps a single anonymous function, the > other wraps an entire module's worth of functions. From ulf.wiger@REDACTED Tue Feb 23 12:09:24 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 23 Feb 2010 12:09:24 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> <19331.2769.995187.686294@pilspetsen.it.uu.se> <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> Message-ID: <4B83B764.8020002@erlang-solutions.com> John Hughes wrote: > We use parameterised modules occasionally in the internals of > QuickCheck. The reason is that we need to supply a call-back module > implementing a behaviour to a generic module like gen_server or gen_fsm, > and the callback module needs access to parameters that aren't fixed. So > we use a parameterised call-back module and pass that to the generic > one. This is the same kind of example that motivated Richard Carlsson's > paper in the first place... and there isn't any other good way of > solving the problem. Making the parameterised module into a gen_server > instead, which has been suggested, isn't a good solution in this case > because it's not reentrant--you can then only have one "instance" of the > parameterised module at a time. What if you need more? For basically the same reason I used parameterized modules extensively in Erlhive. Now, Erlhive doesn't have a huge community (by any definition of huge), but parameterized modules fit the problem very well. The problem there was that I needed to momentarily "fix" some parts of the environment so that they couldn't be changed or subverted, while still beingaccessible in a way that was very fast, and also reentrant. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From koops.j@REDACTED Tue Feb 23 12:19:49 2010 From: koops.j@REDACTED (Jeroen Koops) Date: Tue, 23 Feb 2010 12:19:49 +0100 Subject: Unexpected try/catch behaviour Message-ID: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> Here's a quick questions for the try/catch illuminati: The following: try throw(my_error) catch throw:What -> { error, What } end. produces { error, my_error } as expected. This: try case true of true -> throw(my_error) end catch throw:What -> { error, What } end. also gives me { error, my_error }. But this: try true of true -> throw(my_error) catch throw:What -> { error, What } end. does not catch the exception and gives me, from the shell: ** exception throw: my_error Is that logical in a way I don't see? Thanks, Jeroen From ulf.wiger@REDACTED Tue Feb 23 12:28:56 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 23 Feb 2010 12:28:56 +0100 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> Message-ID: <4B83BBF8.2020406@erlang-solutions.com> Jeroen Koops wrote: > > But this: > > try true of > true -> throw(my_error) > catch > throw:What -> { error, What } > end. > > does not catch the exception and gives me, from the shell: ** exception > throw: my_error > > Is that logical in a way I don't see? From the Erlang Reference Manual: "try Exprs of Pattern1 [when GuardSeq1] -> Body1; ...; PatternN [when GuardSeqN] -> BodyN catch [Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] -> ExceptionBody1; ...; [ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] -> ExceptionBodyN end ... An exception occurring during the evaluation of Body is not caught." BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From attila.r.nohl@REDACTED Tue Feb 23 12:36:05 2010 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Tue, 23 Feb 2010 12:36:05 +0100 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <4B83BBF8.2020406@erlang-solutions.com> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> Message-ID: <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> 2010/2/23, Ulf Wiger : [...] > From the Erlang Reference Manual: > > "try Exprs of > Pattern1 [when GuardSeq1] -> > Body1; > ...; > PatternN [when GuardSeqN] -> > BodyN > catch > [Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] -> > ExceptionBody1; > ...; > [ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] -> > ExceptionBodyN > end > ... > > An exception occurring during the evaluation of Body is not caught." This is um, surprising, even by the standards of Erlang... I mean not the documentation, but the actual language construct. From koops.j@REDACTED Tue Feb 23 12:39:37 2010 From: koops.j@REDACTED (Jeroen Koops) Date: Tue, 23 Feb 2010 12:39:37 +0100 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <4B83BBF8.2020406@erlang-solutions.com> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> Message-ID: <331a9abb1002230339v774fe2a9g27a475a97ecebf@mail.gmail.com> >From the Erlang Reference Manual: > > "try Exprs of > Pattern1 [when GuardSeq1] -> > Body1; > ...; > PatternN [when GuardSeqN] -> > BodyN > catch > [Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] -> > ExceptionBody1; > ...; > [ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] -> > ExceptionBodyN > end > ... > > An exception occurring during the evaluation of Body is not caught." > > I see. I always considered the try Expr of ... catch construction to be a shortcut for try case Expr of ... end catch, but in this regard it isn't, apparently. Thanks, Jeroen From twoggle@REDACTED Tue Feb 23 13:32:15 2010 From: twoggle@REDACTED (Tim Fletcher) Date: Tue, 23 Feb 2010 04:32:15 -0800 (PST) Subject: Will parameterized modules become an official part of Erlang? In-Reply-To: <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> <19331.2769.995187.686294@pilspetsen.it.uu.se> <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> Message-ID: <6493bf0f-d26e-49f8-901b-5a6b49c90fce@o5g2000vbb.googlegroups.com> > The reason is that we need to supply a call-back module implementing a > behaviour to a generic module like gen_server or gen_fsm, and the callback > module needs access to parameters that aren't fixed. So we use a > parameterised call-back module and pass that to the generic one. This is the > same kind of example that motivated Richard Carlsson's paper in the first > place... and there isn't any other good way of solving the problem. Making > the parameterised module into a gen_server instead, which has been > suggested, isn't a good solution in this case because it's not > reentrant--you can then only have one "instance" of the parameterised module > at a time. What if you need more? I'm not sure I fully understand all of this, but couldn't you just spawn more servers/processes? If the gen_server callback interface was specified in terms of messages instead of function calls, then all it would depend on is a process that implements that message interface. You could either use a single callback process with several servers, or one process for each server. You could even chain together several processes to extend/wrap existing behaviour. Taking the example from Richard's paper, module A would call module C to start a new callback process, and then pass that reference to module B to configure the callback behaviour. I'm probably being naive about concurrency issues... what am i missing? Tim From luismarianoguerra@REDACTED Tue Feb 23 13:38:39 2010 From: luismarianoguerra@REDACTED (Mariano Guerra) Date: Tue, 23 Feb 2010 13:38:39 +0100 Subject: information about interactive console implementation Message-ID: where can I read information about how the erlang interactive console is implemented? From zubairq@REDACTED Tue Feb 23 13:42:42 2010 From: zubairq@REDACTED (Zubair Quraishi) Date: Tue, 23 Feb 2010 13:42:42 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <6493bf0f-d26e-49f8-901b-5a6b49c90fce@o5g2000vbb.googlegroups.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> <19331.2769.995187.686294@pilspetsen.it.uu.se> <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> <6493bf0f-d26e-49f8-901b-5a6b49c90fce@o5g2000vbb.googlegroups.com> Message-ID: <36a929df1002230442g3c8581afwdb06ea91fc01c7a2@mail.gmail.com> If Joe Armstrong is using parameterised modules in Erlhive, then surely they will become part of the standard? From lovei.laszlo@REDACTED Tue Feb 23 13:50:33 2010 From: lovei.laszlo@REDACTED (Laszlo Lovei) Date: Tue, 23 Feb 2010 04:50:33 -0800 (PST) Subject: Unexpected try/catch behaviour In-Reply-To: <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> Message-ID: <3e362404-3474-48b5-8df9-bf034c9b41f0@j6g2000vbd.googlegroups.com> On Feb 23, 12:36?pm, Attila Rajmund Nohl wrote: > > This is um, surprising, even by the standards of Erlang... It is quite consistent with the standards of Erlang, that is, you have to know the historic background to understand the reasons: http://www.erlang.org/workshop/2004/exception.pdf Laszlo From john.hughes@REDACTED Tue Feb 23 14:55:04 2010 From: john.hughes@REDACTED (John Hughes) Date: Tue, 23 Feb 2010 14:55:04 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: <6493bf0f-d26e-49f8-901b-5a6b49c90fce@o5g2000vbb.googlegroups.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> <19331.2769.995187.686294@pilspetsen.it.uu.se> <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> <6493bf0f-d26e-49f8-901b-5a6b49c90fce@o5g2000vbb.googlegroups.com> Message-ID: >> The reason is that we need to supply a call-back module implementing a >> behaviour to a generic module like gen_server or gen_fsm, and the >> callback >> module needs access to parameters that aren't fixed. So we use a >> parameterised call-back module and pass that to the generic one. This is >> the >> same kind of example that motivated Richard Carlsson's paper in the first >> place... and there isn't any other good way of solving the problem. >> Making >> the parameterised module into a gen_server instead, which has been >> suggested, isn't a good solution in this case because it's not >> reentrant--you can then only have one "instance" of the parameterised >> module >> at a time. What if you need more? > > I'm not sure I fully understand all of this, but couldn't you just > spawn more servers/processes? Well, no. I'm assuming a situation in which a generic module is fixed... maybe it's gen_server or gen_fsm in the OTP libraries, or maybe it's the eqc_statem module we use for testing state machines with QuickCheck. In either case, the generic code contains calls to callback functions which look like M:handle_call(...Params...), where M is the module name I pass in. I'm not going to change those calls--they're part of the published interface of the generic module. Now, when I use a parameterised module, then M will be something like my_parameterised_module:new(ModuleParams), and of course I can construct M1 = my_parameterised_module:new(ModuleParams1), M2 = my_parameterised_module:new(ModuleParams2), M3 = my_parameterised_module:new(ModuleParams3) and use them all at the same time. If my parameterised module implements the gen_server behaviour, for example, then I could create servers running the same code with different ModuleParams at the same time. What happens implicitly is that the value of M1 for example is a tuple {my_parameterised_module,ModuleParams1}, so the module parameters are carried with the module name to the point of call in the generic code. Now the idea of replacing a parameterised module by a gen_server is based on saving the ModuleParams as the state of the server, so that they don't need to be supplied on each call. So now I can just call my_parameterised_module:foo() instead of M1:foo(), and the foo function can pick up ModuleParams1 from the server state. Of course, I could spawn several processes all running the same code with different states--but how would I tell the generic code which process to talk to? All I can do is pass in my_parameterised_module as the module name, then generic code will call my foo function, and then I have to somehow figure out which process to talk to, in order to pick up the right state. There's no information available to enable me to do so. That's why this idea works fine for a single process (just register it with the module name), but fails as soon as you want to support multiple instances. I think you're imagining changing the calls in the generic code--passing a Pid as an extra argument, for example. Of course, if you do that, then you can use multiple processes to represent multiple instances. But now you're not reusing the generic code any more. With parameterised modules, we don't NEED to change the generic code at all, which is a big advantage. John From rvirding@REDACTED Tue Feb 23 15:49:03 2010 From: rvirding@REDACTED (Robert Virding) Date: Tue, 23 Feb 2010 15:49:03 +0100 Subject: [erlang-questions] Re: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> <19331.2769.995187.686294@pilspetsen.it.uu.se> <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> <6493bf0f-d26e-49f8-901b-5a6b49c90fce@o5g2000vbb.googlegroups.com> Message-ID: <3dbc6d1c1002230649k31db0104g9f8c870b17a276cd@mail.gmail.com> There is one thing I don't understand here. For a gen_server or gen_fsm why can't you just put the module parameters, or there values at least, into the state parameter the gen_server passes around for you. I don't feel it would be so much more difficult to use that it would warrant a whole new feature. And it would allow you to change it. Of course I may have missed something here, Robert On 23 February 2010 14:55, John Hughes wrote: > > >>> The reason is that we need to supply a call-back module implementing a >>> behaviour to a generic module like gen_server or gen_fsm, and the >>> callback >>> module needs access to parameters that aren't fixed. So we use a >>> parameterised call-back module and pass that to the generic one. This is >>> the >>> same kind of example that motivated Richard Carlsson's paper in the first >>> place... and there isn't any other good way of solving the problem. >>> Making >>> the parameterised module into a gen_server instead, which has been >>> suggested, isn't a good solution in this case because it's not >>> reentrant--you can then only have one "instance" of the parameterised >>> module >>> at a time. What if you need more? >> >> I'm not sure I fully understand all of this, but couldn't you just >> spawn more servers/processes? > > Well, no. > > I'm assuming a situation in which a generic module is fixed... maybe it's > gen_server or gen_fsm in the OTP libraries, or maybe it's the eqc_statem > module we use for testing state machines with QuickCheck. In either case, > the generic code contains calls to callback functions which look like > M:handle_call(...Params...), where M is the module name I pass in. I'm not > going to change those calls--they're part of the published interface of the > generic module. > > Now, when I use a parameterised module, then M will be something like > my_parameterised_module:new(ModuleParams), and of course I can construct > > ? M1 = my_parameterised_module:new(ModuleParams1), > ? M2 = my_parameterised_module:new(ModuleParams2), > ? M3 = my_parameterised_module:new(ModuleParams3) > > and use them all at the same time. If my parameterised module implements the > gen_server behaviour, for example, then I could create servers running the > same code with different ModuleParams at the same time. What happens > implicitly is that the value of M1 for example is a tuple > {my_parameterised_module,ModuleParams1}, so the module parameters are > carried with the module name to the point of call in the generic code. > > Now the idea of replacing a parameterised module by a gen_server is based on > saving the ModuleParams as the state of the server, so that they don't need > to be supplied on each call. So now I can just call > my_parameterised_module:foo() instead of M1:foo(), and the foo function can > pick up ModuleParams1 from the server state. Of course, I could spawn > several processes all running the same code with different states--but how > would I tell the generic code which process to talk to? All I can do is pass > in my_parameterised_module as the module name, then generic code will call > my foo function, and then I have to somehow figure out which process to talk > to, in order to pick up the right state. There's no information available to > enable me to do so. That's why this idea works fine for a single process > (just register it with the module name), but fails as soon as you want to > support multiple instances. > > I think you're imagining changing the calls in the generic code--passing a > Pid as an extra argument, for example. Of course, if you do that, then you > can use multiple processes to represent multiple instances. But now you're > not reusing the generic code any more. With parameterised modules, we don't > NEED to change the generic code at all, which is a big advantage. > > John > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From john.hughes@REDACTED Tue Feb 23 16:18:22 2010 From: john.hughes@REDACTED (John Hughes) Date: Tue, 23 Feb 2010 16:18:22 +0100 Subject: Will parameterized modules become an official part of Erlang? In-Reply-To: <3dbc6d1c1002230649k31db0104g9f8c870b17a276cd@mail.gmail.com> References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> <19331.2769.995187.686294@pilspetsen.it.uu.se> <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> <6493bf0f-d26e-49f8-901b-5a6b49c90fce@o5g2000vbb.googlegroups.com> <3dbc6d1c1002230649k31db0104g9f8c870b17a276cd@mail.gmail.com> Message-ID: <268DB98CB2C94F6DB2919236ED7C2304@JohnsTablet2009> There is one thing I don't understand here. For a gen_server or gen_fsm why can't you just put the module parameters, or there values at least, into the state parameter the gen_server passes around for you. I don't feel it would be so much more difficult to use that it would warrant a whole new feature. And it would allow you to change it. Of course I may have missed something here, Robert Hmmm. Well, I'm really thinking of our eqc_statem module. That also passes a state around for you, just as gen_server does. But it also initialises the state for you, using an initial_state() callback in your module. It's that initialisation that's the problem--if only you could make the initial_state() callback return a state containing your module parameters, then you'd be fine... but you can't, or at least I can't think how to without using side-effects in some form. Actually, we have another way of setting the initial state which WOULD enable one to get those parameters in there... but QuickCheck users would need to actually do this explicitly, which would complicate the interface somewhat. Then again I don't WANT to complicate the state with internal QuickCheck information (because users see it). So I guess one could make this idea work, but it wouldn't be as smooth to use as the solution based on parameterized modules. John On 23 February 2010 14:55, John Hughes wrote: > > >>> The reason is that we need to supply a call-back module implementing a >>> behaviour to a generic module like gen_server or gen_fsm, and the >>> callback >>> module needs access to parameters that aren't fixed. So we use a >>> parameterised call-back module and pass that to the generic one. This is >>> the >>> same kind of example that motivated Richard Carlsson's paper in the first >>> place... and there isn't any other good way of solving the problem. >>> Making >>> the parameterised module into a gen_server instead, which has been >>> suggested, isn't a good solution in this case because it's not >>> reentrant--you can then only have one "instance" of the parameterised >>> module >>> at a time. What if you need more? >> >> I'm not sure I fully understand all of this, but couldn't you just >> spawn more servers/processes? > > Well, no. > > I'm assuming a situation in which a generic module is fixed... maybe it's > gen_server or gen_fsm in the OTP libraries, or maybe it's the eqc_statem > module we use for testing state machines with QuickCheck. In either case, > the generic code contains calls to callback functions which look like > M:handle_call(...Params...), where M is the module name I pass in. I'm not > going to change those calls--they're part of the published interface of the > generic module. > > Now, when I use a parameterised module, then M will be something like > my_parameterised_module:new(ModuleParams), and of course I can construct > > M1 = my_parameterised_module:new(ModuleParams1), > M2 = my_parameterised_module:new(ModuleParams2), > M3 = my_parameterised_module:new(ModuleParams3) > > and use them all at the same time. If my parameterised module implements the > gen_server behaviour, for example, then I could create servers running the > same code with different ModuleParams at the same time. What happens > implicitly is that the value of M1 for example is a tuple > {my_parameterised_module,ModuleParams1}, so the module parameters are > carried with the module name to the point of call in the generic code. > > Now the idea of replacing a parameterised module by a gen_server is based on > saving the ModuleParams as the state of the server, so that they don't need > to be supplied on each call. So now I can just call > my_parameterised_module:foo() instead of M1:foo(), and the foo function can > pick up ModuleParams1 from the server state. Of course, I could spawn > several processes all running the same code with different states--but how > would I tell the generic code which process to talk to? All I can do is pass > in my_parameterised_module as the module name, then generic code will call > my foo function, and then I have to somehow figure out which process to talk > to, in order to pick up the right state. There's no information available to > enable me to do so. That's why this idea works fine for a single process > (just register it with the module name), but fails as soon as you want to > support multiple instances. > > I think you're imagining changing the calls in the generic code--passing a > Pid as an extra argument, for example. Of course, if you do that, then you > can use multiple processes to represent multiple instances. But now you're > not reusing the generic code any more. With parameterised modules, we don't > NEED to change the generic code at all, which is a big advantage. > > John > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED From launoja@REDACTED Tue Feb 23 13:50:31 2010 From: launoja@REDACTED (Jani Launonen) Date: Tue, 23 Feb 2010 14:50:31 +0200 Subject: [CLARIFY]: starting application as permanent and takeover frequency Message-ID: Hello, Is there way to start an application as permanent other than directly by application:start(Application, permanent)? I couldn't find a way to put 'permanent' to .app or .config files to make application controller start the application as permanent. Nor can one seem to give permanent option directly as command line argument. The way I thought to start an application as permanent from command line was to introduce extra starting function to application_app.erl file, which in turn calls application:start(Application, permanent). This seems to work nicely from command line, but aren't there way to give this option in configuration files? Apparently one can hack the .script file as in http://www.lshift.net/blog/2009/09/30/erlang-otp-boot-files-for-fun-and-profit but that seems bit tedious and requires doing (and understanding) the whole release cycle. Perhaps it would be time to study the release tutorial in more depth. Now, after starting application as permanent, suppose I want it to be distributed as shown in Ulf's release tutorial. Let's further assume that I've hacked the .script file so that the node taking over starts the application as permanent too. Now, say that there's an external service (possibly replicated, but could still be unavailable) that our application connects to. If the connection is lost, our application tries to resolve the situation by restarting itself. If the connection cannot be restored after few restarts the application finally dies if the restart frequency is exceeded. I suppose, at that moment the dist_ac starts the application in another node and the process repeats if the connection is not established. Will this result in ping-pong with the nodes, if the nodes are restarted by heart after crash? Feel free to point me to documentation if I've missed something, but further ideas for implementing HA application would be greatly appreciated! Cheers, Jani Launonen From twoggle@REDACTED Tue Feb 23 17:13:28 2010 From: twoggle@REDACTED (Tim Fletcher) Date: Tue, 23 Feb 2010 08:13:28 -0800 (PST) Subject: Will parameterized modules become an official part of Erlang? In-Reply-To: References: <36a929df1002181240u570c679dve4e6636386989bed@mail.gmail.com> <36a929df1002210312x2eb544aag5205226277bac2bb@mail.gmail.com> <97619b171002210325q82561eapafe6f7f5e8b26747@mail.gmail.com> <36a929df1002210348w27656323t4a135665ec8e07c4@mail.gmail.com> <19330.55255.20059.563095@pilspetsen.it.uu.se> <19331.2769.995187.686294@pilspetsen.it.uu.se> <07D518B7C29A4E85B7DF72FF7E9E308E@HALL> <6493bf0f-d26e-49f8-901b-5a6b49c90fce@o5g2000vbb.googlegroups.com> Message-ID: <00101362-e452-4820-bd1a-7ea490fb198b@d34g2000vbl.googlegroups.com> > Now the idea of replacing a parameterised module by a gen_server is based on > saving the ModuleParams as the state of the server, so that they don't need > to be supplied on each call. I didn't quite understand the mechanics of this idea from your previous message, but the clarification helps, thank you. > I think you're imagining changing the calls in the generic code--passing a > Pid as an extra argument, for example. Of course, if you do that, then you > can use multiple processes to represent multiple instances. But now you're > not reusing the generic code any more. Correct, I was considering the hypothetical, albeit not too practical "let's re-implement gen_server et al" approach :) > With parameterised modules, we don't > NEED to change the generic code at all, which is a big advantage. Except that you had to change the language instead, which has disadvantages. So there's a trade off: would you rather change the language or re-implement the interfaces of the generic code? Both approaches would seem to solve the problem at hand. Tim From ulf.wiger@REDACTED Tue Feb 23 17:42:44 2010 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Tue, 23 Feb 2010 17:42:44 +0100 Subject: [erlang-questions] [CLARIFY]: starting application as permanent and takeover frequency In-Reply-To: References: Message-ID: <4B840584.8090401@erlang-solutions.com> Jani Launonen wrote: > > Now, after starting application as permanent, suppose I want it to be > distributed as shown in Ulf's release tutorial. The release handling tutorial describes how to start from a boot script. Applications started from a boot script are always started as 'permanent'. If such an application crashes, the whole node is shut down. BR, Ulf W -- Ulf Wiger CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd http://www.erlang-solutions.com --------------------------------------------------- --------------------------------------------------- WE'VE CHANGED NAMES! Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD. www.erlang-solutions.com From andrew@REDACTED Tue Feb 23 18:18:57 2010 From: andrew@REDACTED (Andrew Thompson) Date: Tue, 23 Feb 2010 12:18:57 -0500 Subject: [erlang-questions] Programmatically starting a remote shell In-Reply-To: <988961A3-043E-47E1-B7A0-5F1942E6B9EB@souja.net> References: <988961A3-043E-47E1-B7A0-5F1942E6B9EB@souja.net> Message-ID: <20100223171857.GA1751@hijacked.us> On Mon, Feb 22, 2010 at 12:19:44PM -0800, Jayson Vantuyl wrote: > I know that you can do it from the command-line with -remsh , but that doesn't so much help from an escript. > I couldn't even get a fully working local shell out of an escript (I got close but there were still some screwy issues). It'd be nice to either be able to *fully* promote an escript to a shell or to have exec(3) support in escripts so you could launch erl with the options you determine you need. Andrew From hknight555@REDACTED Tue Feb 23 19:33:40 2010 From: hknight555@REDACTED (Hank Knight) Date: Tue, 23 Feb 2010 14:33:40 -0400 Subject: Selecting a speedy NoSQL datastore Message-ID: There are an abundance of NoSQL datastores powered by Erlang. Riak, CouchDB, Dynomite and Scalaris to name a few. I need to select a datastore for a logging application. We anticipate 1,000+ write transitions per second and 100+ read transactions per second. There will be about two dozen columns and each of the columns will store between 200 and 800 bytes of data. The hosted solution will be served on a cloud. Speed is important. Please help me select a datastore with low-latency and high scalability. Thanks! - Hank From hd2010@REDACTED Tue Feb 23 19:50:45 2010 From: hd2010@REDACTED (Henning Diedrich) Date: Tue, 23 Feb 2010 19:50:45 +0100 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: References: Message-ID: <4B842385.8090305@eonblast.com> Hi Hank, you might want to be sure that you really need low-latency, rather than high-thruput. Also, do you need to be able to write to any node or can you live with a fixed gateway-node that all access is going through. Finally, looking at CAP and find out what two constraint are the more important to you. You might find that you could actually use Mnesia. Henning Hank Knight wrote: > There are an abundance of NoSQL datastores powered by Erlang. > > Riak, CouchDB, Dynomite and Scalaris to name a few. > > I need to select a datastore for a logging application. > > We anticipate 1,000+ write transitions per second and 100+ read > transactions per second. > > There will be about two dozen columns and each of the columns will > store between 200 and 800 bytes of data. > > The hosted solution will be served on a cloud. > > Speed is important. Please help me select a datastore with > low-latency and high scalability. > > Thanks! > - Hank > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From max.lapshin@REDACTED Tue Feb 23 19:52:46 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 23 Feb 2010 21:52:46 +0300 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: References: Message-ID: Have you profiled usual database? 1000 per sec is not too much for postgres or mysql. And they don't loose data like MongoDB. From masklinn@REDACTED Tue Feb 23 19:55:40 2010 From: masklinn@REDACTED (Masklinn) Date: Tue, 23 Feb 2010 19:55:40 +0100 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: References: Message-ID: <92A7ED66-CBF9-4AF8-AEAB-BF53407C7B55@masklinn.net> On 23 Feb 2010, at 19:33 , Hank Knight wrote: > > There are an abundance of NoSQL datastores powered by Erlang. > > Riak, CouchDB, Dynomite and Scalaris to name a few. > > I need to select a datastore for a logging application. > > We anticipate 1,000+ write transitions per second and 100+ read > transactions per second. > > There will be about two dozen columns and each of the columns will > store between 200 and 800 bytes of data. > > The hosted solution will be served on a cloud. > > Speed is important. Please help me select a datastore with > low-latency and high scalability. Disclaimer: I don't have any involvement in nor experience with any of the systems below, those are just the results of my readings and thus "suggestions to try out" rather than "suggestions to use" As far as I know, the most stable and best performing NoSQL dbs right now seem to be Redis and Tokyo Tyrant. You might want to take them for a drive, either is apparently able to handle about 10000 transactions (read or write) per second on a *small* EC2 instance (see http://michalf.me/blog:redis-performance for instance for Redis). Note that I dont know how the performance scales with the size of the tables, don't forget to test for that (e.g. some solutions might completely crumble once you reach a few dozen million records). MySQL Cluster (the Cluster part is important) might also be a target worth considering. From hd2010@REDACTED Tue Feb 23 20:25:35 2010 From: hd2010@REDACTED (Henning Diedrich) Date: Tue, 23 Feb 2010 20:25:35 +0100 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: <92A7ED66-CBF9-4AF8-AEAB-BF53407C7B55@masklinn.net> References: <92A7ED66-CBF9-4AF8-AEAB-BF53407C7B55@masklinn.net> Message-ID: <4B842BAF.9050906@eonblast.com> Redis and Tokyo are written in C, not sure if that was meant with "powered by". The Erlang DBs are generally more about distribution, thus scalable. Redis and Tokyo are about speed. Henning Masklinn wrote: > On 23 Feb 2010, at 19:33 , Hank Knight wrote: > >> There are an abundance of NoSQL datastores powered by Erlang. >> >> Riak, CouchDB, Dynomite and Scalaris to name a few. >> >> I need to select a datastore for a logging application. >> >> We anticipate 1,000+ write transitions per second and 100+ read >> transactions per second. >> >> There will be about two dozen columns and each of the columns will >> store between 200 and 800 bytes of data. >> >> The hosted solution will be served on a cloud. >> >> Speed is important. Please help me select a datastore with >> low-latency and high scalability. >> > Disclaimer: I don't have any involvement in nor experience with any of the systems below, those are just the results of my readings and thus "suggestions to try out" rather than "suggestions to use" > > As far as I know, the most stable and best performing NoSQL dbs right now seem to be Redis and Tokyo Tyrant. You might want to take them for a drive, either is apparently able to handle about 10000 transactions (read or write) per second on a *small* EC2 instance (see http://michalf.me/blog:redis-performance for instance for Redis). Note that I dont know how the performance scales with the size of the tables, don't forget to test for that (e.g. some solutions might completely crumble once you reach a few dozen million records). > > MySQL Cluster (the Cluster part is important) might also be a target worth considering. > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From zubairq@REDACTED Tue Feb 23 20:59:10 2010 From: zubairq@REDACTED (Zubair Quraishi) Date: Tue, 23 Feb 2010 20:59:10 +0100 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: <4B842BAF.9050906@eonblast.com> References: <92A7ED66-CBF9-4AF8-AEAB-BF53407C7B55@masklinn.net> <4B842BAF.9050906@eonblast.com> Message-ID: <36a929df1002231159x27c6acbeu5f7ebdc748351397@mail.gmail.com> I have personally used Riak, Tokyo Cabinet, and Redis. Redis is by far the best performing data store at the moment, and you also have disk based support for the values. On Tue, Feb 23, 2010 at 8:25 PM, Henning Diedrich wrote: > Redis and Tokyo are written in C, not sure if that was meant with "powered > by". > > The Erlang DBs are generally more about distribution, thus scalable. Redis > and Tokyo are about speed. > > Henning > > Masklinn wrote: >> >> On 23 Feb 2010, at 19:33 , Hank Knight wrote: >> >>> >>> There are an abundance of NoSQL datastores powered by Erlang. >>> >>> Riak, CouchDB, Dynomite and Scalaris to name a few. >>> >>> I need to select a datastore for a logging application. >>> >>> We anticipate 1,000+ write transitions per second and 100+ read >>> transactions per second. >>> >>> There will be about two dozen columns and each of the columns will >>> store between 200 and 800 bytes of data. >>> >>> The hosted solution will be served on a cloud. >>> >>> Speed is important. ?Please help me select a datastore with >>> low-latency and high scalability. >>> >> >> Disclaimer: I don't have any involvement in nor experience with any of the >> systems below, those are just the results of my readings and thus >> "suggestions to try out" rather than "suggestions to use" >> >> As far as I know, the most stable and best performing NoSQL dbs right now >> seem to be Redis and Tokyo Tyrant. You might want to take them for a drive, >> either is apparently able to handle about 10000 transactions (read or write) >> per second on a *small* EC2 instance (see >> http://michalf.me/blog:redis-performance for instance for Redis). Note that >> I dont know how the performance scales with the size of the tables, don't >> forget to test for that (e.g. some solutions might completely crumble once >> you reach a few dozen million records). >> >> MySQL Cluster (the Cluster part is important) might also be a target worth >> considering. >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> >> > > From rapsey@REDACTED Tue Feb 23 21:03:17 2010 From: rapsey@REDACTED (Rapsey) Date: Tue, 23 Feb 2010 21:03:17 +0100 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: References: Message-ID: <97619b171002231203p17d4c293g90dc8664aa799fbd@mail.gmail.com> MongoDB looses data? First time I've heard mongodb having such an issue. Sergej On Tue, Feb 23, 2010 at 7:52 PM, Max Lapshin wrote: > Have you profiled usual database? 1000 per sec is not too much for > postgres or mysql. > And they don't loose data like MongoDB. > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From max.lapshin@REDACTED Tue Feb 23 21:06:34 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 23 Feb 2010 23:06:34 +0300 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: <97619b171002231203p17d4c293g90dc8664aa799fbd@mail.gmail.com> References: <97619b171002231203p17d4c293g90dc8664aa799fbd@mail.gmail.com> Message-ID: On Tue, Feb 23, 2010 at 11:03 PM, Rapsey wrote: > MongoDB looses data? First time I've heard mongodb having such an issue. > Yes, we have experienced this problem on staging tests and stopped experiments with nosql after it. From rapsey@REDACTED Tue Feb 23 21:26:13 2010 From: rapsey@REDACTED (Rapsey) Date: Tue, 23 Feb 2010 21:26:13 +0100 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: References: <97619b171002231203p17d4c293g90dc8664aa799fbd@mail.gmail.com> Message-ID: <97619b171002231226n1b9ac023ra56d8bbbfd17844f@mail.gmail.com> On Tue, Feb 23, 2010 at 9:06 PM, Max Lapshin wrote: > On Tue, Feb 23, 2010 at 11:03 PM, Rapsey wrote: > > MongoDB looses data? First time I've heard mongodb having such an issue. > > > > Yes, we have experienced this problem on staging tests and stopped > experiments with nosql after it. > Were you using the unstable 1.3.x series by any chance? We have a number of sites on mongodb and had zero issues with it. I'm usually on the mongodb irc channel and I've never seen anyone complain about losing data. I would definitely recommend MongoDB for a NoSQL project. It's very fast (memcached levels fast) and has the most flexible query system of all NoSQL dbs. The developers (10gen) are also very responsive if you are having any issues with it. From per.melin@REDACTED Tue Feb 23 21:44:35 2010 From: per.melin@REDACTED (Per Melin) Date: Tue, 23 Feb 2010 21:44:35 +0100 Subject: [erlang-questions] Programmatically starting a remote shell In-Reply-To: <20100223171857.GA1751@hijacked.us> References: <988961A3-043E-47E1-B7A0-5F1942E6B9EB@souja.net> <20100223171857.GA1751@hijacked.us> Message-ID: On Tue, Feb 23, 2010 at 6:18 PM, Andrew Thompson wrote: > I couldn't even get a fully working local shell out of an escript (I got > close but there were still some screwy issues). It'd be nice to either > be able to *fully* promote an escript to a shell or to have exec(3) > support in escripts so you could launch erl with the options you > determine you need. Not perfect, but I get something (at first glance) usable with: main(_) -> shell:server(false, false). Haven't tested it for more than ten seconds, but that can turn into a remote shell: main(_) -> net_kernel:start([foo@REDACTED, longnames]), rpc:call(bar@REDACTED, shell, server, [false, false]). I'm not absolutely sure, but I think that when you run this: $ escript ./foo arg1 arg2 ?what essentially gets executed is this: $ erl +B -noshell -s escript -- ./foo arg1 arg2 And I wonder if the -noshell switch does something other than just not starting a shell? Something that will make it impossible to get a 100% functioning shell? From hynek@REDACTED Tue Feb 23 23:54:38 2010 From: hynek@REDACTED (Hynek Vychodil) Date: Tue, 23 Feb 2010 23:54:38 +0100 Subject: [erlang-questions] Sequential I/O access for large files in Erlang In-Reply-To: <682872.24444.qm@web65607.mail.ac4.yahoo.com> References: <682872.24444.qm@web65607.mail.ac4.yahoo.com> Message-ID: <4d08db371002231454i5657838fn2379a5c32cf66a77@mail.gmail.com> Thank you for fast fix. On Tue, Feb 23, 2010 at 1:32 AM, Isaac Gouy wrote: > On Mon, 2010-02-22 at 11:58 +0100, Hynek Vychodil wrote: >> If you want really fast IO you can use approach shown there >> http://shootout.alioth.debian.org/u64q/program.php?test=regexdna?=hipe&id=6 > >> But don't forgot add -noinput parameter to erl. I have mentioned it in >> mine contribution, it worked for a while and #6 version was there in >> top list with ~60s, but they broke it without any warning. I have long >> message exchange with Isaac Gouy >> https://alioth.debian.org/tracker/index.php?func=detail&aid=312099 >> before they accept it. It worked but they changed it again. I have >> found it just now but I'm fed up with this arrogant moron and I will >> not waste mine time trying fix it again. > > > For anyone who is more interested in getting bugs fixed than venting personal abuse - when you see what you think is a bug, report a bug - > > http://shootout.alioth.debian.org/help.php#reportbugs > > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > -- --Hynek (Pichi) Vychodil Analyze your data in minutes. Share your insights instantly. Thrill your boss. Be a data hero! Try GoodData now for free: www.gooddata.com From andrew@REDACTED Tue Feb 23 23:59:45 2010 From: andrew@REDACTED (Andrew Thompson) Date: Tue, 23 Feb 2010 17:59:45 -0500 Subject: [erlang-questions] Programmatically starting a remote shell In-Reply-To: References: <988961A3-043E-47E1-B7A0-5F1942E6B9EB@souja.net> <20100223171857.GA1751@hijacked.us> Message-ID: <20100223225945.GC1751@hijacked.us> On Tue, Feb 23, 2010 at 09:44:35PM +0100, Per Melin wrote: > On Tue, Feb 23, 2010 at 6:18 PM, Andrew Thompson wrote: > > I couldn't even get a fully working local shell out of an escript (I got > > close but there were still some screwy issues). It'd be nice to either > > be able to *fully* promote an escript to a shell or to have exec(3) > > support in escripts so you could launch erl with the options you > > determine you need. > > Not perfect, but I get something (at first glance) usable with: > main(_) -> shell:server(false, false). > At the very least, the readline history stuff doesn't seem to work. Neither does ^G (so no job control). This is about what I ended up with when I was testing, too. Andrew From ok@REDACTED Wed Feb 24 00:11:44 2010 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 24 Feb 2010 12:11:44 +1300 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> Message-ID: <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> On Feb 24, 2010, at 12:36 AM, Attila Rajmund Nohl wrote: > 2010/2/23, Ulf Wiger : > [...] >> From the Erlang Reference Manual: >> >> >> An exception occurring during the evaluation of Body is not caught." > > This is um, surprising, even by the standards of Erlang... I mean not > the documentation, but the actual language construct. I had forgotten about try...of...catch...end. When is it appropriate to use try E of H catch ... end instead of try case E of H end catch ... end? I think the _intent_ is clear, that in try E ... end it is *only* E that is protected. It does make sense, but it would be really nice to see a couple of examples where try .. of .. catch .. end was the right thing to do. From rvirding@REDACTED Wed Feb 24 00:35:29 2010 From: rvirding@REDACTED (Robert Virding) Date: Wed, 24 Feb 2010 00:35:29 +0100 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> Message-ID: <3dbc6d1c1002231535j6b737f92s61f418f370d3530c@mail.gmail.com> On 23 February 2010 12:36, Attila Rajmund Nohl wrote: > > This is um, surprising, even by the standards of Erlang... I mean not > the documentation, but the actual language construct. Not really. It does make the try a little more complex but in return it does allow you to directly do a case on the return value of expression without having to do something special to differentiate between it and value from catching an error. This is cleaner than what you need with catch. Try is definitely the most complex single construct in Erlang today. Robert From bernie@REDACTED Wed Feb 24 00:36:16 2010 From: bernie@REDACTED (Bernard Duggan) Date: Wed, 24 Feb 2010 10:36:16 +1100 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> Message-ID: <4B846670.6020700@m5net.com> Richard O'Keefe wrote: > When is it appropriate to use try E of H catch ... end > instead of try case E of H end catch ... end? When you want to use tail recursion. The recursive call to foo() here: foo(X) -> try case f(X) of A -> foo(A); _ -> ok end catch _ -> doom() end Is /not/ tail recursive on account of the catch block. This, however: foo(X) -> try f(X) of A -> foo(A); _ -> ok catch _ -> doom() end /is/ tail recursive, specifically because exceptions thrown in the body of the try block are not subject to the catch at the end. (Obviously that code won't work, but you get the idea). I think. Going from memory here. Cheers, Bernard From per.melin@REDACTED Wed Feb 24 01:05:17 2010 From: per.melin@REDACTED (Per Melin) Date: Wed, 24 Feb 2010 01:05:17 +0100 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> Message-ID: On Wed, Feb 24, 2010 at 12:11 AM, Richard O'Keefe wrote: > I had forgotten about try...of...catch...end. > When is it appropriate to use try E of H catch ... end > instead of try case E of H end catch ... end? > > I think the _intent_ is clear, that in try E ... end > it is *only* E that is protected. > > It does make sense, but it would be really nice to see > a couple of examples where try .. of .. catch .. end was > the right thing to do. How about when you need to catch a specific event? try ets:slot(Table, SlotNumber) of '$end_of_table' -> ok; Items -> do_stuff(Items) catch error:badarg -> % We get badarg when the slot number was higher than the total % number of slots. This can happen if someone deleted items from % the table while we were traversing it. No worries. ok end. I don't want to accidentally catch a badarg in do_stuff/1 here. From ok@REDACTED Wed Feb 24 01:25:33 2010 From: ok@REDACTED (Richard O'Keefe) Date: Wed, 24 Feb 2010 13:25:33 +1300 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> Message-ID: On Feb 24, 2010, at 1:05 PM, Per Melin wrote: > How about when you need to catch a specific event? > > try ets:slot(Table, SlotNumber) of > '$end_of_table' -> > ok; > Items -> > do_stuff(Items) > catch > error:badarg -> > % We get badarg when the slot number was higher than the total > % number of slots. This can happen if someone deleted items > from > % the table while we were traversing it. No worries. > ok > end. That can be written just as well as case try ets:slot(Table, Slot_Number) catch error:badarg -> '$end_of_table' end of '$end_of_table' -> ok ; Items -> do_stuff(Items) end in which not only will badargs inside do_stuff not be caught, but the call to do_stuff is visibly *outside* the try, so it is _obvious_ that they won't be caught. The problem here is the definition of ets:slot/2: "Returns all objects in the I:th slot of the table Tab. A table can be traversed by repeatedly calling the function, starting with the first slot I = 0 and ending when '$end_of_table' is returned. The function will fail with reason badarg if the I argument is out of range." A better definition would be to say that The function will fail with reason badarg if I is not a non-negative integer. Sufficiently large values of I result in '$end_of_table' returns. With that interface, the whole example would just be case ets:slot(Table, Slot_Number) of '$end_of_table' -> ok ; Items -> do_stuff(Items) end In erl_db_tree.c, for example, I _think_ if (is_not_small(slot_term) || ((slot = signed_val(slot_term)) < 0) || (slot > tb->common.nitems)) return DB_ERROR_BADPARAM; if (slot == tb->common.nitems) { *ret = am_EOT; return DB_ERROR_NONE; } should change to if (is_not_small(slot_term) || ((slot = signed_val(slot_term)) < 0)) return DB_ERROR_BADPARAM; if (slot >= tb_common.nitems) { *ret = am_EOT; return DB_ERROR_NONE; } In erl_db_hash.c, I _think_ if (is_not_small(slot_term) || ((slot = signed_val(slot_term)) < 0) || (slot > tb->nactive)) return DB_ERROR_BADPARAM; if (slot == tb->nactive) { *ret = am_EOT; return DB_ERROR_NONE; } should change to if (is_not_small(slot_term) || ((slot = signed_val(slot_term)) < 0)) return DB_ERROR_BADPARAM; if (slot >= tb->nactive) { *ret = am_EOT; return DB_ERROR_NONE; } The reason for this change is the one you give, that someone else might have been changing the table. If that someone else adds stuff to the table so that it grows, nothing bad happens, but if they delete, and the tree or hash table shrinks, you are really out of luck. From g@REDACTED Wed Feb 24 01:28:33 2010 From: g@REDACTED (Garrett Smith) Date: Tue, 23 Feb 2010 18:28:33 -0600 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <4B846670.6020700@m5net.com> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> <4B846670.6020700@m5net.com> Message-ID: On Tue, Feb 23, 2010 at 5:36 PM, Bernard Duggan wrote: > Richard O'Keefe wrote: >> When is it appropriate to use try E of H catch ... end >> instead of try case E of H end catch ... end? > When you want to use tail recursion. > The recursive call to foo() here: > > foo(X) -> > ? ?try > ? ? ? ?case f(X) of > ? ? ? ? ? ?A -> foo(A); > ? ? ? ? ? ?_ -> ok > ? ? ? end > ? ?catch > ? ? ? _ -> doom() > ? ?end > > Is /not/ tail recursive on account of the catch block. Another problem with that block is that you don't know whether the exception originated from f(X) or foo(A). The beauty of try...of is that you isolate the code your trying. Garrett From tuncer.ayaz@REDACTED Wed Feb 24 01:34:14 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 24 Feb 2010 01:34:14 +0100 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266567436.4073.6.camel@humaira-laptop> <1266572041.4073.8.camel@humaira-laptop> <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> Message-ID: <4ac8254d1002231634x4ac64dd1g623bbb0a745985bb@mail.gmail.com> On Sat, Feb 20, 2010 at 2:08 PM, Tuncer Ayaz wrote: > On Sat, Feb 20, 2010 at 2:01 PM, Chandru > wrote: >> On 19 February 2010 23:49, Tuncer Ayaz wrote: >>> On Fri, Feb 19, 2010 at 11:17 AM, Chandru >>> wrote: >>>> Here it is. A correction to my previous statement - I think Sean Hinde >>>> modified Tobbe's code to use gen_fsm instead. >>> >>> Tobbe's version including Sean's changes is available at >>> http://github.com/etnt/eldap >>> >> >> I just checked, and it doesn't have the changes made by Sean. > > http://github.com/etnt/eldap/raw/master/test/eldap_fsm.erl > seemed to be what you were looking for. > > Interesting. I just compared both and the fsm is different. Chandru, where did you find the archive? Tobbe's version at github seems to be the same as jungerl's CVS revision. From kagato@REDACTED Wed Feb 24 03:02:44 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Tue, 23 Feb 2010 18:02:44 -0800 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: References: <97619b171002231203p17d4c293g90dc8664aa799fbd@mail.gmail.com> Message-ID: <4765D998-922A-40F6-B7FA-5814C04460F7@souja.net> This is not entirely so simple. MongoDB does not ensure durability for a single machine database. Instead, they require you to use replication across multiple servers. When properly deployed on redundant storage, you get eventually-consistent durability across the system. Read a little about it here: http://blog.mongodb.org/post/381927266/what-about-durability Their rationale, which is actually quite insightful, is that anyone who is really concerned with not losing data (and understands the problem) wouldn't want just one machine durability anyway--especially with the weaker guarantees that they've otherwise accepted due to eventual-consistency. Also, note that Mongo Sharding gives you the same replication plus horizontal scalability. Right now, Mongo, Riak, and Dynomite are the NoSQLs that really seem to scale. All of them are apparently eventually-consistent. Among those, Mongo is the best performing. Mongo doesn't "lose data" any more than the others. More directly, in an eventually-consistent system, there is always a point where you can lose the partition of nodes that has the data. On Feb 23, 2010, at 12:06 PM, Max Lapshin wrote: > On Tue, Feb 23, 2010 at 11:03 PM, Rapsey wrote: >> MongoDB looses data? First time I've heard mongodb having such an issue. >> > > Yes, we have experienced this problem on staging tests and stopped > experiments with nosql after it. > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- Jayson Vantuyl kagato@REDACTED From mjtruog@REDACTED Wed Feb 24 03:57:26 2010 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 23 Feb 2010 18:57:26 -0800 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: <36a929df1002231159x27c6acbeu5f7ebdc748351397@mail.gmail.com> References: <92A7ED66-CBF9-4AF8-AEAB-BF53407C7B55@masklinn.net> <4B842BAF.9050906@eonblast.com> <36a929df1002231159x27c6acbeu5f7ebdc748351397@mail.gmail.com> Message-ID: <4B849596.2090007@gmail.com> By Tokyo Cabinet, do you mean Tokyo Tyrant? (i.e., the server front-end to Tokyo Cabinet) Zubair Quraishi wrote: > I have personally used Riak, Tokyo Cabinet, and Redis. Redis is by far > the best performing data store at the moment, and you also have disk > based support for the values. > > On Tue, Feb 23, 2010 at 8:25 PM, Henning Diedrich wrote: > >> Redis and Tokyo are written in C, not sure if that was meant with "powered >> by". >> >> The Erlang DBs are generally more about distribution, thus scalable. Redis >> and Tokyo are about speed. >> >> Henning >> >> Masklinn wrote: >> >>> On 23 Feb 2010, at 19:33 , Hank Knight wrote: >>> >>> >>>> There are an abundance of NoSQL datastores powered by Erlang. >>>> >>>> Riak, CouchDB, Dynomite and Scalaris to name a few. >>>> >>>> I need to select a datastore for a logging application. >>>> >>>> We anticipate 1,000+ write transitions per second and 100+ read >>>> transactions per second. >>>> >>>> There will be about two dozen columns and each of the columns will >>>> store between 200 and 800 bytes of data. >>>> >>>> The hosted solution will be served on a cloud. >>>> >>>> Speed is important. Please help me select a datastore with >>>> low-latency and high scalability. >>>> >>>> >>> Disclaimer: I don't have any involvement in nor experience with any of the >>> systems below, those are just the results of my readings and thus >>> "suggestions to try out" rather than "suggestions to use" >>> >>> As far as I know, the most stable and best performing NoSQL dbs right now >>> seem to be Redis and Tokyo Tyrant. You might want to take them for a drive, >>> either is apparently able to handle about 10000 transactions (read or write) >>> per second on a *small* EC2 instance (see >>> http://michalf.me/blog:redis-performance for instance for Redis). Note that >>> I dont know how the performance scales with the size of the tables, don't >>> forget to test for that (e.g. some solutions might completely crumble once >>> you reach a few dozen million records). >>> >>> MySQL Cluster (the Cluster part is important) might also be a target worth >>> considering. >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >>> >>> >>> >> > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From kyleqian@REDACTED Wed Feb 24 04:42:03 2010 From: kyleqian@REDACTED (=?GB2312?B?x67P/sP3?=) Date: Wed, 24 Feb 2010 11:42:03 +0800 Subject: Why it is a illegal guard expression? Message-ID: Hi, I am a newer of erlang. I wrote a module to find all files(no directory) under a directory, including its subdirectory: -module(lib_test). -export([list_files/1]). list_files(Path)-> {ok, FileList} = file:list_dir(Path), process_filelist(FileList, []). process_filelist([File|FileList], Files)-> if filelib:is_dir(File) -> {ok, NewFileList} = file:list_dir(File), process_filelist(NewFileList, Files); true -> process_filelist(FileList, [File|Files]) end; process_filelist([], Files) -> Files. But I fail to compile this file, because " filelib:is_dir(File) ->" is illegal guard expression. So Why it is illegal? What should I write? Thanks for your help! From ttmrichter@REDACTED Wed Feb 24 04:48:41 2010 From: ttmrichter@REDACTED (Michael Richter) Date: Wed, 24 Feb 2010 11:48:41 +0800 Subject: [erlang-questions] Why it is a illegal guard expression? In-Reply-To: References: Message-ID: There is a very limited list of which functions can be used in guard expressions. From http://www.erlang.org/doc/reference_manual/expressions.html#id2273702 we have: The set of valid guard expressions (sometimes called guard tests) is a > subset of the set of valid Erlang expressions. The reason for restricting > the set of valid expressions is that evaluation of a guard expression must > be guaranteed to be free of side effects. We also find a list of functions which can be used in guard expressions there. On 24 February 2010 11:42, ??? wrote: > Hi, I am a newer of erlang. I wrote a module to find all files(no > directory) > under a directory, including its subdirectory: > -module(lib_test). > -export([list_files/1]). > > list_files(Path)-> > {ok, FileList} = file:list_dir(Path), > process_filelist(FileList, []). > > process_filelist([File|FileList], Files)-> > if > filelib:is_dir(File) -> > {ok, NewFileList} = file:list_dir(File), > process_filelist(NewFileList, Files); > true -> > process_filelist(FileList, [File|Files]) > end; > process_filelist([], Files) -> > Files. > > But I fail to compile this file, because " filelib:is_dir(File) ->" is > illegal guard expression. So Why it is illegal? What should I write? > Thanks for your help! > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. From jvantuyl@REDACTED Wed Feb 24 04:51:17 2010 From: jvantuyl@REDACTED (Jayson Vantuyl) Date: Tue, 23 Feb 2010 19:51:17 -0800 Subject: Give Your Erlang Program A CLI with ErlCtl Message-ID: <606E98F7-8C10-4206-9734-F4BFE2D455BC@scatterbit.com> Hello everybody, I just released a little library that I thought might be handy for everybody. It's a one-stop-shop for giving your daemon-process a powerful command-line interface. Read about it on my blog, here: > http://needlesslymessianic.com/2010/02/21/announcing-erlctl-0-1 Enjoy! -- Jayson Vantuyl Chief Technical Officer ScatterBit, Inc. http://www.scatterbit.com jvantuyl@REDACTED +1-724-826-8895 From bob@REDACTED Wed Feb 24 04:58:51 2010 From: bob@REDACTED (Bob Ippolito) Date: Tue, 23 Feb 2010 19:58:51 -0800 Subject: [erlang-questions] Why it is a illegal guard expression? In-Reply-To: References: Message-ID: <6a36e7291002231958h6449d539i9ce32956712b54f6@mail.gmail.com> Additionally, there are very few reasons to use "if". In general you should be using "case", which does not have this problem. process_filelist([File|FileList], Files)-> case filelib:is_dir(File) of true -> {ok, NewFileList} = file:list_dir(File), process_filelist(NewFileList, Files); false -> process_filelist(FileList, [File|Files]) end; process_filelist([], Files) -> Files. On Tue, Feb 23, 2010 at 7:48 PM, Michael Richter wrote: > There is a very limited list of which functions can be used in guard > expressions. ?From > http://www.erlang.org/doc/reference_manual/expressions.html#id2273702 we > have: > > The set of valid guard expressions (sometimes called guard tests) is a >> subset of the set of valid Erlang expressions. The reason for restricting >> the set of valid expressions is that evaluation of a guard expression must >> be guaranteed to be free of side effects. > > > We also find a list of functions which can be used in guard expressions > there. > > On 24 February 2010 11:42, ??? wrote: > >> Hi, I am a newer of erlang. I wrote a module to find all files(no >> directory) >> under a directory, including its subdirectory: >> -module(lib_test). >> -export([list_files/1]). >> >> list_files(Path)-> >> ? ?{ok, FileList} = file:list_dir(Path), >> ? ?process_filelist(FileList, []). >> >> process_filelist([File|FileList], Files)-> >> ? ?if >> ? ? ? filelib:is_dir(File) -> >> ? ? ? ?{ok, NewFileList} = file:list_dir(File), >> ? ? ? ?process_filelist(NewFileList, Files); >> ? ? ? true -> >> ? ? ? ?process_filelist(FileList, [File|Files]) >> ? ?end; >> process_filelist([], Files) -> >> ? ?Files. >> >> But I fail to compile this file, because " filelib:is_dir(File) ->" is >> illegal guard expression. So Why it is illegal? What should I write? >> Thanks for your help! >> > > > > -- > "Perhaps people don't believe this, but throughout all of the discussions of > entering China our focus has really been what's best for the Chinese people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. > From mjtruog@REDACTED Wed Feb 24 06:12:26 2010 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 23 Feb 2010 21:12:26 -0800 Subject: [erlang-questions] Why it is a illegal guard expression? In-Reply-To: <6a36e7291002231958h6449d539i9ce32956712b54f6@mail.gmail.com> References: <6a36e7291002231958h6449d539i9ce32956712b54f6@mail.gmail.com> Message-ID: <4B84B53A.9080309@gmail.com> Guards are the only statements in Erlang that do not have side-effects and they should be faster when evaluated in guard expressions. So there are reasons to use if statements for guard expressions. However, most of the time you must use case statements, since very few functions can be used within guard expressions. Using an if statement can keep the code a little bit more pure, by avoiding residual statefulness. Bob Ippolito wrote: > Additionally, there are very few reasons to use "if". In general you > should be using "case", which does not have this problem. > > process_filelist([File|FileList], Files)-> > case filelib:is_dir(File) of > true -> > {ok, NewFileList} = file:list_dir(File), > process_filelist(NewFileList, Files); > false -> > process_filelist(FileList, [File|Files]) > end; > process_filelist([], Files) -> > Files. > > On Tue, Feb 23, 2010 at 7:48 PM, Michael Richter wrote: > >> There is a very limited list of which functions can be used in guard >> expressions. From >> http://www.erlang.org/doc/reference_manual/expressions.html#id2273702 we >> have: >> >> The set of valid guard expressions (sometimes called guard tests) is a >> >>> subset of the set of valid Erlang expressions. The reason for restricting >>> the set of valid expressions is that evaluation of a guard expression must >>> be guaranteed to be free of side effects. >>> >> We also find a list of functions which can be used in guard expressions >> there. >> >> On 24 February 2010 11:42, ??? wrote: >> >> >>> Hi, I am a newer of erlang. I wrote a module to find all files(no >>> directory) >>> under a directory, including its subdirectory: >>> -module(lib_test). >>> -export([list_files/1]). >>> >>> list_files(Path)-> >>> {ok, FileList} = file:list_dir(Path), >>> process_filelist(FileList, []). >>> >>> process_filelist([File|FileList], Files)-> >>> if >>> filelib:is_dir(File) -> >>> {ok, NewFileList} = file:list_dir(File), >>> process_filelist(NewFileList, Files); >>> true -> >>> process_filelist(FileList, [File|Files]) >>> end; >>> process_filelist([], Files) -> >>> Files. >>> >>> But I fail to compile this file, because " filelib:is_dir(File) ->" is >>> illegal guard expression. So Why it is illegal? What should I write? >>> Thanks for your help! >>> >>> >> >> -- >> "Perhaps people don't believe this, but throughout all of the discussions of >> entering China our focus has really been what's best for the Chinese people. >> It's not been about our revenue or profit or whatnot." >> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. >> >> > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From ramkrishna.kulkarni@REDACTED Wed Feb 24 06:39:06 2010 From: ramkrishna.kulkarni@REDACTED (Ramkrishna Kulkarni) Date: Wed, 24 Feb 2010 11:09:06 +0530 Subject: Active open source Erlang projects Message-ID: Hello, I am planning to take a few months off my job to contribute to Erlang open source projects. I am a beginner and can write simple modules. Apart from helping the project, my aim is to get an in depth understanding of Erlang. Please let me know if there are any active Erlang projects needing help. TIA, Ram From raimo+erlang-questions@REDACTED Wed Feb 24 09:56:09 2010 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Wed, 24 Feb 2010 09:56:09 +0100 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> Message-ID: <20100224085609.GA14027@erix.ericsson.se> On Wed, Feb 24, 2010 at 12:11:44PM +1300, Richard O'Keefe wrote: > > On Feb 24, 2010, at 12:36 AM, Attila Rajmund Nohl wrote: > > >2010/2/23, Ulf Wiger : > >[...] > >>From the Erlang Reference Manual: > >> > >> > >>An exception occurring during the evaluation of Body is not caught." > > > >This is um, surprising, even by the standards of Erlang... I mean not > >the documentation, but the actual language construct. > > I had forgotten about try...of...catch...end. > When is it appropriate to use try E of H catch ... end > instead of try case E of H end catch ... end? > > I think the _intent_ is clear, that in try E ... end > it is *only* E that is protected. > > It does make sense, but it would be really nice to see > a couple of examples where try .. of .. catch .. end was > the right thing to do. I think this kind of construct is harder to do without the of..catch part: Handle = resource:open("foo.txt"), try resource:read(Handle) of {ok, Data} -> foo(Data); Error -> Error catch error:Reason -> {error,Reason} after resource:close(Handle) end > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From lovei.laszlo@REDACTED Wed Feb 24 10:56:56 2010 From: lovei.laszlo@REDACTED (Laszlo Lovei) Date: Wed, 24 Feb 2010 01:56:56 -0800 (PST) Subject: Unexpected try/catch behaviour In-Reply-To: <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> Message-ID: <03540252-31fc-4ad3-878e-d009d62c4d53@15g2000yqi.googlegroups.com> On Feb 24, 12:11?am, "Richard O'Keefe" wrote: > > When is it appropriate to use try E of H catch ... end > instead of try case E of H end catch ... end? I always find the former more appropriate. I usually only want to catch specific exceptions from specific expressions, and consider other exceptions as errors. In this situation, "try case E of H end catch ... end" can incidentally catch errors, while a simple "try E of H catch ... end" does exactly what I want. I admit that in most "try" expressions I don't need the "of H" part, but when I need it, "try ... of" is always more appropriate than "try case ... of". Another point: if you want to catch exceptions from H, you can write "try case E of H end catch ... end". However, it is much harder to write code that doesn't catch exceptions from H: in "case try E catch ... end of H end" you must extend H with clauses that do something in case of a caught exception. (The "ets:slot" example was easy, because the exception was treated in the same way as the end of the table, but normally exceptions signal exceptional situations, which should be treated differently.) Laszlo From schramm.ingo@REDACTED Wed Feb 24 11:30:10 2010 From: schramm.ingo@REDACTED (ingo.schramm) Date: Wed, 24 Feb 2010 02:30:10 -0800 (PST) Subject: busy_dist_port: Who's seeing it? (Heh, who's bothered to look?) In-Reply-To: <26780.1266874178@snookles.snookles.com> References: <26780.1266874178@snookles.snookles.com> Message-ID: Now I understand why I got curious timeouts with a distributed application sending huge amounts of data over the network. I helped me with lowering the message sizes and increasing the number of messages from node to node. Sure it could help to be able to tune this behavior to find some optimum. From als@REDACTED Wed Feb 24 11:45:01 2010 From: als@REDACTED (Anthony Shipman) Date: Wed, 24 Feb 2010 21:45:01 +1100 Subject: reductions galore Message-ID: <201002242145.01460.als@iinet.net.au> Here is some code from experimenting with profiling. run() -> Keys = lists:seq(1, 2000), Child = spawn(fun() -> receive after 5000 -> ok end end), %Child = spawn(fun() -> receive _ -> ok end end), {reductions,R1} = process_info(self(), reductions), lists:foreach(fun(K) -> Child!K end, Keys), {reductions,R2} = process_info(self(), reductions), io:format("reductions ~p~n", [R2 - R1]), ok. It prints reductions 3344538 If I change the child process to the second one with the receive X I get reductions 6334 In the first case messages are queuing in the child process. But can the reduction count be real? -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From clist@REDACTED Wed Feb 24 11:56:52 2010 From: clist@REDACTED (Angel Alvarez) Date: Wed, 24 Feb 2010 11:56:52 +0100 Subject: [erlang-questions] reductions galore In-Reply-To: <201002242145.01460.als@iinet.net.au> References: <201002242145.01460.als@iinet.net.au> Message-ID: <201002241156.52977.clist@uah.es> El Mi?rcoles, 24 de Febrero de 2010 11:45:01 Anthony Shipman escribi?: > Here is some code from experimenting with profiling. > > run() -> > Keys = lists:seq(1, 2000), > > Child = spawn(fun() -> receive after 5000 -> ok end end), > %Child = spawn(fun() -> receive _ -> ok end end), > > > {reductions,R1} = process_info(self(), reductions), > lists:foreach(fun(K) -> Child!K end, Keys), > {reductions,R2} = process_info(self(), reductions), > > io:format("reductions ~p~n", [R2 - R1]), > ok. > > > It prints > reductions 3344538 > > If I change the child process to the second one with the receive X I get > reductions 6334 > > In the first case messages are queuing in the child process. But can the > reduction count be real? > IIRC reductions are bumped for a process sending large amount of messages filling up other porcess queue. This is a counter measure to allow receiver process messages in case of flooding... You should read: http://www.erlang.org/cgi-bin/ezmlm-cgi/4/18382 for the classical "log process flooding" problem. /angel -- Este correo no tiene dibujos. Las formas extra?as en la pantalla son letras. __________________________________________ Clist UAH a.k.a Angel __________________________________________ If debugging is the process of removing bugs, then programming must be the process of putting them in. Dijkstra. From kenneth.lundin@REDACTED Wed Feb 24 12:00:11 2010 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 24 Feb 2010 12:00:11 +0100 Subject: Erlang/OTP R13B04 has been released Message-ID: Bug fix release : otp_src_R13B04 Build date ? ? ?: 2010-02-23 This is R13B04, the fourth maintenance release for the R13B major release. You can find the README file for the release at http://www.erlang.org/download/otp_src_R13B04.readme The source distribution and binary distribution for Windows can be downloaded from http://www.erlang.org/download/otp_src_R13B04.tar.gz http://www.erlang.org/download/otp_win32_R13B04.exe The distribution can also be downloaded using the BitTorrent protocol. Use the following torrent files to download the source distribution and binary distribution for Windows: http://www.erlang.org/download/otp_src_R13B04.tar.gz.torrent http://www.erlang.org/download/otp_win32_R13B04.exe.torrent Note: To unpack the TAR archive you need a GNU TAR compatible program. For installation instructions please read the README file that is part of the distribution. The on-line documentation can be found at: http://www.erlang.org/doc/ You can also download the complete HTML documentation or the Unix manual files http://www.erlang.org/download/otp_doc_html_R13B04.tar.gz http://www.erlang.org/download/otp_doc_man_R13B04.tar.gz We also want to thank those that sent us patches, suggestions and bug reports, The OTP Team Kenneth Lundin, Erlang/OTP, Ericsson AB ________________________________________________________________ erlang-questions mailing list. See http://www.erlang.org/faq.html erlang-questions (at) erlang.org From max.lapshin@REDACTED Wed Feb 24 12:11:48 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 24 Feb 2010 14:11:48 +0300 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: References: Message-ID: Have you added setting PATH environment to windows installer? From kagato@REDACTED Wed Feb 24 12:22:43 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Wed, 24 Feb 2010 03:22:43 -0800 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: References: Message-ID: <45CB2AE9-CE02-47F7-944E-35BE9CA25ECB@souja.net> Max, I don't see it in the Release README. Did you submit a patch? On Feb 24, 2010, at 3:11 AM, Max Lapshin wrote: > Have you added setting PATH environment to windows installer? > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- Jayson Vantuyl kagato@REDACTED From max.lapshin@REDACTED Wed Feb 24 12:25:56 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 24 Feb 2010 14:25:56 +0300 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: <45CB2AE9-CE02-47F7-944E-35BE9CA25ECB@souja.net> References: <45CB2AE9-CE02-47F7-944E-35BE9CA25ECB@souja.net> Message-ID: On Wed, Feb 24, 2010 at 2:22 PM, Jayson Vantuyl wrote: > Max, > > I don't see it in the Release README. ?Did you submit a patch? > No, because I don't know even where is the windows installer source lays =( From vladdu55@REDACTED Wed Feb 24 12:35:41 2010 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 24 Feb 2010 12:35:41 +0100 Subject: [erlang-questions] busy_dist_port: Who's seeing it? (Heh, who's bothered to look?) In-Reply-To: <26780.1266874178@snookles.snookles.com> References: <26780.1266874178@snookles.snookles.com> Message-ID: <95be1d3b1002240335p239f199aj97322c6e51978930@mail.gmail.com> On Mon, Feb 22, 2010 at 22:29, Scott Lystig Fritchie wrote: > This causes really weird latency problems when the outside world, > e.g. proc P on node bar@REDACTED, tries a synchronous gen_server:call() to Proc > A. ?Huge variations of latency (jitter), sometimes many seconds worth > (and *very* unpredictable). Thanks for the info, this is very interesting. Could someone in the knowing please specify if this applies even to Erlang-to-C-node communication? best regards, Vlad From chandrashekhar.mullaparthi@REDACTED Wed Feb 24 12:59:19 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Wed, 24 Feb 2010 11:59:19 +0000 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <4ac8254d1002231634x4ac64dd1g623bbb0a745985bb@mail.gmail.com> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266567436.4073.6.camel@humaira-laptop> <1266572041.4073.8.camel@humaira-laptop> <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> <4ac8254d1002231634x4ac64dd1g623bbb0a745985bb@mail.gmail.com> Message-ID: On 24 February 2010 00:34, Tuncer Ayaz wrote: >>> >>> I just checked, and it doesn't have the changes made by Sean. >> >> http://github.com/etnt/eldap/raw/master/test/eldap_fsm.erl >> seemed to be what you were looking for. >> >> Interesting. > > I just compared both and the fsm is different. > > Chandru, where did you find the archive? > As I said before, this is a locally modified version of eldap. Sean Hinde made these changes a long time ago. cheers Chandru From kagato@REDACTED Wed Feb 24 14:19:10 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Wed, 24 Feb 2010 05:19:10 -0800 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: References: <45CB2AE9-CE02-47F7-944E-35BE9CA25ECB@souja.net> Message-ID: Max, Sorry, it doesn't look like the installer was modified in this release. It appears that Erlang uses the NullSoft Install System. The files used to build the installer are in "erts/etc/win32/nsis" (http://github.com/erlang/otp/tree/ccase/r13b04_dev/erts/etc/win32/nsis/). There seems to be two installer scripts: erlang.nsi and erlang20.nsi. They look like they are each used in turn for different versions of the installer system. On the web, I found the following information about using NSIS to modify the path of a system: > http://nsis.sourceforge.net/Environmental_Variables:_append,_prepend,_and_remove_entries I have no idea if this is really useful information. Unfortunately, I don't have the environment necessary to build OTP for Windows, so I can't make a patch for you. I hope you can figure it out or find someone who can. Good luck, and I look forward to seeing the patch come through. On Feb 24, 2010, at 3:25 AM, Max Lapshin wrote: > On Wed, Feb 24, 2010 at 2:22 PM, Jayson Vantuyl wrote: >> Max, >> >> I don't see it in the Release README. Did you submit a patch? >> > > No, because I don't know even where is the windows installer source lays =( > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > -- Jayson Vantuyl kagato@REDACTED From max.lapshin@REDACTED Wed Feb 24 14:21:26 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 24 Feb 2010 16:21:26 +0300 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: References: <45CB2AE9-CE02-47F7-944E-35BE9CA25ECB@souja.net> Message-ID: Oh, thank you for pointing me into sources. I will prepare patch and submit it. I really do require this feature, because erlyvideo users complain that "not working" From tuncer.ayaz@REDACTED Wed Feb 24 14:55:29 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 24 Feb 2010 14:55:29 +0100 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266567436.4073.6.camel@humaira-laptop> <1266572041.4073.8.camel@humaira-laptop> <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> <4ac8254d1002231634x4ac64dd1g623bbb0a745985bb@mail.gmail.com> Message-ID: <4ac8254d1002240555y4acfc317uedf38924af432dc4@mail.gmail.com> On Wed, Feb 24, 2010 at 12:59 PM, Chandru wrote: > On 24 February 2010 00:34, Tuncer Ayaz wrote: >>>> >>>> I just checked, and it doesn't have the changes made by Sean. >>> >>> http://github.com/etnt/eldap/raw/master/test/eldap_fsm.erl >>> seemed to be what you were looking for. >>> >>> Interesting. >> >> I just compared both and the fsm is different. >> >> Chandru, where did you find the archive? >> > > As I said before, this is a locally modified version of eldap. Sean > Hinde made these changes a long time ago. Thanks. Would it make sense to include your modified version in Tobbe's git repo? From kenneth.lundin@REDACTED Wed Feb 24 15:02:43 2010 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Wed, 24 Feb 2010 15:02:43 +0100 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: References: <45CB2AE9-CE02-47F7-944E-35BE9CA25ECB@souja.net> Message-ID: Hi, Long time ago we did update the path in the Windows Installer but we removed it later for several reasons: 1. We don't think it is common practice in Windows installers to update the path 2. A number of problems can arise if the installer updates the path automatically, - where in the path should we put our entry? - what to do if there are several versions of Erlang installed - remove path during uninstall? 3. You may need to restart Windows in order to use the updated path So please don't provide a patch since I don't think we will accept it. By the way we don't update the path on Linux, Solaris etc either. We think it is better to let the user handle the path by himself. In your particular case where you have an application written in Erlang I think you should make an installer for your App and there you can update the path if you want and possibly invoke the Erlang/OTP installer from your installer. We deliver a development system that you install on your system. With this system you develop your application. In order to distribute your application you package it together with a subset of the components in Erlang/OTP (i.e only the components you need) and make your own installer. NSIS is a free Installer maker for Windows that we use. Reltool is a tool that you can use for making your own package. It helps you to create a file tree with the necessary files but it does not help you doing the installer. What might be helpful would be to provide a skeleton for an installer , we have considered that but i can't promise when it will happen. /Kenneth, Erlang/OTP Ericsson On Wed, Feb 24, 2010 at 2:21 PM, Max Lapshin wrote: > Oh, thank you for pointing me into sources. I will prepare patch and submit it. > I really do require this feature, because erlyvideo users complain > that "not working" > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From rtrlists@REDACTED Wed Feb 24 15:41:36 2010 From: rtrlists@REDACTED (Robert Raschke) Date: Wed, 24 Feb 2010 14:41:36 +0000 Subject: [erlang-questions] Re: What about making sense? In-Reply-To: <9b08084c1002201002k1ffc01e9k676b01727588586b@mail.gmail.com> References: <3dbc6d1c1002170718h31c54bablf04880d6300972b7@mail.gmail.com> <9b08084c1002182340n7250406cgeeff1609f231d0eb@mail.gmail.com> <52b3a39d-9772-4bbb-ad21-0cae275ab817@q16g2000yqq.googlegroups.com> <4B7FE751.5080908@gmail.com> <9b08084c1002201002k1ffc01e9k676b01727588586b@mail.gmail.com> Message-ID: <6a3ae47e1002240641x1fa372dbicae013e8d405c662@mail.gmail.com> On Sat, Feb 20, 2010 at 6:02 PM, Joe Armstrong wrote: > > So If you *really* want to learn, try things in this order: > > 1) go on a course > 2) watch a video > 3) read a book > 4) read the documentaion > 5) read some code > > Intriguing, how different learning approaches can be! My preferred order of learning is the exact opposite: Look at the code, if that doesn't make sense, look at the documentation, if it's still opaque and I really need to learn this, get me a book, if that's not helping much, maybe a video might provide insight (but this hasn't happened to me yet), but I have never been to a technical course that was worth it. (There are good technical courses out there, but I just haven't been fortunate enough to attend any.) It is entirely possible that this approach of mine stems from the fact that I never learnt C, Java, Basic, Pascal, Fortran, etc. I learnt to program in some university made up language that had no implementation outside the uni computers. So I never got swamped by the gunk that most languages carry around as libraries while learning. There was never any aspect of glueing stuff together. All exercises in the first 3 semesters were sized such that they were impossible to solve on your own, you had to have groups of 3-4 people working together (2 could work if stretched). Later semesters taught content, not languages, you implemented in whatever language you liked or thought appropriate (sometimes the tools at your disposal might be very restricted, for the OS course, for example). But in general, languages were tools you had to pick up yourself. Having heard a lot of other's experiences in learning "programming" (CS, Informatics, etc.), I have come to the conclusion that I have been extraordinarely lucky in my university experience. Robby From humaira.surve@REDACTED Wed Feb 24 15:58:50 2010 From: humaira.surve@REDACTED (Humaira Surve) Date: Wed, 24 Feb 2010 16:58:50 +0200 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <4ac8254d1002240555y4acfc317uedf38924af432dc4@mail.gmail.com> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266572041.4073.8.camel@humaira-laptop> <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> <4ac8254d1002231634x4ac64dd1g623bbb0a745985bb@mail.gmail.com> <4ac8254d1002240555y4acfc317uedf38924af432dc4@mail.gmail.com> Message-ID: <930e5b151002240658h79cb6be5oc579abdf43dc33b1@mail.gmail.com> Hi Chandru, Tuncer, I've been playing around with the FSM version but I'm struggling to run it. My logs say that count:inc cannot be found. Do either of you know where to find this count library? I think it might be nice to have a copy of the FSM version on a central repository. I'm happy to assist with uploading it / writing up some simple install notes once I have it working. Regards, Humaira On Wed, Feb 24, 2010 at 3:55 PM, Tuncer Ayaz wrote: > On Wed, Feb 24, 2010 at 12:59 PM, Chandru > wrote: > > On 24 February 2010 00:34, Tuncer Ayaz wrote: > >>>> > >>>> I just checked, and it doesn't have the changes made by Sean. > >>> > >>> http://github.com/etnt/eldap/raw/master/test/eldap_fsm.erl > >>> seemed to be what you were looking for. > >>> > >>> Interesting. > >> > >> I just compared both and the fsm is different. > >> > >> Chandru, where did you find the archive? > >> > > > > As I said before, this is a locally modified version of eldap. Sean > > Hinde made these changes a long time ago. > > Thanks. Would it make sense to include your modified version in > Tobbe's git repo? > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From g@REDACTED Wed Feb 24 16:06:37 2010 From: g@REDACTED (Garrett Smith) Date: Wed, 24 Feb 2010 09:06:37 -0600 Subject: [erlang-questions] Give Your Erlang Program A CLI with ErlCtl In-Reply-To: <606E98F7-8C10-4206-9734-F4BFE2D455BC@scatterbit.com> References: <606E98F7-8C10-4206-9734-F4BFE2D455BC@scatterbit.com> Message-ID: On Tue, Feb 23, 2010 at 9:51 PM, Jayson Vantuyl wrote: > Hello everybody, > > I just released a little library that I thought might be handy for everybody. ?It's a one-stop-shop for giving your daemon-process a powerful command-line interface. > > Read about it on my blog, here: > >> http://needlesslymessianic.com/2010/02/21/announcing-erlctl-0-1 This looks great! From chandrashekhar.mullaparthi@REDACTED Wed Feb 24 16:08:16 2010 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Wed, 24 Feb 2010 15:08:16 +0000 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <930e5b151002240658h79cb6be5oc579abdf43dc33b1@mail.gmail.com> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <1266572041.4073.8.camel@humaira-laptop> <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> <4ac8254d1002231634x4ac64dd1g623bbb0a745985bb@mail.gmail.com> <4ac8254d1002240555y4acfc317uedf38924af432dc4@mail.gmail.com> <930e5b151002240658h79cb6be5oc579abdf43dc33b1@mail.gmail.com> Message-ID: Hi, On 24 February 2010 14:58, Humaira Surve wrote: > Hi Chandru, Tuncer, > > I've been playing around with the FSM version but I'm struggling to run it. > > My logs say that count:inc cannot be found. Do either of you know where to > find this count library? > Sorry about that, I forgot to remove those calls. The 'count' module is part of an internal application which we use to record statistics. Feel free to rip out all count:inc invocations. > I think it might be nice to have a copy of the FSM version on a central > repository. I'm happy to assist with uploading it / writing up some simple > install notes once I have it working. github? cheers Chandru From anders@REDACTED Wed Feb 24 16:33:27 2010 From: anders@REDACTED (Anders Dahlin) Date: Wed, 24 Feb 2010 16:33:27 +0100 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: References: <45CB2AE9-CE02-47F7-944E-35BE9CA25ECB@souja.net> Message-ID: <4B8546C7.9060200@dahlinenergy.se> Hi, The windows distribution seems to be lacking files in the tools-2.6.5.1/emacs directory. I only get: erlang-eunit.el erlang-start.el erlang.el README test.erl.indented test.erl.orig Brgds, /Anders From hd2010@REDACTED Wed Feb 24 17:17:16 2010 From: hd2010@REDACTED (Henning Diedrich) Date: Wed, 24 Feb 2010 17:17:16 +0100 Subject: [erlang-questions] Give Your Erlang Program A CLI with ErlCtl In-Reply-To: References: <606E98F7-8C10-4206-9734-F4BFE2D455BC@scatterbit.com> Message-ID: <4B85510C.2060507@eonblast.com> Cool, thanks! Garrett Smith wrote: > On Tue, Feb 23, 2010 at 9:51 PM, Jayson Vantuyl wrote: > >> Hello everybody, >> >> I just released a little library that I thought might be handy for everybody. It's a one-stop-shop for giving your daemon-process a powerful command-line interface. >> >> Read about it on my blog, here: >> >> >>> http://needlesslymessianic.com/2010/02/21/announcing-erlctl-0-1 >>> > > This looks great! > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From dgud@REDACTED Wed Feb 24 17:39:24 2010 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 24 Feb 2010 17:39:24 +0100 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: <4B8546C7.9060200@dahlinenergy.se> References: <45CB2AE9-CE02-47F7-944E-35BE9CA25ECB@souja.net> <4B8546C7.9060200@dahlinenergy.se> Message-ID: <93df43b61002240839s52424116x43c754e5f0d71925@mail.gmail.com> Sigh.. They are available here: http://github.com/erlang/otp/raw/ccase/r13b04_dev/lib/tools/emacs/erlang-skels-old.el http://github.com/erlang/otp/raw/ccase/r13b04_dev/lib/tools/emacs/erlang-skels.el /Dan On Wed, Feb 24, 2010 at 4:33 PM, Anders Dahlin wrote: > Hi, > > The windows distribution seems to be lacking files in the > tools-2.6.5.1/emacs directory. I only get: > > erlang-eunit.el > erlang-start.el > erlang.el > README > test.erl.indented > test.erl.orig > > Brgds, > /Anders > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From jan@REDACTED Wed Feb 24 17:32:39 2010 From: jan@REDACTED (Jan Lehnardt) Date: Wed, 24 Feb 2010 08:32:39 -0800 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: <97619b171002231203p17d4c293g90dc8664aa799fbd@mail.gmail.com> References: <97619b171002231203p17d4c293g90dc8664aa799fbd@mail.gmail.com> Message-ID: <3DAC7D4F-9A72-40D8-888E-7DE68824347D@apache.org> On 23 Feb 2010, at 12:03, Rapsey wrote: > MongoDB looses data? First time I've heard mongodb having such an issue. It's a feature (not kidding): http://blog.mongodb.org/post/381927266/what-about-durability NoSQL is about finding the right solution for your data and situation. Trading speed for data durability is definitely valid and useful, but not generally applicable. Cheers Jan -- > > > Sergej > > On Tue, Feb 23, 2010 at 7:52 PM, Max Lapshin wrote: > >> Have you profiled usual database? 1000 per sec is not too much for >> postgres or mysql. >> And they don't loose data like MongoDB. >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> From tuncer.ayaz@REDACTED Wed Feb 24 18:32:38 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Wed, 24 Feb 2010 18:32:38 +0100 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> <4ac8254d1002231634x4ac64dd1g623bbb0a745985bb@mail.gmail.com> <4ac8254d1002240555y4acfc317uedf38924af432dc4@mail.gmail.com> <930e5b151002240658h79cb6be5oc579abdf43dc33b1@mail.gmail.com> Message-ID: <4ac8254d1002240932v5cdc83c3o3a6ee849f0d62109@mail.gmail.com> On Wed, Feb 24, 2010 at 4:08 PM, Chandru wrote: > Hi, > > On 24 February 2010 14:58, Humaira Surve wrote: >> Hi Chandru, Tuncer, >> >> I've been playing around with the FSM version but I'm struggling to run it. >> >> My logs say that count:inc cannot be found. Do either of you know where to >> find this count library? >> > > Sorry about that, I forgot to remove those calls. The 'count' module > is part of an internal application which we use to record statistics. > Feel free to rip out all count:inc invocations. > >> I think it might be nice to have a copy of the FSM version on a central >> repository. I'm happy to assist with uploading it / writing up some simple >> install notes once I have it working. > > github? I talked to Tobbe and he would be glad to accept relevant changes. He also told me that ejabberd carries their own eldap version. I'm not heavily using LDAP myself right now so it might be best if you work on this. I've only been trying to streamline the different eldap versions into one canonical repo and work from there. From martti.kuparinen@REDACTED Wed Feb 24 19:02:50 2010 From: martti.kuparinen@REDACTED (Martti Kuparinen) Date: Wed, 24 Feb 2010 20:02:50 +0200 Subject: Getting OSI approval for the Erlang Public License Message-ID: <4B8569CA.8090703@iki.fi> Has there been any attempt to submit the EPL (http://www.erlang.org/EPLICENSE) for OSI (http://www.opensource.org/approval) review? Personally I don't care about this but I'm updating the Erlang package in NetBSD pkgsrc and someone raised a question about the OSI/FSF approval status... Martti From kaykay.unique@REDACTED Wed Feb 24 19:33:32 2010 From: kaykay.unique@REDACTED (Kay Kay) Date: Wed, 24 Feb 2010 10:33:32 -0800 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: References: Message-ID: <4B8570FC.8030904@gmail.com> This is great. Curious - how close is the integration of the release with the ubuntu repositories , so that it would be available for update as well. On 2/24/10 3:00 AM, Kenneth Lundin wrote: > Bug fix release : otp_src_R13B04 > Build date : 2010-02-23 > > This is R13B04, the fourth maintenance release for the R13B major release. > > You can find the README file for the release at > > http://www.erlang.org/download/otp_src_R13B04.readme > > The source distribution and binary distribution for Windows can be > downloaded from > > http://www.erlang.org/download/otp_src_R13B04.tar.gz > http://www.erlang.org/download/otp_win32_R13B04.exe > > The distribution can also be downloaded using the BitTorrent > protocol. Use the following torrent files to download the source > distribution and binary distribution for Windows: > > http://www.erlang.org/download/otp_src_R13B04.tar.gz.torrent > http://www.erlang.org/download/otp_win32_R13B04.exe.torrent > > Note: To unpack the TAR archive you need a GNU TAR compatible program. > > For installation instructions please read the README file that is part > of the distribution. > > The on-line documentation can be found at: http://www.erlang.org/doc/ > You can also download the complete HTML documentation or the Unix manual files > > http://www.erlang.org/download/otp_doc_html_R13B04.tar.gz > http://www.erlang.org/download/otp_doc_man_R13B04.tar.gz > > We also want to thank those that sent us patches, suggestions and bug > reports, > > The OTP Team > Kenneth Lundin, Erlang/OTP, Ericsson AB > > ________________________________________________________________ > erlang-questions mailing list. See http://www.erlang.org/faq.html > erlang-questions (at) erlang.org > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From vik@REDACTED Wed Feb 24 20:53:28 2010 From: vik@REDACTED (Vik Olliver) Date: Thu, 25 Feb 2010 08:53:28 +1300 Subject: [erlang-questions] Getting OSI approval for the Erlang Public License In-Reply-To: <4B8569CA.8090703@iki.fi> References: <4B8569CA.8090703@iki.fi> Message-ID: <4B8583B8.5020202@catalyst.net.nz> Martti Kuparinen wrote: > Has there been any attempt to submit the EPL > (http://www.erlang.org/EPLICENSE) for OSI > (http://www.opensource.org/approval) review? > > Personally I don't care about this but I'm updating the Erlang package > in NetBSD pkgsrc and someone raised a question about the OSI/FSF > approval status... I do care. There are a number of competitions and awards that encourage program development which are only applicable to OSI-licenced software. It'd be a shame if Erlang was excluded from those. Plus government procurement is starting to move towards projects using OSI-approved licences. Vik :v) From icfp.publicity@REDACTED Wed Feb 24 21:10:32 2010 From: icfp.publicity@REDACTED (Wouter Swierstra) Date: Wed, 24 Feb 2010 21:10:32 +0100 Subject: ICFP 2010: Second call for papers Message-ID: <53ff55481002241210w59bdc613ya85725c107f47ce5@mail.gmail.com> ===================================================================== Second Call for Papers ICFP 2010: International Conference on Functional Programming Baltimore, Maryland, 27 -- 29 September 2010 http://www.icfpconference.org/icfp2010 ===================================================================== Important Dates (at 14:00 UTC) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Submission: 2 April 2010 Author response: 24 -- 25 May 2010 Notification: 7 June 2010 Final papers due: 12 July 2010 Scope ~~~~~ ICFP 2010 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 or concurrency. Particular topics of interest include * Language Design: type systems; concurrency and distribution; modules; components and composition; metaprogramming; relations to object-oriented or logic programming; interoperability * Implementation: abstract machines; compilation; compile-time and run-time optimization; memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components or low-level machine resources * Software-Development Techniques: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling * Foundations: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects * Transformation and Analysis: abstract interpretation; partial evaluation; program transformation; program calculation; program proof * Applications and Domain-Specific Languages: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia programming; scripting; system administration; security; education * Functional Pearls: elegant, instructive, and fun essays on functional programming The conference also solicits Experience Reports, which are short papers that provide evidence that functional programming really works or describe obstacles that have kept it from working in a particular application. Abbreviated instructions for authors ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ By 2 April 2010, 14:00 UTC, submit an abstract of at most 300 words and a full paper of at most 12 pages (6 pages for an Experience Report), including bibliography and figures. The deadline will be strictly enforced and papers exceeding the page limits will be summarily rejected. Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. A submission will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. Functional Pearls and Experience Reports are separate categories of papers that need not report original research results and must be marked as such at the time of submission. Detailed guidelines on both categories are on the conference web site. Each submission must adhere to SIGPLAN's republication policy, as explained on the web at http://www.acm.org/sigplan/republicationpolicy.htm. Proceedings will be published by ACM Press. Authors of accepted submissions are expected to transfer the copyright to the ACM. Presentations will be videotaped and released online if the presenter consents by signing an additional permission form at the time of the presentation. Formatting: Submissions must be in PDF format printable in black and white on US Letter sized paper and interpretable by Ghostscript. If this requirement is a hardship, make contact with the program chair at least one week before the deadline. Papers must adhere to the standard ACM conference format: two columns, nine-point font on a ten-point baseline, with columns 20pc (3.33in) wide and 54pc (9in) tall, with a column gutter of 2pc (0.33in). A suitable document template for LATEX is available from SIGPLAN at http://www.acm.org/sigs/sigplan/authorInformation.htm. Submission: Submissions will be accepted electronically at a URL to be named later. Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Author response: Authors will have a 48-hour period, starting at 14:00 UTC on 24 May 2010, to read and respond to reviews. Special Journal Issue: There will be a special issue of the Journal of Functional Programming with papers from ICFP 2010. The program committee will invite the authors of select accepted papers to submit a journal version to this issue. Organization ~~~~~~~~~~~~ Conference Chair Paul Hudak, Yale University Program Chair Stephanie Weirich, University of Pennsylvania Program Committee: Umut Acar, Max Planck Institute for Software Systems Zena Ariola, University of Oregon James Cheney, University of Edinburgh Peter Dybjer, Chalmers University of Technology Robert Bruce Findler, Northwestern University Andy Gill, Kansas University Fritz Henglein, University of Copenhagen Michael Hicks, University of Maryland, College Park Patricia Johann, University of Strathclyde Andres L?h, Utrecht University Simon L. Peyton Jones, Microsoft Research Didier R?my, INRIA Paris-Rocquencourt John Reppy, University of Chicago Manuel Serrano, INRIA Sophia-Antipolis Matthieu Sozeau, Harvard University From kenji.rikitake@REDACTED Thu Feb 25 00:54:04 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Thu, 25 Feb 2010 08:54:04 +0900 Subject: Erlang R13B04 *EXPERIMENTAL* FreeBSD port Message-ID: <20100224235404.GA74854@k2r.org> FreeBSD *EXPERIMENTAL* (unofficial) port for R13B04 available at http://www.ne.jp/asahi/bdx/info/software/erlang-r13b04,1-beta-20100225.tar.gz KNOWN issues: * NO JAVA test yet (WITHOUT_JAVA=yes set in the Makefile) * some patches are not applied (et and wx; both libs build OK) Giacomo: please check this one for building the official port. Regards, Kenji Rikitake From ok@REDACTED Thu Feb 25 02:47:05 2010 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 25 Feb 2010 14:47:05 +1300 Subject: [erlang-questions] Why it is a illegal guard expression? In-Reply-To: References: Message-ID: <01F0CB47-4FF1-4A66-B410-7C6F773B0BF9@cs.otago.ac.nz> On Feb 24, 2010, at 4:42 PM, ??? wrote: > Hi, I am a newer of erlang. I wrote a module to find all files(no > directory) > under a directory, including its subdirectory: > -module(lib_test). > -export([list_files/1]). > > list_files(Path)-> > {ok, FileList} = file:list_dir(Path), > process_filelist(FileList, []). > > process_filelist([File|FileList], Files)-> > if > filelib:is_dir(File) -> > {ok, NewFileList} = file:list_dir(File), > process_filelist(NewFileList, Files); > true -> > process_filelist(FileList, [File|Files]) > end; > process_filelist([], Files) -> > Files. > > But I fail to compile this file, because " filelib:is_dir(File) ->" is > illegal guard expression. So Why it is illegal? What should I write? What did you find when you looked in the reference manual? What does it say you are allowed to use in a guard? You should write process_file_list([Path|Paths], Files) -> case filelib:is_dir(Path) of true -> {ok, Children} = file:list_dir(Path), Children_Paths = [filename:join(Path, Child) || Child <- Children], process_file_list(Paths, process_file_list(Children_Paths, Files)) ; false -> process_file_list(Paths, [Path|Files]) end; process_file_list([], Files) -> Files. There are four issues. (1) If your function is processing [A,B,C] and A is a directory, it will completely forget about B and C. I suspect that you don't want that. If you do, you really really need to make that explicit in a comment. (2) The documentation for file:list_dir/1 does not make it clear whether you get just the simple name of each child or the simple name with the directory prefix. The second is what you *need* if you want to recursively walk the directory tree; the first is what you *get*. (3) Not everything that isn't a directory is a file. If you simply define a file to be anything that is not a directory, OK, but if you think a "file" is what UNIX calls a "regular file", that's not what you get. Arguably you should be using case (Path) of directory -> ... ; file -> ... ; socket -> ... ; device -> ... ; other -> ... ; {error,_} -> ... end This is an unexpected benefit of the limitations of guards; Booleans-and-ifs are very often the wrong thing to do anyway. (4) I dare say that you understand perfectly well that a single directory you're not allowed to search inside will bring your whole function crashing down rather than just skipping that directory, but it's definitely worth a comment to remind less savvy readers. From ok@REDACTED Thu Feb 25 02:57:18 2010 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 25 Feb 2010 14:57:18 +1300 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: <20100224085609.GA14027@erix.ericsson.se> References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> <20100224085609.GA14027@erix.ericsson.se> Message-ID: On Feb 24, 2010, at 9:56 PM, Raimo Niskanen wrote: > I think this kind of construct is harder to do without the of..catch > part: > > Handle = resource:open("foo.txt"), > try resource:read(Handle) of > {ok, Data} -> > foo(Data); > Error -> > Error > catch > error:Reason -> > {error,Reason} > after > resource:close(Handle) > end The tricky thing here is that foo(Data) is *outside* the scope of the "catch" *inside* the scsope of the "after" if I haven't blown all my fuses entirely. Useful, this is. Easy to take into acount when reading, it isn't. I think I'd want some comments, being a Bear of very little Brain. Handle = resource:open("foo.txt"), try % catch? after? resource:read(Handle) % yes yes of {ok, Data} -> foo(Data) % no yes ; Error -> Error catch error:Reason -> {error,Reason} after resource:close(Handle) % no no end Perhaps nested tries and cases might actually be easier to read. From ok@REDACTED Thu Feb 25 03:07:03 2010 From: ok@REDACTED (Richard O'Keefe) Date: Thu, 25 Feb 2010 15:07:03 +1300 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> Message-ID: <5C25C6CD-C4E4-434A-AD07-5EA34B50C258@cs.otago.ac.nz> On Feb 25, 2010, at 5:58 AM, Tony Finch wrote: > On Wed, 24 Feb 2010, Richard O'Keefe wrote: >> >> It does make sense, but it would be really nice to see a couple of >> examples where try .. of .. catch .. end was the right thing to do. > > Is this not answered by the papers? > > http://www.erlang.org/workshop/2004/exception.pdf Not really. Papers don't have room for realistic examples. From mevans@REDACTED Thu Feb 25 03:13:20 2010 From: mevans@REDACTED (Evans, Matthew) Date: Wed, 24 Feb 2010 21:13:20 -0500 Subject: Erlang linked in drivers, ErlDrvEntry structure Message-ID: Hi All, I've been looking at linkedin drivers a little. I 'm trying to find a description of all the handler functions that are contained in the ErlDrvEntry structure. Obviously startup and shutdown make sense, but what about all the others (see the example below)? When are they called (for example ready_input, handle, control, process)? Pointers to documentation would be helpful, the Erlang documentation in http://www.erlang.org/doc/man/erl_driver.html seems to be missing quite a few of them.... Many thanks Matt static ErlDrvEntry basic_driver_entry = { NULL, /* init */ start, /* startup */ stop, /* shutdown */ NULL, /* output */ NULL, /* ready_input */ NULL, /* ready_output */ "basic_drv", /* the name of the driver */ NULL, /* finish */ NULL, /* handle */ NULL, /* control */ NULL, /* timeout */ process, /* process */ NULL, /* ready_async */ NULL, /* flush */ NULL, /* call */ NULL, /* event */ ERL_DRV_EXTENDED_MARKER, /* ERL_DRV_EXTENDED_MARKER */ ERL_DRV_EXTENDED_MAJOR_VERSION, /* ERL_DRV_EXTENDED_MAJOR_VERSION */ ERL_DRV_EXTENDED_MAJOR_VERSION, /* ERL_DRV_EXTENDED_MINOR_VERSION */ ERL_DRV_FLAG_USE_PORT_LOCKING /* ERL_DRV_FLAGs */ }; From jay@REDACTED Thu Feb 25 02:33:12 2010 From: jay@REDACTED (Jay Nelson) Date: Wed, 24 Feb 2010 17:33:12 -0800 Subject: Tilera processors Message-ID: <2E348378-11C7-4134-B3C6-726783DC5AEA@duomark.com> I have heard some interest from others in the new Tilera chips, and Ericsson has kindly arranged for the erlang code to run on Tilera, so I thought I would collect a little background information on erlang programmer / user interest in the Tilera processor. If anyone has specific interest, questions or ideas related to Tilera, you can contact me through my website at http://www.duomark.com/ If you would like to contribute to the data collection, I have a poll form at http://duomark.wufoo.com/reports/tilera-results/ The form is valid from Thursday, Feb 25 at midnight until Thursday, March 4 (not sure what time zone, I am GMT -8:00), so you may have to wait a half a day or more before submitting the first response. I will post a link to the final report with a summary of the answers at the end of next week after receiving submissions. The form is limited to 100 responses. @joe: the best form builder / poll taker is at http://www.wufoo.com/ jay From jay@REDACTED Thu Feb 25 02:37:07 2010 From: jay@REDACTED (Jay Nelson) Date: Wed, 24 Feb 2010 17:37:07 -0800 Subject: Tilera processors Message-ID: And of course, I published the wrong link for the questionnaire. Use this one instead: http://duomark.wufoo.com/forms/tilera-questionnaire/ jay From sergey.miryanov@REDACTED Thu Feb 25 06:25:02 2010 From: sergey.miryanov@REDACTED (sergey-miryanov) Date: Wed, 24 Feb 2010 21:25:02 -0800 (PST) Subject: Erlang linked in drivers, ErlDrvEntry structure In-Reply-To: References: Message-ID: <6702b8de-3380-411f-9fa5-86dcf5018d48@a18g2000yqc.googlegroups.com> Do you see this: http://www.erlang.org/doc/man/driver_entry.html? On Feb 25, 7:13?am, "Evans, Matthew" wrote: > Hi All, > > I've been looking at linkedin drivers a little. I 'm trying to find a description of all the handler functions that are contained in the ErlDrvEntry structure. Obviously startup and shutdown make sense, but what about all the others (see the example below)? When are they called (for example ready_input, handle, control, process)? Pointers to documentation would be helpful, the Erlang documentation inhttp://www.erlang.org/doc/man/erl_driver.htmlseems to be missing quite a few of them.... > > Many thanks > > Matt > > static ErlDrvEntry basic_driver_entry = { > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* init */ > ? ? start, ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* startup */ > ? ? stop, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* shutdown */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* output */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_input */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_output */ > ? ? "basic_drv", ? ? ? ? ? ? ? ? ? ? ?/* the name of the driver */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* finish */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* handle */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* control */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* timeout */ > ? ? process, ? ? ? ? ? ? ? ? ? ? ? ? ?/* process */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_async */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* flush */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* call */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* event */ > ? ? ERL_DRV_EXTENDED_MARKER, ? ? ? ? ?/* ERL_DRV_EXTENDED_MARKER */ > ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MAJOR_VERSION */ > ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MINOR_VERSION */ > ? ? ERL_DRV_FLAG_USE_PORT_LOCKING ? ? /* ERL_DRV_FLAGs */ > > }; > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > Seehttp://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED From kenji.rikitake@REDACTED Thu Feb 25 06:33:45 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Thu, 25 Feb 2010 14:33:45 +0900 Subject: [erlang-questions] A sender() BIF? In-Reply-To: <3B2D56CF-C766-4453-A4FE-858C0CC425D8@cs.otago.ac.nz> References: <4JyGEm7n.1266758439.0683540.leap@gol.com> <33A39648E8D6FF438E3907E5396598E001C11278EC@NYWEXMBX2128.msad.ms.com> <3B2D56CF-C766-4453-A4FE-858C0CC425D8@cs.otago.ac.nz> Message-ID: <20100225053345.GA13972@k2r.org> In the message <3B2D56CF-C766-4453-A4FE-858C0CC425D8@REDACTED> dated Tue, Feb 23, 2010 at 02:54:14PM +1300, Richard O'Keefe writes: > I don't think it is appropriate to hack on the fundamental machinery > used within a node or trusted cluster (plain Erlang message passing) > to satisfy the needs of less trusting applications. Not because > there is anything wrong with security, but because once you are "in" > with the Erlang distribution protocol, you are _totally_ in, and > that's not how to get good security. +1. Layer 3 (IPsec or VPN) is a practical way. inet_ssl_dist on Erlang/OTP looks too complex to me, and I wonder whether it works on R13B04, though I once tested on an R12 release. jungerl once tried to implement ssh_dist, but it's way too old and I feel it's not worth rewriting so long as I skimmed the code. Correct me if I'm wrong. Kenji Rikitake From hd2010@REDACTED Thu Feb 25 08:17:39 2010 From: hd2010@REDACTED (Henning Diedrich) Date: Thu, 25 Feb 2010 08:17:39 +0100 Subject: [erlang-questions] Selecting a speedy NoSQL datastore In-Reply-To: <4765D998-922A-40F6-B7FA-5814C04460F7@souja.net> References: <97619b171002231203p17d4c293g90dc8664aa799fbd@mail.gmail.com> <4765D998-922A-40F6-B7FA-5814C04460F7@souja.net> Message-ID: <4B862413.6060104@eonblast.com> Scalaris is the one that promises strong consistency. The trade off is that it is not as tolerant with the number of copies that may go amiss at any time. Meaning that while Riak, CouchDB et al. could recover data from just one surviving node, Scalaris currently needs at least 3 out of 4 to recover (floor(n/2+1) nodes of n). That's because they use Paxos, which may be the best you can do to be consistent, not only "Eventual Consistent". VoltDB may be interesting if you need throughput, and don't care what the data base is implemented in: http://www.voltdb.com. This is the newest creation of Mike Stonebraker and it's optimized for extreme throughput at the cost of some latency. This means that you can write a lot at once it just may take a bit (~msecs) to execute. For OLTP that should be just what you want. You can sign up to get information on it at their site and/or learn more about the principle they apply at http://db.cs.yale.edu/hstore/ VoltDB is SQL, albeit a small but essential subset, and ACID. The main trade off is that there are no ad hoc queries with VoltDB, which is not really a disadvantage compared to NoSQLs. It's currently in beta. Thanks to Bob Ippolito for pointing me to their stuff. Henning Jayson Vantuyl wrote: > This is not entirely so simple. MongoDB does not ensure durability for a single machine database. Instead, they require you to use replication across multiple servers. When properly deployed on redundant storage, you get eventually-consistent durability across the system. > > Read a little about it here: > > http://blog.mongodb.org/post/381927266/what-about-durability > > Their rationale, which is actually quite insightful, is that anyone who is really concerned with not losing data (and understands the problem) wouldn't want just one machine durability anyway--especially with the weaker guarantees that they've otherwise accepted due to eventual-consistency. > > Also, note that Mongo Sharding gives you the same replication plus horizontal scalability. Right now, Mongo, Riak, and Dynomite are the NoSQLs that really seem to scale. All of them are apparently eventually-consistent. Among those, Mongo is the best performing. > > Mongo doesn't "lose data" any more than the others. More directly, in an eventually-consistent system, there is always a point where you can lose the partition of nodes that has the data. > > On Feb 23, 2010, at 12:06 PM, Max Lapshin wrote: > > >> On Tue, Feb 23, 2010 at 11:03 PM, Rapsey wrote: >> >>> MongoDB looses data? First time I've heard mongodb having such an issue. >>> >>> >> Yes, we have experienced this problem on staging tests and stopped >> experiments with nosql after it. >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > > From vladdu55@REDACTED Thu Feb 25 14:58:41 2010 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 25 Feb 2010 14:58:41 +0100 Subject: debugging remote node Message-ID: <95be1d3b1002250558s48096ed0n45209d609f2ba469@mail.gmail.com> Hi! When debugging remote nodes, do they need to share filesystem (or have the files in the same place) with the "current" machine? Looking in the code I see that read_file is used, which would make me say that this is a requirement, but there is enough magic going on that there might be some other path that doesn't use that. Yes, I tried it in practice and it didn't work (while it worked with a system with shared filesystem), but I'd like to get it confirmed (or to get pointed to the relevant part of the docs). best regards, Vlad From mevans@REDACTED Thu Feb 25 15:36:15 2010 From: mevans@REDACTED (Evans, Matthew) Date: Thu, 25 Feb 2010 09:36:15 -0500 Subject: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure In-Reply-To: <6702b8de-3380-411f-9fa5-86dcf5018d48@a18g2000yqc.googlegroups.com> References: <6702b8de-3380-411f-9fa5-86dcf5018d48@a18g2000yqc.googlegroups.com> Message-ID: Many thanks...that's just what I was after -----Original Message----- From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of sergey-miryanov Sent: Thursday, February 25, 2010 12:25 AM To: erlang-questions@REDACTED Subject: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure Do you see this: http://www.erlang.org/doc/man/driver_entry.html? On Feb 25, 7:13?am, "Evans, Matthew" wrote: > Hi All, > > I've been looking at linkedin drivers a little. I 'm trying to find a description of all the handler functions that are contained in the ErlDrvEntry structure. Obviously startup and shutdown make sense, but what about all the others (see the example below)? When are they called (for example ready_input, handle, control, process)? Pointers to documentation would be helpful, the Erlang documentation inhttp://www.erlang.org/doc/man/erl_driver.htmlseems to be missing quite a few of them.... > > Many thanks > > Matt > > static ErlDrvEntry basic_driver_entry = { > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* init */ > ? ? start, ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* startup */ > ? ? stop, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* shutdown */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* output */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_input */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_output */ > ? ? "basic_drv", ? ? ? ? ? ? ? ? ? ? ?/* the name of the driver */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* finish */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* handle */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* control */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* timeout */ > ? ? process, ? ? ? ? ? ? ? ? ? ? ? ? ?/* process */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_async */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* flush */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* call */ > ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* event */ > ? ? ERL_DRV_EXTENDED_MARKER, ? ? ? ? ?/* ERL_DRV_EXTENDED_MARKER */ > ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MAJOR_VERSION */ > ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MINOR_VERSION */ > ? ? ERL_DRV_FLAG_USE_PORT_LOCKING ? ? /* ERL_DRV_FLAGs */ > > }; > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > Seehttp://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED ________________________________________________________________ erlang-questions (at) erlang.org mailing list. See http://www.erlang.org/faq.html To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED From paul.joseph.davis@REDACTED Thu Feb 25 15:50:38 2010 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Thu, 25 Feb 2010 09:50:38 -0500 Subject: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure In-Reply-To: References: <6702b8de-3380-411f-9fa5-86dcf5018d48@a18g2000yqc.googlegroups.com> Message-ID: Matthew, If you're willing to play near the edge you might want to check out NIF's [1]. They're pretty awesome but have only been around for a couple releases. Paul Davis [1] http://www.erlang.org/doc/man/erl_nif.html On Thu, Feb 25, 2010 at 9:36 AM, Evans, Matthew wrote: > Many thanks...that's just what I was after > > -----Original Message----- > From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of sergey-miryanov > Sent: Thursday, February 25, 2010 12:25 AM > To: erlang-questions@REDACTED > Subject: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure > > Do you see this: http://www.erlang.org/doc/man/driver_entry.html? > > On Feb 25, 7:13?am, "Evans, Matthew" wrote: >> Hi All, >> >> I've been looking at linkedin drivers a little. I 'm trying to find a description of all the handler functions that are contained in the ErlDrvEntry structure. Obviously startup and shutdown make sense, but what about all the others (see the example below)? When are they called (for example ready_input, handle, control, process)? Pointers to documentation would be helpful, the Erlang documentation inhttp://www.erlang.org/doc/man/erl_driver.htmlseems to be missing quite a few of them.... >> >> Many thanks >> >> Matt >> >> static ErlDrvEntry basic_driver_entry = { >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* init */ >> ? ? start, ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* startup */ >> ? ? stop, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* shutdown */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* output */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_input */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_output */ >> ? ? "basic_drv", ? ? ? ? ? ? ? ? ? ? ?/* the name of the driver */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* finish */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* handle */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* control */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* timeout */ >> ? ? process, ? ? ? ? ? ? ? ? ? ? ? ? ?/* process */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_async */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* flush */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* call */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* event */ >> ? ? ERL_DRV_EXTENDED_MARKER, ? ? ? ? ?/* ERL_DRV_EXTENDED_MARKER */ >> ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MAJOR_VERSION */ >> ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MINOR_VERSION */ >> ? ? ERL_DRV_FLAG_USE_PORT_LOCKING ? ? /* ERL_DRV_FLAGs */ >> >> }; >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> Seehttp://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From hakan@REDACTED Thu Feb 25 16:11:29 2010 From: hakan@REDACTED (=?ISO-8859-1?Q?H=E5kan_Mattsson?=) Date: Thu, 25 Feb 2010 16:11:29 +0100 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: <93df43b61002240839s52424116x43c754e5f0d71925@mail.gmail.com> References: <45CB2AE9-CE02-47F7-944E-35BE9CA25ECB@souja.net> <4B8546C7.9060200@dahlinenergy.se> <93df43b61002240839s52424116x43c754e5f0d71925@mail.gmail.com> Message-ID: <922d05851002250711p6f7fd6c9hddfbfcc56d19a311@mail.gmail.com> As the branch "ccase/r13b04_dev" now has been replaced with "dev" the files are found here: http://github.com/erlang/otp/raw/dev/lib/tools/emacs/erlang-skels-old.el http://github.com/erlang/otp/raw/dev/lib/tools/emacs/erlang-skels.el /H?kan On Wed, Feb 24, 2010 at 5:39 PM, Dan Gudmundsson wrote: > Sigh.. > > They are available here: > > http://github.com/erlang/otp/raw/ccase/r13b04_dev/lib/tools/emacs/erlang-skels-old.el > http://github.com/erlang/otp/raw/ccase/r13b04_dev/lib/tools/emacs/erlang-skels.el > > /Dan > > On Wed, Feb 24, 2010 at 4:33 PM, Anders Dahlin wrote: >> Hi, >> >> The windows distribution seems to be lacking files in the >> tools-2.6.5.1/emacs directory. I only get: >> >> erlang-eunit.el >> erlang-start.el >> erlang.el >> README >> test.erl.indented >> test.erl.orig >> >> Brgds, >> /Anders From dmercer@REDACTED Thu Feb 25 16:36:27 2010 From: dmercer@REDACTED (David Mercer) Date: Thu, 25 Feb 2010 09:36:27 -0600 Subject: [erlang-questions] Unexpected try/catch behaviour In-Reply-To: References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> <20100224085609.GA14027@erix.ericsson.se> Message-ID: <09B9269BA04C487C839EA417D6F96BFC@SSI.CORP> On February 24, 2010, Richard O'Keefe wrote: > On Feb 24, 2010, at 9:56 PM, Raimo Niskanen wrote: > > I think this kind of construct is harder to do without the of..catch > > part: > > > > Handle = resource:open("foo.txt"), > > try resource:read(Handle) of > > {ok, Data} -> > > foo(Data); > > Error -> > > Error > > catch > > error:Reason -> > > {error,Reason} > > after > > resource:close(Handle) > > end > > The tricky thing here is that foo(Data) is > *outside* the scope of the "catch" > *inside* the scsope of the "after" > if I haven't blown all my fuses entirely. > > Useful, this is. Easy to take into acount when reading, it isn't. That is a good point. Sounds like the ordering of the clauses should be changed from try.of.catch.after to try.catch.of.after. Try this on for size: try resource:read(Handle) catch error:Reason -> {error,Reason} of {ok, Data} -> foo(Data); Error -> Error after resource:close(Handle) end No, that doesn't really work, since it leads you to believe that the "of" applies also to the result of the "catch." Would dispensing with the catch clause entirely help? I'm not sure that a valid "*catch* match" (with the colon) is a valid "*of* match," so maybe we can mix-and-match: try resource:read(Handle) of {ok, Data} -> foo(Data); Error -> Error; error:Reason -> {error,Reason} after resource:close(Handle) end Certainly that seems to convey the meaning better. Is it foolproof? Cheers, David From mevans@REDACTED Thu Feb 25 17:00:10 2010 From: mevans@REDACTED (Evans, Matthew) Date: Thu, 25 Feb 2010 11:00:10 -0500 Subject: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure In-Reply-To: References: <6702b8de-3380-411f-9fa5-86dcf5018d48@a18g2000yqc.googlegroups.com> Message-ID: Yes, I've looked at them and I think they have great potential. This particular application is going to be receiving asynchronous requests from drivers in the C/C++ world. I can do that using a port-driver, not sure if it can be done in a NIF (without blocking the scheduler). If it can, I'd love to see how. Matt -----Original Message----- From: Paul Davis [mailto:paul.joseph.davis@REDACTED] Sent: Thursday, February 25, 2010 9:51 AM To: Evans, Matthew Cc: sergey-miryanov; erlang-questions@REDACTED Subject: Re: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure Matthew, If you're willing to play near the edge you might want to check out NIF's [1]. They're pretty awesome but have only been around for a couple releases. Paul Davis [1] http://www.erlang.org/doc/man/erl_nif.html On Thu, Feb 25, 2010 at 9:36 AM, Evans, Matthew wrote: > Many thanks...that's just what I was after > > -----Original Message----- > From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of sergey-miryanov > Sent: Thursday, February 25, 2010 12:25 AM > To: erlang-questions@REDACTED > Subject: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure > > Do you see this: http://www.erlang.org/doc/man/driver_entry.html? > > On Feb 25, 7:13?am, "Evans, Matthew" wrote: >> Hi All, >> >> I've been looking at linkedin drivers a little. I 'm trying to find a description of all the handler functions that are contained in the ErlDrvEntry structure. Obviously startup and shutdown make sense, but what about all the others (see the example below)? When are they called (for example ready_input, handle, control, process)? Pointers to documentation would be helpful, the Erlang documentation inhttp://www.erlang.org/doc/man/erl_driver.htmlseems to be missing quite a few of them.... >> >> Many thanks >> >> Matt >> >> static ErlDrvEntry basic_driver_entry = { >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* init */ >> ? ? start, ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* startup */ >> ? ? stop, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* shutdown */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* output */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_input */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_output */ >> ? ? "basic_drv", ? ? ? ? ? ? ? ? ? ? ?/* the name of the driver */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* finish */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* handle */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* control */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* timeout */ >> ? ? process, ? ? ? ? ? ? ? ? ? ? ? ? ?/* process */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_async */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* flush */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* call */ >> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* event */ >> ? ? ERL_DRV_EXTENDED_MARKER, ? ? ? ? ?/* ERL_DRV_EXTENDED_MARKER */ >> ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MAJOR_VERSION */ >> ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MINOR_VERSION */ >> ? ? ERL_DRV_FLAG_USE_PORT_LOCKING ? ? /* ERL_DRV_FLAGs */ >> >> }; >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> Seehttp://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From lovei.laszlo@REDACTED Thu Feb 25 17:39:37 2010 From: lovei.laszlo@REDACTED (Laszlo Lovei) Date: Thu, 25 Feb 2010 08:39:37 -0800 (PST) Subject: Unexpected try/catch behaviour In-Reply-To: References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> <20100224085609.GA14027@erix.ericsson.se> Message-ID: On Feb 25, 2:57?am, "Richard O'Keefe" wrote: > > The tricky thing here is that foo(Data) is > *outside* the scope of the "catch" > *inside* the scsope of the "after" > if I haven't blown all my fuses entirely. > > Useful, this is. ?Easy to take into acount when reading, it isn't. > I think I'd want some comments, being a Bear of very little Brain. > > ? ? ?Handle = resource:open("foo.txt"), > ? ? ?try ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?% catch? after? > ? ? ? ? ?resource:read(Handle) ? ? ? ? ?% yes ? ?yes > ? ? of {ok, Data} -> foo(Data) ? ? ? ? % no ? ? yes > ? ? ? ; Error ? ? ?-> Error > ? ? ?catch > ? ? ? ? ?error:Reason -> {error,Reason} > ? ? ?after > ? ? ? ? ?resource:close(Handle) ? ? ? ? ?% no ? ? no > ? ? ?end > > Perhaps nested tries and cases might actually be easier to read. Funny, if you indent the code like that, I find it straightforward to read: "try to evaluate read(), return values should be matched against the of clauses, exceptions against the catch clauses, and after that, evaluate close()". Why should exceptions from "of" clauses be caught by "catch" clauses in this structure? They are not nested constructs, but clauses of the same nesting level in "try". Catching exceptions from "of" clauses would be analogous to evaluating "case" clauses sequentially, matching the return value of a clause against the next pattern. Laszlo From paul.joseph.davis@REDACTED Thu Feb 25 17:47:33 2010 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Thu, 25 Feb 2010 11:47:33 -0500 Subject: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure In-Reply-To: References: <6702b8de-3380-411f-9fa5-86dcf5018d48@a18g2000yqc.googlegroups.com> Message-ID: Matt, Ah. I'd stick with a driver for that. You could theoretically implement that as a NIF, but there's not really much of a reason when drivers are already meant for such things. HTH, Paul Davis On Thu, Feb 25, 2010 at 11:00 AM, Evans, Matthew wrote: > Yes, I've looked at them and I think they have great potential. > > This particular application is going to be receiving asynchronous requests from drivers in the C/C++ world. I can do that using a port-driver, not sure if it can be done in a NIF (without blocking the scheduler). If it can, I'd love to see how. > > Matt > > -----Original Message----- > From: Paul Davis [mailto:paul.joseph.davis@REDACTED] > Sent: Thursday, February 25, 2010 9:51 AM > To: Evans, Matthew > Cc: sergey-miryanov; erlang-questions@REDACTED > Subject: Re: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure > > Matthew, > > If you're willing to play near the edge you might want to check out > NIF's [1]. They're pretty awesome but have only been around for a > couple releases. > > Paul Davis > > [1] http://www.erlang.org/doc/man/erl_nif.html > > On Thu, Feb 25, 2010 at 9:36 AM, Evans, Matthew wrote: >> Many thanks...that's just what I was after >> >> -----Original Message----- >> From: erlang-questions@REDACTED [mailto:erlang-questions@REDACTED] On Behalf Of sergey-miryanov >> Sent: Thursday, February 25, 2010 12:25 AM >> To: erlang-questions@REDACTED >> Subject: [erlang-questions] Re: Erlang linked in drivers, ErlDrvEntry structure >> >> Do you see this: http://www.erlang.org/doc/man/driver_entry.html? >> >> On Feb 25, 7:13?am, "Evans, Matthew" wrote: >>> Hi All, >>> >>> I've been looking at linkedin drivers a little. I 'm trying to find a description of all the handler functions that are contained in the ErlDrvEntry structure. Obviously startup and shutdown make sense, but what about all the others (see the example below)? When are they called (for example ready_input, handle, control, process)? Pointers to documentation would be helpful, the Erlang documentation inhttp://www.erlang.org/doc/man/erl_driver.htmlseems to be missing quite a few of them.... >>> >>> Many thanks >>> >>> Matt >>> >>> static ErlDrvEntry basic_driver_entry = { >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* init */ >>> ? ? start, ? ? ? ? ? ? ? ? ? ? ? ? ? ?/* startup */ >>> ? ? stop, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* shutdown */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* output */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_input */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_output */ >>> ? ? "basic_drv", ? ? ? ? ? ? ? ? ? ? ?/* the name of the driver */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* finish */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* handle */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* control */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* timeout */ >>> ? ? process, ? ? ? ? ? ? ? ? ? ? ? ? ?/* process */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* ready_async */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* flush */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* call */ >>> ? ? NULL, ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* event */ >>> ? ? ERL_DRV_EXTENDED_MARKER, ? ? ? ? ?/* ERL_DRV_EXTENDED_MARKER */ >>> ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MAJOR_VERSION */ >>> ? ? ERL_DRV_EXTENDED_MAJOR_VERSION, ? /* ERL_DRV_EXTENDED_MINOR_VERSION */ >>> ? ? ERL_DRV_FLAG_USE_PORT_LOCKING ? ? /* ERL_DRV_FLAGs */ >>> >>> }; >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> Seehttp://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> > From dizzyd@REDACTED Thu Feb 25 17:58:24 2010 From: dizzyd@REDACTED (Dave Smith) Date: Thu, 25 Feb 2010 09:58:24 -0700 Subject: Debug helper for erl Message-ID: Greetings, A while back I wrote up a trick that I've found useful when debugging port drivers: http://dizzyd.com/blog/post/190 Basically, the idea is to tweak the erl script so that if an environment variable (USE_GDB) is set, gdb is invoked with the appropriate parameters for a debugging session. Is there any interest on the part of the OTP team for incorporating this into the mainline? Thanks, D. From dmercer@REDACTED Thu Feb 25 18:26:10 2010 From: dmercer@REDACTED (David Mercer) Date: Thu, 25 Feb 2010 11:26:10 -0600 Subject: Purpose of supervising temporary children? Message-ID: <26FC11BA57474C3E8E94778878025095@SSI.CORP> What is the purpose of supervising temporary children? I know you're not supposed to have rogue unsupervised processes running around in your OTP system, but is there that much danger in having such rogue processes if they are linked to supervised processes? Is the supervisory role just smoothing off some of the rough corner cases of plain old linked processes, or is there more to it than that? Please advise. Thank-you. David From g@REDACTED Thu Feb 25 18:51:03 2010 From: g@REDACTED (Garrett Smith) Date: Thu, 25 Feb 2010 11:51:03 -0600 Subject: [erlang-questions] Purpose of supervising temporary children? In-Reply-To: <26FC11BA57474C3E8E94778878025095@SSI.CORP> References: <26FC11BA57474C3E8E94778878025095@SSI.CORP> Message-ID: On Thu, Feb 25, 2010 at 11:26 AM, David Mercer wrote: > What is the purpose of supervising temporary children? ?I know you're not > supposed to have rogue unsupervised processes running around in your OTP > system, but is there that much danger in having such rogue processes if they > are linked to supervised processes? ?Is the supervisory role just smoothing > off some of the rough corner cases of plain old linked processes, or is > there more to it than that? In the case of simple_one_for_one, you get house keeping -- a temporary process will be automatically removed from the supervisor's list of children when it terminates, regardless of exit status. This lets you use the supervisor as both a factory and an inventory (which_children) of a certain type/category of process. I've gotten into the habit of religiously using supervisors to create processes. There's probably more advanced patterns, but I find my code can get messy with process management tasks when I don't use supervisors. Garrett From tuncer.ayaz@REDACTED Thu Feb 25 19:30:35 2010 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Thu, 25 Feb 2010 19:30:35 +0100 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <4ac8254d1002240932v5cdc83c3o3a6ee849f0d62109@mail.gmail.com> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <4ac8254d1002191549x16bb8c1w237a4de2abbdae2f@mail.gmail.com> <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> <4ac8254d1002231634x4ac64dd1g623bbb0a745985bb@mail.gmail.com> <4ac8254d1002240555y4acfc317uedf38924af432dc4@mail.gmail.com> <930e5b151002240658h79cb6be5oc579abdf43dc33b1@mail.gmail.com> <4ac8254d1002240932v5cdc83c3o3a6ee849f0d62109@mail.gmail.com> Message-ID: <4ac8254d1002251030q7820bcf1pb31a8b055dba2d7d@mail.gmail.com> On Wed, Feb 24, 2010 at 6:32 PM, Tuncer Ayaz wrote: > On Wed, Feb 24, 2010 at 4:08 PM, Chandru > wrote: >> Hi, >> >> On 24 February 2010 14:58, Humaira Surve wrote: >>> Hi Chandru, Tuncer, >>> >>> I've been playing around with the FSM version but I'm struggling to run it. >>> >>> My logs say that count:inc cannot be found. Do either of you know where to >>> find this count library? >>> >> >> Sorry about that, I forgot to remove those calls. The 'count' module >> is part of an internal application which we use to record statistics. >> Feel free to rip out all count:inc invocations. >> >>> I think it might be nice to have a copy of the FSM version on a central >>> repository. I'm happy to assist with uploading it / writing up some simple >>> install notes once I have it working. >> >> github? > > I talked to Tobbe and he would be glad to accept relevant changes. > He also told me that ejabberd carries their own eldap version. I'm > not heavily using LDAP myself right now so it might be best if you Just in case the mail was possibly mis-worded: 'you' referred to either Humaira or Chandru as developers who seem to have a need for and interest in eldap. I leave it up to you guys to coordinate with Tobbe :). If you need any help/assistance ping me off-list. > work on this. ?I've only been trying to streamline the different > eldap versions into one canonical repo and work from there. From fritchie@REDACTED Thu Feb 25 23:21:24 2010 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Thu, 25 Feb 2010 16:21:24 -0600 Subject: [erlang-questions] debugging remote node In-Reply-To: Message of "Thu, 25 Feb 2010 14:58:41 +0100." <95be1d3b1002250558s48096ed0n45209d609f2ba469@mail.gmail.com> Message-ID: <58660.1267136484@snookles.snookles.com> Vlad, could you be a bit more specific about what you're trying to do? Things like the shell's built-in function "nl(ModuleName)." don't require ModuleName.beam to sit on all machines, IIRC. It just needs to be accessible by & loaded into the node that is executing the shell. On a maybe-related, maybe-not-related topic, I've become a big, big fan of the "redbug" package for tracing on both local and remote nodes. (Ask Google Code for the source's location.) -Scott From caio.ariede@REDACTED Fri Feb 26 01:13:34 2010 From: caio.ariede@REDACTED (caio ariede) Date: Thu, 25 Feb 2010 21:13:34 -0300 Subject: What atom name to represent a null value Message-ID: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> In common sense, what atom name can I use to better represent null values? Thanks. Caio Ariede http://caioariede.com/ From caio.ariede@REDACTED Fri Feb 26 01:20:44 2010 From: caio.ariede@REDACTED (caio ariede) Date: Thu, 25 Feb 2010 21:20:44 -0300 Subject: [erlang-questions] What atom name to represent a null value In-Reply-To: <1267143285.3672.18.camel@isengaard> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> Message-ID: <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> I already saw some people using "undef", but I want to know what name is commonly used (if there is). Caio Ariede http://caioariede.com/ On Thu, Feb 25, 2010 at 9:14 PM, David Lloyd wrote: > > Why couldn't you use "null"? > > DSL > > -----Original Message----- > *From*: caio ariede > > > *To*: erlang-questions > > > *Subject*: [erlang-questions] What atom name to represent a null value > *Date*: Thu, 25 Feb 2010 21:13:34 -0300 > > In common sense, what atom name can I use to better represent null values? > > Thanks. > > Caio Ariedehttp://caioariede.com/ > > > From kagato@REDACTED Fri Feb 26 01:29:38 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Thu, 25 Feb 2010 16:29:38 -0800 Subject: [erlang-questions] What atom name to represent a null value In-Reply-To: <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> Message-ID: <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> undefined is the standard one. Although I've used none, null, and nil before (in different situations). On Feb 25, 2010, at 4:20 PM, caio ariede wrote: > I already saw some people using "undef", but I want to know what name is > commonly used (if there is). > > Caio Ariede > http://caioariede.com/ > > > On Thu, Feb 25, 2010 at 9:14 PM, David Lloyd wrote: > >> >> Why couldn't you use "null"? >> >> DSL >> >> -----Original Message----- >> *From*: caio ariede >>> >> *To*: erlang-questions >>> >> *Subject*: [erlang-questions] What atom name to represent a null value >> *Date*: Thu, 25 Feb 2010 21:13:34 -0300 >> >> In common sense, what atom name can I use to better represent null values? >> >> Thanks. >> >> Caio Ariedehttp://caioariede.com/ >> >> >> -- Jayson Vantuyl kagato@REDACTED From caio.ariede@REDACTED Fri Feb 26 01:33:39 2010 From: caio.ariede@REDACTED (caio ariede) Date: Thu, 25 Feb 2010 21:33:39 -0300 Subject: [erlang-questions] What atom name to represent a null value In-Reply-To: <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> Message-ID: <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> Right. It is defined in somewhere? Some documentation? Or just in common sense? Thanks Caio Ariede http://caioariede.com/ On Thu, Feb 25, 2010 at 9:29 PM, Jayson Vantuyl wrote: > undefined is the standard one. Although I've used none, null, and nil > before (in different situations). > > On Feb 25, 2010, at 4:20 PM, caio ariede wrote: > > > I already saw some people using "undef", but I want to know what name is > > commonly used (if there is). > > > > Caio Ariede > > http://caioariede.com/ > > > > > > On Thu, Feb 25, 2010 at 9:14 PM, David Lloyd > wrote: > > > >> > >> Why couldn't you use "null"? > >> > >> DSL > >> > >> -----Original Message----- > >> *From*: caio ariede caio%20ariede%20%3ccaio.ariede@REDACTED > %3e> > >>> > >> *To*: erlang-questions erlang-questions%20%3cerlang-questions@REDACTED > %3e> > >>> > >> *Subject*: [erlang-questions] What atom name to represent a null value > >> *Date*: Thu, 25 Feb 2010 21:13:34 -0300 > >> > >> In common sense, what atom name can I use to better represent null > values? > >> > >> Thanks. > >> > >> Caio Ariedehttp://caioariede.com/ > >> > >> > >> > > -- > Jayson Vantuyl > kagato@REDACTED > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From kagato@REDACTED Fri Feb 26 01:53:15 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Thu, 25 Feb 2010 16:53:15 -0800 Subject: [erlang-questions] What atom name to represent a null value In-Reply-To: <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> Message-ID: I don't believe that it's defined explicitly, but it's the standard API of many functions. For example: * when accessing the process dictionary, if the key doesn't exist, the value is undefined; try: get(foo), or erase(foo) * when accessing a proplist for a key that doesn't exist, the value is undefined; try: proplists:get_value(foo,[]) * when looking for a registered name that isn't registered, the value is undefined: try: whereis(foo) * erlang:decode_packet/3 returns undefined when the length of a packet is unknown * erlang:delete_module/1 returns undefined when you delete a module that isn't loaded * erlang:port_info/2 returns undefined on a nonexistent port * erlang:process_info/1 returns undefined on a nonexistent process * erlang:system_monitor/1 takes undefined as an argument, meaning to set null monitoring settings * file:pid2name/1 gives undefined if a pid isn't associated with a filename It's all over the libraries. Conversely, I can't find none, null, or nil anywhere. Of course, I didn't look too hard. Given the overwhelming use of undefined in Erlang itself, I think it's safe to use in your code to represent a null value. On Feb 25, 2010, at 4:33 PM, caio ariede wrote: > Right. > > It is defined in somewhere? Some documentation? > > Or just in common sense? > > Thanks > > Caio Ariede > http://caioariede.com/ > > > On Thu, Feb 25, 2010 at 9:29 PM, Jayson Vantuyl wrote: > >> undefined is the standard one. Although I've used none, null, and nil >> before (in different situations). >> >> On Feb 25, 2010, at 4:20 PM, caio ariede wrote: >> >>> I already saw some people using "undef", but I want to know what name is >>> commonly used (if there is). >>> >>> Caio Ariede >>> http://caioariede.com/ >>> >>> >>> On Thu, Feb 25, 2010 at 9:14 PM, David Lloyd >> wrote: >>> >>>> >>>> Why couldn't you use "null"? >>>> >>>> DSL >>>> >>>> -----Original Message----- >>>> *From*: caio ariede > caio%20ariede%20%3ccaio.ariede@REDACTED >> %3e> >>>>> >>>> *To*: erlang-questions > erlang-questions%20%3cerlang-questions@REDACTED >> %3e> >>>>> >>>> *Subject*: [erlang-questions] What atom name to represent a null value >>>> *Date*: Thu, 25 Feb 2010 21:13:34 -0300 >>>> >>>> In common sense, what atom name can I use to better represent null >> values? >>>> >>>> Thanks. >>>> >>>> Caio Ariedehttp://caioariede.com/ >>>> >>>> >>>> >> >> -- >> Jayson Vantuyl >> kagato@REDACTED >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> -- Jayson Vantuyl kagato@REDACTED From nbowe@REDACTED Fri Feb 26 01:55:53 2010 From: nbowe@REDACTED (Nikolas Bowe) Date: Fri, 26 Feb 2010 11:55:53 +1100 Subject: [erlang-questions] What atom name to represent a null value In-Reply-To: <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> Message-ID: <4B871C19.7020808@infinite-interactive.com> I think its because the default value for record fields is 'undefined' caio ariede wrote: > Right. > > It is defined in somewhere? Some documentation? > > Or just in common sense? > > Thanks > > Caio Ariede > http://caioariede.com/ > > > On Thu, Feb 25, 2010 at 9:29 PM, Jayson Vantuyl wrote: > > >> undefined is the standard one. Although I've used none, null, and nil >> before (in different situations). >> >> On Feb 25, 2010, at 4:20 PM, caio ariede wrote: >> >> >>> I already saw some people using "undef", but I want to know what name is >>> commonly used (if there is). >>> >>> Caio Ariede >>> http://caioariede.com/ >>> >>> >>> On Thu, Feb 25, 2010 at 9:14 PM, David Lloyd >>> >> wrote: >> >>>> Why couldn't you use "null"? >>>> >>>> DSL >>>> >>>> -----Original Message----- >>>> *From*: caio ariede >>> >> caio%20ariede%20%3ccaio.ariede@REDACTED >> %3e> >> >>>> *To*: erlang-questions >>> >> erlang-questions%20%3cerlang-questions@REDACTED >> %3e> >> >>>> *Subject*: [erlang-questions] What atom name to represent a null value >>>> *Date*: Thu, 25 Feb 2010 21:13:34 -0300 >>>> >>>> In common sense, what atom name can I use to better represent null >>>> >> values? >> >>>> Thanks. >>>> >>>> Caio Ariedehttp://caioariede.com/ >>>> >>>> >>>> >>>> >> -- >> Jayson Vantuyl >> kagato@REDACTED >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> >> > > This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect. From damien_kakpo@REDACTED Fri Feb 26 01:31:57 2010 From: damien_kakpo@REDACTED (Damien Kakpo) Date: Fri, 26 Feb 2010 00:31:57 +0000 (GMT) Subject: Newbie OSERL question Message-ID: <566882.23074.qm@web24706.mail.ird.yahoo.com> Hello, I just started learnig erlang and I've come across your interesting work on oserl which have given me some idea. What the state of oserl today ? Where can I find the latest version which is in production and help to implemente it just to send SMS to several persons. Thanks ???????????????????????????????????????????????????????????????????? Damien KAKPO Hello, I just started learnig erlang and I've come across your interesting work on oserl which have given me some idea. What the state of oserl today ? Where can I find the latest version which is in production and help to implemente it just to send SMS to several persons. Thanks ???????????????????????????????????????????????????????????????????? Damien KAKPO Hello, I just started learnig erlang and I've come across?an interesting? SMPP work?( oserl )which have given me some idea. What the state of oserl today ? Where can I find the latest version which is in production and help to implemente it just to send SMSs. Thanks ???????????????????????????????????????????????????????????????????? Damien KAKPO From ok@REDACTED Fri Feb 26 02:39:36 2010 From: ok@REDACTED (Richard O'Keefe) Date: Fri, 26 Feb 2010 14:39:36 +1300 Subject: [erlang-questions] Re: Unexpected try/catch behaviour In-Reply-To: References: <331a9abb1002230319h4fb69cc0x6dfc44000bc75133@mail.gmail.com> <4B83BBF8.2020406@erlang-solutions.com> <401d3ba31002230336l7661b0d8rce2def8a540353ba@mail.gmail.com> <07F42FFD-429E-4E6D-A17E-CA561D1ACBE8@cs.otago.ac.nz> <20100224085609.GA14027@erix.ericsson.se> Message-ID: On Feb 26, 2010, at 5:39 AM, Laszlo Lovei wrote: > evaluate close()". Why should exceptions from "of" clauses be caught > by "catch" clauses in this structure? They are not nested constructs, > but clauses of the same nesting level in "try". They are, in fact, clauses of the same nesting as the head part where exceptions *are* caught *and* (like it) preceding 'catch'. I am not saying that any of this is wrong, or broken, or should be changed in any way at all. Just that it's easy to get confused. I DON'T have any better ideas, except careful layout and commenting. From jvliwanag@REDACTED Fri Feb 26 03:25:52 2010 From: jvliwanag@REDACTED (Jan Vincent) Date: Fri, 26 Feb 2010 10:25:52 +0800 Subject: Frequent Node Disconnects Message-ID: <329C7AC8-0731-426E-AFC9-32588AFEFD99@gmail.com> Hi guys, I find my erlang nodes in a distributed system frequently being disconnected under light load. What symptoms should I look out for why this happens? It seems that when I attempt reconnection after the disconnection, it works just fine. (Using net_adm:ping or net_adm:world). Also, what's the best way to cope with these frequent disconnections? Jan Vincent Liwanag jvliwanag@REDACTED From kenji.rikitake@REDACTED Fri Feb 26 05:11:14 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Fri, 26 Feb 2010 13:11:14 +0900 Subject: Tokyo Erlang Workshop #4, 7pm tonight, at Oracle Japan meeting room (Gaienmae, Tokyo, Japan) Message-ID: <20100226041114.GA34463@k2r.org> The Fourth Tokyo Erlang Workshop (free but reservation required), to be held today (26-FEB-2010 7pm-9pm Japan Standard Time (JST)) has two vacant sheets as of 1:07pm JST. If you are interested in joining the event, register yourself from the following URL (NOTE: the registration page and the event will be Japanese-spoken) http://atnd.org/events/2251 And four more sheets for the Erlounge from 9pm near Gaienmae: http://atnd.org/events/3017 Regards, Kenji Rikitake From lloy0076@REDACTED Fri Feb 26 01:14:45 2010 From: lloy0076@REDACTED (David Lloyd) Date: Fri, 26 Feb 2010 10:44:45 +1030 Subject: [erlang-questions] What atom name to represent a null value In-Reply-To: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> Message-ID: <1267143285.3672.18.camel@isengaard> Why couldn't you use "null"? DSL -----Original Message----- From: caio ariede To: erlang-questions Subject: [erlang-questions] What atom name to represent a null value Date: Thu, 25 Feb 2010 21:13:34 -0300 In common sense, what atom name can I use to better represent null values? Thanks. Caio Ariede http://caioariede.com/ From dujinfang@REDACTED Fri Feb 26 06:40:15 2010 From: dujinfang@REDACTED (Seven Du) Date: Fri, 26 Feb 2010 13:40:15 +0800 Subject: [erlang-questions] What atom name to represent a null value In-Reply-To: <4B871C19.7020808@infinite-interactive.com> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> <4B871C19.7020808@infinite-interactive.com> Message-ID: <23f91031002252140q71d29ee2qb1a61d4d072f2bfe@mail.gmail.com> doesn't matter, you can use anything, it's only an atom which has no special meaning, however, "undefined" is kind of common. 2010/2/26 Nikolas Bowe : > I think its because the default value for record fields is 'undefined' > > > caio ariede wrote: >> >> Right. >> >> It is defined in somewhere? Some documentation? >> >> Or just in common sense? >> >> Thanks >> >> Caio Ariede >> http://caioariede.com/ >> >> >> On Thu, Feb 25, 2010 at 9:29 PM, Jayson Vantuyl wrote: >> >> >>> >>> undefined is the standard one. ?Although I've used none, null, and nil >>> before (in different situations). >>> >>> On Feb 25, 2010, at 4:20 PM, caio ariede wrote: >>> >>> >>>> >>>> I already saw some people using "undef", but I want to know what name is >>>> commonly used (if there is). >>>> >>>> Caio Ariede >>>> http://caioariede.com/ >>>> >>>> >>>> On Thu, Feb 25, 2010 at 9:14 PM, David Lloyd >>>> >>> >>> wrote: >>> >>>>> >>>>> Why couldn't you use "null"? >>>>> >>>>> DSL >>>>> >>>>> -----Original Message----- >>>>> *From*: caio ariede >>>> >>> >>> >>> caio%20ariede%20%3ccaio.ariede@REDACTED >>> %3e> >>> >>>>> >>>>> *To*: erlang-questions >>>> >>> >>> >>> erlang-questions%20%3cerlang-questions@REDACTED >>> %3e> >>> >>>>> >>>>> *Subject*: [erlang-questions] What atom name to represent a null value >>>>> *Date*: Thu, 25 Feb 2010 21:13:34 -0300 >>>>> >>>>> In common sense, what atom name can I use to better represent null >>>>> >>> >>> values? >>> >>>>> >>>>> Thanks. >>>>> >>>>> Caio Ariedehttp://caioariede.com/ >>>>> >>>>> >>>>> >>>>> >>> >>> -- >>> Jayson Vantuyl >>> kagato@REDACTED >>> >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >>> >>> >> >> > > > This message and its attachments may contain legally privileged or > confidential information. This message is intended for the use of the > individual or entity to which it is addressed. If you are not the addressee > indicated in this message, or the employee or agent responsible for > delivering the message to the intended recipient, you may not copy or > deliver this message or its attachments to anyone. Rather, you should > permanently delete this message and its attachments and kindly notify the > sender by reply e-mail. Any content of this message and its attachments, > which does not relate to the official business of the sending company must > be taken not to have been sent or endorsed by the sending company or any of > its related entities. No warranty is made that the e-mail or attachment(s) > are free from computer virus or other defect. > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From elliot@REDACTED Fri Feb 26 07:27:25 2010 From: elliot@REDACTED (Elliot Murphy) Date: Fri, 26 Feb 2010 01:27:25 -0500 Subject: [erlang-questions] Erlang/OTP R13B04 has been released In-Reply-To: <4B8570FC.8030904@gmail.com> References: <4B8570FC.8030904@gmail.com> Message-ID: <595970ad1002252227ud4ace40s1c7f7283dfe5b85e@mail.gmail.com> Hi! Ubuntu usually syncs packages from Debian and tries to minimize the differences. The version of Ubuntu currently in development, Ubuntu 10.04, has already stopped taking new versions of software and is focused on stabilizing and bugfixes in preparation for release in April. So this version of Erlang would likely go into Ubuntu 10.10 which will be released in October. If there are important bugs fixed by this version of Erlang, specific bugfixes may be able to be backported into stable releases of Ubuntu that have already shipped. It should be possible to prepare a package of this new release in a PPA (personal package archive) so that it can easily be installed by folks wanting to have the very latest Erlang on Ubuntu. I have attempted to prepare these packages and uploaded them here: https://edge.launchpad.net/~erlang-dev/+archive/ppa . Hopefully they build ok and are useful to you - please let me know if these packages worked fine or if they had problems. Normally Sergei uploads new versions of Erlang to Debian very shortly after they are released, so I'd imagine this latest Erlang will be available in Debian testing before very long. Elliot Murphy On Feb 24, 2010 1:34 PM, "Kay Kay" wrote: This is great. Curious - how close is the integration of the release with the ubuntu repositories , so that it would be available for update as well. On 2/24/10 3:00 AM, Kenneth Lundin wrote: > > Bug fix release : otp_src_R13B04 > Build date ... From bob@REDACTED Fri Feb 26 07:35:32 2010 From: bob@REDACTED (Bob Ippolito) Date: Thu, 25 Feb 2010 22:35:32 -0800 Subject: [erlang-questions] What atom name to represent a null value In-Reply-To: References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> Message-ID: <6a36e7291002252235m51a1e158t52f312f1d6207486@mail.gmail.com> none is used in proplists:lookup/2 error is used in other similar scenarios, like dict:find/2 On Thu, Feb 25, 2010 at 4:53 PM, Jayson Vantuyl wrote: > I don't believe that it's defined explicitly, but it's the standard API of many functions. ?For example: > > * when accessing the process dictionary, if the key doesn't exist, the value is undefined; try: get(foo), or erase(foo) > * when accessing a proplist for a key that doesn't exist, the value is undefined; try: proplists:get_value(foo,[]) > * when looking for a registered name that isn't registered, the value is undefined: try: whereis(foo) > * erlang:decode_packet/3 returns undefined when the length of a packet is unknown > * erlang:delete_module/1 returns undefined when you delete a module that isn't loaded > * erlang:port_info/2 returns undefined on a nonexistent port > * erlang:process_info/1 returns undefined on a nonexistent process > * erlang:system_monitor/1 takes undefined as an argument, meaning to set null monitoring settings > * file:pid2name/1 gives undefined if a pid isn't associated with a filename > > It's all over the libraries. ?Conversely, I can't find none, null, or nil anywhere. ?Of course, I didn't look too hard. > > Given the overwhelming use of undefined in Erlang itself, I think it's safe to use in your code to represent a null value. > > On Feb 25, 2010, at 4:33 PM, caio ariede wrote: > >> Right. >> >> It is defined in somewhere? Some documentation? >> >> Or just in common sense? >> >> Thanks >> >> Caio Ariede >> http://caioariede.com/ >> >> >> On Thu, Feb 25, 2010 at 9:29 PM, Jayson Vantuyl wrote: >> >>> undefined is the standard one. ?Although I've used none, null, and nil >>> before (in different situations). >>> >>> On Feb 25, 2010, at 4:20 PM, caio ariede wrote: >>> >>>> I already saw some people using "undef", but I want to know what name is >>>> commonly used (if there is). >>>> >>>> Caio Ariede >>>> http://caioariede.com/ >>>> >>>> >>>> On Thu, Feb 25, 2010 at 9:14 PM, David Lloyd >>> wrote: >>>> >>>>> >>>>> Why couldn't you use "null"? >>>>> >>>>> DSL >>>>> >>>>> -----Original Message----- >>>>> *From*: caio ariede >> caio%20ariede%20%3ccaio.ariede@REDACTED >>> %3e> >>>>>> >>>>> *To*: erlang-questions >> erlang-questions%20%3cerlang-questions@REDACTED >>> %3e> >>>>>> >>>>> *Subject*: [erlang-questions] What atom name to represent a null value >>>>> *Date*: Thu, 25 Feb 2010 21:13:34 -0300 >>>>> >>>>> In common sense, what atom name can I use to better represent null >>> values? >>>>> >>>>> Thanks. >>>>> >>>>> Caio Ariedehttp://caioariede.com/ >>>>> >>>>> >>>>> >>> >>> -- >>> Jayson Vantuyl >>> kagato@REDACTED >>> >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >>> > > -- > Jayson Vantuyl > kagato@REDACTED > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From mail@REDACTED Fri Feb 26 08:40:53 2010 From: mail@REDACTED (Tim Fletcher) Date: Thu, 25 Feb 2010 23:40:53 -0800 (PST) Subject: What atom name to represent a null value In-Reply-To: <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> Message-ID: <6096767b-4085-4214-85e9-e47226452766@19g2000yqu.googlegroups.com> > It is defined in somewhere? Some documentation? > > Or just in common sense? I suspect it is a practical application of the theoretical notion of undefined in functional programming (and mathematics). For example, here's a little function: foo(1) -> 2; foo(2) -> 3; foo(3) -> 1. This function is only defined for the values 1, 2, and 3. It is undefined for any other value. You can use the theoretical notion of undefined when doing certain transformations on this function and so on. On a practical level, calling this function with any other value will throw an error, which isn't always helpful. What if you wanted to pass in any integer? In Erlang you can write this: foo(1) -> 2; foo(2) -> 3; foo(3) -> 1. foo(_) -> undefined. You can then call foo(4) and have it actually return a value, which means you can then write things like foo(X) =:= 1 without it throwing a badmatch error. Sometimes you may want to distinguish between values that aren't defined, and values that do exist but are null; in this case you can use undefined in combination with null/nil/none/nothing, as long as your values aren't atoms. If your values can be atoms then you'll probably need to use tagged tuples, something like this: > datastore:lookup(foo). undefined % key/value is not defined > datastore:lookup(bar). none % key exists, value is "null" > datastore:lookup(baz). {ok, undefined} % key exists, value is undefined The important thing is to be able to distinguish between the different cases. Hope that helps. Tim From bgustavsson@REDACTED Fri Feb 26 09:20:13 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Fri, 26 Feb 2010 09:20:13 +0100 Subject: [erlang-questions] Debug helper for erl In-Reply-To: References: Message-ID: <6672d0161002260020n2d826896y95f31be2242f895d@mail.gmail.com> On Thu, Feb 25, 2010 at 5:58 PM, Dave Smith wrote: > Is there any interest on the part of the OTP team for incorporating > this into the mainline? There already is a script called "cerl" in the bin directory for doing that. (In the source tree when it has been built -- the source can be found in erts/etc/unix/cerl.src.) -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From als@REDACTED Fri Feb 26 09:23:11 2010 From: als@REDACTED (Anthony Shipman) Date: Fri, 26 Feb 2010 19:23:11 +1100 Subject: [erlang-questions] Purpose of supervising temporary children? In-Reply-To: References: <26FC11BA57474C3E8E94778878025095@SSI.CORP> Message-ID: <201002261923.11266.als@iinet.net.au> On Fri, 26 Feb 2010 04:51:03 am Garrett Smith wrote: > On Thu, Feb 25, 2010 at 11:26 AM, David Mercer wrote: > > What is the purpose of supervising temporary children? ?I know you're not > > supposed to have rogue unsupervised processes running around in your OTP > > system, but is there that much danger in having such rogue processes if > > they are linked to supervised processes? ?Is the supervisory role just > > smoothing off some of the rough corner cases of plain old linked > > processes, or is there more to it than that? > > In the case of simple_one_for_one, you get house keeping -- a > temporary process will be automatically removed from the supervisor's > list of children when it terminates, regardless of exit status. This > lets you use the supervisor as both a factory and an inventory > (which_children) of a certain type/category of process. > > I've gotten into the habit of religiously using supervisors to create > processes. There's probably more advanced patterns, but I find my code > can get messy with process management tasks when I don't use > supervisors. > > Garrett > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED Also the live code update can only find supervised processes. -- Anthony Shipman Mamas don't let your babies als@REDACTED grow up to be outsourced. From vladdu55@REDACTED Fri Feb 26 09:59:52 2010 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 26 Feb 2010 09:59:52 +0100 Subject: [erlang-questions] debugging remote node In-Reply-To: <58660.1267136484@snookles.snookles.com> References: <95be1d3b1002250558s48096ed0n45209d609f2ba469@mail.gmail.com> <58660.1267136484@snookles.snookles.com> Message-ID: <95be1d3b1002260059h579e00ebl351bcdeef817b45e@mail.gmail.com> Hi, On Thu, Feb 25, 2010 at 23:21, Scott Lystig Fritchie wrote: > Vlad, could you be a bit more specific about what you're trying to do? > Things like the shell's built-in function "nl(ModuleName)." don't > require ModuleName.beam to sit on all machines, IIRC. ?It just needs to > be accessible by & loaded into the node that is executing the shell. It's not really my use case, I'm just forwarding a question i got, so I might not get all details right. I can load and run code on a remote node and it executes just fine. The problem is that if I start the debugger and set a breakpoint, it's getting activated only if the remote node shares filesystem with the local machine. Looking at the debugger code, I see that the interpreter uses read_file to load the code to interpret, which would explain the behaviour. What I'd like to know is if there is something I missed or do wrong and this can be made to work in all cases, or if there's a built-in limitation of the debugger (which would be useful to document). > On a maybe-related, maybe-not-related topic, I've become a big, big fan > of the "redbug" package for tracing on both local and remote nodes. > (Ask Google Code for the source's location.) Thanks, I know, I use it too sometimes. regards, Vlad From rvirding@REDACTED Fri Feb 26 10:43:01 2010 From: rvirding@REDACTED (Robert Virding) Date: Fri, 26 Feb 2010 10:43:01 +0100 Subject: [erlang-questions] Re: What atom name to represent a null value In-Reply-To: <6096767b-4085-4214-85e9-e47226452766@19g2000yqu.googlegroups.com> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> <6096767b-4085-4214-85e9-e47226452766@19g2000yqu.googlegroups.com> Message-ID: <3dbc6d1c1002260143l1573a870u358f4735f235bf8@mail.gmail.com> On 26 February 2010 08:40, Tim Fletcher wrote: >> It is defined in somewhere? Some documentation? >> >> Or just in common sense? > > I suspect it is a practical application of the theoretical notion of > undefined in functional programming (and mathematics). For example, > here's a little function: > > ?foo(1) -> 2; > ?foo(2) -> 3; > ?foo(3) -> 1. > > This function is only defined for the values 1, 2, and 3. It is > undefined for any other value. You can use the theoretical notion of > undefined when doing certain transformations on this function and so > on. > > On a practical level, calling this function with any other value will > throw an error, which isn't always helpful. What if you wanted to pass > in any integer? In Erlang you can write this: > > ?foo(1) -> 2; > ?foo(2) -> 3; > ?foo(3) -> 1. > ?foo(_) -> undefined. > > You can then call foo(4) and have it actually return a value, which > means you can then write things like foo(X) =:= 1 without it throwing > a badmatch error. The important thing here when deciding between these two cases is what it means in your application if foo/1 is called with a value which is not 1, 2 or 3. If it is an error, a value which should never occur, a bug, then you should definitely not add an extra clause which catches and returns a "helpful" value. Doing this will force you to check error returns through the rest of code to handle this which is definitely something you wish to avoid. If, on the other hand, this is not an error but just the default case where you can return something sensible then adding the extra clause makes sense. As an example of the difference: dict:find/2 returns (the atom) 'error' if a key is found, while dict:fetch/2 throws an error if the key is not found as it is defined to assume the key does exist. Robert From kiszl@REDACTED Fri Feb 26 11:09:45 2010 From: kiszl@REDACTED (Zoltan Lajos Kis) Date: Fri, 26 Feb 2010 11:09:45 +0100 (CET) Subject: Error compiling R13B04 Message-ID: <50820.194.88.55.211.1267178985.squirrel@localhost> Hi, I've just downloaded the tar.gz'd sources from erlang.org, and when trying to compile it fails with what is pasted at the end of this mail. R13B03 compiles just fine. gcc is 4.4.2-8, and the config parameters used were: ./configure --prefix=/opt/erlang-R13B04 --enable-hipe --enable-smp-support --enable-kernel-poll Did anyone else experience something similar? Thank you, Zoltan. g++ -c -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -g -Wall -O2 -fPIC -fomit-frame-pointer -fno-strict-aliasing -g -O2 -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DSIZEOF_VOID_P=4 -DHAVE_GL_GL_H=1 -DHAVE_GL_SUPPORT=1 -DHAVE_GLINTPTR=1 -DHAVE_GLINTPTRARB=1 -DHAVE_GLCHAR=1 -DHAVE_GLCHARARB=1 -DHAVE_GLHALFARB=1 -DHAVE_GLINT64EXT=1 -DHAVE_WX_STC_STC_H=1 -I/tmp/otp_src_R13B04/erts/emulator/beam -I/tmp/otp_src_R13B04/erts/include -I/tmp/otp_src_R13B04/erts/include/i686-pc-linux-gnu -I/tmp/otp_src_R13B04/erts/include/internal -I/tmp/otp_src_R13B04/erts/include/internal/i686-pc-linux-gnu -I/tmp/otp_src_R13B04/erts/emulator/sys/unix gen/wxe_funcs.cpp -o i686-pc-linux-gnu/wxe_funcs.o g++: Internal error: Killed (program cc1plus) Please submit a full bug report. See for instructions. make[3]: *** [i686-pc-linux-gnu/wxe_funcs.o] Error 1 make[3]: Leaving directory `/tmp/otp_src_R13B04/lib/wx/c_src' make[2]: *** [opt] Error 2 make[2]: Leaving directory `/tmp/otp_src_R13B04/lib/wx' make[1]: *** [opt] Error 2 make[1]: Leaving directory `/tmp/otp_src_R13B04/lib' make: *** [libs] Error 2 From zabrane3@REDACTED Fri Feb 26 11:39:53 2010 From: zabrane3@REDACTED (zabrane Mikael) Date: Fri, 26 Feb 2010 11:39:53 +0100 Subject: [erlang-questions] Error compiling R13B04 In-Reply-To: <50820.194.88.55.211.1267178985.squirrel@localhost> References: <50820.194.88.55.211.1267178985.squirrel@localhost> Message-ID: <18a1db031002260239x37a2e755w9a49e05f03981d0f@mail.gmail.com> Hi Zoltan, This error is related to "wx" (which I think is still unstable). If you're not GUI fan, just type: $ touch lib/wx/SKIP before the "configure" step. Regards. Zabrane 2010/2/26 Zoltan Lajos Kis > Hi, > > I've just downloaded the tar.gz'd sources from erlang.org, and when trying > to compile it fails with what is pasted at the end of this mail. R13B03 > compiles just fine. > > > gcc is 4.4.2-8, and the config parameters used were: > ./configure --prefix=/opt/erlang-R13B04 --enable-hipe --enable-smp-support > --enable-kernel-poll > > > Did anyone else experience something similar? > > Thank you, > Zoltan. > > > > g++ -c -I/usr/lib/wx/include/gtk2-unicode-release-2.8 > -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ > -pthread -g -Wall -O2 -fPIC -fomit-frame-pointer -fno-strict-aliasing -g > -O2 -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -DPACKAGE_NAME=\"\" > -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" > -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 > -DSIZEOF_VOID_P=4 -DHAVE_GL_GL_H=1 -DHAVE_GL_SUPPORT=1 -DHAVE_GLINTPTR=1 > -DHAVE_GLINTPTRARB=1 -DHAVE_GLCHAR=1 -DHAVE_GLCHARARB=1 -DHAVE_GLHALFARB=1 > -DHAVE_GLINT64EXT=1 -DHAVE_WX_STC_STC_H=1 > -I/tmp/otp_src_R13B04/erts/emulator/beam > -I/tmp/otp_src_R13B04/erts/include > -I/tmp/otp_src_R13B04/erts/include/i686-pc-linux-gnu > -I/tmp/otp_src_R13B04/erts/include/internal > -I/tmp/otp_src_R13B04/erts/include/internal/i686-pc-linux-gnu > -I/tmp/otp_src_R13B04/erts/emulator/sys/unix gen/wxe_funcs.cpp -o > i686-pc-linux-gnu/wxe_funcs.o > g++: Internal error: Killed (program cc1plus) > Please submit a full bug report. > See for instructions. > make[3]: *** [i686-pc-linux-gnu/wxe_funcs.o] Error 1 > make[3]: Leaving directory `/tmp/otp_src_R13B04/lib/wx/c_src' > make[2]: *** [opt] Error 2 > make[2]: Leaving directory `/tmp/otp_src_R13B04/lib/wx' > make[1]: *** [opt] Error 2 > make[1]: Leaving directory `/tmp/otp_src_R13B04/lib' > make: *** [libs] Error 2 > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From kenji.rikitake@REDACTED Fri Feb 26 11:41:26 2010 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Fri, 26 Feb 2010 19:41:26 +0900 Subject: [erlang-questions] Error compiling R13B04 In-Reply-To: <50820.194.88.55.211.1267178985.squirrel@localhost> References: <50820.194.88.55.211.1267178985.squirrel@localhost> Message-ID: <20100226104126.GA39072@k2r.org> Compiling wxe_funcs.cpp consumes a lot of memory (~500MB, watched on top of Ubuntu 9.10 and FreeBSD 7.2 gccs). Check the process limit of virtual memory. FYI Kenji Rikitake In the message <50820.194.88.55.211.1267178985.squirrel@REDACTED> dated Fri, Feb 26, 2010 at 11:09:21AM +0100, Zoltan Lajos Kis writes: > g++: Internal error: Killed (program cc1plus) > Please submit a full bug report. > See for instructions. > make[3]: *** [i686-pc-linux-gnu/wxe_funcs.o] Error 1 > make[3]: Leaving directory `/tmp/otp_src_R13B04/lib/wx/c_src' From mikpe@REDACTED Fri Feb 26 12:02:21 2010 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 26 Feb 2010 12:02:21 +0100 Subject: [erlang-questions] Error compiling R13B04 In-Reply-To: <50820.194.88.55.211.1267178985.squirrel@localhost> References: <50820.194.88.55.211.1267178985.squirrel@localhost> Message-ID: <19335.43581.897674.558120@pilspetsen.it.uu.se> Zoltan Lajos Kis writes: > g++ -c -I/usr/lib/wx/include/gtk2-unicode-release-2.8 > -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ > -pthread -g -Wall -O2 -fPIC -fomit-frame-pointer -fno-strict-aliasing -g > -O2 -D_GNU_SOURCE -D_THREAD_SAFE -D_REENTRANT -DPACKAGE_NAME=\"\" > -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" > -DPACKAGE_BUGREPORT=\"\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 > -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 > -DSIZEOF_VOID_P=4 -DHAVE_GL_GL_H=1 -DHAVE_GL_SUPPORT=1 -DHAVE_GLINTPTR=1 > -DHAVE_GLINTPTRARB=1 -DHAVE_GLCHAR=1 -DHAVE_GLCHARARB=1 -DHAVE_GLHALFARB=1 > -DHAVE_GLINT64EXT=1 -DHAVE_WX_STC_STC_H=1 > -I/tmp/otp_src_R13B04/erts/emulator/beam > -I/tmp/otp_src_R13B04/erts/include > -I/tmp/otp_src_R13B04/erts/include/i686-pc-linux-gnu > -I/tmp/otp_src_R13B04/erts/include/internal > -I/tmp/otp_src_R13B04/erts/include/internal/i686-pc-linux-gnu > -I/tmp/otp_src_R13B04/erts/emulator/sys/unix gen/wxe_funcs.cpp -o > i686-pc-linux-gnu/wxe_funcs.o > g++: Internal error: Killed (program cc1plus) > Please submit a full bug report. > See for instructions. Your C++ compiler died, asked you to submit a bug report, and even pointed you to its bug reporting instructions. Not an Erlang bug. You can skip the wx build by ./configure (same params as before) echo > lib/wx/SKIP make From kiszl@REDACTED Fri Feb 26 12:39:48 2010 From: kiszl@REDACTED (Zoltan Lajos Kis) Date: Fri, 26 Feb 2010 12:39:48 +0100 (CET) Subject: [erlang-questions] Error compiling R13B04 In-Reply-To: <20100226104126.GA39072@k2r.org> References: <50820.194.88.55.211.1267178985.squirrel@localhost> <20100226104126.GA39072@k2r.org> Message-ID: <64244.194.237.142.20.1267184388.squirrel@localhost> Thank you! Indeed, this was an "out of memory" error. Also thanks for the others for pointing at the SKIP method. Regards, Zoltan. > Compiling wxe_funcs.cpp consumes a lot of memory (~500MB, watched on top > of Ubuntu 9.10 and FreeBSD 7.2 gccs). Check the process limit of > virtual memory. > > FYI > Kenji Rikitake > > In the message <50820.194.88.55.211.1267178985.squirrel@REDACTED> > dated Fri, Feb 26, 2010 at 11:09:21AM +0100, > Zoltan Lajos Kis writes: >> g++: Internal error: Killed (program cc1plus) >> Please submit a full bug report. >> See for instructions. >> make[3]: *** [i686-pc-linux-gnu/wxe_funcs.o] Error 1 >> make[3]: Leaving directory `/tmp/otp_src_R13B04/lib/wx/c_src' > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From rtrlists@REDACTED Fri Feb 26 12:54:20 2010 From: rtrlists@REDACTED (Robert Raschke) Date: Fri, 26 Feb 2010 11:54:20 +0000 Subject: long sender side delays when sending to an external node Message-ID: <6a3ae47e1002260354x20558e9ds4cc5ba98aa129711@mail.gmail.com> Hi, I have a situation where {mbox, other_node} ! {self(), ok} is taking a very long time (8-12 seconds!). That is, the sender is actually blocked in the ! for that time. Anyone have any ideas why such a thing might happen? The other_node is a jinterface Java Node on the same machine, that creates the named Mbox and then receives messages. This is using R12B-5 running on Windows 2003 Server, so I wouldn't be surprised if the OS is getting in the way. But other potential culprits could be virus checking SW. But I'm a bit out of my depth here. Does anyone have any pointers for avenues of investigation? Thanks, Robby PS I previously started a thread where I mistakenly thought an after clause wasn't timing properly. Additional logging told it's the send that's chewing the time not the receive. From humaira.surve@REDACTED Fri Feb 26 13:02:08 2010 From: humaira.surve@REDACTED (Humaira Surve) Date: Fri, 26 Feb 2010 14:02:08 +0200 Subject: [erlang-questions] Newbie - eldap and threads In-Reply-To: <4ac8254d1002251030q7820bcf1pb31a8b055dba2d7d@mail.gmail.com> References: <930e5b151002180021y2f17a5fbm6f77b0846f7059cf@mail.gmail.com> <4ac8254d1002200508j911b30emfcfba0e8499e987f@mail.gmail.com> <4ac8254d1002231634x4ac64dd1g623bbb0a745985bb@mail.gmail.com> <4ac8254d1002240555y4acfc317uedf38924af432dc4@mail.gmail.com> <930e5b151002240658h79cb6be5oc579abdf43dc33b1@mail.gmail.com> <4ac8254d1002240932v5cdc83c3o3a6ee849f0d62109@mail.gmail.com> <4ac8254d1002251030q7820bcf1pb31a8b055dba2d7d@mail.gmail.com> Message-ID: <930e5b151002260402r7340b99ft64f789b558121c89@mail.gmail.com> Hi, I will contact Tobbe about integrating the changes. Time to give back :) Regards, Humaira On Thu, Feb 25, 2010 at 8:30 PM, Tuncer Ayaz wrote: > On Wed, Feb 24, 2010 at 6:32 PM, Tuncer Ayaz > wrote: > > On Wed, Feb 24, 2010 at 4:08 PM, Chandru > > wrote: > >> Hi, > >> > >> On 24 February 2010 14:58, Humaira Surve > wrote: > >>> Hi Chandru, Tuncer, > >>> > >>> I've been playing around with the FSM version but I'm struggling to run > it. > >>> > >>> My logs say that count:inc cannot be found. Do either of you know where > to > >>> find this count library? > >>> > >> > >> Sorry about that, I forgot to remove those calls. The 'count' module > >> is part of an internal application which we use to record statistics. > >> Feel free to rip out all count:inc invocations. > >> > >>> I think it might be nice to have a copy of the FSM version on a central > >>> repository. I'm happy to assist with uploading it / writing up some > simple > >>> install notes once I have it working. > >> > >> github? > > > > I talked to Tobbe and he would be glad to accept relevant changes. > > He also told me that ejabberd carries their own eldap version. I'm > > not heavily using LDAP myself right now so it might be best if you > > Just in case the mail was possibly mis-worded: > 'you' referred to either Humaira or Chandru as developers > who seem to have a need for and interest in eldap. > > I leave it up to you guys to coordinate with Tobbe :). > If you need any help/assistance ping me off-list. > > > work on this. I've only been trying to streamline the different > > eldap versions into one canonical repo and work from there. > From bengt.kleberg@REDACTED Fri Feb 26 14:58:32 2010 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 26 Feb 2010 14:58:32 +0100 Subject: how: Another library flatten function? Message-ID: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Greetings, I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" Is there another flatten somewhere? bengt From rtrlists@REDACTED Fri Feb 26 15:27:20 2010 From: rtrlists@REDACTED (Robert Raschke) Date: Fri, 26 Feb 2010 14:27:20 +0000 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Message-ID: <6a3ae47e1002260627n7af20675x6e9676ba11ef9bfd@mail.gmail.com> On Fri, Feb 26, 2010 at 1:58 PM, Bengt Kleberg wrote: > Greetings, > > I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] > I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] > lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" > > Is there another flatten somewhere? > > I take it you couldn't easily change your strings to be binaries? 1> lists:flatten([<<"asd">>,[[<<"Flow">>,<<"kalle">>]],[<<"Sub">>,<<"F">>]]). [<<"asd">>,<<"Flow">>,<<"kalle">>,<<"Sub">>,<<"F">>] Robby From bengt.kleberg@REDACTED Fri Feb 26 16:23:00 2010 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 26 Feb 2010 16:23:00 +0100 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <6a3ae47e1002260627n7af20675x6e9676ba11ef9bfd@mail.gmail.com> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <6a3ae47e1002260627n7af20675x6e9676ba11ef9bfd@mail.gmail.com> Message-ID: <1267197780.4783.33.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Easily change them, no. I would have to go over the list of lists and change them. But this is the best suggestion so far. bengt On Fri, 2010-02-26 at 15:27 +0100, Robert Raschke wrote: > > On Fri, Feb 26, 2010 at 1:58 PM, Bengt Kleberg > wrote: > Greetings, > > I have the following list: > ["asd",[["Flow","kalle"]],["Sub","F"]] > I would like to flatten it to: > ["asd","Flow","kalle","Sub","F"] > lists:flatten/1 is too effective. It gives me: > "asdFlowkalleSubF" > > Is there another flatten somewhere? > > > I take it you couldn't easily change your strings to be binaries? > > 1> > lists:flatten([<<"asd">>,[[<<"Flow">>,<<"kalle">>]],[<<"Sub">>,<<"F">>]]). > [<<"asd">>,<<"Flow">>,<<"kalle">>,<<"Sub">>,<<"F">>] > > > Robby > > From hd2010@REDACTED Fri Feb 26 16:43:20 2010 From: hd2010@REDACTED (Henning Diedrich) Date: Fri, 26 Feb 2010 16:43:20 +0100 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <1267197780.4783.33.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <6a3ae47e1002260627n7af20675x6e9676ba11ef9bfd@mail.gmail.com> <1267197780.4783.33.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Message-ID: <4B87EC18.8020702@eonblast.com> Regex may come in handy. Could make it as easy as \W"\w and \w"\W. Bengt Kleberg wrote: > Easily change them, no. I would have to go over the list of lists and > change them. But this is the best suggestion so far. > > > bengt > > On Fri, 2010-02-26 at 15:27 +0100, Robert Raschke wrote: > >> On Fri, Feb 26, 2010 at 1:58 PM, Bengt Kleberg >> wrote: >> Greetings, >> >> I have the following list: >> ["asd",[["Flow","kalle"]],["Sub","F"]] >> I would like to flatten it to: >> ["asd","Flow","kalle","Sub","F"] >> lists:flatten/1 is too effective. It gives me: >> "asdFlowkalleSubF" >> >> Is there another flatten somewhere? >> >> >> I take it you couldn't easily change your strings to be binaries? >> >> 1> >> lists:flatten([<<"asd">>,[[<<"Flow">>,<<"kalle">>]],[<<"Sub">>,<<"F">>]]). >> [<<"asd">>,<<"Flow">>,<<"kalle">>,<<"Sub">>,<<"F">>] >> >> >> Robby >> >> >> > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From rumata-estor@REDACTED Fri Feb 26 16:50:28 2010 From: rumata-estor@REDACTED (Dmitry Belayev) Date: Fri, 26 Feb 2010 18:50:28 +0300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Message-ID: <4B87EDC4.9060404@nm.ru> You can write your own: f(List) -> lists:reverse(f(List, [])). f([], A) -> A; f([L|_]=I, A) when is_number(L) -> [I | A]; f([H|Tail], A) -> f(Tail, f(H, A)). Bengt Kleberg wrote: > Greetings, > > I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] > I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] > lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" > > Is there another flatten somewhere? > > > bengt > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > > From rvirding@REDACTED Fri Feb 26 17:00:21 2010 From: rvirding@REDACTED (Robert Virding) Date: Fri, 26 Feb 2010 17:00:21 +0100 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <4B87EDC4.9060404@nm.ru> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> Message-ID: <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> I personally think this is the best solution, write your own function that is, as it is such a simple function to start with. Of course, I wouldn't use reverse but that is just a matter of detail. :-) Robert On 26 February 2010 16:50, Dmitry Belayev wrote: > You can write your own: > > f(List) -> > ? lists:reverse(f(List, [])). > > f([], A) -> > ? A; > f([L|_]=I, A) when is_number(L) -> > ? [I | A]; > f([H|Tail], A) -> > ? f(Tail, f(H, A)). > > Bengt Kleberg wrote: >> >> Greetings, >> >> I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] >> I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] >> lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" >> >> Is there another flatten somewhere? >> >> >> bengt >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> >> > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From rumata-estor@REDACTED Fri Feb 26 17:22:36 2010 From: rumata-estor@REDACTED (Dmitry Belayev) Date: Fri, 26 Feb 2010 19:22:36 +0300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> Message-ID: <4B87F54C.2060208@nm.ru> How do you propose to remove lists:reverse? To use A ++ [I] in the second clause? I don't think that would be optimal solution. Robert Virding wrote: > I personally think this is the best solution, write your own function > that is, as it is such a simple function to start with. Of course, I > wouldn't use reverse but that is just a matter of detail. :-) > > Robert > > On 26 February 2010 16:50, Dmitry Belayev wrote: > >> You can write your own: >> >> f(List) -> >> lists:reverse(f(List, [])). >> >> f([], A) -> >> A; >> f([L|_]=I, A) when is_number(L) -> >> [I | A]; >> f([H|Tail], A) -> >> f(Tail, f(H, A)). >> >> Bengt Kleberg wrote: >> >>> Greetings, >>> >>> I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] >>> I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] >>> lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" >>> >>> Is there another flatten somewhere? >>> >>> >>> bengt >>> >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >>> >>> >>> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> >> > > From kagato@REDACTED Fri Feb 26 18:29:25 2010 From: kagato@REDACTED (Jayson Vantuyl) Date: Fri, 26 Feb 2010 09:29:25 -0800 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <4B87EDC4.9060404@nm.ru> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> Message-ID: <235221A5-E6F2-48FE-88B5-3C74BF5E891C@souja.net> Or: flat(L) -> lists:map(fun lists:flatten/1,L). Or: flat(L) -> [ lists:flatten(X) || X <- L ]. Sent from my iPhone On Feb 26, 2010, at 7:50 AM, Dmitry Belayev wrote: > You can write your own: > > f(List) -> > lists:reverse(f(List, [])). > > f([], A) -> > A; > f([L|_]=I, A) when is_number(L) -> > [I | A]; > f([H|Tail], A) -> > f(Tail, f(H, A)). > > Bengt Kleberg wrote: >> Greetings, >> >> I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] >> I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] >> lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" >> >> Is there another flatten somewhere? >> >> >> bengt >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> >> >> > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > From g9414002.pccu.edu.tw@REDACTED Fri Feb 26 23:07:13 2010 From: g9414002.pccu.edu.tw@REDACTED (=?UTF-8?B?6buD6ICA6LOiIChZYXUtSHNpZW4gSHVhbmcp?=) Date: Sat, 27 Feb 2010 06:07:13 +0800 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <235221A5-E6F2-48FE-88B5-3C74BF5E891C@souja.net> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <235221A5-E6F2-48FE-88B5-3C74BF5E891C@souja.net> Message-ID: On Fri, Feb 26, 2010 at 9:58 PM, Bengt Kleberg wrote: > Greetings, > > I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] > I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] > lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" > > Is there another flatten somewhere? > The following page tells us that lists:flatten/1 is expensive and even more expensive than ++. http://www.erlang.org/doc/efficiency_guide/listHandling.html And in some cases, lists:append/1 is used for avoiding calling the lists:flattten/1. On Fri, Feb 26, 2010 at 11:50 PM, Dmitry Belayev wrote: > You can write your own: > > f(List) -> > lists:reverse(f(List, [])). > > f([], A) -> > A; > f([L|_]=I, A) when is_number(L) -> > [I | A]; > f([H|Tail], A) -> > f(Tail, f(H, A)). > My solution without lists:reverse/1, flatten([]) -> []; flatten([[S|Ss]|Xs]) when is_number(S) -> [[S|Ss]|flatten(Xs)]; flatten([Xs|Ys]) -> flatten(Xs ++ Ys). Every string occurring in the head of a list is picked out first, or a head of a list which is also a list is appended. Though it looks not efficiency, the page http://www.erlang.org/doc/efficiency_guide/myths.html#id2253656 says that it's somewhat OK. On Sat, Feb 27, 2010 at 1:29 AM, Jayson Vantuyl wrote: > Or: > > flat(L) -> lists:map(fun lists:flatten/1,L). > > Or: > > flat(L) -> [ lists:flatten(X) || X <- L ]. > > Sent from my iPhone > > > lists:flatten/1 is more expensive than ++. From fritchie@REDACTED Fri Feb 26 23:11:05 2010 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 26 Feb 2010 16:11:05 -0600 Subject: [erlang-questions] Frequent Node Disconnects In-Reply-To: Message of "Fri, 26 Feb 2010 10:25:52 +0800." <329C7AC8-0731-426E-AFC9-32588AFEFD99@gmail.com> Message-ID: <29039.1267222265@snookles.snookles.com> Jan Vincent wrote: jvl> I find my erlang nodes in a distributed system frequently being jvl> disconnected under light load. What symptoms should I look out for jvl> why this happens? Sorry, you didn't mention if you were using virtual machines or not. Xen, VMware, and others frequently have problems with guest OS clocks not keeping anywhere close to the hosts's OS clock, much less "real" time. If your Erlang nodes have different values for -kernel net_ticktime, you're almost guaranteed to have unpredictable disconnection events. Otherwise, use erlang:system_monitor(), preferably on all nodes, to get more detail about each specific disconnection. When on all nodes, you can compare: did node A and node B agree about the time and/or the reason for the disconnection? -Scott From caio.ariede@REDACTED Fri Feb 26 23:15:36 2010 From: caio.ariede@REDACTED (caio ariede) Date: Fri, 26 Feb 2010 19:15:36 -0300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <235221A5-E6F2-48FE-88B5-3C74BF5E891C@souja.net> Message-ID: <6a9ba5691002261415h2c65b17aqccc79e6913e62fa7@mail.gmail.com> Do you mean lists:reverse? Caio Ariede http://caioariede.com/ 2010/2/26 ??? (Yau-Hsien Huang) > On Fri, Feb 26, 2010 at 9:58 PM, Bengt Kleberg > > wrote: > > > Greetings, > > > > I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] > > I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] > > lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" > > > > Is there another flatten somewhere? > > > > The following page tells us that lists:flatten/1 is expensive and even more > expensive than ++. > http://www.erlang.org/doc/efficiency_guide/listHandling.html > And in some cases, lists:append/1 is used for avoiding calling the > lists:flattten/1. > > On Fri, Feb 26, 2010 at 11:50 PM, Dmitry Belayev > wrote: > > > You can write your own: > > > > f(List) -> > > lists:reverse(f(List, [])). > > > > f([], A) -> > > A; > > f([L|_]=I, A) when is_number(L) -> > > [I | A]; > > f([H|Tail], A) -> > > f(Tail, f(H, A)). > > > > My solution without lists:reverse/1, > > flatten([]) -> > []; > flatten([[S|Ss]|Xs]) when is_number(S) -> > [[S|Ss]|flatten(Xs)]; > flatten([Xs|Ys]) -> > flatten(Xs ++ Ys). > > Every string occurring in the head of a list is picked out first, or a head > of a list which is also > a list is appended. Though it looks not efficiency, the page > http://www.erlang.org/doc/efficiency_guide/myths.html#id2253656 > says that it's somewhat OK. > > On Sat, Feb 27, 2010 at 1:29 AM, Jayson Vantuyl wrote: > > > Or: > > > > flat(L) -> lists:map(fun lists:flatten/1,L). > > > > Or: > > > > flat(L) -> [ lists:flatten(X) || X <- L ]. > > > > Sent from my iPhone > > > > > > > lists:flatten/1 is more expensive than ++. > From fritchie@REDACTED Fri Feb 26 23:16:37 2010 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 26 Feb 2010 16:16:37 -0600 Subject: [erlang-questions] debugging remote node In-Reply-To: Message of "Fri, 26 Feb 2010 09:59:52 +0100." <95be1d3b1002260059h579e00ebl351bcdeef817b45e@mail.gmail.com> Message-ID: <29338.1267222597@snookles.snookles.com> Vlad Dumitrescu wrote: vd> I can load and run code on a remote node and it executes just fine. vd> The problem is that if I start the debugger and set a breakpoint, vd> it's getting activated only if the remote node shares filesystem vd> with the local machine. Looking at the debugger code, I see that the vd> interpreter uses read_file to load the code to interpret, which vd> would explain the behaviour. Ah, sorry, I didn't realize the question was about the "debugger" OTP application specifically ... I don't have anything specific or helpful to add, alas. -Scott From fritchie@REDACTED Fri Feb 26 23:20:29 2010 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Fri, 26 Feb 2010 16:20:29 -0600 Subject: [erlang-questions] long sender side delays when sending to an external node In-Reply-To: Message of "Fri, 26 Feb 2010 11:54:20 GMT." <6a3ae47e1002260354x20558e9ds4cc5ba98aa129711@mail.gmail.com> Message-ID: <29630.1267222829@snookles.snookles.com> Robert Raschke wrote: rr> I have a situation where {mbox, other_node} ! {self(), ok} is taking rr> a very long time (8-12 seconds!). That is, the sender is actually rr> blocked in the ! for that time. Robby, have you seen my post to the list earlier this month about 'busy_dist_port' system events? If the Erlang port representing the TCP port used for inter-node communication becomes "busy", then a process (any process) attempting to send a message through that port will be unscheduled by the scheduler and won't be rescheduled until the busy port is itself unblocked. That's one way it could happen, at least. There may be others. -Scott From rvirding@REDACTED Fri Feb 26 23:31:34 2010 From: rvirding@REDACTED (Robert Virding) Date: Fri, 26 Feb 2010 23:31:34 +0100 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <4B87F54C.2060208@nm.ru> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> Message-ID: <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> Here are two very similar versions based on the code in lists.erl. They are both coded in a very straight forward style (I think) without reverse or append, but I haven't measured them. -module(ft). -export([fl1/2, fl2/2]). fl1([[C|_]=H|T], Tail) when is_integer(C) -> [H|fl1(T, Tail)]; fl1([H|T], Tail) when is_list(H) -> fl1(H, fl1(T, Tail)); fl1([H|T], Tail) -> [H|fl1(T, Tail)]; fl1([], Tail) -> Tail. fl2([[C|_]=H|T], Tail) when not is_integer(C) -> fl2(H, fl2(T, Tail)); fl2([[]|T], Tail) -> fl2(T, Tail); fl2([H|T], Tail) -> [H|fl2(T, Tail)]; fl2([], Tail) -> Tail. Robert 2010/2/26 Dmitry Belayev : > How do you propose to remove lists:reverse? To use A ++ [I] in the second > clause? I don't think that would be optimal solution. > > Robert Virding wrote: >> >> I personally think this is the best solution, write your own function >> that is, as it is such a simple function to start with. Of course, I >> wouldn't use reverse but that is just a matter of detail. :-) >> >> Robert >> >> On 26 February 2010 16:50, Dmitry Belayev wrote: >> >>> >>> You can write your own: >>> >>> f(List) -> >>> ?lists:reverse(f(List, [])). >>> >>> f([], A) -> >>> ?A; >>> f([L|_]=I, A) when is_number(L) -> >>> ?[I | A]; >>> f([H|Tail], A) -> >>> ?f(Tail, f(H, A)). >>> >>> Bengt Kleberg wrote: >>> >>>> >>>> Greetings, >>>> >>>> I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] >>>> I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] >>>> lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" >>>> >>>> Is there another flatten somewhere? >>>> >>>> >>>> bengt >>>> >>>> >>>> ________________________________________________________________ >>>> erlang-questions (at) erlang.org mailing list. >>>> See http://www.erlang.org/faq.html >>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>>> >>>> >>>> >>>> >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >>> >>> >> >> > > From steven.charles.davis@REDACTED Fri Feb 26 23:33:33 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 26 Feb 2010 14:33:33 -0800 (PST) Subject: Binaries and "strings" Message-ID: <40d3d104-bc97-4f60-9cf9-83c0470fb1d1@g26g2000yqn.googlegroups.com> Found this binary behavior interesting: 1> <<"one", "two">>. <<"onetwo">> 2> <<"one" "two">>. <<"onetwo">> Maybe others will also. /s From rvirding@REDACTED Fri Feb 26 23:42:49 2010 From: rvirding@REDACTED (Robert Virding) Date: Fri, 26 Feb 2010 23:42:49 +0100 Subject: [erlang-questions] Binaries and "strings" In-Reply-To: <40d3d104-bc97-4f60-9cf9-83c0470fb1d1@g26g2000yqn.googlegroups.com> References: <40d3d104-bc97-4f60-9cf9-83c0470fb1d1@g26g2000yqn.googlegroups.com> Message-ID: <3dbc6d1c1002261442o3a5a44bfwc71d99d609ff1cca@mail.gmail.com> On 26 February 2010 23:33, Steve Davis wrote: > Found this binary behavior interesting: > > 1> <<"one", "two">>. > <<"onetwo">> This creates a binary containing the characters (bytes) of the two string. > 2> <<"one" "two">>. > <<"onetwo">> Here the two string are concatenated to one already in the parser, so you are actually writing <<"abcdef">>. This is feature is useful as it allows you to split a long string into many sub strings without extra computational cost. You can also write "abc" ++ "def" in code and the compiler will optimise away the ++. It can always do this if the first argument to ++ is a list literal. Robert From steven.charles.davis@REDACTED Fri Feb 26 23:53:01 2010 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 26 Feb 2010 14:53:01 -0800 (PST) Subject: Binaries and "strings" In-Reply-To: <3dbc6d1c1002261442o3a5a44bfwc71d99d609ff1cca@mail.gmail.com> References: <40d3d104-bc97-4f60-9cf9-83c0470fb1d1@g26g2000yqn.googlegroups.com> <3dbc6d1c1002261442o3a5a44bfwc71d99d609ff1cca@mail.gmail.com> Message-ID: <096174a9-0574-4ead-9478-cb730c35ed35@g26g2000yqn.googlegroups.com> My thanks for the additional elucidation and explanation. It did intrigue me. For sure, there are exceptionally intelligent decisions all the way through the language and platform of which this is just one example. Regards, Steve On Feb 26, 4:42?pm, Robert Virding wrote: > On 26 February 2010 23:33, Steve Davis wrote: > > > Found this binary behavior interesting: > > > 1> <<"one", "two">>. > > <<"onetwo">> > > This creates a binary containing the characters (bytes) of the two string. > > > 2> <<"one" "two">>. > > <<"onetwo">> > > Here the two string are concatenated to one already in the parser, so > you are actually writing <<"abcdef">>. This is feature is useful as it > allows you to split a long string into many sub strings without extra > computational cost. > > You can also write "abc" ++ "def" in code and the compiler will > optimise away the ++. It can always do this if the first argument to > ++ is a list literal. > > Robert > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > Seehttp://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscr...@REDACTED From g9414002.pccu.edu.tw@REDACTED Sat Feb 27 00:26:24 2010 From: g9414002.pccu.edu.tw@REDACTED (=?UTF-8?B?6buD6ICA6LOiIChZYXUtSHNpZW4gSHVhbmcp?=) Date: Sat, 27 Feb 2010 07:26:24 +0800 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> Message-ID: That's right. The second parameter is called Accumulating Parameter. The accumulating technique used by Dmitry is to accumulate heads of lists to AP, and then when base case is met lists:reverse/1 must be applied to the result. Your method is to attach heads of lists in front of AP, so it's no need to reverse the result. 2010/2/27 Robert Virding > Here are two very similar versions based on the code in lists.erl. > They are both coded in a very straight forward style (I think) without > reverse or append, but I haven't measured them. > > -module(ft). > > -export([fl1/2, fl2/2]). > > fl1([[C|_]=H|T], Tail) when is_integer(C) -> > [H|fl1(T, Tail)]; > fl1([H|T], Tail) when is_list(H) -> > fl1(H, fl1(T, Tail)); > fl1([H|T], Tail) -> > [H|fl1(T, Tail)]; > The third clause means that the head of H is not an integer and H is not a list, but what case does [H|T] match? I think the clause is redundant. > fl1([], Tail) -> Tail. > > fl2([[C|_]=H|T], Tail) when not is_integer(C) -> > fl2(H, fl2(T, Tail)); > fl2([[]|T], Tail) -> fl2(T, Tail); > If the case below would pick H as a string and glue it in front of the result of Tail, the above case is not needed, because H can be a string or an empty string. The above clause is not necessary unless any empty string must be strip out from the deep string list. fl2([H|T], Tail) -> > [H|fl2(T, Tail)]; > fl2([], Tail) -> Tail. > > Robert > > 2010/2/26 Dmitry Belayev : > > How do you propose to remove lists:reverse? To use A ++ [I] in the second > > clause? I don't think that would be optimal solution. > > > > Robert Virding wrote: > >> > >> I personally think this is the best solution, write your own function > >> that is, as it is such a simple function to start with. Of course, I > >> wouldn't use reverse but that is just a matter of detail. :-) > >> > >> Robert > >> > >> On 26 February 2010 16:50, Dmitry Belayev wrote: > >> > >>> > >>> You can write your own: > >>> > >>> f(List) -> > >>> lists:reverse(f(List, [])). > >>> > >>> f([], A) -> > >>> A; > >>> f([L|_]=I, A) when is_number(L) -> > >>> [I | A]; > >>> f([H|Tail], A) -> > >>> f(Tail, f(H, A)). > >>> > >>> Bengt Kleberg wrote: > >>> > >>>> > >>>> Greetings, > >>>> > >>>> I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] > >>>> I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] > >>>> lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" > >>>> > >>>> Is there another flatten somewhere? > >>>> > >>>> > >>>> bengt > >>>> > >>>> > >>>> ________________________________________________________________ > >>>> erlang-questions (at) erlang.org mailing list. > >>>> See http://www.erlang.org/faq.html > >>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > >>>> > >>>> > >>>> > >>>> > >>> > >>> ________________________________________________________________ > >>> erlang-questions (at) erlang.org mailing list. > >>> See http://www.erlang.org/faq.html > >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > >>> > >>> > >>> > >> > >> > > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From g9414002.pccu.edu.tw@REDACTED Sat Feb 27 00:28:58 2010 From: g9414002.pccu.edu.tw@REDACTED (=?UTF-8?B?6buD6ICA6LOiIChZYXUtSHNpZW4gSHVhbmcp?=) Date: Sat, 27 Feb 2010 07:28:58 +0800 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> Message-ID: That's right. The second parameter is called Accumulating Parameter. The accumulating technique used by Dmitry is to accumulate heads of lists to AP, and then when base case is met lists:reverse/1 must be applied to the result. Your method is to first attach tails of lists in front of AP, so it's no need to reverse the result. 2010/2/27 Robert Virding Here are two very similar versions based on the code in lists.erl. > They are both coded in a very straight forward style (I think) without > reverse or append, but I haven't measured them. > > -module(ft). > > -export([fl1/2, fl2/2]). > > fl1([[C|_]=H|T], Tail) when is_integer(C) -> > [H|fl1(T, Tail)]; > fl1([H|T], Tail) when is_list(H) -> > fl1(H, fl1(T, Tail)); > fl1([H|T], Tail) -> > [H|fl1(T, Tail)]; > The third clause means that the head of H is not an integer and H is not a list, but what case does [H|T] match? I think the clause is redundant. > fl1([], Tail) -> Tail. > > fl2([[C|_]=H|T], Tail) when not is_integer(C) -> > fl2(H, fl2(T, Tail)); > fl2([[]|T], Tail) -> fl2(T, Tail); > If the case below would pick H as a string and glue it in front of the result of Tail, the above case is not needed, because H can be a string or an empty string. The above clause is not necessary unless any empty string must be strip out from the deep string list. fl2([H|T], Tail) -> > [H|fl2(T, Tail)]; > fl2([], Tail) -> Tail. > > Robert > > 2010/2/26 Dmitry Belayev : > > How do you propose to remove lists:reverse? To use A ++ [I] in the second > > clause? I don't think that would be optimal solution. > > > > Robert Virding wrote: > >> > >> I personally think this is the best solution, write your own function > >> that is, as it is such a simple function to start with. Of course, I > >> wouldn't use reverse but that is just a matter of detail. :-) > >> > >> Robert > >> > >> On 26 February 2010 16:50, Dmitry Belayev wrote: > >> > >>> > >>> You can write your own: > >>> > >>> f(List) -> > >>> lists:reverse(f(List, [])). > >>> > >>> f([], A) -> > >>> A; > >>> f([L|_]=I, A) when is_number(L) -> > >>> [I | A]; > >>> f([H|Tail], A) -> > >>> f(Tail, f(H, A)). > >>> > >>> Bengt Kleberg wrote: > >>> > >>>> > >>>> Greetings, > >>>> > >>>> I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] > >>>> I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] > >>>> lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" > >>>> > >>>> Is there another flatten somewhere? > >>>> > >>>> > >>>> bengt > >>>> > >>>> > >>>> ________________________________________________________________ > >>>> erlang-questions (at) erlang.org mailing list. > >>>> See http://www.erlang.org/faq.html > >>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > >>>> > >>>> > >>>> > >>>> > >>> > >>> ________________________________________________________________ > >>> erlang-questions (at) erlang.org mailing list. > >>> See http://www.erlang.org/faq.html > >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > >>> > >>> > >>> > >> > >> > > > > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From acton@REDACTED Sat Feb 27 01:34:42 2010 From: acton@REDACTED (Brian Acton) Date: Fri, 26 Feb 2010 16:34:42 -0800 Subject: Mnesia - 2Gb or 4Gb - which is it? Message-ID: <7a9fe0201002261634k48909cadn5d6416f1b999edfe@mail.gmail.com> Hi guys, I'm trying to figure out the table limit with Mnesia. If I read this document http://www.erlang.org/doc/man/dets.html I get the following: The size of Dets files cannot exceed 2 GB. However, if I read this document http://erlang.org/faq/mnesia.html I see this in section 11.5 Dets uses 32 bit integers for file offsets, so the largest possible mnesia table (for now) is 4Gb. Is this a documentation bug? Is there some weird inter-relation between mnesia and dets that I'm not coming across? Thx, --b From foolishewe@REDACTED Sat Feb 27 07:39:01 2010 From: foolishewe@REDACTED (Foolish Ewe) Date: Sat, 27 Feb 2010 06:39:01 +0000 Subject: Dialyzer version v2.2.0 From Erlang 13B04 failure Message-ID: Hello All: I have been very keen to try the new distribution and was in particular looking forward to the new dialyzer version that has parameterized support (so that we can check our code with it). I get the errors attached at the end of this e-mail (I show the plt file construction for completeness, the error happens in the actual dialyzer analysis), any ideas about what is happening and how I can help to fix it (help in creating a simple test case would be appreciated). Thanks: Bill M. cd /home/myuserid/securebackup/src/erlang/ make dialyzer.log dialyzer --build_plt -r /usr/lib64/erlang/lib/stdlib-1.16.5 /usr/lib64/erlang/lib/kernel-2.13.5 /usr/lib64/erlang/lib/mnesia-4.4.13 /usr/lib64/erlang/lib/os_mon-2.2.5 /usr/lib64/erlang/lib/crypto-1.6.4 /usr/lib64/erlang/lib/tools-2.6.5.1 --output_plt dialyzer.plt Compiling some key modules to native code... done in 1m15.97s Creating PLT dialyzer.plt ... Unknown functions: alarm_handler:clear_alarm/1 alarm_handler:set_alarm/1 compile:file/2 compile:forms/2 compile:noenv_forms/2 compile:output_generated/1 dbg:trace_client/3 dbg:trace_port/2 erl_prim_loader:get_cwd/0 erl_prim_loader:get_cwd/1 erl_prim_loader:list_dir/1 erl_prim_loader:prim_get_cwd/2 erl_prim_loader:prim_get_file/2 erl_prim_loader:prim_init/0 erl_prim_loader:prim_list_dir/2 erl_prim_loader:prim_read_file_info/2 erl_prim_loader:read_file_info/1 erl_prim_loader:set_primary_archive/3 erlang:integer_to_list/2 erlang:list_to_integer/2 erlang:max/2 erlang:min/2 erlang:spawn_monitor/1 erlang:spawn_opt/5 httpd:parse_query/1 init:archive_extension/0 init:code_path_choice/0 init:ensure_loaded/1 init:fetch_loaded/0 init:get_argument/1 init:get_arguments/0 init:get_plain_arguments/0 init:notify_when_started/1 init:objfile_extension/0 init:stop/0 init:wait_until_started/0 otp_mib:erl_node_table/3 prim_file:altname/2 prim_file:close/1 prim_file:copy/3 prim_file:del_dir/2 prim_file:delete/2 prim_file:get_cwd/1 prim_file:get_cwd/2 prim_file:list_dir/2 prim_file:make_dir/2 prim_file:make_link/3 prim_file:make_symlink/3 prim_file:open/2 prim_file:position/2 prim_file:read/2 prim_file:read_file/1 prim_file:read_file_info/1 prim_file:read_file_info/2 prim_file:read_link/2 prim_file:read_link_info/2 prim_file:rename/3 prim_file:set_cwd/2 prim_file:start/0 prim_file:stop/1 prim_file:sync/1 prim_file:truncate/1 prim_file:write/2 prim_file:write_file/2 prim_file:write_file_info/2 prim_file:write_file_info/3 prim_inet:accept/1 prim_inet:accept/2 prim_inet:bind/3 prim_inet:chgopts/2 prim_inet:close/1 prim_inet:connect/3 prim_inet:connect/4 prim_inet:fdopen/3 prim_inet:getfd/1 prim_inet:gethostname/1 prim_inet:getiflist/1 prim_inet:getopt/2 prim_inet:getopts/2 prim_inet:getservbyname/3 prim_inet:getservbyport/3 prim_inet:getstat/2 prim_inet:getstatus/1 prim_inet:gettype/1 prim_inet:ifget/3 prim_inet:ifset/3 prim_inet:is_sockopt_val/2 prim_inet:listen/2 prim_inet:open/2 prim_inet:peername/1 prim_inet:recv/2 prim_inet:recv/3 prim_inet:recvfrom/2 prim_inet:recvfrom/3 prim_inet:send/2 prim_inet:send/3 prim_inet:sendmsg/3 prim_inet:sendto/4 prim_inet:setopt/3 prim_inet:setopts/2 prim_inet:setpeername/2 prim_inet:setsockname/2 prim_inet:shutdown/2 prim_inet:sockname/1 prim_inet:unrecv/2 prim_zip:close/1 prim_zip:open/3 snmp_shadow_table:table_func/2 snmp_shadow_table:table_func/4 snmpa:load_mibs/2 snmpa:unload_mibs/2 sys_pre_expand:module/2 webtool:start/0 webtool:start_tools/2 webtool:stop/0 webtool:stop_tools/2 zlib:close/1 zlib:crc32/1 zlib:crc32/2 zlib:crc32/3 zlib:deflate/3 zlib:deflateEnd/1 zlib:deflateInit/2 zlib:deflateInit/6 zlib:inflate/2 zlib:inflateEnd/1 zlib:inflateInit/2 zlib:open/0 zlib:uncompress/1 done in 10m33.28s done (passed successfully) #dialyzer --build_plt -r /usr/lib64/erlang/lib --output_plt dialyzer.plt #dialyzer --build_plt -r /usr/lib64/erlang/lib/stdlib-1.15.4 /usr/lib64/erlang/lib/kernel-2.12.4/ /usr/lib64/erlang/lib/mnesia-4.4.5 /usr/lib64/erlang/lib/os_mon-2.1.7 /usr/lib64/erlang/lib/crypto-1.5.2.1 /usr/lib64/erlang/lib/tools-2.6.2 --output_plt dialyzer.plt # we need to eliminate duplicate modules # rm -f ./log4erl/src/mochinum.erl ./log4erl/ebin/mochinum.beam dialyzer --verbose --plt dialyzer.plt -Wunmatched_returns -Wunderspecs -r . | tee dialyzer.log Checking whether the PLT dialyzer.plt is up-to-date... yes Compiling some key modules to native code... done in 1m18.07s Proceeding with analysis... dialyzer: Analysis failed with error: {{case_clause,8}, [{erl_types,t_form_to_string,1}, {erl_types,t_form_to_string,1}, {erl_types,t_form_to_string,1}, {cerl_typean,pp_hook,0}, {dialyzer_succ_typings,get_warnings,7}, {dialyzer_analysis_callgraph,analyze_callgraph,2}, {dialyzer_analysis_callgraph,analysis_start,...}, {cerl_typean,...}]} Last messages in the log cache: Dataflow of one SCC: [b_cfijk_runner] Dataflow of one SCC: [c_negotiate_storage_handler] Dataflow of one SCC: [restore] Dataflow of one SCC: [generic_handler] Dataflow of one SCC: [a_bras_handler] Dataflow of one SCC: [test_bras] Dataflow of one SCC: [test_crc] Dataflow of one SCC: [client_state] Dataflow of one SCC: [a_brf_handler] Dataflow of one SCC: [a_crc_handler] # Uncomment the following to run a modified source version of the dialyzer on Bill's machine (currently turns on dialyzer's debugging output) #~/tools/otp_src_R12B-4/bin/dialyzer --verbose --plt dialyzer.plt -Wunmatched_returns -Wunderspecs -r . | tee dialyzer.log Compilation finished at Fri Feb 26 01:17:32 _________________________________________________________________ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/201469230/direct/01/ From kostis@REDACTED Sat Feb 27 08:10:25 2010 From: kostis@REDACTED (Kostis Sagonas) Date: Sat, 27 Feb 2010 09:10:25 +0200 Subject: [erlang-questions] Dialyzer version v2.2.0 From Erlang 13B04 failure In-Reply-To: References: Message-ID: <4B88C561.90801@cs.ntua.gr> Foolish Ewe wrote: > Hello All: > > I have been very keen to try the new distribution and was in particular > looking forward to the new dialyzer version that has parameterized > support (so that we can check our code with it). I get the errors > attached at the end of this e-mail (I show the plt file construction for completeness, the error happens in the actual dialyzer analysis), any ideas about what is happening > and how I can help to fix it (help in creating a simple test case would be appreciated). I took the liberty and condensed your mail below, so that it is more readable. If you look at the place where it says "Last messages in the log cache:", dialyzer is telling you that it tries dataflow analysis on some set of modules [b_cfijk_runner, ..., a_crc_handler]. Most probably the crash occurs in the analysis of one of these modules. Try to minimize this set of modules by analyzing them in subsets and once you have located the minimal such set, please send them to me (preferably off list) so that I look into this. Best, Kostis > dialyzer --verbose --plt dialyzer.plt -Wunmatched_returns -Wunderspecs -r . | tee dialyzer.log > Checking whether the PLT dialyzer.plt is up-to-date... yes > Compiling some key modules to native code... done in 1m18.07s > Proceeding with analysis... > > dialyzer: Analysis failed with error: {{case_clause,8}, > > [{erl_types,t_form_to_string,1}, > {erl_types,t_form_to_string,1}, > {erl_types,t_form_to_string,1}, > {cerl_typean,pp_hook,0}, > {dialyzer_succ_typings,get_warnings,7}, > {dialyzer_analysis_callgraph,analyze_callgraph,2}, > {dialyzer_analysis_callgraph,analysis_start,...}, > {cerl_typean,...}]} > > Last messages in the log cache: > > Dataflow of one SCC: [b_cfijk_runner] > Dataflow of one SCC: [c_negotiate_storage_handler] > Dataflow of one SCC: [restore] > Dataflow of one SCC: [generic_handler] > Dataflow of one SCC: [a_bras_handler] > Dataflow of one SCC: [test_bras] > Dataflow of one SCC: [test_crc] > Dataflow of one SCC: [client_state] > Dataflow of one SCC: [a_brf_handler] > Dataflow of one SCC: [a_crc_handler] From rumata-estor@REDACTED Sat Feb 27 09:34:36 2010 From: rumata-estor@REDACTED (Dmitry Belayev) Date: Sat, 27 Feb 2010 11:34:36 +0300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <235221A5-E6F2-48FE-88B5-3C74BF5E891C@souja.net> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <235221A5-E6F2-48FE-88B5-3C74BF5E891C@souja.net> Message-ID: <4B88D91C.4040606@nm.ru> 1> lists:map(fun lists:flatten/1,["asd",[["Flow","kalle"]],["Sub","F"]]). ["asd","Flowkalle","SubF"] It doesn't look like desired ["asd","Flow","kalle","Sub","F"] Jayson Vantuyl wrote: > > Or: > > flat(L) -> lists:map(fun lists:flatten/1,L). > > Or: > > flat(L) -> [ lists:flatten(X) || X <- L ]. > > Sent from my iPhone > > On Feb 26, 2010, at 7:50 AM, Dmitry Belayev wrote: > >> You can write your own: >> >> f(List) -> >> lists:reverse(f(List, [])). >> >> f([], A) -> >> A; >> f([L|_]=I, A) when is_number(L) -> >> [I | A]; >> f([H|Tail], A) -> >> f(Tail, f(H, A)). >> >> Bengt Kleberg wrote: >>> Greetings, >>> >>> I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] >>> I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] >>> lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" >>> >>> Is there another flatten somewhere? >>> >>> >>> bengt >>> >>> >>> ________________________________________________________________ >>> erlang-questions (at) erlang.org mailing list. >>> See http://www.erlang.org/faq.html >>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>> >>> >>> >> >> >> ________________________________________________________________ >> erlang-questions (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >> > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From rumata-estor@REDACTED Sat Feb 27 09:37:39 2010 From: rumata-estor@REDACTED (Dmitry Belayev) Date: Sat, 27 Feb 2010 11:37:39 +0300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> Message-ID: <4B88D9D3.4070008@nm.ru> It would be best solution in non-strict language like haskell, but in erlang it is not tail-recursive, so it will use more memory. Robert Virding wrote: > Here are two very similar versions based on the code in lists.erl. > They are both coded in a very straight forward style (I think) without > reverse or append, but I haven't measured them. > > -module(ft). > > -export([fl1/2, fl2/2]). > > fl1([[C|_]=H|T], Tail) when is_integer(C) -> > [H|fl1(T, Tail)]; > fl1([H|T], Tail) when is_list(H) -> > fl1(H, fl1(T, Tail)); > fl1([H|T], Tail) -> > [H|fl1(T, Tail)]; > fl1([], Tail) -> Tail. > > fl2([[C|_]=H|T], Tail) when not is_integer(C) -> > fl2(H, fl2(T, Tail)); > fl2([[]|T], Tail) -> fl2(T, Tail); > fl2([H|T], Tail) -> > [H|fl2(T, Tail)]; > fl2([], Tail) -> Tail. > > Robert > > 2010/2/26 Dmitry Belayev : > >> How do you propose to remove lists:reverse? To use A ++ [I] in the second >> clause? I don't think that would be optimal solution. >> >> Robert Virding wrote: >> >>> I personally think this is the best solution, write your own function >>> that is, as it is such a simple function to start with. Of course, I >>> wouldn't use reverse but that is just a matter of detail. :-) >>> >>> Robert >>> >>> On 26 February 2010 16:50, Dmitry Belayev wrote: >>> >>> >>>> You can write your own: >>>> >>>> f(List) -> >>>> lists:reverse(f(List, [])). >>>> >>>> f([], A) -> >>>> A; >>>> f([L|_]=I, A) when is_number(L) -> >>>> [I | A]; >>>> f([H|Tail], A) -> >>>> f(Tail, f(H, A)). >>>> >>>> Bengt Kleberg wrote: >>>> >>>> >>>>> Greetings, >>>>> >>>>> I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] >>>>> I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] >>>>> lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" >>>>> >>>>> Is there another flatten somewhere? >>>>> >>>>> >>>>> bengt >>>>> >>>>> >>>>> ________________________________________________________________ >>>>> erlang-questions (at) erlang.org mailing list. >>>>> See http://www.erlang.org/faq.html >>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>>>> From max.lapshin@REDACTED Sat Feb 27 09:38:38 2010 From: max.lapshin@REDACTED (Max Lapshin) Date: Sat, 27 Feb 2010 11:38:38 +0300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <4B88D91C.4040606@nm.ru> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <235221A5-E6F2-48FE-88B5-3C74BF5E891C@souja.net> <4B88D91C.4040606@nm.ru> Message-ID: To make such a function, you should peek into first element of each list. From rumata-estor@REDACTED Sat Feb 27 09:42:48 2010 From: rumata-estor@REDACTED (Dmitry Belayev) Date: Sat, 27 Feb 2010 11:42:48 +0300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <4B88D9D3.4070008@nm.ru> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> <4B88D9D3.4070008@nm.ru> Message-ID: <4B88DB08.7050702@nm.ru> Shame on me, my own version uses f(_, f(_)) so it is not-tail recursive too. Dmitry Belayev wrote: > > It would be best solution in non-strict language like haskell, but in > erlang it is not tail-recursive, so it will use more memory. > > Robert Virding wrote: >> Here are two very similar versions based on the code in lists.erl. >> They are both coded in a very straight forward style (I think) without >> reverse or append, but I haven't measured them. >> >> -module(ft). >> >> -export([fl1/2, fl2/2]). >> >> fl1([[C|_]=H|T], Tail) when is_integer(C) -> >> [H|fl1(T, Tail)]; >> fl1([H|T], Tail) when is_list(H) -> >> fl1(H, fl1(T, Tail)); >> fl1([H|T], Tail) -> >> [H|fl1(T, Tail)]; >> fl1([], Tail) -> Tail. >> >> fl2([[C|_]=H|T], Tail) when not is_integer(C) -> >> fl2(H, fl2(T, Tail)); >> fl2([[]|T], Tail) -> fl2(T, Tail); >> fl2([H|T], Tail) -> >> [H|fl2(T, Tail)]; >> fl2([], Tail) -> Tail. >> >> Robert >> >> 2010/2/26 Dmitry Belayev : >> >>> How do you propose to remove lists:reverse? To use A ++ [I] in the >>> second >>> clause? I don't think that would be optimal solution. >>> >>> Robert Virding wrote: >>> >>>> I personally think this is the best solution, write your own function >>>> that is, as it is such a simple function to start with. Of course, I >>>> wouldn't use reverse but that is just a matter of detail. :-) >>>> >>>> Robert >>>> >>>> On 26 February 2010 16:50, Dmitry Belayev wrote: >>>> >>>> >>>>> You can write your own: >>>>> >>>>> f(List) -> >>>>> lists:reverse(f(List, [])). >>>>> >>>>> f([], A) -> >>>>> A; >>>>> f([L|_]=I, A) when is_number(L) -> >>>>> [I | A]; >>>>> f([H|Tail], A) -> >>>>> f(Tail, f(H, A)). >>>>> >>>>> Bengt Kleberg wrote: >>>>> >>>>> >>>>>> Greetings, >>>>>> >>>>>> I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] >>>>>> I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] >>>>>> lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" >>>>>> >>>>>> Is there another flatten somewhere? >>>>>> >>>>>> >>>>>> bengt >>>>>> >>>>>> >>>>>> ________________________________________________________________ >>>>>> erlang-questions (at) erlang.org mailing list. >>>>>> See http://www.erlang.org/faq.html >>>>>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED >>>>>> > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From joe@REDACTED Sat Feb 27 10:01:59 2010 From: joe@REDACTED (Joe Williams) Date: Sat, 27 Feb 2010 01:01:59 -0800 Subject: dns server Message-ID: <4B88DF87.5000208@joetify.com> Anyone know of a decent OSS DNS server implementation in Erlang? I found http://code.google.com/p/erldir/ and http://eddie.sourceforge.net/ but they are both out of date and no longer maintained it seems. Thanks for any suggestions. -Joe -- Name: Joseph A. Williams Email: joe@REDACTED Blog: http://www.joeandmotorboat.com/ From per.melin@REDACTED Sat Feb 27 12:21:20 2010 From: per.melin@REDACTED (Per Melin) Date: Sat, 27 Feb 2010 12:21:20 +0100 Subject: [erlang-questions] Binaries and "strings" In-Reply-To: <3dbc6d1c1002261442o3a5a44bfwc71d99d609ff1cca@mail.gmail.com> References: <40d3d104-bc97-4f60-9cf9-83c0470fb1d1@g26g2000yqn.googlegroups.com> <3dbc6d1c1002261442o3a5a44bfwc71d99d609ff1cca@mail.gmail.com> Message-ID: On Fri, Feb 26, 2010 at 11:42 PM, Robert Virding wrote: >> 2> <<"one" "two">>. >> <<"onetwo">> > > Here the two string are concatenated to one already in the parser, so > you are actually writing <<"abcdef">>. This is feature is useful as it > allows you to split a long string into many sub strings without extra > computational cost. Could be worth to mention explicit, since it doesn't seem to be well known, that this of course works over line breaks. It is, as you say, useful for long string literals in your code, like help and usage texts, or raw XML/HTML. 1> "Lorem ipsum dolor sit amet, " 1> "consectetur adipisicing elit". "Lorem ipsum dolor sit amet, consectetur adipisicing elit" From g9414002.pccu.edu.tw@REDACTED Sat Feb 27 14:19:42 2010 From: g9414002.pccu.edu.tw@REDACTED (=?UTF-8?B?6buD6ICA6LOiIChZYXUtSHNpZW4gSHVhbmcp?=) Date: Sat, 27 Feb 2010 21:19:42 +0800 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <4B88DB08.7050702@nm.ru> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> <4B88D9D3.4070008@nm.ru> <4B88DB08.7050702@nm.ru> Message-ID: The basic concept of flattening a list, similar to process a binary tree, is to flatten the head elements which may be a list or not, to flatten the tail which is a list, and to concatenate these two parts. How to make a flattening function tail-recursive? 2010/2/27 Dmitry Belayev > Shame on me, my own version uses f(_, f(_)) so it is not-tail recursive > too. > > > Dmitry Belayev wrote: > >> >> It would be best solution in non-strict language like haskell, but in >> erlang it is not tail-recursive, so it will use more memory. >> >> From rumata-estor@REDACTED Sat Feb 27 14:37:18 2010 From: rumata-estor@REDACTED (Dmitry Belayev) Date: Sat, 27 Feb 2010 16:37:18 +0300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> <4B88D9D3.4070008@nm.ru> <4B88DB08.7050702@nm.ru> Message-ID: <4B89200E.4030701@nm.ru> I'm not sure but: f(List) -> f(List, [], []). f([], [], A) -> lists:reverse(A); f([], [H|T], A) -> f(H, T, A); f([L|_]=I, T, A) when is_number(L) -> f(T, [], [I | A]); f([H|Tail], T, A) -> f(H, [Tail | T], A). ??? (Yau-Hsien Huang) wrote: > The basic concept of flattening a list, similar to process a binary tree, is > to flatten the head > elements which may be a list or not, to flatten the tail which is a list, > and to concatenate > these two parts. How to make a flattening function tail-recursive? > > > 2010/2/27 Dmitry Belayev > > >> Shame on me, my own version uses f(_, f(_)) so it is not-tail recursive >> too. >> >> >> Dmitry Belayev wrote: >> >> >>> It would be best solution in non-strict language like haskell, but in >>> erlang it is not tail-recursive, so it will use more memory. >>> >>> >>> > > From rumata-estor@REDACTED Sat Feb 27 14:39:22 2010 From: rumata-estor@REDACTED (Dmitry Belayev) Date: Sat, 27 Feb 2010 16:39:22 +0300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> <4B88D9D3.4070008@nm.ru> <4B88DB08.7050702@nm.ru> Message-ID: <4B89208A.4010400@nm.ru> It's kind of "handmade" stack. ??? (Yau-Hsien Huang) wrote: > The basic concept of flattening a list, similar to process a binary tree, is > to flatten the head > elements which may be a list or not, to flatten the tail which is a list, > and to concatenate > these two parts. How to make a flattening function tail-recursive? > > > 2010/2/27 Dmitry Belayev > > >> Shame on me, my own version uses f(_, f(_)) so it is not-tail recursive >> too. >> >> >> Dmitry Belayev wrote: >> >> >>> It would be best solution in non-strict language like haskell, but in >>> erlang it is not tail-recursive, so it will use more memory. >>> >>> >>> > > From g9414002.pccu.edu.tw@REDACTED Sat Feb 27 15:00:52 2010 From: g9414002.pccu.edu.tw@REDACTED (=?UTF-8?B?6buD6ICA6LOiIChZYXUtSHNpZW4gSHVhbmcp?=) Date: Sat, 27 Feb 2010 22:00:52 +0800 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <4B89200E.4030701@nm.ru> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> <4B88D9D3.4070008@nm.ru> <4B88DB08.7050702@nm.ru> <4B89200E.4030701@nm.ru> Message-ID: Right, accumulating parameter and tail recursion. Thank you. 2010/2/27 Dmitry Belayev > I'm not sure but: > > f(List) -> > f(List, [], []). > > f([], [], A) -> > lists:reverse(A); > f([], [H|T], A) -> > f(H, T, A); > f([L|_]=I, T, A) when is_number(L) -> > f(T, [], [I | A]); > f([H|Tail], T, A) -> > f(H, [Tail | T], A). > > > > ??? (Yau-Hsien Huang) wrote: > >> The basic concept of flattening a list, similar to process a binary tree, >> is >> to flatten the head >> elements which may be a list or not, to flatten the tail which is a list, >> and to concatenate >> these two parts. How to make a flattening function tail-recursive? >> >> >> 2010/2/27 Dmitry Belayev >> >> >> >>> Shame on me, my own version uses f(_, f(_)) so it is not-tail recursive >>> too. >>> >>> >>> Dmitry Belayev wrote: >>> >>> >>> >>>> It would be best solution in non-strict language like haskell, but in >>>> erlang it is not tail-recursive, so it will use more memory. >>>> >>>> >>>> >>>> >>> >> >> > > From chad@REDACTED Sat Feb 27 16:16:30 2010 From: chad@REDACTED (Chad DePue) Date: Sat, 27 Feb 2010 12:16:30 -0300 Subject: COM and Erlang Message-ID: <38da08521002270716i2bef4de1hcc70e1c952609508@mail.gmail.com> Hi All, Are there resources on COM and Erlang out there; example projects, etc? Looking to interface with a few MS Exchange services and wondering if it's possible to do this with off the shelf libraries... Chad DePue skype: cdepue inakanetworks.com - Erlang consulting rubyrescue.com - Ruby on Rails consulting From erlang@REDACTED Sat Feb 27 20:48:43 2010 From: erlang@REDACTED (Joe Armstrong) Date: Sat, 27 Feb 2010 20:48:43 +0100 Subject: [erlang-questions] Re: What atom name to represent a null value In-Reply-To: <6096767b-4085-4214-85e9-e47226452766@19g2000yqu.googlegroups.com> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> <6096767b-4085-4214-85e9-e47226452766@19g2000yqu.googlegroups.com> Message-ID: <9b08084c1002271148l401dc999n1ad8a26cc0942154@mail.gmail.com> On Fri, Feb 26, 2010 at 8:40 AM, Tim Fletcher wrote: >> It is defined in somewhere? Some documentation? >> >> Or just in common sense? > > I suspect it is a practical application of the theoretical notion of > undefined in functional programming (and mathematics). For example, > here's a little function: > > ?foo(1) -> 2; > ?foo(2) -> 3; > ?foo(3) -> 1. > > This function is only defined for the values 1, 2, and 3. It is > undefined for any other value. You can use the theoretical notion of > undefined when doing certain transformations on this function and so > on. > > On a practical level, calling this function with any other value will > throw an error, which isn't always helpful. What if you wanted to pass > in any integer? In Erlang you can write this: > > ?foo(1) -> 2; > ?foo(2) -> 3; > ?foo(3) -> 1. > ?foo(_) -> undefined. No no no .... ^ 100 For three reasons. a) Think types. The type of > foo(1) -> 2; > foo(2) -> 3; > foo(3) -> 1. is int() -> int() But the type of > foo(1) -> 2; > foo(2) -> 3; > foo(3) -> 1. > foo(_) -> undefined. is int() -> int() | 'undefined' (which is a crazy type) b) foo(4) has NO VALUE. but if you say foo(4() -> undefined. Then foo(4) HAS a value (namely undefined). The best way to express this in Erlang is as follows: foo(1) -> 2; foo(2) -> 3; foo(3) -> 1; foo(X) -> exit({ebadArgToFoo, X}). This expresses the required relation that foo is oof type int() -> int() and that evaluation foo(4) is illegal and raises and exeception. The the point of exit - it was designed for *exactly* this situation. Now any good erlang programmer would not write foo like this, they would write foo(1) -> 2; foo(2) -> 3; foo(3) -> 1. And *nothing* else - since evaluating foo(4) will raise an exception and the default exception will be sufficient to identify the error. c ) There is also a worse problem. If you use the following: > foo(1) -> 2; > foo(2) -> 3; > foo(3) -> 1. > foo(_) -> undefined. Then calling foo(4) will not cause the program to crash *immediately* but somewhat later. For example, suppose you write this: f(X) -> g(X) * 7. g(X) -> h(X). h(X) -> foo(X). Now you call f(4). The program will crash in g/1, when evaluating undefined * 7, and NOT when calling foo(4). This is two functions removed from where the error occurred - and will make debugging difficult. This is why we say things like 'let it crash' - you should also 'fail early' and 'fail fast'. foo(1) -> 2; foo(2) -> 3; foo(3) -> 1. is a correct program because it crashes if you call foo(4). > foo(1) -> 2; > foo(2) -> 3; > foo(3) -> 1. > foo(_) -> undefined. Is an incorrect program because is succeeds if you call foo(4) returning undefined. > foo(1) -> 2; > foo(2) -> 3; > foo(3) -> 1. > foo(_) -> exit(badArg). Is also a correct program since it crashes (ie raises and exception) when called with foo(4). Error handling in Erlang is supposed to be "not defensive" you should only write code for the expected cases. If you want to write error recovery code enclose the entire function in a catch or try - or spawn link the process to an error handling process and 'let some other process fix the error' /Joe > > You can then call foo(4) and have it actually return a value, which > means you can then write things like foo(X) =:= 1 without it throwing > a badmatch error. > > > Sometimes you may want to distinguish between values that aren't > defined, and values that do exist but are null; in this case you can > use undefined in combination with null/nil/none/nothing, as long as > your values aren't atoms. > > If your values can be atoms then you'll probably need to use tagged > tuples, something like this: > > ?> datastore:lookup(foo). > ?undefined % key/value is not defined > > ?> datastore:lookup(bar). > ?none % key exists, value is "null" > > ?> datastore:lookup(baz). > ?{ok, undefined} % key exists, value is undefined > > The important thing is to be able to distinguish between the different > cases. > > > Hope that helps. > > Tim > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From masklinn@REDACTED Sat Feb 27 21:54:02 2010 From: masklinn@REDACTED (Masklinn) Date: Sat, 27 Feb 2010 21:54:02 +0100 Subject: [erlang-questions] Re: What atom name to represent a null value In-Reply-To: <9b08084c1002271148l401dc999n1ad8a26cc0942154@mail.gmail.com> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> <6096767b-4085-4214-85e9-e47226452766@19g2000yqu.googlegroups.com> <9b08084c1002271148l401dc999n1ad8a26cc0942154@mail.gmail.com> Message-ID: <770E7304-16C6-4978-9CC3-9E0210C0A761@masklinn.net> On 27 Feb 2010, at 20:48 , Joe Armstrong wrote: > > No no no .... ^ 100 > > For three reasons. > > a) Think types. The type of > >> foo(1) -> 2; >> foo(2) -> 3; >> foo(3) -> 1. > > is int() -> int() > > But the type of > >> foo(1) -> 2; >> foo(2) -> 3; >> foo(3) -> 1. >> foo(_) -> undefined. > > is int() -> int() | 'undefined' (which is a crazy type) > Actually, it corresponds to the very simple Haskell type (Integer -> Maybe Integer). There's nothing crazy about it if it's what is needed by the application > b) foo(4) has NO VALUE. but if you say foo(4() -> undefined. Then foo(4) > HAS a value (namely undefined). > > The best way to express this in Erlang is as follows: > > foo(1) -> 2; > foo(2) -> 3; > foo(3) -> 1; > foo(X) -> exit({ebadArgToFoo, X}). > > This expresses the required relation that foo is oof type int() -> int() > and that evaluation foo(4) is illegal and raises and exeception. > > The the point of exit - it was designed for *exactly* this situation. > Well not if Tim doesn't want his function to blow up, which was the use case he considered. > Now any good erlang programmer would not write foo like this, they would write > > foo(1) -> 2; > foo(2) -> 3; > foo(3) -> 1. > > And *nothing* else - since evaluating foo(4) will raise an exception and the > default exception will be sufficient to identify the error. > Unless, of course, you don't want an error. > c ) There is also a worse problem. If you use the following: > >> foo(1) -> 2; >> foo(2) -> 3; >> foo(3) -> 1. >> foo(_) -> undefined. > > Then calling foo(4) will not cause the program to crash *immediately* but > somewhat later. For example, suppose you write this: > Or it won't cause the program to crash at all because at some point when the result is needed it will be matched against `undefined` and a specific operation will be performed based on that knowledge. I'm on Robert's side in this case: whether or not this "pattern" should be applied depends on the application and the semantic meanings of the function call. From martinjlogan@REDACTED Sun Feb 28 02:12:52 2010 From: martinjlogan@REDACTED (Martin Logan) Date: Sat, 27 Feb 2010 19:12:52 -0600 Subject: How to create a mochiweb web application in minutes - video Message-ID: Hey all just wanted to share this. I have put together a screencast that demonstrates how using OTP packaging can help you create erlang software. In this video I demonstrate how to put together a mochiweb web application in just a few minutes starting from a box that does not even have Erlang installed on it. http://www.youtube.com/watch?v=XI7S2NwFPOE Cheers, Martin From bob@REDACTED Sun Feb 28 02:22:16 2010 From: bob@REDACTED (Bob Ippolito) Date: Sat, 27 Feb 2010 17:22:16 -0800 Subject: [erlang-questions] How to create a mochiweb web application in minutes - video In-Reply-To: References: Message-ID: <6a36e7291002271722w3f65149dj6891845bdc532624@mail.gmail.com> "This was made possible by leveraging the work to OTPify Mochiweb done at the last Chicago Erlang User Group code sprint." Can you contribute whatever code that is back upstream? Also it's pronounced like the Japanese mochi (mo-chee), for next time :) On Sat, Feb 27, 2010 at 5:12 PM, Martin Logan wrote: > Hey all just wanted to share this. I have put together a screencast that > demonstrates how using OTP packaging can help you create erlang software. In > this video I demonstrate how to put together a mochiweb web application in > just a few minutes starting from a box that does not even have Erlang > installed on it. > > http://www.youtube.com/watch?v=XI7S2NwFPOE > > > Cheers, > Martin > From rvirding@REDACTED Sun Feb 28 02:46:32 2010 From: rvirding@REDACTED (Robert Virding) Date: Sun, 28 Feb 2010 02:46:32 +0100 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <4B89208A.4010400@nm.ru> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> <4B88D9D3.4070008@nm.ru> <4B88DB08.7050702@nm.ru> <4B89208A.4010400@nm.ru> Message-ID: <3dbc6d1c1002271746j34cc6f1ay9c6bfd22f6834cf0@mail.gmail.com> Yes, somewhere you have to have a stack. Either you use the call stack or you explicitly handle your own stack, in this case with a list. In essence you are doing the same when you push the output onto the front of a list which you reverse at the end, you are handling your own stack. Robert 2010/2/27 Dmitry Belayev : > It's kind of "handmade" stack. > > ??? (Yau-Hsien Huang) wrote: >> >> The basic concept of flattening a list, similar to process a binary tree, >> is >> to flatten the head >> elements which may be a list or not, to flatten the tail which is a list, >> and to concatenate >> these two parts. How to make a flattening function tail-recursive? >> >> >> 2010/2/27 Dmitry Belayev >> >> >>> >>> Shame on me, my own version uses f(_, f(_)) so it is not-tail recursive >>> too. >>> >>> >>> Dmitry Belayev wrote: >>> >>> >>>> >>>> It would be best solution in non-strict language like haskell, but in >>>> erlang it is not tail-recursive, so it will use more memory. >>>> >>>> >>>> >> >> > > > ________________________________________________________________ > erlang-questions (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED > > From bgustavsson@REDACTED Sun Feb 28 08:36:54 2010 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Sun, 28 Feb 2010 08:36:54 +0100 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <3dbc6d1c1002271746j34cc6f1ay9c6bfd22f6834cf0@mail.gmail.com> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> <4B87EDC4.9060404@nm.ru> <3dbc6d1c1002260800g60d1ae48v7275d7df64fedea@mail.gmail.com> <4B87F54C.2060208@nm.ru> <3dbc6d1c1002261431kccc1dfet1d61dd3d7f3670cd@mail.gmail.com> <4B88D9D3.4070008@nm.ru> <4B88DB08.7050702@nm.ru> <4B89208A.4010400@nm.ru> <3dbc6d1c1002271746j34cc6f1ay9c6bfd22f6834cf0@mail.gmail.com> Message-ID: <6672d0161002272336v5582eb4epcf31091e2fa445f3@mail.gmail.com> 2010/2/28 Robert Virding : > Yes, somewhere you have to have a stack. Either you use the call stack > or you explicitly handle your own stack, in this case with a list. In > essence you are doing the same when you push the output onto the front > of a list which you reverse at the end, you are handling your own > stack. Using the call stack (i.e. doing recursive calls) used to be much slower in older versions of Erlang/OTP. Since R12B the difference is smaller, and body-recursive calls can even be faster than tail-recursive calls. If you really need to have the fastest possible program, you will need to implement both a body-recursive and tail-recursive version and measure. If speed is not that important, I would recommend going for the clearest and most readable implementation. See the Efficiency Guide (2.3 Myth: Tail-recursive functions are MUCH faster than recursive functions) for more details: http://www.erlang.org/doc/efficiency_guide/myths.html#id2251841 -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From erlang@REDACTED Sun Feb 28 13:43:27 2010 From: erlang@REDACTED (Joe Armstrong) Date: Sun, 28 Feb 2010 13:43:27 +0100 Subject: [erlang-questions] Re: What atom name to represent a null value In-Reply-To: <770E7304-16C6-4978-9CC3-9E0210C0A761@masklinn.net> References: <6a9ba5691002251613m23fc1060t201aa59634e980f8@mail.gmail.com> <1267143285.3672.18.camel@isengaard> <6a9ba5691002251620u560186b7xaad1447356daa1a9@mail.gmail.com> <8C7ED794-A531-4D4D-BC73-9E61F6E963D4@souja.net> <6a9ba5691002251633p6a12de87uf8a973d87afa7590@mail.gmail.com> <6096767b-4085-4214-85e9-e47226452766@19g2000yqu.googlegroups.com> <9b08084c1002271148l401dc999n1ad8a26cc0942154@mail.gmail.com> <770E7304-16C6-4978-9CC3-9E0210C0A761@masklinn.net> Message-ID: <9b08084c1002280443k7bffebn6047ee735b66e0e7@mail.gmail.com> On Sat, Feb 27, 2010 at 9:54 PM, Masklinn wrote: > On 27 Feb 2010, at 20:48 , Joe Armstrong wrote: >> >> No no no .... ^ 100 >> >> For three reasons. >> >> a) Think types. The type of >> >>> foo(1) -> 2; >>> foo(2) -> 3; >>> foo(3) -> 1. >> >> is ? int() -> int() >> >> But the type of >> >>> foo(1) -> 2; >>> foo(2) -> 3; >>> foo(3) -> 1. >>> foo(_) -> undefined. >> >> is int() -> int() | 'undefined' ?(which is a crazy type) >> > Actually, it corresponds to the very simple Haskell type > (Integer -> Maybe Integer). There's nothing crazy about it if it's what > is needed by the application Right - unfortunately most code like this follows from a fundamental misunderstanding of how error handling works in Erlang. Code with large numbers of functions returning Maybe types is usually a sign of bad design - I usually limit myself to one top-level catch and let everything else generate exceptions. It's also going to be difficult to give an accurate name to foo - ie it's more difficult to name a 'thing-that-returns-an-integer-or-undefined' than just 'thing-that-returns-an-integer' I'm not saying that you shouldn't have Maybe types - but that often they are a sign of bad design, or worse, a misunderstanding of the error handling mechanisms. /Joe > >> b) foo(4) has NO VALUE. but if you say foo(4() -> undefined. Then foo(4) >> HAS a value (namely undefined). >> >> The best way to express this in Erlang is as follows: >> >> foo(1) -> 2; >> foo(2) -> 3; >> foo(3) -> 1; >> foo(X) -> exit({ebadArgToFoo, X}). >> >> This expresses the required relation that foo is oof type int() ?-> int() >> and that evaluation foo(4) is illegal and raises and exeception. >> >> The the point of exit - it was designed for *exactly* this situation. >> > Well not if Tim doesn't want his function to blow up, which was the use case he > considered. > >> Now any good erlang programmer would not write foo like this, they would write >> >> foo(1) -> 2; >> foo(2) -> 3; >> foo(3) -> 1. >> >> And *nothing* else - since evaluating foo(4) will raise an exception and the >> default exception will be sufficient to identify the error. >> > Unless, of course, you don't want an error. > >> c ) There is also a worse problem. If you use the following: >> >>> foo(1) -> 2; >>> foo(2) -> 3; >>> foo(3) -> 1. >>> foo(_) -> undefined. >> >> Then calling foo(4) will not cause the program to crash *immediately* but >> somewhat later. For example, suppose you write this: >> > Or it won't cause the program to crash at all because at some point when > the result is needed it will be matched against `undefined` and a specific > operation will be performed based on that knowledge. > > I'm on Robert's side in this case: whether or not this "pattern" should be > applied depends on the application and the semantic meanings of the function > call. From lucevers@REDACTED Sun Feb 28 17:45:49 2010 From: lucevers@REDACTED (Luc Evers) Date: Sun, 28 Feb 2010 17:45:49 +0100 Subject: Opening Named Pipe for syslog analyser Message-ID: To investigate syslog router messages, I'm using a Linux operating system with syslog-ng. The syslog-ng deamon sends the messages to a name pipe. I like to make a syslog analyzer to investigate and correlate the information coming from different devices. Until now I didn't found an answer on reading from named pipes with the Erlang language. Is there no solution for this problem? Thanks! Luc. From ms@REDACTED Sun Feb 28 18:29:17 2010 From: ms@REDACTED (Martin Scholl) Date: Sun, 28 Feb 2010 18:29:17 +0100 Subject: [erlang-questions] Opening Named Pipe for syslog analyser In-Reply-To: References: Message-ID: <4B8AA7ED.8090707@diskware.net> Hello Luc, this questions pops up from time to time. Erlang's file driver doesn't allow opening non-regular files like named pipes. As a workaround, open_port/2 to open start a command "cat ". This is not equivalent to opening the file with erlang's file driver, but should work for you. Martin Luc Evers wrote: > To investigate syslog router messages, I'm using a Linux operating system > with syslog-ng. > The syslog-ng deamon sends the messages to a name pipe. > I like to make a syslog analyzer to investigate and correlate the > information coming from different devices. > > > Until now I didn't found an answer on reading from named pipes with the > Erlang language. > Is there no solution for this problem? > > > > Thanks! > > Luc. > From ok@REDACTED Sun Feb 28 22:50:54 2010 From: ok@REDACTED (Richard O'Keefe) Date: Mon, 1 Mar 2010 10:50:54 +1300 Subject: [erlang-questions] how: Another library flatten function? In-Reply-To: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> References: <1267192712.4783.27.camel@seasc1137.dyn.rnd.as.sw.ericsson.se> Message-ID: <0A607346-5622-4D6F-98F2-3A97E98E5247@cs.otago.ac.nz> On Feb 27, 2010, at 2:58 AM, Bengt Kleberg wrote: > Greetings, > > I have the following list: ["asd",[["Flow","kalle"]],["Sub","F"]] > I would like to flatten it to: ["asd","Flow","kalle","Sub","F"] > lists:flatten/1 is too effective. It gives me: "asdFlowkalleSubF" > > Is there another flatten somewhere? The general form of flatten is going to be flatten(X) -> flatten_loop(X, []). flatten_loop(X, L) when base_case(X) -> [X|L]; flatten_loop([], L) -> L; flatten_loop([H|T], L) -> flatten_loop(H, flatten_loop(T, L)). where the first clause of flatten_loop/2 isn't legal Erlang. The question of interest is "what exactly is the base case"? If all the strings are non-empty, it's not hard: flatten_string_list(X) -> flatten_string_list_loop(X, []). flatten_string_list_loop(X = [H|_], L) when is_integer(H) -> [X|L]; flatten_string_list_loop(X, L) when is_binary(X) -> [X|L]; flatten_string_list_loop([H|T], L) -> flatten_string_list_loop(H, flatten_string_list_loop(T, L)); flatten_string_list_loop([], L) -> L. and we let anything else crash. Allowing empty strings would make the code rather trickier to develop, although not impossible. I think before looking for another flatten, the task is to specify what you actually want.