From ludovic@REDACTED Sat Mar 1 00:00:52 2014 From: ludovic@REDACTED (Ludovic Demblans) Date: Sat, 01 Mar 2014 00:00:52 +0100 Subject: [erlang-questions] ETS ordering In-Reply-To: References: Message-ID: Hi, So I feel reassured, thank you. I know (a bit) mnesia but I don't need much functionality and I may want have a table per each sell point, I don't want to deal with different record-name/table-name in mnesia at the moment. I can go to mnesia quickly anyway because I use it already on the same project. But I looked a bit and I've found messages on this list stating that the best thing to do is to fetch all the matching records in a list and then sorting it. In LYSE (mafiapp) Fred fetchs records into a dict and then work on this dict. So, what functionalities of mnesia could help dealing with ordering ? I've found some ordering related stuff in the docs for the qlc module but as you may have noticed, english read/write could be hard somehow. Anyway ETS should be enough to implement a simple prototype. Thanks again ! -- lud Le Fri, 28 Feb 2014 18:03:22 +0100, Jesper Louis Andersen a ?crit: > On Fri, Feb 28, 2014 at 5:55 PM, lud wrote: > >> {{ItemTypeID,Price,OrderID},Quantity,BuyerID} >> > > This is a common trick which can often be used to satisfy these kinds of > things. I use it quite often. > > However, given your situation, you may want to take the plunge and move > the > whole thing to mnesia. It gives you a lot of added power which you can > avoid reimplementing yourself. Even if you don't need that extra power > now, > you need to figure out if it is necessary later. > > > -- Utilisant le logiciel de courrier r?volutionnaire d'Opera : http://www.opera.com/mail/ From steven.charles.davis@REDACTED Sat Mar 1 01:40:56 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 28 Feb 2014 16:40:56 -0800 (PST) Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: References: Message-ID: <78219c1a-123a-4f15-bd0f-18dae1a60c77@googlegroups.com> http://lmgtfy.com On Friday, February 28, 2014 7:12:16 AM UTC-6, David Welton wrote: > > Looks like there is, according to Fred's message. Let's see if that > can be tracked down. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris_prieb@REDACTED Sat Mar 1 00:12:49 2014 From: kris_prieb@REDACTED (Kris Prieb) Date: Fri, 28 Feb 2014 17:12:49 -0600 Subject: [erlang-questions] unable to build valgrind-enabled erlang runtime Message-ID: Hello List, I am attempting to build a valgrind-enabled erlang runtime per: http://www.erlang.org/doc/installation_guide/INSTALL.html#id72660 My platform is an amazon linux machine image on ec2 on which I have already installed an erlang disribution from source. I entered the following at the command prompt: [ec2-user@REDACTED emulator]$ env ERL_TOP=/home/ec2-user/otp_src_R16B02 FLAVOR=smp make valgrind FLAVOR=$FLAVOR The following was returned: make -f x86_64-unknown-linux-gnu/Makefile TYPE=valgrind can't open x86_64-unknown-linux-gnu/valgrind/plain/erl_compile_flags.h for writing at utils/make_compiler_flags line 65. make[1]: Entering directory `/home/ec2-user/otp_src_R16B02/erts/emulator' if utils/gen_git_version x86_64-unknown-linux-gnu/gen_git_version.mk; then touch beam/erl_bif_info.c; fi *** valgrind emulator disabled by configure - omitted target all make[1]: Leaving directory `/home/ec2-user/otp_src_R16B02/erts/emulator' What have I done wrong here? Do I have to run "configure" with special arguments before building valgrind-enabled runtime? Any help would be much appreciated! Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Sat Mar 1 08:09:31 2014 From: txrev319@REDACTED (t x) Date: Fri, 28 Feb 2014 23:09:31 -0800 Subject: [erlang-questions] https://github.com/joearms/ezwebframe Message-ID: Hi, I'm having some trouble trying to get https://github.com/joearms/ezwebframe to work. ### In particular, on the server (Ubuntu 13), I get: x@REDACTED:~/ezwebframe$ make rebar compile ==> Entering directory `/home/x/ezwebframe/deps/cowboy' ==> Entering directory `/home/x/ezwebframe/deps/cowlib' ==> cowlib (compile) ==> Leaving directory `/home/x/ezwebframe/deps/cowlib' ==> Entering directory `/home/x/ezwebframe/deps/ranch' ==> ranch (compile) ==> Leaving directory `/home/x/ezwebframe/deps/ranch' ==> cowboy (compile) ==> Leaving directory `/home/x/ezwebframe/deps/cowboy' ==> ezwebframe (compile) cd demos; make make[1]: Entering directory `/home/x/ezwebframe/demos' erlc -o ebin *.erl */*.erl svg/svg_pad4.erl:63: Warning: variable 'Y' is unused svg/svg_pad4.erl:204: Warning: variable 'L1' is unused svg/svg_pad4.erl:218: Warning: variable 'Id' is unused erl -pa ../deps/cowboy/ebin\ -pa ../deps/ranch/ebin\ -pa ../deps/cowlib/ebin\ -pa ../ebin\ -pa ./ebin\ -s ezwebframe_demos start Erlang R16B01 (erts-5.10.2) [source] [64-bit] [async-threads:10] [kernel-poll:false] a simple_demo of websockets.... Load the page http://localhost:1456/ in your browser Starting:{ok,"/home/x/ezwebframe/demos"} Eshell V5.10.2 (abort with ^G) 1> websockets started on port:1456 init: ezwebframe:handle "/" ezwebframe_demos::dispatch / => /home/x/ezwebframe/demos/ mapped to:"/home/x/ezwebframe/demos/" init: ezwebframe:handle "/files" ezwebframe_demos::dispatch /files => /home/x/ezwebframe/demos/files mapped to:"/home/x/ezwebframe/demos/files" ezwebframe_demos::dispatch / => /home/x/ezwebframe/demos/ init: ezwebframe:handle "/clocks/clock1.html" ezwebframe_demos::dispatch /clocks/clock1.html => /home/x/ezwebframe/demos/clocks/clock1.html mapped to:"/home/x/ezwebframe/demos/clocks/clock1.html" init: init: ezwebframe:handle "/ezwebframe/websock.js" ezwebframe:handle "/common/jquery-1.7.1.min.js" init: ezwebframe_demos::dispatch /ezwebframe/websock.js => /home/x/ezwebframe/demos/../priv/websock.js ezwebframe_demos::dispatch /common/jquery-1.7.1.min.js => /home/x/ezwebframe/demos/common/jquery-1.7.1.min.js ezwebframe:handle "/clocks/clock1.css" mapped to:"/home/x/ezwebframe/demos/../priv/websock.js" mapped to:"/home/x/ezwebframe/demos/common/jquery-1.7.1.min.js" ezwebframe_demos::dispatch /clocks/clock1.css => /home/x/ezwebframe/demos/clocks/clock1.css mapped to:"/home/x/ezwebframe/demos/clocks/clock1.css" ### On the client, when I load up the page with "Chrome 33.0.1750.117", I get: "Socket closed -- your erlang probably crashed." ### Questions: What should I try? Thanks! From davidnwelton@REDACTED Sat Mar 1 12:27:02 2014 From: davidnwelton@REDACTED (David Welton) Date: Sat, 1 Mar 2014 12:27:02 +0100 Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: <3D76B21C-242A-436E-9002-D16FA34C7DC4@gmail.com> References: <3D76B21C-242A-436E-9002-D16FA34C7DC4@gmail.com> Message-ID: We are not interested at all in running Erlang on the tablet, so having epmd or anything else is just overhead. The answer as far as our code is concerned, is to create a really simple, small, incomplete epmd in Java: http://www.erlang.org/doc/apps/erts/erl_dist_protocol.html It accepts PORT_PLEASE2_REQ (122) and responds with PORT2_RESP which always points at the same TCP port because we already selected the port to listen on. We'll see if we can get everything working on Monday. This is a lot simpler than trying to package up and include epmd! We only want to have the one node for the time being. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From davidnwelton@REDACTED Sat Mar 1 12:30:44 2014 From: davidnwelton@REDACTED (David Welton) Date: Sat, 1 Mar 2014 12:30:44 +0100 Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: <78219c1a-123a-4f15-bd0f-18dae1a60c77@googlegroups.com> References: <78219c1a-123a-4f15-bd0f-18dae1a60c77@googlegroups.com> Message-ID: Hi Steve, Actually Google was no use, as he had not released his code. Didn't you see my message, and Maxim's prompt, *friendly* reply? http://erlang.org/pipermail/erlang-questions/2014-February/077967.html On Sat, Mar 1, 2014 at 1:40 AM, Steve Davis wrote: > http://lmgtfy.com > > On Friday, February 28, 2014 7:12:16 AM UTC-6, David Welton wrote: >> >> Looks like there is, according to Fred's message. Let's see if that >> can be tracked down. -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From essen@REDACTED Sat Mar 1 12:32:55 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 01 Mar 2014 12:32:55 +0100 Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: References: <78219c1a-123a-4f15-bd0f-18dae1a60c77@googlegroups.com> Message-ID: <5311C567.4020905@ninenines.eu> Plus with the terrible results that Google tends to return these days, that joke has become greatly overrated. Need a good search engine. :-) On 03/01/2014 12:30 PM, David Welton wrote: > Hi Steve, > > Actually Google was no use, as he had not released his code. Didn't > you see my message, and Maxim's prompt, *friendly* reply? > > http://erlang.org/pipermail/erlang-questions/2014-February/077967.html > > > On Sat, Mar 1, 2014 at 1:40 AM, Steve Davis > wrote: >> http://lmgtfy.com >> >> On Friday, February 28, 2014 7:12:16 AM UTC-6, David Welton wrote: >>> >>> Looks like there is, according to Fred's message. Let's see if that >>> can be tracked down. > > > -- Lo?c Hoguin http://ninenines.eu From steven.charles.davis@REDACTED Sat Mar 1 12:41:01 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sat, 1 Mar 2014 05:41:01 -0600 Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: References: <78219c1a-123a-4f15-bd0f-18dae1a60c77@googlegroups.com> Message-ID: Hi David, Well, I guess it was a bit of a snarky joke, but the very first hit for my search: "epmd written in erlang" on google was: http://erlang.org/pipermail/erlang-questions/2012-November/070488.html ...which references: https://github.com/lemenkov/erlpmd It may not be exactly what you want but I believe it was what Fred was referring to. "Was that so hard?" ;-) /s On Mar 1, 2014, at 5:30 AM, David Welton wrote: > Hi Steve, > > Actually Google was no use, as he had not released his code. Didn't > you see my message, and Maxim's prompt, *friendly* reply? > > http://erlang.org/pipermail/erlang-questions/2014-February/077967.html > > > On Sat, Mar 1, 2014 at 1:40 AM, Steve Davis > wrote: >> http://lmgtfy.com >> >> On Friday, February 28, 2014 7:12:16 AM UTC-6, David Welton wrote: >>> >>> Looks like there is, according to Fred's message. Let's see if that >>> can be tracked down. > > > > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ From serge@REDACTED Sat Mar 1 13:11:06 2014 From: serge@REDACTED (Serge Aleynikov) Date: Sat, 1 Mar 2014 07:11:06 -0500 Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: References: Message-ID: As some point I was facing a similar issue when I was implementing a .NET library similar to JInterface ( http://blog.aumcode.com/2013/10/nfx-native-interoperability-of-net-with.html ). I ended up making epmd registration optional (perhaps a similar patch is needed for JInterface), as not every OTP client Java node may need to start a listener for incoming connections, and that registration is unnecessary. On Fri, Feb 28, 2014 at 7:36 AM, David Welton wrote: > Hi, > > I'm wondering if anyone has any ideas regarding a problem we are facing. > > It appears that Erlang's JInterface requires the local machine to have > an epmd daemon running, which, for an Android system, is neither > pleasant nor clean: > > http://www.isotope11.com/blog/android-and-erlang-interop-with-jinterface > > Are there any other workarounds? Say, implementing just enough of > epmd to route what needs routing to the one local node? > > Thank you > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francesco@REDACTED Sat Mar 1 20:26:21 2014 From: francesco@REDACTED (Francesco Cesarini) Date: Sat, 01 Mar 2014 11:26:21 -0800 Subject: [erlang-questions] CS Lab's 30th Anniversary! Message-ID: <5312345D.3040406@erlang-solutions.com> Hi All, I thought I would share this email Bjarne Dacker, co-founder and former head of the computer science lab sent out today. 30 years ago on this day, the CS lab was founded. Happy birthday!!! /F Bjarne D?cker wrote: Hello On 1 March 1984 *CSLab* (/Computer Science Laboratory/) was formally established as an organizational unit at Ericsson Telecom. Activities had already been going on since 1981. On 1 May 1988 *CSLab* was moved to Ellemtel which became Ericsson after some years. On 30 June 2002 *CSLab *was closed down. *CSLab *existed for ~18 years with ~12 people so Ericsson invested >200 person-years on an idea that was originally presented to G?sta Lindberg CTO of Ericsson by four enthusiastic software freaks. Fortunately *Erlang*, the most important invention at *CSLab*, managed to sneak out and conquer the world. On the personal side there have become some doctors, a couple of professors and a few millionaires. Tonight have a beer or a glass of wine or a bottle of Loranga or a whisky and say /cheers/ to the happy memories of *CSLab* which saw the light 30 years ago. /Bjarne/ // http://www.cs-lab.org/ -- Erlang Solutions Ltd. http://www.erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Sat Mar 1 22:25:59 2014 From: davidnwelton@REDACTED (David Welton) Date: Sat, 1 Mar 2014 22:25:59 +0100 Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: References: <78219c1a-123a-4f15-bd0f-18dae1a60c77@googlegroups.com> Message-ID: Hi, The problem is that I am looking for something in Java. I guess I could have spelled that out in more detail, but I thought it was fairly evident from discussing JInterface and Android - which is a "Java" (well, Dalvik, but... yeah, not Erlang) system, that that is what I needed. We don't run, nor want to run Erlang on the Android system at this point in time. On Sat, Mar 1, 2014 at 12:41 PM, Steve Davis wrote: > Hi David, > > Well, I guess it was a bit of a snarky joke, but the very first hit for my search: "epmd written in erlang" on google was: > > http://erlang.org/pipermail/erlang-questions/2012-November/070488.html > > ...which references: > > https://github.com/lemenkov/erlpmd > > It may not be exactly what you want but I believe it was what Fred was referring to. > > "Was that so hard?" ;-) > > /s > > > > On Mar 1, 2014, at 5:30 AM, David Welton wrote: > >> Hi Steve, >> >> Actually Google was no use, as he had not released his code. Didn't >> you see my message, and Maxim's prompt, *friendly* reply? >> >> http://erlang.org/pipermail/erlang-questions/2014-February/077967.html >> >> >> On Sat, Mar 1, 2014 at 1:40 AM, Steve Davis >> wrote: >>> http://lmgtfy.com >>> >>> On Friday, February 28, 2014 7:12:16 AM UTC-6, David Welton wrote: >>>> >>>> Looks like there is, according to Fred's message. Let's see if that >>>> can be tracked down. >> >> >> >> -- >> David N. Welton >> >> http://www.welton.it/davidw/ >> >> http://www.dedasys.com/ > -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From jesper.louis.andersen@REDACTED Sat Mar 1 23:44:17 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sat, 1 Mar 2014 23:44:17 +0100 Subject: [erlang-questions] ETS ordering In-Reply-To: References: Message-ID: On Fri, Feb 28, 2014 at 11:48 PM, Ludovic Demblans wrote: > But I looked a bit and I've found messages on this list stating that the > best thing to do is to fetch all the matching records in a list and then > sorting it. If the number of records happen to be fairly low, this is good approach. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Sun Mar 2 00:36:20 2014 From: txrev319@REDACTED (t x) Date: Sat, 1 Mar 2014 15:36:20 -0800 Subject: [erlang-questions] hot code reloading Message-ID: Hi, I'm reading Chapter 8 of Programming Erlang, and I want to verify if my mental model of erlang code reloading is correct. My erlang is a bit weak, so I'm going to use C++ notation. https://gist.github.com/anonymous/9299344 Is the above correct with respect to *compile* and *lookup* ? It seems to me the defining characteristics of erlang's code hot reloading is: * we have an "old" and a "new" * the new becomes the old, and we kill all processes spawned by the old Suppose we have * module foo, module bar; * foo:hi(), refers to bar:hello(); * we recompile bar; now, all foo's references to bar, uses the _latest_ bar, not the bar that existed when foo was compiled If I have misunderstood anything, please correct me. Thanks! From bob@REDACTED Sun Mar 2 09:10:43 2014 From: bob@REDACTED (Bob Ippolito) Date: Sun, 2 Mar 2014 00:10:43 -0800 Subject: [erlang-questions] hot code reloading In-Reply-To: References: Message-ID: The remote call bar:hello() will always call the newest version of bar:hello/0. The calling module is irrelevant, even if the call happens from the old version of bar the newest version will always be called using that syntax. A local call from bar to hello() (or an equivalent closure) would use the current version referenced by that process. Modules are not linked together in any way so how or when they were compiled is not so relevant. On Saturday, March 1, 2014, t x wrote: > Hi, > > I'm reading Chapter 8 of Programming Erlang, and I want to verify if > my mental model of erlang code reloading is correct. My erlang is a > bit weak, so I'm going to use C++ notation. > > https://gist.github.com/anonymous/9299344 > > Is the above correct with respect to *compile* and *lookup* ? > > It seems to me the defining characteristics of erlang's code hot > reloading is: > > * we have an "old" and a "new" > * the new becomes the old, and we kill all processes spawned by the old > > Suppose we have > > * module foo, module bar; > * foo:hi(), refers to bar:hello(); > > * we recompile bar; now, all foo's references to bar, uses the > _latest_ bar, not the bar that existed when foo was compiled > > If I have misunderstood anything, please correct me. > > Thanks! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianfranco.alongi@REDACTED Sun Mar 2 10:31:22 2014 From: gianfranco.alongi@REDACTED (Gianfranco Alongi) Date: Sun, 2 Mar 2014 10:31:22 +0100 Subject: [erlang-questions] hot code reloading In-Reply-To: References: Message-ID: I actually recommend the documentation, it covers this in a few paragraphs http://www.erlang.org/doc/reference_manual/code_loading.html#id84603 On Sun, Mar 2, 2014 at 9:10 AM, Bob Ippolito wrote: > The remote call bar:hello() will always call the newest version of > bar:hello/0. The calling module is irrelevant, even if the call happens > from the old version of bar the newest version will always be called using > that syntax. A local call from bar to hello() (or an equivalent > closure) would use the current version referenced by that process. > > Modules are not linked together in any way so how or when they were > compiled is not so relevant. > > > On Saturday, March 1, 2014, t x wrote: > >> Hi, >> >> I'm reading Chapter 8 of Programming Erlang, and I want to verify if >> my mental model of erlang code reloading is correct. My erlang is a >> bit weak, so I'm going to use C++ notation. >> >> https://gist.github.com/anonymous/9299344 >> >> Is the above correct with respect to *compile* and *lookup* ? >> >> It seems to me the defining characteristics of erlang's code hot >> reloading is: >> >> * we have an "old" and a "new" >> * the new becomes the old, and we kill all processes spawned by the old >> >> Suppose we have >> >> * module foo, module bar; >> * foo:hi(), refers to bar:hello(); >> >> * we recompile bar; now, all foo's references to bar, uses the >> _latest_ bar, not the bar that existed when foo was compiled >> >> If I have misunderstood anything, please correct me. >> >> Thanks! >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Sun Mar 2 09:40:09 2014 From: txrev319@REDACTED (t x) Date: Sun, 2 Mar 2014 00:40:09 -0800 Subject: [erlang-questions] hot code reloading In-Reply-To: References: Message-ID: Hi Bob, Thanks for the clarification. I ran a simple test: %% begin code -module(hot). -compile(export_all). sleep() -> receive after 3000 -> true end. local_call() -> local_call. remote_call() -> remote_call. loop() -> sleep(), io:format("local_call: ~p~n", [local_call()]), io:format("remote_call: ~p~n", [hot:remote_call()]), loop(). %% end code updating local_call/remote_call to local_call_updated / remote_call_updated . And you're absolute right, the hot:remote_call() line called the new function. Thanks for the clarification! On Sun, Mar 2, 2014 at 12:10 AM, Bob Ippolito wrote: > The remote call bar:hello() will always call the newest version of > bar:hello/0. The calling module is irrelevant, even if the call happens from > the old version of bar the newest version will always be called using that > syntax. A local call from bar to hello() (or an equivalent closure) would > use the current version referenced by that process. > > Modules are not linked together in any way so how or when they were compiled > is not so relevant. > > On Saturday, March 1, 2014, t x wrote: >> >> Hi, >> >> I'm reading Chapter 8 of Programming Erlang, and I want to verify if >> my mental model of erlang code reloading is correct. My erlang is a >> bit weak, so I'm going to use C++ notation. >> >> https://gist.github.com/anonymous/9299344 >> >> Is the above correct with respect to *compile* and *lookup* ? >> >> It seems to me the defining characteristics of erlang's code hot >> reloading is: >> >> * we have an "old" and a "new" >> * the new becomes the old, and we kill all processes spawned by the old >> >> Suppose we have >> >> * module foo, module bar; >> * foo:hi(), refers to bar:hello(); >> >> * we recompile bar; now, all foo's references to bar, uses the >> _latest_ bar, not the bar that existed when foo was compiled >> >> If I have misunderstood anything, please correct me. >> >> Thanks! >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From rickard@REDACTED Sun Mar 2 12:54:21 2014 From: rickard@REDACTED (Rickard Green) Date: Sun, 2 Mar 2014 12:54:21 +0100 Subject: [erlang-questions] system_info in R17.0-rc02 In-Reply-To: References: Message-ID: http://erlang.org/pipermail/erlang-questions/2014-February/077675.html The otp_correction_package in the type-spec in erlang.erl is a leftover and will be removed in 17.0. Regards, Rickard Green, Erlang/OTP, Ericsson AB fredagen den 28:e februari 2014 skrev : > I can get erlang:system_info(otp_release) to give "17", but > erlang:system_info(otp_correction_package) seems to balk. > I remember there was mention on the list that otp_correction_package may > get changed to otp_version, but that doesn't work either. > The erlang.erl source file still has otp_release and > otp_correction_package as the possible parameters in the specification of > the system_info function. > Am I doing something wrong? > Thanks and best regards > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianfranco.alongi@REDACTED Sun Mar 2 12:54:24 2014 From: gianfranco.alongi@REDACTED (Gianfranco Alongi) Date: Sun, 2 Mar 2014 12:54:24 +0100 Subject: [erlang-questions] hot code reloading In-Reply-To: References: Message-ID: If you are alone, this will always be your friend, no matter of time or country http://www.developerduck.com/ On Sun, Mar 2, 2014 at 12:28 PM, t x wrote: > -module(m). > -export([loop/0]). > > loop() -> > receive > code_switch -> > m:loop(); > Msg -> > ... > loop() > end. > > This is #$%-ing brilliant! > > At first, I thought: > > "this is a stupid way to demonstrate global-loop vs local-loop" > > > However, this does much more than that. > > It means that > > * when an existing loop is running > * after we do a hot reload > * after the code processes an old message > * it then calls the _new_ loop > > > Yeah, preaching to the choir, but this is awesome, and I have no one > else to share this intellectual excitement with. :-) > > > > On Sun, Mar 2, 2014 at 1:31 AM, Gianfranco Alongi > wrote: > > I actually recommend the documentation, it covers this in a few > paragraphs > > http://www.erlang.org/doc/reference_manual/code_loading.html#id84603 > > > > > > > > On Sun, Mar 2, 2014 at 9:10 AM, Bob Ippolito wrote: > >> > >> The remote call bar:hello() will always call the newest version of > >> bar:hello/0. The calling module is irrelevant, even if the call happens > from > >> the old version of bar the newest version will always be called using > that > >> syntax. A local call from bar to hello() (or an equivalent closure) > would > >> use the current version referenced by that process. > >> > >> Modules are not linked together in any way so how or when they were > >> compiled is not so relevant. > >> > >> > >> On Saturday, March 1, 2014, t x wrote: > >>> > >>> Hi, > >>> > >>> I'm reading Chapter 8 of Programming Erlang, and I want to verify if > >>> my mental model of erlang code reloading is correct. My erlang is a > >>> bit weak, so I'm going to use C++ notation. > >>> > >>> https://gist.github.com/anonymous/9299344 > >>> > >>> Is the above correct with respect to *compile* and *lookup* ? > >>> > >>> It seems to me the defining characteristics of erlang's code hot > >>> reloading is: > >>> > >>> * we have an "old" and a "new" > >>> * the new becomes the old, and we kill all processes spawned by the > old > >>> > >>> Suppose we have > >>> > >>> * module foo, module bar; > >>> * foo:hi(), refers to bar:hello(); > >>> > >>> * we recompile bar; now, all foo's references to bar, uses the > >>> _latest_ bar, not the bar that existed when foo was compiled > >>> > >>> If I have misunderstood anything, please correct me. > >>> > >>> Thanks! > >>> _______________________________________________ > >>> erlang-questions mailing list > >>> erlang-questions@REDACTED > >>> http://erlang.org/mailman/listinfo/erlang-questions > >> > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Sun Mar 2 12:28:25 2014 From: txrev319@REDACTED (t x) Date: Sun, 2 Mar 2014 03:28:25 -0800 Subject: [erlang-questions] hot code reloading In-Reply-To: References: Message-ID: -module(m). -export([loop/0]). loop() -> receive code_switch -> m:loop(); Msg -> ... loop() end. This is #$%-ing brilliant! At first, I thought: "this is a stupid way to demonstrate global-loop vs local-loop" However, this does much more than that. It means that * when an existing loop is running * after we do a hot reload * after the code processes an old message * it then calls the _new_ loop Yeah, preaching to the choir, but this is awesome, and I have no one else to share this intellectual excitement with. :-) On Sun, Mar 2, 2014 at 1:31 AM, Gianfranco Alongi wrote: > I actually recommend the documentation, it covers this in a few paragraphs > http://www.erlang.org/doc/reference_manual/code_loading.html#id84603 > > > > On Sun, Mar 2, 2014 at 9:10 AM, Bob Ippolito wrote: >> >> The remote call bar:hello() will always call the newest version of >> bar:hello/0. The calling module is irrelevant, even if the call happens from >> the old version of bar the newest version will always be called using that >> syntax. A local call from bar to hello() (or an equivalent closure) would >> use the current version referenced by that process. >> >> Modules are not linked together in any way so how or when they were >> compiled is not so relevant. >> >> >> On Saturday, March 1, 2014, t x wrote: >>> >>> Hi, >>> >>> I'm reading Chapter 8 of Programming Erlang, and I want to verify if >>> my mental model of erlang code reloading is correct. My erlang is a >>> bit weak, so I'm going to use C++ notation. >>> >>> https://gist.github.com/anonymous/9299344 >>> >>> Is the above correct with respect to *compile* and *lookup* ? >>> >>> It seems to me the defining characteristics of erlang's code hot >>> reloading is: >>> >>> * we have an "old" and a "new" >>> * the new becomes the old, and we kill all processes spawned by the old >>> >>> Suppose we have >>> >>> * module foo, module bar; >>> * foo:hi(), refers to bar:hello(); >>> >>> * we recompile bar; now, all foo's references to bar, uses the >>> _latest_ bar, not the bar that existed when foo was compiled >>> >>> If I have misunderstood anything, please correct me. >>> >>> Thanks! >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > From txrev319@REDACTED Sun Mar 2 12:32:05 2014 From: txrev319@REDACTED (t x) Date: Sun, 2 Mar 2014 03:32:05 -0800 Subject: [erlang-questions] erlang / laziness Message-ID: Hi, I'm from a clojure background, where many things are lazy by default, including fundamental constructs, like map. (def x (map func lst)) ;; func is not called on lst yet This has been a source of annoying bugs. In erlang, can I assume that _nothing_ is lazy? i.e. some-expression, [ func(X) || X <- Lst], some-other-expression now, the "value" of the list-comprehension expression is not used anywhere (and in a Lazy language like Clojure would not be evaluated at all). However, in Erlang, it's _always_ executed, as nothing is lazy by default. Is this assumption correct? Thanks! From sergej.jurecko@REDACTED Sun Mar 2 14:20:36 2014 From: sergej.jurecko@REDACTED (Sergej Jurecko) Date: Sun, 2 Mar 2014 14:20:36 +0100 Subject: [erlang-questions] erlang / laziness In-Reply-To: References: Message-ID: <01DF0966-ABB0-41A0-8EFB-209C2BF0A844@gmail.com> andalso will evaluate second expression only if first is true orelse will evaluate second expression only if first is false Nothing else is lazy from what I know. Sergej On Mar 2, 2014, at 12:32 PM, t x wrote: > Hi, > > I'm from a clojure background, where many things are lazy by > default, including fundamental constructs, like map. > > (def x (map func lst)) > ;; func is not called on lst yet > > This has been a source of annoying bugs. > > In erlang, can I assume that _nothing_ is lazy? > > i.e. > > some-expression, > [ func(X) || X <- Lst], > some-other-expression > > now, the "value" of the list-comprehension expression is not used > anywhere (and in a Lazy language like Clojure would not be evaluated > at all). > > However, in Erlang, it's _always_ executed, as nothing is lazy by default. > > Is this assumption correct? > > Thanks! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From steven.charles.davis@REDACTED Sun Mar 2 14:39:05 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Sun, 2 Mar 2014 07:39:05 -0600 Subject: [erlang-questions] Jinterface, Android, and epmd In-Reply-To: References: <78219c1a-123a-4f15-bd0f-18dae1a60c77@googlegroups.com> Message-ID: <798349F9-FFE4-4CC5-947F-A36A5EC4FA1B@gmail.com> Ugh. I see that now. My apologies. I need to learn to read more carefully. /s On Mar 1, 2014, at 3:25 PM, David Welton wrote: > Hi, > > The problem is that I am looking for something in Java. I guess I > could have spelled that out in more detail, but I thought it was > fairly evident from discussing JInterface and Android - which is a > "Java" (well, Dalvik, but... yeah, not Erlang) system, that that is > what I needed. We don't run, nor want to run Erlang on the Android > system at this point in time. > > On Sat, Mar 1, 2014 at 12:41 PM, Steve Davis > wrote: >> Hi David, >> >> Well, I guess it was a bit of a snarky joke, but the very first hit for my search: "epmd written in erlang" on google was: >> >> http://erlang.org/pipermail/erlang-questions/2012-November/070488.html >> >> ...which references: >> >> https://github.com/lemenkov/erlpmd >> >> It may not be exactly what you want but I believe it was what Fred was referring to. >> >> "Was that so hard?" ;-) >> >> /s >> >> >> >> On Mar 1, 2014, at 5:30 AM, David Welton wrote: >> >>> Hi Steve, >>> >>> Actually Google was no use, as he had not released his code. Didn't >>> you see my message, and Maxim's prompt, *friendly* reply? >>> >>> http://erlang.org/pipermail/erlang-questions/2014-February/077967.html >>> >>> >>> On Sat, Mar 1, 2014 at 1:40 AM, Steve Davis >>> wrote: >>>> http://lmgtfy.com >>>> >>>> On Friday, February 28, 2014 7:12:16 AM UTC-6, David Welton wrote: >>>>> >>>>> Looks like there is, according to Fred's message. Let's see if that >>>>> can be tracked down. >>> >>> >>> >>> -- >>> David N. Welton >>> >>> http://www.welton.it/davidw/ >>> >>> http://www.dedasys.com/ >> > > > > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ From jesper.louis.andersen@REDACTED Sun Mar 2 15:15:26 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 2 Mar 2014 15:15:26 +0100 Subject: [erlang-questions] erlang / laziness In-Reply-To: References: Message-ID: On Sun, Mar 2, 2014 at 12:32 PM, t x wrote: > Hi, > > I'm from a clojure background, where many things are lazy by > default, including fundamental constructs, like map. > > (def x (map func lst)) > ;; func is not called on lst yet > > In erlang, this would be: x() -> [Func(L) || L <- list()]. The evaluation will happen when x/0 is invoked, but in Erlang the evaluation order is strict by default and nothing is evaluated "on demand" unless you explicitly ask for an iterator-like construct. Clojure also uses a strict evaluation order, but many data structures are consumed by iteration in Clojure and this means you have a way to terminate a computation in the middle of a map by not demanding the full sequence. > some-expression, > [ func(X) || X <- Lst], > some-other-expression > > Is this assumption correct? > In the above, you essentially have three Expressions E1, E2, E3. The rule in Erlang is that they are evaluated in order, i.e., E1 before E2 before E3. And they are always evaluated for their eventual effect, even if you don't bind the result. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Sun Mar 2 15:16:14 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sun, 2 Mar 2014 15:16:14 +0100 Subject: [erlang-questions] erlang / laziness In-Reply-To: <01DF0966-ABB0-41A0-8EFB-209C2BF0A844@gmail.com> References: <01DF0966-ABB0-41A0-8EFB-209C2BF0A844@gmail.com> Message-ID: On Sun, Mar 2, 2014 at 2:20 PM, Sergej Jurecko wrote: > andalso will evaluate second expression only if first is true > orelse will evaluate second expression only if first is false > > Nothing else is lazy from what I know. > `andalso` and `orelse` are short-circuiting. They are also tail-call optimized (in most recent OTP releases). -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil@REDACTED Sun Mar 2 17:49:19 2014 From: phil@REDACTED (Philip Rhoades) Date: Mon, 03 Mar 2014 03:49:19 +1100 Subject: [erlang-questions] Possibly looking for an Open Source Erlang developer . . or at least useful feedback . . Message-ID: <60979f272a69376398c8cfe4ec8198b5@localhost> People, I have been paying people for the last year or so to get my "Neural Archive Me!" project started: https://narch.me Now that the site is basically going and there is something for people to look at - and be able to get an idea of what it is that I am actually on about - I think that it is time to accelerate the development by Open Sourcing the proposed new parts of the project - see here for a summarised view of what I am thinking: https://docs.google.com/document/d/1yf6W-7EnUy3Zgduc_A119lru7RRz-nVtqiCNaQn3vX0/pub My feeling at the moment is that Erlang would be good for the "Executive Function Supervisor" (a human brain function analogy) because we ultimately want to make this project _very_ big and to be able to deal with lots of concurrency and to be able scale quickly and safely. Even if there isn't anyone here who is in a position to get involved in the project in the traditional Open Source manner (ie no cash remuneration to begin with) I thought maybe the local gurus could offer some useful advice about the appropriateness or not of Erlang for what I had in mind . . Regards, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil@REDACTED From bchesneau@REDACTED Sun Mar 2 22:40:16 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sun, 2 Mar 2014 22:40:16 +0100 Subject: [erlang-questions] [ANN] hackney 0,.11.0 have been released Message-ID: I just released hackney 0,.11.0 my #HTTP client in #Erlang . Lot of improvements in this release: https://github.com/benoitc/hackney/releases/tag/0.11.0 While I was here I also released hackney_lib 0.2.3 https://github.com/benoitc/hackney_lib/releases/tag/0.2.3 Enjoy! - benoit From txrev319@REDACTED Mon Mar 3 01:23:16 2014 From: txrev319@REDACTED (t x) Date: Sun, 2 Mar 2014 16:23:16 -0800 Subject: [erlang-questions] https://github.com/joearms/ezwebframe In-Reply-To: References: Message-ID: In case anyone else runs into this problem (either people on the list or those finding the original question via Google). Here is the problem + solution. * in my setup, localhost = OSX * server = virtual box session running ubuntu Thus, I try to load up the webpage via: http://server:1456 this can load up the webpage, but the problem is that clock1.html hardcodes "localhost", so it tries to open websocket at "localhost:1456" rather than "server:1456" Fixing this solved the problem (and the demos now work). On Fri, Feb 28, 2014 at 11:09 PM, t x wrote: > Hi, > > I'm having some trouble trying to get > https://github.com/joearms/ezwebframe to work. > > ### In particular, on the server (Ubuntu 13), I get: > > x@REDACTED:~/ezwebframe$ make > rebar compile > ==> Entering directory `/home/x/ezwebframe/deps/cowboy' > ==> Entering directory `/home/x/ezwebframe/deps/cowlib' > ==> cowlib (compile) > ==> Leaving directory `/home/x/ezwebframe/deps/cowlib' > ==> Entering directory `/home/x/ezwebframe/deps/ranch' > ==> ranch (compile) > ==> Leaving directory `/home/x/ezwebframe/deps/ranch' > ==> cowboy (compile) > ==> Leaving directory `/home/x/ezwebframe/deps/cowboy' > ==> ezwebframe (compile) > cd demos; make > make[1]: Entering directory `/home/x/ezwebframe/demos' > erlc -o ebin *.erl */*.erl > svg/svg_pad4.erl:63: Warning: variable 'Y' is unused > svg/svg_pad4.erl:204: Warning: variable 'L1' is unused > svg/svg_pad4.erl:218: Warning: variable 'Id' is unused > erl -pa ../deps/cowboy/ebin\ > -pa ../deps/ranch/ebin\ > -pa ../deps/cowlib/ebin\ > -pa ../ebin\ > -pa ./ebin\ > -s ezwebframe_demos start > Erlang R16B01 (erts-5.10.2) [source] [64-bit] [async-threads:10] > [kernel-poll:false] > > a simple_demo of websockets.... > Load the page http://localhost:1456/ in your browser > Starting:{ok,"/home/x/ezwebframe/demos"} > Eshell V5.10.2 (abort with ^G) > 1> websockets started on port:1456 > init: > ezwebframe:handle "/" > ezwebframe_demos::dispatch / => /home/x/ezwebframe/demos/ > mapped to:"/home/x/ezwebframe/demos/" > init: > ezwebframe:handle "/files" > ezwebframe_demos::dispatch /files => /home/x/ezwebframe/demos/files > mapped to:"/home/x/ezwebframe/demos/files" > ezwebframe_demos::dispatch / => /home/x/ezwebframe/demos/ > init: > ezwebframe:handle "/clocks/clock1.html" > ezwebframe_demos::dispatch /clocks/clock1.html => > /home/x/ezwebframe/demos/clocks/clock1.html > mapped to:"/home/x/ezwebframe/demos/clocks/clock1.html" > init: > init: > ezwebframe:handle "/ezwebframe/websock.js" > ezwebframe:handle "/common/jquery-1.7.1.min.js" > init: > ezwebframe_demos::dispatch /ezwebframe/websock.js => > /home/x/ezwebframe/demos/../priv/websock.js > ezwebframe_demos::dispatch /common/jquery-1.7.1.min.js => > /home/x/ezwebframe/demos/common/jquery-1.7.1.min.js > ezwebframe:handle "/clocks/clock1.css" > mapped to:"/home/x/ezwebframe/demos/../priv/websock.js" > mapped to:"/home/x/ezwebframe/demos/common/jquery-1.7.1.min.js" > ezwebframe_demos::dispatch /clocks/clock1.css => > /home/x/ezwebframe/demos/clocks/clock1.css > mapped to:"/home/x/ezwebframe/demos/clocks/clock1.css" > > ### On the client, when I load up the page with "Chrome 33.0.1750.117", I get: > > "Socket closed -- your erlang probably crashed." > > ### Questions: > > What should I try? > > > Thanks! From sean@REDACTED Mon Mar 3 08:00:05 2014 From: sean@REDACTED (Functional Jobs) Date: Mon, 3 Mar 2014 02:00:05 -0500 Subject: [erlang-questions] New Functional Programming Job Opportunities Message-ID: <53142878be6c3@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Erlang Developer at VOALTE http://functionaljobs.com/jobs/8688-erlang-developer-at-voalte Cheers, Sean Murphy FunctionalJobs.com From Maxim.Minin@REDACTED Mon Mar 3 09:00:14 2014 From: Maxim.Minin@REDACTED (Minin Maxim) Date: Mon, 3 Mar 2014 09:00:14 +0100 Subject: [erlang-questions] jinterface and epmd Message-ID: Hi, it is very minimalistic, but it did all, what epmd have to do. You can find it on github - https://github.com/MaximMinin/jepmd There are two or three things that can be improved (logging, exception handling etc.) - I try to do that next weekend. Let me please know, if you have any troubles with it. Regards Maxim Von: Erik S?e S?rensen [mailto:eriksoe@REDACTED] Gesendet: Freitag, 28. Februar 2014 23:58 An: Minin Maxim Cc: Erlang Questions; Kresten Krab Thorup Betreff: Re: [erlang-questions] jinterface and epmd Hi - I think we at the Erjang project might be interested :-) How complete is it? Regards, Erik S?e S?rensen Den 15/11/2013 11.23 skrev "Minin Maxim" >: Hello, i have a little question about jinterface - the communication between an erlang app and an java app (on two different machines) needs epmd on both machines. In my environment there are no possibility to install epmd on the java-machine. That's why I rewrote epmd in java. It can be started as singlton in jvm and acts as normal epmd. Is anyone interested on that solution and what is the best way to pull this implementation to otp standard lib (if there is one)? Thanks Maxim Minin _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Mon Mar 3 10:51:33 2014 From: davidnwelton@REDACTED (David Welton) Date: Mon, 3 Mar 2014 10:51:33 +0100 Subject: [erlang-questions] jinterface and epmd In-Reply-To: References: Message-ID: > it is very minimalistic, but it did all, what epmd have to do. > > You can find it on github - https://github.com/MaximMinin/jepmd > > There are two or three things that can be improved (logging, exception > handling etc.) - I try to do that next weekend. > > Let me please know, if you have any troubles with it. Great, we were moving in that direction as well, but this is much more complete than what we had hacked together so far. Thanks for making it available! -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From davidnwelton@REDACTED Mon Mar 3 11:23:55 2014 From: davidnwelton@REDACTED (David Welton) Date: Mon, 3 Mar 2014 11:23:55 +0100 Subject: [erlang-questions] Erlang nodes, connections and sockets Message-ID: Hello, We have a question here about exactly how Erlang decides to send what where, via which mechanisms. We have a Java node J, and an Erlang node E. J can make rpc calls to E without problems. This always works. J opens an Erlang connection via JInterface, calls what it needs to, and things are fine. Sometimes E can send messages to J, seemingly utilizing the connection that J opens when it starts up. Sometimes J does *not* receive messages from E. Initially we found out that epmd was required and started working on implementing enough of that to route requests through to a server socket on J But it's important to know why it uses one connection over the other - why does it sometimes decide to contact epmd, do a lookup, and open a connection from E to J - and other times, simply use the existing, open connection? We haven't had problems like this with C nodes, although our node J resides on a tablet that is not physically connected to E, so the networking is not quite as fast/clean/robust, although it is a local network and there should not be any huge problems. Thanks, -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From vladdu55@REDACTED Mon Mar 3 11:39:13 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 3 Mar 2014 11:39:13 +0100 Subject: [erlang-questions] Erlang nodes, connections and sockets In-Reply-To: References: Message-ID: Hi David, What do you mean exactly by "sometimes J does not receive messages from E"? Does it happen haphazardly, during the same "session"? Does it happen with the J epmd running? For two nodes to connect, they have to know about each other, which is why epmd exists. If the nodes are connected, epmd is no longer required, the existing connection is used. As you discovered, epmd must run on the machine where the target of the first connection attempt runs. Without a "J epmd", if the first contact is initiated by E, then J is not found. But if J makes a contact after that, then subsequent E->J works fine because the connection has been established. If there is some network hick-up that makes the J node look disconnected or the tablet goes to sleep, then E forgets about it and what happens next depends again on who initiates the contact first. I hope I explained it clearly enough. regards, Vlad On Mon, Mar 3, 2014 at 11:23 AM, David Welton wrote: > Hello, > > We have a question here about exactly how Erlang decides to send what > where, via which mechanisms. > > We have a Java node J, and an Erlang node E. > > J can make rpc calls to E without problems. This always works. J > opens an Erlang connection via JInterface, calls what it needs to, and > things are fine. > > Sometimes E can send messages to J, seemingly utilizing the connection > that J opens when it starts up. > > Sometimes J does *not* receive messages from E. Initially we found > out that epmd was required and started working on implementing enough > of that to route requests through to a server socket on J > > But it's important to know why it uses one connection over the other - > why does it sometimes decide to contact epmd, do a lookup, and open a > connection from E to J - and other times, simply use the existing, > open connection? > > We haven't had problems like this with C nodes, although our node J > resides on a tablet that is not physically connected to E, so the > networking is not quite as fast/clean/robust, although it is a local > network and there should not be any huge problems. > > Thanks, > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnwelton@REDACTED Mon Mar 3 12:05:04 2014 From: davidnwelton@REDACTED (David Welton) Date: Mon, 3 Mar 2014 12:05:04 +0100 Subject: [erlang-questions] Erlang nodes, connections and sockets In-Reply-To: References: Message-ID: Hi, > What do you mean exactly by "sometimes J does not receive messages from E"? > Does it happen haphazardly, during the same "session"? Does it happen with > the J epmd running? I'm not 100% sure, as this was on the Java end. I don't think the pattern was super obvious though. > For two nodes to connect, they have to know about each other, which is why > epmd exists. If the nodes are connected, epmd is no longer required, the > existing connection is used. As you discovered, epmd must run on the machine > where the target of the first connection attempt runs. > > Without a "J epmd", if the first contact is initiated by E, then J is not > found. But if J makes a contact after that, then subsequent E->J works fine > because the connection has been established. > > If there is some network hick-up that makes the J node look disconnected or > the tablet goes to sleep, then E forgets about it and what happens next > depends again on who initiates the contact first. > > I hope I explained it clearly enough. Yes, that's how I had surmised things work, but I wanted to confirm that my mental model reflected reality! Thank you for the explanation, -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From sverker.eriksson@REDACTED Mon Mar 3 15:45:44 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 3 Mar 2014 15:45:44 +0100 Subject: [erlang-questions] unable to build valgrind-enabled erlang runtime In-Reply-To: References: Message-ID: <53149598.7040501@erix.ericsson.se> On 03/01/2014 12:12 AM, Kris Prieb wrote: > Hello List, > > I am attempting to build a valgrind-enabled erlang runtime per: > http://www.erlang.org/doc/installation_guide/INSTALL.html#id72660 > > My platform is an amazon linux machine image on ec2 on which I have already > installed an erlang disribution from source. > > I entered the following at the command prompt: > > [ec2-user@REDACTED emulator]$ env > ERL_TOP=/home/ec2-user/otp_src_R16B02 FLAVOR=smp make valgrind > FLAVOR=$FLAVOR > > The following was returned: > > make -f x86_64-unknown-linux-gnu/Makefile TYPE=valgrind > can't open x86_64-unknown-linux-gnu/valgrind/plain/erl_compile_flags.h for > writing at utils/make_compiler_flags line 65. > make[1]: Entering directory `/home/ec2-user/otp_src_R16B02/erts/emulator' > if utils/gen_git_version x86_64-unknown-linux-gnu/gen_git_version.mk; then > touch beam/erl_bif_info.c; fi > *** valgrind emulator disabled by configure - omitted target all > make[1]: Leaving directory `/home/ec2-user/otp_src_R16B02/erts/emulator' > > > What have I done wrong here? Do I have to run "configure" with special > arguments before building valgrind-enabled runtime? > > Any help would be much appreciated! > Kris > If configure does not find a working valgrind, that target will be disabled. Search for "valgrind" in erts/config.log to see what failed. It probably failed to compile #include . If your valgrind is installed in a non-standard place, point it out to configure with CPPFLAGS=-I/my/valgrind/install/dir/include. /Sverker, Erlang/OTP From bjorn@REDACTED Mon Mar 3 17:49:08 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 3 Mar 2014 17:49:08 +0100 Subject: [erlang-questions] Missing compile warning In-Reply-To: References: Message-ID: On Fri, Feb 28, 2014 at 10:08 PM, Vlad Dumitrescu wrote: > Hi! > > On Fri, Feb 28, 2014 at 7:54 PM, tom kelly wrote: >> >> -module(no_warn). >> -compile(export_all). >> >> -record(my_rec,{field1, field2}). >> >> my_function1(#my_rec{field1 = {tag, _}, field2 = f2}) -> 1; >> my_function1(#my_rec{field1 = {tag, 1}, field2 = f2}) -> 2; % line 7 >> my_function1(_) -> 3. >> >> my_function2(#my_rec{field1 = {tag, _}}) -> 1; >> my_function2(#my_rec{field1 = {tag, 1}}) -> 2; % line11 >> my_function2(_) -> 3. > > > Looks like a bug to me, especially since changing the first clause to > my_function1(#my_rec{field1 = {tag, _}, field2 = _}) -> 1; > gives a warning for the first function too. > It is perhaps a documentation bug. Some warnings can be trusted 100 per cent. For example, if there are no warnigs for unused variables there are no unused variables. The absence of warnings for clauses that don't match does *not* mean that that all clauses can be matched. It merely means that the compiler (during optimisation and pattern matching compilation) did not find any clauses that obviously would not be reached. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From daniel.goertzen@REDACTED Mon Mar 3 17:59:10 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 3 Mar 2014 10:59:10 -0600 Subject: [erlang-questions] case expression scope Message-ID: One thing that repeatedly bites me is the way variables bindings leak out of case expressions. For example, the following code fails to even compile because the Ps and Qs smack into each other... f1(X, Y) -> A = case {X,Y} of {0, Q} -> Q; {P, Q} -> P*Q end, B = case {X,Y} of {0, Q} -> Q; {P, Q} -> P+Q end, {A,B}. In situations like the above, I artificially change the variable names to avoid trouble and end up with something like this: f1(X, Y) -> A = case {X,Y} of {0, Q0} -> Q0; {P0, Q0} -> P0*Q0 end, B = case {X,Y} of {0, Q1} -> Q1; {P1, Q1} -> P1+Q1 end, {A,B}. The binding leakages seems like nothing but hassles and headaches to me, so my questions is, is there actually a reason why bindings need leak out of case expressions? Is there a programming style that leverages this feature? Is there a limitation in the emulator that forces it to be this way? I'd love to have a 'hygienic' case expression. Could it be faked with parse transforms? Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Mar 3 18:06:35 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 03 Mar 2014 17:06:35 +0000 Subject: [erlang-questions] case expression scope In-Reply-To: References: Message-ID: <5314B69B.9020700@llaisdy.com> It doesn't quite answer your question but perhaps case was a late addition. Often more concise code avoids it and uses pattern matching instead. e.g., your example using pattern matching could be: f1(0, Y) -> {Y, Y}; f1(X, Y) -> {X*Y, X+Y}. Best wishes Ivan On 03/03/2014 16:59, Daniel Goertzen wrote: > One thing that repeatedly bites me is the way variables bindings leak > out of case expressions. For example, the following code fails to even > compile because the Ps and Qs smack into each other... > > f1(X, Y) -> > A = case {X,Y} of > {0, Q} -> Q; > {P, Q} -> P*Q > end, > > B = case {X,Y} of > {0, Q} -> Q; > {P, Q} -> P+Q > end, > {A,B}. > > > In situations like the above, I artificially change the variable names > to avoid trouble and end up with something like this: > > f1(X, Y) -> > A = case {X,Y} of > {0, Q0} -> Q0; > {P0, Q0} -> P0*Q0 > end, > > B = case {X,Y} of > {0, Q1} -> Q1; > {P1, Q1} -> P1+Q1 > end, > {A,B}. > > > The binding leakages seems like nothing but hassles and headaches to me, > so my questions is, is there actually a reason why bindings need leak > out of case expressions? Is there a programming style that leverages > this feature? Is there a limitation in the emulator that forces it to > be this way? > > I'd love to have a 'hygienic' case expression. Could it be faked with > parse transforms? > > Dan. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From vladdu55@REDACTED Mon Mar 3 18:16:13 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 3 Mar 2014 18:16:13 +0100 Subject: [erlang-questions] Missing compile warning In-Reply-To: References: Message-ID: On Mon, Mar 3, 2014 at 5:49 PM, Bj?rn Gustavsson wrote: > > On Fri, Feb 28, 2014 at 7:54 PM, tom kelly wrote: > >> > >> -module(no_warn). > >> -compile(export_all). > >> > >> -record(my_rec,{field1, field2}). > >> > >> my_function1(#my_rec{field1 = {tag, _}, field2 = f2}) -> 1; > >> my_function1(#my_rec{field1 = {tag, 1}, field2 = f2}) -> 2; % line 7 > >> my_function1(_) -> 3. > >> > >> my_function2(#my_rec{field1 = {tag, _}}) -> 1; > >> my_function2(#my_rec{field1 = {tag, 1}}) -> 2; % line11 > >> my_function2(_) -> 3. > > It is perhaps a documentation bug. > > Some warnings can be trusted 100 per cent. > For example, if there are no warnigs for unused variables > there are no unused variables. > > The absence of warnings for clauses that > don't match does *not* mean that that all clauses > can be matched. It merely means that > the compiler (during optimisation and > pattern matching compilation) did not find > any clauses that obviously would not be > reached. > > Hi, I'm not sure if I can agree with this. Non-matchable clauses should in my opinion be marked as errors, because they expose a logical flaw (usually a misordering of the clauses), and in this case I would have them be 100% accurate. Given clauses without guards like f(A)->ok; f(B)->ok. then I think we should get a warning/error if B is the same as or more specific than A. This probably applies when there are guards too. If that's the case, it shouldn't be too difficult to implement. What am I missing? Is it difficult just because it is done after some optimization passes that might mess things up? Or is there some other issue? best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Mon Mar 3 18:37:16 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Mon, 3 Mar 2014 18:37:16 +0100 Subject: [erlang-questions] Missing compile warning In-Reply-To: References: Message-ID: On Mon, Mar 3, 2014 at 6:16 PM, Vlad Dumitrescu wrote: > What am I missing? Is it difficult just because it is done after some > optimization passes that might mess things up? Or is there some other issue? I don't know how difficult it would be. The warnings for unreachable clauses are there because they are easy to emit when clauses are discarded during optimisation and pattern matching compilation. We have not really looked at the problem of finding all unreachable clauses; depending on how hard the problem is, it might be more suitable to let Dialyzer do it. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From vladdu55@REDACTED Mon Mar 3 18:50:36 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Mon, 3 Mar 2014 18:50:36 +0100 Subject: [erlang-questions] Missing compile warning In-Reply-To: References: Message-ID: On Mon, Mar 3, 2014 at 6:37 PM, Bj?rn Gustavsson wrote: > On Mon, Mar 3, 2014 at 6:16 PM, Vlad Dumitrescu > wrote: > > > What am I missing? Is it difficult just because it is done after some > > optimization passes that might mess things up? Or is there some other > issue? > > I don't know how difficult it would be. The > warnings for unreachable clauses are there > because they are easy to emit when clauses > are discarded during optimisation and pattern > matching compilation. We have not really > looked at the problem of finding all unreachable > clauses; depending on how hard the problem > is, it might be more suitable to let Dialyzer do > it. I see. I would like to make a case for including this on the list of improvements. To me it is important to be able to rely on this warning/error - it saved me in several occasions. What other warnings have less than 100% coverage? /Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Mar 3 19:46:03 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 3 Mar 2014 10:46:03 -0800 (PST) Subject: [erlang-questions] case expression scope In-Reply-To: References: Message-ID: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> You could hide the bindings inside a fun. ? ?A = (fun() -> case ... end end)( ), ? ?B = (fun() -> case ... end end)( ), ? ?{A, B}. Though I agree with Ivan that refactoring might be a better idea in this case.? A related issue: I'd like to get warnings when variables are matched (not bound) in patterns. I've seldom found repeated variables very useful in practice, they can easily be rewritten to use explicit compares, and sometimes they have hidden groan-inducing bugs.? (Binary patterns are a special case; _some_ repeated variables are be benign there.) Best, Thomas On Monday, March 3, 2014 5:59 PM, Daniel Goertzen wrote: One thing that repeatedly bites me is the way variables bindings leak out of case expressions.? For example, the following code fails to even compile because the Ps and Qs smack into each other... > >f1(X, Y) -> >??? A = case {X,Y} of >??????????? {0, Q} -> Q; >??????????? {P, Q} -> P*Q >??????? end, > >??? B = case {X,Y} of >??????????? {0, Q} -> Q; >??????????? {P, Q} -> P+Q >??????? end, >??? {A,B}. > > > >In situations like the above, I artificially change the variable names to avoid trouble and end up with something like this: > >f1(X, Y) -> >??? A = case {X,Y} of >??????????? {0, Q0} -> Q0; >??????????? {P0, Q0} -> P0*Q0 >??????? end, > >??? B = case {X,Y} of >??????????? {0, Q1} -> Q1; >??????????? {P1, Q1} -> P1+Q1 >??????? end, >??? {A,B}. > > > > >The binding leakages seems like nothing but hassles and headaches to me, so my questions is, is there actually a reason why bindings need leak out of case expressions?? Is there a programming style that leverages this feature?? Is there a limitation in the emulator that forces it to be this way? > > > >I'd love to have a 'hygienic' case expression.? Could it be faked with parse transforms? > > >Dan. > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.goertzen@REDACTED Mon Mar 3 20:07:36 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 3 Mar 2014 13:07:36 -0600 Subject: [erlang-questions] case expression scope In-Reply-To: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: Hmm, fun wrapping could be the basis of hygienic-case parse transform. I'll have to see what the performance overhead of a fun wrap is like. The example I gave is contrived and a bit weak I guess. In my most recent run-in with this issue there were a lot of bindings from the enclosing scope that were used, so breaking things out to top level functions would not always be a good option. Funs would be better, but add clutter and maybe runtime overhead. Compromises, compromises.... Cheers, Dan. On Mon, Mar 3, 2014 at 12:46 PM, Thomas Lindgren wrote: > You could hide the bindings inside a fun. > > A = (fun() -> case ... end end)( ), > B = (fun() -> case ... end end)( ), > {A, B}. > > Though I agree with Ivan that refactoring might be a better idea in this > case. > > A related issue: I'd like to get warnings when variables are matched (not > bound) in patterns. I've seldom found repeated variables very useful in > practice, they can easily be rewritten to use explicit compares, and > sometimes they have hidden groan-inducing bugs. > > (Binary patterns are a special case; _some_ repeated variables are be > benign there.) > > Best, > Thomas > > > On Monday, March 3, 2014 5:59 PM, Daniel Goertzen < > daniel.goertzen@REDACTED> wrote: > > One thing that repeatedly bites me is the way variables bindings leak out > of case expressions. For example, the following code fails to even compile > because the Ps and Qs smack into each other... > > f1(X, Y) -> > A = case {X,Y} of > {0, Q} -> Q; > {P, Q} -> P*Q > end, > > B = case {X,Y} of > {0, Q} -> Q; > {P, Q} -> P+Q > end, > {A,B}. > > > In situations like the above, I artificially change the variable names to > avoid trouble and end up with something like this: > > f1(X, Y) -> > A = case {X,Y} of > {0, Q0} -> Q0; > {P0, Q0} -> P0*Q0 > end, > > B = case {X,Y} of > {0, Q1} -> Q1; > {P1, Q1} -> P1+Q1 > end, > {A,B}. > > > The binding leakages seems like nothing but hassles and headaches to me, > so my questions is, is there actually a reason why bindings need leak out > of case expressions? Is there a programming style that leverages this > feature? Is there a limitation in the emulator that forces it to be this > way? > > I'd love to have a 'hygienic' case expression. Could it be faked with > parse transforms? > > Dan. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Mon Mar 3 21:19:30 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 3 Mar 2014 21:19:30 +0100 Subject: [erlang-questions] Missing compile warning In-Reply-To: References: Message-ID: As for including guards, it is not possible to warn about all cases where a clause cannot be matched. Consider: f (X, Y, Z) when X*X*X+Y*Y*Y==Z*Z*Z, is_integer(X), is_integer(Y), is_integer(Z), X>0, Y>0, Z>0 -> ... you get the picture. :) Linear patterns would be doable. Non-linear patterns perhaps too, but probably less straightforward. Den 03/03/2014 18.16 skrev "Vlad Dumitrescu" : > On Mon, Mar 3, 2014 at 5:49 PM, Bj?rn Gustavsson wrote: > >> > On Fri, Feb 28, 2014 at 7:54 PM, tom kelly >> wrote: >> >> >> >> -module(no_warn). >> >> -compile(export_all). >> >> >> >> -record(my_rec,{field1, field2}). >> >> >> >> my_function1(#my_rec{field1 = {tag, _}, field2 = f2}) -> 1; >> >> my_function1(#my_rec{field1 = {tag, 1}, field2 = f2}) -> 2; % line 7 >> >> my_function1(_) -> 3. >> >> >> >> my_function2(#my_rec{field1 = {tag, _}}) -> 1; >> >> my_function2(#my_rec{field1 = {tag, 1}}) -> 2; % line11 >> >> my_function2(_) -> 3. >> >> It is perhaps a documentation bug. >> >> Some warnings can be trusted 100 per cent. >> For example, if there are no warnigs for unused variables >> there are no unused variables. >> >> The absence of warnings for clauses that >> don't match does *not* mean that that all clauses >> can be matched. It merely means that >> the compiler (during optimisation and >> pattern matching compilation) did not find >> any clauses that obviously would not be >> reached. >> >> > Hi, > > I'm not sure if I can agree with this. Non-matchable clauses should in my > opinion be marked as errors, because they expose a logical flaw (usually a > misordering of the clauses), and in this case I would have them be 100% > accurate. > > Given clauses without guards like f(A)->ok; f(B)->ok. then I think we > should get a warning/error if B is the same as or more specific than A. > This probably applies when there are guards too. If that's the case, it > shouldn't be too difficult to implement. > > What am I missing? Is it difficult just because it is done after some > optimization passes that might mess things up? Or is there some other issue? > > best regards, > Vlad > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon Mar 3 22:02:24 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 4 Mar 2014 10:02:24 +1300 Subject: [erlang-questions] case expression scope In-Reply-To: References: Message-ID: <45BC2735-6ADE-45BE-B6AD-AF2386080DB7@cs.otago.ac.nz> On 4/03/2014, at 5:59 AM, Daniel Goertzen wrote: > One thing that repeatedly bites me is the way variables bindings leak out of case expressions. For example, the following code fails to even compile because the Ps and Qs smack into each other... > > f1(X, Y) -> > A = case {X,Y} of > {0, Q} -> Q; > {P, Q} -> P*Q > end, > > B = case {X,Y} of > {0, Q} -> Q; > {P, Q} -> P+Q > end, > {A,B}. That is of course a sketch, not real code. But as a sketch, it looks like something that is crying out for a couple of functions: f1(X, Y) -> A = f1_A(X, Y), B = f1_B(X, Y), {A,B}. f1_A(0, Q) -> Q; f1_A(P, Q) -> P*Q. f1_B(0, Q) -> Q; f1_B(P, Q) -> P+Q. > The binding leakages seems like nothing but hassles and headaches to me, so my questions is, is there actually a reason why bindings need leak out of case expressions? Yes. (It's not just 'case' either.) Calling it "leaking" is rather prejudicial; when you turn on the tap over your kitchen sink you do not complain that it's "leaking". > Is there a programming style that leverages this feature? Yes. > Is there a limitation in the emulator that forces it to be this way? Certainly not. > > I'd love to have a 'hygienic' case expression. Could it be faked with parse transforms? All selection expressions in Erlang do this, and it is as hygienic as anyone could wish work. You don't need a parse transform. (It would be an AMAZINGLY bad idea to have things that *look* like 'case' expressions not *act* like them.) In fact all you really need is -define(BEGIN, ((fun () ->). -define(END, end)())). f1(X, Y) -> A = ?BEGIN case {X,Y} of {0,Q} -> Q ; {P,Q} -> P*Q end ?END, B = ?BEGIN case {X,Y} of {0,Q} -> Q ; {P,Q} -> P+Q end ?END, {A,B}. Hmm. I seem to recall that this very same solution has already been posted in this mailing list. Right now, I suggest you take this deliberate design feature of Erlang as a style warning: "You are using the same variable for two different purposes in a single clause; this is pretty much guaranteed to confuse people so DON'T." Think of it is not entirely unlike gcc's -Wshadow. From ok@REDACTED Mon Mar 3 22:23:20 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 4 Mar 2014 10:23:20 +1300 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> On 4/03/2014, at 8:07 AM, Daniel Goertzen wrote: > Hmm, fun wrapping could be the basis of hygienic-case parse transform. I'll have to see what the performance overhead of a fun wrap is like. > > The example I gave is contrived and a bit weak I guess. In my most recent run-in with this issue there were a lot of bindings from the enclosing scope that were used, so breaking things out to top level functions would not always be a good option. I see a non-sequitur there. Simplified examples are great for revealing bugs. For illuminating style concerns, NOTHING beats REAL code. "There were a lot of bindings from the enclosing scope" is already a warning sign that the code should be restructured. > Funs would be better, but add clutter and maybe runtime overhead. There is currently some run-time overhead. In R16B03-1, the compiler still does not optimise (fun (...) -> ... ... end)(...) by turning it into the equivalent of an SML let ... in ... end form, but there is no particular reason why it couldn't. Whether you can _measure_ the overhead in a real application is another matter entirely. Splitting out little functions and then telling the compiler to inline them might well have the least overhead of all. From ok@REDACTED Mon Mar 3 22:42:24 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 4 Mar 2014 10:42:24 +1300 Subject: [erlang-questions] Missing compile warning In-Reply-To: References: Message-ID: <61FEA33B-A59A-4731-A71E-47D9DD0AA75A@cs.otago.ac.nz> On 4/03/2014, at 6:16 AM, Vlad Dumitrescu wrote: > > I'm not sure if I can agree with this. Non-matchable clauses should in my opinion be marked as errors, because they expose a logical flaw (usually a misordering of the clauses), and in this case I would have them be 100% accurate. Consider a function with two clauses. f(X, ...) when G1 -> B1; f(X, ...) when G2 -> B2. where X, ... stands for the same sequence of distinct variables in both clauses. The second clause is unmatchable iff G1 and G2 are equivalent. Now G1 and G2 may contain arithmetic expressions, let's say they are E1 > 0 and E2 > 0 respectively. If memory serves me correctly, determining whether two arbitrary arithmetic expressions are equal is unsolvable. If I'm wrong about that, let G1 and G2 be Boolean expressions. Determining whether G1 and G2 are equivalent is then the standard NP-complete problem. There are clearly going to be some special cases that can be handled: guards that are pure conjunctions (,) of type tests and Variable Relop Constant should be doable, for example. It might be an interesting research project for someone to determine the exact complexity of determining when one Erlang guard implies another. If user-defined guards were ever admitted into Erlang the task would become obviously impossible. From eric.pailleau@REDACTED Mon Mar 3 23:54:47 2014 From: eric.pailleau@REDACTED (Eric Pailleau) Date: Mon, 03 Mar 2014 23:54:47 +0100 Subject: [erlang-questions] case expression scope Message-ID: f1(X,Y)-> case {X,Y} of {0, Q} -> {Q, Q} ; {P, Q} -> {P*Q, P+Q} end. regards. ? Envoy? depuis mon mobile ? Eric Daniel Goertzen a ?crit?: >One thing that repeatedly bites me is the way variables bindings leak out >of case expressions. For example, the following code fails to even compile >because the Ps and Qs smack into each other... > >f1(X, Y) -> > A = case {X,Y} of > {0, Q} -> Q; > {P, Q} -> P*Q > end, > > B = case {X,Y} of > {0, Q} -> Q; > {P, Q} -> P+Q > end, > {A,B}. > > >In situations like the above, I artificially change the variable names to >avoid trouble and end up with something like this: > >f1(X, Y) -> > A = case {X,Y} of > {0, Q0} -> Q0; > {P0, Q0} -> P0*Q0 > end, > > B = case {X,Y} of > {0, Q1} -> Q1; > {P1, Q1} -> P1+Q1 > end, > {A,B}. > > >The binding leakages seems like nothing but hassles and headaches to me, so >my questions is, is there actually a reason why bindings need leak out of >case expressions? Is there a programming style that leverages this >feature? Is there a limitation in the emulator that forces it to be this >way? > >I'd love to have a 'hygienic' case expression. Could it be faked with >parse transforms? > >Dan. > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Tue Mar 4 06:08:18 2014 From: bjorn@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 4 Mar 2014 06:08:18 +0100 Subject: [erlang-questions] Missing compile warning In-Reply-To: References: Message-ID: On Mon, Mar 3, 2014 at 6:50 PM, Vlad Dumitrescu wrote: > > What other warnings have less than 100% coverage? Warnings for arithmetic expressions that will fail such as x+42 and 1/0. Guards that will always fail. Those warnings are emitted when the optimiser tries to evaluate expressions at compile time. So although there will be a warning for 1/0, there will be no warning for X/0. There is some documentation about this, at the end of the description of compile:file/2: http://www.erlang.org/doc/man/compile.html /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kris_prieb@REDACTED Tue Mar 4 09:45:54 2014 From: kris_prieb@REDACTED (Kris Prieb) Date: Tue, 4 Mar 2014 02:45:54 -0600 Subject: [erlang-questions] unable to build valgrind-enabled erlang runtime In-Reply-To: <53149598.7040501@erix.ericsson.se> References: <53149598.7040501@erix.ericsson.se> Message-ID: Hello List and Sverker, Thank you for your assistance. I did have valgrind installed prior to running configure, but not its source code. Installing the source code and running configure again did fix the problem of the missing include file just as you indicated. However, I am still unable to build the valgrind-enabled emulator due to occurence of other errors. After calling: env ERL_TOP=/home/ec2-user/otp_src_R16B02 make valgrind FLAVOR=smp I receive the following errors: ... ... obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_bif0.o:(.data+0x5b40): undefined reference to `nbif_emulate_fpe' obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_amd64_bifs.o: In function `nbif_handle_fp_exception': /home/ec2-user/otp_src_R16B02/erts/emulator/x86_64-unknown-linux-gnu/valgrind/smp/hipe_amd64_bifs.S:287: undefined reference to `erts_restore_fpu' collect2: ld returned 1 exit status make[1]: *** [/home/ec2-user/otp_src_R16B02/bin/x86_64-unknown-linux-gnu/beam.valgrind.smp] Error 1 make[1]: Leaving directory `/home/ec2-user/otp_src_R16B02/erts/emulator' Would appreciate any suggestions as to how to fix this. Kris On Mon, Mar 3, 2014 at 8:45 AM, Sverker Eriksson < sverker.eriksson@REDACTED> wrote: > On 03/01/2014 12:12 AM, Kris Prieb wrote: > >> Hello List, >> >> I am attempting to build a valgrind-enabled erlang runtime per: >> http://www.erlang.org/doc/installation_guide/INSTALL.html#id72660 >> >> My platform is an amazon linux machine image on ec2 on which I have >> already >> installed an erlang disribution from source. >> >> I entered the following at the command prompt: >> >> [ec2-user@REDACTED emulator]$ env >> ERL_TOP=/home/ec2-user/otp_src_R16B02 FLAVOR=smp make valgrind >> FLAVOR=$FLAVOR >> >> The following was returned: >> >> make -f x86_64-unknown-linux-gnu/Makefile TYPE=valgrind >> can't open x86_64-unknown-linux-gnu/valgrind/plain/erl_compile_flags.h >> for >> writing at utils/make_compiler_flags line 65. >> make[1]: Entering directory `/home/ec2-user/otp_src_R16B02/erts/emulator' >> if utils/gen_git_version x86_64-unknown-linux-gnu/gen_git_version.mk; >> then >> touch beam/erl_bif_info.c; fi >> *** valgrind emulator disabled by configure - omitted target all >> make[1]: Leaving directory `/home/ec2-user/otp_src_R16B02/erts/emulator' >> >> >> What have I done wrong here? Do I have to run "configure" with special >> arguments before building valgrind-enabled runtime? >> >> Any help would be much appreciated! >> Kris >> >> > If configure does not find a working valgrind, that target will be > disabled. > > Search for "valgrind" in erts/config.log to see what failed. It probably > failed to compile #include . > > If your valgrind is installed in a non-standard place, point it out to > configure with CPPFLAGS=-I/my/valgrind/install/dir/include. > > /Sverker, Erlang/OTP > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Tue Mar 4 11:39:48 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Tue, 4 Mar 2014 11:39:48 +0100 Subject: [erlang-questions] unable to build valgrind-enabled erlang runtime In-Reply-To: References: <53149598.7040501@erix.ericsson.se> Message-ID: <5315AD74.7040205@ericsson.com> You have to disable hipe: ./configure --disable-hipe After successful build, set export VALGRIND_LOG_DIR=/my/valgrind/log/dir export VALGRIND_MISC_FLAGS="--suppressions=$ERL_TOP/erts/emulator/valgrind/suppress.standard --show-possibly-lost=no" and run with $ERL_TOP/bin/cerl -valgrind /Sverker On 03/04/2014 09:45 AM, Kris Prieb wrote: > Hello List and Sverker, > > Thank you for your assistance. I did have valgrind installed prior to > running configure, but not its source code. Installing the source code and > running configure again did fix the problem of the missing include file > just as you indicated. > > However, I am still unable to build the valgrind-enabled emulator due to > occurence of other errors. After calling: > > env ERL_TOP=/home/ec2-user/otp_src_R16B02 make valgrind FLAVOR=smp > > I receive the following errors: > > ... > ... > obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_bif0.o:(.data+0x5b40): > undefined reference to `nbif_emulate_fpe' > obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_amd64_bifs.o: In function > `nbif_handle_fp_exception': > /home/ec2-user/otp_src_R16B02/erts/emulator/x86_64-unknown-linux-gnu/valgrind/smp/hipe_amd64_bifs.S:287: > undefined reference to `erts_restore_fpu' > collect2: ld returned 1 exit status > make[1]: *** > [/home/ec2-user/otp_src_R16B02/bin/x86_64-unknown-linux-gnu/beam.valgrind.smp] > Error 1 > make[1]: Leaving directory `/home/ec2-user/otp_src_R16B02/erts/emulator' > > > Would appreciate any suggestions as to how to fix this. > > Kris > > > On Mon, Mar 3, 2014 at 8:45 AM, Sverker Eriksson < > sverker.eriksson@REDACTED> wrote: > >> On 03/01/2014 12:12 AM, Kris Prieb wrote: >> >>> Hello List, >>> >>> I am attempting to build a valgrind-enabled erlang runtime per: >>> http://www.erlang.org/doc/installation_guide/INSTALL.html#id72660 >>> >>> My platform is an amazon linux machine image on ec2 on which I have >>> already >>> installed an erlang disribution from source. >>> >>> I entered the following at the command prompt: >>> >>> [ec2-user@REDACTED emulator]$ env >>> ERL_TOP=/home/ec2-user/otp_src_R16B02 FLAVOR=smp make valgrind >>> FLAVOR=$FLAVOR >>> >>> The following was returned: >>> >>> make -f x86_64-unknown-linux-gnu/Makefile TYPE=valgrind >>> can't open x86_64-unknown-linux-gnu/valgrind/plain/erl_compile_flags.h >>> for >>> writing at utils/make_compiler_flags line 65. >>> make[1]: Entering directory `/home/ec2-user/otp_src_R16B02/erts/emulator' >>> if utils/gen_git_version x86_64-unknown-linux-gnu/gen_git_version.mk; >>> then >>> touch beam/erl_bif_info.c; fi >>> *** valgrind emulator disabled by configure - omitted target all >>> make[1]: Leaving directory `/home/ec2-user/otp_src_R16B02/erts/emulator' >>> >>> >>> What have I done wrong here? Do I have to run "configure" with special >>> arguments before building valgrind-enabled runtime? >>> >>> Any help would be much appreciated! >>> Kris >>> >>> >> If configure does not find a working valgrind, that target will be >> disabled. >> >> Search for "valgrind" in erts/config.log to see what failed. It probably >> failed to compile #include . >> >> If your valgrind is installed in a non-standard place, point it out to >> configure with CPPFLAGS=-I/my/valgrind/install/dir/include. >> >> /Sverker, Erlang/OTP >> >> >> >> From 249505968@REDACTED Tue Mar 4 14:51:07 2014 From: 249505968@REDACTED (=?gb18030?B?99L30Q==?=) Date: Tue, 4 Mar 2014 21:51:07 +0800 Subject: [erlang-questions] How to investigate a CPU Load problem ? Message-ID: Our Project just get in some trouble.... The CPU Load seems too high (10 for 8 core CPU). we use etop and find out that no any process has more than 1 message. Now I don't know how to investigate next. Could some one give me some advice? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Tue Mar 4 15:51:50 2014 From: eric.pailleau@REDACTED (Eric Pailleau) Date: Tue, 04 Mar 2014 15:51:50 +0100 Subject: [erlang-questions] case expression scope Message-ID: Hello, in fact there is even no need to bind any other variable : f1(X, Y) -> case {X, Y} of {0, Y} -> {Y, Y} ; {X, Y} -> {X*Y, X+Y} end. and this can be reduced to test only X value as 0 or other value. No need to test Y. Regard... ? Envoy? depuis mon mobile ? Eric Eric Pailleau a ?crit?: >f1(X,Y)-> > case {X,Y} of > {0, Q} -> {Q, Q} ; > {P, Q} -> {P*Q, P+Q} > end. > >regards. > >? Envoy? depuis mon mobile ? Eric > >Daniel Goertzen a ?crit?: > >>One thing that repeatedly bites me is the way variables bindings leak out >>of case expressions. For example, the following code fails to even compile >>because the Ps and Qs smack into each other... >> >>f1(X, Y) -> >> A = case {X,Y} of >> {0, Q} -> Q; >> {P, Q} -> P*Q >> end, >> >> B = case {X,Y} of >> {0, Q} -> Q; >> {P, Q} -> P+Q >> end, >> {A,B}. >> >> >>In situations like the above, I artificially change the variable names to >>avoid trouble and end up with something like this: >> >>f1(X, Y) -> >> A = case {X,Y} of >> {0, Q0} -> Q0; >> {P0, Q0} -> P0*Q0 >> end, >> >> B = case {X,Y} of >> {0, Q1} -> Q1; >> {P1, Q1} -> P1+Q1 >> end, >> {A,B}. >> >> >>The binding leakages seems like nothing but hassles and headaches to me, so >>my questions is, is there actually a reason why bindings need leak out of >>case expressions? Is there a programming style that leverages this >>feature? Is there a limitation in the emulator that forces it to be this >>way? >> >>I'd love to have a 'hygienic' case expression. Could it be faked with >>parse transforms? >> >>Dan. >> >>_______________________________________________ >>erlang-questions mailing list >>erlang-questions@REDACTED >>http://erlang.org/mailman/listinfo/erlang-questions > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Tue Mar 4 16:46:01 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Tue, 4 Mar 2014 10:46:01 -0500 Subject: [erlang-questions] [ANN] Recon 2.1.0 released Message-ID: <20140304154600.GD62889@ferdair.local> Hi everyone, I've just released recon 2.1.0, a library to debug dand diagnose Erlang production systems. The biggest addition here is the addition of `recon_trace', to try and allow safe tracing, in production. It's a bit similar in intent to redbug (without the dependency chain), and tries to be more powerful. Example usage: 1> recon_trace:calls({queue, '_', fun([A,_]) -> return_trace() end}, {10,100}). 32 13:24:21.324309 <0.38.0> queue:in(3, {[],[]}) 13:24:21.371473 <0.38.0> queue:in/2 --> {[3],[]} 13:25:14.694865 <0.53.0> queue:split(4, {[10,9,8,7],[1,2,3,4,5,6]}) 13:25:14.695194 <0.53.0> queue:split/2 --> {{[4,3,2],[1]},{[10,9,8,7],[5,6]}} 2> recon_trace:clear(). ok This matches all functions from the queue module with an arity 2, and returns the result of the call. It also puts a practical limit of 10 trace messages per 100 milliseconds. There's more stuff in there: - Limiting to an absolute count or a rate over time - Matching on arity only - Matching on multiple specs - Allowing to match on existing, new, all pids, or one or more processes (of the form , {A,B,C}, "", some_name, {global, Name}, {via, gproc, Name}, etc.) - Printing traces with arities or arguments - tracing local function calls (see f(X), not mod:f(X)) There's also protection against annoying errors: - wildcard matches on modules banned unless restricting the arguments - don't trace IO, lists, or recon_trace itself - Each call to `recon_trace:calls' resets the trace patterns to avoid adding more specs than expected - Linked to the calling process so that a disconnected node or crashed shell turns of tracing on the remote node For the time being, only function calls are being traced -- GC, message passing, and scheduling aren't included. I hope this is still going to be useful to Erlang devs around! Full Documentation: http://ferd.github.io/recon/recon_trace.html Source: https://github.com/ferd/recon Regards, Fred. From daniel.goertzen@REDACTED Tue Mar 4 17:10:57 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Tue, 4 Mar 2014 10:10:57 -0600 Subject: [erlang-questions] case expression scope In-Reply-To: <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> Message-ID: I've been reflecting on this some more, and have realized one of my biases on the subject comes from the way C/C++ manages scope: Anything within curly braces, whether it is a function, if, while, for, try, or catch, is a scope which encapsulates all declarations within. This uniform rule makes it easier to reason about code, and not having it in Erlang is, well, jarring to me. Now both Erlang and C/C++ can *read* variables from enclosing scopes, but only C/C++ can *mutate* variables from enclosing scopes. Perhaps Erlang's case scoping rules are just a way to give similar powers to affect the enclosing scope. The actual clause that predicated all this is here: https://gist.github.com/goertzenator/9347573 There are a lot of case expressions that leave unwanted bindings lying around. I have to pay attention to use different binding names for each to avoid collisions. Specifically the AuthKey and PrivKey expressions had collisions at first because they are nearly identical. The code would be a lot easier to reason about if I didn't have to look out for such things. I tried putting this function together in various different ways, and this way was the most concise, most readable, and most amenable to future tweaking. I normally don't tolerate clauses this long, but breaking it up always seemed to compromise those things. Thank you for your ideas Richard. I see I could also use funs directly instead of cases. f1(X, Y) -> A = fun({0, Q}) -> Q; ({P, Q}) -> P*Q end({X,Y}), B = fun({0, Q}) -> Q; ({P, Q}) -> P+Q end({X,Y}), {A,B}. Regards, Dan. On Mon, Mar 3, 2014 at 3:23 PM, Richard A. O'Keefe wrote: > > On 4/03/2014, at 8:07 AM, Daniel Goertzen wrote: > > > Hmm, fun wrapping could be the basis of hygienic-case parse transform. > I'll have to see what the performance overhead of a fun wrap is like. > > > > The example I gave is contrived and a bit weak I guess. In my most > recent run-in with this issue there were a lot of bindings from the > enclosing scope that were used, so breaking things out to top level > functions would not always be a good option. > > I see a non-sequitur there. > > Simplified examples are great for revealing bugs. > > For illuminating style concerns, NOTHING beats REAL code. > > "There were a lot of bindings from the enclosing scope" > is already a warning sign that the code should be restructured. > > > Funs would be better, but add clutter and maybe runtime overhead. > > There is currently some run-time overhead. > In R16B03-1, the compiler still does not optimise > > (fun (...) -> ... ... end)(...) > > by turning it into the equivalent of an SML let ... in ... end > form, but there is no particular reason why it couldn't. > > Whether you can _measure_ the overhead in a real application > is another matter entirely. > > Splitting out little functions and then telling the compiler > to inline them might well have the least overhead of all. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From send2philip@REDACTED Tue Mar 4 18:33:58 2014 From: send2philip@REDACTED (Philip Clarke) Date: Tue, 4 Mar 2014 17:33:58 +0000 Subject: [erlang-questions] How to investigate a CPU Load problem ? In-Reply-To: References: Message-ID: Hi, I wonder how you measured CPU load ? If your processes have short message queues, then that is good news at least. I would suggest looking at your etop output to see where most reductions are spent. Then if that does not help, fprof will get you very detailed information. Good luck Philip On Tue, Mar 4, 2014 at 1:51 PM, ?? <249505968@REDACTED> wrote: > Our Project just get in some trouble.... > The CPU Load seems too high (10 for 8 core CPU). > we use etop and find out that no any process has more than 1 message. > Now I don't know how to investigate next. > Could some one give me some advice? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil@REDACTED Tue Mar 4 18:08:50 2014 From: phil@REDACTED (Philip Rhoades) Date: Wed, 05 Mar 2014 04:08:50 +1100 Subject: [erlang-questions] Clarification: Possibly looking for an Open Source Erlang developer . . or at least useful feedback . . In-Reply-To: <60979f272a69376398c8cfe4ec8198b5@localhost> References: <60979f272a69376398c8cfe4ec8198b5@localhost> Message-ID: <07eac8b1856a51d132eda5a7b7689caa@localhost> People, From some of the responses I have been getting it is clear that my comment about an "Executive Function Supervisor" is misleading: the "supervisor" I am envisaging is not an AGI in some way and is not doing the actual work - it would be more like the "traffic cop" directing the work to the appropriate place - the first thing is being able to direct lots of incoming text messages to Java servers and sending outgoing messages back to the Web Front End (stuff that Erlang should be good at). I also thought it might be able to manage the automatic creation and removal of virtual Java servers - it would be a load manager in that sense - starting other background (intelligent parsing of large amounts of text data etc) processes when load was low etc. I will update the doc so it is a bit clearer. Regards, Phil. On 2014-03-03 03:49, Philip Rhoades wrote: > People, > > I have been paying people for the last year or so to get my "Neural > Archive Me!" project started: > > https://narch.me > > Now that the site is basically going and there is something for people > to look at - and be able to get an idea of what it is that I am > actually on about - I think that it is time to accelerate the > development by Open Sourcing the proposed new parts of the project - > see here for a summarised view of what I am thinking: > > > https://docs.google.com/document/d/1yf6W-7EnUy3Zgduc_A119lru7RRz-nVtqiCNaQn3vX0/pub > > My feeling at the moment is that Erlang would be good for the > "Executive Function Supervisor" (a human brain function analogy) > because we ultimately want to make this project _very_ big and to be > able to deal with lots of concurrency and to be able scale quickly and > safely. > > Even if there isn't anyone here who is in a position to get involved > in the project in the traditional Open Source manner (ie no cash > remuneration to begin with) I thought maybe the local gurus could > offer some useful advice about the appropriateness or not of Erlang > for what I had in mind . . > > Regards, > > Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil@REDACTED From mloftis@REDACTED Tue Mar 4 19:13:41 2014 From: mloftis@REDACTED (Michael Loftis) Date: Tue, 4 Mar 2014 10:13:41 -0800 Subject: [erlang-questions] How to investigate a CPU Load problem ? In-Reply-To: References: Message-ID: In Linux at least, the load average includes not only the run queue but the io wait queue. You have to look at % CPU utilization stats as well as io stats to figure out where your load is coming from precisely (CPU or IO) On Tue, Mar 4, 2014 at 5:51 AM, ?? <249505968@REDACTED> wrote: > Our Project just get in some trouble.... > The CPU Load seems too high (10 for 8 core CPU). > we use etop and find out that no any process has more than 1 message. > Now I don't know how to investigate next. > Could some one give me some advice? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From gumm@REDACTED Tue Mar 4 21:26:37 2014 From: gumm@REDACTED (Jesse Gumm) Date: Tue, 4 Mar 2014 14:26:37 -0600 Subject: [erlang-questions] How to investigate a CPU Load problem ? In-Reply-To: References: Message-ID: To help find out what processes go haywire when they do, I use a slightly modified version of entop that shows the current function call, process status (waiting, running), and stacktrace to help debug what's going on: https://github.com/choptastic/entop/commit/c27d6c3241949629dc526a55c45a851260aec04b (Yeah, I know the indenting is all hosed up). And of course, htop to verify that it is indeed the beam process that's freaking out. Best of luck, -Jesse On Tue, Mar 4, 2014 at 12:13 PM, Michael Loftis wrote: > In Linux at least, the load average includes not only the run queue > but the io wait queue. You have to look at % CPU utilization stats as > well as io stats to figure out where your load is coming from > precisely (CPU or IO) > > On Tue, Mar 4, 2014 at 5:51 AM, ?? <249505968@REDACTED> wrote: >> Our Project just get in some trouble.... >> The CPU Load seems too high (10 for 8 core CPU). >> we use etop and find out that no any process has more than 1 message. >> Now I don't know how to investigate next. >> Could some one give me some advice? >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > > -- > > "Genius might be described as a supreme capacity for getting its possessors > into trouble of all kinds." > -- Samuel Butler > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- Jesse Gumm Owner, Sigma Star Systems 414.940.4866 || sigma-star.com || @jessegumm From jesper.louis.andersen@REDACTED Tue Mar 4 21:41:46 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Tue, 4 Mar 2014 21:41:46 +0100 Subject: [erlang-questions] How to investigate a CPU Load problem ? In-Reply-To: References: Message-ID: I will suggest installing `recon` on the node and then use recon:proc_window/3 with reductions in order to figure out what are consuming reductions in the system. On Linux, also investigate the process with `perf` in order to make sure it is actually wasting time doing reduction work (beam_emu.c takes up all the time) On Tue, Mar 4, 2014 at 2:51 PM, ?? <249505968@REDACTED> wrote: > Our Project just get in some trouble.... > The CPU Load seems too high (10 for 8 core CPU). > we use etop and find out that no any process has more than 1 message. > Now I don't know how to investigate next. > Could some one give me some advice? > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Mar 4 22:49:12 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 5 Mar 2014 10:49:12 +1300 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> Message-ID: <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> On 5/03/2014, at 5:10 AM, Daniel Goertzen wrote: > I've been reflecting on this some more, and have realized one of my biases on the subject comes from the way C/C++ manages scope: Anything within curly braces, whether it is a function, if, while, for, try, or catch, is a scope which encapsulates all declarations within. This uniform rule makes it easier to reason about code, and not having it in Erlang is, well, jarring to me. > > Now both Erlang and C/C++ can *read* variables from enclosing scopes, but only C/C++ can *mutate* variables from enclosing scopes. Perhaps Erlang's case scoping rules are just a way to give similar powers to affect the enclosing scope. No, you are still thinking in C/C++ terms. There are three things in Erlang that are scopes: - a function clause is a scope - a 'fun' is a scope - a list comprehension is a scope In something like f(X, Y) -> case Y of {A,B} -> Z = 1 ; [A,B] -> Z = 2 end, {foo,A,B,Z}. there is no "leakage" from one scope to another and there is no "affect[ing] the enclosing scope" because THERE IS ONLY ONE SCOPE. > The actual clause that predicated all this is here: https://gist.github.com/goertzenator/9347573 Yike! I have never shared the vulgar prejudice against long functions, but 78 lines for a single clause? I would _definitely_ start by breaking out little functions. engine_id(#{engine_id := local}) -> snmp_agent_controller:get_engine_id(); engine_id(#{engine_id := E}) when is_list(E) -> E. authkey(#{authkey := AuthKey}, _, _) when is_list(AuthKey) -> AuthKey; authkey(#{authpassword := AuthPass}, Localization_Hash, Engine_Id) -> snmp:passwd2localized_key(Localization_Hash, AuthPass, Engine_Id). privkey(#{privkey := PrivKey}, _, _) when is_list(PrivKey) -> PrivKey; privkey(#{privpassword := PrivPass}, Localization_Hash, Engine_Id) when is_list(PrivPass) -> lists:sublist(snmp:passwd2localized_key( Localization_Hash, PrivPass, Engine_Id), 16). ... > There are a lot of case expressions that leave unwanted bindings lying around. There shouldn't _be_ a lot of case expressions in a single function clause. _That_ is the problem. > I have to pay attention to use different binding names for each to avoid collisions. Specifically the AuthKey and PrivKey expressions had collisions at first because they are nearly identical. The code would be a lot easier to reason about if I didn't have to look out for such things. And if you split them out into separate functions, you _wouldn't_ have to look out for such things. > > I tried putting this function together in various different ways, and this way was the most concise, most readable, and most amenable to future tweaking. If this was the most readable, I really do not want to see the other versions! I find the code quite unreadable (the RunTogtherVariableNames don't help) and splitting out little functions made it MUCH easier for me to see what's going on. As for "most amenable to future tweaking", I'd like to point out an advantage of splitting things out as functions: ++ you can give them types and have the types checked. ++ > I see I could also use funs directly instead of cases. > > f1(X, Y) -> > A = fun({0, Q}) -> Q; > ({P, Q}) -> P*Q > end({X,Y}), > > B = fun({0, Q}) -> Q; > ({P, Q}) -> P+Q > end({X,Y}), > {A,B}. You do not need those tuples. f1(X, Y) -> A = (fun (0, Q) -> Q ; (P, Q) -> P*Q end)(X, Y), B = (fun (0, Q) -> Q ; (P, Q) -> P+Q end)(X, Y). I would write {AuthP, LocalizationHash} = case maps:get(authp, Record) of md5 -> {usmHMACMD5AuthProtocol, md5}; sha -> {usmHMACSHAAuthProtocol, sha}; usmHMACMD5AuthProtocol -> {usmHMACMD5AuthProtocol, md5}; usmHMACSHAAuthProtocol -> {usmHMACSHAAuthProtocol, sha} end, as Localization_Hash = case maps:get(authp, Record) of md5 -> md5 ; sha -> sha ; usm_HMAC_MD5_Auth_Protocol -> md5 ; usm_HMAC_SHA_Auth_Protocol -> sha end, Auth_Protocol = case Localization_Hash of md5 -> usm_HMAC_MD5_Auth_Protocol ; sha -> usm_HMAC_SHA_Auth_Protocol end, From erlang@REDACTED Tue Mar 4 21:14:10 2014 From: erlang@REDACTED (Martin Schut) Date: Tue, 04 Mar 2014 21:14:10 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> Message-ID: Why not put the extraction of the AuthKey and PrivKey to separate functions. I'd probably do that to a lot of other case statements as well. This leaves readable code. I do not know why you want it to be concise. Readable would be my first requirement, concise a secondary. Best regards, --Martin > I've been reflecting on this some more, and have realized one of my > biases on the subject comes from the way C/C++ manages scope: Anything > >within curly braces, whether it is a function, if, while, for, try, or > catch, is a scope which encapsulates all declarations within. This > uniform rule >makes it easier to reason about code, and not having it in > Erlang is, well, jarring to me. > > Now both Erlang and C/C++ can *read* variables from enclosing scopes, > but only C/C++ can *mutate* variables from enclosing scopes. Perhaps > >Erlang's case scoping rules are just a way to give similar powers to > affect the enclosing scope. > > > The actual clause that predicated all this is here: > https://gist.github.com/goertzenator/9347573 > > There are a lot of case expressions that leave unwanted bindings lying > around. I have to pay attention to use different binding names for each > to >avoid collisions. Specifically the AuthKey and PrivKey expressions > had collisions at first because they are nearly identical. The code > would be a >lot easier to reason about if I didn't have to look out for > such things. > > I tried putting this function together in various different ways, and > this way was the most concise, most readable, and most amenable to > future >tweaking. I normally don't tolerate clauses this long, but > breaking it up always seemed to compromise those things. > > > Thank you for your ideas Richard. I see I could also use funs directly > instead of cases. > > f1(X, Y) -> > A = fun({0, Q}) -> Q; > ({P, Q}) -> P*Q > end({X,Y}), > > B = fun({0, Q}) -> Q; > ({P, Q}) -> P+Q > end({X,Y}), > {A,B}. > > Regards, > Dan. > > > > On Mon, Mar 3, 2014 at 3:23 PM, Richard A. O'Keefe > wrote: >> >> On 4/03/2014, at 8:07 AM, Daniel Goertzen wrote: >> >>> Hmm, fun wrapping could be the basis of hygienic-case parse >>> transform. I'll have to see what the performance overhead of a fun >>> wrap is like. >>> >>> The example I gave is contrived and a bit weak I guess. In my most >>> recent run-in with this issue there were a lot of bindings from the >>> enclosing >>scope that were used, so breaking things out to top level >>> functions would not always be a good option. >> >> I see a non-sequitur there. >> >> Simplified examples are great for revealing bugs. >> >> For illuminating style concerns, NOTHING beats REAL code. >> >> "There were a lot of bindings from the enclosing scope" >> is already a warning sign that the code should be restructured. >> >>> Funs would be better, but add clutter and maybe runtime overhead. >> >> There is currently some run-time overhead. >> In R16B03-1, the compiler still does not optimise >> >> (fun (...) -> ... ... end)(...) >> >> by turning it into the equivalent of an SML let ... in ... end >> form, but there is no particular reason why it couldn't. >> >> Whether you can _measure_ the overhead in a real application >> is another matter entirely. >> >> Splitting out little functions and then telling the compiler >> to inline them might well have the least overhead of all. >> >> > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Mar 4 23:27:32 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 4 Mar 2014 23:27:32 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> Message-ID: Note that there is also one scope per generator input, which does not spill into the generator pattern nor the rest of the comprehension. -- Anthony Ramine Le 4 mars 2014 ? 22:49, Richard A. O'Keefe a ?crit : > - a list comprehension is a scope From dszoboszlay@REDACTED Tue Mar 4 23:41:19 2014 From: dszoboszlay@REDACTED (=?utf-8?Q?Szoboszlay_D=C3=A1niel?=) Date: Tue, 04 Mar 2014 23:41:19 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> Message-ID: On Tue, 04 Mar 2014 22:49:12 +0100, Richard A. O'Keefe wrote: > No, you are still thinking in C/C++ terms. > There are three things in Erlang that are scopes: > - a function clause is a scope > - a 'fun' is a scope > - a list comprehension is a scope Personally, I feel that these rules are neither convenient nor intuitive. Mainly due to the last one, about the list comprehensions. I *know* that list comprehensions are implemented with funs, hence the scoping, but it still *looks like* a big exception from the "one function, one scope" rule. And if you have background in any C-descendant language you would almost certainly feel that cases, ifs, trys, begins etc. shall have their own scopes too. Some examples where I really miss them: foo(Dict) -> Value = case orddict:find(foo, Dict) of {ok, Value} -> Value; error -> calculate_very_expensive_default_value() end, ... Sorry, variable 'Value' is unsafe in 'case', please rename your internal variable to 'Value1' or refactor this humble four-liner into a get_foo_from_orddict/1 function, whichever you feel more inconvenient. And we aren't done yet, let's add my favorite, the error-handling mess-up to the mix! foo() -> ... V1 = case bar() of {ok, Bar} -> Bar; {error, Reason} -> lager:error("SOS ~p", [Reason]), BarDefault end, V2 = case baz() of {ok, Baz} -> Baz; {error, Reason} -> lager:error("SOS ~p", [Reason]), BazDefault end, ... Of course I know real programmers never put two cases in the same function, but lazy people tend to. And lazy people also tend to use convenient variable names like Reason or Error in error branches. And than get compile errors or random badmatch crashes, depending on their code's complexity. The only benefit I see of *not starting* a new scope within a case is that you can do this: foo() -> case bar() of 1 -> X = 1; 2 -> X = 2; _ -> X = 0 end, bar(X). Which, in my opinion, is less readable than: foo() -> X = case bar() of 1 -> 1; 2 -> 2; _ -> 0 end, bar(X). I hope these examples may pass the "this code is too trivial/ugly to even notice your actual problem" filter with better luck than the previous nominee. :) Cheers, Daniel From pablo.platt@REDACTED Tue Mar 4 23:46:03 2014 From: pablo.platt@REDACTED (pablo platt) Date: Wed, 5 Mar 2014 00:46:03 +0200 Subject: [erlang-questions] DTLS example Message-ID: Hi, I'm trying to use the dtls prototype from: https://github.com/RoadRunnr/otp/tree/new_crypto_dtls I'm getting an exception when trying to use a simple example. What am I doing wrong? Is there an example how to use this modified ssl app with R16 or R17? I see that the branch adds crypto:algorithms/0 Is it the only modification needed except for the ssl app? Thanks test --------------- init() -> Port = 5070, Cert = filename:join([dtls:priv_dir(webrtc), "cert.pem"]), Key = filename:join([dtls:priv_dir(webrtc), "key.pem"]), Options = [{versions, ['dtlsv1.2', dtlsv1]}, {cb_info, ssl_udp}, {reuseaddr, true}, {active, false}, {certfile,Cert}, {keyfile, Key}], {ok, LSocket} = ssl:listen(Port,Options), spawn(?MODULE, accept, [LSocket]), {ok, #state{}}. accept(LSocket) -> {ok, Socket} = ssl_udp:accept(LSocket, 5000), Pid = spawn(?MODULE, loop, [Socket]), ssl:controlling_process(Socket, Pid), accept(LSocket). loop(Socket) -> inet:setopts(Socket, [{active, once}]), receive R -> error_logger:info_msg("~p~n", [R]), loop(Socket) end. exception --------------------------- {'EXIT', {function_clause, [{ssl_udp,call, [{sslsocket,nil, {<0.103.0>, {config, {ssl_options, [{254,253},{254,255}], verify_none, {#Fun,[]}, false,false,false,undefined,1, <<"cert.pem">>, undefined, <<"key.pem">>, undefined,[],undefined,<<>>,undefined,undefined, undefined,undefined,undefined, [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, <<0,107>>, <<0,106>>, <<0,61>>, <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, <<0,103>>, <<0,64>>, <<0,60>>, <<"?\n">>, <<192,20>>, <<0,57>>, <<0,56>>, <<192,5>>, <<192,15>>, <<0,53>>, <<"?\b">>, <<192,18>>, <<0,22>>, <<0,19>>, <<192,3>>, <<"?\r">>, <<0,10>>, <<"?\t">>, <<192,19>>, <<0,51>>, <<0,50>>, <<192,4>>, <<192,14>>, <<0,47>>, <<192,7>>, <<192,17>>, <<0,5>>, <<0,4>>, <<0,21>>, <<192,2>>, <<"?\f">>, <<0,9>>], #Fun,true,268435456,false,undefined, undefined,false,undefined,undefined}, [{reuseaddr,true},{active,false}], {socket_options,list,0,0,0,false}, [{reuseaddr,true}, {packet_size,0}, {packet,0}, {header,0}, {active,false}, {mode,binary}], {ssl_udp,ssl_udp,udp_closed,udp_error}}}}, accept,10000,infinity], [{file,"ssl_udp.erl"},{line,149}]}, {dtls_test,accept,1, [{file,"src/dtls_test.erl"},{line,70}]}]}} -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Mar 4 23:48:43 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 4 Mar 2014 23:48:43 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> Message-ID: <646FE430-1289-40B5-A924-9AD2E57CD11F@gmail.com> Hello, This would be better written as: maybe_log_error(Default, Fun) -> case Fun() of {ok,Result} -> Result; {error,Reason} -> lager:error("SOS ~p", [Reason]), Default end. foo() -> ... V1 = maybe_log_error(BarDefault, fun bar/0), V2 = maybe_log_error(BazDefault, fun baz/0), ... Sorry, but no luck for the filter. -- Anthony Ramine Le 4 mars 2014 ? 23:41, Szoboszlay D?niel a ?crit : > On Tue, 04 Mar 2014 22:49:12 +0100, Richard A. O'Keefe wrote: > >> No, you are still thinking in C/C++ terms. >> There are three things in Erlang that are scopes: >> - a function clause is a scope >> - a 'fun' is a scope >> - a list comprehension is a scope > > Personally, I feel that these rules are neither convenient nor intuitive. Mainly due to the last one, about the list comprehensions. I *know* that list comprehensions are implemented with funs, hence the scoping, but it still *looks like* a big exception from the "one function, one scope" rule. And if you have background in any C-descendant language you would almost certainly feel that cases, ifs, trys, begins etc. shall have their own scopes too. > > Some examples where I really miss them: > > foo(Dict) -> > Value = case orddict:find(foo, Dict) of > {ok, Value} -> Value; > error -> calculate_very_expensive_default_value() > end, > ... > > Sorry, variable 'Value' is unsafe in 'case', please rename your internal variable to 'Value1' or refactor this humble four-liner into a get_foo_from_orddict/1 function, whichever you feel more inconvenient. > > And we aren't done yet, let's add my favorite, the error-handling mess-up to the mix! > > foo() -> > ... > V1 = case bar() of > {ok, Bar} -> > Bar; > {error, Reason} -> > lager:error("SOS ~p", [Reason]), > BarDefault > end, > V2 = case baz() of > {ok, Baz} -> > Baz; > {error, Reason} -> > lager:error("SOS ~p", [Reason]), > BazDefault > end, > ... > > Of course I know real programmers never put two cases in the same function, but lazy people tend to. And lazy people also tend to use convenient variable names like Reason or Error in error branches. And than get compile errors or random badmatch crashes, depending on their code's complexity. > > The only benefit I see of *not starting* a new scope within a case is that you can do this: > > foo() -> > case bar() of > 1 -> X = 1; > 2 -> X = 2; > _ -> X = 0 > end, > bar(X). > > Which, in my opinion, is less readable than: > > foo() -> > X = case bar() of > 1 -> 1; > 2 -> 2; > _ -> 0 > end, > bar(X). > > I hope these examples may pass the "this code is too trivial/ugly to even notice your actual problem" filter with better luck than the previous nominee. :) > > Cheers, > Daniel > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From n.oxyde@REDACTED Tue Mar 4 23:57:11 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 4 Mar 2014 23:57:11 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <646FE430-1289-40B5-A924-9AD2E57CD11F@gmail.com> Message-ID: My point still stands, don?t put such complicated code in the middle of nowhere, why would you call calculate_very_expensive_default_value() here in foo/1? Put the nastiness away from main path. -- Anthony Ramine Le 4 mars 2014 ? 23:55, Szoboszlay D?niel a ?crit : > But what if BazDefault is based on my trusty calculate_very_expensive_default_value(), and the error would have to be logged on warning level with a different format string? :P > > Daniel > > On Tue, 04 Mar 2014 23:48:43 +0100, Anthony Ramine wrote: > >> Hello, >> >> This would be better written as: >> >> maybe_log_error(Default, Fun) -> >> case Fun() of >> {ok,Result} -> >> Result; >> {error,Reason} -> >> lager:error("SOS ~p", [Reason]), >> Default >> end. >> >> foo() -> >> ... >> V1 = maybe_log_error(BarDefault, fun bar/0), >> V2 = maybe_log_error(BazDefault, fun baz/0), >> ... >> >> Sorry, but no luck for the filter. From tony@REDACTED Wed Mar 5 00:23:12 2014 From: tony@REDACTED (Tony Rogvall) Date: Wed, 5 Mar 2014 00:23:12 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> Message-ID: <63C1907D-54AC-4D01-BB07-523243CDCFA3@rogvall.se> Of course. use list comprehensions! or? This is kind of fun. Check the generated beam code for this module (using R16B02 right now) -module(compcase). -compile(export_all). -compile(inline). -compile({inline_size, 100}). -compile({inline_unroll, 2}). f(X,Y) -> [A] = [case {X,Y} of {0,Q} -> Q; {P,Q} -> P+Q end || _ <- [[]]], [B] = [case {X,Y} of {0,Q} -> Q; {P,Q} -> P*Q end || _ <- [[]]], {A,B}. g(X,Y) -> A = fun({0,Q}) -> Q; ({P,Q}) -> P+Q end({X,Y}), B = fun({0,Q}) -> Q; ({P,Q}) -> P*Q end({X,Y}), {A,B}. On 4 mar 2014, at 23:27, Anthony Ramine wrote: > Note that there is also one scope per generator input, which does not spill into the generator pattern nor the rest of the comprehension. > > -- > Anthony Ramine > > Le 4 mars 2014 ? 22:49, Richard A. O'Keefe a ?crit : > >> - a list comprehension is a scope > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Mar 5 03:52:22 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 5 Mar 2014 15:52:22 +1300 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> Message-ID: On 5/03/2014, at 11:41 AM, Szoboszlay D?niel wrote: > On Tue, 04 Mar 2014 22:49:12 +0100, Richard A. O'Keefe wrote: > >> No, you are still thinking in C/C++ terms. >> There are three things in Erlang that are scopes: >> - a function clause is a scope >> - a 'fun' is a scope >> - a list comprehension is a scope > > Personally, I feel that these rules are neither convenient nor intuitive. Mainly due to the last one, about the list comprehensions. I *know* that list comprehensions are implemented with funs, hence the scoping, Wrong. Yes, list comprehensions *happen* to be implemented as calls to out-of-line functions, but the *necessity* for list comprehensions to be separate scopes falls directly out of their semantics. Suppose it were otherwise. R = [(Y = f(X), Y) || X <- L]. What value would X have after the comprehension - if L = []? - if L = [1]? - if L = [1,2]? What value would Y have? The key thing is that X and Y get _different_ values on each iteration, and Erlang variables being immutable, the only way we can make sense of that is if each iteration gets its _own_ X and Y. > And if you have background in any C-descendant language you would almost certainly feel that cases, ifs, trys, begins etc. shall have their own scopes too. Surely C counts as a C-descendant language. And in C, 'switch' is *not* a scope. Consider: int goo(int n) { switch (n) if (0) case 1: return -27; else if (0) case 2: return 43; else if (0) default: return 122; } } #include int main(void) { int i; for (i = 0; i < 4; i++) printf("%d => %d\n", i, goo(i)); return 0; } Yep. That's legal (classic C, C89, C99). I don't have a copy of the C11 standard, but I'd be pretty surprised if it wasn't legal C11. In Classic C and C89, *none* of 'if', 'switch', 'while', 'do', and 'for' introduce new scopes. In C99, it's clear from 6.8.4 that 'if' and 'switch' do *NOT* introduce new scopes and it is clear from 6.8.5 that 'while' and 'do' do *NOT* introduce new scopes. In Classic C and C89 the *ONLY* construction that introduces a new scope is '{...}'. C99 adds iteration-statement: ... for ( declaration expr-opt ; expr-opt ) statement which *is* a new scope, but in C this is very exceptional. Conversely, if switch cases were scopes, you'd expect void goo(int n) { switch (n) { case 1: int x = 1; x++; case 2: int x = 2; x++; default: int x = 3; x--; } } to be legal, but it isn't. Change this to void goo(int n) { switch (n) { case 1:; int x = 1; x++; case 2:; int x = 2; x++; default:; int x = 3; x--; } } and it *still* isn't legal, because the whole body of the switch is a *single* scope and you are not allowed more than one declaration of x within it. I would therefore expect a C programmer to *expect* that occurrences of a variable in two cases would be the same variable. It turns out that the entire body of a switch is a *single* scope, and the example isn't legal Java either. Looking at the Java Language Specification for Java 7, chapter 14, we find that 'if' and 'while' and 'do' do *NOT* introduce new scopes, that 'for' may but need not, that 'catch' does, but that 'try' does only in the 14.20.3 try-with-resources form. So in Java, which is surely a 'C-descendant' language, selection statements do NOT introduce new scopes and any Java progammer who thought they did, or who expected selection statements in some other language to do so on the strength of what Java does, would be exposed as not understanding Java. > > Some examples where I really miss them: > > foo(Dict) -> > Value = case orddict:find(foo, Dict) of > {ok, Value} -> Value; > error -> calculate_very_expensive_default_value() > end, > ... So don't do that. If the compiler *did* allow that, it would be as confusing as all-get-out for suffering human beings trying to make sense of it. It is a blessing that abominations like this are blocked. This example is obviously not real code. We have already seen in this thread that the *real* code that inspired is would be hugely improved by being broken into little functions, whereupon the problem disappears. > And we aren't done yet, let's add my favorite, the error-handling mess-up to the mix! > > foo() -> > ... > V1 = case bar() of > {ok, Bar} -> > Bar; > {error, Reason} -> > lager:error("SOS ~p", [Reason]), > BarDefault > end, > V2 = case baz() of > {ok, Baz} -> > Baz; > {error, Reason} -> > lager:error("SOS ~p", [Reason]), > BazDefault > end, > ... Again, this is totally unreal code. Let me offer an equally unreal alternative: safe_bar() -> case bar() of {ok, Bar} -> Bar ; {error, Reason} -> lager:error("SOS ~p", [Reason]), BarDefault end. safe_baz() -> case baz() of {ok, Baz} -> Baz ; {error, Reason} -> lager:error("SOS ~p", [Reason]), BazDefault end. foo() -> ... V1 = safe_bar(), V2 = safe_baz(), .. > Of course I know real programmers never put two cases in the same function, but lazy people tend to. And lazy people also tend to use convenient variable names like Reason or Error in error branches. Real programmers who put multiple cases in the same clause take care to use disjoint names SO THAT HUMAN BEINGS WILL NOT BE CONFUSED. Lazy programmers who over-use names like Value, Error, Reason deserve to be forced to maintain code written by other lazy programmers. > The only benefit I see of *not starting* a new scope within a case is that you can do this: > > foo() -> > case bar() of > 1 -> X = 1; > 2 -> X = 2; > _ -> X = 0 > end, > bar(X). > > Which, in my opinion, is less readable than: > > foo() -> > X = case bar() of > 1 -> 1; > 2 -> 2; > _ -> 0 > end, > bar(X). You are forgetting that there may be multiple variables involved. Packaging them up in tuples just so that you can unpack them again? Feh. The thing is that Erlang is what it is and is not something else. Criticising Erlang for not being like something else (especially when it turns out that the something else is not in fact like that either) is silly. Before 'fun' and list comprehensions were added to Erlang the rule was simple and uniform: one name, one variable, everywhere in a function clause. 'fun' and list comprehensions break that rule because they *have* to, but even they try not to break it any more than they can help. > > I hope these examples may pass the "this code is too trivial/ugly to even notice your actual problem" filter with better luck than the previous nominee. :) Your examples are profoundly unreal. Real examples could well be informative. So far, all you have shown is that lazy programmers can screw up and the compiler sometimes notices. So this is news, already? From ok@REDACTED Wed Mar 5 04:00:36 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 5 Mar 2014 16:00:36 +1300 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> Message-ID: <9DBC442A-7138-4A95-90A9-0419983CDA9C@cs.otago.ac.nz> On 5/03/2014, at 5:10 AM, Daniel Goertzen wrote: > I've been reflecting on this some more, and have realized one of my biases on the subject comes from the way C/C++ manages scope: Anything within curly braces, whether it is a function, if, while, for, try, or catch, is a scope which encapsulates all declarations within. This uniform rule makes it easier to reason about code, and not having it in Erlang is, well, jarring to me. This is rather confusingly worded. In Classic C and C89, new scopes were introduced by '{...}' and only by '{...}. There was a proposal years ago to add begin within end to Erlang with the idea that variable bindings introduced in would be visible in but not outside, while variable bindings in would be visible outside as usual. I don't know why that was rejected. From kris_prieb@REDACTED Wed Mar 5 07:42:16 2014 From: kris_prieb@REDACTED (Kris Prieb) Date: Wed, 5 Mar 2014 00:42:16 -0600 Subject: [erlang-questions] unable to build valgrind-enabled erlang runtime In-Reply-To: <5315AD74.7040205@ericsson.com> References: <53149598.7040501@erix.ericsson.se> <5315AD74.7040205@ericsson.com> Message-ID: Ok, I've carried out the steps recommended, and valgrind-enabled emulator is now up and running. Thank you! Kris On Tue, Mar 4, 2014 at 4:39 AM, Sverker Eriksson < sverker.eriksson@REDACTED> wrote: > You have to disable hipe: > > ./configure --disable-hipe > > > After successful build, set > export VALGRIND_LOG_DIR=/my/valgrind/log/dir > export VALGRIND_MISC_FLAGS="--suppressions=$ERL_TOP/erts/ > emulator/valgrind/suppress.standard --show-possibly-lost=no" > > and run with > $ERL_TOP/bin/cerl -valgrind > > /Sverker > > > On 03/04/2014 09:45 AM, Kris Prieb wrote: > >> Hello List and Sverker, >> >> Thank you for your assistance. I did have valgrind installed prior to >> running configure, but not its source code. Installing the source code >> and >> running configure again did fix the problem of the missing include file >> just as you indicated. >> >> However, I am still unable to build the valgrind-enabled emulator due to >> occurence of other errors. After calling: >> >> env ERL_TOP=/home/ec2-user/otp_src_R16B02 make valgrind FLAVOR=smp >> >> I receive the following errors: >> >> ... >> ... >> obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_bif0.o:(.data+0x5b40): >> undefined reference to `nbif_emulate_fpe' >> obj/x86_64-unknown-linux-gnu/valgrind/smp/hipe_amd64_bifs.o: In function >> `nbif_handle_fp_exception': >> /home/ec2-user/otp_src_R16B02/erts/emulator/x86_64-unknown- >> linux-gnu/valgrind/smp/hipe_amd64_bifs.S:287: >> undefined reference to `erts_restore_fpu' >> collect2: ld returned 1 exit status >> make[1]: *** >> [/home/ec2-user/otp_src_R16B02/bin/x86_64-unknown- >> linux-gnu/beam.valgrind.smp] >> Error 1 >> make[1]: Leaving directory `/home/ec2-user/otp_src_R16B02/erts/emulator' >> >> >> Would appreciate any suggestions as to how to fix this. >> >> Kris >> >> >> On Mon, Mar 3, 2014 at 8:45 AM, Sverker Eriksson < >> sverker.eriksson@REDACTED> wrote: >> >> On 03/01/2014 12:12 AM, Kris Prieb wrote: >>> >>> Hello List, >>>> >>>> I am attempting to build a valgrind-enabled erlang runtime per: >>>> http://www.erlang.org/doc/installation_guide/INSTALL.html#id72660 >>>> >>>> My platform is an amazon linux machine image on ec2 on which I have >>>> already >>>> installed an erlang disribution from source. >>>> >>>> I entered the following at the command prompt: >>>> >>>> [ec2-user@REDACTED emulator]$ env >>>> ERL_TOP=/home/ec2-user/otp_src_R16B02 FLAVOR=smp make valgrind >>>> FLAVOR=$FLAVOR >>>> >>>> The following was returned: >>>> >>>> make -f x86_64-unknown-linux-gnu/Makefile TYPE=valgrind >>>> can't open x86_64-unknown-linux-gnu/valgrind/plain/erl_compile_flags.h >>>> for >>>> writing at utils/make_compiler_flags line 65. >>>> make[1]: Entering directory `/home/ec2-user/otp_src_ >>>> R16B02/erts/emulator' >>>> if utils/gen_git_version x86_64-unknown-linux-gnu/gen_git_version.mk; >>>> then >>>> touch beam/erl_bif_info.c; fi >>>> *** valgrind emulator disabled by configure - omitted target all >>>> make[1]: Leaving directory `/home/ec2-user/otp_src_ >>>> R16B02/erts/emulator' >>>> >>>> >>>> What have I done wrong here? Do I have to run "configure" with special >>>> arguments before building valgrind-enabled runtime? >>>> >>>> Any help would be much appreciated! >>>> Kris >>>> >>>> >>>> If configure does not find a working valgrind, that target will be >>> disabled. >>> >>> Search for "valgrind" in erts/config.log to see what failed. It probably >>> failed to compile #include . >>> >>> If your valgrind is installed in a non-standard place, point it out to >>> configure with CPPFLAGS=-I/my/valgrind/install/dir/include. >>> >>> /Sverker, Erlang/OTP >>> >>> >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 249505968@REDACTED Wed Mar 5 10:04:53 2014 From: 249505968@REDACTED (=?gb18030?B?99L30Q==?=) Date: Wed, 5 Mar 2014 17:04:53 +0800 Subject: [erlang-questions] =?gb18030?b?u9i4tKO6ICBIb3cgdG8gaW52ZXN0aWdh?= =?gb18030?q?te_a_CPU_Load_problem_=3F?= In-Reply-To: References: Message-ID: hmm, we use "top" in linux.... It's that trustable? And etop show that not a process has take a lot of reds (etop_txt is top 3)..... ------------------ ???? ------------------ ???: "Philip Clarke";; ????: 2014?3?5?(???) ??1:33 ???: "??"<249505968@REDACTED>; ??: "erlang-questions"; ??: Re: [erlang-questions] How to investigate a CPU Load problem ? Hi, I wonder how you measured CPU load ? If your processes have short message queues, then that is good news at least. I would suggest looking at your etop output to see where most reductions are spent. Then if that does not help, fprof will get you very detailed information. Good luck Philip On Tue, Mar 4, 2014 at 1:51 PM, ?? <249505968@REDACTED> wrote: Our Project just get in some trouble.... The CPU Load seems too high (10 for 8 core CPU). we use etop and find out that no any process has more than 1 message. Now I don't know how to investigate next. Could some one give me some advice? _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From pablo.platt@REDACTED Wed Mar 5 10:07:25 2014 From: pablo.platt@REDACTED (pablo platt) Date: Wed, 5 Mar 2014 11:07:25 +0200 Subject: [erlang-questions] DTLS example In-Reply-To: References: Message-ID: Now I'm getting an error: {error,{options,{ciphers,[]}}} When calling: Options = [{versions, ['dtlsv1.2', dtlsv1]}, {cb_info, ssl_udp}, {reuseaddr, true}, {active, false}, {certfile,Cert}, {keyfile, Key}], {ok, LSocket} = ssl:listen(Port, Options). Do I need to pass ciphers to the ssl options? On Wed, Mar 5, 2014 at 12:46 AM, pablo platt wrote: > Hi, > > I'm trying to use the dtls prototype from: > https://github.com/RoadRunnr/otp/tree/new_crypto_dtls > > I'm getting an exception when trying to use a simple example. > What am I doing wrong? > > Is there an example how to use this modified ssl app with R16 or R17? > I see that the branch adds crypto:algorithms/0 > Is it the only modification needed except for the ssl app? > > Thanks > > test > --------------- > > init() -> > Port = 5070, > Cert = filename:join([dtls:priv_dir(webrtc), "cert.pem"]), > Key = filename:join([dtls:priv_dir(webrtc), "key.pem"]), > Options = [{versions, ['dtlsv1.2', dtlsv1]}, > {cb_info, ssl_udp}, > {reuseaddr, true}, > {active, false}, > {certfile,Cert}, > {keyfile, Key}], > {ok, LSocket} = ssl:listen(Port,Options), > spawn(?MODULE, accept, [LSocket]), > {ok, #state{}}. > > accept(LSocket) -> > {ok, Socket} = ssl_udp:accept(LSocket, 5000), > Pid = spawn(?MODULE, loop, [Socket]), > ssl:controlling_process(Socket, Pid), > accept(LSocket). > > loop(Socket) -> > inet:setopts(Socket, [{active, once}]), > receive > R -> > error_logger:info_msg("~p~n", [R]), > loop(Socket) > end. > > > exception > --------------------------- > {'EXIT', > {function_clause, > [{ssl_udp,call, > [{sslsocket,nil, > {<0.103.0>, > {config, > {ssl_options, > [{254,253},{254,255}], > verify_none, > {#Fun,[]}, > false,false,false,undefined,1, > <<"cert.pem">>, > undefined, > <<"key.pem">>, > undefined,[],undefined,<<>>,undefined,undefined, > undefined,undefined,undefined, > [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, > <<0,107>>, > <<0,106>>, > <<0,61>>, > <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, > <<0,103>>, > <<0,64>>, > <<0,60>>, > <<"?\n">>, > <<192,20>>, > <<0,57>>, > <<0,56>>, > <<192,5>>, > <<192,15>>, > <<0,53>>, > <<"?\b">>, > <<192,18>>, > <<0,22>>, > <<0,19>>, > <<192,3>>, > <<"?\r">>, > <<0,10>>, > <<"?\t">>, > <<192,19>>, > <<0,51>>, > <<0,50>>, > <<192,4>>, > <<192,14>>, > <<0,47>>, > <<192,7>>, > <<192,17>>, > <<0,5>>, > <<0,4>>, > <<0,21>>, > <<192,2>>, > <<"?\f">>, > <<0,9>>], > > #Fun,true,268435456,false,undefined, > undefined,false,undefined,undefined}, > [{reuseaddr,true},{active,false}], > {socket_options,list,0,0,0,false}, > [{reuseaddr,true}, > {packet_size,0}, > {packet,0}, > {header,0}, > {active,false}, > {mode,binary}], > {ssl_udp,ssl_udp,udp_closed,udp_error}}}}, > accept,10000,infinity], > [{file,"ssl_udp.erl"},{line,149}]}, > {dtls_test,accept,1, > [{file,"src/dtls_test.erl"},{line,70}]}]}} > -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Wed Mar 5 10:37:09 2014 From: txrev319@REDACTED (t x) Date: Wed, 5 Mar 2014 01:37:09 -0800 Subject: [erlang-questions] erl -sname, emacs, connect to repl Message-ID: Hi, Given: machine name: server user account: x x@REDACTED$ erl -sname gandalf ## we now have an erl running Question: Now, from emacs, how do I tell emacs "connect a repl to the node with sname gandalf" instead of "fire up a new session of erl" ? Rephrase: To rephrase the above, I don't want emacs to create a new erl session. Instead, I want it to connect to an existing erlang session. Thanks! From thomasl_erlang@REDACTED Wed Mar 5 12:18:01 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 5 Mar 2014 03:18:01 -0800 (PST) Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> Message-ID: <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> However, note that you don't want to write that sort of code anyway! However, note that that code also is problematic in another way.? What happens if we modify the second clause of your example to make Value safe?? Value =? >? ?case orddict:find(foo, Dict) of >? ? ?{ok, Value} -> Value; >? ? ?error -> Value = calculate_very_expensive_default_value() >? ?end How does this evaluate? If orddict finds foo, variable Value is bound in {ok, Value} in the first clause of the case. Then that value is returned from the case clause and MATCHED WITH the binding of the variable Value (itself). Recall that, since Value has been bound in the case clause previously, "Value = case ... end" means matching, not just variable binding. The same reasoning goes for the second clause.? The basic problem is that the code above mixes two ways of writing erlang. It works, but only by accident, and only at the cost of needlessly walking Value a number of times matching itself. (See the end of this mail for the underlying problem, though.) Here are the two ways to get it right. First, the old way of writing the same code, which these days give warnings about exported variables: case orddict:find(foo, Dict) of >? {ok, Value} -> Value >? ... >end, >... %% use Value afterwards Note that there's no enclosing "Value = case ... end" up there.?Then the new way (which is what most of us use now): Value = >? ?case orddict:find(foo, Dict) of >? ? ? {ok, Val} -> Val; ? ?%% fresh variable >? ? ? ... >? ?end, >... %% use Value, but not Val In the larger scheme of things: The way I see it, the feature of implicit variable matching is more trouble than it's worth. Warnings about such matches would catch this kind of problems. Best, Thomas On Tuesday, March 4, 2014 11:41 PM, Szoboszlay D?niel wrote: >Some examples where I really miss them: > >foo(Dict) -> >? ? Value = case orddict:find(foo, Dict) of >? ? ? ? ? ? ? ? {ok, Value} -> Value; >? ? ? ? ? ? ? ? error? ? ? -> calculate_very_expensive_default_value() >? ? ? ? ? ? end, >? ? ... > >Sorry, variable 'Value' is unsafe in 'case', please rename your internal? >variable to 'Value1' or refactor this humble four-liner into a? >get_foo_from_orddict/1 function, whichever you feel more inconvenient. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Wed Mar 5 12:20:43 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 5 Mar 2014 03:20:43 -0800 (PST) Subject: [erlang-questions] case expression scope In-Reply-To: <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> Message-ID: <1394018443.61433.YahooMailNeo@web140102.mail.bf1.yahoo.com> (The beginning of that mail looks like Yahoo did a remix of multiple drafts, but I think the rest is okay. Sorry.) Best, Thomas On Wednesday, March 5, 2014 12:18 PM, Thomas Lindgren wrote: > >However, note that you don't want to write that sort of code anyway! >However, note that that code also is problematic in another way.? > > >What happens if we modify the second clause of your example to make Value safe?? >Value =? >>? ?case orddict:find(foo, Dict) of >>? ? ?{ok, Value} -> Value; >>? ? ?error -> Value = calculate_very_expensive_default_value() >>? ?end >How does this evaluate? If orddict finds foo, variable Value is bound in {ok, Value} in the first clause of the case. Then that value is returned from the case clause and MATCHED WITH the binding of the variable Value (itself). Recall that, since Value has been bound in the case clause previously, "Value = case ... end" means matching, not just variable binding. The same reasoning goes for the second clause.? > > > >The basic problem is that the code above mixes two ways of writing erlang. It works, but only by accident, and only at the cost of needlessly walking Value a number of times matching itself. (See the end of this mail for the underlying problem, though.) > > >Here are the two ways to get it right. First, the old way of writing the same code, which these days give warnings about exported variables: >case orddict:find(foo, Dict) of >>? {ok, Value} -> Value >>? ... >>end, >>... %% use Value afterwards >Note that there's no enclosing "Value = case ... end" up there.?Then the new way (which is what most of us use now): >Value = >>? ?case orddict:find(foo, Dict) of >>? ? ? {ok, Val} -> Val; ? ?%% fresh variable >>? ? ? ... >>? ?end, >>... %% use Value, but not Val > > >In the larger scheme of things: The way I see it, the feature of implicit variable matching is more trouble than it's worth. Warnings about such matches would catch this kind of problems. > > >Best, >Thomas > > >On Tuesday, March 4, 2014 11:41 PM, Szoboszlay D?niel wrote: > > > >>Some examples where I really miss them: >> >>foo(Dict) -> >>? ? Value = case orddict:find(foo, Dict) of >>? ? ? ? ? ? ? ? {ok, Value} -> Value; >>? ? ? ? ? ? ? ? error? ? ? -> calculate_very_expensive_default_value() >>? ? ? ? ? ? end, >>? ? ... >> >>Sorry, variable 'Value' is unsafe in 'case', please rename your internal? >>variable to 'Value1' or refactor this humble four-liner into a? >>get_foo_from_orddict/1 function, whichever you feel more inconvenient. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Mar 5 12:25:06 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 5 Mar 2014 12:25:06 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> Message-ID: <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> The compile option is warn_export_vars: Causes warnings to be emitted for all implicitly exported variables referred to after the primitives where they were first defined. No warnings for exported variables unless they are referred to in some pattern, which is the default, can be selected by the option nowarn_export_vars. -- Anthony Ramine Le 5 mars 2014 ? 12:18, Thomas Lindgren a ?crit : > In the larger scheme of things: The way I see it, the feature of implicit variable matching is more trouble than it's worth. Warnings about such matches would catch this kind of problems. > From simon@REDACTED Wed Mar 5 13:56:47 2014 From: simon@REDACTED (Simon MacMullen) Date: Wed, 05 Mar 2014 12:56:47 +0000 Subject: [erlang-questions] eldap using binary() rather than string() in Erlang 17.0 rc2? Message-ID: <53171F0F.90606@rabbitmq.com> Using R16B01: 1> {ok, LDAP} = eldap:open(["localhost"], []). {ok,<0.34.0>} 2> eldap:search(LDAP, [{base, "cn=Simon MacMullen,ou=People,dc=example,dc=com"},{filter, eldap:present("objectClass")}, {attributes, ["description"]}]). {ok,{eldap_search_result, [{eldap_entry, "cn=Simon MacMullen,ou=people,dc=example,dc=com", [{"description",["can-declare-queues"]}]}], []}} So the attribute key/values come back as lists. Using 17.0 rc2: 1> {ok, LDAP} = eldap:open(["localhost"], []). {ok,<0.34.0>} 2> eldap:search(LDAP, [{base, "cn=Simon MacMullen,ou=People,dc=example,dc=com"},{filter, eldap:present("objectClass")}, {attributes, ["description"]}]). {ok,{eldap_search_result, [{eldap_entry, <<"cn=Simon MacMullen,ou=people,dc=example,dc=com">>, [{<<"description">>,[<<"can-declare-queues">>]}]}], []}} Now they come back as binaries. Is this intentional or a bug? Note that in either case if I give attribute names as binaries I get a crash: 3> eldap:search(LDAP, [{base, "cn=Simon MacMullen,ou=People,dc=example,dc=com"},{filter, eldap:present("objectClass")}, {attributes, [<<"description">>]}]). {error,{function_clause,[{lists,thing_to_list, [<<"description">>], [{file,"lists.erl"},{line,601}]}, {lists,flatmap,2,[{file,"lists.erl"},{line,1248}]}, {lists,flatmap,2,[{file,"lists.erl"},{line,1248}]}, {eldap,'-v_attributes/1-fun-0-',1, [{file,"eldap.erl"},{line,850}]}, {lists,map,2,[{file,"lists.erl"},{line,1237}]}, {eldap,do_search_0,2,[{file,"eldap.erl"},{line,613}]}, {eldap,do_search,2,[{file,"eldap.erl"},{line,577}]}, {eldap,loop,2,[{file,"eldap.erl"},{line,425}]}]}} Cheers, Simon -- Simon MacMullen RabbitMQ, Pivotal From thomasl_erlang@REDACTED Wed Mar 5 15:33:42 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 5 Mar 2014 06:33:42 -0800 (PST) Subject: [erlang-questions] case expression scope In-Reply-To: <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> Message-ID: <1394030022.43533.YahooMailNeo@web140101.mail.bf1.yahoo.com> Thanks Anthony, that option warns for Value in the previous example because it's exported from the case, but not for the variable match that then occurs. I'd like to see a compiler option that warned about matching (bound variables occurring in patterns), which would catch other inadvertent reuse of variable names. Best, Thomas On Wednesday, March 5, 2014 2:40 PM, Anthony Ramine wrote: The compile option is warn_export_vars: > >??? Causes warnings to be emitted for all implicitly exported variables referred to after the primitives where they were first defined. No warnings for exported variables unless they are referred to in some pattern, which is the default, can be selected by the option nowarn_export_vars. > >-- >Anthony Ramine > > >Le 5 mars 2014 ? 12:18, Thomas Lindgren a ?crit : > >> In the larger scheme of things: The way I see it, the feature of implicit variable matching is more trouble than it's worth. Warnings about such matches would catch this kind of problems. >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Wed Mar 5 15:36:53 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Wed, 5 Mar 2014 09:36:53 -0500 Subject: [erlang-questions] erl -sname, emacs, connect to repl In-Reply-To: References: Message-ID: On Wed, Mar 5, 2014 at 4:37 AM, t x wrote: > Hi, > > > Given: > > machine name: server > user account: x > > x@REDACTED$ erl -sname gandalf > ## we now have an erl running > > > Question: > > Now, from emacs, how do I tell emacs "connect a repl to the node > with sname gandalf" instead of "fire up a new session of erl" ? If you give a prefix arg to erlang-shell, it reads arguments from the minibuffer. The tricky part is that you also have to set the TERM env var. So, if you type C-u M-x erlang-shell you'll be prompted with "Erlang command: " to enter the erlang shell command. At the prompt enter something like the following: erl -sname bilbo -remsh gandalf@REDACTED -env TERM vt100 The "-env TERM vt100" part is very important, since if you leave it off, the new node will start just fine but will silently fail to connect to the other node. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Mar 5 15:39:01 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 5 Mar 2014 15:39:01 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: <1394030022.43533.YahooMailNeo@web140101.mail.bf1.yahoo.com> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> <1394030022.43533.YahooMailNeo@web140101.mail.bf1.yahoo.com> Message-ID: What would you like to be warned about? I don?t get it. -- Anthony Ramine Le 5 mars 2014 ? 15:33, Thomas Lindgren a ?crit : > Thanks Anthony, that option warns for Value in the previous example because it's exported from the case, but not for the variable match that then occurs. I'd like to see a compiler option that warned about matching (bound variables occurring in patterns), which would catch other inadvertent reuse of variable names. > > Best, > Thomas > > > On Wednesday, March 5, 2014 2:40 PM, Anthony Ramine wrote: > The compile option is warn_export_vars: > > Causes warnings to be emitted for all implicitly exported variables referred to after the primitives where they were first defined. No warnings for exported variables unless they are referred to in some pattern, which is the default, can be selected by the option nowarn_export_vars. > > -- > Anthony Ramine > > Le 5 mars 2014 ? 12:18, Thomas Lindgren a ?crit : > > > In the larger scheme of things: The way I see it, the feature of implicit variable matching is more trouble than it's worth. Warnings about such matches would catch this kind of problems. > > > > From thomasl_erlang@REDACTED Wed Mar 5 16:38:21 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 5 Mar 2014 07:38:21 -0800 (PST) Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> <1394030022.43533.YahooMailNeo@web140101.mail.bf1.yahoo.com> Message-ID: <1394033901.48922.YahooMailNeo@web140104.mail.bf1.yahoo.com> Occurrences of bound variables in patterns. For example A, B, C, and D in these: ? {A, B} = f(X), ? {A, B} = f(Y), ? % A,B already bound ? C = g(Z), ? C = g(W), ? ? ? ?% C is already bound ? {D,D} = h(V) ? ? % D is bound then matched Best, Thomas On Wednesday, March 5, 2014 3:39 PM, Anthony Ramine wrote: What would you like to be warned about? I don?t get it. > >-- >Anthony Ramine > > >Le 5 mars 2014 ? 15:33, Thomas Lindgren a ?crit : > >> Thanks Anthony, that option warns for Value in the previous example because it's exported from the case, but not for the variable match that then occurs. I'd like to see a compiler option that warned about matching (bound variables occurring in patterns), which would catch other inadvertent reuse of variable names. >> >> Best, >> Thomas >> >> >> On Wednesday, March 5, 2014 2:40 PM, Anthony Ramine wrote: >> The compile option is warn_export_vars: >> >>? ? Causes warnings to be emitted for all implicitly exported variables referred to after the primitives where they were first defined. No warnings for exported variables unless they are referred to in some pattern, which is the default, can be selected by the option nowarn_export_vars. >> >> -- >> Anthony Ramine >> >> Le 5 mars 2014 ? 12:18, Thomas Lindgren a ?crit : >> >> > In the larger scheme of things: The way I see it, the feature of implicit variable matching is more trouble than it's worth. Warnings about such matches would catch this kind of problems. >> > >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Wed Mar 5 16:57:28 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 5 Mar 2014 16:57:28 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: <1394033901.48922.YahooMailNeo@web140104.mail.bf1.yahoo.com> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> <1394030022.43533.YahooMailNeo@web140101.mail.bf1.yahoo.com> <1394033901.48922.YahooMailNeo@web140104.mail.bf1.yahoo.com> Message-ID: <75537C7F-2E24-42E8-A39F-1E949446D57E@gmail.com> Why would you warn for this? It?s a feature. -- Anthony Ramine Le 5 mars 2014 ? 16:38, Thomas Lindgren a ?crit : > Occurrences of bound variables in patterns. For example A, B, C, and D in these: > > {A, B} = f(X), > {A, B} = f(Y), % A,B already bound > C = g(Z), > C = g(W), % C is already bound > {D,D} = h(V) % D is bound then matched > > Best, > Thomas > > > > On Wednesday, March 5, 2014 3:39 PM, Anthony Ramine wrote: > What would you like to be warned about? I don?t get it. > > -- > Anthony Ramine > > Le 5 mars 2014 ? 15:33, Thomas Lindgren a ?crit : > > > Thanks Anthony, that option warns for Value in the previous example because it's exported from the case, but not for the variable match that then occurs. I'd like to see a compiler option that warned about matching (bound variables occurring in patterns), which would catch other inadvertent reuse of variable names. > > > > Best, > > Thomas > > > > > > On Wednesday, March 5, 2014 2:40 PM, Anthony Ramine wrote: > > The compile option is warn_export_vars: > > > > Causes warnings to be emitted for all implicitly exported variables referred to after the primitives where they were first defined. No warnings for exported variables unless they are referred to in some pattern, which is the default, can be selected by the option nowarn_export_vars. > > > > -- > > Anthony Ramine > > > > Le 5 mars 2014 ? 12:18, Thomas Lindgren a ?crit : > > > > > In the larger scheme of things: The way I see it, the feature of implicit variable matching is more trouble than it's worth. Warnings about such matches would catch this kind of problems. > > > > > > > > > From aschultz@REDACTED Wed Mar 5 17:02:10 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Wed, 5 Mar 2014 16:02:10 +0000 (UTC) Subject: [erlang-questions] DTLS example In-Reply-To: References: Message-ID: <1386037318.38667.1394035330098.JavaMail.zimbra@tpip.net> Hi Pablo, ----- Original Message ----- > Now I'm getting an error: > {error,{options,{ciphers,[]}}} > > When calling: > > Options = [{versions, ['dtlsv1.2', dtlsv1]}, > {cb_info, ssl_udp}, > {reuseaddr, true}, > {active, false}, > {certfile,Cert}, > {keyfile, Key}], > {ok, LSocket} = ssl:listen(Port, Options). > > Do I need to pass ciphers to the ssl options? I seems that DTLS was never tested without the ciphers. option. In my project I use this list: {ciphers,[{ecdhe_rsa, aes_128_cbc, sha}, {dhe_rsa, aes_128_cbc, sha}, {rsa, aes_128_cbc, sha}, {ecdhe_rsa, aes_256_cbc, sha}, {dhe_rsa, aes_256_cbc, sha}, {rsa, aes_256_cbc, sha}, {ecdhe_psk, aes_128_cbc, sha}, {dhe_psk, aes_128_cbc,sha}, {ecdhe_psk, aes_256_cbc, sha}, {dhe_psk, aes_256_cbc,sha}]} > On Wed, Mar 5, 2014 at 12:46 AM, pablo platt < pablo.platt@REDACTED > wrote: > > Hi, > > I'm trying to use the dtls prototype from: > https://github.com/RoadRunnr/otp/tree/new_crypto_dtls > > I'm getting an exception when trying to use a simple example. > What am I doing wrong? > > Is there an example how to use this modified ssl app with R16 or R17? > I see that the branch adds crypto:algorithms/0 > Is it the only modification needed except for the ssl app? No, Ingela started refactoring the SSL application and incorporating bits of my DTLS stuff after R16B01. So, you can not apply my modifications to anything after R16B01. Andreas > > Thanks > > test > --------------- > > init() -> > Port = 5070, > Cert = filename:join([dtls:priv_dir(webrtc), "cert.pem"]), > Key = filename:join([dtls:priv_dir(webrtc), "key.pem"]), > Options = [{versions, ['dtlsv1.2', dtlsv1]}, > {cb_info, ssl_udp}, > {reuseaddr, true}, > {active, false}, > {certfile,Cert}, > {keyfile, Key}], > {ok, LSocket} = ssl:listen(Port,Options), > spawn(?MODULE, accept, [LSocket]), > {ok, #state{}}. > > accept(LSocket) -> > {ok, Socket} = ssl_udp:accept(LSocket, 5000), > Pid = spawn(?MODULE, loop, [Socket]), > ssl:controlling_process(Socket, Pid), > accept(LSocket). > > loop(Socket) -> > inet:setopts(Socket, [{active, once}]), > receive > R -> > error_logger:info_msg("~p~n", [R]), > loop(Socket) > end. > > > exception > --------------------------- > {'EXIT', > {function_clause, > [{ssl_udp,call, > [{sslsocket,nil, > {<0.103.0>, > {config, > {ssl_options, > [{254,253},{254,255}], > verify_none, > {#Fun,[]}, > false,false,false,undefined,1, > <<"cert.pem">>, > undefined, > <<"key.pem">>, > undefined,[],undefined,<<>>,undefined,undefined, > undefined,undefined,undefined, > [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, > <<0,107>>, > <<0,106>>, > <<0,61>>, > <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, > <<0,103>>, > <<0,64>>, > <<0,60>>, > <<"?\n">>, > <<192,20>>, > <<0,57>>, > <<0,56>>, > <<192,5>>, > <<192,15>>, > <<0,53>>, > <<"?\b">>, > <<192,18>>, > <<0,22>>, > <<0,19>>, > <<192,3>>, > <<"?\r">>, > <<0,10>>, > <<"?\t">>, > <<192,19>>, > <<0,51>>, > <<0,50>>, > <<192,4>>, > <<192,14>>, > <<0,47>>, > <<192,7>>, > <<192,17>>, > <<0,5>>, > <<0,4>>, > <<0,21>>, > <<192,2>>, > <<"?\f">>, > <<0,9>>], > #Fun,true,268435456,false,undefined, > undefined,false,undefined,undefined}, > [{reuseaddr,true},{active,false}], > {socket_options,list,0,0,0,false}, > [{reuseaddr,true}, > {packet_size,0}, > {packet,0}, > {header,0}, > {active,false}, > {mode,binary}], > {ssl_udp,ssl_udp,udp_closed,udp_error}}}}, > accept,10000,infinity], > [{file,"ssl_udp.erl"},{line,149}]}, > {dtls_test,accept,1, > [{file,"src/dtls_test.erl"},{line,70}]}]}} > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From hans@REDACTED Wed Mar 5 16:33:14 2014 From: hans@REDACTED (Hans Nilsson) Date: Wed, 5 Mar 2014 16:33:14 +0100 Subject: [erlang-questions] eldap using binary() rather than string() in Erlang 17.0 rc2? In-Reply-To: <53171F0F.90606@rabbitmq.com> References: <53171F0F.90606@rabbitmq.com> Message-ID: <531743BA.8060700@erix.ericsson.se> It's because of the non-backward compatible change in the asn.1 representation which we forgot to compensate for in eldap. We will correct this eldap behaviour back to strings. Thanks for the report! /Hans 2014-03-05 13:56, Simon MacMullen skrev: > Using R16B01: > > 1> {ok, LDAP} = eldap:open(["localhost"], []). > {ok,<0.34.0>} > 2> eldap:search(LDAP, [{base, "cn=Simon > MacMullen,ou=People,dc=example,dc=com"},{filter, > eldap:present("objectClass")}, {attributes, ["description"]}]). > {ok,{eldap_search_result, > [{eldap_entry, > "cn=Simon MacMullen,ou=people,dc=example,dc=com", > [{"description",["can-declare-queues"]}]}], > []}} > > So the attribute key/values come back as lists. > > Using 17.0 rc2: > > 1> {ok, LDAP} = eldap:open(["localhost"], []). > {ok,<0.34.0>} > 2> eldap:search(LDAP, [{base, "cn=Simon > MacMullen,ou=People,dc=example,dc=com"},{filter, > eldap:present("objectClass")}, {attributes, ["description"]}]). > {ok,{eldap_search_result, > [{eldap_entry, > <<"cn=Simon MacMullen,ou=people,dc=example,dc=com">>, > [{<<"description">>,[<<"can-declare-queues">>]}]}], > []}} > > Now they come back as binaries. Is this intentional or a bug? > > Note that in either case if I give attribute names as binaries I get a > crash: > > 3> eldap:search(LDAP, [{base, "cn=Simon > MacMullen,ou=People,dc=example,dc=com"},{filter, > eldap:present("objectClass")}, {attributes, [<<"description">>]}]). > {error,{function_clause,[{lists,thing_to_list, > [<<"description">>], > [{file,"lists.erl"},{line,601}]}, > > {lists,flatmap,2,[{file,"lists.erl"},{line,1248}]}, > > {lists,flatmap,2,[{file,"lists.erl"},{line,1248}]}, > {eldap,'-v_attributes/1-fun-0-',1, > [{file,"eldap.erl"},{line,850}]}, > {lists,map,2,[{file,"lists.erl"},{line,1237}]}, > > {eldap,do_search_0,2,[{file,"eldap.erl"},{line,613}]}, > > {eldap,do_search,2,[{file,"eldap.erl"},{line,577}]}, > {eldap,loop,2,[{file,"eldap.erl"},{line,425}]}]}} > > Cheers, Simon > From pablo.platt@REDACTED Wed Mar 5 17:22:25 2014 From: pablo.platt@REDACTED (pablo platt) Date: Wed, 5 Mar 2014 18:22:25 +0200 Subject: [erlang-questions] DTLS example In-Reply-To: <1386037318.38667.1394035330098.JavaMail.zimbra@tpip.net> References: <1386037318.38667.1394035330098.JavaMail.zimbra@tpip.net> Message-ID: Hi, I'm using R16B01. I'm getting an error even when adding the Ciphers: {{badmatch,{error,{options,{ciphers,[{ecdhe_rsa,aes_128_cbc,sha},{dhe_rsa,aes_128_cbc,sha},{rsa,aes_128_cbc,sha},{ecdhe_rsa,aes_256_cbc,sha},{dhe_rsa,aes_256_cbc,sha},{rsa,aes_256_cbc,sha},{ecdhe_psk,aes_128_cbc,sha},{dhe_psk,aes_128_cbc,sha},{ecdhe_psk,aes_256_cbc,sha},{dhe_psk,aes_256_cbc,sha}]}}}} Port = 5070, Ciphers = [{ecdhe_rsa, aes_128_cbc, sha}, {dhe_rsa, aes_128_cbc, sha}, {rsa, aes_128_cbc, sha}, {ecdhe_rsa, aes_256_cbc, sha}, {dhe_rsa, aes_256_cbc, sha}, {rsa, aes_256_cbc, sha}, {ecdhe_psk, aes_128_cbc, sha}, {dhe_psk, aes_128_cbc,sha}, {ecdhe_psk, aes_256_cbc, sha}, {dhe_psk, aes_256_cbc,sha}], Options = [{versions, ['dtlsv1.2', dtlsv1]}, {cb_info, ssl_udp}, {reuseaddr, true}, {active, false}, {ciphers, Ciphers}, {certfile,Cert}, {keyfile, Key}], {ok, LSocket} = ssl:listen(Port, Options) Pablo On Wed, Mar 5, 2014 at 6:02 PM, Andreas Schultz wrote: > Hi Pablo, > > > ----- Original Message ----- > > Now I'm getting an error: > > {error,{options,{ciphers,[]}}} > > > > When calling: > > > > Options = [{versions, ['dtlsv1.2', dtlsv1]}, > > {cb_info, ssl_udp}, > > {reuseaddr, true}, > > {active, false}, > > {certfile,Cert}, > > {keyfile, Key}], > > {ok, LSocket} = ssl:listen(Port, Options). > > > > Do I need to pass ciphers to the ssl options? > > > I seems that DTLS was never tested without the ciphers. > option. In my project I use this list: > > {ciphers,[{ecdhe_rsa, aes_128_cbc, sha}, > {dhe_rsa, aes_128_cbc, sha}, > {rsa, aes_128_cbc, sha}, > {ecdhe_rsa, aes_256_cbc, sha}, > {dhe_rsa, aes_256_cbc, sha}, > {rsa, aes_256_cbc, sha}, > {ecdhe_psk, aes_128_cbc, sha}, > {dhe_psk, aes_128_cbc,sha}, > {ecdhe_psk, aes_256_cbc, sha}, > {dhe_psk, aes_256_cbc,sha}]} > > > On Wed, Mar 5, 2014 at 12:46 AM, pablo platt < pablo.platt@REDACTED > > wrote: > > > > Hi, > > > > I'm trying to use the dtls prototype from: > > https://github.com/RoadRunnr/otp/tree/new_crypto_dtls > > > > I'm getting an exception when trying to use a simple example. > > What am I doing wrong? > > > > Is there an example how to use this modified ssl app with R16 or R17? > > I see that the branch adds crypto:algorithms/0 > > Is it the only modification needed except for the ssl app? > > No, Ingela started refactoring the SSL application and incorporating bits > of my > DTLS stuff after R16B01. So, you can not apply my modifications to > anything after > R16B01. > > Andreas > > > > > Thanks > > > > test > > --------------- > > > > init() -> > > Port = 5070, > > Cert = filename:join([dtls:priv_dir(webrtc), "cert.pem"]), > > Key = filename:join([dtls:priv_dir(webrtc), "key.pem"]), > > Options = [{versions, ['dtlsv1.2', dtlsv1]}, > > {cb_info, ssl_udp}, > > {reuseaddr, true}, > > {active, false}, > > {certfile,Cert}, > > {keyfile, Key}], > > {ok, LSocket} = ssl:listen(Port,Options), > > spawn(?MODULE, accept, [LSocket]), > > {ok, #state{}}. > > > > accept(LSocket) -> > > {ok, Socket} = ssl_udp:accept(LSocket, 5000), > > Pid = spawn(?MODULE, loop, [Socket]), > > ssl:controlling_process(Socket, Pid), > > accept(LSocket). > > > > loop(Socket) -> > > inet:setopts(Socket, [{active, once}]), > > receive > > R -> > > error_logger:info_msg("~p~n", [R]), > > loop(Socket) > > end. > > > > > > exception > > --------------------------- > > {'EXIT', > > {function_clause, > > [{ssl_udp,call, > > [{sslsocket,nil, > > {<0.103.0>, > > {config, > > {ssl_options, > > [{254,253},{254,255}], > > verify_none, > > {#Fun,[]}, > > false,false,false,undefined,1, > > <<"cert.pem">>, > > undefined, > > <<"key.pem">>, > > undefined,[],undefined,<<>>,undefined,undefined, > > undefined,undefined,undefined, > > [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, > > <<0,107>>, > > <<0,106>>, > > <<0,61>>, > > <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, > > <<0,103>>, > > <<0,64>>, > > <<0,60>>, > > <<"?\n">>, > > <<192,20>>, > > <<0,57>>, > > <<0,56>>, > > <<192,5>>, > > <<192,15>>, > > <<0,53>>, > > <<"?\b">>, > > <<192,18>>, > > <<0,22>>, > > <<0,19>>, > > <<192,3>>, > > <<"?\r">>, > > <<0,10>>, > > <<"?\t">>, > > <<192,19>>, > > <<0,51>>, > > <<0,50>>, > > <<192,4>>, > > <<192,14>>, > > <<0,47>>, > > <<192,7>>, > > <<192,17>>, > > <<0,5>>, > > <<0,4>>, > > <<0,21>>, > > <<192,2>>, > > <<"?\f">>, > > <<0,9>>], > > #Fun,true,268435456,false,undefined, > > undefined,false,undefined,undefined}, > > [{reuseaddr,true},{active,false}], > > {socket_options,list,0,0,0,false}, > > [{reuseaddr,true}, > > {packet_size,0}, > > {packet,0}, > > {header,0}, > > {active,false}, > > {mode,binary}], > > {ssl_udp,ssl_udp,udp_closed,udp_error}}}}, > > accept,10000,infinity], > > [{file,"ssl_udp.erl"},{line,149}]}, > > {dtls_test,accept,1, > > [{file,"src/dtls_test.erl"},{line,70}]}]}} > > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > -- > Dipl. Inform. > Andreas Schultz > > email: as@REDACTED > phone: +49-391-819099-224 > mobil: +49-170-2226073 > > ------------------- enabling your networks ------------------- > > Travelping GmbH phone: +49-391-819099229 > Roentgenstr. 13 fax: +49-391-819099299 > D-39108 Magdeburg email: info@REDACTED > GERMANY web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 > -------------------------------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon@REDACTED Wed Mar 5 17:50:04 2014 From: simon@REDACTED (Simon MacMullen) Date: Wed, 05 Mar 2014 16:50:04 +0000 Subject: [erlang-questions] eldap using binary() rather than string() in Erlang 17.0 rc2? In-Reply-To: <531743BA.8060700@erix.ericsson.se> References: <53171F0F.90606@rabbitmq.com> <531743BA.8060700@erix.ericsson.se> Message-ID: <531755BC.6010608@rabbitmq.com> On 05/03/14 15:33, Hans Nilsson wrote: > We will correct this eldap behaviour back to strings. Awesome, thanks! Cheers, Simon -- Simon MacMullen RabbitMQ, Pivotal From daniel.goertzen@REDACTED Wed Mar 5 18:12:38 2014 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Wed, 5 Mar 2014 11:12:38 -0600 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> Message-ID: So I received suggestions to factor out the little functions. But I was sure that would ruin the visual locality and "flow" of the code thereby making it harder to read. So I decided to go ahead and implement it that way so I could show those people that they are wrong. But as I starting factoring things out I could see the larger-grain structure more easily, and saw some easy ways to collapse and clean up things... and some of things that I thought would be problems were not problems at all. Boy, am I ever eating crow now. :) Here is the result: https://gist.github.com/goertzenator/9370847 There may be a bug or two; I am in the process of making functional changes. So a big thank you to Richard and the others who commented on my coding style. I am the sole Erlanger at a small startup, so I don't get the benefit of that kind of review. The scoping rules of case still irritate me, but now I have a better sense as to why it is the way it is, and I have been shown a better coding style that mostly removes the irritation. Thanks again, Dan. On Tue, Mar 4, 2014 at 10:10 AM, Daniel Goertzen wrote: > I've been reflecting on this some more, and have realized one of my biases > on the subject comes from the way C/C++ manages scope: Anything within > curly braces, whether it is a function, if, while, for, try, or catch, is a > scope which encapsulates all declarations within. This uniform rule makes > it easier to reason about code, and not having it in Erlang is, well, > jarring to me. > > Now both Erlang and C/C++ can *read* variables from enclosing scopes, but > only C/C++ can *mutate* variables from enclosing scopes. Perhaps Erlang's > case scoping rules are just a way to give similar powers to affect the > enclosing scope. > > > The actual clause that predicated all this is here: > https://gist.github.com/goertzenator/9347573 > > There are a lot of case expressions that leave unwanted bindings lying > around. I have to pay attention to use different binding names for each to > avoid collisions. Specifically the AuthKey and PrivKey expressions had > collisions at first because they are nearly identical. The code would be a > lot easier to reason about if I didn't have to look out for such things. > > I tried putting this function together in various different ways, and this > way was the most concise, most readable, and most amenable to future > tweaking. I normally don't tolerate clauses this long, but breaking it up > always seemed to compromise those things. > > > Thank you for your ideas Richard. I see I could also use funs directly > instead of cases. > > f1(X, Y) -> > A = fun({0, Q}) -> Q; > ({P, Q}) -> P*Q > end({X,Y}), > > B = fun({0, Q}) -> Q; > ({P, Q}) -> P+Q > end({X,Y}), > {A,B}. > > Regards, > Dan. > > > > On Mon, Mar 3, 2014 at 3:23 PM, Richard A. O'Keefe wrote: > >> >> On 4/03/2014, at 8:07 AM, Daniel Goertzen wrote: >> >> > Hmm, fun wrapping could be the basis of hygienic-case parse transform. >> I'll have to see what the performance overhead of a fun wrap is like. >> > >> > The example I gave is contrived and a bit weak I guess. In my most >> recent run-in with this issue there were a lot of bindings from the >> enclosing scope that were used, so breaking things out to top level >> functions would not always be a good option. >> >> I see a non-sequitur there. >> >> Simplified examples are great for revealing bugs. >> >> For illuminating style concerns, NOTHING beats REAL code. >> >> "There were a lot of bindings from the enclosing scope" >> is already a warning sign that the code should be restructured. >> >> > Funs would be better, but add clutter and maybe runtime overhead. >> >> There is currently some run-time overhead. >> In R16B03-1, the compiler still does not optimise >> >> (fun (...) -> ... ... end)(...) >> >> by turning it into the equivalent of an SML let ... in ... end >> form, but there is no particular reason why it couldn't. >> >> Whether you can _measure_ the overhead in a real application >> is another matter entirely. >> >> Splitting out little functions and then telling the compiler >> to inline them might well have the least overhead of all. >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Wed Mar 5 18:13:29 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 5 Mar 2014 09:13:29 -0800 (PST) Subject: [erlang-questions] case expression scope In-Reply-To: <75537C7F-2E24-42E8-A39F-1E949446D57E@gmail.com> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> <1394030022.43533.YahooMailNeo@web140101.mail.bf1.yahoo.com> <1394033901.48922.YahooMailNeo@web140104.mail.bf1.yahoo.com> <75537C7F-2E24-42E8-A39F-1E949446D57E@gmail.com> Message-ID: <1394039609.25545.YahooMailNeo@web140101.mail.bf1.yahoo.com> The way I see it, the feature of implicit variable matching is more trouble than it's worth. Warnings about such matches would catch this kind of problems. For myself, it's seldom used in practice, and mostly a source of hidden bugs and unobvious code. Rewriting into explicit comparisons is normally straightforward and clearer, so having it doesn't buy me a lot. But maybe I'm being unreasonable. Anyone use bound variables in patterns a lot by intent? Best, Thomas On Wednesday, March 5, 2014 4:57 PM, Anthony Ramine wrote: Why would you warn for this? It?s a feature. > >-- >Anthony Ramine > > >Le 5 mars 2014 ? 16:38, Thomas Lindgren a ?crit : > >> Occurrences of bound variables in patterns. For example A, B, C, and D in these: >> >>? {A, B} = f(X), >>? {A, B} = f(Y),? % A,B already bound >>? C = g(Z), >>? C = g(W),? ? ? ? % C is already bound >>? {D,D} = h(V)? ? % D is bound then matched >> >> Best, >> Thomas >> >> >> >> On Wednesday, March 5, 2014 3:39 PM, Anthony Ramine wrote: >> What would you like to be warned about? I don?t get it. >> >> -- >> Anthony Ramine >> >> Le 5 mars 2014 ? 15:33, Thomas Lindgren a ?crit : >> >> > Thanks Anthony, that option warns for Value in the previous example because it's exported from the case, but not for the variable match that then occurs. I'd like to see a compiler option that warned about matching (bound variables occurring in patterns), which would catch other inadvertent reuse of variable names. >> > >> > Best, >> > Thomas >> > >> > >> > On Wednesday, March 5, 2014 2:40 PM, Anthony Ramine wrote: >> > The compile option is warn_export_vars: >> > >> >? ? Causes warnings to be emitted for all implicitly exported variables referred to after the primitives where they were first defined. No warnings for exported variables unless they are referred to in some pattern, which is the default, can be selected by the option nowarn_export_vars. >> > >> > -- >> > Anthony Ramine >> > >> > Le 5 mars 2014 ? 12:18, Thomas Lindgren a ?crit : >> > >> > > In the larger scheme of things: The way I see it, the feature of implicit variable matching is more trouble than it's worth. Warnings about such matches would catch this kind of problems. >> > > >> > >> > >> >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Mar 5 20:22:59 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 05 Mar 2014 20:22:59 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: <1394039609.25545.YahooMailNeo@web140101.mail.bf1.yahoo.com> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> <1394030022.43533.YahooMailNeo@web140101.mail.bf1.yahoo.com> <1394033901.48922.YahooMailNeo@web140104.mail.bf1.yahoo.com> <75537C7F-2E24-42E8-A39F-1E949446D57E@gmail.com> <1394039609.25545.YahooMailNeo@web140101.mail.bf1.yahoo.com> Message-ID: <53177993.1060001@ninenines.eu> On 03/05/2014 06:13 PM, Thomas Lindgren wrote: > The way I see it, the feature of implicit variable matching is more > trouble than it's worth. Warnings about such matches would catch this > kind of problems. > > For myself, it's seldom used in practice, and mostly a source of hidden > bugs and unobvious code. Rewriting into explicit comparisons is normally > straightforward and clearer, so having it doesn't buy me a lot. But > maybe I'm being unreasonable. Anyone use bound variables in patterns a > lot by intent? *Yes*. -- Lo?c Hoguin http://ninenines.eu From jesper.louis.andersen@REDACTED Wed Mar 5 20:35:06 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 5 Mar 2014 20:35:06 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: <53177993.1060001@ninenines.eu> References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> <1394030022.43533.YahooMailNeo@web140101.mail.bf1.yahoo.com> <1394033901.48922.YahooMailNeo@web140104.mail.bf1.yahoo.com> <75537C7F-2E24-42E8-A39F-1E949446D57E@gmail.com> <1394039609.25545.YahooMailNeo@web140101.mail.bf1.yahoo.com> <53177993.1060001@ninenines.eu> Message-ID: On 05 Mar 2014, at 20:22, Lo?c Hoguin wrote: > On 03/05/2014 06:13 PM, Thomas Lindgren wrote: >> The way I see it, the feature of implicit variable matching is more >> trouble than it's worth. Warnings about such matches would catch this >> kind of problems. >> >> For myself, it's seldom used in practice, and mostly a source of hidden >> bugs and unobvious code. Rewriting into explicit comparisons is normally >> straightforward and clearer, so having it doesn't buy me a lot. But >> maybe I'm being unreasonable. Anyone use bound variables in patterns a >> lot by intent? > > *Yes*. Me too! From pablo.platt@REDACTED Wed Mar 5 21:11:52 2014 From: pablo.platt@REDACTED (pablo platt) Date: Wed, 5 Mar 2014 22:11:52 +0200 Subject: [erlang-questions] DTLS example In-Reply-To: References: <1386037318.38667.1394035330098.JavaMail.zimbra@tpip.net> Message-ID: I first tried to copy just the ssl app from your new_crypto_dtls branch and got the error in the previous email. Now I tried to use your complete branch and it works but I'm getting a bad match error somewhere else in my code when trying to encrypt a media stream: State = crypto:stream_init(aes_ctr, MasterKey, <>), {_State2, CipherText} = crypto:stream_encrypt(State, <<0:Size>>), line error: {crypto,stream_encrypt,2,[{file,"crypto.erl"},{line,776} You said your ssl app prototype should be compatible with R16B01. Shouldn't I be able to just copy the ssl app and use the crypto app in R16B01? Thanks On Wed, Mar 5, 2014 at 6:22 PM, pablo platt wrote: > Hi, > > I'm using R16B01. > > I'm getting an error even when adding the Ciphers: > > {{badmatch,{error,{options,{ciphers,[{ecdhe_rsa,aes_128_cbc,sha},{dhe_rsa,aes_128_cbc,sha},{rsa,aes_128_cbc,sha},{ecdhe_rsa,aes_256_cbc,sha},{dhe_rsa,aes_256_cbc,sha},{rsa,aes_256_cbc,sha},{ecdhe_psk,aes_128_cbc,sha},{dhe_psk,aes_128_cbc,sha},{ecdhe_psk,aes_256_cbc,sha},{dhe_psk,aes_256_cbc,sha}]}}}} > > Port = 5070, > Ciphers = [{ecdhe_rsa, aes_128_cbc, sha}, > > {dhe_rsa, aes_128_cbc, sha}, > {rsa, aes_128_cbc, sha}, > {ecdhe_rsa, aes_256_cbc, sha}, > {dhe_rsa, aes_256_cbc, sha}, > {rsa, aes_256_cbc, sha}, > {ecdhe_psk, aes_128_cbc, sha}, > {dhe_psk, aes_128_cbc,sha}, > {ecdhe_psk, aes_256_cbc, sha}, > {dhe_psk, aes_256_cbc,sha}], > > Options = [{versions, ['dtlsv1.2', dtlsv1]}, > {cb_info, ssl_udp}, > {reuseaddr, true}, > {active, false}, > {ciphers, Ciphers}, > > {certfile,Cert}, > {keyfile, Key}], > {ok, LSocket} = ssl:listen(Port, Options) > > Pablo > > > On Wed, Mar 5, 2014 at 6:02 PM, Andreas Schultz wrote: > >> Hi Pablo, >> >> >> ----- Original Message ----- >> > Now I'm getting an error: >> > {error,{options,{ciphers,[]}}} >> > >> > When calling: >> > >> > Options = [{versions, ['dtlsv1.2', dtlsv1]}, >> > {cb_info, ssl_udp}, >> > {reuseaddr, true}, >> > {active, false}, >> > {certfile,Cert}, >> > {keyfile, Key}], >> > {ok, LSocket} = ssl:listen(Port, Options). >> > >> > Do I need to pass ciphers to the ssl options? >> >> >> I seems that DTLS was never tested without the ciphers. >> option. In my project I use this list: >> >> {ciphers,[{ecdhe_rsa, aes_128_cbc, sha}, >> {dhe_rsa, aes_128_cbc, sha}, >> {rsa, aes_128_cbc, sha}, >> {ecdhe_rsa, aes_256_cbc, sha}, >> {dhe_rsa, aes_256_cbc, sha}, >> {rsa, aes_256_cbc, sha}, >> {ecdhe_psk, aes_128_cbc, sha}, >> {dhe_psk, aes_128_cbc,sha}, >> {ecdhe_psk, aes_256_cbc, sha}, >> {dhe_psk, aes_256_cbc,sha}]} >> >> > On Wed, Mar 5, 2014 at 12:46 AM, pablo platt < pablo.platt@REDACTED > >> wrote: >> > >> > Hi, >> > >> > I'm trying to use the dtls prototype from: >> > https://github.com/RoadRunnr/otp/tree/new_crypto_dtls >> > >> > I'm getting an exception when trying to use a simple example. >> > What am I doing wrong? >> > >> > Is there an example how to use this modified ssl app with R16 or R17? >> > I see that the branch adds crypto:algorithms/0 >> > Is it the only modification needed except for the ssl app? >> >> No, Ingela started refactoring the SSL application and incorporating bits >> of my >> DTLS stuff after R16B01. So, you can not apply my modifications to >> anything after >> R16B01. >> >> Andreas >> >> > >> > Thanks >> > >> > test >> > --------------- >> > >> > init() -> >> > Port = 5070, >> > Cert = filename:join([dtls:priv_dir(webrtc), "cert.pem"]), >> > Key = filename:join([dtls:priv_dir(webrtc), "key.pem"]), >> > Options = [{versions, ['dtlsv1.2', dtlsv1]}, >> > {cb_info, ssl_udp}, >> > {reuseaddr, true}, >> > {active, false}, >> > {certfile,Cert}, >> > {keyfile, Key}], >> > {ok, LSocket} = ssl:listen(Port,Options), >> > spawn(?MODULE, accept, [LSocket]), >> > {ok, #state{}}. >> > >> > accept(LSocket) -> >> > {ok, Socket} = ssl_udp:accept(LSocket, 5000), >> > Pid = spawn(?MODULE, loop, [Socket]), >> > ssl:controlling_process(Socket, Pid), >> > accept(LSocket). >> > >> > loop(Socket) -> >> > inet:setopts(Socket, [{active, once}]), >> > receive >> > R -> >> > error_logger:info_msg("~p~n", [R]), >> > loop(Socket) >> > end. >> > >> > >> > exception >> > --------------------------- >> > {'EXIT', >> > {function_clause, >> > [{ssl_udp,call, >> > [{sslsocket,nil, >> > {<0.103.0>, >> > {config, >> > {ssl_options, >> > [{254,253},{254,255}], >> > verify_none, >> > {#Fun,[]}, >> > false,false,false,undefined,1, >> > <<"cert.pem">>, >> > undefined, >> > <<"key.pem">>, >> > undefined,[],undefined,<<>>,undefined,undefined, >> > undefined,undefined,undefined, >> > [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, >> > <<0,107>>, >> > <<0,106>>, >> > <<0,61>>, >> > <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, >> > <<0,103>>, >> > <<0,64>>, >> > <<0,60>>, >> > <<"?\n">>, >> > <<192,20>>, >> > <<0,57>>, >> > <<0,56>>, >> > <<192,5>>, >> > <<192,15>>, >> > <<0,53>>, >> > <<"?\b">>, >> > <<192,18>>, >> > <<0,22>>, >> > <<0,19>>, >> > <<192,3>>, >> > <<"?\r">>, >> > <<0,10>>, >> > <<"?\t">>, >> > <<192,19>>, >> > <<0,51>>, >> > <<0,50>>, >> > <<192,4>>, >> > <<192,14>>, >> > <<0,47>>, >> > <<192,7>>, >> > <<192,17>>, >> > <<0,5>>, >> > <<0,4>>, >> > <<0,21>>, >> > <<192,2>>, >> > <<"?\f">>, >> > <<0,9>>], >> > #Fun,true,268435456,false,undefined, >> > undefined,false,undefined,undefined}, >> > [{reuseaddr,true},{active,false}], >> > {socket_options,list,0,0,0,false}, >> > [{reuseaddr,true}, >> > {packet_size,0}, >> > {packet,0}, >> > {header,0}, >> > {active,false}, >> > {mode,binary}], >> > {ssl_udp,ssl_udp,udp_closed,udp_error}}}}, >> > accept,10000,infinity], >> > [{file,"ssl_udp.erl"},{line,149}]}, >> > {dtls_test,accept,1, >> > [{file,"src/dtls_test.erl"},{line,70}]}]}} >> > >> > >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> > >> >> -- >> -- >> Dipl. Inform. >> Andreas Schultz >> >> email: as@REDACTED >> phone: +49-391-819099-224 >> mobil: +49-170-2226073 >> >> ------------------- enabling your networks ------------------- >> >> Travelping GmbH phone: +49-391-819099229 >> Roentgenstr. 13 fax: +49-391-819099299 >> D-39108 Magdeburg email: info@REDACTED >> GERMANY web: http://www.travelping.com >> >> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >> Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 >> -------------------------------------------------------------- >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Wed Mar 5 21:31:51 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Wed, 5 Mar 2014 12:31:51 -0800 (PST) Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> <1394018281.10341.YahooMailNeo@web140101.mail.bf1.yahoo.com> <838E60B8-1598-45B6-8012-7CD6981D2C32@gmail.com> <1394030022.43533.YahooMailNeo@web140101.mail.bf1.yahoo.com> <1394033901.48922.YahooMailNeo@web140104.mail.bf1.yahoo.com> <75537C7F-2E24-42E8-A39F-1E949446D57E@gmail.com> <1394039609.25545.YahooMailNeo@web140101.mail.bf1.yahoo.com> <53177993.1060001@ninenines.eu> Message-ID: <1394051511.16764.YahooMailNeo@web140101.mail.bf1.yahoo.com> Thanks, any examples either of you can share where they are particularly handy? Best, Thomas On Wednesday, March 5, 2014 8:35 PM, Jesper Louis Andersen wrote: >On 05 Mar 2014, at 20:22, Lo?c Hoguin wrote: > >> On 03/05/2014 06:13 PM, Thomas Lindgren wrote: >>> The way I see it, the feature of implicit variable matching is more >>> trouble than it's worth. Warnings about such matches would catch this >>> kind of problems. >>> >>> For myself, it's seldom used in practice, and mostly a source of hidden >>> bugs and unobvious code. Rewriting into explicit comparisons is normally >>> straightforward and clearer, so having it doesn't buy me a lot. But >>> maybe I'm being unreasonable. Anyone use bound variables in patterns a >>> lot by intent? >> >> *Yes*. > >Me too! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dszoboszlay@REDACTED Wed Mar 5 21:48:05 2014 From: dszoboszlay@REDACTED (=?utf-8?Q?Szoboszlay_D=C3=A1niel?=) Date: Wed, 05 Mar 2014 21:48:05 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> Message-ID: On Wed, 05 Mar 2014 03:52:22 +0100, Richard A. O'Keefe wrote: > Wrong. Yes, list comprehensions *happen* to be implemented > as calls to out-of-line functions, but the *necessity* for > list comprehensions to be separate scopes falls directly > out of their semantics. > > Suppose it were otherwise. > > R = [(Y = f(X), Y) || X <- L]. > > What value would X have after the comprehension > - if L = []? > - if L = [1]? > - if L = [1,2]? > What value would Y have? > > The key thing is that X and Y get _different_ values > on each iteration, and Erlang variables being immutable, > the only way we can make sense of that is if each > iteration gets its _own_ X and Y. The key thing is list comprehensions introduce a new scope, thus behave different from the rest of the expressions. This is not intuitive, even if it is necessary. > In Classic C and C89, *none* of 'if', 'switch', 'while', > 'do', and 'for' introduce new scopes. > In C99, it's clear from 6.8.4 that 'if' and 'switch' > do *NOT* introduce new scopes and it is clear from > 6.8.5 that 'while' and 'do' do *NOT* introduce new > scopes. > > In Classic C and C89 the *ONLY* construction that > introduces a new scope is '{...}'. I don't want to argue with specs, you are technically correct of course. But the mental model is that whenever I introduce a new variable in an if-branch, it will go into a new scope. From the compiler's perspective it's due to the curly braces. From my perspective it's because I want to use that variable in that single block only. > The thing is that Erlang is what it is > and is not something else. > Criticising Erlang for not being like something else > (especially when it turns out that the something else > is not in fact like that either) > is silly. I'm not criticizing Erlang for being what it is. I love this language the way it is already. But I think it could be improved in some areas, and the lack of scoping expressions is one such area. Changing the way case works would be no doubt a terrible decision. Allowing to write code in the style of my examples without breaking backward compatibility would be a useful addition for those who prefer this style. If starting a new scope would be as easy in Erlang as in C, I'd be very happy. And why shouldn't it be? For example consider a new expression: "<- Expression" that has the value of Expression but introduces new variables in Expression to a new scope. (OK, probably using the left arrow might have some problems, but at least it looks very Erlangish). Then I could write: foo(Dict) -> Value = <- case orddict:find(foo, Dict) of {ok, Value} -> Value; error -> calculate_very_expensive_default_value() end, ... (Btw. my problem with "begin ... within ... end" mentioned in a later email is that it is way too verbose. Which is of course also very Erlangish...) And once we are there, there are some other nice tricks we could do with scopes. Consider this real life example: https://github.com/rebar/rebar/blob/master/src/rebar_core.erl#L182-L263 - this function performs a lot of sequential tasks and generates a series of Config variables in the meantime (Config1, Config2, ...). A typical error is that after creating Config123 somewhere later you accidentally use Config122 instead. It would be nice if I could "drop" a variable from the scope and get a compile error if I'd happen to reuse it later. Like this: DirSet3 = sets:add_element(Dir, DirSet2), ~DirSet2, % Never ever use DirSet2 again! ... or even: DirSet3 = sets:add_element(Dir, ~DirSet2), ... But I can accept if you think these ideas are worthless as well, only I'd love to hear and discuss your arguments. Cheers, Daniel From n.oxyde@REDACTED Wed Mar 5 22:12:35 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Wed, 5 Mar 2014 22:12:35 +0100 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> Message-ID: Replied inline. -- Anthony Ramine Le 5 mars 2014 ? 21:48, Szoboszlay D?niel a ?crit : > > On Wed, 05 Mar 2014 03:52:22 +0100, Richard A. O'Keefe wrote: > >> Wrong. Yes, list comprehensions *happen* to be implemented >> as calls to out-of-line functions, but the *necessity* for >> list comprehensions to be separate scopes falls directly >> out of their semantics. >> >> Suppose it were otherwise. >> >> R = [(Y = f(X), Y) || X <- L]. >> >> What value would X have after the comprehension >> - if L = []? >> - if L = [1]? >> - if L = [1,2]? >> What value would Y have? >> >> The key thing is that X and Y get _different_ values >> on each iteration, and Erlang variables being immutable, >> the only way we can make sense of that is if each >> iteration gets its _own_ X and Y. > > The key thing is list comprehensions introduce a new scope, thus behave different from the rest of the expressions. This is not intuitive, even if it is necessary. > >> In Classic C and C89, *none* of 'if', 'switch', 'while', >> 'do', and 'for' introduce new scopes. >> In C99, it's clear from 6.8.4 that 'if' and 'switch' >> do *NOT* introduce new scopes and it is clear from >> 6.8.5 that 'while' and 'do' do *NOT* introduce new >> scopes. >> >> In Classic C and C89 the *ONLY* construction that >> introduces a new scope is '{...}'. > > I don't want to argue with specs, you are technically correct of course. But the mental model is that whenever I introduce a new variable in an if-branch, it will go into a new scope. From the compiler's perspective it's due to the curly braces. From my perspective it's because I want to use that variable in that single block only. Javascript compilers would love it if scope was just a matter of a pair of curly braces. From my perspective, the code X = ..., foo(X). isn?t the same as let X = ... in foo(X). In the first, ? = ? does not denote a let-binding of which the resulting augmented environment is used to evaluate its body. It denotes a match expression, which happens to never fail because the pattern matches everything, and of which the environment spills into the next expression ? foo(X) ?. Given that a match exports variables, why shouldn?t case? if? I have a patch somewhere which I need to finish, that makes exporting from try possible to, for consistency?s sake. That being said, if it were just me, I would just forbid the use of all unsafe and exported names. And make fun heads non-shadowing. One True Scope, all the way long. >> The thing is that Erlang is what it is >> and is not something else. >> Criticising Erlang for not being like something else >> (especially when it turns out that the something else >> is not in fact like that either) >> is silly. > > I'm not criticizing Erlang for being what it is. I love this language the way it is already. But I think it could be improved in some areas, and the lack of scoping expressions is one such area. Changing the way case works would be no doubt a terrible decision. Allowing to write code in the style of my examples without breaking backward compatibility would be a useful addition for those who prefer this style. The lack of scoping expressions is a feature, I don?t want to have to look hard to find the initial binding of a variable, rebinding makes finding the original binding place harder. Also, I find the One True Scope and nonlinear patterns to be quite related and I don?t think it would be nice to have one without the other. Removing nonlinear patterns makes very idiomatic code impossible: Ref = erlang:make_ref(), Pid ! {request,Ref}, receive {reply,Ref,Msg} -> ok end. > If starting a new scope would be as easy in Erlang as in C, I'd be very happy. And why shouldn't it be? Because we don?t want a new scope. > For example consider a new expression: "<- Expression" that has the value of Expression but introduces new variables in Expression to a new scope. (OK, probably using the left arrow might have some problems, but at least it looks very Erlangish). Then I could write: > > foo(Dict) -> > Value = <- case orddict:find(foo, Dict) of > {ok, Value} -> Value; > error -> calculate_very_expensive_default_value() > end, > ... > > (Btw. my problem with "begin ... within ... end" mentioned in a later email is that it is way too verbose. Which is of course also very Erlangish?) This is certainly not Erlangish because it introduces a new scope even though there is no lambda involved, and because there is no arrow in Erlang which is a prefix or postfix operator. Why would you use an arrow unbalanced? > And once we are there, there are some other nice tricks we could do with scopes. Consider this real life example: https://github.com/rebar/rebar/blob/master/src/rebar_core.erl#L182-L263 - this function performs a lot of sequential tasks and generates a series of Config variables in the meantime (Config1, Config2, ...). A typical error is that after creating Config123 somewhere later you accidentally use Config122 instead. It would be nice if I could "drop" a variable from the scope and get a compile error if I'd happen to reuse it later. Like this: Sometimes, the rules in Erlang are just here to make sure your life will be miserable if you get too fancy in a single clause; this is such an occurrence. Also if there were less comments, it would be better in my opinion. And all these newlines, they make my eyes wander all around. %% Check that this directory is not on the skip list Config7 = case rebar_config:is_skip_dir(Config3, Dir) of What?s the point of such comments? > DirSet3 = sets:add_element(Dir, DirSet2), > ~DirSet2, % Never ever use DirSet2 again! > ... > > or even: > > DirSet3 = sets:add_element(Dir, ~DirSet2), > ... > > But I can accept if you think these ideas are worthless as well, only I'd love to hear and discuss your arguments. > > Cheers, > Daniel > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From pablo.platt@REDACTED Thu Mar 6 01:04:56 2014 From: pablo.platt@REDACTED (pablo platt) Date: Thu, 6 Mar 2014 02:04:56 +0200 Subject: [erlang-questions] DTLS example In-Reply-To: References: <1386037318.38667.1394035330098.JavaMail.zimbra@tpip.net> Message-ID: This code works in R16B01 and throws and exception in the new_crypto_dtls branch. Size = 128, IVec = <<240,2,55,217,6,222,90,182,131,77,108,124,205,94>>, MasterKey = <<37,119,224,9,196,4,28,97,252,51,130,229,170,203,18,65>>, State = crypto:stream_init(aes_ctr, MasterKey, <>), crypto:stream_encrypt(State, <<0:Size>>). ** exception error: no match of right hand side value {{<<37,119,224,9,196,4,28,97,252,51,130,229,170,203,18,65>>, <<240,2,55,217,6,222,90,182,131,77,108,124,205,94,0,1>>, <<253,130,61,97,94,199,237,208,157,100,10,240,73,47,199, 159>>, 0}, <<253,130,61,97,94,199,237,208,157,100,10,240,73,47,199, 159>>} in function crypto:stream_encrypt/2 (crypto.erl, line 776) Am I missing something? Thanks On Wed, Mar 5, 2014 at 10:11 PM, pablo platt wrote: > I first tried to copy just the ssl app from your new_crypto_dtls branch > and got the error in the previous email. > Now I tried to use your complete branch and it works > but I'm getting a bad match error somewhere else in my code when trying to > encrypt a media stream: > > State = crypto:stream_init(aes_ctr, MasterKey, <>), > {_State2, CipherText} = crypto:stream_encrypt(State, <<0:Size>>), > > line error: > {crypto,stream_encrypt,2,[{file,"crypto.erl"},{line,776} > > You said your ssl app prototype should be compatible with R16B01. > Shouldn't I be able to just copy the ssl app and use the crypto app in > R16B01? > > Thanks > > > > > On Wed, Mar 5, 2014 at 6:22 PM, pablo platt wrote: > >> Hi, >> >> I'm using R16B01. >> >> I'm getting an error even when adding the Ciphers: >> >> {{badmatch,{error,{options,{ciphers,[{ecdhe_rsa,aes_128_cbc,sha},{dhe_rsa,aes_128_cbc,sha},{rsa,aes_128_cbc,sha},{ecdhe_rsa,aes_256_cbc,sha},{dhe_rsa,aes_256_cbc,sha},{rsa,aes_256_cbc,sha},{ecdhe_psk,aes_128_cbc,sha},{dhe_psk,aes_128_cbc,sha},{ecdhe_psk,aes_256_cbc,sha},{dhe_psk,aes_256_cbc,sha}]}}}} >> >> Port = 5070, >> Ciphers = [{ecdhe_rsa, aes_128_cbc, sha}, >> >> {dhe_rsa, aes_128_cbc, sha}, >> {rsa, aes_128_cbc, sha}, >> {ecdhe_rsa, aes_256_cbc, sha}, >> {dhe_rsa, aes_256_cbc, sha}, >> {rsa, aes_256_cbc, sha}, >> {ecdhe_psk, aes_128_cbc, sha}, >> {dhe_psk, aes_128_cbc,sha}, >> {ecdhe_psk, aes_256_cbc, sha}, >> {dhe_psk, aes_256_cbc,sha}], >> >> Options = [{versions, ['dtlsv1.2', dtlsv1]}, >> {cb_info, ssl_udp}, >> {reuseaddr, true}, >> {active, false}, >> {ciphers, Ciphers}, >> >> {certfile,Cert}, >> {keyfile, Key}], >> {ok, LSocket} = ssl:listen(Port, Options) >> >> Pablo >> >> >> On Wed, Mar 5, 2014 at 6:02 PM, Andreas Schultz wrote: >> >>> Hi Pablo, >>> >>> >>> ----- Original Message ----- >>> > Now I'm getting an error: >>> > {error,{options,{ciphers,[]}}} >>> > >>> > When calling: >>> > >>> > Options = [{versions, ['dtlsv1.2', dtlsv1]}, >>> > {cb_info, ssl_udp}, >>> > {reuseaddr, true}, >>> > {active, false}, >>> > {certfile,Cert}, >>> > {keyfile, Key}], >>> > {ok, LSocket} = ssl:listen(Port, Options). >>> > >>> > Do I need to pass ciphers to the ssl options? >>> >>> >>> I seems that DTLS was never tested without the ciphers. >>> option. In my project I use this list: >>> >>> {ciphers,[{ecdhe_rsa, aes_128_cbc, sha}, >>> {dhe_rsa, aes_128_cbc, sha}, >>> {rsa, aes_128_cbc, sha}, >>> {ecdhe_rsa, aes_256_cbc, sha}, >>> {dhe_rsa, aes_256_cbc, sha}, >>> {rsa, aes_256_cbc, sha}, >>> {ecdhe_psk, aes_128_cbc, sha}, >>> {dhe_psk, aes_128_cbc,sha}, >>> {ecdhe_psk, aes_256_cbc, sha}, >>> {dhe_psk, aes_256_cbc,sha}]} >>> >>> > On Wed, Mar 5, 2014 at 12:46 AM, pablo platt < pablo.platt@REDACTED> wrote: >>> > >>> > Hi, >>> > >>> > I'm trying to use the dtls prototype from: >>> > https://github.com/RoadRunnr/otp/tree/new_crypto_dtls >>> > >>> > I'm getting an exception when trying to use a simple example. >>> > What am I doing wrong? >>> > >>> > Is there an example how to use this modified ssl app with R16 or R17? >>> > I see that the branch adds crypto:algorithms/0 >>> > Is it the only modification needed except for the ssl app? >>> >>> No, Ingela started refactoring the SSL application and incorporating >>> bits of my >>> DTLS stuff after R16B01. So, you can not apply my modifications to >>> anything after >>> R16B01. >>> >>> Andreas >>> >>> > >>> > Thanks >>> > >>> > test >>> > --------------- >>> > >>> > init() -> >>> > Port = 5070, >>> > Cert = filename:join([dtls:priv_dir(webrtc), "cert.pem"]), >>> > Key = filename:join([dtls:priv_dir(webrtc), "key.pem"]), >>> > Options = [{versions, ['dtlsv1.2', dtlsv1]}, >>> > {cb_info, ssl_udp}, >>> > {reuseaddr, true}, >>> > {active, false}, >>> > {certfile,Cert}, >>> > {keyfile, Key}], >>> > {ok, LSocket} = ssl:listen(Port,Options), >>> > spawn(?MODULE, accept, [LSocket]), >>> > {ok, #state{}}. >>> > >>> > accept(LSocket) -> >>> > {ok, Socket} = ssl_udp:accept(LSocket, 5000), >>> > Pid = spawn(?MODULE, loop, [Socket]), >>> > ssl:controlling_process(Socket, Pid), >>> > accept(LSocket). >>> > >>> > loop(Socket) -> >>> > inet:setopts(Socket, [{active, once}]), >>> > receive >>> > R -> >>> > error_logger:info_msg("~p~n", [R]), >>> > loop(Socket) >>> > end. >>> > >>> > >>> > exception >>> > --------------------------- >>> > {'EXIT', >>> > {function_clause, >>> > [{ssl_udp,call, >>> > [{sslsocket,nil, >>> > {<0.103.0>, >>> > {config, >>> > {ssl_options, >>> > [{254,253},{254,255}], >>> > verify_none, >>> > {#Fun,[]}, >>> > false,false,false,undefined,1, >>> > <<"cert.pem">>, >>> > undefined, >>> > <<"key.pem">>, >>> > undefined,[],undefined,<<>>,undefined,undefined, >>> > undefined,undefined,undefined, >>> > [<<"?$">>,<<"?(">>,<<"?&">>,<<"?*">>, >>> > <<0,107>>, >>> > <<0,106>>, >>> > <<0,61>>, >>> > <<"?#">>,<<"?'">>,<<"?%">>,<<"?)">>, >>> > <<0,103>>, >>> > <<0,64>>, >>> > <<0,60>>, >>> > <<"?\n">>, >>> > <<192,20>>, >>> > <<0,57>>, >>> > <<0,56>>, >>> > <<192,5>>, >>> > <<192,15>>, >>> > <<0,53>>, >>> > <<"?\b">>, >>> > <<192,18>>, >>> > <<0,22>>, >>> > <<0,19>>, >>> > <<192,3>>, >>> > <<"?\r">>, >>> > <<0,10>>, >>> > <<"?\t">>, >>> > <<192,19>>, >>> > <<0,51>>, >>> > <<0,50>>, >>> > <<192,4>>, >>> > <<192,14>>, >>> > <<0,47>>, >>> > <<192,7>>, >>> > <<192,17>>, >>> > <<0,5>>, >>> > <<0,4>>, >>> > <<0,21>>, >>> > <<192,2>>, >>> > <<"?\f">>, >>> > <<0,9>>], >>> > #Fun,true,268435456,false,undefined, >>> > undefined,false,undefined,undefined}, >>> > [{reuseaddr,true},{active,false}], >>> > {socket_options,list,0,0,0,false}, >>> > [{reuseaddr,true}, >>> > {packet_size,0}, >>> > {packet,0}, >>> > {header,0}, >>> > {active,false}, >>> > {mode,binary}], >>> > {ssl_udp,ssl_udp,udp_closed,udp_error}}}}, >>> > accept,10000,infinity], >>> > [{file,"ssl_udp.erl"},{line,149}]}, >>> > {dtls_test,accept,1, >>> > [{file,"src/dtls_test.erl"},{line,70}]}]}} >>> > >>> > >>> > _______________________________________________ >>> > erlang-questions mailing list >>> > erlang-questions@REDACTED >>> > http://erlang.org/mailman/listinfo/erlang-questions >>> > >>> >>> -- >>> -- >>> Dipl. Inform. >>> Andreas Schultz >>> >>> email: as@REDACTED >>> phone: +49-391-819099-224 >>> mobil: +49-170-2226073 >>> >>> ------------------- enabling your networks ------------------- >>> >>> Travelping GmbH phone: +49-391-819099229 >>> Roentgenstr. 13 fax: +49-391-819099299 >>> D-39108 Magdeburg email: info@REDACTED >>> GERMANY web: http://www.travelping.com >>> >>> Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 >>> Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 >>> -------------------------------------------------------------- >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Thu Mar 6 02:02:25 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Thu, 6 Mar 2014 14:02:25 +1300 Subject: [erlang-questions] case expression scope In-Reply-To: References: <1393872363.2957.YahooMailNeo@web140106.mail.bf1.yahoo.com> <2748B8D1-EB91-4323-B5F6-C27DB092055D@cs.otago.ac.nz> <25BB9783-2E82-437F-BAB8-61DF2A3EBC08@cs.otago.ac.nz> Message-ID: <96995A73-D75D-4663-A293-F8CBFA2E923F@cs.otago.ac.nz> > Le 5 mars 2014 ? 21:48, Szoboszlay D?niel a ?crit : >> And once we are there, there are some other nice tricks we could do with scopes. Consider this real life example: https://github.com/rebar/rebar/blob/master/src/rebar_core.erl#L182-L263 - this function performs a lot of sequential tasks and generates a series of Config variables in the meantime (Config1, Config2, ...). I don't have a problem with multipage functions that have lots of clauses. I have a serious problem with clauses that I can't see all at once. These days I have a lovely big screen so I can get 60 lines on screen at once, which is also about what I can see on a sheet of paper. This function is one 82-line clause. There are a number of little bits that bug me about it. For example %% Make sure the CWD is reset properly; processing the dirs may have %% caused it to change ok = file:set_cwd(Dir), occurs twice. That tells me that the code is in the wrong place: if "processing the dirs may" cause an *unwanted* change to the current directly, then it *shouldn't*. It would be interesting to change the design, but the comments don't tell me *where* the current directory might be changed. Oddly enough, an issue about changing the current working directory came up recently in the SWI Prolog mailing list. The answer was "These days, SWI Prolog is multithreaded, so after your program starts up, DON'T change the current working directory." The file server's notion of the current working directory counts as *shared mutable state*, the kind of thing Erlang is supposed to help us avoid. Just looking at this function, it is far from obvious that Dir ever _was_ the current directory. Let us suppose that it was. Then there is a snag. The pattern let saved_cwd = getcwd() in $( do something chdir(saved_cwd) $) can fail. That's why modern UNIX systems have fd = open(".", O_RONLY); ... fchdir(fd); If I were doing anything in Erlang where I needed to change "the" current working directory, I'd put the information in the process dictionary Now let's return to the issue of variable names and possible collisions between them. I see a lot of Config variables, and I haven't a clue what they are, and I especially haven't a clue how the execute_* functions are supposed to be updating them. The documentation for execute/5, for example, says nothing about the result. What a 'Config' *is* and how it's processed are core concepts in this file, but nothing in the file documents them. When it comes to trying to read the code, _this_ is a far more serious issue than 'case'; it's even more serious than the length of the function. From txrev319@REDACTED Thu Mar 6 06:42:37 2014 From: txrev319@REDACTED (t x) Date: Wed, 5 Mar 2014 21:42:37 -0800 Subject: [erlang-questions] erl -sname, emacs, connect to repl In-Reply-To: References: Message-ID: Everything appears to work. Thanks! On Wed, Mar 5, 2014 at 6:36 AM, Steve Vinoski wrote: > > > > On Wed, Mar 5, 2014 at 4:37 AM, t x wrote: >> >> Hi, >> >> >> Given: >> >> machine name: server >> user account: x >> >> x@REDACTED$ erl -sname gandalf >> ## we now have an erl running >> >> >> Question: >> >> Now, from emacs, how do I tell emacs "connect a repl to the node >> with sname gandalf" instead of "fire up a new session of erl" ? > > > If you give a prefix arg to erlang-shell, it reads arguments from the > minibuffer. The tricky part is that you also have to set the TERM env var. > So, if you type > > C-u M-x erlang-shell > > you'll be prompted with "Erlang command: " to enter the erlang shell > command. At the prompt enter something like the following: > > erl -sname bilbo -remsh gandalf@REDACTED -env TERM vt100 > > The "-env TERM vt100" part is very important, since if you leave it off, the > new node will start just fine but will silently fail to connect to the other > node. > > --steve From txrev319@REDACTED Thu Mar 6 07:46:26 2014 From: txrev319@REDACTED (t x) Date: Wed, 5 Mar 2014 22:46:26 -0800 Subject: [erlang-questions] pre-map erlang, json, list of kv pairs Message-ID: Hi, I'm studying https://github.com/joearms/ezwebframe/blob/master/demos/clocks/clock1.html#L81-L88 From this, I have a question: In per-map (i.e. before E17) erlang, when json maps are convereted to Erlang data structures, do they become lists of key-value pairs? On one hand this seems weird, but on the other hand, since pre-17 Erlang doesn't have maps, how else can maps be represented? Thanks! From prof3ta@REDACTED Thu Mar 6 10:15:55 2014 From: prof3ta@REDACTED (Roberto Aloi) Date: Thu, 6 Mar 2014 10:15:55 +0100 Subject: [erlang-questions] mfa/0 built-in type and behaviour in R15/R16 Message-ID: Hi, Whilst R15B03 prevents you from redefine the mfa() built-in type: R15$ erlc recon_trace.erl recon_trace.erl:182: type mfa() is a builtin type; it cannot be redefined R16 doesn't complain at all and allows the type to be redefined. Is this intentional? I looked at erl_lint in both Erlang versions and, even if mfa/0 seems to be defined as a default type in both cases, the type_def function behaves very differently in the two Erlang versions. Looking at the dict:is_key/2 function called as part of the top-level case in the type_def function you get: R15B03: $ erlc recon_trace.erl (<0.25.0>) call dict:is_key({mfa,0},{dict,67,16,16,8,80,48, {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}, {{[[{boolean,0}|-1], [{'fun',0}|-1], [{function,0}|-1], [{no_return,0}|-1], [{shellfun,0},{line,{"recon_trace.erl",165}}], [{fn,0},{line,{"recon_trace.erl",180}}]], [], [[{'fun',2}|-1]], [[{iodata,0}|-1],[{mfa,0}|-1]], [[{char,0}|-1], [{identifier,0}|-1], [{integer,0}|-1], [{neg_integer,0}|-1], [{non_neg_integer,0}|-1], [{number,0}|-1], [{pos_integer,0}|-1]], [[{matchspec,0},{line,{"recon_trace.erl",164}}], [{millisecs,0},{line,{"recon_trace.erl",166}}], [{pidspec,0},{line,{"recon_trace.erl",167}}], [{max_traces,0},{line,{"recon_trace.erl",168}}], [{options,0},{line,{"recon_trace.erl",172}}], [{args,0},{line,{"recon_trace.erl",181}}], [{num_matches,0},{line,{"recon_trace.erl",183}}]], [[{dict,0}|-1], [{float,0}|-1], [{gb_set,0}|-1], [{iolist,0}|-1], [{list,0}|-1], [{maybe_improper_list,0}|-1], [{nonempty_list,0}|-1], [{nonempty_maybe_improper_list,0}|-1], [{pid,0}|-1], [{port,0}|-1], [{set,0}|-1], [{timeout,0}|-1], [{mod,0},{line,{"recon_trace.erl",179}}]], [[{byte,0}|-1], [{gb_tree,0}|-1], [{module,0}|-1], [{node,0}|-1], [{none,0}|-1], [{queue,0}|-1], [{reference,0}|-1], [{max_rate,0},{line,{"recon_trace.erl",169}}]], [[{atom,1}|-1], [{maybe_improper_list,2}|-1], [{nonempty_improper_list,2}|-1], [{nonempty_maybe_improper_list,2}|-1]], [[{bitstring,0}|-1], [{nonempty_string,0}|-1], [{range,2}|-1], [{string,0}|-1]], [[{digraph,0}|-1],[{max,0},{line,{"recon_trace.erl",182}}]], [[{any,0}|-1],[{arity,0}|-1],[{array,0}|-1],[{binary,0}|-1]], [], [[{binary,2}|-1],[{integer,1}|-1],[{var,1}|-1]], [[{bool,0}|-1],[{nil,0}|-1]], [[{atom,0}|-1],[{list,1}|-1],[{nonempty_list,1}|-1],[{term,0}|-1]]}}}) (<0.25.0>) returned from dict:is_key/2 -> true Indeed, in this case mfa/0 is part of the State and cannot be redefined, so the right branch of the case is executed. R16B03: $ erlc recon_trace.erl (<0.25.0>) call dict:is_key({mfa,0},{dict,12,16,16,8,80,48, {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}, {{[[{shellfun,0}|{typeinfo,type,[{line,{"recon_trace.erl",165}}]}], [{fn,0}|{typeinfo,type,[{line,{"recon_trace.erl",180}}]}]], [],[],[],[], [[{matchspec,0}|{typeinfo,type,[{line,{"recon_trace.erl",164}}]}], [{millisecs,0}|{typeinfo,type,[{line,{"recon_trace.erl",166}}]}], [{pidspec,0}|{typeinfo,type,[{line,{"recon_trace.erl",167}}]}], [{max_traces,0}|{typeinfo,type,[{line,{"recon_trace.erl",168}}]}], [{options,0}|{typeinfo,type,[{line,{"recon_trace.erl",172}}]}], [{args,0}|{typeinfo,type,[{line,{"recon_trace.erl",181}}]}], [{num_matches,0}|{typeinfo,type,[{line,{"recon_trace.erl",183}}]}]], [[{mod,0}|{typeinfo,type,[{line,{"recon_trace.erl",179}}]}]], [[{max_rate,0}|{typeinfo,type,[{line,{"recon_trace.erl",169}}]}]], [],[], [[{max,0}|{typeinfo,type,[{line,{"recon_trace.erl",182}}]}]], [],[],[],[],[]}}}) (<0.25.0>) returned from dict:is_key/2 -> false It looks to me like the default types are not part of the state yet? I need some coffee now. -- Roberto Aloi --- Website: http://roberto-aloi.com Twitter: @robertoaloi -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas@REDACTED Thu Mar 6 11:15:46 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Thu, 6 Mar 2014 11:15:46 +0100 Subject: [erlang-questions] Fwd: FW: Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: <58912684E2630B45963406CF7D8C52581C369E4D@ESESSMB103.ericsson.se> References: <58912684E2630B45963406CF7D8C52581C369E4D@ESESSMB103.ericsson.se> Message-ID: Admittedly, we did not communicate those (intentional) incompatibilities effectively prior to the release. Hence, we will make some adaptations to ease the transition. They will be published in the master branch of the erlang/otp GitHub repository at the beginning of next week. Re: 1. utf-8 is now the default encoding The default encoding of Erlang files has been changed from ISO-8859-1 (Latin-1) to UTF-8. The encoding of XML files has also been changed to UTF-8. In OTP 17.0-rc{1,2}, a file that is encoded in latin-1 and contains non-UTF-8/non-ASCII-7 characters, causes a compiler error similar to the following: tst.erl:1: cannot parse file, giving up tst.erl:1: no module definition tst.erl:1: cannot translate from UTF-8 In OTP 17.0, if a file is encoded in latin-1 and contains non-UTF-8/non-ASCII characters, but does not declare the encoding with a magic encoding comment at the beginning of the file, epp (the Erlang code pre-processor) issues a deprecation warning, and processes the file again, assuming latin-1 encoding. In a future major version, preferably in OTP 18, the deprecation warning will be turned into an error again. That is, only UTF-8 encoded files, and files that declare the source code encoding at the beginning of the source code file, will be accepted. NOTE: The deprecation workaround in OTP 17 does only apply to Erlang source code files, but not to other files; e.g., yecc files and files read by file:consult/1. For more information, see the STDLIB User's Guide, 2 Using Unicode in Erlang [1] and the STDLIB Reference Manual, epp [2]. [1] http://www.erlang.org/doc/apps/stdlib/unicode_usage.html [2] http://www.erlang.org/doc/man/epp.html Re: 2. Dialyzer dislikes queue(), dict(), ... OTP-10342 The pre-defined types array/0, dict/0, digraph/0, gb_set/0, gb_tree/0, queue/0, set/0, and tid/0 have been deprecated. They will be removed in Erlang/OTP 18.0. Instead the types array:array/0, dict:dict/0, digraph:graph/0, gb_set:set/0, gb_tree:tree/0, queue:queue/0, sets:set/0, and ets:tid/0 can be used. (Note: it has always been necessary to use ets:tid/0.) It is allowed in Erlang/OTP 17 to locally re-define the types array/0, dict/0, and so on. New types array:array/1, dict:dict/2, gb_sets:set/1, gb_trees:tree/2, queue:queue/1, and sets:set/1 have been added. A compiler option, nowarn_deprecated_type, has been introduced. By including the attribute -compile(nowarn_deprecated_type). in an Erlang source file, warnings about deprecated types can be avoided in Erlang/OTP 17.0. The option can also be given as a compiler flag: erlc +nowarn_deprecated_type file.erl Andreas Schumacher, Erlang/OTP, Ericsson AB ---------- Forwarded message ---------- From: Andreas Schumacher Date: Thu, Mar 6, 2014 at 9:56 AM Subject: FW: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 To: "andreasschu@REDACTED" *From:* erlang-questions-bounces@REDACTED [mailto: erlang-questions-bounces@REDACTED] *On Behalf Of *Jesper Louis Andersen *Sent:* den 28 februari 2014 00:07 *To:* Erlang (E-mail) *Subject:* [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2 Release 17.0 brings two changes which prove to take some work getting around. 1. utf-8 is now the default encoding. This is a rather insignificant change. The source code which uses latin1 can be fixed by one of three ways: * Tell the compiler the file is latin1. This won't work going forward but works now. * Change the file to utf-8. This won't work going backward a long way. But it will work going backwards for a bit. * Change the file to ASCII. This works both backward and forward as long as we want. This is a benign problem. I have tried compiling some projects and it turns out there are numerous repositories which needs fixing now. But the fix is rather simple. 2. Dialyzer dislikes queue(), dict(), ... Dialyzer now prefers using queue:queue() and the like. This is *definitely* the right thing to support as it is much more consistent with the rest of the system and doesn't treat certain types as magically introduced types. -module(z). -export([f/1]). -spec f(queue:queue()) -> queue:queue(). f(Q) -> queue:in(3, Q). Which is nice, but this doesn't work on R16B03: z.erl:5: referring to built-in type queue as a remote type; please take out the module name z.erl:5: referring to built-in type queue as a remote type; please take out the module name So here, I have no way of getting my source code to work with both R16 and 17.0 easily. There is no transition period so-to-speak. Many projects run with warnings-as-errors and they are in trouble: * They can't compile * They can remove the warnings-as-errors but this defeats the purpose * They will have warnings spewed out over the console all the time In the case of crypto:hash/2, we had somewhat the same situation. Prominent projects like Yaws, and lesser projects like Emysql has EPP macros in place as well as detection in order to figure out what to do. Or you can disable the warnings in this case specifically for this. But can I do the same with wrong type specs? Also, this workaround is done in almost every project out there, which is darn irritating. I don't know what we need to solve this. At one point, I would really like to have a set of feature flags http://www.lispworks.com/documentation/HyperSpec/Body/v_featur.htm , ZFS, ... where you have a way to compile-time scrutinize what your environment supports. Another way to solve it is the variant Go uses, namely "build constraints" http://golang.org/pkg/go/build/#pkg-overview which will mention under which circumstances to include a file as a part of an application. This would allow for easy handling of crypto:hash/2, but I do note it will fail on the dialyzer problem. It looks like the only sane way to solve that is to allow both queue() and queue:queue() as aliases for a major release and then proceed to remove queue(). Am I completely wrong here? I can accept languages evolve and that Release 17 has maps which will be used and break a lot of software for R16 quickly. But I also feel we should have some way of having a process so there is a way to handle this gracefully going forward. It is natural for libraries and languages to evolve and break compatibility. Yet, it should be easy to handle for programmers. There is much time wasted, which could be used better were there a nice solution. Thoughts? -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Thu Mar 6 11:25:06 2014 From: roger@REDACTED (Roger Lipscombe) Date: Thu, 6 Mar 2014 10:25:06 +0000 Subject: [erlang-questions] slave:start_link/3 hangs if it can't start the slave Message-ID: If I start a slave node as follows: Args = "-pa ebin -s spartacus -s init stop -config whoops", {ok, Node} = slave:start_link(localhost, spartacus, Args). ...and the config file "whoops.config" doesn't exist, the call to slave:start_link/3 hangs (it probably times out, but I got impatient). If I run "erl -pa ebin -s spartacus -s init stop -config whoops", with the missing config file, I get an error immediately. So: 1. Can I detect that the slave failed to start without waiting for a timeout? 2. Alternatively, can I shorten the timeout period? 3. Should I just use "open_port({spawn, ..." instead? OTOH, If I _do_ use open_port, how do I get the child erlang VM to close when I kill the parent (which is actually an escript) using Ctrl+C? Regards, Roger. From z@REDACTED Thu Mar 6 11:50:05 2014 From: z@REDACTED (Danil Zagoskin) Date: Thu, 6 Mar 2014 14:50:05 +0400 Subject: [erlang-questions] Making SSL fail silently Message-ID: Hello! My application is listening SSL port using ssl:listen, ssl:transport_accept and ssl:ssl_accept (indeed it uses some old patched mochiweb). Erlang/OTP release is R16B02. I use SASL for error logging. Due to existence of network scanners, network errors and buggy clients some of connections fail to negotiate. This leads to two kind of log entries: 1. "insufficient security", etc. 2. Crash reports due to a function_clause error in tls_v1:enum_to_oid(0) (this may be not the only one, but definitely the most popular) First one seems to be fixed by {log_alert, false} ssl option. Second one keeps flooding logs with huge state printouts. So, my question is: How to make all SSL-related troubles not to generate error reports? Simple {error, handshake_failed} returned by one of accepting functions would be enough. Maybe this is useful: =ERROR REPORT==== 6-Mar-2014::05:35:19 === ** State machine <0.19029.3> terminating ** Last message in was {tcp,#Port<0.68651>, <<22,3,1,0,209,1,0,0,205,3,1,83,23,208,215,254, 236,125,231,33,138,62,193,101,12,193,176,102, 114,62,166,230,143,36,171,53,199,66,68,65,164, 166,184,0,0,100,0,51,0,50,0,57,0,56,0,22,0,19, 192,19,192,9,192,20,192,10,192,18,192,8,0,47,0, 53,0,10,0,21,0,18,0,61,0,60,0,103,0,64,0,107,0, 106,192,17,192,7,0,150,0,154,0,153,0,65,0,132,0, 69,0,68,0,136,0,135,0,186,0,190,0,189,0,192,0, 196,0,195,192,60,192,68,192,66,192,61,192,69, 192,67,0,9,0,5,0,4,0,255,1,0,0,64,0,10,0,54,0, 52,0,0,0,1,0,2,0,3,0,4,0,5,0,6,0,7,0,8,0,9,0,10, 0,11,0,12,0,13,0,14,0,15,0,16,0,17,0,18,0,19,0, 20,0,21,0,22,0,23,0,24,0,25,0,11,0,2,1,0>>} ** When State == hello ** Data == {state,server, LOTS_OF_STUFF_SKIPPED} ** Reason for termination = ** {function_clause,[{tls_v1,enum_to_oid,[0],[{file,"tls_v1.erl"},{line,404}]}, {ssl_handshake,'-dec_hello_extensions/2-blc$^1/1-0-',1, [{file,"ssl_handshake.erl"},{line,1467}]}, {ssl_handshake,dec_hello_extensions,2, [{file,"ssl_handshake.erl"},{line,1467}]}, {tls_handshake,decode_handshake,3, [{file,"tls_handshake.erl"},{line,237}]}, {tls_handshake,get_tls_handshake_aux,3, [{file,"tls_handshake.erl"},{line,204}]}, {tls_connection,next_state,4, [{file,"tls_connection.erl"}, {line,2546}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}, {proc_lib,init_p_do_apply,3, [{file,"proc_lib.erl"},{line,239}]}]} -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Thu Mar 6 15:08:40 2014 From: txrev319@REDACTED (t x) Date: Thu, 6 Mar 2014 06:08:40 -0800 Subject: [erlang-questions] idiomatic way to do hot code reloading with erlang.mk + relx Message-ID: Hi, This is what I currently understand: * how to use erlang.mk (from playing with examples in cowboy) * how to use relx (from playing with examples in cowboy) * how hot code reloading works in Erlang (from chapter in Programming Erlang) * how to attach my emacs to an existing erlang node (via help from mailing list) This is what I currently do not understand: * suppose I have something I'm running via erlang.mk + relx, i.e.: make; ./_rel/bin/websocket_example console * how do I: 1) give it a -sname so I can attach to it from another erlang node? 2) do hot code reloading on something that is already running via relx In particular, I'd love to read a guide / tutorial on what to keep in mind, gotchas, tips / tricks, etc ... Thanks! From jesper.louis.andersen@REDACTED Thu Mar 6 15:15:51 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 6 Mar 2014 15:15:51 +0100 Subject: [erlang-questions] pre-map erlang, json, list of kv pairs In-Reply-To: References: <40FA2725-487F-4CC6-AE2F-18DC1E6B9A03@erlang-solutions.com> Message-ID: <474F174F-1ABC-4F22-9244-C1EA76B1E15E@erlang-solutions.com> On 06 Mar 2014, at 15:04, t x wrote: > I'm already using r17. Are there any json libraries that take > advantage of this yet? No, you are using 17.0-rc2 which is a release candidate. I don?t know of any JSON library taking advantage of maps yet. I expect code to pick up maps around the 17.0 release and it will probably be in general use around 17.2 when the major bugs have been weeded out. Maps is a feature that will take time to adopt. It will not happen magically over the course of the first release. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Thu Mar 6 15:33:35 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 6 Mar 2014 15:33:35 +0100 Subject: [erlang-questions] warn_missing_spec Message-ID: Hi! This has been asked before, but I can't find any answer. The compiler's warn_missing_spec option is not documented, but at least Kostis is recommending it. I think it's an useful option too, and I wonder why it isn't made official. best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Mar 6 15:38:06 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Mar 2014 15:38:06 +0100 Subject: [erlang-questions] warn_missing_spec In-Reply-To: References: Message-ID: <5318884E.7010509@ninenines.eu> I would like a +warn_missing_spec_in_exported_functions option. I don't want to write specs for every single small function in my module, this is a waste of time. On 03/06/2014 03:33 PM, Vlad Dumitrescu wrote: > Hi! > > This has been asked before, but I can't find any answer. The compiler's > warn_missing_spec option is not documented, but at least Kostis is > recommending it. > > I think it's an useful option too, and I wonder why it isn't made official. > > best regards, > Vlad > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From kostis@REDACTED Thu Mar 6 15:46:44 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Thu, 06 Mar 2014 16:46:44 +0200 Subject: [erlang-questions] warn_missing_spec In-Reply-To: <5318884E.7010509@ninenines.eu> References: <5318884E.7010509@ninenines.eu> Message-ID: <53188A54.4000201@cs.ntua.gr> On 03/06/2014 04:38 PM, Lo?c Hoguin wrote: > I would like a +warn_missing_spec_in_exported_functions option. I don't > want to write specs for every single small function in my module, this > is a waste of time. This is what +warn_missing_spec actually does. (*) There is also a +warn_missing_spec_all which warns you because you have not done what you do not want to do ;) Kostis (*) I realize the current names are not very fortunate, but I could not come up with something precise and concise at the same time. Suggestions welcome! From essen@REDACTED Thu Mar 6 15:48:23 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Mar 2014 15:48:23 +0100 Subject: [erlang-questions] warn_missing_spec In-Reply-To: <53188A54.4000201@cs.ntua.gr> References: <5318884E.7010509@ninenines.eu> <53188A54.4000201@cs.ntua.gr> Message-ID: <53188AB7.3040307@ninenines.eu> On 03/06/2014 03:46 PM, Kostis Sagonas wrote: > On 03/06/2014 04:38 PM, Lo?c Hoguin wrote: >> I would like a +warn_missing_spec_in_exported_functions option. I don't >> want to write specs for every single small function in my module, this >> is a waste of time. > > This is what +warn_missing_spec actually does. (*) Thanks. Not sure why I ended up disabling it by default then. I will have to try again! -- Lo?c Hoguin http://ninenines.eu From andreas@REDACTED Thu Mar 6 16:35:04 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Thu, 6 Mar 2014 16:35:04 +0100 Subject: [erlang-questions] Fwd: FW: [erlang-bugs] Bug in TFTP client implementation? In-Reply-To: <58912684E2630B45963406CF7D8C52581C36A3C4@ESESSMB103.ericsson.se> References: <1394034794.4361.57.camel@ax-sze> <58912684E2630B45963406CF7D8C52581C36A3C4@ESESSMB103.ericsson.se> Message-ID: Unfortunately, RFC 1350 - The TFTP Protocol (Revision 2) - does not address this issue. Nevertheless, based on TFTP's initial connection protocol and its relation to the underlying protocols, the Erlang/OTP TFTP client behaviour seems to be sensible in this case. According to the initial connection protocol, which is used to establish a "pseudo" connection between the client and the server, the client sends its first datagram to the server's well-known port (69). The server sends its packet (here: ACK) from a freshly allocated ephemeral port, and all future packets to the server should be sent to this port. Consequently, if the server decides to allocate that port on a different host, then it seems sensible that the client uses the server's unique socket 3-tuple (protocol, ip-address, port) for all future packets to that server. In short, there are no plans to change the current TFTP client behaviour, unless further information is provided, which indicates that a different behaviour would be more appropriate. Andreas Schumacher, Erlang/OTP, Ericsson AB -----Original Message----- From: erlang-bugs-bounces@REDACTED [mailto:erlang-bugs-bounces@REDACTED] On Behalf Of Stefan Zegenhagen Sent: den 5 mars 2014 16:53 To: erlang-bugs@REDACTED Subject: [erlang-bugs] Bug in TFTP client implementation? Dear all, There might be a bug in erlang's TFTP client implementation that prevents erlang to successfully transfer files over IPv6 with many Microsoft(R) Windows TFTP servers. Those TFTP servers (most of them are available free of charge) are capable to bind to a single IP address only, not to an interface. The problem arises when the server has statically configured IPv6 addresses as well as automatically configured ones. Here's the step-by-step error description: 1. start the Windows TFTP server and bind to the static IPv6 server address 2. call tftp:read_file(...) to download a file from the TFTP server using the static IPv6 server address 3. transmission of packets is as follows: => : Write Request => : Ack, Port #xxxx => :xxxx : Data block=0 It appears that the TFTP servers are unwilling (or unable) to respond from the IPv6 address they have been contacted at. Furthermore it seems that the erlang TFTP client uses the source IPv6 of the received Ack packet in all further communication. Since the TFTP server is not listening to its dynamic IPv6 address (from which it always responds, though), the data blocks transmitted after the initial successful "connection establishment" are never received by the TFTP server. I agree that the TFTP server should respond from the IPv6 address it was contacted at. However, I also think it to be a questionable behaviour to change to a different IP address for the actual data transfer. Kind regards, -- Dr. Stefan Zegenhagen arcutronix GmbH Garbsener Landstr. 10 30419 Hannover Germany Tel: +49 511 277-2734 Fax: +49 511 277-2709 Email: stefan.zegenhagen@REDACTED Web: www.arcutronix.com *Synchronize the Ethernet* General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer - Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht Hannover; Ust-Id: DE257551767. Please consider the environment before printing this message. _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rj@REDACTED Thu Mar 6 17:17:31 2014 From: rj@REDACTED (Richard Jones) Date: Thu, 6 Mar 2014 16:17:31 +0000 Subject: [erlang-questions] Nomenclature straw-poll Message-ID: Java, Scala & Clojure are all JVM languages / they all run on the JVM. Erlang, LFE & Elixir all run on the: - EVM - BEAM - Erlang VM - Other (please specify) I started saying EVM, because it has VM in it and sounds modern and trendy. BEAM is a bit abstract. RJ From egil@REDACTED Thu Mar 6 17:23:37 2014 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Thu, 6 Mar 2014 17:23:37 +0100 Subject: [erlang-questions] Nomenclature straw-poll In-Reply-To: References: Message-ID: <5318A109.2070206@erlang.org> On 2014-03-06 17:17, Richard Jones wrote: > Java, Scala & Clojure are all JVM languages / they all run on the JVM. > > Erlang, LFE & Elixir all run on the: > > - EVM > - BEAM > - Erlang VM > - Other (please specify) > > > I started saying EVM, because it has VM in it and sounds modern and trendy. > BEAM is a bit abstract. BEAM is the correct one. EVM and Erlang VM is used when people don't understand what we talk about. =) > > > RJ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From n.oxyde@REDACTED Thu Mar 6 17:24:40 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 6 Mar 2014 17:24:40 +0100 Subject: [erlang-questions] Nomenclature straw-poll In-Reply-To: References: Message-ID: <5FEBAF29-4BE3-4D30-A213-4B0C054D5955@gmail.com> Java has no ?lang? in it. We should rename it Jalang. -- Anthony Ramine Le 6 mars 2014 ? 17:17, Richard Jones a ?crit : > BEAM is a bit abstract. From n.oxyde@REDACTED Thu Mar 6 17:33:41 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Thu, 6 Mar 2014 17:33:41 +0100 Subject: [erlang-questions] Nomenclature straw-poll In-Reply-To: References: Message-ID: Also, 'the JVM' can actually refer to multiple different VMs, from different vendors, it would be better for them to have actual names, like Dalvik. -- Anthony Ramine Le 6 mars 2014 ? 17:17, Richard Jones a ?crit : > Java, Scala & Clojure are all JVM languages / they all run on the JVM. From peerst@REDACTED Thu Mar 6 17:35:11 2014 From: peerst@REDACTED (Peer Stritzinger) Date: Thu, 6 Mar 2014 17:35:11 +0100 Subject: [erlang-questions] Why the name Erlang/OTP is good Message-ID: Late to the party and by all means don't want to restart the discussion, just a short dialog with one of my customers using Erlang: Me: ... its called Erlang/OTP, namead after a danish mathematician Customer: What does OTP stand for? Me: It stands for Open Telecom Platform, Erlang was initially used for programming phone switches by Ericsson. They build a ATM switch that has nine nines availabaility with it (five nines is normal) thats about 30 milliseconds per year! Me: The features they built into it to achieve this will enable us to build very high available and robust systems too, btw the 30 milliseconds is including updates! Customer: How's this possible?? Me: Erlang hast lowlevel onstructs leveraged by OTP to .... bla bla bla ... If you can't sell Erlang to a customer/boss because it has OTP in it, its either hopeless or you can't sell anything. I like the name OTP because it gives me a nice historical intro to explain why Erlang/OTP is great. Just saying. Cheers, -- Peer From kenneth.lundin@REDACTED Thu Mar 6 17:39:31 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 6 Mar 2014 17:39:31 +0100 Subject: [erlang-questions] Nomenclature straw-poll In-Reply-To: <5318A109.2070206@erlang.org> References: <5318A109.2070206@erlang.org> Message-ID: I think Beam is the correct name of the current implementation of the Erlang VM. And there are no other complete and in practice useful EVMs that I know of. My experience is that starting with talking about Beam will lead to confusion if you are not talking to experienced Erlangers. The name of the executable is beam or beam.smp So if you are talkin about what you can observe with top, ps etc. Beam is the right thing. /Kenneth On Mar 6, 2014 5:23 PM, "Bj?rn-Egil Dahlberg" wrote: > On 2014-03-06 17:17, Richard Jones wrote: > >> Java, Scala & Clojure are all JVM languages / they all run on the JVM. >> >> Erlang, LFE & Elixir all run on the: >> >> - EVM >> - BEAM >> - Erlang VM >> - Other (please specify) >> >> >> I started saying EVM, because it has VM in it and sounds modern and >> trendy. >> BEAM is a bit abstract. >> > BEAM is the correct one. > > EVM and Erlang VM is used when people don't understand what we talk about. > =) > > >> >> RJ >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Thu Mar 6 18:34:50 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Thu, 06 Mar 2014 18:34:50 +0100 Subject: [erlang-questions] Nomenclature straw-poll In-Reply-To: References: Message-ID: <5318B1BA.9090407@ninenines.eu> Use Erlang VM when you are generally talking about the VM you are running on (whether BEAM or LingVM). Use BEAM when talking about specifics of this VM, like options, allocators, schedulers, and pretty much everything really. EVM is the Elixir VM. It has "better syntax" and metaprogramming and stuff and doesn't exist. On 03/06/2014 05:17 PM, Richard Jones wrote: > Java, Scala & Clojure are all JVM languages / they all run on the JVM. > > Erlang, LFE & Elixir all run on the: > > - EVM > - BEAM > - Erlang VM > - Other (please specify) > > > I started saying EVM, because it has VM in it and sounds modern and trendy. > BEAM is a bit abstract. > > > RJ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From jose.valim@REDACTED Thu Mar 6 18:50:33 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Thu, 6 Mar 2014 18:50:33 +0100 Subject: [erlang-questions] Nomenclature straw-poll In-Reply-To: <5318B1BA.9090407@ninenines.eu> References: <5318B1BA.9090407@ninenines.eu> Message-ID: > > EVM is the Elixir VM. It has "better syntax" and metaprogramming and stuff > and doesn't exist. > What?! That doesn't make any sense. I have heard only Joe Armstrong calling it EVMand, although it is in the post he talks about Elixir, he still calls it *Erlang* Virtual Machine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From juanjo@REDACTED Thu Mar 6 19:32:27 2014 From: juanjo@REDACTED (Juan Jose Comellas) Date: Thu, 6 Mar 2014 15:32:27 -0300 Subject: [erlang-questions] pre-map erlang, json, list of kv pairs In-Reply-To: <474F174F-1ABC-4F22-9244-C1EA76B1E15E@erlang-solutions.com> References: <40FA2725-487F-4CC6-AE2F-18DC1E6B9A03@erlang-solutions.com> <474F174F-1ABC-4F22-9244-C1EA76B1E15E@erlang-solutions.com> Message-ID: As Jesper said, there is no official Erlang release with support for maps, so most JSON libraries still represent parsed JSON documents as k/v lists. I'm currently working on a project that uses lots of JSON-like documents and in order to preserve my sanity I wrote kvlists, which should greatly simplify the manipulation of JSON documents decoded by the jsx library. Check the examples and let me know if there is any particular functionality that you'd find useful and is not already there. On Thu, Mar 6, 2014 at 11:15 AM, Jesper Louis Andersen < jesper.louis.andersen@REDACTED> wrote: > > On 06 Mar 2014, at 15:04, t x wrote: > > I'm already using r17. Are there any json libraries that take > advantage of this yet? > > > No, you are using 17.0-rc2 which is a release candidate. I don?t know of > any JSON library taking advantage of maps yet. I expect code to pick up > maps around the 17.0 release and it will probably be in general use around > 17.2 when the major bugs have been weeded out. > > Maps is a feature that will take time to adopt. It will not happen > magically over the course of the first release. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Mar 6 20:44:16 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 6 Mar 2014 20:44:16 +0100 Subject: [erlang-questions] FW: Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: <58912684E2630B45963406CF7D8C52581C369E4D@ESESSMB103.ericsson.se> Message-ID: On Thu, Mar 6, 2014 at 11:15 AM, Andreas Schumacher wrote: > Admittedly, we did not communicate those (intentional) incompatibilities > effectively prior to the release. Thank you (and all of the OTP team) for making a nice solution to this problem. I really like the path you took here. It is sensible and gives programmers a nice upgrade path from earlier Erlang releases and up to release 17.0. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Thu Mar 6 21:01:08 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Thu, 6 Mar 2014 21:01:08 +0100 Subject: [erlang-questions] idiomatic way to do hot code reloading with erlang.mk + relx In-Reply-To: References: Message-ID: On Thu, Mar 6, 2014 at 3:08 PM, t x wrote: > * how do I: > > 1) give it a -sname so I can attach to it from another erlang node? > > 2) do hot code reloading on something that is already running via relx > Okie, you normally have something like this in relx releases: app/bin/app remote_console if you have given your original app node a name (I often pick app@REDACTED). This allows you to have a remote console on the Erlang node and you can then hot-deploy modules into the running node by placing a .beam in the load path of the project and then executing l(Module). For more general perusal of this consult the appropriate man-page: erl -man code For development, you might consider something like https://github.com/rustyio/sync which is an even faster development path. This was 1), now for 2) and further on. There is also a concept called release upgrades. Fred did an amazing job at handling them: http://learnyousomeerlang.com/relups they allow you to upgrade systems which you for some reason cannot shut down between upgrades. There are a few places where this is necessary, but I would recommend designing your system in a way to avoid them if possible. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela.andin@REDACTED Thu Mar 6 22:39:22 2014 From: ingela.andin@REDACTED (Ingela Andin) Date: Thu, 6 Mar 2014 22:39:22 +0100 Subject: [erlang-questions] Making SSL fail silently In-Reply-To: References: Message-ID: Hi! 2014-03-06 11:50 GMT+01:00 Danil Zagoskin : > Hello! > > My application is listening SSL port > using ssl:listen, ssl:transport_accept and ssl:ssl_accept (indeed it uses > some old patched mochiweb). > Erlang/OTP release is R16B02. > I use SASL for error logging. > > Due to existence of network scanners, network errors and buggy clients > some of connections fail to negotiate. This leads to two kind of log > entries: > 1. "insufficient security", etc. > 2. Crash reports due to a function_clause error in tls_v1:enum_to_oid(0) > (this may be not the only one, but definitely the most popular) > > First one seems to be fixed by {log_alert, false} ssl option. > Second one keeps flooding logs with huge state printouts. > > So, my question is: How to make all SSL-related troubles not to generate > error reports? Simple {error, handshake_failed} returned by one of > accepting functions would be enough. > > > The first option should logically be enough. I think the problem is that tls_v1:enum_to_oid should have a try and throw a handshake alert if it fails or be ignored, depending on situation, i.e. be an expected error instead of an unexpected error. I will create an issue to handle that. Regards Ingela Erlang/OTP team - Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From yoursurrogategod@REDACTED Fri Mar 7 02:29:05 2014 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Thu, 6 Mar 2014 20:29:05 -0500 Subject: [erlang-questions] wx not working in Erlang Message-ID: Hello, I recently updated to the latest release version of Erlang with my package manager. I tried starting up the debugger using im(). and it did, but then I got the following error dump. (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed I'm not sure why this is happening. Maybe the order of installing the packages matters? I'm running ArchLinux at the moment. Thanks in advance, --Yves -------------- next part -------------- An HTML attachment was scrubbed... URL: From ccherng@REDACTED Fri Mar 7 03:09:03 2014 From: ccherng@REDACTED (Cary Cherng) Date: Thu, 6 Mar 2014 18:09:03 -0800 Subject: [erlang-questions] Creating a fault tolerant poker service Message-ID: What is the idiomatic way to create a fault tolerant poker service with Erlang? One could use a single server type, a bunch of machines for a fragmented mnesia table that stores the state of each game. This ensures that state is replicated to guard against machine failures. But it still leaves questions open: * How are games created so that they are load balanced across the servers so that cpu usage is relatively even? If game creation goes through some special server that also keeps track of where all games are so it knows loads on the backends, then that special server is a potential single failure point. * And a similar problem. If a user is disconnected, how does it find which games it is part of when it reconnects without some special server to track games. I am aware that others have made poker services with Erlang such as OpenPoker. But what would be the right idiomatic way of architecting a poker service to be resistant to machine failures assuming you were starting from scratch? The questions I asked above imply features that I would expect many distributed systems would need. That is a kind of abstract pattern. Are there maybe design patterns for these kinds of distributed systems? From carlsson.richard@REDACTED Fri Mar 7 08:01:13 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 06 Mar 2014 23:01:13 -0800 Subject: [erlang-questions] Fwd: FW: Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: <58912684E2630B45963406CF7D8C52581C369E4D@ESESSMB103.ericsson.se> Message-ID: <53196EB9.7080707@gmail.com> On 2014-03-06 02:15 , Andreas Schumacher wrote: > In OTP 17.0-rc{1,2}, a file that is encoded in latin-1 and contains > non-UTF-8/non-ASCII-7 characters, causes a compiler error similar to the > following: > > tst.erl:1: cannot parse file, giving up > tst.erl:1: no module definition > tst.erl:1: cannot translate from UTF-8 > > In OTP 17.0, if a file is encoded in latin-1 and contains > non-UTF-8/non-ASCII characters, but does not declare the encoding with a > magic encoding comment at the beginning of the file, epp (the Erlang > code pre-processor) issues a deprecation warning, and processes the file > again, assuming latin-1 encoding. > > In a future major version, preferably in OTP 18, the deprecation warning > will be turned into an error again. That is, only UTF-8 encoded files, > and files that declare the source code encoding at the beginning of the > source code file, will be accepted. Still not good enough. I want to be able to move up to R18 when that time comes without having to modify files all over our codebase. (And retrying is an ugly workaround anyway.) The following patch has allowed me to compile all of our sources under R17 by simply adding '+{default_encoding,latin1}' to the erlc options in our Makefiles: https://github.com/erlang/otp/pull/276 /Richard From z@REDACTED Fri Mar 7 11:14:32 2014 From: z@REDACTED (Danil Zagoskin) Date: Fri, 7 Mar 2014 14:14:32 +0400 Subject: [erlang-questions] Making SSL fail silently In-Reply-To: References: Message-ID: Thank you! May I help you? Test case, pull request, etc? 2014-03-07 1:39 GMT+04:00 Ingela Andin : > Hi! > > 2014-03-06 11:50 GMT+01:00 Danil Zagoskin : > > Hello! >> >> My application is listening SSL port >> using ssl:listen, ssl:transport_accept and ssl:ssl_accept (indeed it uses >> some old patched mochiweb). >> Erlang/OTP release is R16B02. >> I use SASL for error logging. >> >> Due to existence of network scanners, network errors and buggy clients >> some of connections fail to negotiate. This leads to two kind of log >> entries: >> 1. "insufficient security", etc. >> 2. Crash reports due to a function_clause error >> in tls_v1:enum_to_oid(0) (this may be not the only one, but definitely the >> most popular) >> >> First one seems to be fixed by {log_alert, false} ssl option. >> Second one keeps flooding logs with huge state printouts. >> >> So, my question is: How to make all SSL-related troubles not to generate >> error reports? Simple {error, handshake_failed} returned by one of >> accepting functions would be enough. >> >> >> > > > The first option should logically be enough. I think the problem is that > tls_v1:enum_to_oid > should have a try and throw a handshake alert if it fails or be ignored, > depending on situation, i.e. be an expected error instead of an unexpected > error. I will create an issue to handle that. > > Regards Ingela Erlang/OTP team - Ericsson AB > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- --------------------------------------------- ????? ???????? | +7 906 064 20 47 | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Fri Mar 7 11:51:06 2014 From: txrev319@REDACTED (t x) Date: Fri, 7 Mar 2014 02:51:06 -0800 Subject: [erlang-questions] erlang.mk neotoma Message-ID: ## consider: PROJECT = websocket DEPS = cowboy neotoma dep_cowboy = pkg://cowboy master dep_neotoma = pkg://neotoma master include erlang.mk ## question: Now, if I remove the neotoma lines, and hit "make", it pulls in the cowboy dependency perfectly fine. However, "make" doesn't pull in the neotoma dependency. What is different about neotoma vs cowboy, and how do I fix this? Thanks! From txrev319@REDACTED Fri Mar 7 11:59:15 2014 From: txrev319@REDACTED (t x) Date: Fri, 7 Mar 2014 02:59:15 -0800 Subject: [erlang-questions] erlang.mk neotoma In-Reply-To: References: Message-ID: Sorry for spamming. This is what I needed (for the sake of search engine searches). PROJECT = websocket DEPS = cowboy neotoma dep_cowboy = pkg://cowboy master dep_neotoma = https://github.com/seancribbs/neotoma.git master On Fri, Mar 7, 2014 at 2:51 AM, t x wrote: > ## consider: > > PROJECT = websocket > > DEPS = cowboy neotoma > dep_cowboy = pkg://cowboy master > dep_neotoma = pkg://neotoma master > > include erlang.mk > > ## question: > > Now, if I remove the neotoma lines, and hit "make", it pulls in the > cowboy dependency perfectly fine. > > However, "make" doesn't pull in the neotoma dependency. > > What is different about neotoma vs cowboy, and how do I fix this? > > Thanks! From jesper.louis.andersen@REDACTED Fri Mar 7 12:01:37 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 7 Mar 2014 12:01:37 +0100 Subject: [erlang-questions] erlang.mk neotoma In-Reply-To: References: Message-ID: On Fri, Mar 7, 2014 at 11:51 AM, t x wrote: > ## consider: > > PROJECT = websocket > > DEPS = cowboy neotoma > dep_cowboy = pkg://cowboy master > dep_neotoma = pkg://neotoma master > > Neotoma is not among the packages: https://github.com/extend/erlang.mk/blob/master/packages.v1.tsv You will need a pull request for that one, or refer it directly through a github link -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bombadil@REDACTED Fri Mar 7 12:26:25 2014 From: bombadil@REDACTED (Manuel A. Rubio "Bombadil") Date: Fri, 07 Mar 2014 13:26:25 +0200 Subject: [erlang-questions] [ANN] ecomponent 1.0.0 Message-ID: <5ef8a9942a65af59d1d6891a93521112@bosqueviejo.net> Hi, ecomponent is a XMPP component framework developed in Erlang and based in XEP-0114, that does easy the introduction to SOA 2.0 using XMPP: https://github.com/altenwald/ecomponent/releases/tag/1.0.0 More documentation about: https://github.com/altenwald/ecomponent/README.md Thanks. Manuel Rubio. From essen@REDACTED Fri Mar 7 18:00:00 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Mar 2014 18:00:00 +0100 Subject: [erlang-questions] erlang.mk neotoma In-Reply-To: References: Message-ID: <5319FB10.4060603@ninenines.eu> Yes, please send me pull requests of all the packages that you found work, so that we can populate this. Later on the package feature will also allow you to simply do DEPS = cowboy neotoma without having to specify anything else if the dependency is found in the packages, so that'll be pretty useful. It will also use the preferred version by default (example cowboy 1.*) and will be able to act as a central version-locking file if needed. But that file isn't going to get populated by itself. =) On 03/07/2014 12:01 PM, Jesper Louis Andersen wrote: > > > > On Fri, Mar 7, 2014 at 11:51 AM, t x > wrote: > > ## consider: > > PROJECT = websocket > > DEPS = cowboy neotoma > dep_cowboy = pkg://cowboy master > dep_neotoma = pkg://neotoma master > > > Neotoma is not among the packages: > > https://github.com/extend/erlang.mk/blob/master/packages.v1.tsv > > You will need a pull request for that one, or refer it directly through > a github link > > -- > J. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Fri Mar 7 18:19:29 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Mar 2014 18:19:29 +0100 Subject: [erlang-questions] wx not working in Erlang In-Reply-To: References: Message-ID: <5319FFA1.2010400@ninenines.eu> This issue was there for a while but it seems to work fine using Erlang 17.0-rc2. On 03/07/2014 02:29 AM, Yves S. Garret wrote: > Hello, > > I recently updated to the latest release version of Erlang with my > package manager. I tried starting up the debugger using im(). and it > did, but then I got the following error dump. > > > (Erlang:5577): GdkPixbuf-CRITICAL **: > gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed > > (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed > > (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed > > > (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: > assertion 'GDK_IS_PIXBUF (pixbuf)' failed > > (Erlang:5577): GdkPixbuf-CRITICAL **: > gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed > > (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed > > (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed > > (Erlang:5577): > GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF > (pixbuf)' failed > > > I'm not sure why this is happening. Maybe the order of installing the > packages matters? > > I'm running ArchLinux at the moment. > > Thanks in advance, > --Yves > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From max.lapshin@REDACTED Fri Mar 7 19:48:54 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 7 Mar 2014 22:48:54 +0400 Subject: [erlang-questions] erlang.mk neotoma In-Reply-To: <5319FB10.4060603@ninenines.eu> References: <5319FB10.4060603@ninenines.eu> Message-ID: I couldn't find in docs: can erlang.mk compile ports or nifs? Problem is that it is required to add erl_interface/include to includes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Mar 7 19:52:18 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Mar 2014 19:52:18 +0100 Subject: [erlang-questions] erlang.mk neotoma In-Reply-To: References: <5319FB10.4060603@ninenines.eu> Message-ID: <531A1562.4040401@ninenines.eu> Not yet. The solution retained for this will be to detect if c_src/Makefile exists, and if it does, create a env.mk file (once) containing the paths and then run make on the c_src Makefile, which may include this env.mk file. I'm still testing that solution but it should be there sometimes this month. On 03/07/2014 07:48 PM, Max Lapshin wrote: > I couldn't find in docs: can erlang.mk compile ports > or nifs? Problem is that it is required to add erl_interface/include to > includes. > -- Lo?c Hoguin http://ninenines.eu From max.lapshin@REDACTED Fri Mar 7 20:04:22 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 7 Mar 2014 23:04:22 +0400 Subject: [erlang-questions] erlang.mk neotoma In-Reply-To: <531A1562.4040401@ninenines.eu> References: <5319FB10.4060603@ninenines.eu> <531A1562.4040401@ninenines.eu> Message-ID: why not to declare required ports in common makefile? what for to have additional c_src/Makefile ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Mar 7 20:10:14 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Mar 2014 20:10:14 +0100 Subject: [erlang-questions] erlang.mk neotoma In-Reply-To: References: <5319FB10.4060603@ninenines.eu> <531A1562.4040401@ninenines.eu> Message-ID: <531A1996.5020305@ninenines.eu> We can't make any assumptions on how the C code will need to be built. If we make assumptions then only the simplest ports/NIFs will work. You may need autotools to run first for example. These can create a Makefile in c_src/ and then erlang.mk can directly call it. That's just one example of course. On 03/07/2014 08:04 PM, Max Lapshin wrote: > why not to declare required ports in common makefile? > what for to have additional c_src/Makefile ? -- Lo?c Hoguin http://ninenines.eu From max.lapshin@REDACTED Fri Mar 7 20:11:22 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 7 Mar 2014 23:11:22 +0400 Subject: [erlang-questions] erlang.mk neotoma In-Reply-To: <531A1996.5020305@ninenines.eu> References: <5319FB10.4060603@ninenines.eu> <531A1562.4040401@ninenines.eu> <531A1996.5020305@ninenines.eu> Message-ID: uh! Who said "autotools" ? Rebar doesn't need autotools to compile ports. On Fri, Mar 7, 2014 at 11:10 PM, Lo?c Hoguin wrote: > We can't make any assumptions on how the C code will need to be built. If > we make assumptions then only the simplest ports/NIFs will work. You may > need autotools to run first for example. These can create a Makefile in > c_src/ and then erlang.mk can directly call it. That's just one example > of course. > > > On 03/07/2014 08:04 PM, Max Lapshin wrote: > >> why not to declare required ports in common makefile? >> what for to have additional c_src/Makefile ? >> > > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Fri Mar 7 20:14:43 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 07 Mar 2014 20:14:43 +0100 Subject: [erlang-questions] erlang.mk neotoma In-Reply-To: References: <5319FB10.4060603@ninenines.eu> <531A1562.4040401@ninenines.eu> <531A1996.5020305@ninenines.eu> Message-ID: <531A1AA3.80005@ninenines.eu> Nobody said they were *needed*. But people might use them and even may be required to use them to compile the C code that their port will talk to. Rebar only works with the simplest of them. People that need more need to start writing a mess of hooks and yeah, blargh. Let's not do that. On 03/07/2014 08:11 PM, Max Lapshin wrote: > uh! Who said "autotools" ? > > Rebar doesn't need autotools to compile ports. > > > > On Fri, Mar 7, 2014 at 11:10 PM, Lo?c Hoguin > wrote: > > We can't make any assumptions on how the C code will need to be > built. If we make assumptions then only the simplest ports/NIFs will > work. You may need autotools to run first for example. These can > create a Makefile in c_src/ and then erlang.mk > can directly call it. That's just one example of course. > > > On 03/07/2014 08:04 PM, Max Lapshin wrote: > > why not to declare required ports in common makefile? > what for to have additional c_src/Makefile ? > > > -- > Lo?c Hoguin > http://ninenines.eu > > -- Lo?c Hoguin http://ninenines.eu From andra.dinu@REDACTED Fri Mar 7 20:54:57 2014 From: andra.dinu@REDACTED (Andra Dinu) Date: Fri, 7 Mar 2014 20:54:57 +0100 (CET) Subject: [erlang-questions] Videos from Erlang Factory SF Bay 2014 up on ErlangCentral.org In-Reply-To: <1678704480.77723.1394222038984.JavaMail.zimbra@erlang-solutions.com> Message-ID: <99075311.77724.1394222097496.JavaMail.zimbra@erlang-solutions.com> Happy to announce that videos from two tracks of the Erlang Factory Conference are up on ErlangCentral.org (and two more tracks will be uploaded at the end of the conference) NEXT GENERATION DATABASES & ANALYTICS https://erlangcentral.org/streaming/next-generation-databases-analytics/ SCALABILITY & MULTICORE https://erlangcentral.org/streaming/scalability-multicore/ Also check out the chat function enabled by @Kato -- Andra Dinu Community & Social ERLANG SOLUTIONS LTD New Loom House 101 Back Church Lane London, E1 1LU United Kingdom Tel +44(0)2076550344 Mob +44(0)7983484387 www.erlang-solutions.com From desired.mta@REDACTED Sat Mar 8 07:13:51 2014 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Fri, 7 Mar 2014 22:13:51 -0800 Subject: [erlang-questions] Videos from Erlang Factory SF Bay 2014 up on ErlangCentral.org In-Reply-To: <99075311.77724.1394222097496.JavaMail.zimbra@erlang-solutions.com> References: <1678704480.77723.1394222038984.JavaMail.zimbra@erlang-solutions.com> <99075311.77724.1394222097496.JavaMail.zimbra@erlang-solutions.com> Message-ID: On Fri, Mar 7, 2014 at 11:54 AM, Andra Dinu wrote: > Happy to announce that videos from two tracks of the Erlang Factory Conference are up on ErlangCentral.org (and two more tracks will be uploaded at the end of the conference) > > > NEXT GENERATION DATABASES & ANALYTICS https://erlangcentral.org/streaming/next-generation-databases-analytics/ > > SCALABILITY & MULTICORE https://erlangcentral.org/streaming/scalability-multicore/ > > Also check out the chat function enabled by @Kato Hi, Andra, thanks for uploading the videos that quickly. That is a really wonderful job. One question though regarding accessing the videos. I understand the need to have as many registered users as possible, but is it really so necessary to put a registration wall for videos? I understand it is necessary to make life harder for spammers if I want to post a comment (I can write junk to chat without logging in, so there must be another reason). But for anonymous video watching? That is out of my understanding. I visited the website to have a quick look at what's available. Requires registration. Ok. Email confirmation. OK. Fifteen minutes, yet no email received. Cannot see the videos because it requires registration which requires an email validation and the email validation service does send me the bloody email. Today morning in the keynote Dave Thomas stressed that it is paramount to reduce entry curve for new Erlang users. Is this the message we want to send for one? See some interesting free stuff about Erlang, registration is required, which does not actually work, please come back later? Because of the reasons above I would suggest and appreciate registration requirement waived for read-only activities on erlangcentral. Kind regards, Motiejus Jak?tys From essen@REDACTED Sat Mar 8 08:09:57 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 08 Mar 2014 08:09:57 +0100 Subject: [erlang-questions] Videos from Erlang Factory SF Bay 2014 up on ErlangCentral.org In-Reply-To: References: <1678704480.77723.1394222038984.JavaMail.zimbra@erlang-solutions.com> <99075311.77724.1394222097496.JavaMail.zimbra@erlang-solutions.com> Message-ID: <531AC245.1090503@ninenines.eu> I mentioned that last year. Guess that makes two of us now! If more people start complaining perhaps things will change. :-) On 03/08/2014 07:13 AM, Motiejus Jak?tys wrote: > On Fri, Mar 7, 2014 at 11:54 AM, Andra Dinu > wrote: >> Happy to announce that videos from two tracks of the Erlang Factory Conference are up on ErlangCentral.org (and two more tracks will be uploaded at the end of the conference) >> >> >> NEXT GENERATION DATABASES & ANALYTICS https://erlangcentral.org/streaming/next-generation-databases-analytics/ >> >> SCALABILITY & MULTICORE https://erlangcentral.org/streaming/scalability-multicore/ >> >> Also check out the chat function enabled by @Kato > > Hi, Andra, > > thanks for uploading the videos that quickly. That is a really wonderful job. > > One question though regarding accessing the videos. I understand the > need to have as many registered users as possible, but is it really so > necessary to put a registration wall for videos? I understand it is > necessary to make life harder for spammers if I want to post a comment > (I can write junk to chat without logging in, so there must be another > reason). But for anonymous video watching? That is out of my > understanding. > > I visited the website to have a quick look at what's available. > Requires registration. Ok. Email confirmation. OK. Fifteen minutes, > yet no email received. Cannot see the videos because it requires > registration which requires an email validation and the email > validation service does send me the bloody email. > > Today morning in the keynote Dave Thomas stressed that it is paramount > to reduce entry curve for new Erlang users. Is this the message we > want to send for one? See some interesting free stuff about Erlang, > registration is required, which does not actually work, please come > back later? > > Because of the reasons above I would suggest and appreciate > registration requirement waived for read-only activities on > erlangcentral. > > Kind regards, > Motiejus Jak?tys > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From txrev319@REDACTED Sat Mar 8 08:13:43 2014 From: txrev319@REDACTED (t x) Date: Fri, 7 Mar 2014 23:13:43 -0800 Subject: [erlang-questions] erlang restart application Message-ID: Hi, [apologies for this stream of stupid questions; I haven't figured out how the various pieces work together yet] I'm reading http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ In particular, I'm looking at https://gist.github.com/txrev319/9426556 How does the {registered, [hello_erlang_sup]}, {mod, {hello_erlang_app, []}}, lines work? In particular, how can I restart the hello_erlang_app app ? So after I do "_rel/..../ remote_console", I do: * c(hello_erlang_app). * l(hello_erlang_app). --> now, at this point, how do I _restart_ the existing hello_erlang_app ? Thanks! From essen@REDACTED Sat Mar 8 08:21:41 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 08 Mar 2014 08:21:41 +0100 Subject: [erlang-questions] erlang restart application In-Reply-To: References: Message-ID: <531AC505.4030502@ninenines.eu> It's not explained in the getting started on purpose, as this is an advanced topic. Basically this is an OTP application, where hello_erlang_app is an application behaviour and the hello_erlang_sup is the main supervisor of that application. To answer your question, you can just use: application:stop(hello_erlang). application:start(hello_erlang). With hello_erlang the name of the application. On the other hand you have a release, which means c(hello_erlang_app) doesn't operate on your src/ directory anymore (you don't need to use l/1 after using c/1 by the way as it already does it), so the quickest way is most likely to just Ctrl+C twice, type make and restart the VM again. Another way is to use a reloader that understands releases. But yeah, I wouldn't worry about these things for quite some time as you don't need to know them to operate Cowboy. On 03/08/2014 08:13 AM, t x wrote: > Hi, > > > [apologies for this stream of stupid questions; I haven't figured out > how the various pieces work together yet] > > > I'm reading http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ > > > In particular, I'm looking at https://gist.github.com/txrev319/9426556 > > > How does the > > {registered, [hello_erlang_sup]}, > {mod, {hello_erlang_app, []}}, > > lines work? > > > In particular, how can I restart the hello_erlang_app app ? > > So after I do "_rel/..../ remote_console", I do: > > * c(hello_erlang_app). > * l(hello_erlang_app). > > --> now, at this point, how do I _restart_ the existing hello_erlang_app ? > > > Thanks! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From fhamilton@REDACTED Sat Mar 8 08:34:02 2014 From: fhamilton@REDACTED (Felix Hamilton) Date: Fri, 7 Mar 2014 23:34:02 -0800 Subject: [erlang-questions] Videos from Erlang Factory SF Bay 2014 up on ErlangCentral.org In-Reply-To: <531AC245.1090503@ninenines.eu> References: <1678704480.77723.1394222038984.JavaMail.zimbra@erlang-solutions.com> <99075311.77724.1394222097496.JavaMail.zimbra@erlang-solutions.com> <531AC245.1090503@ninenines.eu> Message-ID: I had the same problem - I cannot read or watch content on Erlang Central website without an account so I actually set up an account in order to do so (very rare occurrence). Then I do not receive the activation email which it seems you must have to actually use an account. So I try to log in and fail, then go to the effort of requesting another activation email, which also does not arrive. At this point I throw up my hands, close the Erlang Central tab, and move on. ;-) Probably not the experience folks are looking for in an outreach site ... /Felix On Fri, Mar 7, 2014 at 11:09 PM, Lo?c Hoguin wrote: > I mentioned that last year. Guess that makes two of us now! If more people > start complaining perhaps things will change. :-) > > > On 03/08/2014 07:13 AM, Motiejus Jak?tys wrote: > >> On Fri, Mar 7, 2014 at 11:54 AM, Andra Dinu >> wrote: >> >>> Happy to announce that videos from two tracks of the Erlang Factory >>> Conference are up on ErlangCentral.org (and two more tracks will be >>> uploaded at the end of the conference) >>> >>> >>> NEXT GENERATION DATABASES & ANALYTICS https://erlangcentral.org/ >>> streaming/next-generation-databases-analytics/ >>> >>> SCALABILITY & MULTICORE https://erlangcentral.org/streaming/scalability- >>> multicore/ >>> >>> Also check out the chat function enabled by @Kato >>> >> >> Hi, Andra, >> >> thanks for uploading the videos that quickly. That is a really wonderful >> job. >> >> One question though regarding accessing the videos. I understand the >> need to have as many registered users as possible, but is it really so >> necessary to put a registration wall for videos? I understand it is >> necessary to make life harder for spammers if I want to post a comment >> (I can write junk to chat without logging in, so there must be another >> reason). But for anonymous video watching? That is out of my >> understanding. >> >> I visited the website to have a quick look at what's available. >> Requires registration. Ok. Email confirmation. OK. Fifteen minutes, >> yet no email received. Cannot see the videos because it requires >> registration which requires an email validation and the email >> validation service does send me the bloody email. >> >> Today morning in the keynote Dave Thomas stressed that it is paramount >> to reduce entry curve for new Erlang users. Is this the message we >> want to send for one? See some interesting free stuff about Erlang, >> registration is required, which does not actually work, please come >> back later? >> >> Because of the reasons above I would suggest and appreciate >> registration requirement waived for read-only activities on >> erlangcentral. >> >> Kind regards, >> Motiejus Jak?tys >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Sat Mar 8 11:52:41 2014 From: txrev319@REDACTED (t x) Date: Sat, 8 Mar 2014 02:52:41 -0800 Subject: [erlang-questions] erlang restart application In-Reply-To: <531AC505.4030502@ninenines.eu> References: <531AC505.4030502@ninenines.eu> Message-ID: @Loic: Thanks! This was extremely clear and helpful. ================================= As a follow up question, is there documentation for erlang.mk anywhere? I know of the README at https://github.com/extend/erlang.mk , but it's a bit short on details. I'm also aware of https://github.com/erlware/relx/wiki/configuration but I don't really understand it. What I really want to understand is what happens behind the scenes, a detailed description of: * when I run _rel/bin/websocket_example start * how does this use src/websocket.app.src * what processes are created? (clearly websocket_app.erl is called) * what options are they called with * and questions I'm not even asking I feel that when I run: make; _rel/bin/websocket_example console there's _alot_ of stuff (compared to say, what Programming Erlang, up to chapter 18, covers) going on behind the scenes. I'd really like to understand what is happening behind the scenes for debugging purposes. What tutorial should I be going through? Thanks! On Fri, Mar 7, 2014 at 11:21 PM, Lo?c Hoguin wrote: > It's not explained in the getting started on purpose, as this is an advanced > topic. > > Basically this is an OTP application, where hello_erlang_app is an > application behaviour and the hello_erlang_sup is the main supervisor of > that application. > > To answer your question, you can just use: > > application:stop(hello_erlang). > application:start(hello_erlang). > > With hello_erlang the name of the application. > > On the other hand you have a release, which means c(hello_erlang_app) > doesn't operate on your src/ directory anymore (you don't need to use l/1 > after using c/1 by the way as it already does it), so the quickest way is > most likely to just Ctrl+C twice, type make and restart the VM again. > Another way is to use a reloader that understands releases. > > But yeah, I wouldn't worry about these things for quite some time as you > don't need to know them to operate Cowboy. > > > On 03/08/2014 08:13 AM, t x wrote: >> >> Hi, >> >> >> [apologies for this stream of stupid questions; I haven't figured out >> how the various pieces work together yet] >> >> >> I'm reading >> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ >> >> >> In particular, I'm looking at https://gist.github.com/txrev319/9426556 >> >> >> How does the >> >> {registered, [hello_erlang_sup]}, >> {mod, {hello_erlang_app, []}}, >> >> lines work? >> >> >> In particular, how can I restart the hello_erlang_app app ? >> >> So after I do "_rel/..../ remote_console", I do: >> >> * c(hello_erlang_app). >> * l(hello_erlang_app). >> >> --> now, at this point, how do I _restart_ the existing >> hello_erlang_app ? >> >> >> Thanks! >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > Lo?c Hoguin > http://ninenines.eu From txrev319@REDACTED Sat Mar 8 11:59:13 2014 From: txrev319@REDACTED (t x) Date: Sat, 8 Mar 2014 02:59:13 -0800 Subject: [erlang-questions] erlang restart application In-Reply-To: References: <531AC505.4030502@ninenines.eu> Message-ID: Err, I think there's a bug in my followup question. The questions asked seem more related to OTP (see chapter 10 of Erlang and OTP in action) than to erlang.mk / relx. On Sat, Mar 8, 2014 at 2:52 AM, t x wrote: > @Loic: > > Thanks! This was extremely clear and helpful. > > ================================= > > As a follow up question, is there documentation for erlang.mk > anywhere? I know of the README at https://github.com/extend/erlang.mk > , but it's a bit short on details. > > I'm also aware of https://github.com/erlware/relx/wiki/configuration > but I don't really understand it. > > > What I really want to understand is what happens behind the scenes, a > detailed description of: > > * when I run _rel/bin/websocket_example start > * how does this use src/websocket.app.src > > * what processes are created? (clearly websocket_app.erl is called) > * what options are they called with > > * and questions I'm not even asking > > > I feel that when I run: > > make; _rel/bin/websocket_example console > > there's _alot_ of stuff (compared to say, what Programming Erlang, > up to chapter 18, covers) going on behind the scenes. > > I'd really like to understand what is happening behind the scenes for > debugging purposes. > > > What tutorial should I be going through? > > Thanks! > > > > > > On Fri, Mar 7, 2014 at 11:21 PM, Lo?c Hoguin wrote: >> It's not explained in the getting started on purpose, as this is an advanced >> topic. >> >> Basically this is an OTP application, where hello_erlang_app is an >> application behaviour and the hello_erlang_sup is the main supervisor of >> that application. >> >> To answer your question, you can just use: >> >> application:stop(hello_erlang). >> application:start(hello_erlang). >> >> With hello_erlang the name of the application. >> >> On the other hand you have a release, which means c(hello_erlang_app) >> doesn't operate on your src/ directory anymore (you don't need to use l/1 >> after using c/1 by the way as it already does it), so the quickest way is >> most likely to just Ctrl+C twice, type make and restart the VM again. >> Another way is to use a reloader that understands releases. >> >> But yeah, I wouldn't worry about these things for quite some time as you >> don't need to know them to operate Cowboy. >> >> >> On 03/08/2014 08:13 AM, t x wrote: >>> >>> Hi, >>> >>> >>> [apologies for this stream of stupid questions; I haven't figured out >>> how the various pieces work together yet] >>> >>> >>> I'm reading >>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ >>> >>> >>> In particular, I'm looking at https://gist.github.com/txrev319/9426556 >>> >>> >>> How does the >>> >>> {registered, [hello_erlang_sup]}, >>> {mod, {hello_erlang_app, []}}, >>> >>> lines work? >>> >>> >>> In particular, how can I restart the hello_erlang_app app ? >>> >>> So after I do "_rel/..../ remote_console", I do: >>> >>> * c(hello_erlang_app). >>> * l(hello_erlang_app). >>> >>> --> now, at this point, how do I _restart_ the existing >>> hello_erlang_app ? >>> >>> >>> Thanks! >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu From ulf@REDACTED Sat Mar 8 12:51:32 2014 From: ulf@REDACTED (Ulf Wiger) Date: Sat, 8 Mar 2014 12:51:32 +0100 Subject: [erlang-questions] Videos from Erlang Factory SF Bay 2014 up on ErlangCentral.org In-Reply-To: References: <1678704480.77723.1394222038984.JavaMail.zimbra@erlang-solutions.com> <99075311.77724.1394222097496.JavaMail.zimbra@erlang-solutions.com> <531AC245.1090503@ninenines.eu> Message-ID: <5D10B688-BEEB-48E4-A8A0-10E51BCE8E33@feuerlabs.com> Note that the videos are actually hosted on Youtube - not on Erlang Central: https://www.youtube.com/user/ErlangSolutions?feature=watch You can watch them there - no registration necessary. Great video formats, BTW, and thanks ESL for the very timely upload. :) BR, Ulf W On 8 Mar 2014, at 08:34, Felix Hamilton wrote: > I had the same problem - I cannot read or watch content on Erlang Central website without an account so I actually set up an account in order to do so (very rare occurrence). Then I do not receive the activation email which it seems you must have to actually use an account. So I try to log in and fail, then go to the effort of requesting another activation email, which also does not arrive. At this point I throw up my hands, close the Erlang Central tab, and move on. ;-) > > Probably not the experience folks are looking for in an outreach site ... > > /Felix > > > On Fri, Mar 7, 2014 at 11:09 PM, Lo?c Hoguin wrote: > I mentioned that last year. Guess that makes two of us now! If more people start complaining perhaps things will change. :-) > > > On 03/08/2014 07:13 AM, Motiejus Jak?tys wrote: > On Fri, Mar 7, 2014 at 11:54 AM, Andra Dinu > wrote: > Happy to announce that videos from two tracks of the Erlang Factory Conference are up on ErlangCentral.org (and two more tracks will be uploaded at the end of the conference) > > > NEXT GENERATION DATABASES & ANALYTICS https://erlangcentral.org/streaming/next-generation-databases-analytics/ > > SCALABILITY & MULTICORE https://erlangcentral.org/streaming/scalability-multicore/ > > Also check out the chat function enabled by @Kato > > Hi, Andra, > > thanks for uploading the videos that quickly. That is a really wonderful job. > > One question though regarding accessing the videos. I understand the > need to have as many registered users as possible, but is it really so > necessary to put a registration wall for videos? I understand it is > necessary to make life harder for spammers if I want to post a comment > (I can write junk to chat without logging in, so there must be another > reason). But for anonymous video watching? That is out of my > understanding. > > I visited the website to have a quick look at what's available. > Requires registration. Ok. Email confirmation. OK. Fifteen minutes, > yet no email received. Cannot see the videos because it requires > registration which requires an email validation and the email > validation service does send me the bloody email. > > Today morning in the keynote Dave Thomas stressed that it is paramount > to reduce entry curve for new Erlang users. Is this the message we > want to send for one? See some interesting free stuff about Erlang, > registration is required, which does not actually work, please come > back later? > > Because of the reasons above I would suggest and appreciate > registration requirement waived for read-only activities on > erlangcentral. > > Kind regards, > Motiejus Jak?tys > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > Lo?c Hoguin > http://ninenines.eu > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chuck.irvine@REDACTED Sat Mar 8 14:01:10 2014 From: chuck.irvine@REDACTED (Charles Irvine) Date: Sat, 08 Mar 2014 07:01:10 -0600 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? Message-ID: I recently read that the ?JSON Bridge? that Joe Armstrong describes in his new book won?t be included in Erlang 17.0. This would have been very useful. With Json becoming so prevalent (web services, browsers, Mongodb, etc), I think it is really surpassing XML as a common data interoperability format. It must have been on the table at one point or it wouldn?t have appeared in Joe?s book. Why did it not make it into the release? I think someone indicated that it really didn?t belong in the maps module and I can kind of see that. But why not just put it in a ?json? module? Regards, Chuck From jesper.louis.andersen@REDACTED Sat Mar 8 14:14:36 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Sat, 8 Mar 2014 14:14:36 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: On Sat, Mar 8, 2014 at 2:01 PM, Charles Irvine wrote: > I recently read that the ?JSON Bridge? that Joe Armstrong describes in his > new book won?t be included in Erlang 17.0. This would have been very > useful. With Json becoming so prevalent (web services, browsers, Mongodb, > etc), I think it is really surpassing XML as a common data interoperability > format. It must have been on the table at one point or it wouldn?t have > appeared in Joe?s book. Why did it not make it into the release? I think > someone indicated that it really didn?t belong in the maps module and I can > kind of see that. But why not just put it in a ?json? module? Regards, Chuck We already have a fair number of JSON handlers for Erlang: jsx, jiffy, mochijson, mochijson2, yaws json (deprecated), yaws json2, ... The reason we have that many is quite simple. One JSON parser does not satisfy all requirements. And to make things worse, there are small fluctuations in the "standard" which make it hard to create proper support. Adding a `json` module to the standard library is asking for jumping into this minefield. I'd much rather see libraries adopt maps as a way to represent JSON structures in Erlang. With maps, there is a neat mapping between most JSON documents and Erlang terms which will be useful. But I would be wary of standardizing on one due to the different requirements in handling. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cabo@REDACTED Sat Mar 8 14:42:49 2014 From: cabo@REDACTED (Carsten Bormann) Date: Sat, 8 Mar 2014 13:42:49 +0000 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: It is true that different applications may need different mappings of the JSON data model into the data model of the specific application, but the following is not a valid reason: On 08 Mar 2014, at 13:14, Jesper Louis Andersen wrote: > And to make things worse, there are small fluctuations in the "standard" which make it hard to create proper support. Adding a `json` module to the standard library is asking for jumping into this minefield. The ?standard? has been stable since RFC 4627, which was published in July 2006. Since, ECMA TC39 (the committee for changing JavaScript) has decided to allow top-level numbers, primitives (false, true, null), and strings; the IETF has reluctantly followed this change and published RFC 7159 with that change. Apart from the question whether one should accept top-level numbers/primitives/strings (and it is easy for an application to follow the Postel principle here: be liberal in what you accept and conservative in what you send), there has been no ?fluctuation? in JSON. With the acceptance of UTF-8 strings (?binaries?) into the Erlang world, there is a straightforward mapping of JSON data into the Erlang model. Mapping back may require a bit more application knowledge (e.g., how do you encode non-JSON concepts such as atoms?), but a basic mapping can easily be part of the standard library, certainly easier than for ASN.1 or XML. Gr??e, Carsten From pierrefenoll@REDACTED Sat Mar 8 14:47:33 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Sat, 8 Mar 2014 14:47:33 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: Let's not forget though that most languages implementation of JSON uses hash tables. Before 17.0, the JSON mapping used lists; taking lookup linear time. Maps have a lookup time of O(log n). That's still not O(1)? Cheers, -- Pierre Fenoll On 8 March 2014 14:42, Carsten Bormann wrote: > It is true that different applications may need different mappings of the > JSON data model into the data model of the specific application, but the > following is not a valid reason: > > On 08 Mar 2014, at 13:14, Jesper Louis Andersen < > jesper.louis.andersen@REDACTED> wrote: > > > And to make things worse, there are small fluctuations in the "standard" > which make it hard to create proper support. Adding a `json` module to the > standard library is asking for jumping into this minefield. > > The ?standard? has been stable since RFC 4627, which was published in July > 2006. > Since, ECMA TC39 (the committee for changing JavaScript) has decided to > allow top-level numbers, primitives (false, true, null), and strings; the > IETF has reluctantly followed this change and published RFC 7159 with that > change. > > Apart from the question whether one should accept top-level > numbers/primitives/strings (and it is easy for an application to follow the > Postel principle here: be liberal in what you accept and conservative in > what you send), there has been no ?fluctuation? in JSON. > > With the acceptance of UTF-8 strings (?binaries?) into the Erlang world, > there is a straightforward mapping of JSON data into the Erlang model. > Mapping back may require a bit more application knowledge (e.g., how do > you encode non-JSON concepts such as atoms?), but a basic mapping can > easily be part of the standard library, certainly easier than for ASN.1 or > XML. > > Gr??e, Carsten > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sat Mar 8 15:01:53 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sat, 8 Mar 2014 15:01:53 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> The problem is not about what is accepted, it?s about how one?s (un)parser works. Sometimes you want a streaming-like API, sometimes the whole tree, etc. The Postel principle is orthogonal here. Furthermore, I would argue that JSON is harder to map than ASN.1 and XML. I can map any term to ASN.1 and XML with the right schemas. I can?t do that with JSON. And don?t mention JSON schemas, they don?t really exist. -- Anthony Ramine Le 8 mars 2014 ? 14:42, Carsten Bormann a ?crit : > It is true that different applications may need different mappings of the JSON data model into the data model of the specific application, but the following is not a valid reason: > > On 08 Mar 2014, at 13:14, Jesper Louis Andersen wrote: > >> And to make things worse, there are small fluctuations in the "standard" which make it hard to create proper support. Adding a `json` module to the standard library is asking for jumping into this minefield. > > The ?standard? has been stable since RFC 4627, which was published in July 2006. > Since, ECMA TC39 (the committee for changing JavaScript) has decided to allow top-level numbers, primitives (false, true, null), and strings; the IETF has reluctantly followed this change and published RFC 7159 with that change. > > Apart from the question whether one should accept top-level numbers/primitives/strings (and it is easy for an application to follow the Postel principle here: be liberal in what you accept and conservative in what you send), there has been no ?fluctuation? in JSON. > > With the acceptance of UTF-8 strings (?binaries?) into the Erlang world, there is a straightforward mapping of JSON data into the Erlang model. > Mapping back may require a bit more application knowledge (e.g., how do you encode non-JSON concepts such as atoms?), but a basic mapping can easily be part of the standard library, certainly easier than for ASN.1 or XML. > > Gr??e, Carsten > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From essen@REDACTED Sat Mar 8 18:00:28 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 08 Mar 2014 18:00:28 +0100 Subject: [erlang-questions] erlang restart application In-Reply-To: References: <531AC505.4030502@ninenines.eu> Message-ID: <531B4CAC.3010002@ninenines.eu> Hello, Yep most of these questions relate to OTP itself as you found out. I don't plan to explain all the details in the documentation. :-) On the other hand the erlang.mk docs are getting a complete rewrite with a lot more details filled in and that should land in a few weeks. On 03/08/2014 11:52 AM, t x wrote: > @Loic: > > Thanks! This was extremely clear and helpful. > > ================================= > > As a follow up question, is there documentation for erlang.mk > anywhere? I know of the README at https://github.com/extend/erlang.mk > , but it's a bit short on details. > > I'm also aware of https://github.com/erlware/relx/wiki/configuration > but I don't really understand it. > > > What I really want to understand is what happens behind the scenes, a > detailed description of: > > * when I run _rel/bin/websocket_example start > * how does this use src/websocket.app.src > > * what processes are created? (clearly websocket_app.erl is called) > * what options are they called with > > * and questions I'm not even asking > > > I feel that when I run: > > make; _rel/bin/websocket_example console > > there's _alot_ of stuff (compared to say, what Programming Erlang, > up to chapter 18, covers) going on behind the scenes. > > I'd really like to understand what is happening behind the scenes for > debugging purposes. > > > What tutorial should I be going through? > > Thanks! > > > > > > On Fri, Mar 7, 2014 at 11:21 PM, Lo?c Hoguin wrote: >> It's not explained in the getting started on purpose, as this is an advanced >> topic. >> >> Basically this is an OTP application, where hello_erlang_app is an >> application behaviour and the hello_erlang_sup is the main supervisor of >> that application. >> >> To answer your question, you can just use: >> >> application:stop(hello_erlang). >> application:start(hello_erlang). >> >> With hello_erlang the name of the application. >> >> On the other hand you have a release, which means c(hello_erlang_app) >> doesn't operate on your src/ directory anymore (you don't need to use l/1 >> after using c/1 by the way as it already does it), so the quickest way is >> most likely to just Ctrl+C twice, type make and restart the VM again. >> Another way is to use a reloader that understands releases. >> >> But yeah, I wouldn't worry about these things for quite some time as you >> don't need to know them to operate Cowboy. >> >> >> On 03/08/2014 08:13 AM, t x wrote: >>> >>> Hi, >>> >>> >>> [apologies for this stream of stupid questions; I haven't figured out >>> how the various pieces work together yet] >>> >>> >>> I'm reading >>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ >>> >>> >>> In particular, I'm looking at https://gist.github.com/txrev319/9426556 >>> >>> >>> How does the >>> >>> {registered, [hello_erlang_sup]}, >>> {mod, {hello_erlang_app, []}}, >>> >>> lines work? >>> >>> >>> In particular, how can I restart the hello_erlang_app app ? >>> >>> So after I do "_rel/..../ remote_console", I do: >>> >>> * c(hello_erlang_app). >>> * l(hello_erlang_app). >>> >>> --> now, at this point, how do I _restart_ the existing >>> hello_erlang_app ? >>> >>> >>> Thanks! >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu -- Lo?c Hoguin http://ninenines.eu From ingela.andin@REDACTED Sat Mar 8 22:49:24 2014 From: ingela.andin@REDACTED (Ingela Andin) Date: Sat, 8 Mar 2014 22:49:24 +0100 Subject: [erlang-questions] Making SSL fail silently In-Reply-To: References: Message-ID: Hi! 2014-03-07 11:14 GMT+01:00 Danil Zagoskin : > Thank you! > > May I help you? Test case, pull request, etc? > > You are always welcome to make a pull request which, if you follow the guide lines, should include a test case. Regards Ingela Erlang/OTP team - Ericsson AB > > 2014-03-07 1:39 GMT+04:00 Ingela Andin : > >> Hi! >> >> 2014-03-06 11:50 GMT+01:00 Danil Zagoskin : >> >> Hello! >>> >>> My application is listening SSL port >>> using ssl:listen, ssl:transport_accept and ssl:ssl_accept (indeed it uses >>> some old patched mochiweb). >>> Erlang/OTP release is R16B02. >>> I use SASL for error logging. >>> >>> Due to existence of network scanners, network errors and buggy clients >>> some of connections fail to negotiate. This leads to two kind of log >>> entries: >>> 1. "insufficient security", etc. >>> 2. Crash reports due to a function_clause error >>> in tls_v1:enum_to_oid(0) (this may be not the only one, but definitely the >>> most popular) >>> >>> First one seems to be fixed by {log_alert, false} ssl option. >>> Second one keeps flooding logs with huge state printouts. >>> >>> So, my question is: How to make all SSL-related troubles not to generate >>> error reports? Simple {error, handshake_failed} returned by one of >>> accepting functions would be enough. >>> >>> >>> >> >> >> The first option should logically be enough. I think the problem is that >> tls_v1:enum_to_oid >> should have a try and throw a handshake alert if it fails or be >> ignored, depending on situation, i.e. be an expected error instead of an >> unexpected error. I will create an issue to handle that. >> >> Regards Ingela Erlang/OTP team - Ericsson AB >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > -- > --------------------------------------------- > ????? ???????? | +7 906 064 20 47 | z@REDACTED > -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Sun Mar 9 08:11:43 2014 From: txrev319@REDACTED (t x) Date: Sat, 8 Mar 2014 23:11:43 -0800 Subject: [erlang-questions] cowboy / start_http ... multiple ports? Message-ID: Hi, Is there a way to run cowboy / start_http on multiple ports? I want port 8080 and port 7070 to serve different files (release vs dev js files from clojurescript). I have tried the following, but get an error: https://gist.github.com/txrev319/9443959 Can someone let me know what I'm doing wrong? Thanks! From txrev319@REDACTED Sun Mar 9 08:46:33 2014 From: txrev319@REDACTED (t x) Date: Sat, 8 Mar 2014 23:46:33 -0800 Subject: [erlang-questions] cowboy / start_http ... multiple ports? In-Reply-To: References: Message-ID: Fixed. cowboy:start_http(http, ...) cowboy:start_http(http, ...) is the problem the "http" is actually an atom for the name of some regsitered server, so one needs to do: cowboy:start_http(foo, ...) cowboy:start_http(bar, ...) :-) On Sat, Mar 8, 2014 at 11:11 PM, t x wrote: > Hi, > > Is there a way to run cowboy / start_http on multiple ports? > > > I want port 8080 and port 7070 to serve different files (release vs > dev js files from clojurescript). > > I have tried the following, but get an error: > https://gist.github.com/txrev319/9443959 > > Can someone let me know what I'm doing wrong? > > Thanks! From max.lapshin@REDACTED Sun Mar 9 09:07:27 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Sun, 9 Mar 2014 12:07:27 +0400 Subject: [erlang-questions] cowboy / start_http ... multiple ports? In-Reply-To: References: Message-ID: It is ok to: cowboy:start_http({myserver,80}, ...) cowboy:start_http({myserver,8080}, ...) cowboy:start_http({myserver,443}, ...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Sun Mar 9 11:53:41 2014 From: tony@REDACTED (Tony Rogvall) Date: Sun, 9 Mar 2014 11:53:41 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: On 8 mar 2014, at 14:47, Pierre Fenoll wrote: > Let's not forget though that most languages implementation of JSON uses hash tables. > Before 17.0, the JSON mapping used lists; taking lookup linear time. > Maps have a lookup time of O(log n). > That's still not O(1)? > The current map implementation suggest that you should not use it for big maps yet. Say less than 10 elements or so. Guess what? that could be thought of as O(1) :-) /Tony > > Cheers, > -- > Pierre Fenoll > > > > On 8 March 2014 14:42, Carsten Bormann wrote: > It is true that different applications may need different mappings of the JSON data model into the data model of the specific application, but the following is not a valid reason: > > On 08 Mar 2014, at 13:14, Jesper Louis Andersen wrote: > > > And to make things worse, there are small fluctuations in the "standard" which make it hard to create proper support. Adding a `json` module to the standard library is asking for jumping into this minefield. > > The ?standard? has been stable since RFC 4627, which was published in July 2006. > Since, ECMA TC39 (the committee for changing JavaScript) has decided to allow top-level numbers, primitives (false, true, null), and strings; the IETF has reluctantly followed this change and published RFC 7159 with that change. > > Apart from the question whether one should accept top-level numbers/primitives/strings (and it is easy for an application to follow the Postel principle here: be liberal in what you accept and conservative in what you send), there has been no ?fluctuation? in JSON. > > With the acceptance of UTF-8 strings (?binaries?) into the Erlang world, there is a straightforward mapping of JSON data into the Erlang model. > Mapping back may require a bit more application knowledge (e.g., how do you encode non-JSON concepts such as atoms?), but a basic mapping can easily be part of the standard library, certainly easier than for ASN.1 or XML. > > Gr??e, Carsten > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From z@REDACTED Sun Mar 9 14:44:10 2014 From: z@REDACTED (Danil Zagoskin) Date: Sun, 9 Mar 2014 17:44:10 +0400 Subject: [erlang-questions] Making SSL fail silently In-Reply-To: References: Message-ID: I've investigated this case a bit and it seems to me that ECC handshake implementation has a bug: As fas as I understand RFC 4492 ( https://tools.ietf.org/html/rfc4492#section-5.1), it tells that it's OK for server to not support all curves supported by client if there are enough curves supported by both of them. So if I'm correct, the tls_v1:enum_to_oid/1 function should have a default clause returning some magic value ('unsupported_curve' ?) which should be filtered out from EllipticCurves list in ?ELLIPTIC_CURVES_EXT clause of ssl_handshake:dec_hello_extensions/2 (line 1654). I hope to fix it today. 2014-03-09 1:49 GMT+04:00 Ingela Andin : > Hi! > > 2014-03-07 11:14 GMT+01:00 Danil Zagoskin : > > Thank you! >> >> May I help you? Test case, pull request, etc? >> >> > You are always welcome to make a pull request which, if you follow the > guide lines, should include a test case. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > >> >> 2014-03-07 1:39 GMT+04:00 Ingela Andin : >> >>> Hi! >>> >>> 2014-03-06 11:50 GMT+01:00 Danil Zagoskin : >>> >>> Hello! >>>> >>>> My application is listening SSL port >>>> using ssl:listen, ssl:transport_accept and ssl:ssl_accept (indeed it uses >>>> some old patched mochiweb). >>>> Erlang/OTP release is R16B02. >>>> I use SASL for error logging. >>>> >>>> Due to existence of network scanners, network errors and buggy clients >>>> some of connections fail to negotiate. This leads to two kind of log >>>> entries: >>>> 1. "insufficient security", etc. >>>> 2. Crash reports due to a function_clause error >>>> in tls_v1:enum_to_oid(0) (this may be not the only one, but definitely the >>>> most popular) >>>> >>>> First one seems to be fixed by {log_alert, false} ssl option. >>>> Second one keeps flooding logs with huge state printouts. >>>> >>>> So, my question is: How to make all SSL-related troubles not to >>>> generate error reports? Simple {error, handshake_failed} returned by one of >>>> accepting functions would be enough. >>>> >>>> >>>> >>> >>> >>> The first option should logically be enough. I think the problem is that >>> tls_v1:enum_to_oid >>> should have a try and throw a handshake alert if it fails or be >>> ignored, depending on situation, i.e. be an expected error instead of an >>> unexpected error. I will create an issue to handle that. >>> >>> Regards Ingela Erlang/OTP team - Ericsson AB >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> >> -- >> --------------------------------------------- >> ????? ???????? | +7 906 064 20 47 | z@REDACTED >> > > -- --------------------------------------------- ????? ???????? | +7 906 064 20 47 | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From liuyanghejerry@REDACTED Sun Mar 9 15:56:57 2014 From: liuyanghejerry@REDACTED (liuyanghejerry) Date: Sun, 09 Mar 2014 22:56:57 +0800 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> Message-ID: <531C8139.9020108@126.com> ? 2014/3/8 22:01, Anthony Ramine ??: > The problem is not about what is accepted, it?s about how one?s (un)parser works. Sometimes you want a streaming-like API, sometimes the whole tree, etc. The Postel principle is orthogonal here. > So, all languages with JSON module in their standard library seems unbelievable? Because people need different parsers, so we give them no parser? I don't think this is a reason for rejecting it. From aschultz@REDACTED Sun Mar 9 17:11:15 2014 From: aschultz@REDACTED (Andreas Schultz) Date: Sun, 9 Mar 2014 16:11:15 +0000 (UTC) Subject: [erlang-questions] Making SSL fail silently In-Reply-To: References: Message-ID: <714432239.70973.1394381475592.JavaMail.zimbra@tpip.net> Hi, ----- Original Message ----- > I've investigated this case a bit and it seems to me that ECC handshake > implementation has a bug: > As fas as I understand RFC 4492 ( > https://tools.ietf.org/html/rfc4492#section-5.1 ), it tells that it's OK for > server to not support all curves supported by client if there are enough > curves supported by both of them. > So if I'm correct, the tls_v1:enum_to_oid/1 function should have a default > clause returning some magic value ('unsupported_curve' ?) which should be > filtered out from EllipticCurves list in ?ELLIPTIC_CURVES_EXT clause of > ssl_handshake:dec_hello_extensions/2 (line 1654). There have been several changes that went into R16B03 and R17 concerning the curve selection. Did you check if your problem also occurs with those releases? Andreas > > I hope to fix it today. > > > 2014-03-09 1:49 GMT+04:00 Ingela Andin < ingela.andin@REDACTED > : > > > > Hi! > > 2014-03-07 11:14 GMT+01:00 Danil Zagoskin < z@REDACTED > : > > > > > Thank you! > > May I help you? Test case, pull request, etc? > > > You are always welcome to make a pull request which, if you follow the guide > lines, should include a test case. > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > > 2014-03-07 1:39 GMT+04:00 Ingela Andin < ingela.andin@REDACTED > : > > > > Hi! > > 2014-03-06 11:50 GMT+01:00 Danil Zagoskin < z@REDACTED > : > > > > > Hello! > > My application is listening SSL port using ssl:listen, ssl:transport_accept > and ssl:ssl_accept (indeed it uses some old patched mochiweb). > Erlang/OTP release is R16B02. > I use SASL for error logging. > > Due to existence of network scanners, network errors and buggy clients some > of connections fail to negotiate. This leads to two kind of log entries: > 1. "insufficient security", etc. > 2. Crash reports due to a function_clause error in tls_v1:enum_to_oid(0) > (this may be not the only one, but definitely the most popular) > > First one seems to be fixed by {log_alert, false} ssl option. > Second one keeps flooding logs with huge state printouts. > > So, my question is: How to make all SSL-related troubles not to generate > error reports? Simple {error, handshake_failed} returned by one of accepting > functions would be enough. > > > > > The first option should logically be enough. I think the problem is that > tls_v1:enum_to_oid > should have a try and throw a handshake alert if it fails or be ignored, > depending on situation, i.e. be an expected error instead of an unexpected > error. I will create an issue to handle that. > > Regards Ingela Erlang/OTP team - Ericsson AB > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > --------------------------------------------- > ????? ???????? | +7 906 064 20 47 | z@REDACTED > > > > > -- > --------------------------------------------- > ????? ???????? | +7 906 064 20 47 | z@REDACTED > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- -- Dipl. Inform. Andreas Schultz email: as@REDACTED phone: +49-391-819099-224 mobil: +49-170-2226073 ------------------- enabling your networks ------------------- Travelping GmbH phone: +49-391-819099229 Roentgenstr. 13 fax: +49-391-819099299 D-39108 Magdeburg email: info@REDACTED GERMANY web: http://www.travelping.com Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 -------------------------------------------------------------- From z@REDACTED Sun Mar 9 17:43:38 2014 From: z@REDACTED (Danil Zagoskin) Date: Sun, 9 Mar 2014 20:43:38 +0400 Subject: [erlang-questions] Making SSL fail silently In-Reply-To: <714432239.70973.1394381475592.JavaMail.zimbra@tpip.net> References: <714432239.70973.1394381475592.JavaMail.zimbra@tpip.net> Message-ID: Yes, I have reproduced a crash in handshake parsing. Pull Request with test case is available at https://github.com/erlang/otp/pull/286 By the way, there is another crash when talking to security scanner ? badarg at crypto:rsa_sign_nif: ** Reason for termination = ** {badarg,[{crypto,rsa_sign_nif, [md5sha, {digest,<<124,187,138,41,125,55,222,61,16,209,73,157,86, 21,130,223,96,214,189,59,0,64,136,130,168,238, 245,220,105,191,145,194,112,201,251,184>>}, _LARGE_IOLIST_HERE_ ], []}, {crypto,sign,4,[{file,"crypto.erl"},{line,467}]}, {ssl_handshake,enc_server_key_exchange,6, [{file,"ssl_handshake.erl"},{line,660}]}, {tls_connection,key_exchange,1, [{file,"tls_connection.erl"},{line,1661}]}, {tls_connection,server_certify_and_key_exchange,1, [{file,"tls_connection.erl"},{line,1553}]}, {tls_connection,new_server_hello,2, [{file,"tls_connection.erl"},{line,1470}]}, {tls_connection,next_state,4, [{file,"tls_connection.erl"},{line,2548}]}, {gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}]} I'll look at this later. 2014-03-09 20:11 GMT+04:00 Andreas Schultz : > Hi, > > ----- Original Message ----- > > I've investigated this case a bit and it seems to me that ECC handshake > > implementation has a bug: > > As fas as I understand RFC 4492 ( > > https://tools.ietf.org/html/rfc4492#section-5.1 ), it tells that it's > OK for > > server to not support all curves supported by client if there are enough > > curves supported by both of them. > > So if I'm correct, the tls_v1:enum_to_oid/1 function should have a > default > > clause returning some magic value ('unsupported_curve' ?) which should be > > filtered out from EllipticCurves list in ?ELLIPTIC_CURVES_EXT clause of > > ssl_handshake:dec_hello_extensions/2 (line 1654). > > There have been several changes that went into R16B03 and R17 concerning > the curve selection. Did you check if your problem also occurs with those > releases? > > Andreas > > > > > I hope to fix it today. > > > > > > 2014-03-09 1:49 GMT+04:00 Ingela Andin < ingela.andin@REDACTED > : > > > > > > > > Hi! > > > > 2014-03-07 11:14 GMT+01:00 Danil Zagoskin < z@REDACTED > : > > > > > > > > > > Thank you! > > > > May I help you? Test case, pull request, etc? > > > > > > You are always welcome to make a pull request which, if you follow the > guide > > lines, should include a test case. > > > > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > > > > > > > > > 2014-03-07 1:39 GMT+04:00 Ingela Andin < ingela.andin@REDACTED > : > > > > > > > > Hi! > > > > 2014-03-06 11:50 GMT+01:00 Danil Zagoskin < z@REDACTED > : > > > > > > > > > > Hello! > > > > My application is listening SSL port using ssl:listen, > ssl:transport_accept > > and ssl:ssl_accept (indeed it uses some old patched mochiweb). > > Erlang/OTP release is R16B02. > > I use SASL for error logging. > > > > Due to existence of network scanners, network errors and buggy clients > some > > of connections fail to negotiate. This leads to two kind of log entries: > > 1. "insufficient security", etc. > > 2. Crash reports due to a function_clause error in tls_v1:enum_to_oid(0) > > (this may be not the only one, but definitely the most popular) > > > > First one seems to be fixed by {log_alert, false} ssl option. > > Second one keeps flooding logs with huge state printouts. > > > > So, my question is: How to make all SSL-related troubles not to generate > > error reports? Simple {error, handshake_failed} returned by one of > accepting > > functions would be enough. > > > > > > > > > > The first option should logically be enough. I think the problem is that > > tls_v1:enum_to_oid > > should have a try and throw a handshake alert if it fails or be ignored, > > depending on situation, i.e. be an expected error instead of an > unexpected > > error. I will create an issue to handle that. > > > > Regards Ingela Erlang/OTP team - Ericsson AB > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > > > > > > > -- > > --------------------------------------------- > > ????? ???????? | +7 906 064 20 47 | z@REDACTED > > > > > > > > > > -- > > --------------------------------------------- > > ????? ???????? | +7 906 064 20 47 | z@REDACTED > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > -- > Dipl. Inform. > Andreas Schultz > > email: as@REDACTED > phone: +49-391-819099-224 > mobil: +49-170-2226073 > > ------------------- enabling your networks ------------------- > > Travelping GmbH phone: +49-391-819099229 > Roentgenstr. 13 fax: +49-391-819099299 > D-39108 Magdeburg email: info@REDACTED > GERMANY web: http://www.travelping.com > > Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 > Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 > -------------------------------------------------------------- > -- --------------------------------------------- ????? ???????? | +7 906 064 20 47 | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Mar 9 18:05:40 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 9 Mar 2014 18:05:40 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <531C8139.9020108@126.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> Message-ID: <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> What about the utter lack of proper specifications around JSON? The fact that you always have to think about where the JSON will be injected? What about a JSON-encoded string containing "", should that be avoided by Erlang?s builtin parser? What about "]]>"? What about the two characters that are accepted in JSON but not in JavaScript? Just because other languages include such a thing doesn?t mean Erlang should too. If diversity is not a reason to reject it, other languages providing it is not a reason to include it either. -- Anthony Ramine Le 9 mars 2014 ? 15:56, liuyanghejerry a ?crit : > ? 2014/3/8 22:01, Anthony Ramine ??: >> The problem is not about what is accepted, it?s about how one?s (un)parser works. Sometimes you want a streaming-like API, sometimes the whole tree, etc. The Postel principle is orthogonal here. >> > > So, all languages with JSON module in their standard library seems unbelievable? Because people need different parsers, so we give them no parser? I don't think this is a reason for rejecting it. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From bob@REDACTED Sun Mar 9 19:35:24 2014 From: bob@REDACTED (Bob Ippolito) Date: Sun, 9 Mar 2014 11:35:24 -0700 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> Message-ID: It would be a bad idea to standardize something that nobody uses yet. How will we know if they got it right? Once it's in there, we're stuck with it. Arguably we should've had some JSON library by Erlang 16, but the community never really settled on a standard representation or API. Erlang 18 would be a much better time to add a standard maps-using JSON library. Perhaps even a lower level streaming parser too. On Sun, Mar 9, 2014 at 10:05 AM, Anthony Ramine wrote: > What about the utter lack of proper specifications around JSON? The fact > that you always have to think about where the JSON will be injected? > > What about a JSON-encoded string containing "", should that be > avoided by Erlang?s builtin parser? What about "]]>"? What about the two > characters that are accepted in JSON but not in JavaScript? > > Just because other languages include such a thing doesn?t mean Erlang > should too. If diversity is not a reason to reject it, other languages > providing it is not a reason to include it either. > > -- > Anthony Ramine > > Le 9 mars 2014 ? 15:56, liuyanghejerry a ?crit : > > > ? 2014/3/8 22:01, Anthony Ramine ??: > >> The problem is not about what is accepted, it?s about how one?s > (un)parser works. Sometimes you want a streaming-like API, sometimes the > whole tree, etc. The Postel principle is orthogonal here. > >> > > > > So, all languages with JSON module in their standard library seems > unbelievable? Because people need different parsers, so we give them no > parser? I don't think this is a reason for rejecting it. > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Mar 9 19:55:44 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 9 Mar 2014 19:55:44 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> Message-ID: <2770AE06-C7B9-44D7-BBF1-B0CE67424CBF@gmail.com> Too many big features in a single release would be bad. Wouldn?t you rather have ?cond?, ?&&?, and Clang-like diagnostics? :p -- Anthony Ramine Le 9 mars 2014 ? 19:35, Bob Ippolito a ?crit : > Erlang 18 would be a much better time to add a standard maps-using JSON library. Perhaps even a lower level streaming parser too. From cabo@REDACTED Sun Mar 9 20:06:27 2014 From: cabo@REDACTED (Carsten Bormann) Date: Sun, 9 Mar 2014 19:06:27 +0000 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> Message-ID: <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> On 09 Mar 2014, at 17:05, Anthony Ramine wrote: > What about the utter lack of proper specifications around JSON? JSON is fully specified in RFC 7159. > The fact that you always have to think about where the JSON will be injected? Why would you need to think about that? JSON is usually transported using a data-transparent transfer mechanism such as HTTP. If it isn?t, you may need some help from an application-specific library, but that is irrelevant for the dominant usage of JSON. > What about a JSON-encoded string containing "", should that be avoided by Erlang?s builtin parser? What about "]]>"? What about the two characters that are accepted in JSON but not in JavaScript? The news here may be that in the present decade JSON rarely is transported inside HTML documents or converted into JavaScript for parsing. So all this is entirely irrelevant. > Just because other languages include such a thing doesn?t mean Erlang should too. Of course that would be a weak reason. But it's a straw man. The reason for supporting JSON at the standard library level is that JSON is the most widely used format to interchange data. Not having it is fine for a language that doesn?t care about interchanging data. Gr??e, Carsten From mark.nijhof@REDACTED Sun Mar 9 20:07:30 2014 From: mark.nijhof@REDACTED (Mark Nijhof) Date: Sun, 9 Mar 2014 20:07:30 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <2770AE06-C7B9-44D7-BBF1-B0CE67424CBF@gmail.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <2770AE06-C7B9-44D7-BBF1-B0CE67424CBF@gmail.com> Message-ID: JSON parser seems easy to do as a seperate project anyway? On Mar 9, 2014 7:55 PM, "Anthony Ramine" wrote: > Too many big features in a single release would be bad. > > Wouldn't you rather have 'cond', '&&', and Clang-like diagnostics? :p > > -- > Anthony Ramine > > Le 9 mars 2014 ? 19:35, Bob Ippolito a ?crit : > > > Erlang 18 would be a much better time to add a standard maps-using JSON > library. Perhaps even a lower level streaming parser too. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob@REDACTED Sun Mar 9 20:20:17 2014 From: bob@REDACTED (Bob Ippolito) Date: Sun, 9 Mar 2014 12:20:17 -0700 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <2770AE06-C7B9-44D7-BBF1-B0CE67424CBF@gmail.com> Message-ID: It is, which is why we have so many of them. On Sun, Mar 9, 2014 at 12:07 PM, Mark Nijhof wrote: > JSON parser seems easy to do as a seperate project anyway? > On Mar 9, 2014 7:55 PM, "Anthony Ramine" wrote: > >> Too many big features in a single release would be bad. >> >> Wouldn?t you rather have ?cond?, ?&&?, and Clang-like diagnostics? :p >> >> -- >> Anthony Ramine >> >> Le 9 mars 2014 ? 19:35, Bob Ippolito a ?crit : >> >> > Erlang 18 would be a much better time to add a standard maps-using JSON >> library. Perhaps even a lower level streaming parser too. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Mar 9 20:25:31 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 9 Mar 2014 20:25:31 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> Message-ID: <186CA341-8834-4434-B126-64BAC675A6D4@gmail.com> Replied inline. -- Anthony Ramine Le 9 mars 2014 ? 20:06, Carsten Bormann a ?crit : > On 09 Mar 2014, at 17:05, Anthony Ramine wrote: > >> What about the utter lack of proper specifications around JSON? > > JSON is fully specified in RFC 7159. I said around. There is absolutely no tooling around JSON which is properly specified and widely used, that was to reply to the namedropping of ASN.1 and XML. >> The fact that you always have to think about where the JSON will be injected? > > Why would you need to think about that? JSON is usually transported using a data-transparent transfer mechanism such as HTTP. > If it isn?t, you may need some help from an application-specific library, but that is irrelevant for the dominant usage of JSON. Dominant? Do you have statistics for this? My own experience is that we inject JSON in webpages a lot. Stack Overflow seems to agree. >> What about a JSON-encoded string containing "", should that be avoided by Erlang?s builtin parser? What about "]]>"? What about the two characters that are accepted in JSON but not in JavaScript? > > The news here may be that in the present decade JSON rarely is transported inside HTML documents or converted into JavaScript for parsing. So all this is entirely irrelevant. See above. PHP has some options to counter these problems, Rails has escape_html_entities_in_json. >> Just because other languages include such a thing doesn?t mean Erlang should too. > > Of course that would be a weak reason. But it's a straw man. > The reason for supporting JSON at the standard library level is that JSON is the most widely used format to interchange data. Most widely used? In the web probably. In other fields, I wouldn?t bet on this. > Not having it is fine for a language that doesn?t care about interchanging data. Given that there is a myriad of third-party JSON libraries, what?s the problem? And a standard library which sets in stone such a supposedly-important feature the moment a convenient datatype is available isn?t worth anything, in my opinion. From z@REDACTED Sun Mar 9 20:25:11 2014 From: z@REDACTED (Danil Zagoskin) Date: Sun, 9 Mar 2014 23:25:11 +0400 Subject: [erlang-questions] [ANN] io_libc -- fast formatting NIF Message-ID: Hello! This is io_libc: https://github.com/maxlapshin/io_libc It was created to speedup massive CSV generation but may be useful for other purposes. io_libc provides an erlangish interface to standard C printf(). It has very poor protection from malformed input, falling back to zeroes and empty strings, but it is very fast. Some examples: erl> io_libc:format("hello, %08.3f, %s %04X!", [3.14, dead, 48879]). <<"hello, 0003.140, dead BEEF!">> erl> io_libc:format("%*.*f; %0*d", [8, 3, 2.7, 6, 12]). <<" 2.700; 000012">> -- Danil Zagoskin | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Mar 9 20:38:03 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 9 Mar 2014 20:38:03 +0100 Subject: [erlang-questions] [ANN] io_libc -- fast formatting NIF In-Reply-To: References: Message-ID: <103F4C3E-525E-47C4-90FC-821971DB8BCB@gmail.com> What about hooking up into erts_*printf? -- Anthony Ramine Le 9 mars 2014 ? 20:25, Danil Zagoskin a ?crit : > Hello! > > This is io_libc: https://github.com/maxlapshin/io_libc > It was created to speedup massive CSV generation but may be useful for other purposes. > > io_libc provides an erlangish interface to standard C printf(). > > It has very poor protection from malformed input, falling back to zeroes and empty strings, but it is very fast. > > Some examples: > > erl> io_libc:format("hello, %08.3f, %s %04X!", [3.14, dead, 48879]). > <<"hello, 0003.140, dead BEEF!">> > > erl> io_libc:format("%*.*f; %0*d", [8, 3, 2.7, 6, 12]). > <<" 2.700; 000012">> > > -- > Danil Zagoskin | z@REDACTED > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From z@REDACTED Sun Mar 9 20:56:22 2014 From: z@REDACTED (Danil Zagoskin) Date: Sun, 9 Mar 2014 23:56:22 +0400 Subject: [erlang-questions] [ANN] io_libc -- fast formatting NIF In-Reply-To: <103F4C3E-525E-47C4-90FC-821971DB8BCB@gmail.com> References: <103F4C3E-525E-47C4-90FC-821971DB8BCB@gmail.com> Message-ID: 1. We didn't know about these functions. 2. There is no erts_asprintf, so we need to guess the length of output buffer 3. Files in this directory are *not* for public use and should *only* be used by Erlang/OTP applications. The content of this directory and the interfaces present in this directory may be changed at any time without prior notice. 2014-03-09 23:38 GMT+04:00 Anthony Ramine : > What about hooking up into erts_*printf? > > -- > Anthony Ramine > > Le 9 mars 2014 ? 20:25, Danil Zagoskin a ?crit : > > > Hello! > > > > This is io_libc: https://github.com/maxlapshin/io_libc > > It was created to speedup massive CSV generation but may be useful for > other purposes. > > > > io_libc provides an erlangish interface to standard C printf(). > > > > It has very poor protection from malformed input, falling back to zeroes > and empty strings, but it is very fast. > > > > Some examples: > > > > erl> io_libc:format("hello, %08.3f, %s %04X!", [3.14, dead, 48879]). > > <<"hello, 0003.140, dead BEEF!">> > > > > erl> io_libc:format("%*.*f; %0*d", [8, 3, 2.7, 6, 12]). > > <<" 2.700; 000012">> > > > > -- > > Danil Zagoskin | z@REDACTED > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > -- --------------------------------------------- ????? ???????? | +7 906 064 20 47 | z@REDACTED -------------- next part -------------- An HTML attachment was scrubbed... URL: From cabo@REDACTED Sun Mar 9 22:15:24 2014 From: cabo@REDACTED (Carsten Bormann) Date: Sun, 9 Mar 2014 21:15:24 +0000 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <186CA341-8834-4434-B126-64BAC675A6D4@gmail.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> <186CA341-8834-4434-B126-64BAC675A6D4@gmail.com> Message-ID: <052CB271-B551-4465-9568-CCDD1CCDACE0@tzi.org> > I said around. There is absolutely no tooling around JSON which is properly specified and widely used, that was to reply to the namedropping of ASN.1 and XML. Yeah. JSON is ready to eat. No ASN.1 compilers or XML schema tools needed. > Dominant? Do you have statistics for this? My own experience is that we inject JSON in webpages a lot. Indeed, I had the impression that the comments would relate to such a background. > Stack Overflow seems to agree. Stack Overflow certainly agrees that this usage is problematic and therefore generates a lot of questions about how to remove the bullet from the foot, > See above. PHP has some options to counter these problems, Rails has escape_html_entities_in_json. PHP has a lot of things that are not needed in Erlang? The Rails people have since learned that generating JavaScript with data values inserted is not such a great idea (the feature is not really about JSON despite its name). >>> Just because other languages include such a thing doesn?t mean Erlang should too. >> >> Of course that would be a weak reason. But it's a straw man. >> The reason for supporting JSON at the standard library level is that JSON is the most widely used format to interchange data. > > Most widely used? In the web probably. In other fields, I wouldn?t bet on this. It?s not replacing HDF5. But it is quickly getting rid of CSV, XML, and a ton of ad-hoc syntaxes that together with a bit of spit and string hold together the Economy. > Given that there is a myriad of third-party JSON libraries, what?s the problem? That *is* the problem. When I need to print a floating-point number, I don?t start looking for and comparing third-party libraries. (Printing floating-point is a problem that is about ten times as difficult as the problem of printing JSON is when you already can print floating point numbers. It also has more parameters than a JSON printer needs.) > And a standard library which sets in stone such a supposedly-important feature the moment a convenient datatype is available isn?t worth anything, in my opinion. Well, it?s worth to design it properly then. The reason I?m reacting to this discussion is that it seems to be dominated by people who have never used JSON for what it is good at. That is not a character flaw, but it may skew the discussion in the wrong direction. (Replace ?JSON? with ?strings decimally representing floating point numbers? in the previous messages in this thread to find out how ridiculous some of them sound to me.) Gr??e, Carsten From jd@REDACTED Mon Mar 10 05:24:54 2014 From: jd@REDACTED (John Daily) Date: Mon, 10 Mar 2014 00:24:54 -0400 Subject: [erlang-questions] UTF-8 and escript problem Message-ID: <73A4434B-F467-4050-8E79-83665630831A@epep.us> I ran into a problem with io:format() when invoked remotely, and with Scott Fritchie?s assistance I?ve narrowed it down (I think) to escript. Here?s my script: #!/usr/bin/env escript %% %%! -sname foo main([]) -> Other = 'bar@REDACTED', Farsi = [1601,1575,1585,1587,1740], Farsi2 = "?????", spawn(Other, fun() -> io:format("Bytes: ~ts~n", [Farsi]) end), spawn(Other, fun() -> io:format("Bytes: ~w~n", [Farsi]) end), spawn(Other, fun() -> io:format("Paste: ~ts~n", [Farsi2]) end), spawn(Other, fun() -> io:format("Paste: ~w~n", [Farsi2]) end), timer:sleep(1000). When attempting this directly from a different node?s console (spawned to run on ?bar?), everything displays as expected: Bytes: ????? Bytes: [1601,1575,1585,1587,1740] Paste: ????? Paste: [1601,1575,1585,1587,1740] When invoked via the above escript, I consistently get the wrong output: Bytes: \x{641}\x{627}\x{631}\x{633}\x{6CC} Bytes: [1601,1575,1585,1587,1740] Paste: ????? Paste: [217,129,216,167,216,177,216,179,219,140] This is repeatable on R15B01 and R16B03-1, both under OS X Mavericks installed via kerl. My LANG environment variable is set to en_US.UTF-8, and all other UTF-8 behavior seems correct. Just spun up an older Amazon Linux AMI instance running R15B01. Same behavior. My unicode experience consists of years of banging my head against various toolchain problems with only a marginal clue as to what?s supposed to happen, so my ability to troubleshoot this further is limited. -John -------------- next part -------------- An HTML attachment was scrubbed... URL: From jd@REDACTED Mon Mar 10 05:34:49 2014 From: jd@REDACTED (John Daily) Date: Mon, 10 Mar 2014 00:34:49 -0400 Subject: [erlang-questions] UTF-8 and escript problem In-Reply-To: <73A4434B-F467-4050-8E79-83665630831A@epep.us> References: <73A4434B-F467-4050-8E79-83665630831A@epep.us> Message-ID: And I think I?ve found the solution in an older thread. Still no support for unicode strings directly embedded in the source. Thanks, sorry for the noise. -John On Mar 10, 2014, at 12:24 AM, John Daily wrote: > I ran into a problem with io:format() when invoked remotely, and with Scott Fritchie?s assistance I?ve narrowed it down (I think) to escript. > > Here?s my script: > > #!/usr/bin/env escript > %% > %%! -sname foo > > main([]) -> > Other = 'bar@REDACTED', > Farsi = [1601,1575,1585,1587,1740], > Farsi2 = "?????", > spawn(Other, fun() -> io:format("Bytes: ~ts~n", [Farsi]) end), > spawn(Other, fun() -> io:format("Bytes: ~w~n", [Farsi]) end), > spawn(Other, fun() -> io:format("Paste: ~ts~n", [Farsi2]) end), > spawn(Other, fun() -> io:format("Paste: ~w~n", [Farsi2]) end), > timer:sleep(1000). > > When attempting this directly from a different node?s console (spawned to run on ?bar?), everything displays as expected: > > Bytes: ????? > Bytes: [1601,1575,1585,1587,1740] > Paste: ????? > Paste: [1601,1575,1585,1587,1740] > > When invoked via the above escript, I consistently get the wrong output: > > Bytes: \x{641}\x{627}\x{631}\x{633}\x{6CC} > Bytes: [1601,1575,1585,1587,1740] > Paste: ????? > Paste: [217,129,216,167,216,177,216,179,219,140] > > This is repeatable on R15B01 and R16B03-1, both under OS X Mavericks installed via kerl. My LANG environment variable is set to en_US.UTF-8, and all other UTF-8 behavior seems correct. > > Just spun up an older Amazon Linux AMI instance running R15B01. Same behavior. > > My unicode experience consists of years of banging my head against various toolchain problems with only a marginal clue as to what?s supposed to happen, so my ability to troubleshoot this further is limited. > > -John > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liuyanghejerry@REDACTED Mon Mar 10 03:43:02 2014 From: liuyanghejerry@REDACTED (liuyanghejerry) Date: Mon, 10 Mar 2014 10:43:02 +0800 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> Message-ID: <531D26B6.90503@126.com> > The fact that you always have to think about where the JSON will be injected? Yes I do, because I really hope Erlang std lib has it so I can use it without searching "what JSON package do you use with Erlang", without considering too much about compatibility, etc. Yes, I want my life easier with Erlang. > What about a JSON-encoded string containing "", should that be avoided by Erlang?s builtin parser? What about "]]>"? What about the two characters that are accepted in JSON but not in JavaScript? JSON is not really that tight with JavaScript and HTML, you may want to learn more[1]. > > Just because other languages include such a thing doesn?t mean Erlang should too. If diversity is not a reason to reject it, other languages providing it is not a reason to include it either. > Yes, it is my point that it's not a reason to reject it. Since you're questioning how parsers should behave, there're lots of "examples" in other languages. [1]: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf From jd@REDACTED Mon Mar 10 06:13:55 2014 From: jd@REDACTED (John Daily) Date: Mon, 10 Mar 2014 01:13:55 -0400 Subject: [erlang-questions] UTF-8 and escript problem In-Reply-To: References: <73A4434B-F467-4050-8E79-83665630831A@epep.us> Message-ID: <1B671483-459E-4D24-B07B-578874006234@epep.us> I retract my retraction. Setting aside the unworkable Farsi2 variable, Farsi (expressed in bytes) really should work, but displays as \x{641}\x{627}\x{631}\x{633}\x{6CC}. Why? -John On Mar 10, 2014, at 12:34 AM, John Daily wrote: > And I think I?ve found the solution in an older thread. Still no support for unicode strings directly embedded in the source. Thanks, sorry for the noise. > > -John > > On Mar 10, 2014, at 12:24 AM, John Daily wrote: > >> I ran into a problem with io:format() when invoked remotely, and with Scott Fritchie?s assistance I?ve narrowed it down (I think) to escript. >> >> Here?s my script: >> >> #!/usr/bin/env escript >> %% >> %%! -sname foo >> >> main([]) -> >> Other = 'bar@REDACTED', >> Farsi = [1601,1575,1585,1587,1740], >> Farsi2 = "?????", >> spawn(Other, fun() -> io:format("Bytes: ~ts~n", [Farsi]) end), >> spawn(Other, fun() -> io:format("Bytes: ~w~n", [Farsi]) end), >> spawn(Other, fun() -> io:format("Paste: ~ts~n", [Farsi2]) end), >> spawn(Other, fun() -> io:format("Paste: ~w~n", [Farsi2]) end), >> timer:sleep(1000). >> >> When attempting this directly from a different node?s console (spawned to run on ?bar?), everything displays as expected: >> >> Bytes: ????? >> Bytes: [1601,1575,1585,1587,1740] >> Paste: ????? >> Paste: [1601,1575,1585,1587,1740] >> >> When invoked via the above escript, I consistently get the wrong output: >> >> Bytes: \x{641}\x{627}\x{631}\x{633}\x{6CC} >> Bytes: [1601,1575,1585,1587,1740] >> Paste: ????? >> Paste: [217,129,216,167,216,177,216,179,219,140] >> >> This is repeatable on R15B01 and R16B03-1, both under OS X Mavericks installed via kerl. My LANG environment variable is set to en_US.UTF-8, and all other UTF-8 behavior seems correct. >> >> Just spun up an older Amazon Linux AMI instance running R15B01. Same behavior. >> >> My unicode experience consists of years of banging my head against various toolchain problems with only a marginal clue as to what?s supposed to happen, so my ability to troubleshoot this further is limited. >> >> -John >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordon@REDACTED Mon Mar 10 07:35:54 2014 From: gordon@REDACTED (Gordon Guthrie) Date: Mon, 10 Mar 2014 06:35:54 +0000 Subject: [erlang-questions] [ANN] emdoc-1.0 In-Reply-To: References: <1393525350.60465.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: I have been playing around with a literate-erlang markdown approach - specifically designed to make good looking GitHub repositories: https://github.com/hypernumbers/literate-erlang The project I am using it on is LuvvieScript: https://github.com/hypernumbers/LuvvieScript I originally wrote ErlMarkdown: https://github.com/hypernumbers/erlmarkdown but for literate erlang abandoned that in favour of just using Git-flavoured markdown. Gordon On 28 February 2014 02:13, Leo Liu wrote: > On 2014-02-28 03:02 +0800, Sean Cribbs wrote: > > There's also edown: https://github.com/esl/edown > > Any plan to merge it with edoc? > > Leo > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- --- Gordon Guthrie CEO vixo.com @gordonguthrie +44 (0) 7776 251669 (in Bonnie Scotland!) vixo is made in Scotland from electrons -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Mar 10 11:03:01 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 10 Mar 2014 03:03:01 -0700 (PDT) Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> Message-ID: <1394445781.29146.YahooMailNeo@web140104.mail.bf1.yahoo.com> "What about a JSON-encoded string containing "", should that be avoided by Erlang?s builtin parser? What about "]]>"? What about the two characters that are accepted in JSON but not in JavaScript" To what extent are these issues problematic in an Erlang environment?? My proposal: support an optional plugin API for sanitizing strings, and provide a standard plugin that detects these cases. Best, Thomas On Sunday, March 9, 2014 6:05 PM, Anthony Ramine wrote: What about the utter lack of proper specifications around JSON? The fact that you always have to think about where the JSON will be injected? > >What about a JSON-encoded string containing "", should that be avoided by Erlang?s builtin parser? What about "]]>"? What about the two characters that are accepted in JSON but not in JavaScript? > >Just because other languages include such a thing doesn?t mean Erlang should too. If diversity is not a reason to reject it, other languages providing it is not a reason to include it either. > >-- >Anthony Ramine > >Le 9 mars 2014 ? 15:56, liuyanghejerry a ?crit : > >> ? 2014/3/8 22:01, Anthony Ramine ??: >>> The problem is not about what is accepted, it?s about how one?s (un)parser works. Sometimes you want a streaming-like API, sometimes the whole tree, etc. The Postel principle is orthogonal here. >>> >> >> So, all languages with JSON module in their standard library seems unbelievable? Because people need different parsers, so we give them no parser? I don't think this is a reason for rejecting it. >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Mar 10 11:07:44 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 10 Mar 2014 11:07:44 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <531D26B6.90503@126.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <531D26B6.90503@126.com> Message-ID: Hi, Some important points to consider: * If you put a library into stdlib, it becomes a slow moving target. That is, changes to this library will take months. Since maps are so new, it would be better to iterate the library outside the standard release in any case. Cutting down the OTP standard libraries is an important goal since it unties the hands of the OTP team so they have to maintain less code. * I think the parsing/unparsing is the least of the problems to handle. We can, with proper options, work around oddities that doesn't follow the standard correctly in both directions. * The library API however, is going to be hard to tackle. Some will want a C-NIF because lolspeed. Some will want stability and an implementation in Erlang. Some will want SAX-style parsing and some just wants a term fully decoded. Some will want an enumerator/iteratee pattern for chunked decoding over a socket. Some will hate streaming. Some will like to inject transforming functions into the JSON parser. Some will want the ability to turn JSON objects into erlang records. And so on. Any implementation will only support a subset of this. The different implementations have differing guarantees. I think this is good because we avoid one-library-to-rule-them-all and the bad design symptoms it brings. On Mon, Mar 10, 2014 at 3:43 AM, liuyanghejerry wrote: > > The fact that you always have to think about where the JSON will be >> injected? >> > > Yes I do, because I really hope Erlang std lib has it so I can use it > without searching "what JSON package do you use with Erlang", without > considering too much about compatibility, etc. Yes, I want my life easier > with Erlang. > > > What about a JSON-encoded string containing "", should that be >> avoided by Erlang?s builtin parser? What about "]]>"? What about the two >> characters that are accepted in JSON but not in JavaScript? >> > > JSON is not really that tight with JavaScript and HTML, you may want to > learn more[1]. > > > >> Just because other languages include such a thing doesn?t mean Erlang >> should too. If diversity is not a reason to reject it, other languages >> providing it is not a reason to include it either. >> >> > Yes, it is my point that it's not a reason to reject it. Since you're > questioning how parsers should behave, there're lots of "examples" in other > languages. > > [1]: http://www.ecma-international.org/publications/files/ECMA- > ST/ECMA-404.pdf > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Mon Mar 10 11:08:50 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Mon, 10 Mar 2014 10:08:50 +0000 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <1394445781.29146.YahooMailNeo@web140104.mail.bf1.yahoo.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <1394445781.29146.YahooMailNeo@web140104.mail.bf1.yahoo.com> Message-ID: <531D8F32.20601@llaisdy.com> Apart from anything else there is the question of whether the json parser should be written in erlang or C. There are good arguments, and use cases, for each. Should the erlang standard library have two json parsers? The status quo is fine. It's not as if the preferred erlang json parsers are hard to find. Ivan On 10/03/2014 10:03, Thomas Lindgren wrote: > "What about a JSON-encoded string containing "", should that be > avoided by Erlang?s builtin parser? What about "]]>"? What about the two > characters that are accepted in JSON but not in JavaScript" > > To what extent are these issues problematic in an Erlang environment? > > My proposal: support an optional plugin API for sanitizing strings, and > provide a standard plugin that detects these cases. > > Best, > Thomas > > > On Sunday, March 9, 2014 6:05 PM, Anthony Ramine wrote: > > What about the utter lack of proper specifications around JSON? The > fact that you always have to think about where the JSON will be > injected? > > What about a JSON-encoded string containing "", should that > be avoided by Erlang?s builtin parser? What about "]]>"? What about > the two characters that are accepted in JSON but not in JavaScript? > > Just because other languages include such a thing doesn?t mean > Erlang should too. If diversity is not a reason to reject it, other > languages providing it is not a reason to include it either. > > -- > Anthony Ramine > > Le 9 mars 2014 ? 15:56, liuyanghejerry > a ?crit : > > > ? 2014/3/8 22:01, Anthony Ramine ??: > >> The problem is not about what is accepted, it?s about how one?s > (un)parser works. Sometimes you want a streaming-like API, sometimes > the whole tree, etc. The Postel principle is orthogonal here. > >> > > > > So, all languages with JSON module in their standard library > seems unbelievable? Because people need different parsers, so we > give them no parser? I don't think this is a reason for rejecting it. > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From n.oxyde@REDACTED Mon Mar 10 11:14:32 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Mon, 10 Mar 2014 11:14:32 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <531D26B6.90503@126.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <531D26B6.90503@126.com> Message-ID: <8C1087A3-C6D8-4302-B459-208D088FB512@gmail.com> I didn?t assume anything about your own knowledge so feel free to do the same. Even jsx, the most popular Erlang JSON lib, has options to handle these issues. -- Anthony Ramine Le 10 mars 2014 ? 03:43, liuyanghejerry a ?crit : > >> The fact that you always have to think about where the JSON will be injected? > > Yes I do, because I really hope Erlang std lib has it so I can use it without searching "what JSON package do you use with Erlang", without considering too much about compatibility, etc. Yes, I want my life easier with Erlang. > >> What about a JSON-encoded string containing "", should that be avoided by Erlang?s builtin parser? What about "]]>"? What about the two characters that are accepted in JSON but not in JavaScript? > > JSON is not really that tight with JavaScript and HTML, you may want to learn more[1]. > >> >> Just because other languages include such a thing doesn?t mean Erlang should too. If diversity is not a reason to reject it, other languages providing it is not a reason to include it either. >> > > Yes, it is my point that it's not a reason to reject it. Since you're questioning how parsers should behave, there're lots of "examples" in other languages. > > [1]: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf > From davidnwelton@REDACTED Mon Mar 10 11:30:10 2014 From: davidnwelton@REDACTED (David Welton) Date: Mon, 10 Mar 2014 11:30:10 +0100 Subject: [erlang-questions] default timeout values for a library (epgsql) Message-ID: Hi, We've been having something of a debate on the epgsql mailing list about timeouts for database queries: https://groups.google.com/forum/#!topic/epgsql/jmwSCybEN3E I thought that it'd be interesting to hear how other people handle things like this. One thing that looks like we need is the ability to specify a timeout, but, beyond that, I just thought I'd ask a wider group of people what their thoughts are on timeouts in library code like this. Thank you, -- David N. Welton http://www.welton.it/davidw/ http://www.dedasys.com/ From jesper.louis.andersen@REDACTED Mon Mar 10 12:29:14 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 10 Mar 2014 12:29:14 +0100 Subject: [erlang-questions] default timeout values for a library (epgsql) In-Reply-To: References: Message-ID: There are two things to consider here: 1. A client is using the database library. Surely, you want some kind of progress in the client. Progress here means that if you time out, you want to do something with the client in question. Maybe it should crash. Maybe it should do something else. There is a *protocol* between the client and the database driver. Clearly, it should be possible for the client to set a timeout on the connection. Also, if the client dies and goes away, the database driver must have a way to clean up after this incident. It can not be the responsibility of the client to do so. 2. The database driver has a TCP/SSL socket to the database server. This transport has some kind of progress as well. It might be that you want to keep the connection alive, or that you know the DB server will send a "I am still processing goddamit!" back to the client once in a while. These two cases are orthogonal. You can't just set a 10 second timeout, because there will be queries which take longer than 10 seconds to even begin returning result sets (typical if there is a large sort job in the query planner pipeline). On the other hand, you want clients to be able to cancel a currently running query so you can break long-running jobs on the server side. My hunch is that a good solution is found by: * Thinking about crash behaviour. What should happen if a given process crashes? * Thinking in terms of protocols. What is the client -> driver protocol? What is the driver -> server protocol? * Constraining the set of guarantees you give the client. You may have to trade off certain aspects in order to achieve better performance or reliability. The Emysql driver mashed these things together and a lot of problems arise from the fact that there is no separation of protocols in it. Suddenly, TCP transport timeouts lingers in the API of the client. Why are they doing that? All of a sudden, if I set `infinity` as a timeout, the result is that a client can be blocked ad infinitum. So the timeout has been pushed back and forth between infinity and some random default value between 3000 and 60000 ms. Also, most Erlang code I have seen written utterly fails handling this by error handling and uses timeout values as a first-principle for handling error. The timeout should be a safety measure to ensure a subsystem has progress. On the other hand, a client which "hangs" on a TCP session until some other event might kill it is not a problem. As long as there is *some* event which can ensure progress in the system. and that was my 2 cents. On Mon, Mar 10, 2014 at 11:30 AM, David Welton wrote: > Hi, > > We've been having something of a debate on the epgsql mailing list > about timeouts for database queries: > > https://groups.google.com/forum/#!topic/epgsql/jmwSCybEN3E > > I thought that it'd be interesting to hear how other people handle > things like this. > > One thing that looks like we need is the ability to specify a timeout, > but, beyond that, I just thought I'd ask a wider group of people what > their thoughts are on timeouts in library code like this. > > Thank you, > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liuyanghejerry@REDACTED Mon Mar 10 12:56:02 2014 From: liuyanghejerry@REDACTED (liuyanghejerry) Date: Mon, 10 Mar 2014 19:56:02 +0800 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <8C1087A3-C6D8-4302-B459-208D088FB512@gmail.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <531D26B6.90503@126.com> <8C1087A3-C6D8-4302-B459-208D088FB512@gmail.com> Message-ID: <531DA852.6000009@126.com> ? 2014/3/10 18:14, Anthony Ramine ??: > I didn?t assume anything about your own knowledge so feel free to do the same. > > Even jsx, the most popular Erlang JSON lib, has options to handle these issues. > ? 2014/3/10 18:07, Jesper Louis Andersen ??: > Hi, > > Some important points to consider: > > * If you put a library into stdlib, it becomes a slow moving target. > That is, changes to this library will take months. Since maps are so > new, it would be better to iterate the library outside the standard > release in any case. Cutting down the OTP standard libraries is an > important goal since it unties the hands of the OTP team so they have > to maintain less code. > > * I think the parsing/unparsing is the least of the problems to > handle. We can, with proper options, work around oddities that doesn't > follow the standard correctly in both directions. > > * The library API however, is going to be hard to tackle. Some will > want a C-NIF because lolspeed. Some will want stability and an > implementation in Erlang. Some will want SAX-style parsing and some > just wants a term fully decoded. Some will want an enumerator/iteratee > pattern for chunked decoding over a socket. Some will hate streaming. > Some will like to inject transforming functions into the JSON parser. > Some will want the ability to turn JSON objects into erlang records. > And so on. Any implementation will only support a subset of this. > > The different implementations have differing guarantees. I think this > is good because we avoid one-library-to-rule-them-all and the bad > design symptoms it brings. Okay, then. I didn't consider that much. Is there anything like "playground" for experimental libraries? Start JSON library there may be better? From alex@REDACTED Mon Mar 10 13:03:15 2014 From: alex@REDACTED (Aleksandar Radulovic) Date: Mon, 10 Mar 2014 13:03:15 +0100 Subject: [erlang-questions] Creating a fault tolerant poker service In-Reply-To: References: Message-ID: Hey, You might want to check out riak_core [1] which looks like it will suit your needs. With it, you can partition your users, games and whatnot and distribute work between the nodes. It will also handle node memberships to the "ring" for you, so you don't have to worry about nodes dropping out and such. It's actually quite easy to integrate into an existing OTP application. [1] - https://github.com/basho/riak_core Cheers, alex On Fri, Mar 7, 2014 at 3:09 AM, Cary Cherng wrote: > What is the idiomatic way to create a fault tolerant poker service with > Erlang? > > One could use a single server type, a bunch of machines for a > fragmented mnesia table that stores the state of each game. This > ensures that state is replicated to guard against machine failures. > > > But it still leaves questions open: > > * How are games created so that they are load balanced across the > servers so that cpu usage is relatively even? If game creation goes > through some special server that also keeps track of where all games > are so it knows loads on the backends, then that special server is a > potential single failure point. > > * And a similar problem. If a user is disconnected, how does it find > which games it is part of when it reconnects without some special > server to track games. > > > I am aware that others have made poker services with Erlang such as > OpenPoker. But what would be the right idiomatic way of architecting a > poker service to be resistant to machine failures assuming you were > starting from scratch? > > The questions I asked above imply features that I would expect many > distributed systems would need. That is a kind of abstract pattern. > Are there maybe design patterns for these kinds of distributed > systems? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- a lex 13 x http://a13x.net | @a13xnet -------------- next part -------------- An HTML attachment was scrubbed... URL: From eriksoe@REDACTED Mon Mar 10 13:19:46 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 10 Mar 2014 13:19:46 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: By the way, whatever happened to the community library list on erlang.org? The linked page, http://www.erlang.org/user.html , is a 404 these days... And it sounds like it could still be useful (especially if maintained to a reasonable degree). Den 08/03/2014 14.15 skrev "Jesper Louis Andersen" < jesper.louis.andersen@REDACTED>: > > On Sat, Mar 8, 2014 at 2:01 PM, Charles Irvine wrote: > >> I recently read that the "JSON Bridge" that Joe Armstrong describes in >> his new book won't be included in Erlang 17.0. This would have been very >> useful. With Json becoming so prevalent (web services, browsers, Mongodb, >> etc), I think it is really surpassing XML as a common data interoperability >> format. It must have been on the table at one point or it wouldn't have >> appeared in Joe's book. Why did it not make it into the release? I think >> someone indicated that it really didn't belong in the maps module and I can >> kind of see that. But why not just put it in a "json" module? Regards, Chuck > > > We already have a fair number of JSON handlers for Erlang: > > jsx, jiffy, mochijson, mochijson2, yaws json (deprecated), yaws json2, ... > > The reason we have that many is quite simple. One JSON parser does not > satisfy all requirements. And to make things worse, there are small > fluctuations in the "standard" which make it hard to create proper support. > Adding a `json` module to the standard library is asking for jumping into > this minefield. I'd much rather see libraries adopt maps as a way to > represent JSON structures in Erlang. With maps, there is a neat mapping > between most JSON documents and Erlang terms which will be useful. But I > would be wary of standardizing on one due to the different requirements in > handling. > > > > > -- > J. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christopher.Phillips@REDACTED Mon Mar 10 14:17:02 2014 From: Christopher.Phillips@REDACTED (Phillips, Christopher) Date: Mon, 10 Mar 2014 13:17:02 +0000 Subject: [erlang-questions] Videos from Erlang Factory SF Bay 2014 up on ErlangCentral.org Message-ID: This does not address the base issue that it makes it less approachable for new people, but you can find them on youtube under ErlangSolution's account; https://www.youtube.com/user/ErlangSolutions/videos?view=0&shelf_id=1&sort= dd On 3/8/14, 6:00 AM, "erlang-questions-request@REDACTED" wrote: > >I had the same problem - I cannot read or watch content on Erlang Central >website without an account so I actually set up an account in order to do >so (very rare occurrence). Then I do not receive the activation email >which >it seems you must have to actually use an account. So I try to log in and >fail, then go to the effort of requesting another activation email, which >also does not arrive. At this point I throw up my hands, close the Erlang >Central tab, and move on. ;-) > >Probably not the experience folks are looking for in an outreach site ... > >/Felix > > >On Fri, Mar 7, 2014 at 11:09 PM, Lo?c Hoguin wrote: > >>I mentioned that last year. Guess that makes two of us now! If more >>people >>start complaining perhaps things will change. :-) >> >> >>On 03/08/2014 07:13 AM, Motiejus Jak?tys wrote: >> >>>On Fri, Mar 7, 2014 at 11:54 AM, Andra Dinu >>> wrote: >>> >>>>Happy to announce that videos from two tracks of the Erlang Factory >>>>Conference are up on ErlangCentral.org (and two more tracks will be >>>>uploaded at the end of the conference) >>>> >>>> >>>>NEXT GENERATION DATABASES & ANALYTICS https://erlangcentral.org/ >>>>streaming/next-generation-databases-analytics/ >>>> >>>>SCALABILITY & MULTICORE >>>>https://erlangcentral.org/streaming/scalability- >>>>multicore/ >>>> >>>>Also check out the chat function enabled by @Kato >>>> >>> >>>Hi, Andra, >>> >>>thanks for uploading the videos that quickly. That is a really wonderful >>>job. >>> >>>One question though regarding accessing the videos. I understand the >>>need to have as many registered users as possible, but is it really so >>>necessary to put a registration wall for videos? I understand it is >>>necessary to make life harder for spammers if I want to post a comment >>>(I can write junk to chat without logging in, so there must be another >>>reason). But for anonymous video watching? That is out of my >>>understanding. >>> >>>I visited the website to have a quick look at what's available. >>>Requires registration. Ok. Email confirmation. OK. Fifteen minutes, >>>yet no email received. Cannot see the videos because it requires >>>registration which requires an email validation and the email >>>validation service does send me the bloody email. >>> >>>Today morning in the keynote Dave Thomas stressed that it is paramount >>>to reduce entry curve for new Erlang users. Is this the message we >>>want to send for one? See some interesting free stuff about Erlang, >>>registration is required, which does not actually work, please come >>>back later? >>> >>>Because of the reasons above I would suggest and appreciate >>>registration requirement waived for read-only activities on >>>erlangcentral. >>> >>>Kind regards, >>>Motiejus Jak?tys >>>_______________________________________________ >>>erlang-questions mailing list >>>erlang-questions@REDACTED >>>http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >>-- >>Lo?c Hoguin >>http://ninenines.eu >> >>_______________________________________________ >>erlang-questions mailing list >>erlang-questions@REDACTED >>http://erlang.org/mailman/listinfo/erlang-questions >> >-------------- next part -------------- >An HTML attachment was scrubbed... >URL: >9/attachment-0001.html> > >------------------------------ From egil@REDACTED Mon Mar 10 14:51:46 2014 From: egil@REDACTED (=?windows-1252?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 10 Mar 2014 14:51:46 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: <531DC372.5080005@erlang.org> Erlang/OTP won't include a Json library if there isn't a specific need for it from another OTP library. And, even if it had, it would be a tough sell. There is currently no such need. Also, the Erlang community already has a couple of implementations. We have no wish to increase our maintenance with something that has already been solved. // Bj?rn-Egil On 2014-03-08 14:01, Charles Irvine wrote: > I recently read that the ?JSON Bridge? that Joe Armstrong describes in his new book won?t be included in Erlang 17.0. This would have been very useful. With Json becoming so prevalent (web services, browsers, Mongodb, etc), I think it is really surpassing XML as a common data interoperability format. It must have been on the table at one point or it wouldn?t have appeared in Joe?s book. Why did it not make it into the release? I think someone indicated that it really didn?t belong in the maps module and I can kind of see that. But why not just put it in a ?json? module? Regards, Chuck > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From eriksoe@REDACTED Mon Mar 10 14:54:36 2014 From: eriksoe@REDACTED (=?ISO-8859-1?Q?Erik_S=F8e_S=F8rensen?=) Date: Mon, 10 Mar 2014 14:54:36 +0100 Subject: [erlang-questions] UTF-8 and escript problem In-Reply-To: <1B671483-459E-4D24-B07B-578874006234@epep.us> References: <73A4434B-F467-4050-8E79-83665630831A@epep.us> <1B671483-459E-4D24-B07B-578874006234@epep.us> Message-ID: Hi - this is very probably related to the problem (and cause) described in this thread: http://erlang.org/pipermail/erlang-bugs/2012-January/002747.html A simpler demo is: $ erl -eval 'io:format("[~ts]\n", [[300]]), timer:sleep(2000), init:stop().' Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] [systemtap] Eshell V5.9.1 (abort with ^G) 1> [?] versus $ erl -noinput -eval 'io:format("[~ts]\n", [[300]]), timer:sleep(2000), init:stop().' [\x{12C}] and the cause is, briefly put, that the code handling output is different in the two cases. The solution, equally briefly, is to set the encoding manually in the escript: $ erl -noinput -eval 'ok = io:setopts([{encoding, unicode}]), io:format("[~ts]\n", [[300]]), timer:sleep(2000), init:stop().' [?] (That is, I've not tested it with escript, but I'd be surprised if it didn't work :-)) /Erik 2014-03-10 6:13 GMT+01:00 John Daily : > I retract my retraction. Setting aside the unworkable Farsi2 variable, > Farsi (expressed in bytes) really should work, but displays > as \x{641}\x{627}\x{631}\x{633}\x{6CC}. Why? > > -John > > On Mar 10, 2014, at 12:34 AM, John Daily wrote: > > And I think I?ve found the solution in an older thread. Still no support > for unicode strings directly embedded in the source. Thanks, sorry for the > noise. > > -John > > On Mar 10, 2014, at 12:24 AM, John Daily wrote: > > I ran into a problem with io:format() when invoked remotely, and with > Scott Fritchie?s assistance I?ve narrowed it down (I think) to escript. > > Here?s my script: > > #!/usr/bin/env escript > %% > %%! -sname foo > > main([]) -> > Other = 'bar@REDACTED', > Farsi = [1601,1575,1585,1587,1740], > Farsi2 = "?????", > spawn(Other, fun() -> io:format("Bytes: ~ts~n", [Farsi]) end), > spawn(Other, fun() -> io:format("Bytes: ~w~n", [Farsi]) end), > spawn(Other, fun() -> io:format("Paste: ~ts~n", [Farsi2]) end), > spawn(Other, fun() -> io:format("Paste: ~w~n", [Farsi2]) end), > timer:sleep(1000). > > When attempting this directly from a different node?s console (spawned to > run on ?bar?), everything displays as expected: > > Bytes: ????? > Bytes: [1601,1575,1585,1587,1740] > Paste: ????? > Paste: [1601,1575,1585,1587,1740] > > When invoked via the above escript, I consistently get the wrong output: > > Bytes: \x{641}\x{627}\x{631}\x{633}\x{6CC} > Bytes: [1601,1575,1585,1587,1740] > Paste: ????? > Paste: [217,129,216,167,216,177,216,179,219,140] > > This is repeatable on R15B01 and R16B03-1, both under OS X Mavericks > installed via kerl. My LANG environment variable is set to en_US.UTF-8, and > all other UTF-8 behavior seems correct. > > Just spun up an older Amazon Linux AMI instance running R15B01. Same > behavior. > > My unicode experience consists of years of banging my head against various > toolchain problems with only a marginal clue as to what?s supposed to > happen, so my ability to troubleshoot this further is limited. > > -John > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasl_erlang@REDACTED Mon Mar 10 15:46:04 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Mon, 10 Mar 2014 07:46:04 -0700 (PDT) Subject: [erlang-questions] [ANN] emdoc-1.0 In-Reply-To: References: <1393525350.60465.YahooMailNeo@web140106.mail.bf1.yahoo.com> Message-ID: <1394462764.61922.YahooMailNeo@web140106.mail.bf1.yahoo.com> That's an excellent idea Gordon. I've added emdoc-lit for the same purpose to emdoc. Best, Thomas On Monday, March 10, 2014 7:36 AM, Gordon Guthrie wrote: I have been playing around with a literate-erlang markdown approach - specifically designed to make good looking GitHub repositories: >https://github.com/hypernumbers/literate-erlang > > > >The project I am using it on is LuvvieScript: >https://github.com/hypernumbers/LuvvieScript > > > >I originally wrote ErlMarkdown: >https://github.com/hypernumbers/erlmarkdown > > > >but for literate erlang abandoned that in favour of just using Git-flavoured markdown. > > >Gordon > > > >On 28 February 2014 02:13, Leo Liu wrote: > >On 2014-02-28 03:02 +0800, Sean Cribbs wrote: >>> There's also edown: https://github.com/esl/edown >> >>Any plan to merge it with edoc? >> >>Leo >> >> >>_______________________________________________ >>erlang-questions mailing list >>erlang-questions@REDACTED >>http://erlang.org/mailman/listinfo/erlang-questions >> > > > >-- >--- >Gordon Guthrie >CEO vixo.com >@gordonguthrie >+44 (0) 7776 251669 (in Bonnie Scotland!) > >vixo is made in Scotland from electrons > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jd@REDACTED Mon Mar 10 15:53:59 2014 From: jd@REDACTED (John Daily) Date: Mon, 10 Mar 2014 10:53:59 -0400 Subject: [erlang-questions] UTF-8 and escript problem In-Reply-To: References: <73A4434B-F467-4050-8E79-83665630831A@epep.us> <1B671483-459E-4D24-B07B-578874006234@epep.us> Message-ID: Thank you, that solved the problem. -John On Mar 10, 2014, at 9:54 AM, Erik S?e S?rensen wrote: > Hi - this is very probably related to the problem (and cause) described in this thread: > http://erlang.org/pipermail/erlang-bugs/2012-January/002747.html > A simpler demo is: > > $ erl -eval 'io:format("[~ts]\n", [[300]]), timer:sleep(2000), init:stop().' > Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8] [async-threads:0] [hipe] [kernel-poll:false] [systemtap] > > Eshell V5.9.1 (abort with ^G) > 1> [?] > > versus > > $ erl -noinput -eval 'io:format("[~ts]\n", [[300]]), timer:sleep(2000), init:stop().' > [\x{12C}] > > and the cause is, briefly put, that the code handling output is different in the two cases. > > The solution, equally briefly, is to set the encoding manually in the escript: > > $ erl -noinput -eval 'ok = io:setopts([{encoding, unicode}]), io:format("[~ts]\n", [[300]]), timer:sleep(2000), init:stop().' > [?] > > > (That is, I've not tested it with escript, but I'd be surprised if it didn't work :-)) > > /Erik > > > 2014-03-10 6:13 GMT+01:00 John Daily : > I retract my retraction. Setting aside the unworkable Farsi2 variable, Farsi (expressed in bytes) really should work, but displays as \x{641}\x{627}\x{631}\x{633}\x{6CC}. Why? > > -John > > On Mar 10, 2014, at 12:34 AM, John Daily wrote: > >> And I think I?ve found the solution in an older thread. Still no support for unicode strings directly embedded in the source. Thanks, sorry for the noise. >> >> -John >> >> On Mar 10, 2014, at 12:24 AM, John Daily wrote: >> >>> I ran into a problem with io:format() when invoked remotely, and with Scott Fritchie?s assistance I?ve narrowed it down (I think) to escript. >>> >>> Here?s my script: >>> >>> #!/usr/bin/env escript >>> %% >>> %%! -sname foo >>> >>> main([]) -> >>> Other = 'bar@REDACTED', >>> Farsi = [1601,1575,1585,1587,1740], >>> Farsi2 = "?????", >>> spawn(Other, fun() -> io:format("Bytes: ~ts~n", [Farsi]) end), >>> spawn(Other, fun() -> io:format("Bytes: ~w~n", [Farsi]) end), >>> spawn(Other, fun() -> io:format("Paste: ~ts~n", [Farsi2]) end), >>> spawn(Other, fun() -> io:format("Paste: ~w~n", [Farsi2]) end), >>> timer:sleep(1000). >>> >>> When attempting this directly from a different node?s console (spawned to run on ?bar?), everything displays as expected: >>> >>> Bytes: ????? >>> Bytes: [1601,1575,1585,1587,1740] >>> Paste: ????? >>> Paste: [1601,1575,1585,1587,1740] >>> >>> When invoked via the above escript, I consistently get the wrong output: >>> >>> Bytes: \x{641}\x{627}\x{631}\x{633}\x{6CC} >>> Bytes: [1601,1575,1585,1587,1740] >>> Paste: ????? >>> Paste: [217,129,216,167,216,177,216,179,219,140] >>> >>> This is repeatable on R15B01 and R16B03-1, both under OS X Mavericks installed via kerl. My LANG environment variable is set to en_US.UTF-8, and all other UTF-8 behavior seems correct. >>> >>> Just spun up an older Amazon Linux AMI instance running R15B01. Same behavior. >>> >>> My unicode experience consists of years of banging my head against various toolchain problems with only a marginal clue as to what?s supposed to happen, so my ability to troubleshoot this further is limited. >>> >>> -John >>> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Mar 10 15:54:52 2014 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 10 Mar 2014 15:54:52 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? Message-ID: Could you elaborate on what the dominant usage of JSON is? -- Lo?c Hoguin http://ninenines.eu -------- Original Message -------- From:Carsten Bormann Sent:Sun, 09 Mar 2014 20:06:27 +0100 To:Anthony Ramine Cc:Erlang MailingList Subject:Re: [erlang-questions] No JSON/MAPS interoperability in 17.0? >On 09 Mar 2014, at 17:05, Anthony Ramine wrote: > >> What about the utter lack of proper specifications around JSON? > >JSON is fully specified in RFC 7159. > >> The fact that you always have to think about where the JSON will be injected? > >Why would you need to think about that? JSON is usually transported using a data-transparent transfer mechanism such as HTTP. >If it isn?t, you may need some help from an application-specific library, but that is irrelevant for the dominant usage of JSON. > >> What about a JSON-encoded string containing "", should that be avoided by Erlang?s builtin parser? What about "]]>"? What about the two characters that are accepted in JSON but not in JavaScript? > >The news here may be that in the present decade JSON rarely is transported inside HTML documents or converted into JavaScript for parsing. So all this is entirely irrelevant. > >> Just because other languages include such a thing doesn?t mean Erlang should too. > >Of course that would be a weak reason. But it's a straw man. >The reason for supporting JSON at the standard library level is that JSON is the most widely used format to interchange data. > >Not having it is fine for a language that doesn?t care about interchanging data. > >Gr??e, Carsten > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Mon Mar 10 15:57:03 2014 From: essen@REDACTED (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) Date: Mon, 10 Mar 2014 15:57:03 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? Message-ID: <1gl5wq7xhmgl5cd8a9vxuljp.1394463423517@email.android.com> By economy I hope you don't mean financial data, as it is utterly terrible at it. It is terrible at most of everything important really. People only use it because everyone uses it. -- Lo?c Hoguin http://ninenines.eu -------- Original Message -------- From:Carsten Bormann Sent:Sun, 09 Mar 2014 22:15:24 +0100 To:Anthony Ramine Cc:Erlang MailingList Subject:Re: [erlang-questions] No JSON/MAPS interoperability in 17.0? >> I said around. There is absolutely no tooling around JSON which is properly specified and widely used, that was to reply to the namedropping of ASN.1 and XML. > >Yeah. JSON is ready to eat. No ASN.1 compilers or XML schema tools needed. > >> Dominant? Do you have statistics for this? My own experience is that we inject JSON in webpages a lot. > >Indeed, I had the impression that the comments would relate to such a background. > >> Stack Overflow seems to agree. > >Stack Overflow certainly agrees that this usage is problematic and therefore generates a lot of questions about how to remove the bullet from the foot, > >> See above. PHP has some options to counter these problems, Rails has escape_html_entities_in_json. > >PHP has a lot of things that are not needed in Erlang? >The Rails people have since learned that generating JavaScript with data values inserted is not such a great idea (the feature is not really about JSON despite its name). > >>>> Just because other languages include such a thing doesn?t mean Erlang should too. >>> >>> Of course that would be a weak reason. But it's a straw man. >>> The reason for supporting JSON at the standard library level is that JSON is the most widely used format to interchange data. >> >> Most widely used? In the web probably. In other fields, I wouldn?t bet on this. > >It?s not replacing HDF5. >But it is quickly getting rid of CSV, XML, and a ton of ad-hoc syntaxes that together with a bit of spit and string hold together the Economy. > >> Given that there is a myriad of third-party JSON libraries, what?s the problem? > >That *is* the problem. >When I need to print a floating-point number, I don?t start looking for and comparing third-party libraries. >(Printing floating-point is a problem that is about ten times as difficult as the problem of printing JSON is when you already can print floating point numbers. It also has more parameters than a JSON printer needs.) > >> And a standard library which sets in stone such a supposedly-important feature the moment a convenient datatype is available isn?t worth anything, in my opinion. > >Well, it?s worth to design it properly then. > > >The reason I?m reacting to this discussion is that it seems to be dominated by people who have never used JSON for what it is good at. >That is not a character flaw, but it may skew the discussion in the wrong direction. >(Replace ?JSON? with ?strings decimally representing floating point numbers? in the previous messages in this thread to find out how ridiculous some of them sound to me.) > >Gr??e, Carsten > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Mon Mar 10 16:01:20 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 10 Mar 2014 08:01:20 -0700 Subject: [erlang-questions] default timeout values for a library (epgsql) In-Reply-To: References: Message-ID: <20140310150119.GD3876@ferdair.local> Hi David, On top of what Jesper said, the timeouts issue have a big, big impact on how your distributed system behaves. As pointed out by Kyle Kingsbury in "Call me maybe: Postgres" [1], you have to consider the client as part of the distributed system, and bound by its inherent limitations. Basically, on a network error, partition, or effectively a timeout triggered by the TCP stack, the server, or the client itself, the client is left with an ambiguous result: did the call fail (is the server even alive?), or did it succeed, but only after I gave up? It is in fact impossible to make any assertion on the topic without having further information down the line. This is really the core of a large issue with consistency. If the client assumes, by default, that the call failed and decides to retry it, the transaction being re-applied may 'corrupt' the data in the DB (say, ending up doing a '+2' on a money counter instead of a '+1'). If you assume it succeeded, you're possibly going to be missing part of the information your client submitted to the database. How can this be resolved? At least two broad strategies exist: 1) read your writes and make sure the effect you intended to have is noticeable. Sadly this isn't always possible (say multiple people are incrementing the money counter) 2) make your requests idempotent. In general, this means having a transaction id that you can access and associate with your request, forcing it to be present in the system only once. In many ways, this is something you do by having a table or log of such entries, but a quick circumvention can be done by having the status of any transaction ID for a given amount of time be pollable on the server for its success, for example. I'm simplifying 2) a bit, and I realize I'm getting entirely away from the idea of how long should a timeout be, but that is exactly why this is a hard problem. No matter how long the timeout is, this will happen anyway. The solution is, in my opinion, to give tools to know what kind of timeout happened: - Connection timeout (when you try to open the socket) - Idle connection timing out (not having heard back from the server at a connection level) - Request timeout - Connection error (could be due to timing out on either end too!) - Server crash (which may only be visible as a timeout) It is very well possible that some of these timeouts will overlap, or be nearly impossible to tell apart without tracing the TCP stack or doing some deeper investigation after the fact. The important part, here, is that issues related to connectivity and timeouts (often indistinguishable by their symptoms) should be easy to tell apart from obviously failed transactions so people don't assume that timeout = failed transaction. An infinite timeout, in CAP terms, is a cop-out. It basically brushes the issue under the rug. To quote Pat Helland, if you're going to make the default timeout infinity, I'd instead recommend setting it to 30 years. It's going to be nearly as long in practice, but will eventually give up (that's guaranteed). It's not more ridiculous of an option, is it? If the timeout isn't set explicitly, it'll be set implicitly by whatever the TCP stack is doing and the rate at which heartbeats (or equivalent data) is coming over the wire. There's always a timeout (or something that has timeout effects) looming in your system. Sometimes you just don't know what it is before it happens. For the time being, my suggestion is therefore: 30 years. If that sounds ridiculous, maybe 15 seconds to one minute is more reasonable. Or maybe something in between that and 30 years. Regards, Fred. [1]: http://aphyr.com/posts/282-call-me-maybe-postgres From jose.valim@REDACTED Mon Mar 10 16:07:01 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Mon, 10 Mar 2014 16:07:01 +0100 Subject: [erlang-questions] Videos from Erlang Factory SF Bay 2014 up on ErlangCentral.org In-Reply-To: References: Message-ID: I don't have an account and I can access all videos here: https://erlangcentral.org/category/videos/ The link to this page can be found in the home page by clicking the "Videos" category. Maybe I am missing something? *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Mon, Mar 10, 2014 at 2:17 PM, Phillips, Christopher < Christopher.Phillips@REDACTED> wrote: > > This does not address the base issue that it makes it less approachable > for new people, but you can find them on youtube under ErlangSolution's > account; > https://www.youtube.com/user/ErlangSolutions/videos?view=0&shelf_id=1&sort= > dd > > On 3/8/14, 6:00 AM, "erlang-questions-request@REDACTED" > wrote: > > > > >I had the same problem - I cannot read or watch content on Erlang Central > >website without an account so I actually set up an account in order to do > >so (very rare occurrence). Then I do not receive the activation email > >which > >it seems you must have to actually use an account. So I try to log in and > >fail, then go to the effort of requesting another activation email, which > >also does not arrive. At this point I throw up my hands, close the Erlang > >Central tab, and move on. ;-) > > > >Probably not the experience folks are looking for in an outreach site ... > > > >/Felix > > > > > >On Fri, Mar 7, 2014 at 11:09 PM, Lo?c Hoguin wrote: > > > >>I mentioned that last year. Guess that makes two of us now! If more > >>people > >>start complaining perhaps things will change. :-) > >> > >> > >>On 03/08/2014 07:13 AM, Motiejus Jak?tys wrote: > >> > >>>On Fri, Mar 7, 2014 at 11:54 AM, Andra Dinu > >>> wrote: > >>> > >>>>Happy to announce that videos from two tracks of the Erlang Factory > >>>>Conference are up on ErlangCentral.org (and two more tracks will be > >>>>uploaded at the end of the conference) > >>>> > >>>> > >>>>NEXT GENERATION DATABASES & ANALYTICS https://erlangcentral.org/ > >>>>streaming/next-generation-databases-analytics/ > >>>> > >>>>SCALABILITY & MULTICORE > >>>>https://erlangcentral.org/streaming/scalability- > >>>>multicore/ > >>>> > >>>>Also check out the chat function enabled by @Kato > >>>> > >>> > >>>Hi, Andra, > >>> > >>>thanks for uploading the videos that quickly. That is a really wonderful > >>>job. > >>> > >>>One question though regarding accessing the videos. I understand the > >>>need to have as many registered users as possible, but is it really so > >>>necessary to put a registration wall for videos? I understand it is > >>>necessary to make life harder for spammers if I want to post a comment > >>>(I can write junk to chat without logging in, so there must be another > >>>reason). But for anonymous video watching? That is out of my > >>>understanding. > >>> > >>>I visited the website to have a quick look at what's available. > >>>Requires registration. Ok. Email confirmation. OK. Fifteen minutes, > >>>yet no email received. Cannot see the videos because it requires > >>>registration which requires an email validation and the email > >>>validation service does send me the bloody email. > >>> > >>>Today morning in the keynote Dave Thomas stressed that it is paramount > >>>to reduce entry curve for new Erlang users. Is this the message we > >>>want to send for one? See some interesting free stuff about Erlang, > >>>registration is required, which does not actually work, please come > >>>back later? > >>> > >>>Because of the reasons above I would suggest and appreciate > >>>registration requirement waived for read-only activities on > >>>erlangcentral. > >>> > >>>Kind regards, > >>>Motiejus Jak?tys > >>>_______________________________________________ > >>>erlang-questions mailing list > >>>erlang-questions@REDACTED > >>>http://erlang.org/mailman/listinfo/erlang-questions > >>> > >>> > >>-- > >>Lo?c Hoguin > >>http://ninenines.eu > >> > >>_______________________________________________ > >>erlang-questions mailing list > >>erlang-questions@REDACTED > >>http://erlang.org/mailman/listinfo/erlang-questions > >> > >-------------- next part -------------- > >An HTML attachment was scrubbed... > >URL: > >< > http://erlang.org/pipermail/erlang-questions/attachments/20140307/908c0cc > >9/attachment-0001.html> > > > >------------------------------ > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fly@REDACTED Mon Mar 10 16:34:51 2014 From: fly@REDACTED (Fred Youhanaie) Date: Mon, 10 Mar 2014 15:34:51 +0000 Subject: [erlang-questions] Videos from Erlang Factory SF Bay 2014 up on ErlangCentral.org In-Reply-To: References: Message-ID: <531DDB9B.8050102@anydata.co.uk> On 10/03/14 15:07, Jos? Valim wrote: > I don't have an account and I can access all videos here: > > https://erlangcentral.org/category/videos/ > > The link to this page can be found in the home page by clicking the > "Videos" category. > > Maybe I am missing something? The original links provided for the videos are those found under the "EFSF 2014" drop down menu, which still requires logging in! I set up an account a year or so ago, and I remember a longish delay before I could login. More importantly, I have watched two of the videos and they have been produced extremely well - Thank you ESL :-) Cheers f. From tomasz.szkaradek@REDACTED Mon Mar 10 15:02:29 2014 From: tomasz.szkaradek@REDACTED (Tomasz Szkaradek) Date: Mon, 10 Mar 2014 15:02:29 +0100 Subject: [erlang-questions] Videos from Erlang Factory SF Bay 2014 up on ErlangCentral.org In-Reply-To: References: Message-ID: <531DC5F5.3090302@erlang-solutions.com> Hi, thanks for reporting the bug. The issue has been fixed and all the confirmation emails have been sent to the new registrants. Best Regards W dniu 10/03/14 14:17, Phillips, Christopher pisze: > This does not address the base issue that it makes it less approachable > for new people, but you can find them on youtube under ErlangSolution's > account; > https://www.youtube.com/user/ErlangSolutions/videos?view=0&shelf_id=1&sort= > dd > > On 3/8/14, 6:00 AM, "erlang-questions-request@REDACTED" > wrote: > >> I had the same problem - I cannot read or watch content on Erlang Central >> website without an account so I actually set up an account in order to do >> so (very rare occurrence). Then I do not receive the activation email >> which >> it seems you must have to actually use an account. So I try to log in and >> fail, then go to the effort of requesting another activation email, which >> also does not arrive. At this point I throw up my hands, close the Erlang >> Central tab, and move on. ;-) >> >> Probably not the experience folks are looking for in an outreach site ... >> >> /Felix >> >> >> On Fri, Mar 7, 2014 at 11:09 PM, Lo?c Hoguin wrote: >> >>> I mentioned that last year. Guess that makes two of us now! If more >>> people >>> start complaining perhaps things will change. :-) >>> >>> >>> On 03/08/2014 07:13 AM, Motiejus Jak?tys wrote: >>> >>>> On Fri, Mar 7, 2014 at 11:54 AM, Andra Dinu >>>> wrote: >>>> >>>>> Happy to announce that videos from two tracks of the Erlang Factory >>>>> Conference are up on ErlangCentral.org (and two more tracks will be >>>>> uploaded at the end of the conference) >>>>> >>>>> >>>>> NEXT GENERATION DATABASES & ANALYTICS https://erlangcentral.org/ >>>>> streaming/next-generation-databases-analytics/ >>>>> >>>>> SCALABILITY & MULTICORE >>>>> https://erlangcentral.org/streaming/scalability- >>>>> multicore/ >>>>> >>>>> Also check out the chat function enabled by @Kato >>>>> >>>> Hi, Andra, >>>> >>>> thanks for uploading the videos that quickly. That is a really wonderful >>>> job. >>>> >>>> One question though regarding accessing the videos. I understand the >>>> need to have as many registered users as possible, but is it really so >>>> necessary to put a registration wall for videos? I understand it is >>>> necessary to make life harder for spammers if I want to post a comment >>>> (I can write junk to chat without logging in, so there must be another >>>> reason). But for anonymous video watching? That is out of my >>>> understanding. >>>> >>>> I visited the website to have a quick look at what's available. >>>> Requires registration. Ok. Email confirmation. OK. Fifteen minutes, >>>> yet no email received. Cannot see the videos because it requires >>>> registration which requires an email validation and the email >>>> validation service does send me the bloody email. >>>> >>>> Today morning in the keynote Dave Thomas stressed that it is paramount >>>> to reduce entry curve for new Erlang users. Is this the message we >>>> want to send for one? See some interesting free stuff about Erlang, >>>> registration is required, which does not actually work, please come >>>> back later? >>>> >>>> Because of the reasons above I would suggest and appreciate >>>> registration requirement waived for read-only activities on >>>> erlangcentral. >>>> >>>> Kind regards, >>>> Motiejus Jak?tys >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> -- >>> Lo?c Hoguin >>> http://ninenines.eu >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> > 9/attachment-0001.html> >> >> ------------------------------ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dmkolesnikov@REDACTED Mon Mar 10 20:37:40 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Mon, 10 Mar 2014 21:37:40 +0200 Subject: [erlang-questions] default timeout values for a library (epgsql) In-Reply-To: References: Message-ID: Hello, I'd like to add couple of practical notes on top of essential statements made by Jesper and Fred. The meaning of timeouts should differ depending on application use-cases and operation, e.g. reads are constrained by latency of data retrieval, writes by data consistency; OLTP queries should fail faster but OLAP can take longer time. I am running a big MySQL data set with Erlang application and timeouts was major pain... The root cause of timeouts in 99.99% is not network partition or server crash. It is slow disk, large data set and un-optimal queries. I've made number of tweaks to the query interface to handle timeouts: * both read/write methods of API provides timeout interface, any default or infinite timeouts would not work for API. Like it was stated in previous posts, write timeouts are most challenging one. Only application code can resolver them properly. * API provides synchronous and asynchronous/non-blocking flavor to execute read/write requests. Sync calls are normal gen_server calls but async are traceable casts with mandatory feed-backs. Async calls allows to made client progress while waiting results of slow query. These tweaks allows application to adapt to one of there desired use-cases... Best Regards, Dmitry >-|-|-(*> > On 10 Mar 2014, at 12:30, David Welton wrote: > > Hi, > > We've been having something of a debate on the epgsql mailing list > about timeouts for database queries: > > https://groups.google.com/forum/#!topic/epgsql/jmwSCybEN3E > > I thought that it'd be interesting to hear how other people handle > things like this. > > One thing that looks like we need is the ability to specify a timeout, > but, beyond that, I just thought I'd ask a wider group of people what > their thoughts are on timeouts in library code like this. > > Thank you, > -- > David N. Welton > > http://www.welton.it/davidw/ > > http://www.dedasys.com/ > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From txrev319@REDACTED Mon Mar 10 22:32:16 2014 From: txrev319@REDACTED (t x) Date: Mon, 10 Mar 2014 14:32:16 -0700 Subject: [erlang-questions] otp / behavior / cowboy_websocket_handler Message-ID: Hi, I'm trying to understand what Erlang is doing with the following piece of code: https://github.com/extend/cowboy/blob/master/examples/websocket/src/ws_handler.erl Please note: * this code is running fine (I don't need help trouble shooting the code) * the behavior I get matches my intuition of what is happening My actual problem is _why_ does everything happen the way it is. ### Behavior I get: Upon opening a websocket and connecting, I get back: Hello! [ 1 second delay ] How' you doing'? [ 1 second delay ] How' you doing'? ... This behavior is expected because * websocket_init is called, which causes a "Hello!" message to be sent to self (handled by websocket_info) * every time websocket_info is called, it: * registers 1-second call back for "How'you doing'?" * and sends out the msg it received ## Question: What is happening behind the scenes with: -behavior(cowboy_websocket_handler) which causes all this to happen? ## What I've tried: So I googled and got: https://github.com/extend/cowboy/blob/master/manual/cowboy_websocket_handler.md And this is a great human-level understanding. However, I want to see the code that makes it happen. Then, I look at: https://github.com/extend/cowboy/blob/master/src/cowboy_websocket_handler.erl And now, I am confused. What I see is a bunch of "-callback" lines. What I expect to see is something like: spawn(func, ...) func ( ... ) -> some loop or some sort for handling messages In particular, my confusion is: it's clear that behavior(cowboy_websocket_handler) causes some process to be spawned somewhere. Where is this happening? Thanks! From moxford@REDACTED Mon Mar 10 23:31:15 2014 From: moxford@REDACTED (Mike Oxford) Date: Mon, 10 Mar 2014 15:31:15 -0700 Subject: [erlang-questions] otp / behavior / cowboy_websocket_handler In-Reply-To: References: Message-ID: Erlang behaviours are, I believe and for lack of a better term, interface definitions. It says what is required to be implemented to be a valid behaviour. Once it's compiled and verified I do not believe that it's ever used again. It does not actually "do" anything since it's just a specification. It looks like ws_handler:websocket_init/3 starts a 1 second timer. When that timer fires then you're seeing the 1 second handler, which is ws_handler. The "loop" you're expecting to see is in websocket_app:start/2 where you register the callbacks (such as ws_handler) for cowboy:start_http/3 So cowboy:start/3 takes in the ws_handler definition, inits it (and that init starts the 1s timer.) Every time it fires (eg, every 1 seconds) the cowboy system will hit the ws_handler callback (which, since it's a cowboy_websocket_handler behaviour, is known to have a websocket_handle/3 function.) HTH. -mox On Mon, Mar 10, 2014 at 2:32 PM, t x wrote: > Hi, > > I'm trying to understand what Erlang is doing with the following > piece of code: > > > https://github.com/extend/cowboy/blob/master/examples/websocket/src/ws_handler.erl > > Please note: > > * this code is running fine (I don't need help trouble shooting the code) > > * the behavior I get matches my intuition of what is happening > > My actual problem is _why_ does everything happen the way it is. > > > ### Behavior I get: > > Upon opening a websocket and connecting, I get back: > > Hello! > [ 1 second delay ] > How' you doing'? > [ 1 second delay ] > How' you doing'? > ... > > > This behavior is expected because > > * websocket_init is called, which causes a "Hello!" message to be > sent to self (handled by websocket_info) > > * every time websocket_info is called, it: > * registers 1-second call back for "How'you doing'?" > * and sends out the msg it received > > > ## Question: What is happening behind the scenes with: > > -behavior(cowboy_websocket_handler) which causes all this to happen? > > > > ## What I've tried: > > So I googled and got: > > > https://github.com/extend/cowboy/blob/master/manual/cowboy_websocket_handler.md > > And this is a great human-level understanding. > > > However, I want to see the code that makes it happen. > > > Then, I look at: > > > https://github.com/extend/cowboy/blob/master/src/cowboy_websocket_handler.erl > > > > And now, I am confused. > > > What I see is a bunch of "-callback" lines. > > > > What I expect to see is something like: > > spawn(func, ...) > > func ( ... ) -> > some loop or some sort for handling messages > > > In particular, my confusion is: it's clear that > behavior(cowboy_websocket_handler) causes some process to be spawned > somewhere. Where is this happening? > > > > Thanks! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Mon Mar 10 23:37:56 2014 From: moxford@REDACTED (Mike Oxford) Date: Mon, 10 Mar 2014 15:37:56 -0700 Subject: [erlang-questions] otp / behavior / cowboy_websocket_handler In-Reply-To: References: Message-ID: The -callback is a dialyzer (testing tool) type spec. It's just an annotation so that some behaviour metadata gets added for the analysis. The code would run exactly the same if you took out the -callback from each line (though Dialyzer might then complain!) http://learnyousomeerlang.com/dialyzer and search for "-callback" On Mon, Mar 10, 2014 at 3:31 PM, Mike Oxford wrote: > Erlang behaviours are, I believe and for lack of a better term, interface > definitions. It says what is required to be implemented to be a valid > behaviour. Once it's compiled and verified I do not believe that it's ever > used again. It does not actually "do" anything since it's just a > specification. > > It looks like ws_handler:websocket_init/3 starts a 1 second timer. > When that timer fires then you're seeing the 1 second handler, which is > ws_handler. > The "loop" you're expecting to see is in websocket_app:start/2 where you > register the callbacks (such as ws_handler) for cowboy:start_http/3 > > So cowboy:start/3 takes in the ws_handler definition, inits it (and that > init starts the 1s timer.) Every time it fires (eg, every 1 seconds) the > cowboy system will hit the ws_handler callback (which, since it's > a cowboy_websocket_handler behaviour, is known to have a websocket_handle/3 > function.) > > HTH. > > -mox > > > > > > On Mon, Mar 10, 2014 at 2:32 PM, t x wrote: > >> Hi, >> >> I'm trying to understand what Erlang is doing with the following >> piece of code: >> >> >> https://github.com/extend/cowboy/blob/master/examples/websocket/src/ws_handler.erl >> >> Please note: >> >> * this code is running fine (I don't need help trouble shooting the >> code) >> >> * the behavior I get matches my intuition of what is happening >> >> My actual problem is _why_ does everything happen the way it is. >> >> >> ### Behavior I get: >> >> Upon opening a websocket and connecting, I get back: >> >> Hello! >> [ 1 second delay ] >> How' you doing'? >> [ 1 second delay ] >> How' you doing'? >> ... >> >> >> This behavior is expected because >> >> * websocket_init is called, which causes a "Hello!" message to be >> sent to self (handled by websocket_info) >> >> * every time websocket_info is called, it: >> * registers 1-second call back for "How'you doing'?" >> * and sends out the msg it received >> >> >> ## Question: What is happening behind the scenes with: >> >> -behavior(cowboy_websocket_handler) which causes all this to happen? >> >> >> >> ## What I've tried: >> >> So I googled and got: >> >> >> https://github.com/extend/cowboy/blob/master/manual/cowboy_websocket_handler.md >> >> And this is a great human-level understanding. >> >> >> However, I want to see the code that makes it happen. >> >> >> Then, I look at: >> >> >> https://github.com/extend/cowboy/blob/master/src/cowboy_websocket_handler.erl >> >> >> >> And now, I am confused. >> >> >> What I see is a bunch of "-callback" lines. >> >> >> >> What I expect to see is something like: >> >> spawn(func, ...) >> >> func ( ... ) -> >> some loop or some sort for handling messages >> >> >> In particular, my confusion is: it's clear that >> behavior(cowboy_websocket_handler) causes some process to be spawned >> somewhere. Where is this happening? >> >> >> >> Thanks! >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail@REDACTED Tue Mar 11 07:09:48 2014 From: mail@REDACTED (Alexander Alexeev) Date: Tue, 11 Mar 2014 10:09:48 +0400 Subject: [erlang-questions] [ANN] erl-min-prj -- Easy way to create a .deb package + minimal project template Message-ID: <20140311100948.7e21aa69@portege> Hello. In case you have some problems with packing your Erlang project in .deb package you could be interested in taking a look on this repository: https://github.com/afiskon/erl-min-prj First of all, it's an example of minimal Erlang project. It comes with Makefile which packs a project in .deb package (using FPM). A script for creating a new project using this one as a template is also provided. It's very simple to use: # (create/checkout a new git repository) cd mynewservice wget https://raw.github.com/afiskon/erl-min-prj/master/scripts/new-erl-srv chmod u+x new-erl-srv ./new-erl-srv mynewservice "My Service Description" http://homepage.example.com/ rm new-erl-srv git add . git commit -am 'Initial Commit' git push origin HEAD git tag 0.1.0 # tags are used as deb package version git push origin 0.1.0 make run # run service, for debug purposes make deb # create deb package I hope you will find all this stuff useful. Feel free for make bug reports (I'm pretty sure there are none but who knows) and pull requests. In particular I don't work with rpm-based Linux distros at all. So it would be nice if someone who does will add support of building rpm packages :) -- Best regards, Alexander Alexeev http://eax.me/ From essen@REDACTED Tue Mar 11 08:37:25 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 11 Mar 2014 08:37:25 +0100 Subject: [erlang-questions] otp / behavior / cowboy_websocket_handler In-Reply-To: References: Message-ID: <531EBD35.8050507@ninenines.eu> The actual code is in cowboy_websocket. (Hence init/3 returning it wants to upgrade to cowboy_websocket). The guide now has a proper chapter for Websocket (on github) that explains that part of the code. On 03/10/2014 10:32 PM, t x wrote: > Hi, > > I'm trying to understand what Erlang is doing with the following > piece of code: > > https://github.com/extend/cowboy/blob/master/examples/websocket/src/ws_handler.erl > > Please note: > > * this code is running fine (I don't need help trouble shooting the code) > > * the behavior I get matches my intuition of what is happening > > My actual problem is _why_ does everything happen the way it is. > > > ### Behavior I get: > > Upon opening a websocket and connecting, I get back: > > Hello! > [ 1 second delay ] > How' you doing'? > [ 1 second delay ] > How' you doing'? > ... > > > This behavior is expected because > > * websocket_init is called, which causes a "Hello!" message to be > sent to self (handled by websocket_info) > > * every time websocket_info is called, it: > * registers 1-second call back for "How'you doing'?" > * and sends out the msg it received > > > ## Question: What is happening behind the scenes with: > > -behavior(cowboy_websocket_handler) which causes all this to happen? > > > > ## What I've tried: > > So I googled and got: > > https://github.com/extend/cowboy/blob/master/manual/cowboy_websocket_handler.md > > And this is a great human-level understanding. > > > However, I want to see the code that makes it happen. > > > Then, I look at: > > https://github.com/extend/cowboy/blob/master/src/cowboy_websocket_handler.erl > > > > And now, I am confused. > > > What I see is a bunch of "-callback" lines. > > > > What I expect to see is something like: > > spawn(func, ...) > > func ( ... ) -> > some loop or some sort for handling messages > > > In particular, my confusion is: it's clear that > behavior(cowboy_websocket_handler) causes some process to be spawned > somewhere. Where is this happening? > > > > Thanks! > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From txrev319@REDACTED Tue Mar 11 09:14:55 2014 From: txrev319@REDACTED (t x) Date: Tue, 11 Mar 2014 01:14:55 -0700 Subject: [erlang-questions] otp / behavior / cowboy_websocket_handler In-Reply-To: <531EBD35.8050507@ninenines.eu> References: <531EBD35.8050507@ninenines.eu> Message-ID: So I'm still not seeing the "loop" ## https://github.com/extend/cowboy/blob/master/examples/websocket/src/ws_handler.erl This file defines websocket_*, thus fulfilling the behavior. However, it does not spawn the process itself. ## https://github.com/extend/cowboy/blob/master/examples/websocket/src/websocket_app.erl#L16-L20 I believe this spawns the process, via calling cowboy:start_http to do the actual work. ## https://github.com/extend/cowboy/blob/master/src/cowboy.erl#L43-L46 This is cowboy:start_http, which appears to just pass the work off to ranch:start_listener. ## https://github.com/extend/ranch/blob/master/src/ranch.erl#L39-L68 This is ranch:start_listener. I have no idea what's going on here. Can someone pin point / explain to me where in ranch this process is being spawn? Thanks! PS: I've looked at: http://ninenines.eu/docs/en/cowboy/HEAD/guide/ws_handlers/ http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_websocket/ http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_websocket_handler/ However, I want more details / see the mechanics of how it works / get familiar with tracing through Erlang code. On Tue, Mar 11, 2014 at 12:37 AM, Lo?c Hoguin wrote: > The actual code is in cowboy_websocket. (Hence init/3 returning it wants to > upgrade to cowboy_websocket). > > The guide now has a proper chapter for Websocket (on github) that explains > that part of the code. > > > On 03/10/2014 10:32 PM, t x wrote: >> >> Hi, >> >> I'm trying to understand what Erlang is doing with the following >> piece of code: >> >> >> https://github.com/extend/cowboy/blob/master/examples/websocket/src/ws_handler.erl >> >> Please note: >> >> * this code is running fine (I don't need help trouble shooting the >> code) >> >> * the behavior I get matches my intuition of what is happening >> >> My actual problem is _why_ does everything happen the way it is. >> >> >> ### Behavior I get: >> >> Upon opening a websocket and connecting, I get back: >> >> Hello! >> [ 1 second delay ] >> How' you doing'? >> [ 1 second delay ] >> How' you doing'? >> ... >> >> >> This behavior is expected because >> >> * websocket_init is called, which causes a "Hello!" message to be >> sent to self (handled by websocket_info) >> >> * every time websocket_info is called, it: >> * registers 1-second call back for "How'you doing'?" >> * and sends out the msg it received >> >> >> ## Question: What is happening behind the scenes with: >> >> -behavior(cowboy_websocket_handler) which causes all this to happen? >> >> >> >> ## What I've tried: >> >> So I googled and got: >> >> >> https://github.com/extend/cowboy/blob/master/manual/cowboy_websocket_handler.md >> >> And this is a great human-level understanding. >> >> >> However, I want to see the code that makes it happen. >> >> >> Then, I look at: >> >> >> https://github.com/extend/cowboy/blob/master/src/cowboy_websocket_handler.erl >> >> >> >> And now, I am confused. >> >> >> What I see is a bunch of "-callback" lines. >> >> >> >> What I expect to see is something like: >> >> spawn(func, ...) >> >> func ( ... ) -> >> some loop or some sort for handling messages >> >> >> In particular, my confusion is: it's clear that >> behavior(cowboy_websocket_handler) causes some process to be spawned >> somewhere. Where is this happening? >> >> >> >> Thanks! >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > -- > Lo?c Hoguin > http://ninenines.eu From essen@REDACTED Tue Mar 11 10:03:37 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 11 Mar 2014 10:03:37 +0100 Subject: [erlang-questions] otp / behavior / cowboy_websocket_handler In-Reply-To: References: <531EBD35.8050507@ninenines.eu> Message-ID: <531ED169.1030305@ninenines.eu> cowboy_protocol On 03/11/2014 09:14 AM, t x wrote: > So I'm still not seeing the "loop" > > > ## https://github.com/extend/cowboy/blob/master/examples/websocket/src/ws_handler.erl > > This file defines websocket_*, thus fulfilling the behavior. > However, it does not spawn the process itself. > > > ## https://github.com/extend/cowboy/blob/master/examples/websocket/src/websocket_app.erl#L16-L20 > > I believe this spawns the process, via calling cowboy:start_http to > do the actual work. > > > ## https://github.com/extend/cowboy/blob/master/src/cowboy.erl#L43-L46 > > This is cowboy:start_http, which appears to just pass the work off > to ranch:start_listener. > > > ## https://github.com/extend/ranch/blob/master/src/ranch.erl#L39-L68 > > This is ranch:start_listener. I have no idea what's going on here. > > > Can someone pin point / explain to me where in ranch this process is > being spawn? > > > Thanks! > > > PS: I've looked at: > > http://ninenines.eu/docs/en/cowboy/HEAD/guide/ws_handlers/ > http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_websocket/ > http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_websocket_handler/ > > However, I want more details / see the mechanics of how it works / get > familiar with tracing through Erlang code. > > On Tue, Mar 11, 2014 at 12:37 AM, Lo?c Hoguin wrote: >> The actual code is in cowboy_websocket. (Hence init/3 returning it wants to >> upgrade to cowboy_websocket). >> >> The guide now has a proper chapter for Websocket (on github) that explains >> that part of the code. >> >> >> On 03/10/2014 10:32 PM, t x wrote: >>> >>> Hi, >>> >>> I'm trying to understand what Erlang is doing with the following >>> piece of code: >>> >>> >>> https://github.com/extend/cowboy/blob/master/examples/websocket/src/ws_handler.erl >>> >>> Please note: >>> >>> * this code is running fine (I don't need help trouble shooting the >>> code) >>> >>> * the behavior I get matches my intuition of what is happening >>> >>> My actual problem is _why_ does everything happen the way it is. >>> >>> >>> ### Behavior I get: >>> >>> Upon opening a websocket and connecting, I get back: >>> >>> Hello! >>> [ 1 second delay ] >>> How' you doing'? >>> [ 1 second delay ] >>> How' you doing'? >>> ... >>> >>> >>> This behavior is expected because >>> >>> * websocket_init is called, which causes a "Hello!" message to be >>> sent to self (handled by websocket_info) >>> >>> * every time websocket_info is called, it: >>> * registers 1-second call back for "How'you doing'?" >>> * and sends out the msg it received >>> >>> >>> ## Question: What is happening behind the scenes with: >>> >>> -behavior(cowboy_websocket_handler) which causes all this to happen? >>> >>> >>> >>> ## What I've tried: >>> >>> So I googled and got: >>> >>> >>> https://github.com/extend/cowboy/blob/master/manual/cowboy_websocket_handler.md >>> >>> And this is a great human-level understanding. >>> >>> >>> However, I want to see the code that makes it happen. >>> >>> >>> Then, I look at: >>> >>> >>> https://github.com/extend/cowboy/blob/master/src/cowboy_websocket_handler.erl >>> >>> >>> >>> And now, I am confused. >>> >>> >>> What I see is a bunch of "-callback" lines. >>> >>> >>> >>> What I expect to see is something like: >>> >>> spawn(func, ...) >>> >>> func ( ... ) -> >>> some loop or some sort for handling messages >>> >>> >>> In particular, my confusion is: it's clear that >>> behavior(cowboy_websocket_handler) causes some process to be spawned >>> somewhere. Where is this happening? >>> >>> >>> >>> Thanks! >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >> >> -- >> Lo?c Hoguin >> http://ninenines.eu -- Lo?c Hoguin http://ninenines.eu From alexander.poulikakos@REDACTED Tue Mar 11 11:15:49 2014 From: alexander.poulikakos@REDACTED (Alexander Poulikakos) Date: Tue, 11 Mar 2014 10:15:49 +0000 Subject: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? Message-ID: <13201259F072B44F99FC47096AAA78B12899206A@ESESSMB203.ericsson.se> Hi erlang users I use the ct_netconfc client, from within Common Test. I'm communicating with a System Under Test (SUT), with the NETCONF protocol and I want to send a "delete" operation to delete some object. Example of my code: Config = {'ElementA',[], [{elementAId,[],["1"]}, {elementB,[], [{elementB,[],["1"]}, {elementC,[{'xc:operation',"delete"}], [{elementCId,[],["6"]}]}]}]}, {ok, Client}=ct_netconfc:open([{ssh, "some-ip-address"}, {port, some-port}, {user, "some-username"},{password,"some-password"}]), ct_netconfc:edit_config(Client, running, Config), Which gives me the following error message: {error,[{'error-type',[{xmlns,"urn:ietf:params:xml:ns:netconf:base:1.0"}], ["protocol"]}, {'error-tag',[{xmlns,"urn:ietf:params:xml:ns:netconf:base:1.0"}], ["operation-failed"]}, {'error-severity',[{xmlns,"urn:ietf:params:xml:ns:netconf:base:1.0"}], ["error"]}, {'error-message',[{xmlns,"urn:ietf:params:xml:ns:netconf:base:1.0"}, {'xml:lang',"en"}], ["Malformed XML!!!"]}]} And the actual XML document (after processed by ct_netconfc) sent to my SUT looks as follow: 1 1 6 According to examples in RFC6241 [ http://tools.ietf.org/html/rfc6241 June 2011 page 41] the config element contains a namespace attribute xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0". So if I add it to the xml document (as below) and manually send it to my SUT, then it works. 1 1 6 So question is, how do I add the namespace attribute using ct_netconfc:edit_config/3? Or is there any other way of doing it? Regards, Alex (erlang newbie) -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlangsiri@REDACTED Tue Mar 11 13:58:45 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 11 Mar 2014 13:58:45 +0100 Subject: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? In-Reply-To: <13201259F072B44F99FC47096AAA78B12899206A@ESESSMB203.ericsson.se> References: <13201259F072B44F99FC47096AAA78B12899206A@ESESSMB203.ericsson.se> Message-ID: Would this also work ? 1 1 6 i.e. without the 'xc' prefix (the netconf base namespace is the default anyway). It's probably up to your netconf server if it can handle that or not. Ideally it should be something like: 1 1 6 where "mynamespace" defines your own config data. This can be expressed in the erlang term like this: Config = {'ElementA',[{xmlns,"mynamespace"},{'xmlns:xc',"urn:ietf:params:xml:ns:netconf:base:1.0"}], [{elementAId,[],["1"]}, {elementB,[], [{elementB,[],["1"]}, {elementC,[{'xc:operation',"delete"}], [{elementCId,[],["6"]}]}]}]}, (but you can probably skip the whole "mynamespace" business and just add the {'xmlns:xc',..} part. /siri 2014-03-11 11:15 GMT+01:00 Alexander Poulikakos < alexander.poulikakos@REDACTED>: > Hi erlang users > > > > I use the ct_netconfc client, from within Common Test. > > > > I'm communicating with a System Under Test (SUT), with the NETCONF > protocol and I want to send a "delete" operation to delete some object. > Example of my code: > > Config = {'ElementA',[], > > [{elementAId,[],["1"]}, > > {elementB,[], > > [{elementB,[],["1"]}, > > {elementC,[{'xc:operation',"delete"}], > > [{elementCId,[],["6"]}]}]}]}, > > {ok, Client}=ct_netconfc:open([{ssh, "some-ip-address"}, {port, > some-port}, {user, "some-username"},{password,"some-password"}]), > > ct_netconfc:edit_config(Client, running, Config), > > > > Which gives me the following error message: > > > > {error,[{'error-type',[{xmlns,"urn:ietf:params:xml:ns:netconf:base:1.0"}], > > ["protocol"]}, > > {'error-tag',[{xmlns,"urn:ietf:params:xml:ns:netconf:base:1.0"}], > > ["operation-failed"]}, > > > {'error-severity',[{xmlns,"urn:ietf:params:xml:ns:netconf:base:1.0"}], > > ["error"]}, > > > {'error-message',[{xmlns,"urn:ietf:params:xml:ns:netconf:base:1.0"}, > > {'xml:lang',"en"}], > > ["Malformed XML!!!"]}]} > > > > > > And the actual XML document (after processed by ct_netconfc) sent to my > SUT looks as follow: > > > > > > > > > > > > > > > > > > > > 1 > > > > 1 > > > > 6 > > > > > > > > > > > > > > > > > > According to examples in RFC6241 [ http://tools.ietf.org/html/rfc6241 June 2011 page 41] the config element contains a namespace attribute xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0". > > So if I add it to the xml document (as below) and manually send it to my SUT, then it works. > > > > > > > > > > > > > > > > > > > > 1 > > > > 1 > > > > 6 > > > > > > > > > > > > > > > > So question is, how do I add the namespace attribute using > ct_netconfc:edit_config/3? Or is there any other way of doing it? > > Regards, > > Alex (erlang newbie) > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbj@REDACTED Tue Mar 11 14:49:55 2014 From: mbj@REDACTED (Martin Bjorklund) Date: Tue, 11 Mar 2014 14:49:55 +0100 (CET) Subject: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? In-Reply-To: References: <13201259F072B44F99FC47096AAA78B12899206A@ESESSMB203.ericsson.se> Message-ID: <20140311.144955.789040872297880364.mbj@tail-f.com> Hi, Siri Hansen wrote: > Would this also work ? > > > > > > > > > > 1 > > 1 > > 6 > > > > > > > > > i.e. without the 'xc' prefix (the netconf base namespace is the default > anyway). This is actually not how default namespaces work. The default namespace does not apply to XML attributes. > It's probably up to your netconf server if it can handle that or > not. Some NETCONF servers are lax and will accept an unqualified "operation" attribute. > Ideally it should be something like: > > > > > > > > > xmlns:xc=\"urn:ietf:params:xml:ns:netconf:base:1.0\"> > 1 > > 1 > > 6 > > > > > > > > where "mynamespace" defines your own config data. This is the only example so far that is correct. It is important that the "ElementA" has a namespace declaration; otherwise it refers to "ElementA" in the namespace "urn:ietf:params:xml:ns:netconf:base:1.0", which clearly is wrong. /martin From max.lapshin@REDACTED Tue Mar 11 16:04:59 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Tue, 11 Mar 2014 19:04:59 +0400 Subject: [erlang-questions] [ANN] erl-min-prj -- Easy way to create a .deb package + minimal project template In-Reply-To: <20140311100948.7e21aa69@portege> References: <20140311100948.7e21aa69@portege> Message-ID: You really offer to install additionally ruby just for making package when making it in erlang takes just several lines: https://github.com/flussonic/epm/blob/master/epm.erl#L241 and without any additional dependencies like librpm for making rpm?! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mallen@REDACTED Tue Mar 11 16:42:40 2014 From: mallen@REDACTED (Mark Allen) Date: Tue, 11 Mar 2014 10:42:40 -0500 Subject: [erlang-questions] [ANN] erl-min-prj -- Easy way to create a .deb package + minimal project template In-Reply-To: References: <20140311100948.7e21aa69@portege> Message-ID: I had no idea such a thing existed. Thanks. Mark From: Max Lapshin > Date: Tuesday, March 11, 2014 10:04 AM To: Alexander Alexeev > Cc: Erlang-Questions Questions > Subject: Re: [erlang-questions] [ANN] erl-min-prj -- Easy way to create a .deb package + minimal project template You really offer to install additionally ruby just for making package when making it in erlang takes just several lines: https://github.com/flussonic/epm/blob/master/epm.erl#L241 and without any additional dependencies like librpm for making rpm?! -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Tue Mar 11 19:43:58 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 11 Mar 2014 19:43:58 +0100 Subject: [erlang-questions] common_test test case documentation Message-ID: <531F596E.3030405@ninenines.eu> Hello, Is there a convenient way to document a test case? I see a few different things in OTP and in the common_test documentation. This seems related to test_server but I don't see anything calling or using it. testcase1(doc) -> ["docs here"]; testcase1(Config) -> ?TEST_HERE. This seems to do nothing and isn't documented anywhere. testcase2() -> [{doc, "docs here"}]. This is awkward, it only shows up in the HTML if the test succeeds. testcase3() -> ?TEST_HERE, {comment, "docs here"}. Otherwise there's of course ct:print/log/pal but it feels like there should be an easier way. Ideally I want the same result as returning a comment tuple from the test case, but that works all the time. Suggestions? -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Tue Mar 11 19:45:41 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Tue, 11 Mar 2014 19:45:41 +0100 Subject: [erlang-questions] common_test test case documentation In-Reply-To: <531F596E.3030405@ninenines.eu> References: <531F596E.3030405@ninenines.eu> Message-ID: <531F59D5.8080208@ninenines.eu> And of course I made a mistake in one example. Sorry. On 03/11/2014 07:43 PM, Lo?c Hoguin wrote: > testcase3() -> ?TEST_HERE, {comment, "docs here"}. The above should read: testcase3(Config) -> ?TEST_HERE, {comment, "docs here"}. -- Lo?c Hoguin http://ninenines.eu From raould@REDACTED Wed Mar 12 00:00:07 2014 From: raould@REDACTED (Raoul Duke) Date: Tue, 11 Mar 2014 16:00:07 -0700 Subject: [erlang-questions] "been there done that" Message-ID: in https://erlangcentral.org/catch-me-if-you-can-processing-terabytes-in-secs there's an off hand comment about not going overboard, like spawning a new process for every request. i'd love to hear more about such pragmatism. please, people speak up with rules of thumb, and dos-and-don'ts. thanks. From ok@REDACTED Wed Mar 12 00:31:43 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 12 Mar 2014 12:31:43 +1300 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> Message-ID: On 10/03/2014, at 8:06 AM, Carsten Bormann wrote: > On 09 Mar 2014, at 17:05, Anthony Ramine wrote: > >> What about the utter lack of proper specifications around JSON? > > JSON is fully specified in RFC 7159. Speaking as someone who has built a JSON library, NO, JSON is *NOT* fully specified. Anywhere. RFC 7159 is ambiguous on a number of key points, and existing parsers differ on those points. To give just one example, if you are given {"foo": 1, "foo": 2} should this be (a) an error, (b) equivalent to {"foo": 1}, (c) equivalent to {"foo": 2}, or (d) something else? I used to believe in Postel's principle, but after trying to work with HTML and JSON, I believe that there are cases where it is better for the community as a whole if you are strict in what you accept. See http://programmingisterrible.com/post/42215715657/postels-principle-is-a-bad-idea But also see http://www.cookcomputing.com/blog/archives/000551.html where we learn what Postel actually meant: - be converative: only generate a core subset of what the protocol allows - be liberal: accept everything *that the protocol allows*. When people accept stuff outside what the protocol explicitly allows, they cannot appeal to Postel. In any case, Erlang's problem is not that it does not support JSON but that there are so many JSON libraries out there that it is difficult to know which one to pick. From ok@REDACTED Wed Mar 12 00:35:53 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 12 Mar 2014 12:35:53 +1300 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <531D26B6.90503@126.com> Message-ID: On 10/03/2014, at 11:07 PM, Jesper Louis Andersen wrote: > * The library API however, is going to be hard to tackle. There is, in fact, an EEP for a JSON library. It's not that recent either. There was a fair bit of bikeshedding in response. From yoursurrogategod@REDACTED Wed Mar 12 00:53:12 2014 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Tue, 11 Mar 2014 19:53:12 -0400 Subject: [erlang-questions] wx not working in Erlang In-Reply-To: <5319FFA1.2010400@ninenines.eu> References: <5319FFA1.2010400@ninenines.eu> Message-ID: Hello, Thanks for pointing that out. I'll just wait until the official release and then update. On Fri, Mar 7, 2014 at 12:19 PM, Lo?c Hoguin wrote: > This issue was there for a while but it seems to work fine using Erlang > 17.0-rc2. > > > On 03/07/2014 02:29 AM, Yves S. Garret wrote: > >> Hello, >> >> I recently updated to the latest release version of Erlang with my >> package manager. I tried starting up the debugger using im(). and it >> did, but then I got the following error dump. >> >> >> (Erlang:5577): GdkPixbuf-CRITICAL **: >> gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed >> >> >> (Erlang:5577): >> GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF >> (pixbuf)' failed >> >> >> (Erlang:5577): GdkPixbuf-CRITICAL **: >> gdk_pixbuf_get_pixels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed >> >> >> (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: >> assertion 'GDK_IS_PIXBUF (pixbuf)' failed >> >> (Erlang:5577): GdkPixbuf-CRITICAL **: >> gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed >> >> >> (Erlang:5577): >> GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF >> (pixbuf)' failed >> >> >> (Erlang:5577): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_width: >> assertion 'GDK_IS_PIXBUF (pixbuf)' failed >> >> (Erlang:5577): >> GdkPixbuf-CRITICAL **: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF >> (pixbuf)' failed >> >> >> I'm not sure why this is happening. Maybe the order of installing the >> packages matters? >> >> I'm running ArchLinux at the moment. >> >> Thanks in advance, >> --Yves >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Wed Mar 12 01:24:38 2014 From: mjtruog@REDACTED (Michael Truog) Date: Tue, 11 Mar 2014 17:24:38 -0700 Subject: [erlang-questions] "been there done that" In-Reply-To: References: Message-ID: <531FA946.5030005@gmail.com> On 03/11/2014 04:00 PM, Raoul Duke wrote: > in > > https://erlangcentral.org/catch-me-if-you-can-processing-terabytes-in-secs > > there's an off hand comment about not going overboard, like spawning a > new process for every request. i'd love to hear more about such > pragmatism. please, people speak up with rules of thumb, and > dos-and-don'ts. > > thanks. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > There is no reason not to spawn a process per request. The reason to spawn a process per request, is it helps the garbage collector keep up with heap and binary garbage collection as you do message deserialization and/or serialization. That way, you can avoid the complexity of trying to tune the garbage collection parameters in erts, when you don't need to. If instead you decide to not use a process per request, and you get higher throughput than your previous testing, any previous garbage collection tuning can become invalid due to the rate increase. The Erlang process for the request, when using a process per request, is a short-lived process, to make sure there is a benefit (so this is something separate from using an Erlang process per connection, since an Erlang connection process could have a longer lifetime). From raould@REDACTED Wed Mar 12 01:27:11 2014 From: raould@REDACTED (Raoul Duke) Date: Tue, 11 Mar 2014 17:27:11 -0700 Subject: [erlang-questions] "been there done that" In-Reply-To: <531FA946.5030005@gmail.com> References: <531FA946.5030005@gmail.com> Message-ID: > sure there is a benefit (so this is something separate from using an Erlang > process per connection, since an Erlang connection process could have a > longer lifetime). i'm unfortunately an eternally clueless newbie about erlang, so i might well have mis understood and mis written, and the original claim might well have e.g. been about connections and not requests. :-) From joaohf@REDACTED Wed Mar 12 03:27:04 2014 From: joaohf@REDACTED (=?ISO-8859-1?Q?Jo=E3o_Henrique_Ferreira_de_Freitas?=) Date: Tue, 11 Mar 2014 23:27:04 -0300 Subject: [erlang-questions] Erlang and SDL (ITU Z.100) Message-ID: <531FC5F8.7060708@gmail.com> Hello, I am starting some experiments about SDL ([1]) and Erlang. My aim is to use OpenGEODE [2] and add Erlang backend to create erlang code from SDL (PR). I don't know if this is a cool think to do but I am learning a lot. I've been read this sdl2erlang [3] paper to get some ideas. Anybody know what happened with that initiative ? Maybe there are some code on somewhere ? I believe that sdl2erlang has some key points that I could use to create a good work (that works). Thanks. [1] http://www.itu.int/ITU-T/studygroups/com17/languages/Z100.pdf [2] http://taste.tuxfamily.org/wiki/index.php?title=Technical_topic:_OpenGEODE,_an_SDL_editor_for_TASTE [3] http://www.erlang.se/publications/sdl2erlang.pdf From mail@REDACTED Wed Mar 12 09:19:18 2014 From: mail@REDACTED (Alexander Alexeev) Date: Wed, 12 Mar 2014 12:19:18 +0400 Subject: [erlang-questions] [ANN] erl-min-prj -- Easy way to create a .deb package + minimal project template In-Reply-To: References: <20140311100948.7e21aa69@portege> Message-ID: <20140312121918.21d3402d@portege> Sure, since EPM was designed as drop-in replacement for FPM, you can just create a symlink to epm named fpm. In theory it will work just fine. Unfortunately for now it doesn't. See my bugreport to EPM. Also FPM seems to have more features than EPM. I've used FPM for a long time and didn't encountered any problems which EPM claims to solve. So for now it seems reasonable to use well known and stable FPM instead of EPM. However I will be happy to get rid of FPM in favor of EPM when EPM will reach sufficient maturity. > You really offer to install additionally ruby just for making package > when making it in erlang takes just several lines: > > https://github.com/flussonic/epm/blob/master/epm.erl#L241 > > and without any additional dependencies like librpm for making rpm?! -- Best regards, Alexander Alexeev http://eax.me/ From alexander.poulikakos@REDACTED Wed Mar 12 09:38:44 2014 From: alexander.poulikakos@REDACTED (Alexander Poulikakos) Date: Wed, 12 Mar 2014 08:38:44 +0000 Subject: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? In-Reply-To: <20140311.144955.789040872297880364.mbj@tail-f.com> References: <13201259F072B44F99FC47096AAA78B12899206A@ESESSMB203.ericsson.se> <20140311.144955.789040872297880364.mbj@tail-f.com> Message-ID: <13201259F072B44F99FC47096AAA78B128993040@ESESSMB203.ericsson.se> Hi Yes, this works for me (it also works without the 'xs' prefix), thanks for that :) 1 1 < xc:operation="delete"> 6 But what is the difference between putting the namespace attribute on ElementA, instead of config? Which is the correct NETCONF way? Or maybe it does not matter? Seems to work to add the namespace attribute on the "elementC" as well (at least for my SUT). Is the example in RFC6241 [ http://tools.ietf.org/html/rfc6241 June 2011 page 41], where they use the "config" element, wrong? See below: none Ethernet0/0 ///Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@REDACTED] Sent: den 11 mars 2014 14:50 To: erlangsiri@REDACTED Cc: Alexander Poulikakos; erlang-questions@REDACTED Subject: Re: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? Hi, Siri Hansen wrote: > Would this also work ? > > xmlns=\"urn:ietf:params:xml:ns:netconf:base:1.0\"> > > > > > > > 1 > > 1 > > 6 > > > > > > > > > i.e. without the 'xc' prefix (the netconf base namespace is the > default anyway). This is actually not how default namespaces work. The default namespace does not apply to XML attributes. > It's probably up to your netconf server if it can handle that or not. Some NETCONF servers are lax and will accept an unqualified "operation" attribute. > Ideally it should be something like: > > xmlns=\"urn:ietf:params:xml:ns:netconf:base:1.0\"> > > > > > > xmlns:xc=\"urn:ietf:params:xml:ns:netconf:base:1.0\"> > 1 > > 1 > > 6 > > > > > > > > where "mynamespace" defines your own config data. This is the only example so far that is correct. It is important that the "ElementA" has a namespace declaration; otherwise it refers to "ElementA" in the namespace "urn:ietf:params:xml:ns:netconf:base:1.0", which clearly is wrong. /martin From jesper.louis.andersen@REDACTED Wed Mar 12 10:06:55 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 12 Mar 2014 10:06:55 +0100 Subject: [erlang-questions] "been there done that" In-Reply-To: References: Message-ID: Many of the Erlang web servers will reuse a process for the next request and only cycle them once in a while. And they will systematically extend number of processes that are sitting and waiting. This avoids spawning a new process on each request, but still allows the system to grow in capacity should it be needed. The rule of thumb is: Make a new process per request. If this seems to be a bad idea, then measure and change the scheme. The problem is that these more intricate process schemes take more code and are more error prone. So if you can avoid it, you can have better code. Measurement is key! On Wed, Mar 12, 2014 at 12:00 AM, Raoul Duke wrote: > in > > https://erlangcentral.org/catch-me-if-you-can-processing-terabytes-in-secs > > there's an off hand comment about not going overboard, like spawning a > new process for every request. i'd love to hear more about such > pragmatism. please, people speak up with rules of thumb, and > dos-and-don'ts. > > thanks. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbj@REDACTED Wed Mar 12 10:14:21 2014 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 12 Mar 2014 10:14:21 +0100 (CET) Subject: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? In-Reply-To: <13201259F072B44F99FC47096AAA78B128993040@ESESSMB203.ericsson.se> References: <20140311.144955.789040872297880364.mbj@tail-f.com> <13201259F072B44F99FC47096AAA78B128993040@ESESSMB203.ericsson.se> Message-ID: <20140312.101421.131973479180564446.mbj@tail-f.com> Alexander Poulikakos wrote: > Hi > > Yes, this works for me (it also works without the 'xs' prefix), thanks > for that :) > > > > > > > > > > 1 > > 1 > < xc:operation="delete"> > 6 > > > > > > > > > But what is the difference between putting the namespace attribute on > ElementA, instead of config? Which is the correct NETCONF way? Or > maybe it does not matter? This is a generic XML issue, rather than NETCONF specific. The XML attribute 'xmlns:xc="..."' is really like a variable assignment: xc := "..." After this, 'xc' can be used in the subtree as a prefix, e.g. "xc:operation". So in this example, it doesn't matter where you define your "xc" prefix; you can put in on any element above the element where it is used, e.g., any of , , , , , or . > > > Seems to work to add the namespace attribute on the "elementC" as well > (at least for my SUT). > > Is the example in RFC6241 [ http://tools.ietf.org/html/rfc6241 June > 2011 page 41], where they use the "config" element, wrong? See below: No, it is correct. /martin > > > > > > > none > > > > Ethernet0/0 > > > > > > > > ///Alex > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@REDACTED] > Sent: den 11 mars 2014 14:50 > To: erlangsiri@REDACTED > Cc: Alexander Poulikakos; erlang-questions@REDACTED > Subject: Re: [erlang-questions] ct_netconfc.erl: is this the expected > behavior or is it a bug? > > Hi, > > Siri Hansen wrote: > > Would this also work ? > > > > > xmlns=\"urn:ietf:params:xml:ns:netconf:base:1.0\"> > > > > > > > > > > > > > > 1 > > > > 1 > > > > 6 > > > > > > > > > > > > > > > > > > i.e. without the 'xc' prefix (the netconf base namespace is the > > default anyway). > > This is actually not how default namespaces work. The default > namespace does not apply to XML attributes. > > > It's probably up to your netconf server if it can handle that or not. > > Some NETCONF servers are lax and will accept an unqualified > "operation" attribute. > > > Ideally it should be something like: > > > > > xmlns=\"urn:ietf:params:xml:ns:netconf:base:1.0\"> > > > > > > > > > > > > > xmlns:xc=\"urn:ietf:params:xml:ns:netconf:base:1.0\"> > > 1 > > > > 1 > > > > 6 > > > > > > > > > > > > > > > > where "mynamespace" defines your own config data. > > This is the only example so far that is correct. It is important that > the "ElementA" has a namespace declaration; otherwise it refers to > "ElementA" in the namespace "urn:ietf:params:xml:ns:netconf:base:1.0", > which clearly is wrong. > > > /martin > From erlangsiri@REDACTED Wed Mar 12 10:25:53 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 12 Mar 2014 10:25:53 +0100 Subject: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? In-Reply-To: <20140311.144955.789040872297880364.mbj@tail-f.com> References: <13201259F072B44F99FC47096AAA78B12899206A@ESESSMB203.ericsson.se> <20140311.144955.789040872297880364.mbj@tail-f.com> Message-ID: 2014-03-11 14:49 GMT+01:00 Martin Bjorklund : > Hi, > > Siri Hansen wrote: > > Would this also work ? > > > > > > > > > > > > > > > > > > > > 1 > > > > 1 > > > > 6 > > > > > > > > > > > > > > > > > > i.e. without the 'xc' prefix (the netconf base namespace is the default > > anyway). > > This is actually not how default namespaces work. The default > namespace does not apply to XML attributes. > > Thanks, Martin, for pointing that out! Is this a fact in general or do you mean that the default namespace would not apply to an XML attribute which is located inside an XML element that is not part of the default namespace? I mean, would the default namespace apply an attribute in e.g. the 'config' element? /siri -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Wed Mar 12 10:49:22 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Wed, 12 Mar 2014 13:49:22 +0400 Subject: [erlang-questions] [ANN] erl-min-prj -- Easy way to create a .deb package + minimal project template In-Reply-To: <20140312121918.21d3402d@portege> References: <20140311100948.7e21aa69@portege> <20140312121918.21d3402d@portege> Message-ID: Problem with fpm is that it is a growing technical dept. I hire people who are working or going to work with erlang. We write software in erlang. If one team member will bring new software in ruby, then all people will require to maintain ruby (it requires compiling it from source), maintain proper version of ruby software, etc. I want to mention that we are speaking not about additional separate service written in Ruby on Rails, we are speaking about infrastructure tool that will be used by all people. Each time when you don't bundle rebar into your repository or you add dependency from external software, you create new problem that will appear a year after. When you will forget about this tool or forget what version of tool have you used. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbj@REDACTED Wed Mar 12 10:52:49 2014 From: mbj@REDACTED (Martin Bjorklund) Date: Wed, 12 Mar 2014 10:52:49 +0100 (CET) Subject: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? In-Reply-To: References: <20140311.144955.789040872297880364.mbj@tail-f.com> Message-ID: <20140312.105249.1825143830807485544.mbj@tail-f.com> Siri Hansen wrote: > 2014-03-11 14:49 GMT+01:00 Martin Bjorklund : > > > Hi, > > > > Siri Hansen wrote: > > > Would this also work ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1 > > > > > > 1 > > > > > > 6 > > > > > > > > > > > > > > > > > > > > > > > > > > > i.e. without the 'xc' prefix (the netconf base namespace is the default > > > anyway). > > > > This is actually not how default namespaces work. The default > > namespace does not apply to XML attributes. > > > > > Thanks, Martin, for pointing that out! Is this a fact in general or do you > mean that the default namespace would not apply to an XML attribute which > is located inside an XML element that is not part of the default namespace? It is general. See e.g. http://www.rpbourret.com/xml/NamespacesFAQ.htm#doc_3, http://www.rpbourret.com/xml/NamespaceMyths.htm#myth4 (see also http://www.rpbourret.com/xml/NamespacesFAQ.htm#politics_1) Or if you prefer the spec: http://www.w3.org/TR/REC-xml-names/#defaulting. /martin From alexander.poulikakos@REDACTED Wed Mar 12 11:20:53 2014 From: alexander.poulikakos@REDACTED (Alexander Poulikakos) Date: Wed, 12 Mar 2014 10:20:53 +0000 Subject: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? In-Reply-To: <20140312.101421.131973479180564446.mbj@tail-f.com> References: <20140311.144955.789040872297880364.mbj@tail-f.com> <13201259F072B44F99FC47096AAA78B128993040@ESESSMB203.ericsson.se> <20140312.101421.131973479180564446.mbj@tail-f.com> Message-ID: <13201259F072B44F99FC47096AAA78B1289932D8@ESESSMB203.ericsson.se> > So in this example, it doesn't matter where you define your "xc" > prefix; you can put in on any element above the element where it is used, e.g., any of , , , , , or . How can I define the "xc" prefix on the element with ct_netconfc:edit_config/3 function? From erlangsiri@REDACTED Wed Mar 12 12:03:11 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 12 Mar 2014 12:03:11 +0100 Subject: [erlang-questions] ct_netconfc.erl: is this the expected behavior or is it a bug? In-Reply-To: <13201259F072B44F99FC47096AAA78B1289932D8@ESESSMB203.ericsson.se> References: <20140311.144955.789040872297880364.mbj@tail-f.com> <13201259F072B44F99FC47096AAA78B128993040@ESESSMB203.ericsson.se> <20140312.101421.131973479180564446.mbj@tail-f.com> <13201259F072B44F99FC47096AAA78B1289932D8@ESESSMB203.ericsson.se> Message-ID: You can not do that with ct_netconfc:edit_config/3. If you want to alter the 'config' element you must use ct_netconfc:send_rpc (and specify the edit-config element with all it's contents) or ct_netconfc:send (if you want to specify the complete rpc message). /siri 2014-03-12 11:20 GMT+01:00 Alexander Poulikakos < alexander.poulikakos@REDACTED>: > > So in this example, it doesn't matter where you define your "xc" > > prefix; you can put in on any element above the element where it is > used, e.g., any of , , , , > , or . > > How can I define the "xc" prefix on the element with > ct_netconfc:edit_config/3 function? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Wed Mar 12 12:43:05 2014 From: txrev319@REDACTED (t x) Date: Wed, 12 Mar 2014 04:43:05 -0700 Subject: [erlang-questions] erldn:parse_str Message-ID: Hi, Consider: erldn:parse_str("{:hi-hello 42}"). {ok,{map,[{'hi-hello',42}]}} Now, it looks like this format is not hard to change to user Erlang r17-rc2 maps. Out of laziness, has anyone else (1) run into this problem and (2) written up a script to change it? Thanks! :-) From suraj.kumar@REDACTED Thu Mar 13 04:15:55 2014 From: suraj.kumar@REDACTED (Suraj Kumar) Date: Thu, 13 Mar 2014 08:45:55 +0530 Subject: [erlang-questions] Workflow Execution Engine and DSL documentation Message-ID: Hi, I'm on the lookout for a solid workflow execution engine. The idea is to make that engine consume data from our CouchDB database and maintain computed workflow states back in the same highly available data store. The current contender is JBPM. JBPM makes people feel very secure ("Enterprise-grade solution", XML and BPMN and BPEL and what not :) ). But really, it is because there are many tools to make development, testing and monitoring of workflows easy. A native erlang solution, like WEE, could be of help: http://sourceforge.net/projects/weeworkflow/ But I'm afraid, it will still be more effort to setup WEE for the purpose of: - Modeling many workflows easily - Validating defined workflows - monitor state of execution of all workflows across all entities Any suggestions or pointers to how to pull this off? -- An Onion is the Onion skin and the Onion under the skin until the Onion Skin without any Onion underneath. -- _____________________________________________________________ The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The firm is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Thu Mar 13 07:39:52 2014 From: moxford@REDACTED (Mike Oxford) Date: Wed, 12 Mar 2014 23:39:52 -0700 Subject: [erlang-questions] Workflow Execution Engine and DSL documentation In-Reply-To: References: Message-ID: I've used Camel before. Mixed bag of likes and dislikes. I don't know of any Erlang-specific ESB packages, though, really, do you need more than just an FSM? Define one gen_fsm per flow and let those run themselves through your service pools. On Wed, Mar 12, 2014 at 8:15 PM, Suraj Kumar wrote: > Hi, > > I'm on the lookout for a solid workflow execution engine. The idea is to > make that engine consume data from our CouchDB database and maintain > computed workflow states back in the same highly available data store. > > The current contender is JBPM. JBPM makes people feel very secure > ("Enterprise-grade solution", XML and BPMN and BPEL and what not :) ). But > really, it is because there are many tools to make development, testing and > monitoring of workflows easy. > > A native erlang solution, like WEE, could be of help: > http://sourceforge.net/projects/weeworkflow/ But I'm afraid, it will > still be more effort to setup WEE for the purpose of: > > - Modeling many workflows easily > - Validating defined workflows > - monitor state of execution of all workflows across all entities > > > Any suggestions or pointers to how to pull this off? > > -- > An Onion is the Onion skin and the Onion under the skin until the Onion > Skin without any Onion underneath. > > > _____________________________________________________________ > The information contained in this communication is intended solely for the > use of the individual or entity to whom it is addressed and others > authorized to receive it. It may contain confidential or legally privileged > information. If you are not the intended recipient you are hereby notified > that any disclosure, copying, distribution or taking any action in reliance > on the contents of this information is strictly prohibited and may be > unlawful. If you have received this communication in error, please notify > us immediately by responding to this email and then delete it from your > system. The firm is neither liable for the proper and complete transmission > of the information contained in this communication nor for any delay in its > receipt. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Thu Mar 13 07:40:31 2014 From: moxford@REDACTED (Mike Oxford) Date: Wed, 12 Mar 2014 23:40:31 -0700 Subject: [erlang-questions] Workflow Execution Engine and DSL documentation In-Reply-To: References: Message-ID: Another option might be Mule but, again, that's not Erlang. =) On Wed, Mar 12, 2014 at 11:39 PM, Mike Oxford wrote: > I've used Camel before. Mixed bag of likes and dislikes. > > I don't know of any Erlang-specific ESB packages, though, really, do you > need more than just an FSM? Define one gen_fsm per flow and let those run > themselves through your service pools. > > > On Wed, Mar 12, 2014 at 8:15 PM, Suraj Kumar wrote: > >> Hi, >> >> I'm on the lookout for a solid workflow execution engine. The idea is to >> make that engine consume data from our CouchDB database and maintain >> computed workflow states back in the same highly available data store. >> >> The current contender is JBPM. JBPM makes people feel very secure >> ("Enterprise-grade solution", XML and BPMN and BPEL and what not :) ). But >> really, it is because there are many tools to make development, testing and >> monitoring of workflows easy. >> >> A native erlang solution, like WEE, could be of help: >> http://sourceforge.net/projects/weeworkflow/ But I'm afraid, it will >> still be more effort to setup WEE for the purpose of: >> >> - Modeling many workflows easily >> - Validating defined workflows >> - monitor state of execution of all workflows across all entities >> >> >> Any suggestions or pointers to how to pull this off? >> >> -- >> An Onion is the Onion skin and the Onion under the skin until the Onion >> Skin without any Onion underneath. >> >> >> _____________________________________________________________ >> The information contained in this communication is intended solely for >> the use of the individual or entity to whom it is addressed and others >> authorized to receive it. It may contain confidential or legally privileged >> information. If you are not the intended recipient you are hereby notified >> that any disclosure, copying, distribution or taking any action in reliance >> on the contents of this information is strictly prohibited and may be >> unlawful. If you have received this communication in error, please notify >> us immediately by responding to this email and then delete it from your >> system. The firm is neither liable for the proper and complete transmission >> of the information contained in this communication nor for any delay in its >> receipt. >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas@REDACTED Thu Mar 13 08:26:51 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Thu, 13 Mar 2014 08:26:51 +0100 Subject: [erlang-questions] Fwd: Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: <53196EB9.7080707@gmail.com> Message-ID: Hi Richard, Thank you for the patch. We are going to take the parts related to opening the file, in order to reduce the number of times a file is opened, but we are not going to introduce the proposed flag to the erlc options. Early on, before the actual introduction of Unicode/UTF-8 encoding, it was decided that Unicode using UTF-8 encoding shall be supported through an encoding instruction in a comment in the beginning of the file (as in Python), which informs the tool chain about the input file encoding format. This approach has the benefit of allowing encoding information in all kind of source code in Erlang/OTP using the same mechanism; that is, it solves issues with both erlang source, yecc, leex, and file:consult. The underlying design philosophy is that the encoding is a property of the file, and not part of the language. The default file encoding was ISO-Latin-1 until R16, but will be changed to UTF-8 in OTP 17. The intention was that source code does not need to be changed in R16, but adding a comment denoting ISO-Latin-1 encoding ensures that the code can be compiled with the OTP 17 compiler. Likewise, adding a comment denoting UTF-8 encoding allows for Unicode characters with code points > 255 in string and character literals in R16. The same comment will allow for atoms containing any Unicode code point in OTP 18. As pointed out in previous mails, we did not communicate the impact on the applications clearly enough. Hence, we are now introducing a workaround, in which the preprocessor processes the file again using ISO-Latin-1 encoding if it failed to read the file with the default UTF-8 encoding. This solution, although it may seem awkward, is in line with the original design philosophy. We anticipate that there will only be a small amount of files for which this automatic workaround needs to kick in. ASCII is valid UTF-8; and thus, only files containing ISO-Latin-1 characters #80 and above are impacted. The workaround is going to be removed in a future release and the corresponding deprecation warning will then be turned into an error. Whether that will happen in OTP 18 or later is for further discussion. Andreas Schumacher, Erlang/OTP, Ericsson AB *From: *Richard Carlsson *Subject: * *Re: [erlang-questions] Fwd: FW: Breaking backwards compatibility in Release 17.0-rc2* *Date: *7 Mar 2014 08:01:13 GMT+1 *To: *Andreas Schumacher , "erlang-questions@REDACTED" On 2014-03-06 02:15 , Andreas Schumacher wrote: In OTP 17.0-rc{1,2}, a file that is encoded in latin-1 and contains non-UTF-8/non-ASCII-7 characters, causes a compiler error similar to the following: tst.erl:1: cannot parse file, giving up tst.erl:1: no module definition tst.erl:1: cannot translate from UTF-8 In OTP 17.0, if a file is encoded in latin-1 and contains non-UTF-8/non-ASCII characters, but does not declare the encoding with a magic encoding comment at the beginning of the file, epp (the Erlang code pre-processor) issues a deprecation warning, and processes the file again, assuming latin-1 encoding. In a future major version, preferably in OTP 18, the deprecation warning will be turned into an error again. That is, only UTF-8 encoded files, and files that declare the source code encoding at the beginning of the source code file, will be accepted. Still not good enough. I want to be able to move up to R18 when that time comes without having to modify files all over our codebase. (And retrying is an ugly workaround anyway.) The following patch has allowed me to compile all of our sources under R17 by simply adding '+{default_encoding,latin1}' to the erlc options in our Makefiles: https://github.com/erlang/otp/pull/276 /Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlsson.richard@REDACTED Thu Mar 13 11:49:40 2014 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Thu, 13 Mar 2014 11:49:40 +0100 Subject: [erlang-questions] Fwd: Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: <53196EB9.7080707@gmail.com> Message-ID: <53218D44.7080509@gmail.com> On 2014-03-13 08:26 , Andreas Schumacher wrote: > We anticipate that there will only be a small amount of files for which > this automatic workaround needs to kick in. ASCII is valid UTF-8; and > thus, only files containing ISO-Latin-1 characters #80 and above are > impacted. I checked our code base, and found almost 700 .erl and .hrl files containing Latin-1 characters. That's only about 15% of all source files, so the effect on compilation times of retrying should be small. You might also want to retry with Latin-1 in file:consult() and the other functions in file.erl that depend on encodings. /Richard From andreas@REDACTED Thu Mar 13 12:12:08 2014 From: andreas@REDACTED (Andreas Schumacher) Date: Thu, 13 Mar 2014 12:12:08 +0100 Subject: [erlang-questions] Fwd: Breaking backwards compatibility in Release 17.0-rc2 In-Reply-To: References: <53218D44.7080509@gmail.com> Message-ID: Thanks for the additional feedback. We will look into applying the workaround to file:consult() and other functions in file.erl as well. Andreas Begin forwarded message: *From: *Richard Carlsson *Subject: * *Re: Fwd: [erlang-questions] Breaking backwards compatibility in Release 17.0-rc2* *Date: *13 Mar 2014 11:49:40 GMT+1 *To: *Andreas Schumacher *Cc: * On 2014-03-13 08:26 , Andreas Schumacher wrote: We anticipate that there will only be a small amount of files for which this automatic workaround needs to kick in. ASCII is valid UTF-8; and thus, only files containing ISO-Latin-1 characters #80 and above are impacted. I checked our code base, and found almost 700 .erl and .hrl files containing Latin-1 characters. That's only about 15% of all source files, so the effect on compilation times of retrying should be small. You might also want to retry with Latin-1 in file:consult() and the other functions in file.erl that depend on encodings. /Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.aadi07@REDACTED Thu Mar 13 12:22:44 2014 From: i.aadi07@REDACTED (aadi i) Date: Thu, 13 Mar 2014 16:52:44 +0530 Subject: [erlang-questions] How can I handle do_post method for HTTPS server usiing httpd Message-ID: Hi I am trying to implement HTTPS server in Erlang using httpd In which options/properties of httpd do i need to supply the user callbacks which are handling the post and get methods .?? Thanks in advance :-) adinarayana murthy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Thu Mar 13 16:59:20 2014 From: mrtndimitrov@REDACTED (Martin Koroudjiev) Date: Thu, 13 Mar 2014 17:59:20 +0200 Subject: [erlang-questions] Why is tv module missing from R17 rc 2? Message-ID: <5321D5D8.10208@gmail.com> Hello, I don't see in the source distribution the "tv" module. Is this intentional? What is the new way of seeing the ETS tables? Regards, Martin From kenneth.lundin@REDACTED Thu Mar 13 17:07:04 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 13 Mar 2014 17:07:04 +0100 Subject: [erlang-questions] Why is tv module missing from R17 rc 2? In-Reply-To: <5321D5D8.10208@gmail.com> References: <5321D5D8.10208@gmail.com> Message-ID: The possibility to view ets and mnesia tables in a graphical tool is now provided by the observer tool. The table viewer function has in fact been there for quite some time. start with "observer:start()." /Kenneth, Erlang/OTP, Ericsson On Thu, Mar 13, 2014 at 4:59 PM, Martin Koroudjiev wrote: > Hello, > > I don't see in the source distribution the "tv" module. Is this > intentional? What is the new way of seeing the ETS tables? > > Regards, > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrtndimitrov@REDACTED Thu Mar 13 17:10:32 2014 From: mrtndimitrov@REDACTED (Martin Koroudjiev) Date: Thu, 13 Mar 2014 18:10:32 +0200 Subject: [erlang-questions] Why is tv module missing from R17 rc 2? In-Reply-To: References: <5321D5D8.10208@gmail.com> Message-ID: <5321D878.8030602@gmail.com> Thank you. On 3/13/2014 6:07 PM, Kenneth Lundin wrote: > The possibility to view ets and mnesia tables in a graphical tool is > now provided by the observer tool. > The table viewer function has in fact been there for quite some time. > > start with "observer:start()." > > /Kenneth, Erlang/OTP, Ericsson > > > On Thu, Mar 13, 2014 at 4:59 PM, Martin Koroudjiev > > wrote: > > Hello, > > I don't see in the source distribution the "tv" module. Is this > intentional? What is the new way of seeing the ETS tables? > > Regards, > Martin > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cabo@REDACTED Thu Mar 13 21:16:25 2014 From: cabo@REDACTED (Carsten Bormann) Date: Thu, 13 Mar 2014 21:16:25 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: On 10 Mar 2014, at 15:54, Lo?c Hoguin wrote: > Could you elaborate on what the dominant usage of JSON is? Certainly. JSON is used for data interchange between applications or within components of an application. The most extensive use is from JavaScript-based Web application front-ends (running in the browser) to their backends (running on a server) and back; these are shipped as application/json representations in AJAX accesses (HTTP access from JavaScript via the confusingly named XMLHttpRequest object). Many Web APIs that have been designed in the last half decade are described in JSON form, so applications that access another application via a Web API are likely to ship back and forth application/json representations via HTTP accesses. Gr??e, Carsten From cabo@REDACTED Thu Mar 13 21:31:16 2014 From: cabo@REDACTED (Carsten Bormann) Date: Thu, 13 Mar 2014 21:31:16 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> Message-ID: <249F6596-9BB3-4217-A29A-A3DBA3E7D355@tzi.org> On 12 Mar 2014, at 00:31, Richard A. O'Keefe wrote: > RFC 7159 is ambiguous on a number of key points, and > existing parsers differ on those points. To give just > one example, if you are given > {"foo": 1, "foo": 2} > should this be (a) an error, (b) equivalent to {"foo": 1}, > (c) equivalent to {"foo": 2}, or (d) something else? The example you cite is using JSON?s syntax, but not compatible with JSON?s data model. RFC 7159 is not ambiguous at all here (even if the spec language is slightly broken): An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates. So don?t generate something like this if you want to be able to predict what the receiver will do with it. The more interesting question is indeed how to react to input of this form. For Erlang, ?let it crash? philosophy should direct the implementer to generating an error. However, RFC 7159 does not overspecify the behavior because detection of the error may be expensive. So, for instance, the behavior specified in recent ECMAScript documents (use only the last value received for a duplicate key) may be more efficiently implementable than throwing an error. > I used to believe in Postel's principle Postel?s principle is fine (it is essentially expressing the cleverness antipattern). It is just often misunderstood as a mandate to ?accept all soup? (which is not compatible with ?conservative what you send? at all!). It should be well known in this community that failing fast is much better then trudging on with questionable interpretations of murky data. Gr??e, Carsten From ok@REDACTED Thu Mar 13 22:52:44 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Fri, 14 Mar 2014 10:52:44 +1300 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <249F6596-9BB3-4217-A29A-A3DBA3E7D355@tzi.org> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> <249F6596-9BB3-4217-A29A-A3DBA3E7D355@tzi.org> Message-ID: <01FFB1CD-EDB4-4E84-B55E-416638224BCE@cs.otago.ac.nz> On 14/03/2014, at 9:31 AM, Carsten Bormann wrote: > On 12 Mar 2014, at 00:31, Richard A. O'Keefe wrote: > >> RFC 7159 is ambiguous on a number of key points, and >> existing parsers differ on those points. To give just >> one example, if you are given >> {"foo": 1, "foo": 2} >> should this be (a) an error, (b) equivalent to {"foo": 1}, >> (c) equivalent to {"foo": 2}, or (d) something else? > > The example you cite is using JSON?s syntax, but not compatible with JSON?s data model. ECMA 404 doesn't *HAVE* a data model. > > RFC 7159 is not ambiguous at all here (even if the spec language is slightly broken): Sorry, I *meant* to write "RFC 4627". In fact the issue that caused me grief with 4627 is one of the things that's been fixed in 7159 (which I wasn't aware of). Maybe RFC 7159 is not ambiguous now. (The versions that's up now , but ECMA 404 does not have anything like the text cited from RFC 7159. The original specification of JSON said that it was a *binary* format where characters must be encoded as UTF-8. RFC 7159 says that it SHALL be UTF-8, UTF-16, or UTF-32 but then forbids the use of a BOM! In contrast, ECMA 404 defines JSON as a sequence of Unicode code-points, saying nothing about encoding. Presumably an ECMA-404-compliant implementation of JSON could use UTF-16 *with* a BOM, or SCSU, or some private encoding convention... I think you will agree that the existence of *two* standards (RFC 7159 and ECMA 404) with differing content is a problem all by itself. From cabo@REDACTED Thu Mar 13 23:00:21 2014 From: cabo@REDACTED (Carsten Bormann) Date: Thu, 13 Mar 2014 23:00:21 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <01FFB1CD-EDB4-4E84-B55E-416638224BCE@cs.otago.ac.nz> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> <249F6596-9BB3-4217-A29A-A3DBA3E7D355@tzi.org> <01FFB1CD-EDB4-4E84-B55E-416638224BCE@cs.otago.ac.nz> Message-ID: <1B11D50E-F4C1-4EFB-8666-F188B92B138A@tzi.org> >> The example you cite is using JSON?s syntax, but not compatible with JSON?s data model. > > ECMA 404 doesn't *HAVE* a data model. (It does, it just tries to act as if it didn?t.) Tim Bray has a pretty good account on how that accident happened: https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-JSON Don?t waste any time with ECMA-404. If you want to do useful work with JSON, RFC 7159 it is. (Leafing through EEP-18, this strikes me as rather competent*) ? why did it get stuck?) Gr??e, Carsten *) Except maybe for the odd JSON extension proposal; just say no. From be.dmitry@REDACTED Thu Mar 13 23:11:54 2014 From: be.dmitry@REDACTED (Dmitry Belyaev) Date: Fri, 14 Mar 2014 09:11:54 +1100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <01FFB1CD-EDB4-4E84-B55E-416638224BCE@cs.otago.ac.nz> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> <249F6596-9BB3-4217-A29A-A3DBA3E7D355@tzi.org> <01FFB1CD-EDB4-4E84-B55E-416638224BCE@cs.otago.ac.nz> Message-ID: <21bda60c-c62d-4849-98f3-6981e00cad71@email.android.com> On 14 March 2014 8:52:44 AM AEDT, "Richard A. O'Keefe" wrote: > >... > >The original specification of JSON said that it was a >*binary* format where characters must be encoded as UTF-8. >RFC 7159 says that it SHALL be UTF-8, UTF-16, or UTF-32 >but then forbids the use of a BOM! I guess this encoding problem must be solved the same way as content type - this information has to be provided outside of content. From cabo@REDACTED Thu Mar 13 23:40:13 2014 From: cabo@REDACTED (Carsten Bormann) Date: Thu, 13 Mar 2014 23:40:13 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <21bda60c-c62d-4849-98f3-6981e00cad71@email.android.com> References: <90D94FFC-4F47-4766-98D3-4E7797E92178@gmail.com> <531C8139.9020108@126.com> <62E5FAD4-75F5-4522-B132-60170B4E8D81@gmail.com> <236D4BE4-3340-4BFB-9FEC-7C38B1729A25@tzi.org> <249F6596-9BB3-4217-A29A-A3DBA3E7D355@tzi.org> <01FFB1CD-EDB4-4E84-B55E-416638224BCE@cs.otago.ac.nz> <21bda60c-c62d-4849-98f3-6981e00cad71@email.android.com> Message-ID: <480D5E09-E66C-46CC-968E-E2E65BFDF77A@tzi.org> >> The original specification of JSON said that it was a >> *binary* format where characters must be encoded as UTF-8. >> RFC 7159 says that it SHALL be UTF-8, UTF-16, or UTF-32 >> but then forbids the use of a BOM! > > I guess this encoding problem must be solved the same way as content type - this information has to be provided outside of content. It?s much simpler than that ? the encoding is UTF-8. Always. (RFC 7159 removed the language that RFC 4627 had about auto detecting the character encoding scheme from the initial bytes, in part because the old language assumed only arrays and maps (?objects?) could be top-level, but also because UTF-16 and UTF-32 are not in real-world use. There wasn?t enough energy to remove the fiction of UTF-16 or UTF-32 support from the document, because there was a feeling that would ?break? something ? break what? One of the few failings of the process that led to RFC 7159.) The whole text: JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encoding is UTF-8, and JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the maximum number of implementations; there are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32). In other words: Don?t do that (where that = UTF-16 or UTF-32). More specifically, the Internet Media Type application/json does *not* have a charset parameter, because it doesn?t need one. (Autodetection would still work, but you have to figure out the details by yourself.) Gr??e, Carsten From n.oxyde@REDACTED Fri Mar 14 00:57:45 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 14 Mar 2014 00:57:45 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: Where is the scientific study that proves this? Or is that just your personal experience? -- Anthony Ramine Le 13 mars 2014 ? 21:16, Carsten Bormann a ?crit : > On 10 Mar 2014, at 15:54, Lo?c Hoguin wrote: > >> Could you elaborate on what the dominant usage of JSON is? > > Certainly. > > JSON is used for data interchange between applications or within components of an application. > > The most extensive use is from JavaScript-based Web application front-ends (running in the browser) to their backends (running on a server) and back; these are shipped as application/json representations in AJAX accesses (HTTP access from JavaScript via the confusingly named XMLHttpRequest object). > > Many Web APIs that have been designed in the last half decade are described in JSON form, so applications that access another application via a Web API are likely to ship back and forth application/json representations via HTTP accesses. > > Gr??e, Carsten > From essen@REDACTED Fri Mar 14 02:08:42 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 14 Mar 2014 02:08:42 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: <5322569A.8010600@ninenines.eu> On 03/13/2014 09:16 PM, Carsten Bormann wrote: > On 10 Mar 2014, at 15:54, Lo?c Hoguin wrote: > >> Could you elaborate on what the dominant usage of JSON is? > > Certainly. > > JSON is used for data interchange between applications or within components of an application. It's a terrible format for doing the above. * It's text-based, meaning it's incredibly slow to parse. * It has to be valid UTF-8, meaning it's incredibly slow to validate. * Its numbers representation is double-precision floating-point, meaning it's incredibly imprecise and limited. These are the three main reasons why I avoid JSON. There are numerous others I'm sure. I'm sure everyone has heard horror stories. Side note: I do not understand how so many programmers can identify themselves as pro-environment and then waste so much energy and resources by parsing these ridiculously bad formats and protocols. Stop using JSON, save the planet! Another criticism I have for it with regards to the Web specifically is the lack of hypertext, which in turn makes it harder to design a proper REST service. Most APIs seem to decide on a convention for identifying links (like _link keys), and that convention must also be hardcoded into clients that use it, and isn't common to all services. That's pretty bad. You still can be RESTful, but only with the help of something heavy like RSDL, which is probably worse than just not being RESTful. I do not have a magical format to propose to replace it (I tend to go with msgpack, but it also has its issues, though not as many as JSON) but perhaps I should work on it soon in preparation for my EUC talk. I'm on the edge of off-topic there, so I'll stop this comment there. -- Lo?c Hoguin http://ninenines.eu From bino@REDACTED Fri Mar 14 03:14:58 2014 From: bino@REDACTED (bino@REDACTED) Date: Fri, 14 Mar 2014 10:14:58 +0800 Subject: [erlang-questions] trying to run RabbitMQ on RB411 Message-ID: Dear All I try to compile and run RabbitMQ in OpenWRT on RouterBoard411. My step is 1. Download rabbitmq Source, and compile it per http://wiki.openwrt.org/doc/devel/crosscompile 2. Download rabbitmq 'Generix-linux' and extract to another directory 3. Replace sub directory 'ebin' and 'plugins' of #2 from same-sub-directories of #1. 4. scp #2 (with new content) to my Openwrt. 5. run rabbitMQ on my openwrt per http://www.rabbitmq.com/install-generic-unix.html 6. Results : a. I got console error report : ---------------- root@REDACTED:~/generic01# sbin/rabbitmq-server {error_logger,{{2014,3,13},{14,43,17}},"Error when reading /root/.erlang.cookie: einval",[]} {error_logger,{{2014,3,13},{14,43,17}},crash_report,[[{initial_call,{auth,init,['Argument__} {error_logger,{{2014,3,13},{14,43,17}},supervisor_report,[{supervisor,{local,net_sup}},{err} {error_logger,{{2014,3,13},{14,43,17}},supervisor_report,[{supervisor,{local,kernel_sup}},{} {error_logger,{{2014,3,13},{14,43,17}},crash_report,[[{initial_call,{application_master,ini} {error_logger,{{2014,3,13},{14,43,17}},std_info,[{application,kernel},{exited,{{shutdown,{f} {"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{{shutdo} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,kernel,{{shutdowc ---------------- b. I check /root/.erlang.cookie , and content is : XHTCCBNIPSPCMPJQZIGF c. I check the mnesia dir (/root/generic01/var/lib/mnesia), and got : root@REDACTED:~# ls ./generic01/var/lib/rabbitmq/mnesia/ rabbit@REDACTED root@REDACTED:~# cat ./generic01/var/lib/rabbitmq/mnesia/rabbit@REDACTED 1763 I post the erl_crash.dump at http://pastebin.com/wgarGEy4 Kindly please tell me what to look for , and/or how to fix it ? Sincerely -bino- From cabo@REDACTED Fri Mar 14 08:41:00 2014 From: cabo@REDACTED (Carsten Bormann) Date: Fri, 14 Mar 2014 08:41:00 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <5322569A.8010600@ninenines.eu> References: <5322569A.8010600@ninenines.eu> Message-ID: <635FF308-A167-44AA-8B3D-7126A16F144C@tzi.org> On 14 Mar 2014, at 02:08, Lo?c Hoguin wrote: > On 03/13/2014 09:16 PM, Carsten Bormann wrote: >> On 10 Mar 2014, at 15:54, Lo?c Hoguin wrote: >> >>> Could you elaborate on what the dominant usage of JSON is? >> >> Certainly. >> >> JSON is used for data interchange between applications or within components of an application. > > It's a terrible format for doing the above. > > * It's text-based, meaning it's incredibly slow to parse. The encoding/parsing overhead is in the noise for many JSON applications. But yes, other applications exist (hint: RFC 7049). > * It has to be valid UTF-8, meaning it's incredibly slow to validate. Well? either the application needs text, in which case UTF-8 is the right way to encode it, or it doesn?t, in which case the point is moot. > * Its numbers representation is double-precision floating-point, meaning it's incredibly imprecise and limited. JSON provides unlimited precision decimal floating point; it?s up to you what you do with that. (Yes, most JSON implementations translate non-integers into IEEE 754 binary64; JavaScript even makes a point that that?s the only numeric format in that language even for integers. The use of binary64 in libraries is just a reflection of the way floating-point is used in much of the industry.) > These are the three main reasons why I avoid JSON. There are numerous others I'm sure. I'm sure everyone has heard horror stories. While there may be horror stories around JSON*), overall the interoperability record of JSON is stellar. The main reason programmers use JSON is that it is a one-liner solution to a problem that could require a lot of effort otherwise. > Side note: I do not understand how so many programmers can identify themselves as pro-environment and then waste so much energy and resources by parsing these ridiculously bad formats and protocols. Stop using JSON, save the planet! (In the Internet of Things, where we have to care much more about energy, this is a valid concern. Did I mention RFC 7049?) I like your comments about RESTfulness; this is indeed a major issue usually solved in rather ad-hoc ways. This area needs work (RFC 7049 on its own doesn't help much, either; at least it offers tag 32). oOo None of this takes away from my point that, in 2014, to interoperate you need to speak JSON. Gr??e, Carsten *) An amusing one for this community: https://dev.twitter.com/docs/twitter-ids-json-and-snowflake Yes, an integer range issue :-) From bchesneau@REDACTED Fri Mar 14 08:56:35 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Fri, 14 Mar 2014 08:56:35 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: So I am curious in what could replace json today as an interoperable exchange data format. Message pack is interesting but not sure it's a good one (no type support). Any idea? - benoit On Fri, Mar 14, 2014 at 12:57 AM, Anthony Ramine wrote: > Where is the scientific study that proves this? > > Or is that just your personal experience? > > -- > Anthony Ramine > > Le 13 mars 2014 ? 21:16, Carsten Bormann a ?crit : > >> On 10 Mar 2014, at 15:54, Lo?c Hoguin wrote: >> >>> Could you elaborate on what the dominant usage of JSON is? >> >> Certainly. >> >> JSON is used for data interchange between applications or within components of an application. >> >> The most extensive use is from JavaScript-based Web application front-ends (running in the browser) to their backends (running on a server) and back; these are shipped as application/json representations in AJAX accesses (HTTP access from JavaScript via the confusingly named XMLHttpRequest object). >> >> Many Web APIs that have been designed in the last half decade are described in JSON form, so applications that access another application via a Web API are likely to ship back and forth application/json representations via HTTP accesses. >> >> Gr??e, Carsten >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From kxepal@REDACTED Fri Mar 14 09:04:56 2014 From: kxepal@REDACTED (Alexander Shorin) Date: Fri, 14 Mar 2014 12:04:56 +0400 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: On Fri, Mar 14, 2014 at 11:56 AM, Benoit Chesneau wrote: > So I am curious in what could replace json today as an interoperable > exchange data format. Message pack is interesting but not sure it's a > good one (no type support). Any idea? How about EDN? https://github.com/edn-format/edn -- ,,,^..^,,, From ph@REDACTED Fri Mar 14 09:38:54 2014 From: ph@REDACTED (Pieter Hintjens) Date: Fri, 14 Mar 2014 09:38:54 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: When you judge an encoding like JSON you're weighing simplicity of use against efficiency. For messages you send a few times a second, at most, text encoding costs are irrelevant. The big advantage of JSON, like XML and YAML, is the ability to extend contracts experimentally and cheaply. In comparison, any binary format raises steep costs for change, creating absurd incompatibility that has no benefit. The OpenStack RPC API being a good example of this. One answer I've used with success is the "Cheap and Nasty" pattern, where slow-changing high-volume data uses a binary encoding, and fast-changing low-volume data uses JSON, XML, or similar. By forcing protocols into these extremes you can win both games. Using a single approach for the two cases creates mediocrity, in my experience. Thus mspack, protobufs, etc. are poor choices either way. What this comes to is, often, a protocol message split into binary fields that are extremely tuned and fast to parse, plus optionally, an extensible hash or JSON document or similar. We've built a toolkit for this, zeromq/zproto, which is simple and efficient. Loic is right that lack of URLs in JSON makes it harder to use for RESTful work, however that's trivially solved by defining URLs explicitly. Then you can do very nice RESTful work without caring what encoding you use. E.g. https://github.com/UnifyProject/RFC/blob/master/draft/rfc-2.md tl;dr use the best tool for the job, no single encoding can solve all use cases. -Pieter On Fri, Mar 14, 2014 at 8:56 AM, Benoit Chesneau wrote: > So I am curious in what could replace json today as an interoperable > exchange data format. Message pack is interesting but not sure it's a > good one (no type support). Any idea? > > - benoit > > On Fri, Mar 14, 2014 at 12:57 AM, Anthony Ramine wrote: >> Where is the scientific study that proves this? >> >> Or is that just your personal experience? >> >> -- >> Anthony Ramine >> >> Le 13 mars 2014 ? 21:16, Carsten Bormann a ?crit : >> >>> On 10 Mar 2014, at 15:54, Lo?c Hoguin wrote: >>> >>>> Could you elaborate on what the dominant usage of JSON is? >>> >>> Certainly. >>> >>> JSON is used for data interchange between applications or within components of an application. >>> >>> The most extensive use is from JavaScript-based Web application front-ends (running in the browser) to their backends (running on a server) and back; these are shipped as application/json representations in AJAX accesses (HTTP access from JavaScript via the confusingly named XMLHttpRequest object). >>> >>> Many Web APIs that have been designed in the last half decade are described in JSON form, so applications that access another application via a Web API are likely to ship back and forth application/json representations via HTTP accesses. >>> >>> Gr??e, Carsten >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From jesper.louis.andersen@REDACTED Fri Mar 14 10:52:46 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 14 Mar 2014 10:52:46 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: Yes, EDN is an interesting format. But don't forget data.fressian, UBF and ASN.1 BER/DER which are nice formats as well. No encoding format can rule them all it seems. But certainly, the world is relying far too much on JSON as it stands right now. On Fri, Mar 14, 2014 at 9:04 AM, Alexander Shorin wrote: > On Fri, Mar 14, 2014 at 11:56 AM, Benoit Chesneau > wrote: > > So I am curious in what could replace json today as an interoperable > > exchange data format. Message pack is interesting but not sure it's a > > good one (no type support). Any idea? > > How about EDN? > https://github.com/edn-format/edn > > -- > ,,,^..^,,, > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Fri Mar 14 11:03:57 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Fri, 14 Mar 2014 11:03:57 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: On Fri, Mar 14, 2014 at 10:52 AM, Jesper Louis Andersen wrote: > Yes, EDN is an interesting format. > > But don't forget data.fressian, UBF and ASN.1 BER/DER which are nice formats > as well. > > No encoding format can rule them all it seems. But certainly, the world is > relying far too much on JSON as it stands right now. > > I didn't know about fressian, is there any Erlang implementation? ASN.1 requires a schema which make it really different from the JSON usage imo. What would be cool at least is having a format that correctly handle numbers and binary types instead of considering everything as string. Also a simple way to decode json in a straming fashion. - benoit > On Fri, Mar 14, 2014 at 9:04 AM, Alexander Shorin wrote: >> >> On Fri, Mar 14, 2014 at 11:56 AM, Benoit Chesneau >> wrote: >> > So I am curious in what could replace json today as an interoperable >> > exchange data format. Message pack is interesting but not sure it's a >> > good one (no type support). Any idea? >> >> How about EDN? >> https://github.com/edn-format/edn >> >> -- >> ,,,^..^,,, >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > > -- > J. From essen@REDACTED Fri Mar 14 11:10:25 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 14 Mar 2014 11:10:25 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <635FF308-A167-44AA-8B3D-7126A16F144C@tzi.org> References: <5322569A.8010600@ninenines.eu> <635FF308-A167-44AA-8B3D-7126A16F144C@tzi.org> Message-ID: <5322D591.2070600@ninenines.eu> On 03/14/2014 08:41 AM, Carsten Bormann wrote: > On 14 Mar 2014, at 02:08, Lo?c Hoguin wrote: > >> On 03/13/2014 09:16 PM, Carsten Bormann wrote: >>> On 10 Mar 2014, at 15:54, Lo?c Hoguin wrote: >>> >>>> Could you elaborate on what the dominant usage of JSON is? >>> >>> Certainly. >>> >>> JSON is used for data interchange between applications or within components of an application. >> >> It's a terrible format for doing the above. >> >> * It's text-based, meaning it's incredibly slow to parse. > > The encoding/parsing overhead is in the noise for many JSON applications. 99% of applications just spend their resources doing irrelevant stuff, JSON only being one of them. In Erlang JSON tends to be the one thing that will eat your CPU, remove JSON and your nodes basically do nothing CPU-wise, and still handle connection and logic for thousands of users with little footprint. So I guess I can also say: Use Erlang, save the planet! > But yes, other applications exist (hint: RFC 7049). I wouldn't classify it as interoperable as it seems to be missing a number of implementations (Erlang being one). To be honest I'm not sure how a format can be considered interoperable if it's not possible to generate an encoder/decoder for any language from a machine-readable spec. But maybe that's just me. Interoperability and relying on the implementor to do the right thing don't really go hand in hand. > The main reason programmers use JSON is that it is a one-liner solution to a problem that could require a lot of effort otherwise. Sure, but any serialization is a one-liner solution. I don't see your point there. > None of this takes away from my point that, in 2014, to interoperate you need to speak JSON. To consume foreign data you need JSON sure, but you can use other formats in your own service and still be interoperable. And perhaps if enough people do it things will change for the better. -- Lo?c Hoguin http://ninenines.eu From solomon.wzs@REDACTED Fri Mar 14 11:21:52 2014 From: solomon.wzs@REDACTED (Solomon) Date: Fri, 14 Mar 2014 18:21:52 +0800 Subject: [erlang-questions] what is the format of disk_log Message-ID: Hi, I want to read the disk_log by C, but I don't know the format of disk_log. Is there any documents about this? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maruthavanan_s@REDACTED Fri Mar 14 12:00:28 2014 From: maruthavanan_s@REDACTED (Maruthavanan Subbarayan) Date: Fri, 14 Mar 2014 07:00:28 -0400 Subject: [erlang-questions] Common test and application version Message-ID: Hi, I have an Erlang Application and I write all it its test SUITES in directory named test at the project directory, I have the app.src file in "src" folder which contains the a version attribute "{vsn, "0.1"}", So when ever I run the common test, I would like common test to log in test results with what was the version the test was performed. I could figure out the option "-label" in ct run where I can pass the version but I have to program some code that would take version number and passed it as argument and I also doubt whether rebar would support this label? I am curious on how community handles this kind of situation or is there something which is simple that I am missing out? Thanks in advance,Marutha -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Fri Mar 14 12:53:25 2014 From: rtrlists@REDACTED (Robert Raschke) Date: Fri, 14 Mar 2014 11:53:25 +0000 Subject: [erlang-questions] what is the format of disk_log In-Reply-To: References: Message-ID: Hi Solomon, I assume you've read http://www.erlang.org/doc/man/disk_log.html , and that you're trying to read a log written in internal format. In that case, you'll want to verify how the log is written by the disk_log code. As the documentation states it is repairable, my guess is that it is probably binary terms with additional housekeeping. I had a quick peek at the code and, unfortunately, it doesn't look easy to figure out the exact format. It is binary terms, but the housekeeping values elude me. :-( With external format, it's up to the logger to define the format. Thus much easier to handle. Sorry, can't be of more help. Regards, Robby On Mar 14, 2014 10:21 AM, "Solomon" wrote: > Hi, > > I want to read the disk_log by C, but I don't know the format of disk_log. > Is there any documents about this? > > Thanks. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Mar 14 12:55:45 2014 From: erlang@REDACTED (Joe Armstrong) Date: Fri, 14 Mar 2014 12:55:45 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: On Fri, Mar 14, 2014 at 9:38 AM, Pieter Hintjens wrote: > When you judge an encoding like JSON you're weighing simplicity of use > against efficiency. For messages you send a few times a second, at > most, text encoding costs are irrelevant. The big advantage of JSON, > like XML and YAML, is the ability to extend contracts experimentally > and cheaply. In comparison, any binary format raises steep costs for > change, creating absurd incompatibility that has no benefit. The > OpenStack RPC API being a good example of this. > > One answer I've used with success is the "Cheap and Nasty" pattern, > where slow-changing high-volume data uses a binary encoding, and > fast-changing low-volume data uses JSON, XML, or similar. By forcing > protocols into these extremes you can win both games. Using a single > approach for the two cases creates mediocrity, in my experience. Thus > mspack, protobufs, etc. are poor choices either way. > Good point. I think people "understand" JSON on two levels - at one level of understanding JSON is "easy" - in this mindset encodings etc. multiple keys etc are irrelevant. To an implementor of a library JSON is complicated. When I think of *implementing* JSON<->Erlang maps My hair goes even greyer. I think: 1) does a floating point number survive a round-trip from erlang -> JSON -> Erlang is it "bit identical" after the round trip? - why does this matter? - well it might just matter - I might want to cache the result or compute a SHA1 from it. 2) Do I have to worry about filling the erlang atom table? 3) Do I have to handle "infinite"JSON streams (for some meaning of "infinite") 4) Do want parse trees, or a SAX like interface 5) Do I want pure erlang or a NIF (the NIF might crash erlang) Now suppose there are two answers to each question. That's 2^5 implementations. That's why there are multiple libraries - they make different design choices. It's also extremely confusing to a beginner since the different design choices are not clearly stated - I find the choice of libraries difficult for just this reason, they all appear to do the same thing. A user of a JSON library would by now be crying out loud - "just give me a ****ing library - all I want to do is parse this JSON that I have in a file. This is what most libraries do - they work 99% of the time. (( the 99% is horrible - just when I think a library is great I find - *but I can't do X* then I'm in trouble - but I guess this is in the nature of the beast - only pure mathematical functions have the kind of "platonic interfaces" that will never change - real world problems with time and space involved are just plain messy )) If we freeze the JSON design and say: 1) floating point number will not survive a round-trip 2) JSON tags will be erlang atoms 3) Terms are not-infinite and rather small (few MB at max) 4) we want a parse tree 5) best effort at sorting out character set encodings 6) Pure erlang Then the problem becomes "easy" and can be knocked out in a few lies of code using maps:from_list and maps:to_list. And *because* it's easy nobody writes a library to do this. The trouble is a beginner probably does not find this easy and would appreciate a library that worked 99% of the time on simple problems. I watched DaveTomas and Jose Valim's Erlang factory lecture where they criticised Erlang for not having simple ways of doing common things. I think they were right. I think we to make some simple ways to solve common problems. The problem is simple things are very difficult to invent. I think we need a "otp subset" and "library subset" that is designed for beginners. Cheers /Joe > > What this comes to is, often, a protocol message split into binary > fields that are extremely tuned and fast to parse, plus optionally, an > extensible hash or JSON document or similar. > > We've built a toolkit for this, zeromq/zproto, which is simple and > efficient. > > Loic is right that lack of URLs in JSON makes it harder to use for > RESTful work, however that's trivially solved by defining URLs > explicitly. Then you can do very nice RESTful work without caring what > encoding you use. > > E.g. https://github.com/UnifyProject/RFC/blob/master/draft/rfc-2.md > > tl;dr use the best tool for the job, no single encoding can solve all use > cases. > > -Pieter > > > On Fri, Mar 14, 2014 at 8:56 AM, Benoit Chesneau > wrote: > > So I am curious in what could replace json today as an interoperable > > exchange data format. Message pack is interesting but not sure it's a > > good one (no type support). Any idea? > > > > - benoit > > > > On Fri, Mar 14, 2014 at 12:57 AM, Anthony Ramine > wrote: > >> Where is the scientific study that proves this? > >> > >> Or is that just your personal experience? > >> > >> -- > >> Anthony Ramine > >> > >> Le 13 mars 2014 ? 21:16, Carsten Bormann a ?crit : > >> > >>> On 10 Mar 2014, at 15:54, Lo?c Hoguin wrote: > >>> > >>>> Could you elaborate on what the dominant usage of JSON is? > >>> > >>> Certainly. > >>> > >>> JSON is used for data interchange between applications or within > components of an application. > >>> > >>> The most extensive use is from JavaScript-based Web application > front-ends (running in the browser) to their backends (running on a server) > and back; these are shipped as application/json representations in AJAX > accesses (HTTP access from JavaScript via the confusingly named > XMLHttpRequest object). > >>> > >>> Many Web APIs that have been designed in the last half decade are > described in JSON form, so applications that access another application via > a Web API are likely to ship back and forth application/json > representations via HTTP accesses. > >>> > >>> Gr??e, Carsten > >>> > >> > >> _______________________________________________ > >> erlang-questions mailing list > >> erlang-questions@REDACTED > >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ph@REDACTED Fri Mar 14 13:09:48 2014 From: ph@REDACTED (Pieter Hintjens) Date: Fri, 14 Mar 2014 13:09:48 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: On Fri, Mar 14, 2014 at 12:55 PM, Joe Armstrong wrote: > To an implementor of a library JSON is complicated. > When I think of *implementing* JSON<->Erlang maps My hair goes even greyer. Absolutely. I've looked at using JSON several times in my protocols, and each time it's... ugh... the only place I'm doing this now is for detailed resource specifications, in that XRAP RESTful protocol. There, a self-describing structure makes sense. XML, JSON, YAML, etc. all good. What is simple to implement, and useful for 90% of the cheap/nasty contracts I've seen, are binary serialization for lists and hashes. It's simple to do, efficient, and a map gives excellent space for experimentation. Like HTTP headers, for example. I'd probably go as far as saying, JSON encoding/decoding is an application issue and should never be an infrastructure decision. Like XML, YAML, or any other document format. Applications can be slow and stupid, that is how they make profit. Infrastructure cannot. Which brings us to a three-piece dance for protocols / contracts: * tight binary encoding for rarely-changing fields * an extensible map or maps for experimentation * when needed, a content (type and blob) that contains document data Where the infrastructure delivers the last part but never opens it. -Pieter From cabo@REDACTED Fri Mar 14 13:58:35 2014 From: cabo@REDACTED (Carsten Bormann) Date: Fri, 14 Mar 2014 13:58:35 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: > 1) does a floating point number survive a round-trip from erlang -> JSON -> Erlang > is it "bit identical" after the round trip? - why does this matter? - well it > might just matter - I might want to cache the result or compute a SHA1 from it. Yes, and that is not hard to do if you already can print and read floating point numbers. > 2) Do I have to worry about filling the erlang atom table? Not with default parameters. (EEP-18 has an option to control what happens with object keys, and I think that is prudent.) > 3) Do I have to handle "infinite"JSON streams (for some meaning of "infinite?) No. ?Streaming? is much more application specific, so it makes more sense to have to use an application-specific library for this. > 4) Do want parse trees, or a SAX like interface Parse trees (see above). > 5) Do I want pure erlang or a NIF (the NIF might crash erlang) That can change over time (start with pure Erlang). > [?] > I watched DaveTomas and Jose Valim's Erlang factory lecture where > they criticised Erlang for not having simple ways of doing common things. > > I think they were right. _!_ > The problem is simple things are very difficult to invent. It seems to me EEP-18 already did most of the work here. Gr??e, Carsten From steven.charles.davis@REDACTED Fri Mar 14 14:46:39 2014 From: steven.charles.davis@REDACTED (Steve Davis) Date: Fri, 14 Mar 2014 06:46:39 -0700 (PDT) Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: What about "Bert"? http://bert-rpc.org /s On Friday, March 14, 2014 2:56:35 AM UTC-5, Benoit Chesneau wrote: > > So I am curious in what could replace json today as an interoperable > exchange data format. Message pack is interesting but not sure it's a > good one (no type support). Any idea? > > - benoit > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ali.sabil@REDACTED Fri Mar 14 15:40:36 2014 From: ali.sabil@REDACTED (Ali Sabil) Date: Fri, 14 Mar 2014 15:40:36 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: On Fri, Mar 14, 2014 at 12:55 PM, Joe Armstrong wrote: > > > > On Fri, Mar 14, 2014 at 9:38 AM, Pieter Hintjens wrote: > >> When you judge an encoding like JSON you're weighing simplicity of use >> against efficiency. For messages you send a few times a second, at >> most, text encoding costs are irrelevant. The big advantage of JSON, >> like XML and YAML, is the ability to extend contracts experimentally >> and cheaply. In comparison, any binary format raises steep costs for >> change, creating absurd incompatibility that has no benefit. The >> OpenStack RPC API being a good example of this. >> >> One answer I've used with success is the "Cheap and Nasty" pattern, >> where slow-changing high-volume data uses a binary encoding, and >> fast-changing low-volume data uses JSON, XML, or similar. By forcing >> protocols into these extremes you can win both games. Using a single >> approach for the two cases creates mediocrity, in my experience. Thus >> mspack, protobufs, etc. are poor choices either way. >> > > > Good point. > > I think people "understand" JSON on two levels - at one level of > understanding > JSON is "easy" - in this mindset encodings etc. multiple keys etc are > irrelevant. > > To an implementor of a library JSON is complicated. > When I think of *implementing* JSON<->Erlang maps My hair goes even greyer. > > I think: > > 1) does a floating point number survive a round-trip from erlang -> > JSON -> Erlang > is it "bit identical" after the round trip? - why does this > matter? - well it > might just matter - I might want to cache the result or compute a > SHA1 from it. > 2) Do I have to worry about filling the erlang atom table? > 3) Do I have to handle "infinite"JSON streams (for some meaning of > "infinite") > 4) Do want parse trees, or a SAX like interface > 5) Do I want pure erlang or a NIF (the NIF might crash erlang) > > Now suppose there are two answers to each question. That's 2^5 > implementations. > > That's why there are multiple libraries - they make different design > choices. > > It's also extremely confusing to a beginner since the different design > choices > are not clearly stated - I find the choice of libraries difficult for just > this reason, > they all appear to do the same thing. > > A user of a JSON library would by now be crying out loud - "just give me > a ****ing library - all I want to do is parse this JSON that I have in a > file. > > This is what most libraries do - they work 99% of the time. > > (( the 99% is horrible - just when I think a library is great I find - > *but I can't do X* then > I'm in trouble - but I guess this is in the nature of the beast - only > pure mathematical > functions have the kind of "platonic interfaces" that will never > change - real > world problems with time and space involved are just plain messy )) > > If we freeze the JSON design and say: > > 1) floating point number will not survive a round-trip > 2) JSON tags will be erlang atoms > 3) Terms are not-infinite and rather small (few MB at max) > 4) we want a parse tree > 5) best effort at sorting out character set encodings > 6) Pure erlang > > Then the problem becomes "easy" and can be knocked out in a few lies of > code > using maps:from_list and maps:to_list. > > And *because* it's easy nobody writes a library to do this. > > The trouble is a beginner probably does not find this easy and would > appreciate > a library that worked 99% of the time on simple problems. > > I watched DaveTomas and Jose Valim's Erlang factory lecture where > they criticised Erlang for not having simple ways of doing common things. > > I think they were right. > > I think we to make some simple ways to solve common problems. > > The problem is simple things are very difficult to invent. > > I think we need a "otp subset" and "library subset" that is designed for > beginners. > > I think having something like OTP but focused around web technologies (http client+server, websocket, spdy, json, database connectors, email sending), would be very useful to help. > > Cheers > > /Joe > > >> >> What this comes to is, often, a protocol message split into binary >> fields that are extremely tuned and fast to parse, plus optionally, an >> extensible hash or JSON document or similar. >> >> We've built a toolkit for this, zeromq/zproto, which is simple and >> efficient. >> >> Loic is right that lack of URLs in JSON makes it harder to use for >> RESTful work, however that's trivially solved by defining URLs >> explicitly. Then you can do very nice RESTful work without caring what >> encoding you use. >> >> E.g. https://github.com/UnifyProject/RFC/blob/master/draft/rfc-2.md >> >> tl;dr use the best tool for the job, no single encoding can solve all use >> cases. >> >> -Pieter >> >> >> On Fri, Mar 14, 2014 at 8:56 AM, Benoit Chesneau >> wrote: >> > So I am curious in what could replace json today as an interoperable >> > exchange data format. Message pack is interesting but not sure it's a >> > good one (no type support). Any idea? >> > >> > - benoit >> > >> > On Fri, Mar 14, 2014 at 12:57 AM, Anthony Ramine >> wrote: >> >> Where is the scientific study that proves this? >> >> >> >> Or is that just your personal experience? >> >> >> >> -- >> >> Anthony Ramine >> >> >> >> Le 13 mars 2014 ? 21:16, Carsten Bormann a ?crit : >> >> >> >>> On 10 Mar 2014, at 15:54, Lo?c Hoguin wrote: >> >>> >> >>>> Could you elaborate on what the dominant usage of JSON is? >> >>> >> >>> Certainly. >> >>> >> >>> JSON is used for data interchange between applications or within >> components of an application. >> >>> >> >>> The most extensive use is from JavaScript-based Web application >> front-ends (running in the browser) to their backends (running on a server) >> and back; these are shipped as application/json representations in AJAX >> accesses (HTTP access from JavaScript via the confusingly named >> XMLHttpRequest object). >> >>> >> >>> Many Web APIs that have been designed in the last half decade are >> described in JSON form, so applications that access another application via >> a Web API are likely to ship back and forth application/json >> representations via HTTP accesses. >> >>> >> >>> Gr??e, Carsten >> >>> >> >> >> >> _______________________________________________ >> >> erlang-questions mailing list >> >> erlang-questions@REDACTED >> >> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ >> > erlang-questions mailing list >> > erlang-questions@REDACTED >> > http://erlang.org/mailman/listinfo/erlang-questions >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Mar 14 16:20:13 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 14 Mar 2014 08:20:13 -0700 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: <20140314152012.GA95455@ferdair.local> Hi Joe, I think the library you have described (does 99% of the work) is the equivalent of bait-and-switch at the language/library level: 1) it's not just a question of do floating point numbers survive the roadtrip, but also integers. 2) json tags are more or less strings and expect utf-8. Currently, we 'support' utf8 atoms but we don't. See http://www.erlang.org/erldoc?q=list_to_atom. This doesn't mention what you do in case of trying to encode a map which currently uses keys such as '1.0', 1.0, <<"1.0">>, and "1.0" at the same time. We currently have 4 data types that will possibly need an identical representation while being converted. Woops, that doesn't work super well and may in fact cover far less than 99% of the cases. We have to consider all the other cases such as just 1, 1.0, "1.00", "1.000", ..., and so on. 3) That can be made to work 4) No opinion on this one 5) This can also be read as "best effort not corrupting values read" which scares me a lot if the end result is not "raise an error when you can't figure it out reliably" 6) Amen to that. This doesn't even take into account the issue that by using atoms by default, you're actively using a source of memory leaks into the library. This guarantees that every tutorial out there will recommend not using the standard library for your tasks. What I'm getting at here is that while your scheme might work for 99% of possible JSON -> Erlang decodings, it will do so in a risky way that cannot be advocated. If you consider all the possible Erlang -> JSON mappings (and this is where the biggest problem always is), then it covers far, far less than 99% of the cases, because there is not one good way to do it (how do you even represent binaries that are not UTF-8 and distinguish them from actual strings? You validate the entire thing unless you want to create unparseable JSON). I used the words bait-and-switch and I mean it there. This is one of the points where Jose Valim and I disagree the most. I hate, absolutely hate solutions that bring you 70% of the way (to use a number we discussed between ourselves). Why? Because you start by learning the 70% solution and then it doesn't work. Suddenly you have to go out and look for the 99% and the 100% solutions out there. Except you now have a crusty code base full of legacy, and you start supporting, one, two libraries, which you never envisioned. And you find out you're married to encoders and decoders that decided to do things differently, but you just don't have the time to fix everything right now. You start seeing node crashes because someone decided atoms is a good way to receive unvalidated data without first having implemented a scheme to GC them (say EEP-20: http://www.erlang.org/eeps/eep-0020.html). You start being pretty angry that a language so focused on getting productions systems live has a standard library that lets you hang dry. Then you get even angrier when you figure out a crapload of frameworks in the wild all use that faulty function because it was in the standard library. Then you get certainly extremely angry and leave for Go or some other language when you figure out the community already had solutions to these problems in the year 2014 (and before!) but they were just overlooked because we wanted an easy JSON implementation in the stdlib. I can't for the life of me see the benefit of canonizing a bad library when tradeoffs are already known and worked around in the wild. What we should focus on is explaining these tradeoffs and making it easy to show the different options. Currently, picking a JSON lib is hard because there is such a very poor match between what you can possibly encode in Erlang and how you can translate this back and forth with JSON. Not just because it's not in the standard library. Not speaking about the problem doesn't make it go away, it makes it more surprising, which is not a desirable property. Regards, Fred. On 03/14, Joe Armstrong wrote: > This is what most libraries do - they work 99% of the time. > > (( the 99% is horrible - just when I think a library is great I find - *but > I can't do X* then > I'm in trouble - but I guess this is in the nature of the beast - only > pure mathematical > functions have the kind of "platonic interfaces" that will never change > - real > world problems with time and space involved are just plain messy )) > > If we freeze the JSON design and say: > > 1) floating point number will not survive a round-trip > 2) JSON tags will be erlang atoms > 3) Terms are not-infinite and rather small (few MB at max) > 4) we want a parse tree > 5) best effort at sorting out character set encodings > 6) Pure erlang > > Then the problem becomes "easy" and can be knocked out in a few lies of code > using maps:from_list and maps:to_list. > > And *because* it's easy nobody writes a library to do this. > > The trouble is a beginner probably does not find this easy and would > appreciate > a library that worked 99% of the time on simple problems. > > /Joe > From thomasl_erlang@REDACTED Fri Mar 14 18:04:43 2014 From: thomasl_erlang@REDACTED (Thomas Lindgren) Date: Fri, 14 Mar 2014 10:04:43 -0700 (PDT) Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <20140314152012.GA95455@ferdair.local> References: <20140314152012.GA95455@ferdair.local> Message-ID: <1394816683.57674.YahooMailNeo@web140105.mail.bf1.yahoo.com> Hey OTPeople, Since this comes up every now and then, does Ericsson have any plan to introduce atom garbage collection or suchlike in Erlang/OTP? Some official info would be great. Best, Thomas On Friday, March 14, 2014 4:20 PM, Fred Hebert wrote: Hi Joe, > >I think the library you have described (does 99% of the work) is the >equivalent of bait-and-switch at the language/library level: > >1) it's not just a question of do floating point numbers survive the >? roadtrip, but also integers. >2) json tags are more or less strings and expect utf-8. Currently, we >? 'support' utf8 atoms but we don't. See >? http://www.erlang.org/erldoc?q=list_to_atom. >? This doesn't mention what you do in case of trying to encode a map >? which currently uses keys such as '1.0', 1.0, <<"1.0">>, and "1.0" at >? the same time. We currently have 4 data types that will possibly need >? an identical representation while being converted. > >? Woops, that doesn't work super well and may in fact cover far less >? than 99% of the cases. We have to consider all the other cases such >? as just 1, 1.0, "1.00", "1.000", ..., and so on. > > >3) That can be made to work >4) No opinion on this one >5) This can also be read as "best effort not corrupting values read" >? which scares me a lot if the end result is not "raise an error when you can't >? figure it out reliably" >6) Amen to that. > >This doesn't even take into account the issue that by using atoms by >default, you're actively using a source of memory leaks into the >library. This guarantees that every tutorial out there will recommend >not using the standard library for your tasks. > >What I'm getting at here is that while your scheme might work for 99% of >possible JSON -> Erlang decodings, it will do so in a risky way that >cannot be advocated. > >If you consider all the possible Erlang -> JSON mappings (and this is >where the biggest problem always is), then it covers far, far less than >99% of the cases, because there is not one good way to do it (how do you >even represent binaries that are not UTF-8 and distinguish them from >actual strings? You validate the entire thing unless you want to create >unparseable JSON). > >I used the words bait-and-switch and I mean it there. This is one of the >points where Jose Valim and I disagree the most. > >I hate, absolutely hate solutions that bring you 70% of the way (to use >a number we discussed between ourselves). Why? Because you start by >learning the 70% solution and then it doesn't work. Suddenly you have to >go out and look for the 99% and the 100% solutions out there. > >Except you now have a crusty code base full of legacy, and you start >supporting, one, two libraries, which you never envisioned. And you find >out you're married to encoders and decoders that decided to do things >differently, but you just don't have the time to fix everything right >now. > >You start seeing node crashes because someone decided atoms is a good >way to receive unvalidated data without first having implemented a >scheme to GC them (say EEP-20: >http://www.erlang.org/eeps/eep-0020.html). > >You start being pretty angry that a language so focused on getting >productions systems live has a standard library that lets you hang dry. > >Then you get even angrier when you figure out a crapload of frameworks >in the wild all use that faulty function because it was in the standard >library. > >Then you get certainly extremely angry and leave for Go or some other >language when you figure out the community already had solutions to >these problems in the year 2014 (and before!) but they were just >overlooked because we wanted an easy JSON implementation in the stdlib. > >I can't for the life of me see the benefit of canonizing a bad library >when tradeoffs are already known and worked around in the wild. > >What we should focus on is explaining these tradeoffs and making it easy >to show the different options. Currently, picking a JSON lib is hard >because there is such a very poor match between what you can possibly >encode in Erlang and how you can translate this back and forth with >JSON. Not just because it's not in the standard library. > >Not speaking about the problem doesn't make it go away, it makes it more >surprising, which is not a desirable property. > >Regards, >Fred. > >On 03/14, Joe Armstrong wrote: > >> This is what most libraries do - they work 99% of the time. >> >> (( the 99% is horrible - just when I think a library is great I find - *but >> I can't do X* then >>? ? I'm in trouble - but I guess this is in the nature of the beast - only >> pure mathematical >>? ? functions have the kind of "platonic interfaces" that will never change >> - real >>? ? world problems with time and space involved are just plain messy )) >> >> If we freeze the JSON design and say: >> >>? ? 1) floating point number will not survive a round-trip >>? ? 2) JSON tags will be erlang atoms >>? ? 3) Terms are not-infinite and rather small (few MB at max) >>? ? 4) we want a parse tree >>? ? 5) best effort at sorting out character set encodings >>? ? 6) Pure erlang >> >> Then the problem becomes "easy" and can be knocked out in a few lies of code >> using maps:from_list and maps:to_list. >> >> And *because* it's easy nobody writes a library to do this. >> >> The trouble is a beginner probably does not find this easy and would >> appreciate >> a library that worked 99% of the time on simple problems. >> >> /Joe >> > >_______________________________________________ >erlang-questions mailing list >erlang-questions@REDACTED >http://erlang.org/mailman/listinfo/erlang-questions > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Fri Mar 14 20:06:18 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 14 Mar 2014 20:06:18 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <1394816683.57674.YahooMailNeo@web140105.mail.bf1.yahoo.com> References: <20140314152012.GA95455@ferdair.local> <1394816683.57674.YahooMailNeo@web140105.mail.bf1.yahoo.com> Message-ID: <826AB912-A85B-4310-8DDF-84B248BF8949@gmail.com> I have some code for EEP20, but I have to rebase it and adapt it to new Unicode atoms. https://github.com/nox/otp/tree/eep20 I kinda want to finish it for 18.0. -- Anthony Ramine Le 14 mars 2014 ? 18:04, Thomas Lindgren a ?crit : > Since this comes up every now and then, does Ericsson have any plan to introduce atom garbage collection or suchlike in Erlang/OTP? Some official info would be great. > From essen@REDACTED Fri Mar 14 20:07:32 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 14 Mar 2014 20:07:32 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <826AB912-A85B-4310-8DDF-84B248BF8949@gmail.com> References: <20140314152012.GA95455@ferdair.local> <1394816683.57674.YahooMailNeo@web140105.mail.bf1.yahoo.com> <826AB912-A85B-4310-8DDF-84B248BF8949@gmail.com> Message-ID: <53235374.8050707@ninenines.eu> On 03/14/2014 08:06 PM, Anthony Ramine wrote: > I have some code for EEP20, but I have to rebase it and adapt it to new Unicode atoms. > > https://github.com/nox/otp/tree/eep20 > > I kinda want to finish it for 18.0. Yes please! :) :( -- Lo?c Hoguin http://ninenines.eu From jose.valim@REDACTED Fri Mar 14 20:42:11 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Fri, 14 Mar 2014 12:42:11 -0700 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <20140314152012.GA95455@ferdair.local> References: <20140314152012.GA95455@ferdair.local> Message-ID: > > I used the words bait-and-switch and I mean it there. This is one of the > points where Jose Valim and I disagree the most. > Just to be clear: I was not advocating for bait-and-switch. I was not advocating for optimizing "hello world". I was/am advocating for providing "higher level abstractions" that are first proved to be useful in production. A direct consequence of having those is that it would provide more palpable abstractions for those getting started with the language. Point in case: one of the patterns proposed (the task pattern) *already* exists in OTP and is used in the OTP codebase itself. It is not an invention nor a bait-and-switch mechanism. I know you know it, as you were the one who pointed it out. :) > You start seeing node crashes because someone decided atoms is a good > way to receive unvalidated data without first having implemented a > scheme to GC them (say EEP-20: > http://www.erlang.org/eeps/eep-0020.html). This is happening not because a 70% solution was provided but because a very bad design decision was made i.e. using atoms for decoding unverified data by default. A 99% solution, whatever that would mean, would still be a horrible solution if that is the default behaviour. What we should focus on is explaining these tradeoffs and making it easy > to show the different options. Currently, picking a JSON lib is hard > because there is such a very poor match between what you can possibly > encode in Erlang and how you can translate this back and forth with > JSON. Not just because it's not in the standard library. > It should be clear to everyone that providing a built-in solution does not mean "we never get to talk about it, ever again". In fact, this is something the OTP documentation in general does pretty well: making it clear (with the green and red boxes) when something in particular must be used or avoided. Personally, I am against including JSON by default too. But arguing the reason to not include it is because someone can make a bad design decision or because it will automatically stop all discussion around the other solutions seems to be a very weak point against it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Fri Mar 14 20:53:36 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Fri, 14 Mar 2014 12:53:36 -0700 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <20140314152012.GA95455@ferdair.local> Message-ID: <20140314195336.GA96075@ferdair.local> On 03/14, Jos? Valim wrote: > Just to be clear: I was not advocating for bait-and-switch. I was not > advocating for optimizing "hello world". > > I was/am advocating for providing "higher level abstractions" that are > first proved to be useful in production. A direct consequence of having > those is that it would provide more palpable abstractions for those getting > started with the language. Point in case: one of the patterns proposed (the > task pattern) *already* exists in OTP and is used in the OTP codebase > itself. It is not an invention nor a bait-and-switch mechanism. > > I know you know it, as you were the one who pointed it out. :) > Right, I merged both topics at once -- I didn't mean to imply you were doing bait and switch, but that we disagreed on the 70% solution idea. I prefer a single more difficult 100% solution than having both a 70% solution that I have to unlearn to then get to the 100% one (at which point I'll have needed to learn two ways to get the same result, plus legacy code). I think it's worth making a bigger effort at the beginning if it means you don't end up duplicating work later on. People are free to disagree with me on that, however, and this isn't a topic that is objectively debatable as far as I can tell. I don't think either of us will move our positions on this and that's entirely fine. A JSON library the way Joe briefly described it is what would be bait and switch to me, because it has extremely deep pitfalls. (I also understand that this is a mailing list post where conciseness can be of use!) > It should be clear to everyone that providing a built-in solution does not > mean "we never get to talk about it, ever again". In fact, this is > something the OTP documentation in general does pretty well: making it > clear (with the green and red boxes) when something in particular must be > used or avoided. > > Personally, I am against including JSON by default too. But arguing the > reason to not include it is because someone can make a bad design decision > or because it will automatically stop all discussion around the other > solutions seems to be a very weak point against it. This gets harder with a strong commitment to backwards compatibility, which is one of the number one features of using Erlang for me. Code that worked yesterday will work tomorrow, except for exceptional circumstances which are announced a long time in advance anyway. If you're building a JSON library and that you have notices that say "please don't use it, we're only testing the waters", then why include it in the language *at all*? There are plenty of mature JSON libraries in the wild already. This is already work done, no need to repeat it an Nth time inside the language. I know you were talking in more general cases, and I'm a strong believer of evaluating context to make a decision. There are areas where it's definitely worth trying within Erlang (and the VM), but JSON just isn't one to me. Regards, Fred. From raould@REDACTED Fri Mar 14 20:59:20 2014 From: raould@REDACTED (Raoul Duke) Date: Fri, 14 Mar 2014 12:59:20 -0700 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <20140314195336.GA96075@ferdair.local> References: <20140314152012.GA95455@ferdair.local> <20140314195336.GA96075@ferdair.local> Message-ID: > I know you were talking in more general cases, and I'm a strong believer > of evaluating context to make a decision. There are areas where it's > definitely worth trying within Erlang (and the VM), but JSON just isn't > one to me. this sort of situation is never really resolvable as far as i have seen. consider naked ocaml vs. ocaml with batteries; consider the popularity of java in a large part due to the sdk; consider scala vs. scalaz; consider how many different ways there are to effing try to effing install any effing library in effing python. if you include stuff, you are making the language a lot more amenable to newbies, to greater adoption, even if what you end up with in the long run is java-esque poop. if you exclude stuff, you are making the language a lot less adoptable and possibly more fragmented all of which just pisses (at least some) people off and away from adopting the language. i guess if there were something like a non-core-erlang group that made their own "stack" for erlang, that would be a way to keep it outside the core, yet somehow "standardized". ? From n.oxyde@REDACTED Fri Mar 14 22:58:58 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 14 Mar 2014 22:58:58 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <20140314152012.GA95455@ferdair.local> Message-ID: EEP20 is a 99% solution to the atom overflow issue. But it is a 100% solution to the JSON object keys because no key would enter the atom table given they wouldn?t be used as process names or whatever fancy thing. -- Anthony Ramine Le 14 mars 2014 ? 20:42, Jos? Valim a ?crit : > A 99% solution, whatever that would mean, would still be a horrible solution if that is the default behaviour. From n.oxyde@REDACTED Fri Mar 14 23:03:20 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Fri, 14 Mar 2014 23:03:20 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <20140314152012.GA95455@ferdair.local> <20140314195336.GA96075@ferdair.local> Message-ID: Replied inline. -- Anthony Ramine Le 14 mars 2014 ? 20:59, Raoul Duke a ?crit : > this sort of situation is never really resolvable as far as i have > seen. consider naked ocaml vs. ocaml with batteries; consider the > popularity of java in a large part due to the sdk; consider scala vs. > scalaz; consider how many different ways there are to effing try to > effing install any effing library in effing python. > > if you include stuff, you are making the language a lot more amenable > to newbies, to greater adoption, even if what you end up with in the > long run is java-esque poop. How is that a good thing in the long run? > > > i guess if there were something like a non-core-erlang group that made > their own "stack" for erlang, that would be a way to keep it outside > the core, yet somehow "standardized ?. Well, anyone is free to try to make one. From raould@REDACTED Fri Mar 14 23:07:44 2014 From: raould@REDACTED (Raoul Duke) Date: Fri, 14 Mar 2014 15:07:44 -0700 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <20140314152012.GA95455@ferdair.local> <20140314195336.GA96075@ferdair.local> Message-ID: >> if you include stuff, you are making the language a lot more amenable >> to newbies, to greater adoption, even if what you end up with in the >> long run is java-esque poop. > > How is that a good thing in the long run? for the most part i concur with your comment. but it all depends, everything is subjective, e.g. the financial trading software people are possibly making a lot of money, using java poop. it is to cry. From essen@REDACTED Fri Mar 14 23:10:41 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 14 Mar 2014 23:10:41 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <20140314152012.GA95455@ferdair.local> <20140314195336.GA96075@ferdair.local> Message-ID: <53237E61.80607@ninenines.eu> On 03/14/2014 11:03 PM, Anthony Ramine wrote: > Replied inline. Which makes it hard to reply to since it's now part of your signature. :-) > How is that a good thing in the long run? The long run doesn't exist anymore. It's all only about the next quarter. Haven't you been following? -- Lo?c Hoguin http://ninenines.eu From essen@REDACTED Fri Mar 14 23:50:38 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Fri, 14 Mar 2014 23:50:38 +0100 Subject: [erlang-questions] monitor/2 Message-ID: <532387BE.8080908@ninenines.eu> Hello, I want to discuss monitor/2. It's been there for a while, and it's always taking 'process' as first argument. Any plans to add anything else? And if nothing is foreseen before the end of times, any plans to add a monitor/1 instead? Thanks. -- Lo?c Hoguin http://ninenines.eu From jinni.park@REDACTED Sat Mar 15 16:46:21 2014 From: jinni.park@REDACTED (Park, Sungjin) Date: Sun, 16 Mar 2014 00:46:21 +0900 Subject: [erlang-questions] monitor/2 In-Reply-To: <532387BE.8080908@ninenines.eu> References: <532387BE.8080908@ninenines.eu> Message-ID: Agreed, monitor(node, ...) should be there too. On Sat, Mar 15, 2014 at 7:50 AM, Lo?c Hoguin wrote: > Hello, > > I want to discuss monitor/2. > > It's been there for a while, and it's always taking 'process' as first > argument. Any plans to add anything else? And if nothing is foreseen before > the end of times, any plans to add a monitor/1 instead? > > Thanks. > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Park, Sungjin ------------------------------------------------------------------------------------------------------------------- Peculiar travel suggestions are dancing lessons from god. -- The Books of Bokonon ------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Sat Mar 15 16:58:22 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 15 Mar 2014 16:58:22 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: Message-ID: <5324789E.3000508@ninenines.eu> On 03/14/2014 12:55 PM, Joe Armstrong wrote: > 1) does a floating point number survive a round-trip from erlang > -> JSON -> Erlang > is it "bit identical" after the round trip? - why does this > matter? - well it > might just matter - I might want to cache the result or > compute a SHA1 from it. I'm not sure you can guarantee this if the encoding/decoding happens on different architectures, can you? Is a 64bit floating point number the same on Intel, AMD, ARM, GPUs, FPGAs and so on? -- Lo?c Hoguin http://ninenines.eu From cabo@REDACTED Sat Mar 15 17:17:17 2014 From: cabo@REDACTED (Carsten Bormann) Date: Sat, 15 Mar 2014 17:17:17 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <5324789E.3000508@ninenines.eu> References: <5324789E.3000508@ninenines.eu> Message-ID: On 15 Mar 2014, at 16:58, Lo?c Hoguin wrote: > On 03/14/2014 12:55 PM, Joe Armstrong wrote: >> 1) does a floating point number survive a round-trip from erlang >> -> JSON -> Erlang >> is it "bit identical" after the round trip? - why does this >> matter? - well it >> might just matter - I might want to cache the result or >> compute a SHA1 from it. > > I'm not sure you can guarantee this if the encoding/decoding happens on different architectures, can you? Is a 64bit floating point number the same on Intel, AMD, ARM, GPUs, FPGAs and so on? In the most general sense, no. However, in 2014, you can pretty much assume that floating point implementation in living CPUs complies with IEEE 754. Especially so with the format used for 32- and 64-bit floating point (binary32 and binary64 in IEEE 754). The IBM zSeries (was /360, /370, i.e. the "mainframe") is the only major remaining architecture that has a different 64-bit binary floating point format (?hexadecimal floating point?, it now also does support IEEE formats, and of course, it additionally features IEEE 754 decimal floating point, but that is a different animal). The Vax had its own formats, but that only lives on in the now also outdated Alpha. A few more architectures with pre-754 floating point formats only exist in emulation platforms now (Univac, anyone?). And, of course, all bets are off in special-purpose embedded hardware/DSPs. (Note that Erlang only seems to support part of IEEE 754 (no non-finites), and the minor differences that are found in partially-compliant embedded platforms often are in the support of non-finites only.) Gr??e, Carsten From dmkolesnikov@REDACTED Sat Mar 15 17:36:59 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Sat, 15 Mar 2014 18:36:59 +0200 Subject: [erlang-questions] monitor/2 In-Reply-To: References: <532387BE.8080908@ninenines.eu> Message-ID: <50DBF2DB-CAC2-4BAE-BE12-2973B7CABB80@gmail.com> and this would be a wrapper over monitor_nodes !? http://erlang.org/doc/man/net_kernel.html#monitor_nodes-1 I see a clear use-case to monitor a particular process and I see use-cases to monitor nodes, cluster memberships, etc. However, what would be purpose to do explicit node monitor? Best Regards, Dmitry >-|-|-(*> > On 15 Mar 2014, at 17:46, "Park, Sungjin" wrote: > > Agreed, monitor(node, ...) should be there too. > > > >> On Sat, Mar 15, 2014 at 7:50 AM, Lo?c Hoguin wrote: >> Hello, >> >> I want to discuss monitor/2. >> >> It's been there for a while, and it's always taking 'process' as first argument. Any plans to add anything else? And if nothing is foreseen before the end of times, any plans to add a monitor/1 instead? >> >> Thanks. >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > > > -- > Park, Sungjin > ------------------------------------------------------------------------------------------------------------------- > Peculiar travel suggestions are dancing lessons from god. > -- The Books of Bokonon > ------------------------------------------------------------------------------------------------------------------- > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Sat Mar 15 17:51:11 2014 From: lukas@REDACTED (Lukas Larsson) Date: Sat, 15 Mar 2014 17:51:11 +0100 Subject: [erlang-questions] monitor/2 In-Reply-To: <532387BE.8080908@ninenines.eu> References: <532387BE.8080908@ninenines.eu> Message-ID: On Fri, Mar 14, 2014 at 11:50 PM, Lo?c Hoguin wrote: > It's been there for a while, and it's always taking 'process' as first > argument. Any plans to add anything else? And if nothing is foreseen before the end of times, any plans to add a > monitor/1 instead? Yes, we plan to add erlang:monitor(port,#Port). There are no plans, that I know of, to introduce an erlang:monitor/1. Speaking of erlang:monitor, we have also been talking about adding a erlang:monitor/3 which would as a third argument take the identifier that you want to be sent back to the caller instead of the current reference. Is that something which could be useful to anyone? Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From freza@REDACTED Sat Mar 15 18:52:06 2014 From: freza@REDACTED (Jachym Holecek) Date: Sat, 15 Mar 2014 13:52:06 -0400 Subject: [erlang-questions] monitor/2 In-Reply-To: References: <532387BE.8080908@ninenines.eu> Message-ID: <20140315175206.GA26621@circlewave.net> # Lukas Larsson 2014-03-15: > Speaking of erlang:monitor, we have also been talking about adding a > erlang:monitor/3 which would as a third argument take the identifier that > you want to be sent back to the caller instead of the current reference. Is > that something which could be useful to anyone? Yes, that would be useful. Ideally "in addition to" rather than "instead of", if possible. BR, -- Jachym From essen@REDACTED Sat Mar 15 18:54:33 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Sat, 15 Mar 2014 18:54:33 +0100 Subject: [erlang-questions] monitor/2 In-Reply-To: References: <532387BE.8080908@ninenines.eu> Message-ID: <532493D9.8040200@ninenines.eu> On 03/15/2014 05:51 PM, Lukas Larsson wrote: > On Fri, Mar 14, 2014 at 11:50 PM, Lo?c Hoguin > wrote: > > It's been there for a while, and it's always taking 'process' as > first argument. Any plans to add anything else? > > And if nothing is foreseen before the end of times, any plans to add > a monitor/1 instead? > > > Yes, we plan to add erlang:monitor(port,#Port). There are no plans, that > I know of, to introduce an erlang:monitor/1. If port monitoring gets introduced then forget what I said about monitor/1. I just wouldn't want monitor/2 to stay the same forever if the first argument is never gonna be used. In what release port monitoring would land, presumably? > Speaking of erlang:monitor, we have also been talking about adding a > erlang:monitor/3 which would as a third argument take the identifier > that you want to be sent back to the caller instead of the current > reference. Is that something which could be useful to anyone? That does sound like something I could use, yes. The Gun HTTP client API (a few days from being public) creates a process per connection, and then each request on the connection gets a reference. If the user wants to do many requests on the same connection, then creating a separate reference for the monitor makes sense, however I could use what you propose when the user wants to do a single request and then close the connection, we can reuse the reference from the request in the monitor instead of creating two references. Doing it the other way (use the monitor ref as the request ref) would complicate the API, so that's not an option. -- Lo?c Hoguin http://ninenines.eu From tony@REDACTED Sun Mar 16 00:21:56 2014 From: tony@REDACTED (Tony Rogvall) Date: Sun, 16 Mar 2014 00:21:56 +0100 Subject: [erlang-questions] monitor/2 In-Reply-To: <532387BE.8080908@ninenines.eu> References: <532387BE.8080908@ninenines.eu> Message-ID: <2801035D-23E5-404D-93BD-648E1A9EF692@rogvall.se> I would like to see (and have been for a long time :): monitor(name, abc) -> reference() and then be able get notifications when the name abc is registered and unregistered. Then notifications could be something like: {'UP',Ref, name, Pid, abc } {'UP',Ref, name, Port, abc } {'DOWN', Ref, name, Pid, abc} {'DOWN', Ref, name, Port, abc} /Tony On 14 mar 2014, at 23:50, Lo?c Hoguin wrote: > Hello, > > I want to discuss monitor/2. > > It's been there for a while, and it's always taking 'process' as first argument. Any plans to add anything else? And if nothing is foreseen before the end of times, any plans to add a monitor/1 instead? > > Thanks. > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From nem@REDACTED Sun Mar 16 05:06:17 2014 From: nem@REDACTED (Geoff Cant) Date: Sat, 15 Mar 2014 21:06:17 -0700 Subject: [erlang-questions] monitor/2 In-Reply-To: <2801035D-23E5-404D-93BD-648E1A9EF692@rogvall.se> References: <532387BE.8080908@ninenines.eu> <2801035D-23E5-404D-93BD-648E1A9EF692@rogvall.se> Message-ID: This single change would eliminate a whole lot of book keeping that processes currently need to do. The more I think about it, the more uses I have for it. Maybe also erlang:monitors() -> [{Ref, What, UserData}]. To get the list of things you are currently monitoring? -Geoff On 2014-03-15, at 16:21 , Tony Rogvall wrote: > I would like to see (and have been for a long time :): > > monitor(name, abc) -> reference() > > and then be able get notifications when the name abc is registered and unregistered. > > Then notifications could be something like: > > {'UP',Ref, name, Pid, abc } > {'UP',Ref, name, Port, abc } > {'DOWN', Ref, name, Pid, abc} > {'DOWN', Ref, name, Port, abc} > > /Tony > > > On 14 mar 2014, at 23:50, Lo?c Hoguin wrote: > >> Hello, >> >> I want to discuss monitor/2. >> >> It's been there for a while, and it's always taking 'process' as first argument. Any plans to add anything else? And if nothing is foreseen before the end of times, any plans to add a monitor/1 instead? >> >> Thanks. >> >> -- >> Lo?c Hoguin >> http://ninenines.eu From alisdairsullivan@REDACTED Sun Mar 16 07:28:03 2014 From: alisdairsullivan@REDACTED (alisdair sullivan) Date: Sat, 15 Mar 2014 23:28:03 -0700 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <20140314152012.GA95455@ferdair.local> References: <20140314152012.GA95455@ferdair.local> Message-ID: <19C738FF-417F-405D-BA92-86BD1588689A@yahoo.ca> > > 1) it's not just a question of do floating point numbers survive the > roadtrip, but also integers. number roundtripping is ok if you are careful and control both encoding and decoding. it?s strings that are hard. first of all you have to either support lists of code points or some sort of encoded binaries (probably but not necessarily utf8) or you have zero hope of roundtripping losslessly. either ?hello world? and <> are both potentially decoded to the wrong term or you inject meta data like `"__encoding?: ?list?` to your json and pray no one else ever uses that key. even if you get that figured out you have a problem with escape sequences. ?hello\\u0020world? and ?hello world? encode differently but decode to the same string if you interpret escape sequences. if you don?t interpret escape sequences you have a new problem when you try to round trip ?hello\tworld? From mononcqc@REDACTED Sun Mar 16 19:33:46 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Sun, 16 Mar 2014 14:33:46 -0400 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <20140314152012.GA95455@ferdair.local> Message-ID: <20140316183340.GA13643@ferdair.local> Answers inline. On 03/16, cri wrote: > > To me, "Bait and switch" seems an unfair and inaccurate characterization. > Unfair due to the negative connotation and inaccurate, unless I am missing > something, because there is no implied "switch". > > the negative connotation is intended. As mention in my earlier emails, I *hate* having to learn a solution, only to discover it's an incomplete one, and then having to learn a new one again, while having the incomplete one everywhere in my code base. The 'switch' here is having me think you have this super elegant bit of code only to find out it's all a lie and that I have to use something else entirely to get the job done. > Isn't there a contradiction here? Either any JSON library is somehow bound > to hang me out to dry or an acceptable solution with trade-offs and and > workarounds is possible. > No single JSON library will do *everything*. Most of them have strings decoded as binaries, which eliminates the atoms case, but makes matching uglier and cannot have dialyzer analyze types the same way for example. Jsx can support both a streaming and a non-streaming API while being in regular Erlang, but will be slower than a library like Jiffy. Not all JSON libraries accept the same input format. The difference is that most workarounds and options aren't afforded through a single juggernaut library that does everything, but through many of them so that you can choose what to use. > It seems to me that the real question is whether JSON, even with its > imperfections, is so prevalent that a std library would be significantly > advantageous for Erlang developers. > My point is that a standard library version as the one Joe described would be extremely bad. Other libraries (say jsx) wouldn't be nearly as bad, but they would be favoring some use cases heavily over others. > I, being the Erlang novice that started this thread, wanted to use the once > imagined maps-to-json functions to convert my maps to json to store them in > mongo and vice versa. If this has been worked out in the wide, can I get a > reference? See https://github.com/talentdeficit/jsx/issues/49 for one example Again, be aware of the caveats mentioned in this here thread already. The object <--> JSON conversion tends to go without an issue, because it's relatively rare to have object attributes be other objects as a name (they'll tend to be values, which JSON can handle), for example. On the other hand, Erlang maps can have any term as a key, including other maps. It can also have any value, some that are not representable easily as strings and aren't covered by the JSON spec(s) (what's a pid?). One has to be aware that even if you have a maps:to_json/1 or maps:from_json/1 calls, it doesn't mean you could even convert most maps with it, even less get the same exact map back that you encoded first. The same goes for third party libraries, but at least, they don't have the surprising attribute of being part of a module (or library) they can't reliably convert. Just keep in mind that you're *translating* to JSON, and *translating* from JSON. Much like putting stuff through google translate back and forth, the results might be surprising. Regards, Fred. From tony@REDACTED Sun Mar 16 21:26:47 2014 From: tony@REDACTED (Tony Rogvall) Date: Sun, 16 Mar 2014 21:26:47 +0100 Subject: [erlang-questions] monitor/2 In-Reply-To: <2801035D-23E5-404D-93BD-648E1A9EF692@rogvall.se> References: <532387BE.8080908@ninenines.eu> <2801035D-23E5-404D-93BD-648E1A9EF692@rogvall.se> Message-ID: <81105AE4-EE8A-455F-973E-A51581ED682C@rogvall.se> On 16 mar 2014, at 00:21, Tony Rogvall wrote: > I would like to see (and have been for a long time :): > > monitor(name, abc) -> reference() > > and then be able get notifications when the name abc is registered and unregistered. > > Then notifications could be something like: > > {'UP',Ref, name, Pid, abc } > {'UP',Ref, name, Port, abc } > {'DOWN', Ref, name, Pid, abc} > {'DOWN', Ref, name, Port, abc} > A comment on my own suggestion: The following (ugly) code in user_sup.erl: wait_for_user_p(0) -> {error, nouser}; wait_for_user_p(N) -> case whereis(user) of Pid when is_pid(Pid) -> link(Pid), {ok, Pid}; _ -> receive after 100 -> ok end, wait_for_user_p(N-1) end. Could then be replace with: wait_for_user_p(N) -> Timeout = N*100, Ref = erlang:monitor(name, user), recieve {'UP', Ref, name, Pid, user} -> link(Pid), {ok, Pid} after Timeout -> {error, nouser} end . > /Tony > > > On 14 mar 2014, at 23:50, Lo?c Hoguin wrote: > >> Hello, >> >> I want to discuss monitor/2. >> >> It's been there for a while, and it's always taking 'process' as first argument. Any plans to add anything else? And if nothing is foreseen before the end of times, any plans to add a monitor/1 instead? >> >> Thanks. >> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf@REDACTED Sun Mar 16 22:08:45 2014 From: ulf@REDACTED (Ulf Wiger) Date: Sun, 16 Mar 2014 22:08:45 +0100 Subject: [erlang-questions] monitor/2 In-Reply-To: <81105AE4-EE8A-455F-973E-A51581ED682C@rogvall.se> References: <532387BE.8080908@ninenines.eu> <2801035D-23E5-404D-93BD-648E1A9EF692@rogvall.se> <81105AE4-EE8A-455F-973E-A51581ED682C@rogvall.se> Message-ID: <7E241EE3-96B1-457B-A38C-B47A7E97ED87@feuerlabs.com> Just as an aside, gproc now has extended monitoring functionality: https://github.com/uwiger/gproc/blob/master/doc/gproc.md#type-monitor_type monitor(Key::key(), Type::monitor_type()) -> reference() monitor_type() = info | standby | follow monitor a registered name monitor(Key, info) works much like erlang:monitor(process, Pid), but monitors a unique name registered via gproc. A message, {gproc, unreg, Ref, Key} will be sent to the requesting process, if the name is unregistered or the registered process dies. If there is a standby monitor (see below), a message {gproc, {failover, ToPid}, Ref, Key} is sent to all monitors. If the name is passed to another process using give_away/2, the event {gproc, {migrated, ToPid}, Ref, Key} is sent to all monitors. monitor(Key, standby) sets up the monitoring process as a standby for the registered name. If the registered process dies, the first standby process inherits the name, and a message {gproc, {failover, ToPid}, Ref, Key} is sent to all monitors, including the one that inherited the name. If the name is not yet registered, the unreg event is sent immediately. If the calling process in this case tried to start a standby monitoring, it receives the registered name and the failover event immediately. monitor(Key, follow) keeps monitoring the registered name even if it is temporarily unregistered. The messages received are the same as for the other monitor types, but {gproc, registered, Ref, Key} is also sent when a new process registers the name. BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Sun Mar 16 22:29:32 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Sun, 16 Mar 2014 22:29:32 +0100 Subject: [erlang-questions] monitor/2 In-Reply-To: <81105AE4-EE8A-455F-973E-A51581ED682C@rogvall.se> References: <532387BE.8080908@ninenines.eu> <2801035D-23E5-404D-93BD-648E1A9EF692@rogvall.se> <81105AE4-EE8A-455F-973E-A51581ED682C@rogvall.se> Message-ID: <44F5959A-E069-4540-A0B4-5368310945F5@gmail.com> This sounds like a good idea but with many edge cases. For starters, there lack a demonitor call with flush option set in the timeout clause. Then, from what I understand reading your snippet of code, I gather that the message is only sent once, right? What happens if I call monitor after the name was registered and wait for ?UP?? Or will it wait for the process to die and the name to be freed to send a ?DOWN?? In my opinion, this behaves in manner too different from process monitors to reuse the same function. -- Anthony Ramine Le 16 mars 2014 ? 21:26, Tony Rogvall a ?crit : > > On 16 mar 2014, at 00:21, Tony Rogvall wrote: > >> I would like to see (and have been for a long time :): >> >> monitor(name, abc) -> reference() >> >> and then be able get notifications when the name abc is registered and unregistered. >> >> Then notifications could be something like: >> >> {'UP',Ref, name, Pid, abc } >> {'UP',Ref, name, Port, abc } >> {'DOWN', Ref, name, Pid, abc} >> {'DOWN', Ref, name, Port, abc} >> > > A comment on my own suggestion: > > The following (ugly) code in user_sup.erl: > > wait_for_user_p(0) -> > {error, nouser}; > wait_for_user_p(N) -> > case whereis(user) of > Pid when is_pid(Pid) -> > link(Pid), > {ok, Pid}; > _ -> > receive after 100 -> ok end, > wait_for_user_p(N-1) > end. > > Could then be replace with: > > wait_for_user_p(N) -> > Timeout = N*100, > Ref = erlang:monitor(name, user), > recieve > {'UP', Ref, name, Pid, user} -> > link(Pid), > {ok, Pid} > after > Timeout -> > {error, nouser} > end . > > >> /Tony >> >> >> On 14 mar 2014, at 23:50, Lo?c Hoguin wrote: >> >>> Hello, >>> >>> I want to discuss monitor/2. >>> >>> It's been there for a while, and it's always taking 'process' as first argument. Any plans to add anything else? And if nothing is foreseen before the end of times, any plans to add a monitor/1 instead? >>> >>> Thanks. >>> >>> -- >>> Lo?c Hoguin >>> http://ninenines.eu >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From tony@REDACTED Mon Mar 17 02:07:09 2014 From: tony@REDACTED (Tony Rogvall) Date: Mon, 17 Mar 2014 02:07:09 +0100 Subject: [erlang-questions] monitor/2 In-Reply-To: <44F5959A-E069-4540-A0B4-5368310945F5@gmail.com> References: <532387BE.8080908@ninenines.eu> <2801035D-23E5-404D-93BD-648E1A9EF692@rogvall.se> <81105AE4-EE8A-455F-973E-A51581ED682C@rogvall.se> <44F5959A-E069-4540-A0B4-5368310945F5@gmail.com> Message-ID: <1F98D084-FB7A-4CFE-944A-0B67F80BA403@rogvall.se> On 16 mar 2014, at 22:29, Anthony Ramine wrote: > This sounds like a good idea but with many edge cases. > > For starters, there lack a demonitor call with flush option set in the timeout clause. > Thanks. Missed that one. > Then, from what I understand reading your snippet of code, I gather that the message is only sent once, right? > Well, then plan is/was that UP/DOWN messages are sent as long as the name monitor is till running. > What happens if I call monitor after the name was registered and wait for ?UP?? Or will it wait for the process to die and the name to be freed to send a ?DOWN?? In my opinion, this behaves in manner too different from process monitors to reuse the same function. > To get this to work (the way I want) one message must be sent when the monitor(name, x) is created to reflect the status of the name registration, DOWN or UP. The demonitor flush will then remove all messages matching the Ref. So for "multi shot" version the a demonitor flush is needed in both cases since a DOWN message may have been sent if the name was not registered at the creation of the monitor. wait_for_user_p(N) -> Timeout = N*100, Ref = erlang:monitor(name, user), recieve {'UP', Ref, name, Pid, user} -> link(Pid), erlang:demonitor(Ref, [flush]), {ok, Pid} after Timeout -> erlang:demonitor(Ref, [flush]), {error, nouser} end . And as you pointed out a "single shot" version could be simpler to understand and be more like the normal monitor. 'whereis' must then be called after the monitor has been started. The monitor will only send registration changes in this case. wait_for_user_p(N) -> Ref = erlang:monitor(name, user), case whereis(user) of Pid when is_pid(Pid) -> erlang:demonitor(Ref, [flush]), link(Pid), {ok, Pid}; _ -> Timeout = N*100, recieve {'UP', Ref, name, Pid, user} -> link(Pid), {ok, Pid} after Timeout -> erlang:demonitor(Ref, [flush]), {error, nouser} end end. I think that name monitors are not really like process or port monitors, where the death of a process or port naturally removes the monitor since there is nothing to monitor. The name however will of course continue to exist for ever. I do think that the "single shot" version could be acceptable since it solves the problem. /Tony > -- > Anthony Ramine > > Le 16 mars 2014 ? 21:26, Tony Rogvall a ?crit : > >> >> On 16 mar 2014, at 00:21, Tony Rogvall wrote: >> >>> I would like to see (and have been for a long time :): >>> >>> monitor(name, abc) -> reference() >>> >>> and then be able get notifications when the name abc is registered and unregistered. >>> >>> Then notifications could be something like: >>> >>> {'UP',Ref, name, Pid, abc } >>> {'UP',Ref, name, Port, abc } >>> {'DOWN', Ref, name, Pid, abc} >>> {'DOWN', Ref, name, Port, abc} >>> >> >> A comment on my own suggestion: >> >> The following (ugly) code in user_sup.erl: >> >> wait_for_user_p(0) -> >> {error, nouser}; >> wait_for_user_p(N) -> >> case whereis(user) of >> Pid when is_pid(Pid) -> >> link(Pid), >> {ok, Pid}; >> _ -> >> receive after 100 -> ok end, >> wait_for_user_p(N-1) >> end. >> >> Could then be replace with: >> >> wait_for_user_p(N) -> >> Timeout = N*100, >> Ref = erlang:monitor(name, user), >> recieve >> {'UP', Ref, name, Pid, user} -> >> link(Pid), >> {ok, Pid} >> after >> Timeout -> >> {error, nouser} >> end . >> >> >>> /Tony >>> >>> >>> On 14 mar 2014, at 23:50, Lo?c Hoguin wrote: >>> >>>> Hello, >>>> >>>> I want to discuss monitor/2. >>>> >>>> It's been there for a while, and it's always taking 'process' as first argument. Any plans to add anything else? And if nothing is foreseen before the end of times, any plans to add a monitor/1 instead? >>>> >>>> Thanks. >>>> >>>> -- >>>> Lo?c Hoguin >>>> http://ninenines.eu >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Mon Mar 17 02:52:08 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Mar 2014 14:52:08 +1300 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <20140314152012.GA95455@ferdair.local> References: <20140314152012.GA95455@ferdair.local> Message-ID: On 15/03/2014, at 4:20 AM, Fred Hebert wrote: > 1) it's not just a question of do floating point numbers survive the > roadtrip, but also integers. The first couple of times I read through Javascript tutorials and the ECMAscript specification, my expectation that any serious language would support integers was so strong that I completely failed to see that it doesn't. This must make life extremely "interesting" for people writing compilers that target Javascript. ... RFC 7159 is explicit: integers up to ?(2**53-1) can be expected to round-trip (probably, maybe) but no more. And they cannot be expected to round-trip *as* integers, but the values should (hopefully, arguably) survive. > 2) json tags are more or less strings and expect utf-8. Currently, we > 'support' utf8 atoms but we don't. See > http://www.erlang.org/erldoc?q=list_to_atom. > This doesn't mention what you do in case of trying to encode a map > which currently uses keys such as '1.0', 1.0, <<"1.0">>, and "1.0" at > the same time. We currently have 4 data types that will possibly need > an identical representation while being converted. > > Woops, that doesn't work super well and may in fact cover far less > than 99% of the cases. We have to consider all the other cases such > as just 1, 1.0, "1.00", "1.000", ..., and so on. JSON is not a format for preserving arbitrary Erlang maps. We can expect a JSON library that's map-aware to offer a function json:can_handle(Term) which will _reject_ any map where the keys are not - all atoms, or - all strings, or - all binaries that are valid as UTF-8. After all, there are other things (like process IDs, references, and functions) that don't translate to JSON. From ok@REDACTED Mon Mar 17 03:00:49 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Mon, 17 Mar 2014 15:00:49 +1300 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <5324789E.3000508@ninenines.eu> References: <5324789E.3000508@ninenines.eu> Message-ID: On 16/03/2014, at 4:58 AM, Lo?c Hoguin wrote: > > I'm not sure you can guarantee this if the encoding/decoding happens on different architectures, can you? Is a 64bit floating point number the same on Intel, AMD, ARM, GPUs, FPGAs and so on? There's an actively maintained standard. Apple have supported it on three different hardware platforms (M680x0, PowerPC, Intel). SPARC does it. HPPA and MIPS do it. Alpha does it. Even IBM mainframes, while still supporting their old format, offer IEEE-compliant arithmetic these days. Intel, AMD and ARM certainly support it. About the only machines you are likely to meet these days that _don't_ offer IEEE arithmetic are Unisys E-mode systems. (Well, there might be some VAXen somewhere I suppose.) As for FPGAs, they do whatever they are programmed to do. Some have been programmed to do IEEE arithmetic, some haven't. As for GPUs, they are why half-precision (16-bit) floats are in IEEE-754:2008. OpenCL says single-precision floats will be there, double precision might or might not, but they are expected to be IEEE-compliant. XDR mandated the use of IEEE formats. It's still around. From paul.joseph.davis@REDACTED Mon Mar 17 07:44:21 2014 From: paul.joseph.davis@REDACTED (Paul Davis) Date: Mon, 17 Mar 2014 02:44:21 -0400 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <5324789E.3000508@ninenines.eu> Message-ID: For extra nerdery on round-tripping floats one of the (historically) oft-requested enhancements for Jiffy was to print 1.1 as "1.1" instead of "1.10000000000000008882000000000000" which is always cumbersome. The standard Googling leads to dtoa.c which depends on processor rounding modes amongst other things. Luckily a lot of this was yanked from V8 into a usable library [1]. The rest of this conversation has wandered a bit too much for me to spend much time following. The basics I'd say are that if you want a fast value-based (DOM?) parser, use Jiffy. If you want a streaming (SAX?) or pure-erlang parser, use jsx. Alisdair and I have talked extensively about most minute details of JSON parsing and our libraries are about as close as they're gonna get in terms of API compatibility. If Erlang decides to choose one or the other one of us is gonna be happy and the other will be sad and have to rewrite a lot of code or not use the builtin. Though I'd point out that the builtin won't actually be "standard" until 3-5 years from now so its probably not a huge issue either way. And just because I haven't heard from Alisdair recently I have to point out that {[]} is still the One True Empty Object representation. [{}] is just atrocious. [1] https://code.google.com/p/double-conversion/ On Sun, Mar 16, 2014 at 10:00 PM, Richard A. O'Keefe wrote: > > On 16/03/2014, at 4:58 AM, Lo?c Hoguin wrote: >> >> I'm not sure you can guarantee this if the encoding/decoding happens on different architectures, can you? Is a 64bit floating point number the same on Intel, AMD, ARM, GPUs, FPGAs and so on? > > There's an actively maintained standard. > Apple have supported it on three different hardware platforms > (M680x0, PowerPC, Intel). SPARC does it. HPPA and MIPS do it. > Alpha does it. Even IBM mainframes, while still supporting > their old format, offer IEEE-compliant arithmetic these days. > Intel, AMD and ARM certainly support it. > > About the only machines you are likely to meet these days > that _don't_ offer IEEE arithmetic are Unisys E-mode systems. > (Well, there might be some VAXen somewhere I suppose.) > > As for FPGAs, they do whatever they are programmed to do. > Some have been programmed to do IEEE arithmetic, some haven't. > > As for GPUs, they are why half-precision (16-bit) floats > are in IEEE-754:2008. OpenCL says single-precision > floats will be there, double precision might or might not, > but they are expected to be IEEE-compliant. > > XDR mandated the use of IEEE formats. It's still around. > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From maruthavanan_s@REDACTED Mon Mar 17 07:51:23 2014 From: maruthavanan_s@REDACTED (Maruthavanan Subbarayan) Date: Mon, 17 Mar 2014 02:51:23 -0400 Subject: [erlang-questions] Edoc and application version Message-ID: Hi All, How can I make overview page generated by edoc, display my application version specified in application.app.src or application.app file? Thanks,Marutha -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinothsparrow@REDACTED Mon Mar 17 08:15:32 2014 From: vinothsparrow@REDACTED (Vinoth Kumar) Date: Mon, 17 Mar 2014 12:45:32 +0530 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? Message-ID: Does gen_tcp supports non-blocking send ?I have tried gen_tcp:send which returns the ok while the packets has not been sent to the receiver. Whether any mechanism in erlang to check the sent message delivary? Thanks,Vinoth Kumar J -------------- next part -------------- An HTML attachment was scrubbed... URL: From jozsef.berces@REDACTED Mon Mar 17 09:51:13 2014 From: jozsef.berces@REDACTED (=?iso-8859-1?Q?J=F3zsef_B=E9rces?=) Date: Mon, 17 Mar 2014 08:51:13 +0000 Subject: [erlang-questions] eheap cannot allocate for which process? Message-ID: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> I receive the classic "eheap_alloc: Cannot allocate..." message. It wants to allocate ~1GB memory and that fails. That is fine, I am doing something wrong. So I took the crash dump and tried to find out which one of my processes is the guilty one. Unfortunately, I cannot tell it from the crash dump. The memory section says: =memory total: 15447352528 processes: 15140232809 processes_used: 15140005610 system: 307119719 atom: 512601 atom_used: 496586 binary: 148574400 code: 21228007 ets: 119988984 I have 16GB RAM, so the processes use almost all. There are 4010 processes. 1 garbing, 31 scheduled, 3978 waiting. If I sum stack+heap of all the processes then I get ~700MB. That is very far from 16GB. Here are the top 10 stack+heap processes: Pid State Reductions Stack+heap MsgQ Length <0.21060.67> Garbing (limited info) 1,508,838,180 145,962,050 1 <0.25689.27> Waiting 86,670,344 145,962,050 0 <0.10003.68> Waiting 1,363,039 38,263,080 0 <0.15943.66> Waiting 1,882,465,380 30,610,465 0 <0.15879.68> Waiting 471,549 30,610,465 0 <0.31854.67> Waiting 154,500,777 24,488,375 0 <0.16221.68> Waiting 262,114 24,488,375 0 <0.16628.68> Waiting 117,268 24,488,375 0 <0.15878.68> Waiting 453,490 19,590,700 0 <0.16235.68> Waiting 181,968 19,590,700 0 Any ideas how to tell which process needs ~1GB memory? Thanks, Jozsef -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Mar 17 09:53:41 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 17 Mar 2014 12:53:41 +0400 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: Message-ID: It is a very, very dangerous practice, because you loose control over your program with non-blocking send. First step that you MUST do is setting send_timeout on socket. By default it is infinity and it means that your process may get blocked forever trying to push data. I don't know why infinity is a default value, it is really strange for me. Second, dangerous step is just using port_command(Socket, IoData). Then you must wait for messages from this socket. But don't use it =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Mar 17 10:28:37 2014 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 17 Mar 2014 10:28:37 +0100 Subject: [erlang-questions] monitor/2 In-Reply-To: <532493D9.8040200@ninenines.eu> References: <532387BE.8080908@ninenines.eu> <532493D9.8040200@ninenines.eu> Message-ID: On Sat, Mar 15, 2014 at 6:54 PM, Lo?c Hoguin wrote: > In what release port monitoring would land, presumably? > I don't know. If someone wants it the fastest way to get it in is submitting a patch. Doing the coding should be relatively similar to how link works with ports, so shouldn't (tm) be too hard. > Speaking of erlang:monitor, we have also been talking about adding a >> erlang:monitor/3 which would as a third argument take the identifier >> that you want to be sent back to the caller instead of the current >> reference. Is that something which could be useful to anyone? >> > > That does sound like something I could use, yes. > > The Gun HTTP client API (a few days from being public) creates a process > per connection, and then each request on the connection gets a reference. > If the user wants to do many requests on the same connection, then creating > a separate reference for the monitor makes sense, however I could use what > you propose when the user wants to do a single request and then close the > connection, we can reuse the reference from the request in the monitor > instead of creating two references. > > Doing it the other way (use the monitor ref as the request ref) would > complicate the API, so that's not an option. Good to know! -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias@REDACTED Mon Mar 17 10:55:52 2014 From: matthias@REDACTED (Matthias Lang) Date: Mon, 17 Mar 2014 10:55:52 +0100 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: Message-ID: <20140317095552.GA5071@corelatus.se> Hi, Here's an earlier discussion on the same topic: https://groups.google.com/forum/#!topic/erlang-programming/pSN3Cl0bBTg You can use 'send_timeout', but note the warning in the fine manual: http://www.erlang.org/doc/man/inet.html#setopts-2 it's basically telling you that the only well-defined thing you can do after send_timeout is to close the socket. Another, less satisfactory, approach is to write code like this: {ok, Tref} = timer:apply_after(500, erlang, exit, [self(), kill]), gen_tcp:send(S, Data), timer:cancel(Tref). --- You haven't really told us what you actually want to do. It could be that what you want isn't really possible at all, at least not with the conventional interface to the OS' TCP stack---there are buffers in the OS and buffers in the Erlang VM which you don't have complete control over. If feel you need to heed the dramatic warnings in Max's post, you should probably ask him to clarify. Matthias ----------------------------------------- Date: Monday, March 17 From: Vinoth Kumar To erlang-questions@REDACTED Subject: [erlang-questions] gen_tcp send non-blocking in erlang? > Does gen_tcp supports non-blocking send ?I have tried gen_tcp:send which returns the ok while the packets has not been sent to the receiver. Whether any mechanism in erlang to check the sent message delivary? > Thanks,Vinoth Kumar J > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vinothsparrow@REDACTED Mon Mar 17 10:32:13 2014 From: vinothsparrow@REDACTED (Vinoth Kumar) Date: Mon, 17 Mar 2014 15:02:13 +0530 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: , Message-ID: I have used both first and second step requested (i.e. {send_timeout,0} and erlang:port_command(Socket,Data)) but these methods also returns the same. Returns OK while tcp packets has not been delivered(i.e. TCP ack not received). The packet is pushed into the queue and trying to send. So i want an async send mechanism to check whether the packet has been sent to receiver. If packet delivered means just returns ok otherwise will return {error,timeout} Thanks,Vinoth Kumar J Date: Mon, 17 Mar 2014 12:53:41 +0400 Subject: Re: [erlang-questions] gen_tcp send non-blocking in erlang? From: max.lapshin@REDACTED To: vinothsparrow@REDACTED CC: erlang-questions@REDACTED It is a very, very dangerous practice, because you loose control over your program with non-blocking send. First step that you MUST do is setting send_timeout on socket. By default it is infinity and it means that your process may get blocked forever trying to push data. I don't know why infinity is a default value, it is really strange for me. Second, dangerous step is just using port_command(Socket, IoData). Then you must wait for messages from this socket. But don't use it =) -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.lapshin@REDACTED Mon Mar 17 11:29:56 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Mon, 17 Mar 2014 14:29:56 +0400 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: Message-ID: As far as I remember, Unix API doesn't give you any ability to tell that you have received ACK. There are many reasons. One of them is that TCP socket is a pipe only from application point of view. Kernel sees TCP as a window: some fragments of window are received, some are not. When to notify you? When all buffer is sent? Perhaps in such way your application will be very inefficient, because you will have to spend more time fetching data from remote server or local disk and send again. Maybe you should take a look at some application level confirm? "Hey there is a packet #145", "Thanks, I've received #145". -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinothsparrow@REDACTED Mon Mar 17 11:47:36 2014 From: vinothsparrow@REDACTED (Vinoth Kumar) Date: Mon, 17 Mar 2014 16:17:36 +0530 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: , , , Message-ID: Thanks Max, I will do it with application level confirmation. :) Date: Mon, 17 Mar 2014 14:29:56 +0400 Subject: Re: [erlang-questions] gen_tcp send non-blocking in erlang? From: max.lapshin@REDACTED To: vinothsparrow@REDACTED CC: erlang-questions@REDACTED As far as I remember, Unix API doesn't give you any ability to tell that you have received ACK. There are many reasons. One of them is that TCP socket is a pipe only from application point of view. Kernel sees TCP as a window: some fragments of window are received, some are not. When to notify you? When all buffer is sent? Perhaps in such way your application will be very inefficient, because you will have to spend more time fetching data from remote server or local disk and send again. Maybe you should take a look at some application level confirm? "Hey there is a packet #145", "Thanks, I've received #145". -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Mon Mar 17 11:49:11 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Mon, 17 Mar 2014 11:49:11 +0100 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: Message-ID: On Mon, Mar 17, 2014 at 8:15 AM, Vinoth Kumar wrote: > Does gen_tcp supports non-blocking send ? > > I have tried gen_tcp:send which returns the ok while the packets has not > been sent to the receiver. Whether any mechanism in erlang to check the > sent message delivary? > I think you must consider you may be going in a direction which TCP does not support, in general. The danger is you end up in a situation where you are bending the rules of TCP to a point where the guarantee you expect is not even there. Only turmoil is on this path. The problem is Erlang can only see so far. Once it delivers data to the kernel, the kernel is in control of what happens and you have relatively few ways to ask the kernel what it is doing. Worse, even if the kernel manages to send data, the NIC might queue you. Modern NICs have buffers in the excess of 4096 packets. And you have even fewer ways to ask those about their state. And if the NIC manages to send data, the hops in route might queue you. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon@REDACTED Mon Mar 17 11:55:44 2014 From: jon@REDACTED (Jon Schneider) Date: Mon, 17 Mar 2014 10:55:44 -0000 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: Message-ID: > Whether any mechanism in erlang to check the sent message delivary? > Thanks,Vinoth Kumar J TCP doesn't so how can Erlang ? I was quite shocked to find that a colleague of mine who has worked in mobile comms for years thought that TCP write()/send() returned when data was delivered rather than queued. Jon From jozsef.berces@REDACTED Mon Mar 17 12:18:02 2014 From: jozsef.berces@REDACTED (=?iso-8859-1?Q?J=F3zsef_B=E9rces?=) Date: Mon, 17 Mar 2014 11:18:02 +0000 Subject: [erlang-questions] ssh_sftp:read_file Message-ID: <7460EBDDCF52084A849D0F271CE059B8098E0A0B@ESESSMB101.ericsson.se> Comparing the ssh_sftp:read_file execution time to command line sftp shows a big difference. I experimented with a ~7MB gzipped file, downloading it from a Debian machine to my Win7 laptop. I tested it with Erlang R15B03, R16B02 and R16B03-1. While the Cygwin sftp transferred it in 4 seconds at 1.7MB/s speed, ssh_sftp:read_file got it in 30-20 seconds, depending on the erlang version. R16B03-1 shows improvement compared to the older releases, so it got the file in ~20s (the older ones needed ~30s). Writing a small program and using ssh_sftp:read to get the file in 64KB chunks speeds up the file transfer on all releases. The best I got with this is ~11 seconds on R16B03-1 (~20s on the older Erlang releases). But that is still far from the 4 seconds of the Cygwin command line sftp. Is there a way to further speed up the sftp file transfers in Erlang to reach (or at least to get near to) the command line sftp? Thanks, Jozsef -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias@REDACTED Mon Mar 17 12:19:42 2014 From: matthias@REDACTED (Matthias Lang) Date: Mon, 17 Mar 2014 12:19:42 +0100 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: Message-ID: <20140317111942.GA20052@corelatus.se> On Monday, March 17, Jon Schneider wrote: > > Whether any mechanism in erlang to check the sent message delivary? > TCP doesn't so how can Erlang ? [This is going beyond what the original poster probably had in mind, but it's an interesting problem.] TCP _does_ know which data has been ACKed. But that information gets lost somewhere between the TCP stack and ordinary programs. Something like this: http://www.erlang.se/workshop/2005/tcpip_presentation.pdf could be tweaked so that it really does let Erlang code figure out whether or not a particular byte has reached the remote TCP stack. Matthias From essen@REDACTED Mon Mar 17 12:26:39 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Mon, 17 Mar 2014 12:26:39 +0100 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: <20140317111942.GA20052@corelatus.se> References: <20140317111942.GA20052@corelatus.se> Message-ID: <5326DBEF.9040700@ninenines.eu> On 03/17/2014 12:19 PM, Matthias Lang wrote: > On Monday, March 17, Jon Schneider wrote: > >>> Whether any mechanism in erlang to check the sent message delivary? > >> TCP doesn't so how can Erlang ? > > [This is going beyond what the original poster probably had in mind, but > it's an interesting problem.] > > TCP _does_ know which data has been ACKed. But that information gets > lost somewhere between the TCP stack and ordinary programs. > > Something like this: > > http://www.erlang.se/workshop/2005/tcpip_presentation.pdf > > could be tweaked so that it really does let Erlang code figure out whether > or not a particular byte has reached the remote TCP stack. But the packet may be lost between the remote stack and the remote program, due to any number of reasons, including bugs and crashes. A way to know a remote endpoint has truly received the packet and processed it is to make it send a packet back. But even that is not perfect, as that "ack" packet can also be lost. A common way to solve this is to have an auto incremented value for all messages sent, and if the remote endpoint disconnects for any reasons, have it send the last value it received when connecting so the local endpoint knows what it needs to send again. -- Lo?c Hoguin http://ninenines.eu From cabo@REDACTED Mon Mar 17 12:29:09 2014 From: cabo@REDACTED (Carsten Bormann) Date: Mon, 17 Mar 2014 12:29:09 +0100 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: <20140317111942.GA20052@corelatus.se> References: <20140317111942.GA20052@corelatus.se> Message-ID: <4FDCF281-D7BF-4DC6-811C-1154B9F303C1@tzi.org> On 17 Mar 2014, at 12:19, Matthias Lang wrote: > TCP _does_ know which data has been ACKed. But that information gets > lost somewhere between the TCP stack and ordinary programs. Not really. Look up ?connection-splitting PEP?. > Something like this: > > http://www.erlang.se/workshop/2005/tcpip_presentation.pdf > > could be tweaked so that it really does let Erlang code figure out whether > or not a particular byte has reached the remote TCP stack. And that is useful how? The process reading from the socket could crash any moment after that. (This discussion seems to conflate misusing transport acknowledgments for application-level acknowledgment with flow control. The latter *is* important, and appears to have somewhat strange solutions, if at all, in the Erlang world.) Gr??e, Carsten From jvliwanag@REDACTED Mon Mar 17 12:51:39 2014 From: jvliwanag@REDACTED (Jan Vincent Liwanag) Date: Mon, 17 Mar 2014 19:51:39 +0800 Subject: [erlang-questions] eheap cannot allocate for which process? In-Reply-To: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> References: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> Message-ID: <626D63D6-519B-44CB-B8D7-FCF546DEE4C9@gmail.com> I'm not sure about the crash dump. But if you're able to re-run it, adding in os_mon should be quite helpful. You can set up listeners that alerts when processes ends up using memory. From there, while the system is still running, you can investigate more on what the process is doing - maybe a sys:get_status on the erlang shell. Sent from my iPhone > On Mar 17, 2014, at 4:51 PM, J?zsef B?rces wrote: > > I receive the classic ?eheap_alloc: Cannot allocate?? message. It wants to allocate ~1GB memory and that fails. That is fine, I am doing something wrong. So I took the crash dump and tried to find out which one of my processes is the guilty one. > > Unfortunately, I cannot tell it from the crash dump. > > The memory section says: > =memory > total: 15447352528 > processes: 15140232809 > processes_used: 15140005610 > system: 307119719 > atom: 512601 > atom_used: 496586 > binary: 148574400 > code: 21228007 > ets: 119988984 > > I have 16GB RAM, so the processes use almost all. There are 4010 processes. 1 garbing, 31 scheduled, 3978 waiting. If I sum stack+heap of all the processes then I get ~700MB. That is very far from 16GB. Here are the top 10 stack+heap processes: > Pid > State > Reductions > Stack+heap > MsgQ Length > <0.21060.67> > Garbing (limited info) > 1,508,838,180 > 145,962,050 > 1 > <0.25689.27> > Waiting > 86,670,344 > 145,962,050 > 0 > <0.10003.68> > Waiting > 1,363,039 > 38,263,080 > 0 > <0.15943.66> > Waiting > 1,882,465,380 > 30,610,465 > 0 > <0.15879.68> > Waiting > 471,549 > 30,610,465 > 0 > <0.31854.67> > Waiting > 154,500,777 > 24,488,375 > 0 > <0.16221.68> > Waiting > 262,114 > 24,488,375 > 0 > <0.16628.68> > Waiting > 117,268 > 24,488,375 > 0 > <0.15878.68> > Waiting > 453,490 > 19,590,700 > 0 > <0.16235.68> > Waiting > 181,968 > 19,590,700 > 0 > > Any ideas how to tell which process needs ~1GB memory? > > Thanks, > Jozsef > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From attila.r.nohl@REDACTED Mon Mar 17 13:36:26 2014 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 17 Mar 2014 13:36:26 +0100 Subject: [erlang-questions] eheap cannot allocate for which process? In-Reply-To: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> References: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> Message-ID: If you're running 32 bit Erlang, only 4 GB of memory is available for a single process. I think that the stack+heap value is in words, not in bytes, so on 32 bit Erlang you have to multiply it by 4, but I'm not quite sure. I my experience usually the processes with the longest queues are guilty in running out of memory (the process gets stuck, can't handle the incoming messages, the queue goes large and memory is eventually exhausted). Even though the queue length is only 1, my suspect is process <0.21060.67>. 2014-03-17 9:51 GMT+01:00 J?zsef B?rces : > I receive the classic "eheap_alloc: Cannot allocate..." message. It wants > to allocate ~1GB memory and that fails. That is fine, I am doing something > wrong. So I took the crash dump and tried to find out which one of my > processes is the guilty one. > > > > Unfortunately, I cannot tell it from the crash dump. > > > > The memory section says: > > =memory > > total: 15447352528 > > processes: 15140232809 > > processes_used: 15140005610 > > system: 307119719 > > atom: 512601 > > atom_used: 496586 > > binary: 148574400 > > code: 21228007 > > ets: 119988984 > > > > I have 16GB RAM, so the processes use almost all. There are 4010 > processes. 1 garbing, 31 scheduled, 3978 waiting. If I sum stack+heap of > all the processes then I get ~700MB. That is very far from 16GB. Here are > the top 10 stack+heap processes: > > *Pid * > > *State* > > *Reductions* > > *Stack+heap* > > *MsgQ Length* > > <0.21060.67> > > Garbing (limited info) > > 1,508,838,180 > > 145,962,050 > > 1 > > <0.25689.27> > > Waiting > > 86,670,344 > > 145,962,050 > > 0 > > <0.10003.68> > > Waiting > > 1,363,039 > > 38,263,080 > > 0 > > <0.15943.66> > > Waiting > > 1,882,465,380 > > 30,610,465 > > 0 > > <0.15879.68> > > Waiting > > 471,549 > > 30,610,465 > > 0 > > <0.31854.67> > > Waiting > > 154,500,777 > > 24,488,375 > > 0 > > <0.16221.68> > > Waiting > > 262,114 > > 24,488,375 > > 0 > > <0.16628.68> > > Waiting > > 117,268 > > 24,488,375 > > 0 > > <0.15878.68> > > Waiting > > 453,490 > > 19,590,700 > > 0 > > <0.16235.68> > > Waiting > > 181,968 > > 19,590,700 > > 0 > > > > Any ideas how to tell which process needs ~1GB memory? > > > > Thanks, > > Jozsef > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dszoboszlay@REDACTED Mon Mar 17 14:00:40 2014 From: dszoboszlay@REDACTED (=?utf-8?Q?Szoboszlay_D=C3=A1niel?=) Date: Mon, 17 Mar 2014 14:00:40 +0100 Subject: [erlang-questions] eheap cannot allocate for which process? In-Reply-To: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> References: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> Message-ID: Hi, I'd say it's the garbing process. The garbage collector is copying, so it first allocates a big chunk of memory then copies the non-garbage data there from the old heap. So it's always a likely suspect. All other processes in the below table are waiting. So they are not running, thus not allocating memory either. Which means it's either the garbing process or one of the 31 scheduled, but since they don't use too much memory they are not likely to cause trouble. Regards, Daniel On Mon, 17 Mar 2014 09:51:13 +0100, J?zsef B?rces wrote: > > I receive the classic ?eheap_alloc: Cannot allocate?? message. It wants > to allocate ~1GB memory and that fails. That is fine, I am doing > something wrong. So I >took the crash dump and tried to find out which > one of my processes is the guilty one. > > Unfortunately, I cannot tell it from the crash dump. > > The memory section says: > > =memory > > total: 15447352528 > > processes: 15140232809 > > processes_used: 15140005610 > > system: 307119719 > > atom: 512601 > > atom_used: 496586 > > binary: 148574400 > > code: 21228007 > > ets: 119988984 > > > I have 16GB RAM, so the processes use almost all. There are 4010 > processes. 1 garbing, 31 scheduled, 3978 waiting. If I sum stack+heap of > all the processes >then I get ~700MB. That is very far from 16GB. Here > are the top 10 stack+heap processes: >> Pid >> State >> Reductions >> Stack+heap >> MsgQ Length >> <0.21060.67> >> Garbing >(limited >info) >> 1,508,838,180 >> 145,962,050 >> 1 >> <0.25689.27> >> Waiting >> 86,670,344 >> 145,962,050 >> 0 >> <0.10003.68> >> Waiting >> 1,363,039 >> 38,263,080 >> 0 >> <0.15943.66> >> Waiting >> 1,882,465,380 >> 30,610,465 >> 0 >> <0.15879.68> >> Waiting >> 471,549 >> 30,610,465 >> 0 >> <0.31854.67> >> Waiting >> 154,500,777 >> 24,488,375 >> 0 >> <0.16221.68> >> Waiting >> 262,114 >> 24,488,375 >> 0 >> <0.16628.68> >> Waiting >> 117,268 >> 24,488,375 >> 0 >> <0.15878.68> >> Waiting >> 453,490 >> 19,590,700 >> 0 >> <0.16235.68> >> Waiting >> 181,968 >> 19,590,700 >> 0 > > > Any ideas how to tell which process needs ~1GB memory? > > > Thanks, > > Jozsef -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Mon Mar 17 14:56:42 2014 From: sean@REDACTED (Sean Cribbs) Date: Mon, 17 Mar 2014 08:56:42 -0500 Subject: [erlang-questions] ssh_sftp:read_file In-Reply-To: <7460EBDDCF52084A849D0F271CE059B8098E0A0B@ESESSMB101.ericsson.se> References: <7460EBDDCF52084A849D0F271CE059B8098E0A0B@ESESSMB101.ericsson.se> Message-ID: If your goal is simply to transfer the file and not to actually read it in your Erlang program, why not use os:cmd/1 to run the faster version? On Mon, Mar 17, 2014 at 6:18 AM, J?zsef B?rces wrote: > Comparing the ssh_sftp:read_file execution time to command line sftp > shows a big difference. I experimented with a ~7MB gzipped file, > downloading it from a Debian machine to my Win7 laptop. I tested it with > Erlang R15B03, R16B02 and R16B03-1. > > > > While the Cygwin sftp transferred it in 4 seconds at 1.7MB/s speed, > ssh_sftp:read_file got it in 30-20 seconds, depending on the erlang > version. R16B03-1 shows improvement compared to the older releases, so it > got the file in ~20s (the older ones needed ~30s). > > > > Writing a small program and using ssh_sftp:read to get the file in 64KB > chunks speeds up the file transfer on all releases. The best I got with > this is ~11 seconds on R16B03-1 (~20s on the older Erlang releases). But > that is still far from the 4 seconds of the Cygwin command line sftp. > > > > Is there a way to further speed up the sftp file transfers in Erlang to > reach (or at least to get near to) the command line sftp? > > > > Thanks, > > Jozsef > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias@REDACTED Mon Mar 17 15:18:15 2014 From: matthias@REDACTED (Matthias Lang) Date: Mon, 17 Mar 2014 15:18:15 +0100 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: <4FDCF281-D7BF-4DC6-811C-1154B9F303C1@tzi.org> References: <20140317111942.GA20052@corelatus.se> <4FDCF281-D7BF-4DC6-811C-1154B9F303C1@tzi.org> Message-ID: <20140317141815.GA21108@corelatus.se> On Monday, March 17, Carsten Bormann wrote: Carsten> Not really. Look up ?connection-splitting PEP?. ... > > could be tweaked so that it really does let Erlang code figure out whether > > or not a particular byte has reached the remote TCP stack. > And that is useful how? How does a connection-splitting PEP (i.e. what you referred to above) decide how much data to allow in from the fixed/fast side? Does it just use a static buffer, or does it keep an eye on how much the mobile/slow side's TCP stack has ACKed? If the latter, then that's an example of where this information would be useful. Matthias From snar@REDACTED Mon Mar 17 15:57:46 2014 From: snar@REDACTED (Alexandre Snarskii) Date: Mon, 17 Mar 2014 18:57:46 +0400 Subject: [erlang-questions] eheap cannot allocate for which process? In-Reply-To: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> References: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> Message-ID: <20140317145746.GA1507@snar.spb.ru> On Mon, Mar 17, 2014 at 08:51:13AM +0000, J?zsef B?rces wrote: > I receive the classic ?eheap_alloc: Cannot allocate?? message. It wants to > allocate ~1GB memory and that fails. That is fine, I am doing something wrong. > So I took the crash dump and tried to find out which one of my processes is > the guilty one. Some months ago I've had a similar problem: application running happily with ~400Mb RAM (on 2Gb RAM host) mostly consisting of four "major consumers" ("huge state" FSMs, ~80Mb each) started crashing with the same eheap_alloc: Cannot allocate 729810240 bytes of memory (of type "heap"). message. After some investigation (and switching from stock SASL error_logger to lager) I found that "guilty" processes were error_logger and gproc and that this problem is a bit deeper. Some screens: after FSM crash, restart and rebuilding its state I saw: Pid Initial Call Heap Reds Msgs Registered Current Function Stack <0.5.0> gen_event:init_it/6 59786060 5199822 0 error_logger gen_event:fetch_msg/5 8 <0.47.0> gproc:init/1 19590700 1650033 0 gproc gen_server:loop/6 9 <0.221.0> ebgp_conn:init/1 19590700 20382184 0 gen_fsm:loop/7 10 where 0.221.0 is my "fat FSM" after crash, restart and "state download". process_info(pid(0,5,0)) shows {total_heap_size,107614910}, {heap_size,59786060}, {stack_size,8}, {reductions,5199822}, {garbage_collection,[{min_bin_vheap_size,46368}, {min_heap_size,233}, {fullsweep_after,65535}, {minor_gcs,1}]}, but after manual call to garbage_collect(pid(0, 5, 0)) heap usage decreased significantly: {total_heap_size,233}, {heap_size,233}, {stack_size,8}, {reductions,5199822}, and the same memory decrease happened with gproc. How can I explain VM crash (not 100% sure, still consider myself as a novice in Erlang): when process crashes, it's state sent to all processes monitoring this one (gproc in this case) and to error_logger. State is big in my case (and in yours too). And there are no shared memory in Erlang. So, it's pretty logical that state of failed process was duplicated (may be even triplicated if copy happens while original process heap is not freed at this moment) and this duplication can cause eheap error. Especially in case when more than one "fat" process crashes instantly.. Lesson learned: while "let it crash" approach is generally good, it is not so good with "fat" processes, especially with heavily linked/monitored "fat" processes. PS: and error_logger and gproc are of course not guilty. They just efficient enough, so their garbage collector was not yet called. > > > > Unfortunately, I cannot tell it from the crash dump. > > > > The memory section says: > > =memory > > total: 15447352528 > > processes: 15140232809 > > processes_used: 15140005610 > > system: 307119719 > > atom: 512601 > > atom_used: 496586 > > binary: 148574400 > > code: 21228007 > > ets: 119988984 > > > > I have 16GB RAM, so the processes use almost all. There are 4010 processes. 1 > garbing, 31 scheduled, 3978 waiting. If I sum stack+heap of all the processes > then I get ~700MB. That is very far from 16GB. Here are the top 10 stack+heap > processes: > > Pid State Reductions Stack+heap MsgQ Length > > Garbing (limited 1,508,838,180 145,962,050 1 > <0.21060.67> info) > > <0.25689.27> Waiting 86,670,344 145,962,050 0 > > <0.10003.68> Waiting 1,363,039 38,263,080 0 > > <0.15943.66> Waiting 1,882,465,380 30,610,465 0 > > <0.15879.68> Waiting 471,549 30,610,465 0 > > <0.31854.67> Waiting 154,500,777 24,488,375 0 > > <0.16221.68> Waiting 262,114 24,488,375 0 > > <0.16628.68> Waiting 117,268 24,488,375 0 > > <0.15878.68> Waiting 453,490 19,590,700 0 > > <0.16235.68> Waiting 181,968 19,590,700 0 > > > > > Any ideas how to tell which process needs ~1GB memory? > > > > Thanks, > > Jozsef > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- In theory, there is no difference between theory and practice. But, in practice, there is. From mononcqc@REDACTED Mon Mar 17 16:48:46 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 17 Mar 2014 11:48:46 -0400 Subject: [erlang-questions] eheap cannot allocate for which process? In-Reply-To: <20140317145746.GA1507@snar.spb.ru> References: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> <20140317145746.GA1507@snar.spb.ru> Message-ID: <20140317154845.GA24082@ferdmbp.local> For this issue, see the format_status callback OTP behaviours contain: http://www.erlang.org/doc/man/gen_server.html#Module:format_status-2 They should let you do things the way you want and reduce the size of the messages logged. More generally, however, if you need to dig into a crash dump, I recommend using the scripts I added to recon: https://github.com/ferd/recon/tree/master/script One of them will do a quick diagnostic over the crashdump and output the info I've always found useful while debugging, and the awk script will output all functions that were running if mailboxes were huge. If the node is still running when you see problems appearing, I'd suggest looking into recon as a whole (docs: http://ferd.github.io/recon/) and see if the issues can be related to the total memory size and how it's allocated (see recon_alloc), binary memory "leaks" (see recon:bin_leak/1), and so on. The binary memory stuff wouldn't necessarily surprise me if you find out GCs tend to solve problems, but that's always system-specific. Regards, Fred. On 03/17, Alexandre Snarskii wrote: > On Mon, Mar 17, 2014 at 08:51:13AM +0000, J?zsef B?rces wrote: > > I receive the classic ?eheap_alloc: Cannot allocate?? message. It wants to > > allocate ~1GB memory and that fails. That is fine, I am doing something wrong. > > So I took the crash dump and tried to find out which one of my processes is > > the guilty one. > > Some months ago I've had a similar problem: application running happily > with ~400Mb RAM (on 2Gb RAM host) mostly consisting of four "major > consumers" ("huge state" FSMs, ~80Mb each) started crashing with the > same eheap_alloc: Cannot allocate 729810240 bytes of memory (of type "heap"). > message. After some investigation (and switching from stock SASL error_logger > to lager) I found that "guilty" processes were error_logger and gproc > and that this problem is a bit deeper. > > Some screens: after FSM crash, restart and rebuilding its state I saw: > > Pid Initial Call Heap Reds Msgs > Registered Current Function Stack > <0.5.0> gen_event:init_it/6 59786060 5199822 0 > error_logger gen_event:fetch_msg/5 8 > <0.47.0> gproc:init/1 19590700 1650033 0 > gproc gen_server:loop/6 9 > <0.221.0> ebgp_conn:init/1 19590700 20382184 0 > gen_fsm:loop/7 10 > > where 0.221.0 is my "fat FSM" after crash, restart and "state download". > process_info(pid(0,5,0)) shows > > {total_heap_size,107614910}, > {heap_size,59786060}, > {stack_size,8}, > {reductions,5199822}, > {garbage_collection,[{min_bin_vheap_size,46368}, > {min_heap_size,233}, > {fullsweep_after,65535}, > {minor_gcs,1}]}, > > but after manual call to garbage_collect(pid(0, 5, 0)) heap usage > decreased significantly: > > {total_heap_size,233}, > {heap_size,233}, > {stack_size,8}, > {reductions,5199822}, > > and the same memory decrease happened with gproc. > > How can I explain VM crash (not 100% sure, still consider myself as a > novice in Erlang): when process crashes, it's state sent to all processes > monitoring this one (gproc in this case) and to error_logger. State is big > in my case (and in yours too). And there are no shared memory in Erlang. > So, it's pretty logical that state of failed process was duplicated (may > be even triplicated if copy happens while original process heap is not > freed at this moment) and this duplication can cause eheap error. > Especially in case when more than one "fat" process crashes instantly.. > > Lesson learned: while "let it crash" approach is generally good, it is > not so good with "fat" processes, especially with heavily linked/monitored > "fat" processes. > > PS: and error_logger and gproc are of course not guilty. They just > efficient enough, so their garbage collector was not yet called. > > > > > > > > > > Unfortunately, I cannot tell it from the crash dump. > > > > > > > > The memory section says: > > > > =memory > > > > total: 15447352528 > > > > processes: 15140232809 > > > > processes_used: 15140005610 > > > > system: 307119719 > > > > atom: 512601 > > > > atom_used: 496586 > > > > binary: 148574400 > > > > code: 21228007 > > > > ets: 119988984 > > > > > > > > I have 16GB RAM, so the processes use almost all. There are 4010 processes. 1 > > garbing, 31 scheduled, 3978 waiting. If I sum stack+heap of all the processes > > then I get ~700MB. That is very far from 16GB. Here are the top 10 stack+heap > > processes: > > > > Pid State Reductions Stack+heap MsgQ Length > > > > Garbing (limited 1,508,838,180 145,962,050 1 > > <0.21060.67> info) > > > > <0.25689.27> Waiting 86,670,344 145,962,050 0 > > > > <0.10003.68> Waiting 1,363,039 38,263,080 0 > > > > <0.15943.66> Waiting 1,882,465,380 30,610,465 0 > > > > <0.15879.68> Waiting 471,549 30,610,465 0 > > > > <0.31854.67> Waiting 154,500,777 24,488,375 0 > > > > <0.16221.68> Waiting 262,114 24,488,375 0 > > > > <0.16628.68> Waiting 117,268 24,488,375 0 > > > > <0.15878.68> Waiting 453,490 19,590,700 0 > > > > <0.16235.68> Waiting 181,968 19,590,700 0 > > > > > > > > > > Any ideas how to tell which process needs ~1GB memory? > > > > > > > > Thanks, > > > > Jozsef > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > In theory, there is no difference between theory and practice. > But, in practice, there is. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From nem@REDACTED Mon Mar 17 19:09:53 2014 From: nem@REDACTED (Geoff Cant) Date: Mon, 17 Mar 2014 11:09:53 -0700 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: Message-ID: gen_tcp is a wrapper around functionality provided by a prim_inet port - and in fact gen_tcp implements a synchronous call interface to the underlying asynchronous message based port API, so if you are prepare to thoroughly void your warranty, you can do async tcp sends in Erlang. A testament to my sins^W^W^W^Wworked example can be seen here: https://github.com/heroku/logplex/blob/master/src/logplex_tcpsyslog_drain.erl#L565, https://github.com/heroku/logplex/blob/master/src/logplex_tcpsyslog_drain.erl#L224 * erlang:port_command(TcpSocket, DataToSend, []) % Start async send * receive {inet_reply, TcpSocket, Result} -> something() end % finish async send - result is 'ok' or {'error', Why} You buy yourself a whole lot of hurt with this - you have to manage all your own timeouts and error detection behaviour. The upside is that the process doing the sending doesn't need to block on a selective receive, so can continue doing work (clearing a noisy incoming message queue in my example above). tl;dr: yes, it can be done but think twice before doing so, and don't bug the OTP team if it goes wrong - they tried to warn us :) -Geoff On 2014-03-17, at 00:15 , Vinoth Kumar wrote: > Does gen_tcp supports non-blocking send ? > > I have tried gen_tcp:send which returns the ok while the packets has not been sent to the receiver. Whether any mechanism in erlang to check the sent message delivary? > > > > Thanks, > > Vinoth Kumar J > From mononcqc@REDACTED Mon Mar 17 21:28:48 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Mon, 17 Mar 2014 16:28:48 -0400 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: References: Message-ID: <20140317202847.GC24082@ferdmbp.local> To note that erlang:port_command(TcpSocket, DataToSend, []) will deschedule the process (and leave it that way) when the buffer is full. The alternative is to pass in the 'nosuspend' option, which will avoid the issue, but will return true/false depending on if it was possible to send the packet to the buffer. On 03/17, Geoff Cant wrote: > gen_tcp is a wrapper around functionality provided by a prim_inet port - and in fact gen_tcp implements a synchronous call interface to the underlying asynchronous message based port API, so if you are prepare to thoroughly void your warranty, you can do async tcp sends in Erlang. > > A testament to my sins^W^W^W^Wworked example can be seen here: https://github.com/heroku/logplex/blob/master/src/logplex_tcpsyslog_drain.erl#L565, https://github.com/heroku/logplex/blob/master/src/logplex_tcpsyslog_drain.erl#L224 > > * erlang:port_command(TcpSocket, DataToSend, []) % Start async send > * receive {inet_reply, TcpSocket, Result} -> something() end % finish async send - result is 'ok' or {'error', Why} > > You buy yourself a whole lot of hurt with this - you have to manage all your own timeouts and error detection behaviour. The upside is that the process doing the sending doesn't need to block on a selective receive, so can continue doing work (clearing a noisy incoming message queue in my example above). > > > tl;dr: yes, it can be done but think twice before doing so, and don't bug the OTP team if it goes wrong - they tried to warn us :) > > -Geoff > > > On 2014-03-17, at 00:15 , Vinoth Kumar wrote: > > > Does gen_tcp supports non-blocking send ? > > > > I have tried gen_tcp:send which returns the ok while the packets has not been sent to the receiver. Whether any mechanism in erlang to check the sent message delivary? > > > > > > > > Thanks, > > > > Vinoth Kumar J > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From alisdairsullivan@REDACTED Tue Mar 18 01:41:59 2014 From: alisdairsullivan@REDACTED (alisdair sullivan) Date: Mon, 17 Mar 2014 17:41:59 -0700 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <5324789E.3000508@ninenines.eu> Message-ID: <59F3FD81-BE09-46D8-9517-21CB999ABD7F@yahoo.ca> > Alisdair and I have talked extensively about most minute details of > JSON parsing and our libraries are about as close as they're gonna get > in terms of API compatibility. If Erlang decides to choose one or the > other one of us is gonna be happy and the other will be sad and have > to rewrite a lot of code or not use the builtin. Though I'd point out > that the builtin won't actually be "standard" until 3-5 years from now > so its probably not a huge issue either way. i think we?re at the point we agree about everything except maybe some weird edge cases and how strict we are with bad utf encoding. if you?d fix your broken object representation we could probably present exactly the same interface > And just because I haven't heard from Alisdair recently I have to > point out that {[]} is still the One True Empty Object representation. > [{}] is just atrocious. or not From 249505968@REDACTED Tue Mar 18 04:17:06 2014 From: 249505968@REDACTED (=?gb18030?B?99L30Q==?=) Date: Tue, 18 Mar 2014 11:17:06 +0800 Subject: [erlang-questions] Is there anything to check the speed of ets like slow log for mysql? Message-ID: The eprof show that some ets operate cost a lot of time (like 100us/call) but I'm not sure which ets make it...How to check out this problem? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Tue Mar 18 06:02:37 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Tue, 18 Mar 2014 18:02:37 +1300 Subject: [erlang-questions] gen_tcp send non-blocking in erlang? In-Reply-To: <4FDCF281-D7BF-4DC6-811C-1154B9F303C1@tzi.org> References: <20140317111942.GA20052@corelatus.se> <4FDCF281-D7BF-4DC6-811C-1154B9F303C1@tzi.org> Message-ID: <6C6B12E1-34DC-47D6-A659-D6FB9843594D@cs.otago.ac.nz> On 18/03/2014, at 12:29 AM, Carsten Bormann wrote: > > Not really. Look up ?connection-splitting PEP?. I did. Practically everything that came back was a patent. Would you care to elaborate? From valentin@REDACTED Tue Mar 18 14:13:24 2014 From: valentin@REDACTED (Valentin Micic) Date: Tue, 18 Mar 2014 15:13:24 +0200 Subject: [erlang-questions] Unexpected list_to_binary behavior Message-ID: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> Hi all, (my apologies if this has been covered already) Is there any reason why: (twist@REDACTED)820> list_to_binary( lists:seq(1,255) ). <<1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21, 22,23,24,25,26,27,28,29,?>> works, but (twist@REDACTED)821> list_to_binary( lists:seq(1,256) ). ** exception error: bad argument in function list_to_binary/1 called as list_to_binary([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, 23,24,25,26,27,28|?]) breaks on Erlang 16B02? Was the limit to 255 characters for list_to_binary/1 always there and I just failed to see it before? Kind regards V/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierrefenoll@REDACTED Tue Mar 18 14:19:05 2014 From: pierrefenoll@REDACTED (Pierre Fenoll) Date: Tue, 18 Mar 2014 14:19:05 +0100 Subject: [erlang-questions] Unexpected list_to_binary behavior In-Reply-To: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> References: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> Message-ID: Also happening here on R16B03-1. (Displayed string is due to +pc unicode) 9> list_to_binary( lists:seq(255,256) ). ** exception error: bad argument in function list_to_binary/1 called as list_to_binary("??") Cheers, -- Pierre Fenoll -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Tue Mar 18 14:19:40 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 18 Mar 2014 09:19:40 -0400 Subject: [erlang-questions] Unexpected list_to_binary behavior In-Reply-To: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> References: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> Message-ID: On Tue, Mar 18, 2014 at 9:13 AM, Valentin Micic wrote: > Hi all, > > (my apologies if this has been covered already) > > Is there any reason why: > > *(twist@REDACTED)820> list_to_binary( lists:seq(1,255) ).* > *<<1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,* > * 22,23,24,25,26,27,28,29,...>>* > > works, but > > (twist@REDACTED)821> list_to_binary( lists:seq(1,256) ). > ** exception error: bad argument > in function list_to_binary/1 > called as > list_to_binary([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, > 23,24,25,26,27,28|...]) > > breaks on *Erlang 16B02*? Was the limit to 255 characters for > list_to_binary/1 always there and I just failed to see it before? > This has nothing to do with the number of characters, but rather that you can't represent the value 256 in a byte: 1> list_to_binary([256]). ** exception error: bad argument in function list_to_binary/1 called as list_to_binary([256]) --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus@REDACTED Tue Mar 18 14:24:15 2014 From: magnus@REDACTED (Magnus Henoch) Date: Tue, 18 Mar 2014 13:24:15 +0000 Subject: [erlang-questions] Unexpected list_to_binary behavior In-Reply-To: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> (Valentin Micic's message of "Tue, 18 Mar 2014 15:13:24 +0200") References: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> Message-ID: Valentin Micic writes: > Hi all, > > (my apologies if this has been covered already) > > Is there any reason why: > > (twist@REDACTED)820> list_to_binary( lists:seq(1,255) ). > <<1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21, > 22,23,24,25,26,27,28,29,?>> > > works, but > > (twist@REDACTED)821> list_to_binary( lists:seq(1,256) ). > ** exception error: bad argument > in function list_to_binary/1 > called as list_to_binary([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, > 23,24,25,26,27,28|?]) > > breaks on Erlang 16B02? Was the limit to 255 characters for list_to_binary/1 always there and I just failed to see it before? The problem is not the length of the list, but the values in it: 2> list_to_binary(lists:duplicate(256, 1)). <<1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1, 1,...>> list_to_binary just takes a list of byte values (0 =< n =< 255) and puts them into a binary. (If you want to convert Unicode codepoints, which may be greater than 255, you could use unicode:characters_to_binary/1.) Regards, Magnus From valentin@REDACTED Tue Mar 18 15:15:57 2014 From: valentin@REDACTED (Valentin Micic) Date: Tue, 18 Mar 2014 16:15:57 +0200 Subject: [erlang-questions] Unexpected list_to_binary behavior In-Reply-To: References: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> Message-ID: Yes, you're right and this make sense at some level, particularly if the function I've called was characters_to_binary/1. Indeed, as Magnus Henoch mentioned in a related email, there is a function for conversion of unicode characters: unicode:characters_to_binary/1; So, why should the other one be called: list_to_binary/1 instead instead of characters_to_binary/1 If one disregard the existence of any previous knowledge, and given that a list may contain any number of arbitrary types, including a list itself, what should be a reasonable expectation for (and here's the kicker -- not an input argument itself, for it is perfectly acceptable to assume it to be a list, but) a content of the input argument? It's surprising (at least was to me) to expect a content of an input argument ( formerly known as list ) to be limited to a list of octets, as much as it is surprising to see that integer_to_binary( 65536 ) results in <<"65536">> instead of <<255,255>>, that is, surprising to se that it behaves like a shortcut to list_to_binary( integer_to_list( 65536 )). On the other hand, it is what it is, and, in a way, I am quite embarrassed that I assumed that integers would be automagically converted to appropriate number of octets, for this is just as unreasonable and arbitrary expectation. Thank you for your responses. Kind regards V/ On 18 Mar 2014, at 3:19 PM, Steve Vinoski wrote: > > > > On Tue, Mar 18, 2014 at 9:13 AM, Valentin Micic wrote: > Hi all, > > (my apologies if this has been covered already) > > Is there any reason why: > > (twist@REDACTED)820> list_to_binary( lists:seq(1,255) ). > <<1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21, > 22,23,24,25,26,27,28,29,?>> > > works, but > > (twist@REDACTED)821> list_to_binary( lists:seq(1,256) ). > ** exception error: bad argument > in function list_to_binary/1 > called as list_to_binary([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, > 23,24,25,26,27,28|?]) > > breaks on Erlang 16B02? Was the limit to 255 characters for list_to_binary/1 always there and I just failed to see it before? > > This has nothing to do with the number of characters, but rather that you can't represent the value 256 in a byte: > > 1> list_to_binary([256]). > ** exception error: bad argument > in function list_to_binary/1 > called as list_to_binary([256]) > > --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Tue Mar 18 15:23:52 2014 From: sean@REDACTED (Sean Cribbs) Date: Tue, 18 Mar 2014 09:23:52 -0500 Subject: [erlang-questions] Unexpected list_to_binary behavior In-Reply-To: References: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> Message-ID: integer_to_binary/1 could be written as integer_to_binary(N) -> list_to_binary(integer_to_list(N)). Furthermore, what you ask for is not straightforward, given the numerous encodings of integers available. What if I wanted a 64-bit signed little-endian integer encoded in the binary? You can't tell i2b that, but you could do it with bit syntax: <<65535:64/little-signed>> ( <<0,0,1,0,0,0,0,0>> ). On Tue, Mar 18, 2014 at 9:15 AM, Valentin Micic wrote: > Yes, you're right and this make sense at some level, particularly if the > function I've called was > > characters_to_binary/1. > > Indeed, as Magnus Henoch mentioned in a related email, there is a function > for conversion of unicode characters: > > unicode:characters_to_binary/1; > > So, why should the other one be called: list_to_binary/1 instead instead > of characters_to_binary/1 > > If one disregard the existence of any previous knowledge, and given that a > list may contain any number of arbitrary types, including a list > itself, what should be a reasonable expectation for (and here's the kicker > -- not an input argument itself, for it is perfectly acceptable to assume > it to be a list, but) a content of the input argument? > > It's surprising (at least was to me) to expect a content of an input > argument ( formerly known as *list *) to be limited to a list of octets, > as much as it is surprising to see that integer_to_binary( 65536 ) results > in <<"65536">> instead of <<255,255>>, that is, surprising to se that it > behaves like a shortcut to *list_to_binary( integer_to_list( 65536 )).* > > On the other hand, it is what it is, and, in a way, I am quite > embarrassed that I assumed that integers would be automagically converted > to appropriate number of octets, for this is just as unreasonable and > arbitrary expectation. > > Thank you for your responses. > > Kind regards > > V/ > > > On 18 Mar 2014, at 3:19 PM, Steve Vinoski wrote: > > > > > On Tue, Mar 18, 2014 at 9:13 AM, Valentin Micic wrote: > >> Hi all, >> >> (my apologies if this has been covered already) >> >> Is there any reason why: >> >> *(twist@REDACTED)820> list_to_binary( lists:seq(1,255) ).* >> *<<1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,* >> * 22,23,24,25,26,27,28,29,?>>* >> >> works, but >> >> (twist@REDACTED)821> list_to_binary( lists:seq(1,256) ). >> ** exception error: bad argument >> in function list_to_binary/1 >> called as >> list_to_binary([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22, >> 23,24,25,26,27,28|?]) >> >> breaks on *Erlang 16B02*? Was the limit to 255 characters for >> list_to_binary/1 always there and I just failed to see it before? >> > > This has nothing to do with the number of characters, but rather that you > can't represent the value 256 in a byte: > > 1> list_to_binary([256]). > ** exception error: bad argument > in function list_to_binary/1 > called as list_to_binary([256]) > > --steve > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Tue Mar 18 18:56:35 2014 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Tue, 18 Mar 2014 18:56:35 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: <1394816683.57674.YahooMailNeo@web140105.mail.bf1.yahoo.com> References: <20140314152012.GA95455@ferdair.local> <1394816683.57674.YahooMailNeo@web140105.mail.bf1.yahoo.com> Message-ID: Den 14 mar 2014 18:05 skrev "Thomas Lindgren" : > > > Hey OTPeople, > > Since this comes up every now and then, does Ericsson have any plan to introduce atom garbage collection or suchlike in Erlang/OTP? Some official info would be great. > > Best, > Thomas Hi, We, the OTP team at Ericsson have no plans to implement GC of atoms in the near future. Meaning within the next 1-2 years. This is simply not one of the most prioritized things we have to do. I would like to have real GC of atoms but it is a big task to implement and it will most probably imply degradation in performance which is not good. We have to weigh this against the problems the non GCed atoms might cause to real systems. We don't know that many. Also note that we don't think that EEP-20 is a good idea in its present form. EEP-20 "Split the atoms" introduces two types of atoms, and is invisible on the language level, but for the VM implementation and the characteristics it is dramatic. Todays atoms are represented as immediates in todays VM meaning that no allocation on the heap is needed. Many places in the VM code relies on that fact which makes it easy to se atom. In EEP-20 some atoms will be boxed types stored on the heap and this will change the impact on memory handling an memory consumption dramatically. Performance will also be impacted, negatively. /Kenneth Erlang/OTP Ericsson Den 14 mar 2014 18:05 skrev "Thomas Lindgren" : > > Hey OTPeople, > > Since this comes up every now and then, does Ericsson have any plan to > introduce atom garbage collection or suchlike in Erlang/OTP? Some official > info would be great. > > Best, > Thomas > > > > On Friday, March 14, 2014 4:20 PM, Fred Hebert wrote: > > Hi Joe, > > I think the library you have described (does 99% of the work) is the > equivalent of bait-and-switch at the language/library level: > > 1) it's not just a question of do floating point numbers survive the > roadtrip, but also integers. > 2) json tags are more or less strings and expect utf-8. Currently, we > 'support' utf8 atoms but we don't. See > http://www.erlang.org/erldoc?q=list_to_atom. > This doesn't mention what you do in case of trying to encode a map > which currently uses keys such as '1.0', 1.0, <<"1.0">>, and "1.0" at > the same time. We currently have 4 data types that will possibly need > an identical representation while being converted. > > Woops, that doesn't work super well and may in fact cover far less > than 99% of the cases. We have to consider all the other cases such > as just 1, 1.0, "1.00", "1.000", ..., and so on. > > > 3) That can be made to work > 4) No opinion on this one > 5) This can also be read as "best effort not corrupting values read" > which scares me a lot if the end result is not "raise an error when you > can't > figure it out reliably" > 6) Amen to that. > > This doesn't even take into account the issue that by using atoms by > default, you're actively using a source of memory leaks into the > library. This guarantees that every tutorial out there will recommend > not using the standard library for your tasks. > > What I'm getting at here is that while your scheme might work for 99% of > possible JSON -> Erlang decodings, it will do so in a risky way that > cannot be advocated. > > If you consider all the possible Erlang -> JSON mappings (and this is > where the biggest problem always is), then it covers far, far less than > 99% of the cases, because there is not one good way to do it (how do you > even represent binaries that are not UTF-8 and distinguish them from > actual strings? You validate the entire thing unless you want to create > unparseable JSON). > > I used the words bait-and-switch and I mean it there. This is one of the > points where Jose Valim and I disagree the most. > > I hate, absolutely hate solutions that bring you 70% of the way (to use > a number we discussed between ourselves). Why? Because you start by > learning the 70% solution and then it doesn't work. Suddenly you have to > go out and look for the 99% and the 100% solutions out there. > > Except you now have a crusty code base full of legacy, and you start > supporting, one, two libraries, which you never envisioned. And you find > out you're married to encoders and decoders that decided to do things > differently, but you just don't have the time to fix everything right > now. > > You start seeing node crashes because someone decided atoms is a good > way to receive unvalidated data without first having implemented a > scheme to GC them (say EEP-20: > http://www.erlang.org/eeps/eep-0020.html). > > You start being pretty angry that a language so focused on getting > productions systems live has a standard library that lets you hang dry. > > Then you get even angrier when you figure out a crapload of frameworks > in the wild all use that faulty function because it was in the standard > library. > > Then you get certainly extremely angry and leave for Go or some other > language when you figure out the community already had solutions to > these problems in the year 2014 (and before!) but they were just > overlooked because we wanted an easy JSON implementation in the stdlib. > > I can't for the life of me see the benefit of canonizing a bad library > when tradeoffs are already known and worked around in the wild. > > What we should focus on is explaining these tradeoffs and making it easy > to show the different options. Currently, picking a JSON lib is hard > because there is such a very poor match between what you can possibly > encode in Erlang and how you can translate this back and forth with > JSON. Not just because it's not in the standard library. > > Not speaking about the problem doesn't make it go away, it makes it more > surprising, which is not a desirable property. > > Regards, > Fred. > > On 03/14, Joe Armstrong wrote: > > > This is what most libraries do - they work 99% of the time. > > > > (( the 99% is horrible - just when I think a library is great I find - > *but > > I can't do X* then > > I'm in trouble - but I guess this is in the nature of the beast - only > > pure mathematical > > functions have the kind of "platonic interfaces" that will never > change > > - real > > world problems with time and space involved are just plain messy )) > > > > If we freeze the JSON design and say: > > > > 1) floating point number will not survive a round-trip > > 2) JSON tags will be erlang atoms > > 3) Terms are not-infinite and rather small (few MB at max) > > 4) we want a parse tree > > 5) best effort at sorting out character set encodings > > 6) Pure erlang > > > > Then the problem becomes "easy" and can be knocked out in a few lies of > code > > using maps:from_list and maps:to_list. > > > > And *because* it's easy nobody writes a library to do this. > > > > The trouble is a beginner probably does not find this easy and would > > appreciate > > a library that worked 99% of the time on simple problems. > > > > /Joe > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.oxyde@REDACTED Tue Mar 18 19:03:41 2014 From: n.oxyde@REDACTED (Anthony Ramine) Date: Tue, 18 Mar 2014 19:03:41 +0100 Subject: [erlang-questions] No JSON/MAPS interoperability in 17.0? In-Reply-To: References: <20140314152012.GA95455@ferdair.local> <1394816683.57674.YahooMailNeo@web140105.mail.bf1.yahoo.com> Message-ID: <99C7A22D-ACD7-4D92-BECE-A72B4BC06544@gmail.com> My understanding of EEP20 is that it is a best effort thing, i.e. local atoms may still enter the global atom table if given as a process name, as an ETS table name, etc. I don?t think it is a bad thing. If there are so few systems that use dynamically-created atoms, why would performance be degraded? I had begun working on this but Unicode atoms made my code irrelevant. Wouldn?t be angry if I ever finish it and it gets rejected though. -- Anthony Ramine Le 18 mars 2014 ? 18:56, Kenneth Lundin a ?crit : > > Den 14 mar 2014 18:05 skrev "Thomas Lindgren" : > > > > > > Hey OTPeople, > > > > Since this comes up every now and then, does Ericsson have any plan to introduce atom garbage collection or suchlike in Erlang/OTP? Some official info would be great. > > > > Best, > > Thomas > > Hi, > > We, the OTP team at Ericsson have no plans to implement GC of atoms in the near future. Meaning within the next 1-2 years. > This is simply not one of the most prioritized things we have to do. > > I would like to have real GC of atoms but it is a big task to implement and it will most probably imply degradation in performance which is not good. > We have to weigh this against the problems the non GCed atoms might cause to real systems. We don't know that many. > > Also note that we don't think that EEP-20 is a good idea in its present form. > EEP-20 "Split the atoms" introduces two types of atoms, and is invisible on the language level, but for the VM implementation and the characteristics it is dramatic. > Todays atoms are represented as immediates in todays VM meaning that no allocation on the heap is needed. Many places in the VM code relies on that fact which makes it easy to se atom. In EEP-20 some atoms will be boxed types stored on the heap and this will change the impact on memory handling an memory consumption dramatically. Performance will also be impacted, negatively. > > /Kenneth Erlang/OTP Ericsson > Den 14 mar 2014 18:05 skrev "Thomas Lindgren" : > > Hey OTPeople, > > Since this comes up every now and then, does Ericsson have any plan to introduce atom garbage collection or suchlike in Erlang/OTP? Some official info would be great. > > Best, > Thomas > > > > On Friday, March 14, 2014 4:20 PM, Fred Hebert wrote: > Hi Joe, > > I think the library you have described (does 99% of the work) is the > equivalent of bait-and-switch at the language/library level: > > 1) it's not just a question of do floating point numbers survive the > roadtrip, but also integers. > 2) json tags are more or less strings and expect utf-8. Currently, we > 'support' utf8 atoms but we don't. See > http://www.erlang.org/erldoc?q=list_to_atom. > This doesn't mention what you do in case of trying to encode a map > which currently uses keys such as '1.0', 1.0, <<"1.0">>, and "1.0" at > the same time. We currently have 4 data types that will possibly need > an identical representation while being converted. > > Woops, that doesn't work super well and may in fact cover far less > than 99% of the cases. We have to consider all the other cases such > as just 1, 1.0, "1.00", "1.000", ..., and so on. > > > 3) That can be made to work > 4) No opinion on this one > 5) This can also be read as "best effort not corrupting values read" > which scares me a lot if the end result is not "raise an error when you can't > figure it out reliably" > 6) Amen to that. > > This doesn't even take into account the issue that by using atoms by > default, you're actively using a source of memory leaks into the > library. This guarantees that every tutorial out there will recommend > not using the standard library for your tasks. > > What I'm getting at here is that while your scheme might work for 99% of > possible JSON -> Erlang decodings, it will do so in a risky way that > cannot be advocated. > > If you consider all the possible Erlang -> JSON mappings (and this is > where the biggest problem always is), then it covers far, far less than > 99% of the cases, because there is not one good way to do it (how do you > even represent binaries that are not UTF-8 and distinguish them from > actual strings? You validate the entire thing unless you want to create > unparseable JSON). > > I used the words bait-and-switch and I mean it there. This is one of the > points where Jose Valim and I disagree the most. > > I hate, absolutely hate solutions that bring you 70% of the way (to use > a number we discussed between ourselves). Why? Because you start by > learning the 70% solution and then it doesn't work. Suddenly you have to > go out and look for the 99% and the 100% solutions out there. > > Except you now have a crusty code base full of legacy, and you start > supporting, one, two libraries, which you never envisioned. And you find > out you're married to encoders and decoders that decided to do things > differently, but you just don't have the time to fix everything right > now. > > You start seeing node crashes because someone decided atoms is a good > way to receive unvalidated data without first having implemented a > scheme to GC them (say EEP-20: > http://www.erlang.org/eeps/eep-0020.html). > > You start being pretty angry that a language so focused on getting > productions systems live has a standard library that lets you hang dry. > > Then you get even angrier when you figure out a crapload of frameworks > in the wild all use that faulty function because it was in the standard > library. > > Then you get certainly extremely angry and leave for Go or some other > language when you figure out the community already had solutions to > these problems in the year 2014 (and before!) but they were just > overlooked because we wanted an easy JSON implementation in the stdlib. > > I can't for the life of me see the benefit of canonizing a bad library > when tradeoffs are already known and worked around in the wild. > > What we should focus on is explaining these tradeoffs and making it easy > to show the different options. Currently, picking a JSON lib is hard > because there is such a very poor match between what you can possibly > encode in Erlang and how you can translate this back and forth with > JSON. Not just because it's not in the standard library. > > Not speaking about the problem doesn't make it go away, it makes it more > surprising, which is not a desirable property. > > Regards, > Fred. > > On 03/14, Joe Armstrong wrote: > > > This is what most libraries do - they work 99% of the time. > > > > (( the 99% is horrible - just when I think a library is great I find - *but > > I can't do X* then > > I'm in trouble - but I guess this is in the nature of the beast - only > > pure mathematical > > functions have the kind of "platonic interfaces" that will never change > > - real > > world problems with time and space involved are just plain messy )) > > > > If we freeze the JSON design and say: > > > > 1) floating point number will not survive a round-trip > > 2) JSON tags will be erlang atoms > > 3) Terms are not-infinite and rather small (few MB at max) > > 4) we want a parse tree > > 5) best effort at sorting out character set encodings > > 6) Pure erlang > > > > Then the problem becomes "easy" and can be knocked out in a few lies of code > > using maps:from_list and maps:to_list. > > > > And *because* it's easy nobody writes a library to do this. > > > > The trouble is a beginner probably does not find this easy and would > > appreciate > > a library that worked 99% of the time on simple problems. > > > > /Joe > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dan@REDACTED Tue Mar 18 22:38:45 2014 From: dan@REDACTED (Daniel Dormont) Date: Tue, 18 Mar 2014 17:38:45 -0400 Subject: [erlang-questions] Mnesia cluster across releases Message-ID: Hi all, Can a Mnesia cluster exist across two OTP releases, specifically R15B and R16B? I'm testing some upgrades here and seeing this error about two minutes after trying to join a node running R16B to an existing cluster running R15B: =ERROR REPORT==== 2014-03-18 17:13:29 === Mnesia('ejabberd@REDACTED'): ** ERROR ** (core dumped to file: "/var/lib/ejabberd/MnesiaCore.ejabberd@REDACTED") ** FATAL ** Schema update error {{badmatch, {error, {bad_object_header, "/var/lib/ejabberd/schema.DAT"}}}, [{mnesia_dumper,dets_insert,4, [{file,"mnesia_dumper.erl"},{line,342}]}, {mnesia_dumper,insert_cstruct,5, [{file,"mnesia_dumper.erl"},{line,1117}]}, {mnesia_dumper,insert_ops,6, [{file,"mnesia_dumper.erl"},{line,309}]}, {mnesia_dumper,perform_update,4, [{file,"mnesia_dumper.erl"},{line,292}]}, {mnesia_dumper,update,3, [{file,"mnesia_dumper.erl"},{line,273}]}, {mnesia_tm,do_commit,3, [{file,"mnesia_tm.erl"},{line,1780}]}, {mnesia_tm,commit_participant,6, [{file,"mnesia_tm.erl"},{line,1699}]}]} [{op, merge_schema, [{name, ... etc. If not, are there strategies for dealing with such an upgrade? Or is this caused by something else entirely? Thanks, Dan From dmercer@REDACTED Tue Mar 18 23:15:26 2014 From: dmercer@REDACTED (David Mercer) Date: Tue, 18 Mar 2014 17:15:26 -0500 Subject: [erlang-questions] Rebar help Message-ID: <001e01cf42f7$90840440$b18c0cc0$@gmail.com> I am trying to hop on the rebar bandwagon, but cannot seem to get it to compile. I am following the instructions at https://github.com/rebar/rebar. On Windows 7, I did the following. Error highlighted below: >git clone git://github.com/rebar/rebar.git Cloning into 'rebar'... remote: Reusing existing pack: 6483, done. remote: Counting objects: 4, done. remote: Compressing objects: 100% (4/4), done. remote: Total 6487 (delta 0), reused 0 (delta 0) Receiving objects: 100% (6487/6487), 2.57 MiB | 923.00 KiB/s, done. Resolving deltas: 100% (3745/3745), done. Checking connectivity... done. >cd rebar >bootstrap.bat Could Not Find rebar\ebin\rebar.beam Recompile: src/rebar Recompile: src/rebar_abnfc_compiler Recompile: src/rebar_app_utils Recompile: src/rebar_appups Recompile: src/rebar_asn1_compiler Recompile: src/rebar_base_compiler Recompile: src/rebar_cleaner Recompile: src/rebar_config Recompile: src/rebar_core Recompile: src/rebar_ct Recompile: src/rebar_deps Recompile: src/rebar_dia_compiler Recompile: src/rebar_edoc Recompile: src/rebar_erlc_compiler Recompile: src/rebar_erlydtl_compiler Recompile: src/rebar_escripter Recompile: src/rebar_eunit Recompile: src/rebar_file_utils Recompile: src/rebar_getopt Recompile: src/rebar_lfe_compiler Recompile: src/rebar_log Recompile: src/rebar_metacmds Recompile: src/rebar_mustache Recompile: src/rebar_neotoma_compiler Recompile: src/rebar_otp_app Recompile: src/rebar_port_compiler Recompile: src/rebar_protobuffs_compiler Recompile: src/rebar_qc Recompile: src/rebar_rel_utils Recompile: src/rebar_reltool Recompile: src/rebar_require_vsn Recompile: src/rebar_shell Recompile: src/rebar_subdirs Recompile: src/rebar_templater Recompile: src/rebar_upgrade Recompile: src/rebar_utils Recompile: src/rebar_xref ==> rebar (compile) Command 'escriptize' not understood or not applicable Congratulations! You now have a self-contained script called "rebar" in your current working directory. Place this script anywhere in your path and you can use rebar to build OTP-compliant apps. Despite the congratulatory message afterwards, there is no rebar file. Anyone know what?s wrong? Cheers, DBM -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok@REDACTED Wed Mar 19 02:13:21 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 19 Mar 2014 14:13:21 +1300 Subject: [erlang-questions] Unexpected list_to_binary behavior In-Reply-To: References: <078B6C97-4BE7-4968-BA05-C719809A5900@pixie.co.za> Message-ID: <562F3293-9BDD-4275-88F1-C3BEB9C57515@cs.otago.ac.nz> On 19/03/2014, at 3:15 AM, Valentin Micic wrote: > So, why should the other one be called: list_to_binary/1 instead instead of characters_to_binary/1 Because it converts a list of BYTES to a binary, and *doesn't* convert a list of characters to a binary. list_to_binary/1 is the opposite of binary_to_list/1. We do need ways to build binaries from data that never were characters to begin with! > > If one disregard the existence of any previous knowledge, and given that a list may contain any number of arbitrary types, including a list itself, what should be a reasonable expectation for (and here's the kicker -- not an input argument itself, for it is perfectly acceptable to assume it to be a list, but) a content of the input argument? How about "a reasonable expectation is what the documentation says"? From the documentation for the 'erlang' module: list_to_binary(IoList) -> binary() Types: IoList = iolist() Returns a binary which is made from the integers and binaries in IoList. where iolist() is defined as maybe_improper_list(byte() | binary() | iolist(), binary() | []) > It's surprising (at least was to me) to expect a content of an input argument ( formerly known as list ) The argument has been called IoList for some time. > to be limited to a list of octets, It isn't. It's limited to a tree whose leaves are byte values, binaries, or the empty list, and where [X|Y] is taken as concatenation. Why would it be surprising for a function to work the way it is documented? > > On the other hand, it is what it is, and, in a way, I am quite embarrassed that I assumed that integers would be automagically converted to appropriate number of octets, for this is just as unreasonable and arbitrary expectation. binary_to_list/1 has no way to tell what an "appropriate number of octets" might be. You can whip up whatever you want in a very few lines using bit syntax. From ok@REDACTED Wed Mar 19 05:08:23 2014 From: ok@REDACTED (Richard A. O'Keefe) Date: Wed, 19 Mar 2014 17:08:23 +1300 Subject: [erlang-questions] 14 seconds from disaster (was: Re: No JSON/MAPS interoperability in 17.0?) In-Reply-To: References: <20140314152012.GA95455@ferdair.local> <1394816683.57674.YahooMailNeo@web140105.mail.bf1.yahoo.com> Message-ID: <2776D15C-C821-45B2-8E65-8F22E2348522@cs.otago.ac.nz> On 19/03/2014, at 6:56 AM, Kenneth Lundin wrote: > Also note that we don't think that EEP-20 is a good idea in its present form. > EEP-20 "Split the atoms" introduces two types of atoms, and is invisible on the language level, but for the VM implementation and the characteristics it is dramatic. As EEP 20 notes, it describes a technique which has been implemented and used in a concurrent logic programming language. > Todays atoms are represented as immediates in todays VM meaning that no allocation on the heap is needed. > Many places in the VM code relies on that fact which makes it easy to se atom. In EEP-20 some atoms will be boxed types stored on the heap and this will change the impact on memory handling an memory consumption dramatically. Performance will also be impacted, negatively. It's certainly true that performance *might* be hurt, but it is very far from obvious that it *must* be so. On the other hand, I have evidence that *not* having collectable atoms *does* have a huge negative performance impact. I tried this on two machines with different CPUs and operating systems. 1> [if N rem 10000 == 0 -> io:write(N), io:nl(), A ; true -> A end 1> || N <- lists:seq(1,10000000), 1> A <- [list_to_atom(integer_to_list(N))]]. This tries to create 10,000,000 atoms, reporting every 10,000. After just 14 seconds 'beam.smp' goes to 95% CPU and stays there, busy doing oodles of system calls (including pthead_cond_wait) and getting nowhere. *That* is a negative performance impact. When people use <<"foo">> instead of 'foo', they are in effect implementing EEP 20 by hand, inconsistently, and without the benefit of the performance hacks that can go into a low-level implementation. From chandrashekhar.mullaparthi@REDACTED Wed Mar 19 06:05:06 2014 From: chandrashekhar.mullaparthi@REDACTED (Chandru) Date: Wed, 19 Mar 2014 05:05:06 +0000 Subject: [erlang-questions] Mnesia cluster across releases In-Reply-To: References: Message-ID: On 18 March 2014 21:38, Daniel Dormont wrote: > Hi all, > > Can a Mnesia cluster exist across two OTP releases, specifically R15B > and R16B? I'm testing some upgrades here and seeing this error about > two minutes after trying to join a node running R16B to an existing > cluster running R15B: > The simplest way to test this is to try this on two standalone nodes, one running R15B and the other R16B. I've tried this, and had no problem joining an R15B-1 node into an R16B-2 node. You say "trying to join", how exactly are you doing this? When a node joins an existing mnesia installation, it should not have a schema of its own. Chandru > =ERROR REPORT==== 2014-03-18 17:13:29 === > Mnesia('ejabberd@REDACTED'): ** ERROR ** (core > dumped to file: > "/var/lib/ejabberd/MnesiaCore.ejabberd@REDACTED") > ** FATAL ** Schema update error {{badmatch, > {error, > {bad_object_header, > "/var/lib/ejabberd/schema.DAT"}}}, > [{mnesia_dumper,dets_insert,4, > > [{file,"mnesia_dumper.erl"},{line,342}]}, > {mnesia_dumper,insert_cstruct,5, > > [{file,"mnesia_dumper.erl"},{line,1117}]}, > {mnesia_dumper,insert_ops,6, > > [{file,"mnesia_dumper.erl"},{line,309}]}, > {mnesia_dumper,perform_update,4, > > [{file,"mnesia_dumper.erl"},{line,292}]}, > {mnesia_dumper,update,3, > > [{file,"mnesia_dumper.erl"},{line,273}]}, > {mnesia_tm,do_commit,3, > [{file,"mnesia_tm.erl"},{line,1780}]}, > {mnesia_tm,commit_participant,6, > > [{file,"mnesia_tm.erl"},{line,1699}]}]} [{op, > > merge_schema, > > [{name, > > ... etc. > > If not, are there strategies for dealing with such an upgrade? Or is > this caused by something else entirely? > > Thanks, > Dan > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kostis@REDACTED Wed Mar 19 08:01:26 2014 From: kostis@REDACTED (Kostis Sagonas) Date: Wed, 19 Mar 2014 08:01:26 +0100 Subject: [erlang-questions] 14 seconds from disaster In-Reply-To: <2776D15C-C821-45B2-8E65-8F22E2348522@cs.otago.ac.nz> References: <20140314152012.GA95455@ferdair.local> <1394816683.57674.YahooMailNeo@web140105.mail.bf1.yahoo.com> <2776D15C-C821-45B2-8E65-8F22E2348522@cs.otago.ac.nz> Message-ID: <532940C6.2060007@cs.ntua.gr> On 03/19/2014 05:08 AM, Richard A. O'Keefe wrote: > I tried this on two machines with different CPUs and operating systems. > > 1> [if N rem 10000 == 0 -> io:write(N), io:nl(), A ; true -> A end > 1> || N <- lists:seq(1,10000000), > 1> A <- [list_to_atom(integer_to_list(N))]]. > > This tries to create 10,000,000 atoms, reporting every 10,000. > > After just 14 seconds 'beam.smp' goes to 95% CPU and stays there, > busy doing oodles of system calls (including pthead_cond_wait) > and getting nowhere. > > *That* is a negative performance impact. Your experiment has very little to do with performance. What happens after 14 seconds in your machine is that the VM crashes because it exceeds the the maximum number of index entries in the atom table (whose default value is 1048576). For better or worse, the system then tries to write a huge erl_crash.dump file and this naturally takes long. Of course this is not nice, but has nothing to do with VM performance for `normal' program execution; it has to do with what happens when the VM crashes. Kostis From dgud@REDACTED Wed Mar 19 08:14:21 2014 From: dgud@REDACTED (Dan Gudmundsson) Date: Wed, 19 Mar 2014 08:14:21 +0100 Subject: [erlang-questions] Mnesia cluster across releases Message-ID: Me and Wiger managed to mess up the upgrades for a while, see mnesia rel notes between 4.4.18-4.5.1 otherwise it should work. But bad_object_header might to be something else though..looks like the dets file is corrupt or? /Dan On Wed, Mar 19, 2014 at 6:05 AM, Chandru < chandrashekhar.mullaparthi@REDACTED> wrote: > On 18 March 2014 21:38, Daniel Dormont wrote: > >> Hi all, >> >> Can a Mnesia cluster exist across two OTP releases, specifically R15B >> and R16B? I'm testing some upgrades here and seeing this error about >> two minutes after trying to join a node running R16B to an existing >> cluster running R15B: >> > > The simplest way to test this is to try this on two standalone nodes, one > running R15B and the other R16B. I've tried this, and had no problem > joining an R15B-1 node into an R16B-2 node. > > You say "trying to join", how exactly are you doing this? When a node > joins an existing mnesia installation, it should not have a schema of its > own. > > Chandru > > >> =ERROR REPORT==== 2014-03-18 17:13:29 === >> Mnesia('ejabberd@REDACTED'): ** ERROR ** (core >> dumped to file: >> "/var/lib/ejabberd/MnesiaCore.ejabberd@REDACTED") >> ** FATAL ** Schema update error {{badmatch, >> {error, >> {bad_object_header, >> "/var/lib/ejabberd/schema.DAT"}}}, >> [{mnesia_dumper,dets_insert,4, >> >> [{file,"mnesia_dumper.erl"},{line,342}]}, >> {mnesia_dumper,insert_cstruct,5, >> >> [{file,"mnesia_dumper.erl"},{line,1117}]}, >> {mnesia_dumper,insert_ops,6, >> >> [{file,"mnesia_dumper.erl"},{line,309}]}, >> {mnesia_dumper,perform_update,4, >> >> [{file,"mnesia_dumper.erl"},{line,292}]}, >> {mnesia_dumper,update,3, >> >> [{file,"mnesia_dumper.erl"},{line,273}]}, >> {mnesia_tm,do_commit,3, >> [{file,"mnesia_tm.erl"},{line,1780}]}, >> {mnesia_tm,commit_participant,6, >> >> [{file,"mnesia_tm.erl"},{line,1699}]}]} [{op, >> >> merge_schema, >> >> [{name, >> >> ... etc. >> >> If not, are there strategies for dealing with such an upgrade? Or is >> this caused by something else entirely? >> >> Thanks, >> Dan >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dch@REDACTED Wed Mar 19 09:02:31 2014 From: dch@REDACTED (Dave Cottlehuber) Date: Wed, 19 Mar 2014 09:02:31 +0100 Subject: [erlang-questions] Rebar help In-Reply-To: <001e01cf42f7$90840440$b18c0cc0$@gmail.com> References: <001e01cf42f7$90840440$b18c0cc0$@gmail.com> Message-ID: On 18. M?rz 2014 at 23:15:38, David Mercer (dmercer@REDACTED) wrote: > I am trying to hop on the rebar bandwagon, but cannot seem to get it to compile. I am following > the instructions at https://github.com/rebar/rebar. On Windows 7, I did the following. > Error highlighted below: > > Command 'escriptize' not understood or not applicable > > Congratulations! You now have a self-contained script called "rebar" in > > your current working directory. Place this script anywhere in your path > > and you can use rebar to build OTP-compliant apps. > > > > Despite the congratulatory message afterwards, there is no rebar file. Anyone know > what?s wrong? Not yet, but it doesn?t work for me, which it used to do :-), same issue. In the meantime, I usually have a pre-built one here; http://people.apache.org/~dch/dist/tools/ It?s not absolute latest rebar but it should work for most projects, built from R14B04 so it should work everywhere. Just drop it in your path. I?m travelling today but will take a look early next week unless somebody else gets to it first. BTW I?d like to see rebar do the same thing as in erica, https://github.com/benoitc/erica/blob/master/bootstrap#L45-L56 where the unix version creates a working windows one. It makes it very easy to maintain a working version for both platforms without actually having to use windows ;-). -- Dave Cottlehuber Sent from my PDP11 From bchesneau@REDACTED Wed Mar 19 09:16:05 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Wed, 19 Mar 2014 09:16:05 +0100 Subject: [erlang-questions] erlang + systemd Message-ID: Hi all, I am looking for a simple way to launch an erlang release using systemd and in particularly using the socket activations possibilities. Form my understanding epmd is not systemd aware for now. Eclus [1] allows to do that. Is there any other tool around? Did someone start to patch the vm? - benoit [1] https://github.com/goerlang/eclus From lemenkov@REDACTED Wed Mar 19 09:29:51 2014 From: lemenkov@REDACTED (Peter Lemenkov) Date: Wed, 19 Mar 2014 12:29:51 +0400 Subject: [erlang-questions] erlang + systemd In-Reply-To: References: Message-ID: 2014-03-19 12:16 GMT+04:00 Benoit Chesneau : > Hi all, > > I am looking for a simple way to launch an erlang release using > systemd and in particularly using the socket activations > possibilities. > > Form my understanding epmd is not systemd aware for now. Eclus [1] > allows to do that. Is there any other tool around? Did someone start > to patch the vm? There are two things which are necessary. First one is to allow socket activation in Erlang Port mapping Daemon as you said. There are two possible ways to do so - either replace stock epmd with eclus (which works quite well and offers you a few more nice things - d-bus publishing/subscribing etc), or apply this patch to the epmd made by Matwey Kornilov - https://github.com/matwey/otp/tree/systemd . Matwey's approach looks slightly better in a short term since eclus won't work on a obscure architectures such as PowerPC / Tilera / MIPS / s390x, so we're going to apply Matwey's patch in Fedora / RHEL 7. After one fixes an issue with epmd, there is another necessary thingto do - to pass sockets to Erlang releases. It looks possible and gen_udp/gen_tcp already has an option to re-use fd opened elsewhere (see {fd, integer()} option). But I'm not sure if it works with systemd or not. -- With best regards, Peter Lemenkov. From dch@REDACTED Wed Mar 19 09:36:52 2014 From: dch@REDACTED (Dave Cottlehuber) Date: Wed, 19 Mar 2014 09:36:52 +0100 Subject: [erlang-questions] Rebar help In-Reply-To: References: <001e01cf42f7$90840440$b18c0cc0$@gmail.com> Message-ID: On 19. M?rz 2014 at 09:02:44, Dave Cottlehuber (dch@REDACTED) wrote: > On 18. M?rz 2014 at 23:15:38, David Mercer (dmercer@REDACTED) wrote: > > I am trying to hop on the rebar bandwagon, but cannot seem to get it to compile. I am following > > the instructions at https://github.com/rebar/rebar. On Windows 7, I did the following. > > Error highlighted below: > > > > Command 'escriptize' not understood or not applicable > > > > Congratulations! You now have a self-contained script called "rebar" in > > > > your current working directory. Place this script anywhere in your path > > > > and you can use rebar to build OTP-compliant apps. > > > > > > > > Despite the congratulatory message afterwards, there is no rebar file. Anyone know > > what?s wrong? > > Not yet, but it doesn?t work for me, which it used to do :-), same issue. > > In the meantime, I usually have a pre-built one here; > > http://people.apache.org/~dch/dist/tools/ > > It?s not absolute latest rebar but it should work for most projects, built from R14B04 > so it should work everywhere. Just drop it in your path. Hi David, I ran git bisect, logged an issue at rebar?https://github.com/rebar/rebar/issues/250 and updated the binary at http://people.apache.org/~dch/dist/tools/ You should be good to go, or you can build yourself off #fa1a2b5, it?s ~ 2 weeks ago. -- Dave Cottlehuber Sent from my PDP11 From ulf@REDACTED Wed Mar 19 09:39:44 2014 From: ulf@REDACTED (Ulf Wiger) Date: Wed, 19 Mar 2014 09:39:44 +0100 Subject: [erlang-questions] Mnesia cluster across releases In-Reply-To: References: Message-ID: <2E0C627C-A7B5-4ECC-9F99-D4EFF540667C@feuerlabs.com> On 19 Mar 2014, at 08:14, Dan Gudmundsson wrote: > Me and Wiger managed to mess up the upgrades for a while, see mnesia rel notes between 4.4.18-4.5.1 otherwise it should work. Hehe, yes, it was a team effort. :) BR, Ulf W Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc. http://feuerlabs.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Wed Mar 19 14:35:41 2014 From: sean@REDACTED (Sean Cribbs) Date: Wed, 19 Mar 2014 08:35:41 -0500 Subject: [erlang-questions] Rebar help In-Reply-To: References: <001e01cf42f7$90840440$b18c0cc0$@gmail.com> Message-ID: On Wed, Mar 19, 2014 at 3:02 AM, Dave Cottlehuber wrote: > > BTW I?d like to see rebar do the same thing as in erica, > https://github.com/benoitc/erica/blob/master/bootstrap#L45-L56 where the > unix version creates a working windows one. It makes it very easy to > maintain a working version for both platforms without actually having to > use windows ;-). > If it's a simple change, we encourage pull-requests: github.com/rebar/rebar. There's also a rebar mailing list where these things can be discussed: http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan@REDACTED Wed Mar 19 16:05:22 2014 From: dan@REDACTED (Daniel Dormont) Date: Wed, 19 Mar 2014 11:05:22 -0400 Subject: [erlang-questions] Mnesia cluster across releases In-Reply-To: References: Message-ID: So it turns out my problem may be more specific. What happened now is that I have a particular table where the only copy of that table was on a node that was shut down and is now lost. Is there any way to recover from that? I'm ok with completely deleting the table from the schema but a simple mnesia:delete_table(tabname). results in {aborted,{no_exists,tabname}} Anything I can do there, or is my whole schema screwed? On Wed, Mar 19, 2014 at 1:05 AM, Chandru wrote: > On 18 March 2014 21:38, Daniel Dormont wrote: >> >> Hi all, >> >> Can a Mnesia cluster exist across two OTP releases, specifically R15B >> and R16B? I'm testing some upgrades here and seeing this error about >> two minutes after trying to join a node running R16B to an existing >> cluster running R15B: > > > The simplest way to test this is to try this on two standalone nodes, one > running R15B and the other R16B. I've tried this, and had no problem joining > an R15B-1 node into an R16B-2 node. > > You say "trying to join", how exactly are you doing this? When a node joins > an existing mnesia installation, it should not have a schema of its own. > > Chandru > >> >> =ERROR REPORT==== 2014-03-18 17:13:29 === >> Mnesia('ejabberd@REDACTED'): ** ERROR ** (core >> dumped to file: >> "/var/lib/ejabberd/MnesiaCore.ejabberd@REDACTED") >> ** FATAL ** Schema update error {{badmatch, >> {error, >> {bad_object_header, >> "/var/lib/ejabberd/schema.DAT"}}}, >> [{mnesia_dumper,dets_insert,4, >> >> [{file,"mnesia_dumper.erl"},{line,342}]}, >> {mnesia_dumper,insert_cstruct,5, >> >> [{file,"mnesia_dumper.erl"},{line,1117}]}, >> {mnesia_dumper,insert_ops,6, >> >> [{file,"mnesia_dumper.erl"},{line,309}]}, >> {mnesia_dumper,perform_update,4, >> >> [{file,"mnesia_dumper.erl"},{line,292}]}, >> {mnesia_dumper,update,3, >> >> [{file,"mnesia_dumper.erl"},{line,273}]}, >> {mnesia_tm,do_commit,3, >> [{file,"mnesia_tm.erl"},{line,1780}]}, >> {mnesia_tm,commit_participant,6, >> >> [{file,"mnesia_tm.erl"},{line,1699}]}]} [{op, >> >> merge_schema, >> >> [{name, >> >> ... etc. >> >> If not, are there strategies for dealing with such an upgrade? Or is >> this caused by something else entirely? >> >> Thanks, >> Dan >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From dmercer@REDACTED Wed Mar 19 20:25:04 2014 From: dmercer@REDACTED (David Mercer) Date: Wed, 19 Mar 2014 14:25:04 -0500 Subject: [erlang-questions] Rebar help In-Reply-To: References: <001e01cf42f7$90840440$b18c0cc0$@gmail.com> Message-ID: <007301cf43a8$ee4b4230$cae1c690$@gmail.com> On Wednesday, March 19, 2014, Dave Cottlehuber wrote: > I ran git bisect, logged an issue at > rebar https://github.com/rebar/rebar/issues/250 and updated the binary at > http://people.apache.org/~dch/dist/tools/ > > You should be good to go, or you can build yourself off #fa1a2b5, it?s ~ > 2 weeks ago. Thank-you. I just grabbed the binary, and it seems to work. Anyone know a good tutorial or user manual for rebar? > Dave Cottlehuber > Sent from my PDP11 Really? Does Erlang run on the PDP, or was that a joke? Cheers, DBM From sean@REDACTED Wed Mar 19 20:34:37 2014 From: sean@REDACTED (Sean Cribbs) Date: Wed, 19 Mar 2014 14:34:37 -0500 Subject: [erlang-questions] Rebar help In-Reply-To: <007301cf43a8$ee4b4230$cae1c690$@gmail.com> References: <001e01cf42f7$90840440$b18c0cc0$@gmail.com> <007301cf43a8$ee4b4230$cae1c690$@gmail.com> Message-ID: This should help: https://github.com/rebar/rebar/wiki On Wed, Mar 19, 2014 at 2:25 PM, David Mercer wrote: > On Wednesday, March 19, 2014, Dave Cottlehuber wrote: > > > I ran git bisect, logged an issue at > > rebar https://github.com/rebar/rebar/issues/250 and updated the binary > at > > http://people.apache.org/~dch/dist/tools/ > > > > You should be good to go, or you can build yourself off #fa1a2b5, it?s ~ > > 2 weeks ago. > > Thank-you. I just grabbed the binary, and it seems to work. Anyone know > a good tutorial or user manual for rebar? > > > Dave Cottlehuber > > Sent from my PDP11 > > Really? Does Erlang run on the PDP, or was that a joke? > > Cheers, > > DBM > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean@REDACTED Thu Mar 20 00:23:50 2014 From: sean@REDACTED (Sean Cribbs) Date: Wed, 19 Mar 2014 18:23:50 -0500 Subject: [erlang-questions] [ANN] eunit_formatters Message-ID: Let's face it, the output from eunit is pretty awful, even with the 'verbose' flag on. It's not made for average humans. I got fed up and created a new tool to ease my pain: https://github.com/seancribbs/eunit_formatters Its main features are: * Prints progress through the test suite on a single line as dots (Pass), asterisks (Skipped), and 'F' (Failure/exception). * At the end of the suite: * Prints skipped tests and groups * Prints test failures; built-in eunit assertions have more human-friendly text * Prints the top 10 slowest tests (as determined by wall-clock time) * Summarizes the time elapsed and the success or failure status * Optionally prints output in color via ANSI-escape sequences Instructions for how to set it up with a rebar-based project are included in the README. Those of you who have used the RSpec runner in Ruby will recognize the formatting, I basically mimiced it. There's lots still to do here, but I hope people can try this on their projects, start tinkering with the code, and help me improve it. Pull-requests are encouraged. Cheers, -- Sean Cribbs Software Engineer Basho Technologies, Inc. http://basho.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan@REDACTED Thu Mar 20 13:15:04 2014 From: dan@REDACTED (Daniel Dormont) Date: Thu, 20 Mar 2014 08:15:04 -0400 Subject: [erlang-questions] Mnesia cluster across releases In-Reply-To: References: Message-ID: Sorry, it turns out I was wrong. What happens is that when I have a node already in the cluster running R16B, and I add a second one, the first one crashes while merging the schemas with the error above. I did some Googling around - looks like this may have been a problem with R16B01 that was later fixed in R16B03? I'm running Ubuntu 13.10 and that's what it came with. On Wed, Mar 19, 2014 at 11:05 AM, Daniel Dormont wrote: > So it turns out my problem may be more specific. What happened now is > that I have a particular table where the only copy of that table was > on a node that was shut down and is now lost. Is there any way to > recover from that? I'm ok with completely deleting the table from the > schema but a simple > > mnesia:delete_table(tabname). > > results in > > {aborted,{no_exists,tabname}} > > Anything I can do there, or is my whole schema screwed? > > On Wed, Mar 19, 2014 at 1:05 AM, Chandru > wrote: >> On 18 March 2014 21:38, Daniel Dormont wrote: >>> >>> Hi all, >>> >>> Can a Mnesia cluster exist across two OTP releases, specifically R15B >>> and R16B? I'm testing some upgrades here and seeing this error about >>> two minutes after trying to join a node running R16B to an existing >>> cluster running R15B: >> >> >> The simplest way to test this is to try this on two standalone nodes, one >> running R15B and the other R16B. I've tried this, and had no problem joining >> an R15B-1 node into an R16B-2 node. >> >> You say "trying to join", how exactly are you doing this? When a node joins >> an existing mnesia installation, it should not have a schema of its own. >> >> Chandru >> >>> >>> =ERROR REPORT==== 2014-03-18 17:13:29 === >>> Mnesia('ejabberd@REDACTED'): ** ERROR ** (core >>> dumped to file: >>> "/var/lib/ejabberd/MnesiaCore.ejabberd@REDACTED") >>> ** FATAL ** Schema update error {{badmatch, >>> {error, >>> {bad_object_header, >>> "/var/lib/ejabberd/schema.DAT"}}}, >>> [{mnesia_dumper,dets_insert,4, >>> >>> [{file,"mnesia_dumper.erl"},{line,342}]}, >>> {mnesia_dumper,insert_cstruct,5, >>> >>> [{file,"mnesia_dumper.erl"},{line,1117}]}, >>> {mnesia_dumper,insert_ops,6, >>> >>> [{file,"mnesia_dumper.erl"},{line,309}]}, >>> {mnesia_dumper,perform_update,4, >>> >>> [{file,"mnesia_dumper.erl"},{line,292}]}, >>> {mnesia_dumper,update,3, >>> >>> [{file,"mnesia_dumper.erl"},{line,273}]}, >>> {mnesia_tm,do_commit,3, >>> [{file,"mnesia_tm.erl"},{line,1780}]}, >>> {mnesia_tm,commit_participant,6, >>> >>> [{file,"mnesia_tm.erl"},{line,1699}]}]} [{op, >>> >>> merge_schema, >>> >>> [{name, >>> >>> ... etc. >>> >>> If not, are there strategies for dealing with such an upgrade? Or is >>> this caused by something else entirely? >>> >>> Thanks, >>> Dan >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> >> From erlangsiri@REDACTED Thu Mar 20 16:24:30 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Thu, 20 Mar 2014 16:24:30 +0100 Subject: [erlang-questions] common_test test case documentation In-Reply-To: <531F59D5.8080208@ninenines.eu> References: <531F596E.3030405@ninenines.eu> <531F59D5.8080208@ninenines.eu> Message-ID: There is also ct:comment/1,2 which could be called at the beginning of the test case. Note that subsequent calls to this function, or the return value {comment,""}, will overwrite previous calls. And it does not necessarily look very nice when a test fails... /siri 2014-03-11 19:45 GMT+01:00 Lo?c Hoguin : > And of course I made a mistake in one example. Sorry. > > > On 03/11/2014 07:43 PM, Lo?c Hoguin wrote: > >> testcase3() -> ?TEST_HERE, {comment, "docs here"}. >> > > The above should read: > > testcase3(Config) -> ?TEST_HERE, {comment, "docs here"}. > > > -- > Lo?c Hoguin > http://ninenines.eu > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reiddraper@REDACTED Thu Mar 20 19:38:50 2014 From: reiddraper@REDACTED (Reid Draper) Date: Thu, 20 Mar 2014 13:38:50 -0500 Subject: [erlang-questions] escript argument encoding Message-ID: I?m running into an issue where OSX and Linux seem to treat the command-line arguments to an escript differently. Using the following escript: #!/usr/bin/env escript %% -*- erlang -*- %%! +pc unicode main([Args]) -> io:setopts([{encoding, utf8}]), io:format("~w~n", [Args]), io:format("~ts~n", [Args]). Both my OSX and Linux (Ubuntu 13.10) boxes have their LANG set to en_US.UTF-8. I?m running the escript like so: ./sample.escript ???? On OSX, the escript seems to treat `Args` as a list of unicode code-points: ./sample.escript ???? [1587,1604,1575,1605] ???? On Linux, it seems to treat the input as a list of UTF-8 bytes, where each byte is turned into an integer. The Erlang unicode guide calls this a 'Lists of UTF-8 Bytes' [1]. ./sample.escript ???? [216,179,217,132,216,167,217,133] ??????? How does I get both OSX and Linux to treat the input of the escript as a list of code-points? Thanks, Reid [1] http://www.erlang.org/doc/apps/stdlib/unicode_usage.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Thu Mar 20 19:42:24 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Thu, 20 Mar 2014 19:42:24 +0100 Subject: [erlang-questions] escript argument encoding In-Reply-To: References: Message-ID: Take a look at the +fnu flags: http://erlang.org/doc/man/erl.html *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Thu, Mar 20, 2014 at 7:38 PM, Reid Draper wrote: > I?m running into an issue where OSX and Linux seem to treat the > command-line arguments to an escript differently. Using the following > escript: > > #!/usr/bin/env escript > %% -*- erlang -*- > %%! +pc unicode > > main([Args]) -> > io:setopts([{encoding, utf8}]), > io:format("~w~n", [Args]), > io:format("~ts~n", [Args]). > > Both my OSX and Linux (Ubuntu 13.10) boxes have their LANG set > to en_US.UTF-8. I?m running the escript like so: > > ./sample.escript ???? > > On OSX, the escript seems to treat `Args` as a list of unicode code-points: > > ./sample.escript ???? > [1587,1604,1575,1605] > ???? > > On Linux, it seems to treat the input as a list of UTF-8 bytes, where each > byte is turned into an integer. The Erlang unicode guide calls this a > 'Lists of UTF-8 Bytes' [1]. > > ./sample.escript ???? > [216,179,217,132,216,167,217,133] > ???????? > > How does I get both OSX and Linux to treat the input of the escript as a > list of code-points? > > Thanks, > Reid > > [1] http://www.erlang.org/doc/apps/stdlib/unicode_usage.html > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reiddraper@REDACTED Thu Mar 20 23:42:42 2014 From: reiddraper@REDACTED (Reid Draper) Date: Thu, 20 Mar 2014 17:42:42 -0500 Subject: [erlang-questions] escript argument encoding In-Reply-To: References: Message-ID: <0CCEC3FA-1E82-449B-A706-CAB2DCB73052@gmail.com> Thanks. +fnu solved it for me. Reid On Mar 20, 2014, at 1:42 PM, Jos? Valim wrote: > Take a look at the +fnu flags: > > http://erlang.org/doc/man/erl.html > > > > Jos? Valim > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Mar 20, 2014 at 7:38 PM, Reid Draper wrote: > I?m running into an issue where OSX and Linux seem to treat the command-line arguments to an escript differently. Using the following escript: > > #!/usr/bin/env escript > %% -*- erlang -*- > %%! +pc unicode > > main([Args]) -> > io:setopts([{encoding, utf8}]), > io:format("~w~n", [Args]), > io:format("~ts~n", [Args]). > > Both my OSX and Linux (Ubuntu 13.10) boxes have their LANG set to en_US.UTF-8. I?m running the escript like so: > > ./sample.escript ???? > > On OSX, the escript seems to treat `Args` as a list of unicode code-points: > > ./sample.escript ???? > [1587,1604,1575,1605] > ???? > > On Linux, it seems to treat the input as a list of UTF-8 bytes, where each byte is turned into an integer. The Erlang unicode guide calls this a 'Lists of UTF-8 Bytes' [1]. > > ./sample.escript ???? > [216,179,217,132,216,167,217,133] > ???????? > > How does I get both OSX and Linux to treat the input of the escript as a list of code-points? > > Thanks, > Reid > > [1] http://www.erlang.org/doc/apps/stdlib/unicode_usage.html > > > > > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From barcojie@REDACTED Fri Mar 21 01:54:01 2014 From: barcojie@REDACTED (Barco You) Date: Fri, 21 Mar 2014 08:54:01 +0800 Subject: [erlang-questions] =?gb2312?b?W0VybGFuZy1xdWVzdGlvbnNdILjfvLZF?= =?gb2312?b?cmxhbme/qreiuaSzzMqm?= Message-ID: ??????????????????????????????????????????????????????????????Functional Programming???????Erlang????????????????????0755-83597260 mprtimes@REDACTED ??? ??Erlang????? ????? 1. ??????????????????????????? 2. ??????????????? 3. ??erlang??????????? ????? 1???erlang?????OTP???????????????Functional Programming???? 2???HTTP?TCP/IP???? 3???????????????? 4???RDBMS????????Nosql????Mysql?Postgresql???????? 5???????????? 6???????????????? 7?????????? 8???Linux???????????????????? 9????????????/????????????? 10?????????????????????????????????????????????? 11??????????? 12???????????????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjtruog@REDACTED Fri Mar 21 05:32:46 2014 From: mjtruog@REDACTED (Michael Truog) Date: Thu, 20 Mar 2014 21:32:46 -0700 Subject: [erlang-questions] Unix domain sockets In-Reply-To: <67cd4667-b605-4fb6-a058-28ad07a24b98@googlegroups.com> References: <3dbc6d1c0903040223w5a079909j8e8851332521efa3@mail.gmail.com> <67cd4667-b605-4fb6-a058-28ad07a24b98@googlegroups.com> Message-ID: <532BC0EE.70303@gmail.com> I also am disappointed that unix domain sockets lack support, but I am also disappointed there are more internal checks to prevent their use now. I have been able to graft on support, but it isn't pretty (since it needs to avoid the internal prim_inet checks): https://github.com/CloudI/CloudI/blob/master/src/lib/cloudi_core/src/cloudi_services_external.erl#L1342-L1375 https://github.com/CloudI/CloudI/blob/master/src/lib/cloudi_core/cxx_src/cloudi_socket_drv.cpp When I add unix domain sockets this way, I do get an internal ERTS thread stuck at 100% CPU (somehow stuck in a tight loop) for unknown reasons, but it works fine otherwise. On 03/19/2014 04:13 PM, James wrote: > > five years later... and there is still no support for uds, only the uds_dist example, which does not even build on linux as it was evidently created for solaris. > > > > > On Wednesday, March 4, 2009 5:23:21 AM UTC-5, rvirding wrote: > > I just saw a lament in twitter that Erlang doesn't support Unix domain sockets. Is that so? If not is there a nice link to some documentation explaining that we do and how to do it? > > Robert > > -- > Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting. > --- > You received this message because you are subscribed to the Google Groups "Erlang Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programming+unsubscribe@REDACTED . > To post to this group, send email to erlang-programming@REDACTED . > Visit this group at http://groups.google.com/group/erlang-programming. > For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jozsef.berces@REDACTED Fri Mar 21 06:15:57 2014 From: jozsef.berces@REDACTED (=?iso-8859-1?Q?J=F3zsef_B=E9rces?=) Date: Fri, 21 Mar 2014 05:15:57 +0000 Subject: [erlang-questions] eheap cannot allocate for which process? In-Reply-To: <20140317154845.GA24082@ferdmbp.local> References: <7460EBDDCF52084A849D0F271CE059B8098E07ED@ESESSMB101.ericsson.se> <20140317145746.GA1507@snar.spb.ru> <20140317154845.GA24082@ferdmbp.local> Message-ID: <7460EBDDCF52084A849D0F271CE059B8098E58F1@ESESSMB101.ericsson.se> Thanks for all the replies so far. I played a bit with recon and I see huge gap between the allocated and used memory: 28> recon_alloc:memory(used). 368489488 29> recon_alloc:memory(allocated). 15139661416 30> recon_alloc:memory(unused). 14757773688 31> recon_alloc:memory(allocated_types,current). [{binary_alloc,199241928}, {driver_alloc,950472}, {eheap_alloc,438374600}, {ets_alloc,14441853128}, {fix_alloc,9117896}, {ll_alloc,33554472}, {sl_alloc,164040}, {std_alloc,7545032}, {temp_alloc,655560}] 32> recon_alloc:memory(allocated_instances,current). [{0,43327848}, {1,5131874624}, {2,5086572864}, {3,4623593792}, {4,246088000}] 33> erlang:memory(). [{total,399193088}, {processes,259732526}, {processes_used,259670741}, {system,139460562}, {atom,512601}, {atom_used,501488}, {binary,62563168}, {code,21154095}, {ets,41092024}] There is more than 14GB memory unused. This is the status even hours after the heavy workers finished and exited. Should not the VM return at least a portion of the unused mem to the OS after a while? It seems it is because of ETS. ets_alloc is about 14GB whilst ets (from erlang:memory/0) is only about 40MB. I use R15B01. Can I expect smaller gaps if I upgrade the VM? Thanks, Jozsef -----Original Message----- From: Fred Hebert [mailto:mononcqc@REDACTED] Sent: Monday, March 17, 2014 22:49 To: Alexandre Snarskii Cc: J?zsef B?rces; erlang-questions@REDACTED Subject: Re: [erlang-questions] eheap cannot allocate for which process? For this issue, see the format_status callback OTP behaviours contain: http://www.erlang.org/doc/man/gen_server.html#Module:format_status-2 They should let you do things the way you want and reduce the size of the messages logged. More generally, however, if you need to dig into a crash dump, I recommend using the scripts I added to recon: https://github.com/ferd/recon/tree/master/script One of them will do a quick diagnostic over the crashdump and output the info I've always found useful while debugging, and the awk script will output all functions that were running if mailboxes were huge. If the node is still running when you see problems appearing, I'd suggest looking into recon as a whole (docs: http://ferd.github.io/recon/) and see if the issues can be related to the total memory size and how it's allocated (see recon_alloc), binary memory "leaks" (see recon:bin_leak/1), and so on. The binary memory stuff wouldn't necessarily surprise me if you find out GCs tend to solve problems, but that's always system-specific. Regards, Fred. On 03/17, Alexandre Snarskii wrote: > On Mon, Mar 17, 2014 at 08:51:13AM +0000, J?zsef B?rces wrote: > > I receive the classic ?eheap_alloc: Cannot allocate?? message. It > > wants to allocate ~1GB memory and that fails. That is fine, I am doing something wrong. > > So I took the crash dump and tried to find out which one of my > > processes is the guilty one. > > Some months ago I've had a similar problem: application running > happily with ~400Mb RAM (on 2Gb RAM host) mostly consisting of four > "major consumers" ("huge state" FSMs, ~80Mb each) started crashing > with the same eheap_alloc: Cannot allocate 729810240 bytes of memory (of type "heap"). > message. After some investigation (and switching from stock SASL > error_logger to lager) I found that "guilty" processes were > error_logger and gproc and that this problem is a bit deeper. > > Some screens: after FSM crash, restart and rebuilding its state I saw: > > Pid Initial Call Heap Reds Msgs > Registered Current Function Stack > <0.5.0> gen_event:init_it/6 59786060 5199822 0 > error_logger gen_event:fetch_msg/5 8 > <0.47.0> gproc:init/1 19590700 1650033 0 > gproc gen_server:loop/6 9 > <0.221.0> ebgp_conn:init/1 19590700 20382184 0 > gen_fsm:loop/7 10 > > where 0.221.0 is my "fat FSM" after crash, restart and "state download". > process_info(pid(0,5,0)) shows > > {total_heap_size,107614910}, > {heap_size,59786060}, > {stack_size,8}, > {reductions,5199822}, > {garbage_collection,[{min_bin_vheap_size,46368}, > {min_heap_size,233}, > {fullsweep_after,65535}, > {minor_gcs,1}]}, > > but after manual call to garbage_collect(pid(0, 5, 0)) heap usage > decreased significantly: > > {total_heap_size,233}, > {heap_size,233}, > {stack_size,8}, > {reductions,5199822}, > > and the same memory decrease happened with gproc. > > How can I explain VM crash (not 100% sure, still consider myself as a > novice in Erlang): when process crashes, it's state sent to all > processes monitoring this one (gproc in this case) and to > error_logger. State is big in my case (and in yours too). And there are no shared memory in Erlang. > So, it's pretty logical that state of failed process was duplicated > (may be even triplicated if copy happens while original process heap > is not freed at this moment) and this duplication can cause eheap error. > Especially in case when more than one "fat" process crashes instantly.. > > Lesson learned: while "let it crash" approach is generally good, it is > not so good with "fat" processes, especially with heavily > linked/monitored "fat" processes. > > PS: and error_logger and gproc are of course not guilty. They just > efficient enough, so their garbage collector was not yet called. > > > > > > > > > > Unfortunately, I cannot tell it from the crash dump. > > > > > > > > The memory section says: > > > > =memory > > > > total: 15447352528 > > > > processes: 15140232809 > > > > processes_used: 15140005610 > > > > system: 307119719 > > > > atom: 512601 > > > > atom_used: 496586 > > > > binary: 148574400 > > > > code: 21228007 > > > > ets: 119988984 > > > > > > > > I have 16GB RAM, so the processes use almost all. There are 4010 > > processes. 1 garbing, 31 scheduled, 3978 waiting. If I sum > > stack+heap of all the processes then I get ~700MB. That is very far > > from 16GB. Here are the top 10 stack+heap > > processes: > > > > Pid State Reductions Stack+heap MsgQ Length > > > > Garbing (limited 1,508,838,180 145,962,050 1 > > <0.21060.67> info) > > > > <0.25689.27> Waiting 86,670,344 145,962,050 0 > > > > <0.10003.68> Waiting 1,363,039 38,263,080 0 > > > > <0.15943.66> Waiting 1,882,465,380 30,610,465 0 > > > > <0.15879.68> Waiting 471,549 30,610,465 0 > > > > <0.31854.67> Waiting 154,500,777 24,488,375 0 > > > > <0.16221.68> Waiting 262,114 24,488,375 0 > > > > <0.16628.68> Waiting 117,268 24,488,375 0 > > > > <0.15878.68> Waiting 453,490 19,590,700 0 > > > > <0.16235.68> Waiting 181,968 19,590,700 0 > > > > > > > > > > Any ideas how to tell which process needs ~1GB memory? > > > > > > > > Thanks, > > > > Jozsef > > > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > In theory, there is no difference between theory and practice. > But, in practice, there is. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From dangud@REDACTED Fri Mar 21 07:28:31 2014 From: dangud@REDACTED (Dan Gudmundsson) Date: Fri, 21 Mar 2014 07:28:31 +0100 Subject: [erlang-questions] escript argument encoding In-Reply-To: <0CCEC3FA-1E82-449B-A706-CAB2DCB73052@gmail.com> References: <0CCEC3FA-1E82-449B-A706-CAB2DCB73052@gmail.com> Message-ID: The default will be +fnaw in 17.0 i.e. dependent on env. On Thu, Mar 20, 2014 at 11:42 PM, Reid Draper wrote: > Thanks. +fnu solved it for me. > > Reid > > On Mar 20, 2014, at 1:42 PM, Jos? Valim > wrote: > > Take a look at the +fnu flags: > > http://erlang.org/doc/man/erl.html > > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Mar 20, 2014 at 7:38 PM, Reid Draper wrote: > >> I?m running into an issue where OSX and Linux seem to treat the >> command-line arguments to an escript differently. Using the following >> escript: >> >> #!/usr/bin/env escript >> %% -*- erlang -*- >> %%! +pc unicode >> >> main([Args]) -> >> io:setopts([{encoding, utf8}]), >> io:format("~w~n", [Args]), >> io:format("~ts~n", [Args]). >> >> Both my OSX and Linux (Ubuntu 13.10) boxes have their LANG set >> to en_US.UTF-8. I?m running the escript like so: >> >> ./sample.escript ???? >> >> On OSX, the escript seems to treat `Args` as a list of unicode >> code-points: >> >> ./sample.escript ???? >> [1587,1604,1575,1605] >> ???? >> >> On Linux, it seems to treat the input as a list of UTF-8 bytes, where >> each byte is turned into an integer. The Erlang unicode guide calls this a >> 'Lists of UTF-8 Bytes' [1]. >> >> ./sample.escript ???? >> [216,179,217,132,216,167,217,133] >> ???????? >> >> How does I get both OSX and Linux to treat the input of the escript as a >> list of code-points? >> >> Thanks, >> Reid >> >> [1] http://www.erlang.org/doc/apps/stdlib/unicode_usage.html >> >> >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Fri Mar 21 07:42:34 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 21 Mar 2014 07:42:34 +0100 Subject: [erlang-questions] escript argument encoding In-Reply-To: References: Message-ID: It's not obvious to me that arguments on the command line of a script are handled as file names. Shouldn't there be a notice on the relevant doc page? Regards, Vlad On 20 Mar 2014 19:42, "Jos? Valim" wrote: > Take a look at the +fnu flags: > > http://erlang.org/doc/man/erl.html > > > > *Jos? Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Lead Developer > > > On Thu, Mar 20, 2014 at 7:38 PM, Reid Draper wrote: > >> I?m running into an issue where OSX and Linux seem to treat the >> command-line arguments to an escript differently. Using the following >> escript: >> >> #!/usr/bin/env escript >> %% -*- erlang -*- >> %%! +pc unicode >> >> main([Args]) -> >> io:setopts([{encoding, utf8}]), >> io:format("~w~n", [Args]), >> io:format("~ts~n", [Args]). >> >> Both my OSX and Linux (Ubuntu 13.10) boxes have their LANG set >> to en_US.UTF-8. I?m running the escript like so: >> >> ./sample.escript ???? >> >> On OSX, the escript seems to treat `Args` as a list of unicode >> code-points: >> >> ./sample.escript ???? >> [1587,1604,1575,1605] >> ???? >> >> On Linux, it seems to treat the input as a list of UTF-8 bytes, where >> each byte is turned into an integer. The Erlang unicode guide calls this a >> 'Lists of UTF-8 Bytes' [1]. >> >> ./sample.escript ???? >> [216,179,217,132,216,167,217,133] >> ???????? >> >> How does I get both OSX and Linux to treat the input of the escript as a >> list of code-points? >> >> Thanks, >> Reid >> >> [1] http://www.erlang.org/doc/apps/stdlib/unicode_usage.html >> >> >> >> >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Fri Mar 21 09:42:31 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 21 Mar 2014 08:42:31 +0000 Subject: [erlang-questions] =?utf-8?b?W0VybGFuZy1xdWVzdGlvbnNdIOmrmOe6p0Vy?= =?utf-8?b?bGFuZ+W8gOWPkeW3peeoi+W4iA==?= In-Reply-To: References: Message-ID: <532BFB77.1060607@llaisdy.com> ???????????????? ;) On 21/03/2014 00:54, Barco You wrote: > ??????????????????????????????????? > ???????????????????????????Functional > Programming???????Erlang?????????????????? > ??0755-83597260 mprtimes@REDACTED > ??? > > ??Erlang????? > > ????? > > 1. ??????????????????????????? > > 2. ??????????????? > > 3. ??erlang??????????? > > ????? > > 1???erlang?????OTP???????????????Functional > Programming???? > > 2???HTTP?TCP/IP???? > > 3???????????????? > > 4???RDBMS????????Nosql????Mysql?Postgresql???????? > > 5???????????? > > 6???????????????? > > 7?????????? > > 8???Linux???????????????????? > > 9????????????/????????????? > > 10?????????????????????????????????? > ???????????? > > 11??????????? > > 12???????????????????????? > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From tony@REDACTED Fri Mar 21 09:59:14 2014 From: tony@REDACTED (Tony Rogvall) Date: Fri, 21 Mar 2014 09:59:14 +0100 Subject: [erlang-questions] Unix domain sockets In-Reply-To: <532BC0EE.70303@gmail.com> References: <3dbc6d1c0903040223w5a079909j8e8851332521efa3@mail.gmail.com> <67cd4667-b605-4fb6-a058-28ad07a24b98@googlegroups.com> <532BC0EE.70303@gmail.com> Message-ID: I did implement this a while ago https://github.com/tonyrog/afunix It is basically a specialized version of inet driver, using the same internal protocol and register in a way the gen_tcp api may be used directly. The drawback with this a approach is of course that this driver must be updated every time the inet driver is updated, but I can not really se any other way of doing this right now. The api is very simple (afunix still lack any kind of documentation) and differ from gen_tcp only in the listen and connect functions. afunix:listen(Name, Options) afunix:connect(Name, Options) The afunix specific functions are afunix:get_peercred(Socket) afunix:get_peerid(Socket) Hope that it can be useful. /Tony On 21 mar 2014, at 05:32, Michael Truog wrote: > I also am disappointed that unix domain sockets lack support, but I am also disappointed there are more internal checks to prevent their use now. I have been able to graft on support, but it isn't pretty (since it needs to avoid the internal prim_inet checks): > https://github.com/CloudI/CloudI/blob/master/src/lib/cloudi_core/src/cloudi_services_external.erl#L1342-L1375 > https://github.com/CloudI/CloudI/blob/master/src/lib/cloudi_core/cxx_src/cloudi_socket_drv.cpp > > When I add unix domain sockets this way, I do get an internal ERTS thread stuck at 100% CPU (somehow stuck in a tight loop) for unknown reasons, but it works fine otherwise. > > On 03/19/2014 04:13 PM, James wrote: >> >> five years later... and there is still no support for uds, only the uds_dist example, which does not even build on linux as it was evidently created for solaris. >> >> >> >> >> On Wednesday, March 4, 2009 5:23:21 AM UTC-5, rvirding wrote: >> I just saw a lament in twitter that Erlang doesn't support Unix domain sockets. Is that so? If not is there a nice link to some documentation explaining that we do and how to do it? >> >> Robert >> >> -- >> Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting. >> --- >> You received this message because you are subscribed to the Google Groups "Erlang Programming" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programming+unsubscribe@REDACTED >> To post to this group, send email to erlang-programming@REDACTED >> Visit this group at http://groups.google.com/group/erlang-programming. >> For more options, visit https://groups.google.com/d/optout. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions "Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix" -------------- next part -------------- An HTML attachment was scrubbed... URL: From raimo+erlang-questions@REDACTED Fri Mar 21 10:26:53 2014 From: raimo+erlang-questions@REDACTED (Raimo Niskanen) Date: Fri, 21 Mar 2014 10:26:53 +0100 Subject: [erlang-questions] =?utf-8?b?W0VybGFuZy1xdWVzdGlvbnNdIOmrmOe6p0Vy?= =?utf-8?b?bGFuZ+W8gOWPkeW3peeoi+W4iA==?= In-Reply-To: References: Message-ID: <20140321092653.GA25144@erix.ericsson.se> Guys, keep this list in english, please. On Fri, Mar 21, 2014 at 08:54:01AM +0800, Barco You wrote: > ??????????????????????????????????????????????????????????????Functional > Programming???????Erlang????????????????????0755-83597260 > mprtimes@REDACTED ??? > > ??Erlang????? > > ????? > > 1. ??????????????????????????? > > 2. ??????????????? > > 3. ??erlang??????????? > > > > ????? > > 1???erlang?????OTP???????????????Functional Programming???? > > 2???HTTP?TCP/IP???? > > 3???????????????? > > 4???RDBMS????????Nosql????Mysql?Postgresql???????? > > 5???????????? > > 6???????????????? > > 7?????????? > > 8???Linux???????????????????? > > 9????????????/????????????? > > 10?????????????????????????????????????????????? > > 11??????????? > > 12???????????????????????? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -- / Raimo Niskanen, Erlang/OTP, Ericsson AB, Mailing list admin at erlang dot org From ivan@REDACTED Fri Mar 21 10:36:22 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 21 Mar 2014 09:36:22 +0000 Subject: [erlang-questions] =?utf-8?b?W0VybGFuZy1xdWVzdGlvbnNdIOmrmOe6p0Vy?= =?utf-8?b?bGFuZ+W8gOWPkeW3peeoi+W4iA==?= In-Reply-To: <20140321092653.GA25144@erix.ericsson.se> References: <20140321092653.GA25144@erix.ericsson.se> Message-ID: <532C0816.9090302@llaisdy.com> Yes, we don't want to encourage the fuzzy-wuzzies. On 21/03/2014 09:26, Raimo Niskanen wrote: > Guys, keep this list in english, please. > > On Fri, Mar 21, 2014 at 08:54:01AM +0800, Barco You wrote: >> ??????????????????????????????????????????????????????????????Functional >> Programming???????Erlang????????????????????0755-83597260 >> mprtimes@REDACTED ??? >> >> ??Erlang????? >> >> ????? >> >> 1. ??????????????????????????? >> >> 2. ??????????????? >> >> 3. ??erlang??????????? >> >> >> >> ????? >> >> 1???erlang?????OTP???????????????Functional Programming???? >> >> 2???HTTP?TCP/IP???? >> >> 3???????????????? >> >> 4???RDBMS????????Nosql????Mysql?Postgresql???????? >> >> 5???????????? >> >> 6???????????????? >> >> 7?????????? >> >> 8???Linux???????????????????? >> >> 9????????????/????????????? >> >> 10?????????????????????????????????????????????? >> >> 11??????????? >> >> 12???????????????????????? > >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From max.lapshin@REDACTED Fri Mar 21 11:30:34 2014 From: max.lapshin@REDACTED (Max Lapshin) Date: Fri, 21 Mar 2014 14:30:34 +0400 Subject: [erlang-questions] Unix domain sockets In-Reply-To: References: <3dbc6d1c0903040223w5a079909j8e8851332521efa3@mail.gmail.com> <67cd4667-b605-4fb6-a058-28ad07a24b98@googlegroups.com> <532BC0EE.70303@gmail.com> Message-ID: What is the problem of implementing unix sockets inside erlang? Are there any hidden problems? -------------- next part -------------- An HTML attachment was scrubbed... URL: From barcojie@REDACTED Fri Mar 21 11:40:40 2014 From: barcojie@REDACTED (Barco You) Date: Fri, 21 Mar 2014 18:40:40 +0800 Subject: [erlang-questions] =?gb2312?b?W0VybGFuZy1xdWVzdGlvbnNdILjfvLZF?= =?gb2312?b?cmxhbme/qreiuaSzzMqm?= In-Reply-To: <532BFB77.1060607@llaisdy.com> References: <532BFB77.1060607@llaisdy.com> Message-ID: Competence of Chinese reading and writing is not mandate. We very welcome English-speaking people join us if only you are a advocate of Erlang. 2014-03-21 16:42 GMT+08:00 Ivan Uemlianin : > ???????????????? ;) > > On 21/03/2014 00:54, Barco You wrote: > >> ??????????????????????????????????? >> ???????????????????????????Functional >> Programming???????Erlang?????????????????? >> ??0755-83597260 mprtimes@REDACTED >> >> ??? >> >> ??Erlang????? >> >> ????? >> >> 1. ??????????????????????????? >> >> 2. ??????????????? >> >> 3. ??erlang??????????? >> >> ????? >> >> 1???erlang?????OTP???????????????Functional >> Programming???? >> >> 2???HTTP?TCP/IP???? >> >> 3???????????????? >> >> 4???RDBMS????????Nosql????Mysql?Postgresql???????? >> >> 5???????????? >> >> 6???????????????? >> >> 7?????????? >> >> 8???Linux???????????????????? >> >> 9????????????/????????????? >> >> 10?????????????????????????????????? >> ???????????? >> >> 11??????????? >> >> 12???????????????????????? >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan@REDACTED Fri Mar 21 11:51:36 2014 From: ivan@REDACTED (Ivan Uemlianin) Date: Fri, 21 Mar 2014 10:51:36 +0000 Subject: [erlang-questions] =?gb2312?b?W0VybGFuZy1xdWVzdGlvbnNdILjfvLZF?= =?gb2312?b?cmxhbme/qreiuaSzzMqm?= In-Reply-To: References: <532BFB77.1060607@llaisdy.com> Message-ID: <532C19B8.8060605@llaisdy.com> Is the position based in Shenzhen? Ivan On 21/03/2014 10:40, Barco You wrote: > Competence of Chinese reading and writing is not mandate. We very > welcome English-speaking people join us if only you are a advocate of > Erlang. > > > 2014-03-21 16:42 GMT+08:00 Ivan Uemlianin >: > > ???????????????? ;) > > On 21/03/2014 00:54, Barco You wrote: > > ?????????????????????__?????????? > ???? > ?????????????????????__??????Functional > Programming???????Erlang??????__????????? > ??? > ??0755-83597260 mprtimes@REDACTED > > > > ??? > > ??Erlang????? > > ????? > > 1. ??????????????????????????? > > 2. ??????????????? > > 3. ??erlang??????????? > > ????? > > 1???erlang?????OTP?????__??????????Functional > Programming???? > > 2???HTTP?TCP/IP???? > > 3???????????????? > > 4???RDBMS????????Nosql???__?Mysql?Postgresql?? > ?????? > > 5???????????? > > 6???????????????? > > 7?????????? > > 8???Linux???????????????????? > > 9????????????/????????????? > > 10???????????????????__??????????? > ???? > ???????????? > > 11??????????? > > 12???????????????????????? > > > > _________________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/__listinfo/erlang-questions > > > > -- > ==============================__============================== > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/__ivanuemlianin > > > festina lente > ==============================__============================== > > -- ============================================================ Ivan A. Uemlianin PhD Llaisdy Speech Technology Research and Development ivan@REDACTED www.llaisdy.com llaisdy.wordpress.com github.com/llaisdy www.linkedin.com/in/ivanuemlianin festina lente ============================================================ From barcojie@REDACTED Fri Mar 21 12:15:48 2014 From: barcojie@REDACTED (Barco You) Date: Fri, 21 Mar 2014 19:15:48 +0800 Subject: [erlang-questions] =?gb2312?b?W0VybGFuZy1xdWVzdGlvbnNdILjfvLZF?= =?gb2312?b?cmxhbme/qreiuaSzzMqm?= In-Reply-To: <532C19B8.8060605@llaisdy.com> References: <532BFB77.1060607@llaisdy.com> <532C19B8.8060605@llaisdy.com> Message-ID: Exactly! 2014-03-21 18:51 GMT+08:00 Ivan Uemlianin : > Is the position based in Shenzhen? > > Ivan > > > On 21/03/2014 10:40, Barco You wrote: > > Competence of Chinese reading and writing is not mandate. We very > > welcome English-speaking people join us if only you are a advocate of > > Erlang. > > > > > > 2014-03-21 16:42 GMT+08:00 Ivan Uemlianin > >: > > > > ???????????????? ;) > > > > On 21/03/2014 00:54, Barco You wrote: > > > > ?????????????????????__?????????? > > ???? > > ?????????????????????__??????Functional > > Programming???????Erlang??????__????????? > > ??? > > ??0755-83597260 mprtimes@REDACTED > > > > > > > > ??? > > > > ??Erlang????? > > > > ????? > > > > 1. ??????????????????????????? > > > > 2. ??????????????? > > > > 3. ??erlang??????????? > > > > ????? > > > > 1???erlang?????OTP?????__??????????Functional > > Programming???? > > > > 2???HTTP?TCP/IP???? > > > > 3???????????????? > > > > 4???RDBMS????????Nosql???__?Mysql?Postgresql?? > > ?????? > > > > 5???????????? > > > > 6???????????????? > > > > 7?????????? > > > > 8???Linux???????????????????? > > > > 9????????????/????????????? > > > > 10???????????????????__??????????? > > ???? > > ???????????? > > > > 11??????????? > > > > 12???????????????????????? > > > > > > > > _________________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/__listinfo/erlang-questions > > > > > > > > -- > > ==============================__============================== > > Ivan A. Uemlianin PhD > > Llaisdy > > Speech Technology Research and Development > > > > ivan@REDACTED > > www.llaisdy.com > > llaisdy.wordpress.com > > github.com/llaisdy > > www.linkedin.com/in/__ivanuemlianin > > > > > > festina lente > > ==============================__============================== > > > > > > -- > ============================================================ > Ivan A. Uemlianin PhD > Llaisdy > Speech Technology Research and Development > > ivan@REDACTED > www.llaisdy.com > llaisdy.wordpress.com > github.com/llaisdy > www.linkedin.com/in/ivanuemlianin > > festina lente > ============================================================ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony@REDACTED Fri Mar 21 15:11:05 2014 From: tony@REDACTED (Tony Rogvall) Date: Fri, 21 Mar 2014 15:11:05 +0100 Subject: [erlang-questions] Unix domain sockets In-Reply-To: References: <3dbc6d1c0903040223w5a079909j8e8851332521efa3@mail.gmail.com> <67cd4667-b605-4fb6-a058-28ad07a24b98@googlegroups.com> <532BC0EE.70303@gmail.com> Message-ID: <1F6B25ED-3B3A-4484-820B-F78053526037@rogvall.se> On 21 mar 2014, at 11:30, Max Lapshin wrote: > What is the problem of implementing unix sockets inside erlang? > You must implement unix sockets with a driver or port program. > Are there any hidden problems? > Not any hidden problems, it is open source :-) But the old trick (R15 and earlier) is not valid any more since inet_drv is checking the socket type when starting. /Tony From dmercer@REDACTED Fri Mar 21 15:53:08 2014 From: dmercer@REDACTED (David Mercer) Date: Fri, 21 Mar 2014 09:53:08 -0500 Subject: [erlang-questions] =?utf-8?b?W0VybGFuZy1xdWVzdGlvbnNdIOmrmOe6p0Vy?= =?utf-8?b?bGFuZ+W8gOWPkeW3peeoi+W4iA==?= In-Reply-To: <20140321092653.GA25144@erix.ericsson.se> References: <20140321092653.GA25144@erix.ericsson.se> Message-ID: <012c01cf4515$45f4bad0$d1de3070$@gmail.com> I presume the job opportunity requires you to be able to read the message. If you can't read it, it's probably not for you. Cheers, DBM > -----Original Message----- > From: erlang-questions-bounces@REDACTED [mailto:erlang-questions- > bounces@REDACTED] On Behalf Of Raimo Niskanen > Sent: Friday, March 21, 2014 04:27 > To: Barco You; erlang-questions@REDACTED > Subject: Re: [erlang-questions] [Erlang-questions] ??Erlang????? > > Guys, keep this list in english, please. > > On Fri, Mar 21, 2014 at 08:54:01AM +0800, Barco You wrote: > > ???????????????????????????????????????? > ??????????????????????Functional > > Programming???????Erlang????????????????????0755- > 83597260 > > mprtimes@REDACTED ??? > > > > ??Erlang????? > > > > ????? > > > > 1. ??????????????????????????? > > > > 2. ??????????????? > > > > 3. ??erlang??????????? > > > > > > > > ????? > > > > 1???erlang?????OTP???????????????Functional > Programming???? > > > > 2???HTTP?TCP/IP???? > > > > 3???????????????? > > > > 4???RDBMS????????Nosql????Mysql?Postgresql???????? > > > > 5???????????? > > > > 6???????????????? > > > > 7?????????? > > > > 8???Linux???????????????????? > > > > 9????????????/????????????? > > > > 10?????????????????????????????????????? > ???????? > > > > 11??????????? > > > > 12???????????????????????? > > > _______________________________________________ > > erlang-questions mailing list > > erlang-questions@REDACTED > > http://erlang.org/mailman/listinfo/erlang-questions > > > -- > > / Raimo Niskanen, Erlang/OTP, Ericsson AB, > Mailing list admin at erlang dot org > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From tony@REDACTED Fri Mar 21 15:11:05 2014 From: tony@REDACTED (Tony Rogvall) Date: Fri, 21 Mar 2014 15:11:05 +0100 Subject: [erlang-questions] Unix domain sockets In-Reply-To: References: <3dbc6d1c0903040223w5a079909j8e8851332521efa3@mail.gmail.com> <67cd4667-b605-4fb6-a058-28ad07a24b98@googlegroups.com> <532BC0EE.70303@gmail.com> Message-ID: <1F6B25ED-3B3A-4484-820B-F78053526037@rogvall.se> On 21 mar 2014, at 11:30, Max Lapshin wrote: > What is the problem of implementing unix sockets inside erlang? > You must implement unix sockets with a driver or port program. > Are there any hidden problems? > Not any hidden problems, it is open source :-) But the old trick (R15 and earlier) is not valid any more since inet_drv is checking the socket type when starting. /Tony From roger@REDACTED Fri Mar 21 16:23:45 2014 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 21 Mar 2014 15:23:45 +0000 Subject: [erlang-questions] Dealing with different environment configurations? Message-ID: We're currently packaging our Erlang node with relx. This generates a startup script that assumes releases/1/sys.config exists. Now, we have to deal with a couple of different environments: dev, test, staging, production. "production" is further divided into (e.g.) "production-us-east", "production-us-west", "production-eu", etc. How do people deal with the need to have different configuration files in different environments? Do you build a different release for each environment? Or do you replace the sys.config in each environment? If so, how? Thanks, Roger. From desired.mta@REDACTED Fri Mar 21 16:47:36 2014 From: desired.mta@REDACTED (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) Date: Fri, 21 Mar 2014 16:47:36 +0100 Subject: [erlang-questions] Dealing with different environment configurations? In-Reply-To: References: Message-ID: On Fri, Mar 21, 2014 at 4:23 PM, Roger Lipscombe wrote: > We're currently packaging our Erlang node with relx. This generates a > startup script that assumes releases/1/sys.config exists. > > Now, we have to deal with a couple of different environments: dev, > test, staging, production. "production" is further divided into (e.g.) > "production-us-east", "production-us-west", "production-eu", etc. > > How do people deal with the need to have different configuration files > in different environments? Do you build a different release for each > environment? Or do you replace the sys.config in each environment? If > so, how? sys.config can include other files: http://www.erlang.org/doc/man/config.html We use 'priv/extra.config' for environment-specific configuration. You might run into problems if you depend on these values from eunit, here is a fix: https://github.com/rebar/rebar/pull/216. Scott Lystig Fritchie is very conservative about merging it, but we have no problems with the change for quite a while now. Motiejus From erlangsiri@REDACTED Fri Mar 21 17:29:18 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Fri, 21 Mar 2014 17:29:18 +0100 Subject: [erlang-questions] escript argument encoding In-Reply-To: References: Message-ID: It is mentioned here: http://www.erlang.org/doc/apps/stdlib/unicode_usage.html#id62041, but there might be other places where it should be added. A user contribution will of course make such an improvement happen faster! /siri fredagen den 21:e mars 2014 skrev Vlad Dumitrescu : > It's not obvious to me that arguments on the command line of a script are > handled as file names. Shouldn't there be a notice on the relevant doc page? > > Regards, > Vlad > On 20 Mar 2014 19:42, "Jos? Valim" > > wrote: > >> Take a look at the +fnu flags: >> >> http://erlang.org/doc/man/erl.html >> >> >> >> *Jos? Valim* >> www.plataformatec.com.br >> Skype: jv.ptec >> Founder and Lead Developer >> >> >> On Thu, Mar 20, 2014 at 7:38 PM, Reid Draper >> > wrote: >> >>> I?m running into an issue where OSX and Linux seem to treat the >>> command-line arguments to an escript differently. Using the following >>> escript: >>> >>> #!/usr/bin/env escript >>> %% -*- erlang -*- >>> %%! +pc unicode >>> >>> main([Args]) -> >>> io:setopts([{encoding, utf8}]), >>> io:format("~w~n", [Args]), >>> io:format("~ts~n", [Args]). >>> >>> Both my OSX and Linux (Ubuntu 13.10) boxes have their LANG set >>> to en_US.UTF-8. I?m running the escript like so: >>> >>> ./sample.escript ???? >>> >>> On OSX, the escript seems to treat `Args` as a list of unicode >>> code-points: >>> >>> ./sample.escript ???? >>> [1587,1604,1575,1605] >>> ???? >>> >>> On Linux, it seems to treat the input as a list of UTF-8 bytes, where >>> each byte is turned into an integer. The Erlang unicode guide calls this a >>> 'Lists of UTF-8 Bytes' [1]. >>> >>> ./sample.escript ???? >>> [216,179,217,132,216,167,217,133] >>> ???????? >>> >>> How does I get both OSX and Linux to treat the input of the escript as a >>> list of code-points? >>> >>> Thanks, >>> Reid >>> >>> [1] http://www.erlang.org/doc/apps/stdlib/unicode_usage.html >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Fri Mar 21 17:30:58 2014 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 21 Mar 2014 16:30:58 +0000 Subject: [erlang-questions] Dealing with different environment configurations? In-Reply-To: References: Message-ID: On 21 March 2014 15:47, Motiejus Jak?tys wrote: > sys.config can include other files: http://www.erlang.org/doc/man/config.html The problem I had with that is that it expects either fully-qualified paths, which means we need to know where the package is going to be installed (I mean, we do, but it seems brittle). Or it looks for config relative to the VM working directory. If you're using the relx start script, that's one up from the 'bin' directory. > We use 'priv/extra.config' for environment-specific configuration. And do you keep that 'priv' directory next to the 'bin', 'lib', 'releases' directories, etc.? That might work. Do you then deploy a separate file into that location on a per-environment basis. > You might run into problems if you depend on these values from eunit, I didn't think eunit (even with rebar) could use a config file. > Motiejus Thanks. From roger@REDACTED Fri Mar 21 17:31:34 2014 From: roger@REDACTED (Roger Lipscombe) Date: Fri, 21 Mar 2014 16:31:34 +0000 Subject: [erlang-questions] Dealing with different environment configurations? In-Reply-To: <91176c5d-755a-4349-bf58-c43046798ce6@googlegroups.com> References: <91176c5d-755a-4349-bf58-c43046798ce6@googlegroups.com> Message-ID: On 21 March 2014 15:57, Andy Richards wrote: > I think you can do this with overlays... > > https://github.com/erlware/relx/wiki/overlays That implies a different release for each environment. Doable, but we'd prefer to look at other options first. From attila.r.nohl@REDACTED Fri Mar 21 18:15:12 2014 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Fri, 21 Mar 2014 18:15:12 +0100 Subject: [erlang-questions] When to release resources in NIF? Message-ID: Hello! I have a NIF module that uses a locks to protect a common resource. The locks are created using enif_rwlock_create in the load function and destroyed in the unload function. When I first load the Erlang module, the locks are initialized and everything is OK. When I compile the module in the same VM the first time, everything is still OK. When I compile it the second time, the old version of the module is unloaded, so unload is called. At this point I'm in trouble, because the unload function destroys the lock. I'm not quite sure how to correctly handle this situation. Somehow I should keep (or destroy/create) the locks in the upgrade step, but after the second compilation the locks are already deleted by unload. I could add a flag to the private data stating that the locks were already destroyed or not, but it feels hackish. What is the correct way? From desired.mta@REDACTED Fri Mar 21 18:36:18 2014 From: desired.mta@REDACTED (=?UTF-8?B?TW90aWVqdXMgSmFrxaF0eXM=?=) Date: Fri, 21 Mar 2014 18:36:18 +0100 Subject: [erlang-questions] Dealing with different environment configurations? Message-ID: <532C7892.3080703@gmail.com> Sharing to list, since might be interesting for more people. 2014.03.21 17:30, Roger Lipscombe ra??: > The problem I had with that is that it expects either fully-qualified > paths, which means we need to know where the package is going to be > installed (I mean, we do, but it seems brittle). Or it looks for > config relative to the VM working directory. If you're using the relx > start script, that's one up from the 'bin' directory. > >>> We use 'priv/extra.config' for environment-specific configuration. > And do you keep that 'priv' directory next to the 'bin', 'lib', > 'releases' directories, etc.? That might work. Do you then deploy a > separate file into that location on a per-environment basis. We use RPM for deployment; creating a symlink in the correct path pointing to the "real" file is part of the application RPM spec. That also means you have to be careful about config compatibility, because they are managed externally. However, priv/extra.config is limited to really simple values, so it's usually fine. >>> You might run into problems if you depend on these values from eunit, > I didn't think eunit (even with rebar) could use a config file. Some applications require some external settings for running tests (like DB credentials). For these, invoke rebar like: ERL_FLAGS="-config rel/files/sys.config" rebar eunit <...> And we have priv/extra.config in application directory, which is generated on setup time. So running tests from scratch: $ git clone ; cd $ make # get-deps, compile $ make setup MYSQL_USER=.... # generate priv/extra.conf and stuff $ make test # "rebar eunit" with necessary flags and ENV Regards, Motiejus From jesper.louis.andersen@REDACTED Fri Mar 21 21:04:48 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Fri, 21 Mar 2014 21:04:48 +0100 Subject: [erlang-questions] Dealing with different environment configurations? In-Reply-To: References: Message-ID: On Fri, Mar 21, 2014 at 5:30 PM, Roger Lipscombe wrote: > The problem I had with that is that it expects either fully-qualified > paths, which means we need to know where the package is going to be > installed (I mean, we do, but it seems brittle). Or it looks for > config relative to the VM working directory. If you're using the relx > start script, that's one up from the 'bin' directory. > Keep the path injection as part of the surrounding build framework. The things around the release will surely know where the configuration file ends up. A simple shell script can replace the last lines of the file with where the configuration is. -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmkolesnikov@REDACTED Fri Mar 21 21:18:00 2014 From: dmkolesnikov@REDACTED (Dmitry Kolesnikov) Date: Fri, 21 Mar 2014 22:18:00 +0200 Subject: [erlang-questions] Dealing with different environment configurations? In-Reply-To: References: Message-ID: <47C7BBA4-D594-428E-93D2-E433B6E83487@gmail.com> Hello, I am using vars overlays to customize sys.config for each environment. This requires to create a new package for each env but I see no issues with it. It is easy to manage a solid package. Best Regards, Dmitry >-|-|-(*> > On 21 Mar 2014, at 17:23, Roger Lipscombe wrote: > > We're currently packaging our Erlang node with relx. This generates a > startup script that assumes releases/1/sys.config exists. > > Now, we have to deal with a couple of different environments: dev, > test, staging, production. "production" is further divided into (e.g.) > "production-us-east", "production-us-west", "production-eu", etc. > > How do people deal with the need to have different configuration files > in different environments? Do you build a different release for each > environment? Or do you replace the sys.config in each environment? If > so, how? > > Thanks, > Roger. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From vladdu55@REDACTED Fri Mar 21 21:31:19 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Fri, 21 Mar 2014 21:31:19 +0100 Subject: [erlang-questions] escript argument encoding In-Reply-To: References: Message-ID: Sent a pull request for the doc addition. /Vlad On Fri, Mar 21, 2014 at 5:29 PM, Siri Hansen wrote: > It is mentioned here: > http://www.erlang.org/doc/apps/stdlib/unicode_usage.html#id62041, > but there might be other places where it should be added. A > user contribution will of course make such an improvement happen faster! > /siri > > fredagen den 21:e mars 2014 skrev Vlad Dumitrescu : > > It's not obvious to me that arguments on the command line of a script are >> handled as file names. Shouldn't there be a notice on the relevant doc page? >> >> Regards, >> Vlad >> On 20 Mar 2014 19:42, "Jos? Valim" >> wrote: >> >>> Take a look at the +fnu flags: >>> >>> http://erlang.org/doc/man/erl.html >>> >>> >>> >>> *Jos? Valim* >>> www.plataformatec.com.br >>> Skype: jv.ptec >>> Founder and Lead Developer >>> >>> >>> On Thu, Mar 20, 2014 at 7:38 PM, Reid Draper wrote: >>> >>>> I?m running into an issue where OSX and Linux seem to treat the >>>> command-line arguments to an escript differently. Using the following >>>> escript: >>>> >>>> #!/usr/bin/env escript >>>> %% -*- erlang -*- >>>> %%! +pc unicode >>>> >>>> main([Args]) -> >>>> io:setopts([{encoding, utf8}]), >>>> io:format("~w~n", [Args]), >>>> io:format("~ts~n", [Args]). >>>> >>>> Both my OSX and Linux (Ubuntu 13.10) boxes have their LANG set >>>> to en_US.UTF-8. I?m running the escript like so: >>>> >>>> ./sample.escript ???? >>>> >>>> On OSX, the escript seems to treat `Args` as a list of unicode >>>> code-points: >>>> >>>> ./sample.escript ???? >>>> [1587,1604,1575,1605] >>>> ???? >>>> >>>> On Linux, it seems to treat the input as a list of UTF-8 bytes, where >>>> each byte is turned into an integer. The Erlang unicode guide calls this a >>>> 'Lists of UTF-8 Bytes' [1]. >>>> >>>> ./sample.escript ???? >>>> [216,179,217,132,216,167,217,133] >>>> ???????? >>>> >>>> How does I get both OSX and Linux to treat the input of the escript as >>>> a list of code-points? >>>> >>>> Thanks, >>>> Reid >>>> >>>> [1] http://www.erlang.org/doc/apps/stdlib/unicode_usage.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sat Mar 22 11:44:31 2014 From: erlang@REDACTED (=?UTF-8?Q?Micha=C5=82_Ptaszek?=) Date: Sat, 22 Mar 2014 11:44:31 +0100 Subject: [erlang-questions] Monitor limitations Message-ID: Hey everyone, can anyone please shed some more light on OTP-6345? For some reasons we can not atomically spawn processes with proc_lib:spawn_opt with 'monitor' flag. The same problem happens with erlang:spawn_opt/5 where we can not spawn a remote process with 'monitor' (however linking is totally ok). Thanks, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Sun Mar 23 09:37:29 2014 From: erlang@REDACTED (Andreas Stenius) Date: Sun, 23 Mar 2014 09:37:29 +0100 Subject: [erlang-questions] Blog post: The Secret To 10 Million Concurrent Connections -The Kernel Is The Problem, Not The Solution Message-ID: Hi, I just stumbled upon this blog post [1], and think it makes a really good job at highlighting the benefits of using Erlang. --Andreas [1] http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchesneau@REDACTED Sun Mar 23 08:48:29 2014 From: bchesneau@REDACTED (Benoit Chesneau) Date: Sun, 23 Mar 2014 08:48:29 +0100 Subject: [erlang-questions] Unix domain sockets In-Reply-To: <532BC0EE.70303@gmail.com> References: <3dbc6d1c0903040223w5a079909j8e8851332521efa3@mail.gmail.com> <67cd4667-b605-4fb6-a058-28ad07a24b98@googlegroups.com> <532BC0EE.70303@gmail.com> Message-ID: I am still wondering why such support is not in the erlang stdlib. That's not like unix sockets are unusual ... Someone that has the knowledge should really propose a patch :) On Fri, Mar 21, 2014 at 5:32 AM, Michael Truog wrote: > I also am disappointed that unix domain sockets lack support, but I am also > disappointed there are more internal checks to prevent their use now. I > have been able to graft on support, but it isn't pretty (since it needs to > avoid the internal prim_inet checks): > https://github.com/CloudI/CloudI/blob/master/src/lib/cloudi_core/src/cloudi_services_external.erl#L1342-L1375 > https://github.com/CloudI/CloudI/blob/master/src/lib/cloudi_core/cxx_src/cloudi_socket_drv.cpp > > When I add unix domain sockets this way, I do get an internal ERTS thread > stuck at 100% CPU (somehow stuck in a tight loop) for unknown reasons, but > it works fine otherwise. > > On 03/19/2014 04:13 PM, James wrote: > > > five years later... and there is still no support for uds, only the uds_dist > example, which does not even build on linux as it was evidently created for > solaris. > > > > > On Wednesday, March 4, 2009 5:23:21 AM UTC-5, rvirding wrote: >> >> I just saw a lament in twitter that Erlang doesn't support Unix domain >> sockets. Is that so? If not is there a nice link to some documentation >> explaining that we do and how to do it? >> >> Robert >> > -- > Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when > posting. > --- > You received this message because you are subscribed to the Google Groups > "Erlang Programming" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to erlang-programming+unsubscribe@REDACTED > To post to this group, send email to erlang-programming@REDACTED > Visit this group at http://groups.google.com/group/erlang-programming. > For more options, visit https://groups.google.com/d/optout. > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > From tuncer.ayaz@REDACTED Sun Mar 23 21:13:31 2014 From: tuncer.ayaz@REDACTED (Tuncer Ayaz) Date: Sun, 23 Mar 2014 21:13:31 +0100 Subject: [erlang-questions] erl_syntax[_lib] error handling In-Reply-To: References: Message-ID: On Mon, Feb 24, 2014 at 9:21 PM, Tuncer Ayaz wrote: > erl_syntax and erl_syntax_lib seem to favor throwing exceptions over > returning error terms. I found this hard to use due to the missing > documenation of what exceptions can be thrown by each function. Only > erl_syntax_lib:analyze_application/1 documents one exception it might > throw, and the documentation for other funs just states the following: > "An exception is thrown if..." > > The only way to handle erl_syntax[_lib] errors I've seen so far is to > catch all exceptions, but that can filter/suppress any kind of > exception. > > What's the recommended way to handle erl_syntax[_lib] errors? Bump. From attila.r.nohl@REDACTED Mon Mar 24 16:34:55 2014 From: attila.r.nohl@REDACTED (Attila Rajmund Nohl) Date: Mon, 24 Mar 2014 16:34:55 +0100 Subject: [erlang-questions] When to release resources in NIF? In-Reply-To: References: Message-ID: Hello! I do have those, the problem is that I don't see any difference in the unload call when the module is explicitly removed using code:delete/1 and code:purge/1 or implicitly removed during a code upgrade. In the first case I have to delete the locks, in the second case I don't have to. I've ended up with this code: static int load(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info) { /* create locks */ return 0; } static void unload(ErlNifEnv* env, void* priv_data) { if (NULL != priv_data) { /* delete locks */ } } static int upgrade(ErlNifEnv* env, void** priv_data, void** old_priv_data, ERL_NIF_TERM load_info) { unload(env, *old_priv_data); *old_priv_data = NULL; load(env, priv_data, load_info); return 0; } It works, but I'm not sure how and why. 2014-03-24 15:17 GMT+01:00 Soup : > Theoretically, you should be able to use the "upgrade" or "reload" callbacks > in your NIF instead of the unload callback. It may be necessary to perform > the upgrade as an app/relup to use that feature, though. Perhaps someone a > bit more versed on NIF modules can shed some light. > > At the very least you need to specify one of those two callback functions. > > ~Soup > > > On Fri, Mar 21, 2014 at 1:15 PM, Attila Rajmund Nohl > wrote: >> >> Hello! >> >> I have a NIF module that uses a locks to protect a common resource. >> The locks are created using enif_rwlock_create in the load function >> and destroyed in the unload function. When I first load the Erlang >> module, the locks are initialized and everything is OK. When I compile >> the module in the same VM the first time, everything is still OK. When >> I compile it the second time, the old version of the module is >> unloaded, so unload is called. At this point I'm in trouble, because >> the unload function destroys the lock. >> >> I'm not quite sure how to correctly handle this situation. Somehow I >> should keep (or destroy/create) the locks in the upgrade step, but >> after the second compilation the locks are already deleted by unload. >> I could add a flag to the private data stating that the locks were >> already destroyed or not, but it feels hackish. What is the correct >> way? >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions > > From erlangsiri@REDACTED Mon Mar 24 17:37:35 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Mon, 24 Mar 2014 17:37:35 +0100 Subject: [erlang-questions] Monitor limitations In-Reply-To: References: Message-ID: >From the notes in the ticket: "Some analysis yields that the cause is that the gen_server:start() call ends up in erlang:spawn_opt(..., [monitor]) which return {Pid, Monitor}, making the proc_lib:sync_wait() wait for {Pid, Monitor} and not Pid which is what the newly spawned process sends in the ack-message." I haven't investigated further, so I don't know anything more about it. It doesn't seem too hard to solve, though, so it seems strange that the solution was to throw a badarg. Or maybe I missed something crucial... /siri 2014-03-22 11:44 GMT+01:00 Micha? Ptaszek : > Hey everyone, > > can anyone please shed some more light on OTP-6345? > > For some reasons we can not atomically spawn processes with > proc_lib:spawn_opt with 'monitor' flag. The same problem happens with > erlang:spawn_opt/5 where we can not spawn a remote process with 'monitor' > (however linking is totally ok). > > Thanks, > Michal > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sverker.eriksson@REDACTED Mon Mar 24 17:37:46 2014 From: sverker.eriksson@REDACTED (Sverker Eriksson) Date: Mon, 24 Mar 2014 17:37:46 +0100 Subject: [erlang-questions] When to release resources in NIF? In-Reply-To: References: Message-ID: <53305F5A.3010700@erix.ericsson.se> As I understand it, this is not about NIF *resources* created by enif_alloc_resource(), but rather some common data structure tied to the module. Do you access this common data via 'priv_data' or a global variable? If you use global variable then you must handle the upgrade case when the *same* NIF library is loaded by both old and new module instances. If they load the same library, they not only share code but also share static data such as global variables. One way to detect this is with a library reference counter: static int lib_refc = 0; /* number of users of this dynamic library */ static int load(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info) { if (++lib_refc != 1) { /* should not happen */ } } static int upgrade(ErlNifEnv* env, void** priv_data, void* old_priv_data, ERL_NIF_TERM load_info) { if (++lib_refc > 1) { /* This library already used by older module instance */ } } static void unload(ErlNifEnv* env, void* priv_data) { if (--lib_refc == 0) { /* We are really unloading this library */ } else { /* Library still used by newer instance of this module */ } } In any case, to support module upgrade you need to decide how the old and new module instances should handle common data. I guess there are three strategies: 1. No sharing. New module instance creates its own data and old instance destroys its own data. 2. Sharing. Old and new module instances share the same common data. Processes running old and new code might exist at the same time so you need to make sure that both old and new code can access the same data in a safe way. You probably need some reference counting here to make sure to not destroy the data while it's still used. 3. Stealing. The new module instance steals the data from the old instance. If a process calls a NIF in the old module instance it needs to handle the fact that it has been "robbed" from its common data and maybe return some sort of error. /Sverker, Erlang/OTP On 03/24/2014 04:34 PM, Attila Rajmund Nohl wrote: > Hello! > > I do have those, the problem is that I don't see any difference in the > unload call when the module is explicitly removed using code:delete/1 > and code:purge/1 or implicitly removed during a code upgrade. In the > first case I have to delete the locks, in the second case I don't have > to. I've ended up with this code: > > static int load(ErlNifEnv* env, void** priv_data, ERL_NIF_TERM load_info) { > /* create locks */ > return 0; > } > > static void unload(ErlNifEnv* env, void* priv_data) { > if (NULL != priv_data) { > /* delete locks */ > } > } > > static int upgrade(ErlNifEnv* env, void** priv_data, void** > old_priv_data, ERL_NIF_TERM load_info) { > unload(env, *old_priv_data); > *old_priv_data = NULL; > load(env, priv_data, load_info); > return 0; > } > > It works, but I'm not sure how and why. > > 2014-03-24 15:17 GMT+01:00 Soup : >> Theoretically, you should be able to use the "upgrade" or "reload" callbacks >> in your NIF instead of the unload callback. It may be necessary to perform >> the upgrade as an app/relup to use that feature, though. Perhaps someone a >> bit more versed on NIF modules can shed some light. >> >> At the very least you need to specify one of those two callback functions. >> >> ~Soup >> >> >> On Fri, Mar 21, 2014 at 1:15 PM, Attila Rajmund Nohl >> wrote: >>> Hello! >>> >>> I have a NIF module that uses a locks to protect a common resource. >>> The locks are created using enif_rwlock_create in the load function >>> and destroyed in the unload function. When I first load the Erlang >>> module, the locks are initialized and everything is OK. When I compile >>> the module in the same VM the first time, everything is still OK. When >>> I compile it the second time, the old version of the module is >>> unloaded, so unload is called. At this point I'm in trouble, because >>> the unload function destroys the lock. >>> >>> I'm not quite sure how to correctly handle this situation. Somehow I >>> should keep (or destroy/create) the locks in the upgrade step, but >>> after the second compilation the locks are already deleted by unload. >>> I could add a flag to the private data stating that the locks were >>> already destroyed or not, but it feels hackish. What is the correct >>> way? >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >> > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > From zachary.hueras@REDACTED Mon Mar 24 15:17:10 2014 From: zachary.hueras@REDACTED (Soup) Date: Mon, 24 Mar 2014 10:17:10 -0400 Subject: [erlang-questions] When to release resources in NIF? In-Reply-To: References: Message-ID: Theoretically, you should be able to use the "upgrade" or "reload" callbacks in your NIF instead of the unload callback. It may be necessary to perform the upgrade as an app/relup to use that feature, though. Perhaps someone a bit more versed on NIF modules can shed some light. At the very least you need to specify one of those two callback functions. ~Soup On Fri, Mar 21, 2014 at 1:15 PM, Attila Rajmund Nohl < attila.r.nohl@REDACTED> wrote: > Hello! > > I have a NIF module that uses a locks to protect a common resource. > The locks are created using enif_rwlock_create in the load function > and destroyed in the unload function. When I first load the Erlang > module, the locks are initialized and everything is OK. When I compile > the module in the same VM the first time, everything is still OK. When > I compile it the second time, the old version of the module is > unloaded, so unload is called. At this point I'm in trouble, because > the unload function destroys the lock. > > I'm not quite sure how to correctly handle this situation. Somehow I > should keep (or destroy/create) the locks in the upgrade step, but > after the second compilation the locks are already deleted by unload. > I could add a flag to the private data stating that the locks were > already destroyed or not, but it feels hackish. What is the correct > way? > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Mon Mar 24 18:16:30 2014 From: erlang@REDACTED (=?UTF-8?Q?Micha=C5=82_Ptaszek?=) Date: Mon, 24 Mar 2014 18:16:30 +0100 Subject: [erlang-questions] Monitor limitations In-Reply-To: References: Message-ID: Even if there was an additional cost for gen modules when spawning new process I still don't see a connection with a complete removal of 'monitor' flag from available options in spawn_opt BIF (or rather, replacing it with throw(badarg)). Moreover there is no public API allowing people to spawn gen_servers on the remote nodes (and only the remote spawn_opt functions were crippled by that change). Would a patch re-enabling that flag be accepted by the OTP team? On Mon, Mar 24, 2014 at 5:37 PM, Siri Hansen wrote: > From the notes in the ticket: > > "Some analysis yields that the cause is that the gen_server:start() call > ends up in erlang:spawn_opt(..., [monitor]) which return {Pid, Monitor}, > making the proc_lib:sync_wait() wait for {Pid, Monitor} and not Pid > which is what the newly spawned process sends in the ack-message." > > I haven't investigated further, so I don't know anything more about it. It > doesn't seem too hard to solve, though, so it seems strange that the > solution was to throw a badarg. Or maybe I missed something crucial... > > /siri > > > 2014-03-22 11:44 GMT+01:00 Micha? Ptaszek : > >> Hey everyone, >> >> can anyone please shed some more light on OTP-6345? >> >> For some reasons we can not atomically spawn processes with >> proc_lib:spawn_opt with 'monitor' flag. The same problem happens with >> erlang:spawn_opt/5 where we can not spawn a remote process with 'monitor' >> (however linking is totally ok). >> >> Thanks, >> Michal >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ward@REDACTED Tue Mar 25 09:25:44 2014 From: ward@REDACTED (Ward Bekker) Date: Tue, 25 Mar 2014 09:25:44 +0100 Subject: [erlang-questions] Can't disable compensation for sudden changes of system time Message-ID: Hi, I invoke erl like this: erl +A 8 +c -sname project@REDACTED -mnesia dir db_data -mnesia debug verbose -mnesia \ no_table_loaders 4 -mnesia dump_log_write_threshold 10000 -mnesia dc_dump_limit 20 \ -config priv/app.development \ -pa `pwd`/ebin `pwd`/deps/*/ebin -run reloader -s project start -s observer start Notice the '+c'. According to the docs (http://erlang.org/doc/man/erl.html) this emulator flag should disable compensation for sudden changes of system time. And more importantly, remove the period of high CPU just after resuming my computer (after a good night sleep). But it doesn't seem to work. How can I double check this emulator flag is indeed toggled within the Erlang shell? /Ward -------------- next part -------------- An HTML attachment was scrubbed... URL: From lcastro@REDACTED Tue Mar 25 12:44:20 2014 From: lcastro@REDACTED (Laura M. Castro) Date: Tue, 25 Mar 2014 12:44:20 +0100 Subject: [erlang-questions] 2nd Call For Papers: Erlang Workshop 2014 Message-ID: Hello all, Please find below the Second Call for Papers for the Thirteenth ACM SIGPLAN Erlang Workshop. Apologies for any duplicates you may receive. CALL FOR PAPERS =============== Thirteenth ACM SIGPLAN Erlang Workshop ----------------------------------------------------------- G?teborg, Sweden, September 5, 2014 Satellite event of the 19th ACM SIGPLAN International Conference on Functional Programming (ICFP 2014) September 1-3, 2014 http://www.erlang.org/workshop/2014 Erlang is a concurrent, distributed functional programming language aimed at systems with requirements of massive concurrency, soft real time response, fault tolerance, and high availability. It has been available as open source for 15 years, creating a community that actively contributes to its already existing rich set of libraries and applications. Originally created for telecom applications, its usage has spread to other domains including e-commerce, banking, databases, and computer telephony and messaging. Erlang programs are today among the largest applications written in any functional programming language. These applications offer new opportunities to evaluate functional programming and functional programming methods on a very large scale and suggest new problems for the research community to solve. This workshop will bring together the open source, academic, and industrial programming communities of Erlang. It will enable participants to familiarize themselves with recent developments on new techniques and tools tailored to Erlang, novel applications, draw lessons from users' experiences and identify research problems and common areas relevant to the practice of Erlang and functional programming. We invite three types of submissions. 1. Technical papers describing language extensions, critical discussions of the status quo, formal semantics of language constructs, program analysis and transformation, virtual machine extensions and compilation techniques, implementations and interfaces of Erlang in/with other languages, and new tools (profilers, tracers, debuggers, testing frameworks, etc.). The maximum length for technical papers is restricted to 12 pages. 2. Practice and application papers describing uses of Erlang in the "real-world", Erlang libraries for specific tasks, experiences from using Erlang in specific application domains, reusable programming idioms and elegant new ways of using Erlang to approach or solve a particular problem. The maximum length for the practice and application papers is restricted to 12 pages. Note that this is a maximum length; we welcome shorter papers also, and the program committee will evaluate all papers on an equal basis independent of their lengths. 3. Poster presentations describing topics related to the workshop goals. Each includes a maximum of 2 pages of the abstract and summary. Presentations in this category will be given an hour of shared simultaneous demonstration time. Workshop Co-Chairs ------------------ Laura M. Castro, University of A Coru?a, Spain Hans Svensson, QuviQ AB, Sweden Program Committee ----------------------------- (Note: the Workshop Co-Chairs are also committee members) Jesper L. Andersen, Erlang Solutions Ltd., UK Richard Carlsson, Klarna AB, Sweden Lars-?ke Fredlund, Universidad Polit?cnica de Madrid, Spain Fr?d H?bert, Heroku, USA Kostis Sagonas, Uppsala University, Sweden & NTUA, Greece Simon Thompson, University of Kent, UK Steve Vinoski, Basho Technologies, USA Philip Wadler, University of Edinburgh, UK Important Dates ----------------------- Submissions due: Sunday, 11 May, 2014 Author notification: Friday, 6 June, 2014 Final copy due: Sunday, 22 June, 2014 Workshop date: September 5, 2014 Instructions to authors -------------------------------- Papers must be submitted online via EasyChair (via the "Erlang2014" event). The submission page is https://www.easychair.org/conferences/?conf=erlang2014 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Each submission must adhere to SIGPLAN's republication policy. Violation risks summary rejection of the offending submission. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. Paper submissions will be considered for poster submission in the case they are not accepted as full papers. Venue & Registration Details ------------------------------------------ For registration, please see the ICFP 2014 web site at: http://icfpconference.org/icfp2014/ Related Links -------------------- ICFP 2014 web site: http://www.icfpconference.org/icfp2014/ Past ACM SIGPLAN Erlang workshops: http://www.erlang.org/workshop/ Open Source Erlang: http://www.erlang.org/ EasyChair submission site: https://www.easychair.org/conferences/?conf=erlang2014 Author Information for SIGPLAN Conferences: http://www.sigplan.org/authorInformation.htm Atendee Information for SIGPLAN Events: http://www.sigplan.org/Resources/Policies/Anti-harassment -- Laura M. Castro Department of Computer Science Universidade da Coru?a (Spain) http://www.madsgroup.org/staff/laura From mayamatakeshi@REDACTED Tue Mar 25 13:49:59 2014 From: mayamatakeshi@REDACTED (mayamatakeshi) Date: Tue, 25 Mar 2014 21:49:59 +0900 Subject: [erlang-questions] No crash reports to tty with OTP R16B03-1 Message-ID: Hello, I have spend some time updating an old OTP app that was running with Erlang R13B03 and yaws-1.87 to Erlang R16B03-1 and yaws-1.98 The app is working fine, but now starting to code more features and debugging with the new version, I am not seeing sasl writing crash reports to tty anymore. The sasl is writing progress and info reports to tty: =PROGRESS REPORT==== 25-Mar-2014::21:38:04 === supervisor: {local,kernel_safe_sup} started: [{pid,<0.164.0>}, {name,timer_server}, {mfargs,{timer,start_link,[]}}, {restart_type,permanent}, {shutdown,1000}, {child_type,worker}] =INFO REPORT==== 25-Mar-2014::21:38:34 === Send ping frame =INFO REPORT==== 25-Mar-2014::21:39:04 === Send ping frame =INFO REPORT==== 25-Mar-2014::21:39:34 === Send ping frame The above are due a WebSocket connection to yaws. I force a crash doing this in yaws: out(A) -> X = 1, Y = 2, X = Y, ... I know the crash is happening because the HTTP request gets this: # curl -x "" http://127.0.0.1:12121/dialplan

Internal error, yaws code crashed




ERROR erlang code threw an uncaught exception:
 File: appmod:0
Class: error
Exception: {badmatch,false}
Req: {http_request,'GET',{abs_path,"/dialplan"},{1,1}}
Stack: [{dialplan,out,1,[{file,"src/dialplan.erl"},{line,19}]},
        {yaws_server,deliver_dyn_part,8,
                     [{file,"yaws_server.erl"},{line,2801}]},
        {yaws_server,aloop,4,[{file,"yaws_server.erl"},{line,1215}]},
        {yaws_server,acceptor0,2,[{file,"yaws_server.erl"},{line,1052}]},
        {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]

But still I don't get crash reports in the tty. Does anyone know of any change related to this? Regards, Takeshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From seglingskungen@REDACTED Tue Mar 25 15:12:31 2014 From: seglingskungen@REDACTED (Chris Williams) Date: Tue, 25 Mar 2014 15:12:31 +0100 Subject: [erlang-questions] Exit Status common_test? Message-ID: Hi, Is the any way to configure common_test always to return an exit status greater that 0 for end_per_suite and end_per test case when they fail? For the moment they always return 0 even when they fail. init_per_suite and init_per_test_case work return a exit status greater than 0 and works like I would expect. Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Tue Mar 25 17:55:29 2014 From: roger@REDACTED (Roger Lipscombe) Date: Tue, 25 Mar 2014 16:55:29 +0000 Subject: [erlang-questions] Bug? inet:listen_options discards extra raw options? Message-ID: I'm attempting to pass a bunch of raw options to ssl:listen, in order to configure TCP keep-alive behaviour. When I run strace, I see only one setsockopt call corresponding to only one of my raw options. Upon further investigation, I see the following: (<0.198.0>) call inet:listen_options([{port,0}, {raw,6,6,<<2,0,0,0>>}, {raw,6,5,<<5,0,0,0>>}, {raw,6,4,<<5,0,0,0>>}, {keepalive,true}, {raw,6,2,<<64,2,0,0>>}, {port,31337}, {mode,binary}, {active,false}, {packet,raw}, {reuseaddr,true}, {nodelay,true}, {backlog,1024}, {send_timeout,30000}, {send_timeout_close,true}],inet) (<0.198.0>) returned from inet:listen_options/2 -> {ok, {listen_opts, {0,0,0,0}, 31337,1024,-1, [{send_timeout_close, true}, {send_timeout,30000}, {nodelay,true}, {reuseaddr,true}, {packet,raw}, {active,false}, {mode,binary}, {raw,{6,2,<<64,2,0,0>>}}, {keepalive,true}]}} It appears that inet:listen_options/2 is throwing away my extra raw options. Is this expected behaviour, or is it a bug? R16B03 on Linux, by the way. Thanks, Roger. From erlangsiri@REDACTED Tue Mar 25 19:50:04 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Tue, 25 Mar 2014 19:50:04 +0100 Subject: [erlang-questions] No crash reports to tty with OTP R16B03-1 In-Reply-To: References: Message-ID: Is the sasl application running on your node? /siri tisdagen den 25:e mars 2014 skrev mayamatakeshi : > Hello, > I have spend some time updating an old OTP app that was running with > Erlang R13B03 and yaws-1.87 > to > Erlang R16B03-1 and yaws-1.98 > The app is working fine, but now starting to code more features and > debugging with the new version, I am not seeing sasl writing crash reports > to tty anymore. > > The sasl is writing progress and info reports to tty: > =PROGRESS REPORT==== 25-Mar-2014::21:38:04 === > supervisor: {local,kernel_safe_sup} > started: [{pid,<0.164.0>}, > {name,timer_server}, > {mfargs,{timer,start_link,[]}}, > {restart_type,permanent}, > {shutdown,1000}, > {child_type,worker}] > > =INFO REPORT==== 25-Mar-2014::21:38:34 === > Send ping frame > =INFO REPORT==== 25-Mar-2014::21:39:04 === > Send ping frame > =INFO REPORT==== 25-Mar-2014::21:39:34 === > Send ping frame > > The above are due a WebSocket connection to yaws. > > I force a crash doing this in yaws: > > out(A) -> > X = 1, > Y = 2, > X = Y, > ... > > I know the crash is happening because the HTTP request gets this: > > # curl -x "" http://127.0.0.1:12121/dialplan > >

Internal error, yaws code crashed



>
>
> ERROR erlang code threw an uncaught exception:
>  File: appmod:0
> Class: error
> Exception: {badmatch,false}
> Req: {http_request,'GET',{abs_path,"/dialplan"},{1,1}}
> Stack: [{dialplan,out,1,[{file,"src/dialplan.erl"},{line,19}]},
>         {yaws_server,deliver_dyn_part,8,
>                      [{file,"yaws_server.erl"},{line,2801}]},
>         {yaws_server,aloop,4,[{file,"yaws_server.erl"},{line,1215}]},
>         {yaws_server,acceptor0,2,[{file,"yaws_server.erl"},{line,1052}]},
>         {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
> 

> > > But still I don't get crash reports in the tty. > > Does anyone know of any change related to this? > > Regards, > Takeshi > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mayamatakeshi@REDACTED Wed Mar 26 00:53:17 2014 From: mayamatakeshi@REDACTED (mayamatakeshi) Date: Wed, 26 Mar 2014 08:53:17 +0900 Subject: [erlang-questions] No crash reports to tty with OTP R16B03-1 In-Reply-To: References: Message-ID: Yes, sasl is running: <0.58.0> supervisor:sasl/1 233 158 0 sasl_sup gen_server:loop/6 9 <0.59.0> supervisor:sasl/1 233 170 0 sasl_safe_sup gen_server:loop/6 9 However, I tested forcing a crash on a different module (not yaws). And I got this: =CRASH REPORT==== 26-Mar-2014::08:47:17 === crasher: initial call: registrar:init/1 pid: <0.156.0> registered_name: registrar exception exit: {bad_return_value,tcp_closed} in function gen_server:terminate/6 (gen_server.erl, line 744) ancestors: [appex_sup,<0.66.0>] messages: [] links: [<0.132.0>] dictionary: [] trap_exit: false status: running heap_size: 610 stack_size: 27 reductions: 2308 neighbours: So, sasl crash reporting to tty seems OK. So what seems to be happening is that yaws is somehow inhibiting its crash reports. I will check this. Regards, Takeshi. On Wed, Mar 26, 2014 at 3:50 AM, Siri Hansen wrote: > Is the sasl application running on your node? > /siri > > tisdagen den 25:e mars 2014 skrev mayamatakeshi : > > Hello, >> I have spend some time updating an old OTP app that was running with >> Erlang R13B03 and yaws-1.87 >> to >> Erlang R16B03-1 and yaws-1.98 >> The app is working fine, but now starting to code more features and >> debugging with the new version, I am not seeing sasl writing crash reports >> to tty anymore. >> >> The sasl is writing progress and info reports to tty: >> =PROGRESS REPORT==== 25-Mar-2014::21:38:04 === >> supervisor: {local,kernel_safe_sup} >> started: [{pid,<0.164.0>}, >> {name,timer_server}, >> {mfargs,{timer,start_link,[]}}, >> {restart_type,permanent}, >> {shutdown,1000}, >> {child_type,worker}] >> >> =INFO REPORT==== 25-Mar-2014::21:38:34 === >> Send ping frame >> =INFO REPORT==== 25-Mar-2014::21:39:04 === >> Send ping frame >> =INFO REPORT==== 25-Mar-2014::21:39:34 === >> Send ping frame >> >> The above are due a WebSocket connection to yaws. >> >> I force a crash doing this in yaws: >> >> out(A) -> >> X = 1, >> Y = 2, >> X = Y, >> ... >> >> I know the crash is happening because the HTTP request gets this: >> >> # curl -x "" http://127.0.0.1:12121/dialplan >> >>

Internal error, yaws code crashed



>>
>>
>> ERROR erlang code threw an uncaught exception:
>>  File: appmod:0
>> Class: error
>> Exception: {badmatch,false}
>> Req: {http_request,'GET',{abs_path,"/dialplan"},{1,1}}
>> Stack: [{dialplan,out,1,[{file,"src/dialplan.erl"},{line,19}]},
>>         {yaws_server,deliver_dyn_part,8,
>>                      [{file,"yaws_server.erl"},{line,2801}]},
>>         {yaws_server,aloop,4,[{file,"yaws_server.erl"},{line,1215}]},
>>         {yaws_server,acceptor0,2,[{file,"yaws_server.erl"},{line,1052}]},
>>         {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
>> 

>> >> >> But still I don't get crash reports in the tty. >> >> Does anyone know of any change related to this? >> >> Regards, >> Takeshi >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vinoski@REDACTED Wed Mar 26 01:06:49 2014 From: vinoski@REDACTED (Steve Vinoski) Date: Tue, 25 Mar 2014 20:06:49 -0400 Subject: [erlang-questions] No crash reports to tty with OTP R16B03-1 In-Reply-To: References: Message-ID: You might try checking the report.log file in the logdir directory configured in yaws.conf. --steve On Tue, Mar 25, 2014 at 7:53 PM, mayamatakeshi wrote: > Yes, sasl is running: > > <0.58.0> supervisor:sasl/1 233 > 158 0 > sasl_sup gen_server:loop/6 > 9 > <0.59.0> supervisor:sasl/1 233 > 170 0 > sasl_safe_sup gen_server:loop/6 > 9 > > However, I tested forcing a crash on a different module (not yaws). > And I got this: > > =CRASH REPORT==== 26-Mar-2014::08:47:17 === > crasher: > initial call: registrar:init/1 > pid: <0.156.0> > registered_name: registrar > exception exit: {bad_return_value,tcp_closed} > in function gen_server:terminate/6 (gen_server.erl, line 744) > ancestors: [appex_sup,<0.66.0>] > messages: [] > links: [<0.132.0>] > dictionary: [] > trap_exit: false > status: running > heap_size: 610 > stack_size: 27 > reductions: 2308 > neighbours: > > So, sasl crash reporting to tty seems OK. > So what seems to be happening is that yaws is somehow inhibiting its crash > reports. > I will check this. > > Regards, > Takeshi. > > > On Wed, Mar 26, 2014 at 3:50 AM, Siri Hansen wrote: > >> Is the sasl application running on your node? >> /siri >> >> tisdagen den 25:e mars 2014 skrev mayamatakeshi > >: >> >> Hello, >>> I have spend some time updating an old OTP app that was running with >>> Erlang R13B03 and yaws-1.87 >>> to >>> Erlang R16B03-1 and yaws-1.98 >>> The app is working fine, but now starting to code more features and >>> debugging with the new version, I am not seeing sasl writing crash reports >>> to tty anymore. >>> >>> The sasl is writing progress and info reports to tty: >>> =PROGRESS REPORT==== 25-Mar-2014::21:38:04 === >>> supervisor: {local,kernel_safe_sup} >>> started: [{pid,<0.164.0>}, >>> {name,timer_server}, >>> {mfargs,{timer,start_link,[]}}, >>> {restart_type,permanent}, >>> {shutdown,1000}, >>> {child_type,worker}] >>> >>> =INFO REPORT==== 25-Mar-2014::21:38:34 === >>> Send ping frame >>> =INFO REPORT==== 25-Mar-2014::21:39:04 === >>> Send ping frame >>> =INFO REPORT==== 25-Mar-2014::21:39:34 === >>> Send ping frame >>> >>> The above are due a WebSocket connection to yaws. >>> >>> I force a crash doing this in yaws: >>> >>> out(A) -> >>> X = 1, >>> Y = 2, >>> X = Y, >>> ... >>> >>> I know the crash is happening because the HTTP request gets this: >>> >>> # curl -x "" http://127.0.0.1:12121/dialplan >>> >>>

Internal error, yaws code crashed



>>>
>>>
>>> ERROR erlang code threw an uncaught exception:
>>>  File: appmod:0
>>> Class: error
>>> Exception: {badmatch,false}
>>> Req: {http_request,'GET',{abs_path,"/dialplan"},{1,1}}
>>> Stack: [{dialplan,out,1,[{file,"src/dialplan.erl"},{line,19}]},
>>>         {yaws_server,deliver_dyn_part,8,
>>>                      [{file,"yaws_server.erl"},{line,2801}]},
>>>         {yaws_server,aloop,4,[{file,"yaws_server.erl"},{line,1215}]},
>>>         {yaws_server,acceptor0,2,[{file,"yaws_server.erl"},{line,1052}]},
>>>         {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
>>> 

>>> >>> >>> But still I don't get crash reports in the tty. >>> >>> Does anyone know of any change related to this? >>> >>> Regards, >>> Takeshi >>> >>> >>> >>> > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mayamatakeshi@REDACTED Wed Mar 26 13:37:59 2014 From: mayamatakeshi@REDACTED (mayamatakeshi) Date: Wed, 26 Mar 2014 21:37:59 +0900 Subject: [erlang-questions] No crash reports to tty with OTP R16B03-1 In-Reply-To: References: Message-ID: Ah, yes. I didn't thought to check that file. The ERROR REPORTs (not crash reports, as I mentioned by mistake) are there. So it just happens that we don't have output to tty anymore. Thanks. On Wed, Mar 26, 2014 at 9:06 AM, Steve Vinoski wrote: > You might try checking the report.log file in the logdir directory > configured in yaws.conf. > > --steve > > > On Tue, Mar 25, 2014 at 7:53 PM, mayamatakeshi wrote: > >> Yes, sasl is running: >> >> <0.58.0> supervisor:sasl/1 233 >> 158 0 >> sasl_sup gen_server:loop/6 >> 9 >> <0.59.0> supervisor:sasl/1 233 >> 170 0 >> sasl_safe_sup gen_server:loop/6 >> 9 >> >> However, I tested forcing a crash on a different module (not yaws). >> And I got this: >> >> =CRASH REPORT==== 26-Mar-2014::08:47:17 === >> crasher: >> initial call: registrar:init/1 >> pid: <0.156.0> >> registered_name: registrar >> exception exit: {bad_return_value,tcp_closed} >> in function gen_server:terminate/6 (gen_server.erl, line 744) >> ancestors: [appex_sup,<0.66.0>] >> messages: [] >> links: [<0.132.0>] >> dictionary: [] >> trap_exit: false >> status: running >> heap_size: 610 >> stack_size: 27 >> reductions: 2308 >> neighbours: >> >> So, sasl crash reporting to tty seems OK. >> So what seems to be happening is that yaws is somehow inhibiting its >> crash reports. >> I will check this. >> >> Regards, >> Takeshi. >> >> >> On Wed, Mar 26, 2014 at 3:50 AM, Siri Hansen wrote: >> >>> Is the sasl application running on your node? >>> /siri >>> >>> tisdagen den 25:e mars 2014 skrev mayamatakeshi >> >: >>> >>> Hello, >>>> I have spend some time updating an old OTP app that was running with >>>> Erlang R13B03 and yaws-1.87 >>>> to >>>> Erlang R16B03-1 and yaws-1.98 >>>> The app is working fine, but now starting to code more features and >>>> debugging with the new version, I am not seeing sasl writing crash reports >>>> to tty anymore. >>>> >>>> The sasl is writing progress and info reports to tty: >>>> =PROGRESS REPORT==== 25-Mar-2014::21:38:04 === >>>> supervisor: {local,kernel_safe_sup} >>>> started: [{pid,<0.164.0>}, >>>> {name,timer_server}, >>>> {mfargs,{timer,start_link,[]}}, >>>> {restart_type,permanent}, >>>> {shutdown,1000}, >>>> {child_type,worker}] >>>> >>>> =INFO REPORT==== 25-Mar-2014::21:38:34 === >>>> Send ping frame >>>> =INFO REPORT==== 25-Mar-2014::21:39:04 === >>>> Send ping frame >>>> =INFO REPORT==== 25-Mar-2014::21:39:34 === >>>> Send ping frame >>>> >>>> The above are due a WebSocket connection to yaws. >>>> >>>> I force a crash doing this in yaws: >>>> >>>> out(A) -> >>>> X = 1, >>>> Y = 2, >>>> X = Y, >>>> ... >>>> >>>> I know the crash is happening because the HTTP request gets this: >>>> >>>> # curl -x "" http://127.0.0.1:12121/dialplan >>>> >>>>

Internal error, yaws code crashed



>>>>
>>>>
>>>> ERROR erlang code threw an uncaught exception:
>>>>  File: appmod:0
>>>> Class: error
>>>> Exception: {badmatch,false}
>>>> Req: {http_request,'GET',{abs_path,"/dialplan"},{1,1}}
>>>> Stack: [{dialplan,out,1,[{file,"src/dialplan.erl"},{line,19}]},
>>>>         {yaws_server,deliver_dyn_part,8,
>>>>                      [{file,"yaws_server.erl"},{line,2801}]},
>>>>         {yaws_server,aloop,4,[{file,"yaws_server.erl"},{line,1215}]},
>>>>
>>>> {yaws_server,acceptor0,2,[{file,"yaws_server.erl"},{line,1052}]},
>>>>         {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
>>>> 

>>>> >>>> >>>> But still I don't get crash reports in the tty. >>>> >>>> Does anyone know of any change related to this? >>>> >>>> Regards, >>>> Takeshi >>>> >>>> >>>> >>>> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mayamatakeshi@REDACTED Wed Mar 26 13:48:37 2014 From: mayamatakeshi@REDACTED (mayamatakeshi) Date: Wed, 26 Mar 2014 21:48:37 +0900 Subject: [erlang-questions] No crash reports to tty with OTP R16B03-1 In-Reply-To: References: Message-ID: No, I realized the problem: I was preparing my embedded yaws with this: Debug = false, GC = yaws_config:make_default_gconf(Debug, "myserver"), In the old yaws-1.87, the above would write logs to tty. But in the new version yaws-1.98 if you want this, you need to enable debug: Debug = true, GC = yaws_config:make_default_gconf(Debug, "myserver"), So the change was a correction of inappropriate behaviour for production. Regards, Takeshi On Wed, Mar 26, 2014 at 9:37 PM, mayamatakeshi wrote: > Ah, yes. I didn't thought to check that file. > The ERROR REPORTs (not crash reports, as I mentioned by mistake) are there. > So it just happens that we don't have output to tty anymore. > Thanks. > > > > On Wed, Mar 26, 2014 at 9:06 AM, Steve Vinoski wrote: > >> You might try checking the report.log file in the logdir directory >> configured in yaws.conf. >> >> --steve >> >> >> On Tue, Mar 25, 2014 at 7:53 PM, mayamatakeshi wrote: >> >>> Yes, sasl is running: >>> >>> <0.58.0> supervisor:sasl/1 233 >>> 158 0 >>> sasl_sup gen_server:loop/6 >>> 9 >>> <0.59.0> supervisor:sasl/1 233 >>> 170 0 >>> sasl_safe_sup gen_server:loop/6 >>> 9 >>> >>> However, I tested forcing a crash on a different module (not yaws). >>> And I got this: >>> >>> =CRASH REPORT==== 26-Mar-2014::08:47:17 === >>> crasher: >>> initial call: registrar:init/1 >>> pid: <0.156.0> >>> registered_name: registrar >>> exception exit: {bad_return_value,tcp_closed} >>> in function gen_server:terminate/6 (gen_server.erl, line 744) >>> ancestors: [appex_sup,<0.66.0>] >>> messages: [] >>> links: [<0.132.0>] >>> dictionary: [] >>> trap_exit: false >>> status: running >>> heap_size: 610 >>> stack_size: 27 >>> reductions: 2308 >>> neighbours: >>> >>> So, sasl crash reporting to tty seems OK. >>> So what seems to be happening is that yaws is somehow inhibiting its >>> crash reports. >>> I will check this. >>> >>> Regards, >>> Takeshi. >>> >>> >>> On Wed, Mar 26, 2014 at 3:50 AM, Siri Hansen wrote: >>> >>>> Is the sasl application running on your node? >>>> /siri >>>> >>>> tisdagen den 25:e mars 2014 skrev mayamatakeshi < >>>> mayamatakeshi@REDACTED>: >>>> >>>> Hello, >>>>> I have spend some time updating an old OTP app that was running with >>>>> Erlang R13B03 and yaws-1.87 >>>>> to >>>>> Erlang R16B03-1 and yaws-1.98 >>>>> The app is working fine, but now starting to code more features and >>>>> debugging with the new version, I am not seeing sasl writing crash reports >>>>> to tty anymore. >>>>> >>>>> The sasl is writing progress and info reports to tty: >>>>> =PROGRESS REPORT==== 25-Mar-2014::21:38:04 === >>>>> supervisor: {local,kernel_safe_sup} >>>>> started: [{pid,<0.164.0>}, >>>>> {name,timer_server}, >>>>> {mfargs,{timer,start_link,[]}}, >>>>> {restart_type,permanent}, >>>>> {shutdown,1000}, >>>>> {child_type,worker}] >>>>> >>>>> =INFO REPORT==== 25-Mar-2014::21:38:34 === >>>>> Send ping frame >>>>> =INFO REPORT==== 25-Mar-2014::21:39:04 === >>>>> Send ping frame >>>>> =INFO REPORT==== 25-Mar-2014::21:39:34 === >>>>> Send ping frame >>>>> >>>>> The above are due a WebSocket connection to yaws. >>>>> >>>>> I force a crash doing this in yaws: >>>>> >>>>> out(A) -> >>>>> X = 1, >>>>> Y = 2, >>>>> X = Y, >>>>> ... >>>>> >>>>> I know the crash is happening because the HTTP request gets this: >>>>> >>>>> # curl -x "" http://127.0.0.1:12121/dialplan >>>>> >>>>>

Internal error, yaws code crashed



>>>>>
>>>>>
>>>>> ERROR erlang code threw an uncaught exception:
>>>>>  File: appmod:0
>>>>> Class: error
>>>>> Exception: {badmatch,false}
>>>>> Req: {http_request,'GET',{abs_path,"/dialplan"},{1,1}}
>>>>> Stack: [{dialplan,out,1,[{file,"src/dialplan.erl"},{line,19}]},
>>>>>         {yaws_server,deliver_dyn_part,8,
>>>>>                      [{file,"yaws_server.erl"},{line,2801}]},
>>>>>         {yaws_server,aloop,4,[{file,"yaws_server.erl"},{line,1215}]},
>>>>>
>>>>> {yaws_server,acceptor0,2,[{file,"yaws_server.erl"},{line,1052}]},
>>>>>
>>>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
>>>>> 

>>>>> >>>>> >>>>> But still I don't get crash reports in the tty. >>>>> >>>>> Does anyone know of any change related to this? >>>>> >>>>> Regards, >>>>> Takeshi >>>>> >>>>> >>>>> >>>>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger@REDACTED Wed Mar 26 14:00:07 2014 From: roger@REDACTED (Roger Lipscombe) Date: Wed, 26 Mar 2014 13:00:07 +0000 Subject: [erlang-questions] Bug? inet:listen_options discards extra raw options? In-Reply-To: References: Message-ID: On 25 March 2014 16:55, Roger Lipscombe wrote: > When I run strace, I see only one setsockopt call corresponding to > only one of my raw options. In inet:add_opt/4, there's a call to lists:keydelete/3. This has the effect of removing duplicate options from #listen_opts.opts. However, differing raw options aren't duplicates. This _has_ to be a bug. From drormein@REDACTED Wed Mar 26 16:45:16 2014 From: drormein@REDACTED (Dror Mein) Date: Wed, 26 Mar 2014 08:45:16 -0700 (PDT) Subject: [erlang-questions] how does an erlang Socket/Port look from inside? Message-ID: <1395848716.38118.YahooMailNeo@web164504.mail.gq1.yahoo.com> Hey all, I want to eunit+meck test a simple telnet client which uses the guard is_port(Port). how can I pass something in meck:expect/4 that will pass the guard? is it a record/reference that I can make up? can I use hd(erlang:ports()) -> #Port<0.0> without blowing up? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Mar 26 17:00:55 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 26 Mar 2014 17:00:55 +0100 Subject: [erlang-questions] how does an erlang Socket/Port look from inside? In-Reply-To: <1395848716.38118.YahooMailNeo@web164504.mail.gq1.yahoo.com> References: <1395848716.38118.YahooMailNeo@web164504.mail.gq1.yahoo.com> Message-ID: <5332F9B7.5080103@ninenines.eu> How about opening a socket on a random port? {ok, S} = gen_tcp:listen(0, [{active, false}]). On 03/26/2014 04:45 PM, Dror Mein wrote: > Hey all, > > I want to eunit+meck test a simple telnet client which uses the guard > is_port(Port). > how can I pass something in meck:expect/4 that will pass the guard? > > is it a record/reference that I can make up? > can I use hd(erlang:ports()) -> #Port<0.0> without blowing up? > Thanks > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From erlangsiri@REDACTED Wed Mar 26 17:02:00 2014 From: erlangsiri@REDACTED (Siri Hansen) Date: Wed, 26 Mar 2014 17:02:00 +0100 Subject: [erlang-questions] Monitor limitations In-Reply-To: References: Message-ID: Hi Michal! Sorry for the delay, but we had to investigate a bit and discuss this before we could answer. First of all, the implementation would be rather extensive and error prone since it would cause a new possible return value from proc_lib:spawn_opt and proc_lib:start*. This must of course be handled by all users, including all gen* behaviours and the supervisor, requiring extensive testing and thorough documentation. When it comes to spawning processes on remote nodes, a change of the distribution protocol would be needed to allow the 'monitor' option (i.e. to make spawn+monitor atomic). We would need to consider if it is ok to allow using monitor with proc_lib on local node but not on remote node, or if the distribution must be updated first. Jobs with such impact on core functionality always require quite much effort from our side, even if they are implemented by our excellent open source contributors. We need to fully understand all changes and also do a quite large investigation to make sure no consequence is missed. It is also such a big change, that we would probably not allow it in a maintenance release, but rather postpone it to the next major release. In order to help us get an idea of the need and the priority of this feature, would it be possible for you to elaborate a bit on the use case? Other people on the list are of course also very welcome with their comments and thoughts on this. Thanks /siri 2014-03-24 18:16 GMT+01:00 Micha? Ptaszek : > Even if there was an additional cost for gen modules when spawning new > process I still don't see a connection with a complete removal of 'monitor' > flag from available options in spawn_opt BIF (or rather, replacing it with > throw(badarg)). Moreover there is no public API allowing people to spawn > gen_servers on the remote nodes (and only the remote spawn_opt functions > were crippled by that change). > > Would a patch re-enabling that flag be accepted by the OTP team? > > > On Mon, Mar 24, 2014 at 5:37 PM, Siri Hansen wrote: > >> From the notes in the ticket: >> >> "Some analysis yields that the cause is that the gen_server:start() call >> ends up in erlang:spawn_opt(..., [monitor]) which return {Pid, Monitor}, >> making the proc_lib:sync_wait() wait for {Pid, Monitor} and not Pid >> which is what the newly spawned process sends in the ack-message." >> >> I haven't investigated further, so I don't know anything more about it. >> It doesn't seem too hard to solve, though, so it seems strange that the >> solution was to throw a badarg. Or maybe I missed something crucial... >> >> /siri >> >> >> 2014-03-22 11:44 GMT+01:00 Micha? Ptaszek : >> >>> Hey everyone, >>> >>> can anyone please shed some more light on OTP-6345? >>> >>> For some reasons we can not atomically spawn processes with >>> proc_lib:spawn_opt with 'monitor' flag. The same problem happens with >>> erlang:spawn_opt/5 where we can not spawn a remote process with 'monitor' >>> (however linking is totally ok). >>> >>> Thanks, >>> Michal >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drormein@REDACTED Wed Mar 26 17:38:17 2014 From: drormein@REDACTED (Dror Mein) Date: Wed, 26 Mar 2014 09:38:17 -0700 (PDT) Subject: [erlang-questions] how does an erlang Socket/Port look from inside? In-Reply-To: <5332F9B7.5080103@ninenines.eu> References: <1395848716.38118.YahooMailNeo@web164504.mail.gq1.yahoo.com> <5332F9B7.5080103@ninenines.eu> Message-ID: <1395851897.93890.YahooMailNeo@web164501.mail.gq1.yahoo.com> for some reason it blocks to wait while on listen... On Wednesday, March 26, 2014 6:00 PM, Lo?c Hoguin wrote: How about opening a socket on a random port? {ok, S} = gen_tcp:listen(0, [{active, false}]). On 03/26/2014 04:45 PM, Dror Mein wrote: > Hey all, > > I want to eunit+meck test a simple telnet client which uses the guard > is_port(Port). > how can I pass something in meck:expect/4 that will pass the guard? > > is it a record/reference that I can make up? > can I use hd(erlang:ports()) -> #Port<0.0> without blowing up? > Thanks > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mononcqc@REDACTED Wed Mar 26 17:59:16 2014 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 26 Mar 2014 12:59:16 -0400 Subject: [erlang-questions] how does an erlang Socket/Port look from inside? In-Reply-To: <1395848716.38118.YahooMailNeo@web164504.mail.gq1.yahoo.com> References: <1395848716.38118.YahooMailNeo@web164504.mail.gq1.yahoo.com> Message-ID: <20140326165915.GA3153@ferdair.local> Hi, I have a solution. As part of recon (which allows to use strings and whatnot as ports) to diagnose issues, I have developed a term_to_port function that uses the serialized binary form of a port and uses binary_to_term/1 to make it into a real Erlang term: https://github.com/ferd/recon/blob/master/src/recon_lib.erl#L157-177 %% @doc Transforms a given term to a port -spec term_to_port(recon:port_term()) -> port(). term_to_port(Port) when is_port(Port) -> Port; term_to_port(Name) when is_atom(Name) -> whereis(Name); term_to_port("#Port<0."++Id) -> N = list_to_integer(lists:sublist(Id, length(Id)-1)), % drop trailing '>' term_to_port(N); term_to_port(N) when is_integer(N) -> %% We rebuild the term from the int received: %% http://www.erlang.org/doc/apps/erts/erl_ext_dist.html#id86892 Name = iolist_to_binary(atom_to_list(node())), NameLen = iolist_size(Name), Vsn = binary:last(term_to_binary(self())), Bin = <<131, % term encoding value 102, % port tag 100, % atom ext tag, used for node name NameLen:2/unit:8, Name:NameLen/binary, N:4/unit:8, % actual counter value Vsn:8>>, % version binary_to_term(Bin). I'm guessing this could be useful in your case here, if gen_tcp:listen doesn't work (and it should totally work) Regards, Fred. On 03/26, Dror Mein wrote: > Hey all, > > I want to eunit+meck test a simple telnet client which uses the guard is_port(Port). > how can I pass something in meck:expect/4 that will pass the guard? > > is it a record/reference that I can make up? > can I use hd(erlang:ports()) -> #Port<0.0> without blowing up? > Thanks > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From drormein@REDACTED Wed Mar 26 18:20:35 2014 From: drormein@REDACTED (Dror Mein) Date: Wed, 26 Mar 2014 10:20:35 -0700 (PDT) Subject: [erlang-questions] how does an erlang Socket/Port look from inside? In-Reply-To: <20140326165915.GA3153@ferdair.local> References: <1395848716.38118.YahooMailNeo@web164504.mail.gq1.yahoo.com> <20140326165915.GA3153@ferdair.local> Message-ID: <1395854435.63476.YahooMailNeo@web164503.mail.gq1.yahoo.com> It works! thank you! On Wednesday, March 26, 2014 7:00 PM, Fred Hebert wrote: Hi, I have a solution. As part of recon (which allows to use strings and whatnot as ports) to diagnose issues, I have developed a term_to_port function that uses the serialized binary form of a port and uses binary_to_term/1 to make it into a real Erlang term: https://github.com/ferd/recon/blob/master/src/recon_lib.erl#L157-177 ? ? %% @doc Transforms a given term to a port ? ? -spec term_to_port(recon:port_term()) -> port(). ? ? term_to_port(Port) when is_port(Port) -> Port; ? ? term_to_port(Name) when is_atom(Name) -> whereis(Name); ? ? term_to_port("#Port<0."++Id) -> ? ? ? ? N = list_to_integer(lists:sublist(Id, length(Id)-1)), % drop trailing '>' ? ? ? ? term_to_port(N); ? ? term_to_port(N) when is_integer(N) -> ? ? ? ? %% We rebuild the term from the int received: ? ? ? ? %% http://www.erlang.org/doc/apps/erts/erl_ext_dist.html#id86892 ? ? ? ? Name = iolist_to_binary(atom_to_list(node())), ? ? ? ? NameLen = iolist_size(Name), ? ? ? ? Vsn = binary:last(term_to_binary(self())), ? ? ? ? Bin = <<131, % term encoding value ? ? ? ? ? ? ? ? 102, % port tag ? ? ? ? ? ? ? ? 100, % atom ext tag, used for node name ? ? ? ? ? ? ? ? NameLen:2/unit:8, ? ? ? ? ? ? ? ? Name:NameLen/binary, ? ? ? ? ? ? ? ? N:4/unit:8, % actual counter value ? ? ? ? ? ? ? ? Vsn:8>>, % version ? ? ? ? binary_to_term(Bin). I'm guessing this could be useful in your case here, if gen_tcp:listen doesn't work (and it should totally work) Regards, Fred. On 03/26, Dror Mein wrote: > Hey all, > > I want to eunit+meck test a simple telnet client which uses the guard is_port(Port). > how can I pass something in meck:expect/4 that will pass the guard? > > is it a record/reference that I can make up? > can I use hd(erlang:ports()) -> #Port<0.0> without blowing up? > Thanks > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Mar 26 20:47:05 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 26 Mar 2014 20:47:05 +0100 Subject: [erlang-questions] debugger: hardcoded source path Message-ID: Hi! I got a problem report for the erlide debugger, and I found that the root cause is in the OTP debugger. int:find_src/1 looks for the source file for a beam in "ebin/../src", which is fine in most cases, but not all projects have the recommended structure. Even for those that do, the test code is not in the src directory, so there is still a problem when int:i/1 is called from the shell or from code. There are a couple of other places where "src" and "ebin" directories are hardcoded. There is an int:i/2 that takes some options as a second argument, but it is ignored. Sending project folder configuration via those options seems like a simple way to solve this. A more general way to solve the problem would be to define some standard metadata for projects/applications, but I suppose it would take a long time to agree on the details. --- In order to provide a patch, I need some information. Is the options format for int:i/2 reserved in any way? Can I structure them as I like (i.e. a proplist with keys like src_dirs, ebin_dir)? best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladdu55@REDACTED Wed Mar 26 21:20:00 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 26 Mar 2014 21:20:00 +0100 Subject: [erlang-questions] build problems Message-ID: Hi, I don't build OTP too often, so I am a little confused because I get errors in the current master for applications appmon, pman, toolbar and tv: no rule to make target 'opt' Is there some change for the build or prerequisites? Or is it a general problem? I'm using ubuntu 13.10 regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From essen@REDACTED Wed Mar 26 21:23:15 2014 From: essen@REDACTED (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) Date: Wed, 26 Mar 2014 21:23:15 +0100 Subject: [erlang-questions] build problems In-Reply-To: References: Message-ID: <53333733.70704@ninenines.eu> Those apps got removed a while ago. You shouldn't have them in lib/ anymore, otherwise you might have to cleanup your clone. On 03/26/2014 09:20 PM, Vlad Dumitrescu wrote: > Hi, > > I don't build OTP too often, so I am a little confused because I get > errors in the current master for applications appmon, pman, toolbar and > tv: no rule to make target 'opt' > > Is there some change for the build or prerequisites? Or is it a general > problem? > > I'm using ubuntu 13.10 > > regards, > Vlad > > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > -- Lo?c Hoguin http://ninenines.eu From vladdu55@REDACTED Wed Mar 26 21:25:47 2014 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Wed, 26 Mar 2014 21:25:47 +0100 Subject: [erlang-questions] build problems In-Reply-To: <53333733.70704@ninenines.eu> References: <53333733.70704@ninenines.eu> Message-ID: Ouch, I should have thought about that... Thanks and sorry about the noise. /Vlad On Wed, Mar 26, 2014 at 9:23 PM, Lo?c Hoguin wrote: > Those apps got removed a while ago. You shouldn't have them in lib/ > anymore, otherwise you might have to cleanup your clone. > > > On 03/26/2014 09:20 PM, Vlad Dumitrescu wrote: > >> Hi, >> >> I don't build OTP too often, so I am a little confused because I get >> errors in the current master for applications appmon, pman, toolbar and >> tv: no rule to make target 'opt' >> >> Is there some change for the build or prerequisites? Or is it a general >> problem? >> >> I'm using ubuntu 13.10 >> >> regards, >> Vlad >> >> >> >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions >> >> > -- > Lo?c Hoguin > http://ninenines.eu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.louis.andersen@REDACTED Wed Mar 26 22:23:08 2014 From: jesper.louis.andersen@REDACTED (Jesper Louis Andersen) Date: Wed, 26 Mar 2014 22:23:08 +0100 Subject: [erlang-questions] build problems In-Reply-To: References: <53333733.70704@ninenines.eu> Message-ID: I often use git clean -dfxq to clean out the OTP repository. BEWARE!! It kills any file in there which is not part of the current index. On Wed, Mar 26, 2014 at 9:25 PM, Vlad Dumitrescu wrote: > Ouch, I should have thought about that... > Thanks and sorry about the noise. > /Vlad > > > On Wed, Mar 26, 2014 at 9:23 PM, Lo?c Hoguin wrote: > >> Those apps got removed a while ago. You shouldn't have them in lib/ >> anymore, otherwise you might have to cleanup your clone. >> >> >> On 03/26/2014 09:20 PM, Vlad Dumitrescu wrote: >> >>> Hi, >>> >>> I don't build OTP too often, so I am a little confused because I get >>> errors in the current master for applications appmon, pman, toolbar and >>> tv: no rule to make target 'opt' >>> >>> Is there some change for the build or prerequisites? Or is it a general >>> problem? >>> >>> I'm using ubuntu 13.10 >>> >>> regards, >>> Vlad >>> >>> >>> >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions >>> >>> >> -- >> Lo?c Hoguin >> http://ninenines.eu >> > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -- J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Thu Mar 27 11:26:31 2014 From: lukas@REDACTED (Lukas Larsson) Date: Thu, 27 Mar 2014 11:26:31 +0100 Subject: [erlang-questions] Can't disable compensation for sudden changes of system time In-Reply-To: References: Message-ID: Hello Word, It is not possible to get this information out of the Erlang runtime via any Erlang API call. The only way that I found was to attach a gdb session to the running beam and print the value of the global variable erts_disable_tolerant_timeofday. Adding a call into erlang:system_info/1 that fetches the value should be very simple if anyone feels like submitting a patch to add it. Lukas On Tue, Mar 25, 2014 at 9:25 AM, Ward Bekker wrote: > Hi, > > I invoke erl like this: > > erl +A 8 +c -sname project@REDACTED -mnesia dir db_data -mnesia debug > verbose -mnesia \ > no_table_loaders 4 -mnesia dump_log_write_threshold 10000 -mnesia > dc_dump_limit 20 \ > -config priv/app.development \ > -pa `pwd`/ebin `pwd`/deps/*/ebin -run reloader -s project start -s > observer start > > > Notice the '+c'. According to the docs (http://erlang.org/doc/man/erl.html) > this emulator flag should disable compensation for sudden changes of system > time. And more importantly, remove the period of high CPU just after > resuming my computer (after a good night sleep). > > But it doesn't seem to work. How can I double check this emulator flag is > indeed toggled within the Erlang shell? > /Ward > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andra.dinu@REDACTED Thu Mar 27 16:01:08 2014 From: andra.dinu@REDACTED (Andra Dinu) Date: Thu, 27 Mar 2014 16:01:08 +0100 (CET) Subject: [erlang-questions] EUC 2014: 70% of speakers now up, Keynote speakers announced In-Reply-To: <1943985967.328894.1395931016101.JavaMail.zimbra@erlang-solutions.com> Message-ID: <461002283.329975.1395932468091.JavaMail.zimbra@erlang-solutions.com> Hi all, Looks like the Erlang User Conference on 9-10 June is shaping up nicely. The keynotes will be delivered by Stuart Bailey, CTO of Infoblox and by Katie Miller, OpenShift Developer Advocate and Co-founder of Lambda Ladies. 70% of the speakers are already up on the website, including: O'Reilly author Bruce Tate, Co-designer of Haskell and QuickCheck John Hughes, Klarna's chief scientist Erik Stenman, lead technologist at Rakuten Yosuke Hara, Feuerlabs Co-founder and Developer Advocate Ulf Wiger and many more: Early Bird rates end on 9 May. http://www.erlang-factory.com/conference/EUC2014/ Also check out the 3-day training courses on 11-13 June: Erlang Express, OTP Express, Elixir, Coweboy Express and Test Driven Developpent. Best, Andra -- Andra Dinu Community & Social ERLANG SOLUTIONS LTD New Loom House 101 Back Church Lane London, E1 1LU United Kingdom Tel +44(0)2076550344 Mob +44(0)7983484387 www.erlang-solutions.com From anders.nygren@REDACTED Thu Mar 27 16:31:45 2014 From: anders.nygren@REDACTED (Anders Nygren) Date: Thu, 27 Mar 2014 09:31:45 -0600 Subject: [erlang-questions] mnesia can not connect to itself Message-ID: We have two nodes n@REDACTED and n@REDACTED, on Ubuntu and Erlang R15B01 with mnesia running on both and all tables have replicas on both nodes. When we disconnect host1 from the network and wait until we get mnesia down messages on both nodes, mnesia writes are performed on both nodes during this time. When we reconnect the network connection on host1, we sometimes get the following. On one node mnesia reports that mnesia on both nodes are running. But on the other node mnesia reports that mnesia is running on that node, but that it is stopped on the other node. We also get a large number of the following *=ERROR REPORT==== 27-Mar-2014::06:51:56 ===* *Mnesia('n@REDACTED'): ** ERROR ** Mnesia on 'n@REDACTED' could not connect to node(s) ['n@REDACTED']* Note that it is trying to connect to itself. 1, Is this just an error in the log message? 2, or is this a sign of some deeper issue? -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah.schwartz1@REDACTED Thu Mar 27 18:23:40 2014 From: noah.schwartz1@REDACTED (Noah Schwartz) Date: Thu, 27 Mar 2014 13:23:40 -0400 Subject: [erlang-questions] mnesia storage types Message-ID: Hello, We use mnesia fairly extensively in our application and are interested in keeping track of table growth. We have one very big table thats already sharded and want to know well ahead of time if/when others need to be sharded. We started with a fairly simple approach of calling mnesia:table_info(Tab, memory) on each table on a regular interval. It seems that for disc_only_tables mnesia defers to dets:info/2 and for disc_copies or ram_copies mnesia defers to ets:info/2. dets returns the size in bytes and ets returns the size in words. We noticed that the words returned by ets didnt match up with the file sizes on disk when converted to bytes. This got us wondering a little more about the different file types -- DAT for dets and DCD/DCL for disc_copies. We also noticed that if you called dets:info(Tab, memory) on a disc_copies table it returned undefined. I was always under the impression that a disc_copies table used ets and dets under the hood but, after looking at the mnesia code that doesn't seem like the case. So my first question is, do tables with a storage type of disc_copies use dets? If so, are they limited by the same 4GB limit that dets is? If so, how can I properly measure the size on disk of a disc_copies table. Thanks in advance -- Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From felixgallo@REDACTED Thu Mar 27 21:30:04 2014 From: felixgallo@REDACTED (Felix Gallo) Date: Thu, 27 Mar 2014 13:30:04 -0700 Subject: [erlang-questions] Orleans - distributed .NET actors from MS Research Message-ID: http://research.microsoft.com/pubs/210931/Orleans-MSR-TR-2014-41.pdf Interesting paper. They went with cooperative multitasking, .NET, unordered messaging, abstracted-away supervision and distribution, what appears to be optional immutability, and promises/futures, but on the plus side ( :D ), dynamic load balancing and automatic distributed restarts on server failures. Good reading to help create intuition about why Erlang does things the way that it does, and some alternative approaches/optimizations for slightly different but similar problem sets under the actor model. F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From moxford@REDACTED Thu Mar 27 21:56:06 2014 From: moxford@REDACTED (Mike Oxford) Date: Thu, 27 Mar 2014 13:56:06 -0700 Subject: [erlang-questions] Orleans - distributed .NET actors from MS Research In-Reply-To: References: Message-ID: Reading it now ... looks solid so far ... Thanks for posting it up! On Thu, Mar 27, 2014 at 1:30 PM, Felix Gallo wrote: > http://research.microsoft.com/pubs/210931/Orleans-MSR-TR-2014-41.pdf > > Interesting paper. They went with cooperative multitasking, .NET, > unordered messaging, abstracted-away supervision and distribution, what > appears to be optional immutability, and promises/futures, but on the plus > side ( :D ), dynamic load balancing and automatic distributed restarts on > server failures. Good reading to help create intuition about why Erlang > does things the way that it does, and some alternative > approaches/optimizations for slightly different but similar problem sets > under the actor model. > > F. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang@REDACTED Fri Mar 28 11:46:20 2014 From: erlang@REDACTED (=?UTF-8?Q?Micha=C5=82_Ptaszek?=) Date: Fri, 28 Mar 2014 11:46:20 +0100 Subject: [erlang-questions] Monitor limitations In-Reply-To: References: Message-ID: Hey Siri, thanks for a detailed reply :) I completely understand the rationale for making sure the code is 100% correct and complete. The way I see it, there are 2 major difficulties in implementing this change: 1. erlang:spawn_opt, and as a result - proc_lib:spawn_opt + all functions that use it can return 2 different data types, depending on the contents of the option list (either pid() or {pid(), reference()}). As you pointed out, making all gen* functions compatible with the new format (not to mention potential incompatibilities with the application code) is a pretty tedious task, and I'm not sure if it's worth it. 2. The fact that distribution protocol supports links, but not monitors. Again, IMO relatively major change, and I guess somewhat tricky to implement (to make both spawn and monitor atomic). As a matter of fact lack of this feature is not a show stopper for us: it's rather something that I wanted to use few times in the code (which later was replaced by calls to proc_lib:spawn_opt and erlang:monitor a moment after), but the functionality wasn't there. After digging into the stdlib code I found the TODO/FIXME note, hence my question posted to the list. On top of that, I am a big fan of the principle of least astonishment: when using functions from erlang:spawn_opt/N family, I expected the 'monitor' option to work in all cases, not only in cases when we spawn processes locally to the caller. On the side note: since remote spawn with 'monitor' option is not supported, maybe we should change the docs to explicitly state that? ( http://www.erlang.org/doc/man/erlang.html#spawn_opt-5) Cheers, Michal On Wed, Mar 26, 2014 at 5:02 PM, Siri Hansen wrote: > Hi Michal! > > Sorry for the delay, but we had to investigate a bit and discuss this > before we could answer. > > First of all, the implementation would be rather extensive and error prone > since it would cause a new possible return value from proc_lib:spawn_opt > and proc_lib:start*. This must of course be handled by all users, including > all gen* behaviours and the supervisor, requiring extensive testing and > thorough documentation. > > When it comes to spawning processes on remote nodes, a change of the > distribution protocol would be needed to allow the 'monitor' option (i.e. > to make spawn+monitor atomic). We would need to consider if it is ok to > allow using monitor with proc_lib on local node but not on remote node, or > if the distribution must be updated first. > > Jobs with such impact on core functionality always require quite much > effort from our side, even if they are implemented by our excellent open > source contributors. We need to fully understand all changes and also do a > quite large investigation to make sure no consequence is missed. It is also > such a big change, that we would probably not allow > it in a maintenance release, but rather postpone it to the next major > release. > > In order to help us get an idea of the need and the priority of this > feature, would it be possible for you to elaborate a bit on the use case? > Other people on the list are of course also very welcome with their > comments and thoughts on this. > > Thanks > /siri > > > > 2014-03-24 18:16 GMT+01:00 Micha? Ptaszek : > > Even if there was an additional cost for gen modules when spawning new >> process I still don't see a connection with a complete removal of 'monitor' >> flag from available options in spawn_opt BIF (or rather, replacing it with >> throw(badarg)). Moreover there is no public API allowing people to spawn >> gen_servers on the remote nodes (and only the remote spawn_opt functions >> were crippled by that change). >> >> Would a patch re-enabling that flag be accepted by the OTP team? >> >> >> On Mon, Mar 24, 2014 at 5:37 PM, Siri Hansen wrote: >> >>> From the notes in the ticket: >>> >>> "Some analysis yields that the cause is that the gen_server:start() call >>> ends up in erlang:spawn_opt(..., [monitor]) which return {Pid, Monitor}, >>> making the proc_lib:sync_wait() wait for {Pid, Monitor} and not Pid >>> which is what the newly spawned process sends in the ack-message." >>> >>> I haven't investigated further, so I don't know anything more about it. >>> It doesn't seem too hard to solve, though, so it seems strange that the >>> solution was to throw a badarg. Or maybe I missed something crucial... >>> >>> /siri >>> >>> >>> 2014-03-22 11:44 GMT+01:00 Micha? Ptaszek : >>> >>>> Hey everyone, >>>> >>>> can anyone please shed some more light on OTP-6345? >>>> >>>> For some reasons we can not atomically spawn processes with >>>> proc_lib:spawn_opt with 'monitor' flag. The same problem happens with >>>> erlang:spawn_opt/5 where we can not spawn a remote process with 'monitor' >>>> (however linking is totally ok). >>>> >>>> Thanks, >>>> Michal >>>> >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.shneyderman@REDACTED Fri Mar 28 13:48:37 2014 From: a.shneyderman@REDACTED (Alex Shneyderman) Date: Fri, 28 Mar 2014 08:48:37 -0400 Subject: [erlang-questions] Is there a simple way to catapult an existing app to a remote server? Message-ID: So, say I start a new node with slave:start[_link]/3 I would like to start a few things on that node but the node obviously lacking all the applications that are available on the local node. Is there an established way to do this sort of teleportation? Cheers, Alex. From Christopher.Phillips@REDACTED Fri Mar 28 14:06:43 2014 From: Christopher.Phillips@REDACTED (Phillips, Christopher) Date: Fri, 28 Mar 2014 13:06:43 +0000 Subject: [erlang-questions] mnesia storage types Message-ID: I'll defer to?well, any and everyone on the current state of this, but I know Ulf Wiger answered this a while back on this mailing list (I had the very same question and so did a fair bit of searching). His answer to whether 4 GB was the max size - If you keep data in ram_copies or disc_copies, and run a 64-bit VM, tables can be larger than that. How much data you can have in practice will e.g. depend on your tolerance for long startup times (disc_copies must be loaded into RAM at startup). Disc_only_copies are in fact limited to 2 GB, and you _really_ don't want to exceed that, as mnesia doesn't have a nice way of handling errors at that level - the result will likely be inconsistencies in the database. And even if you fragment your disc_only_copies tables, Dets repair can result in unacceptably long restart times. You need to measure and consider your requirements. On 3/28/14, 7:00 AM, "erlang-questions-request@REDACTED" wrote: > >Date: Thu, 27 Mar 2014 13:23:40 -0400 >From: Noah Schwartz >To: erlang-questions@REDACTED >Subject: [erlang-questions] mnesia storage types >Message-ID: > >Content-Type: text/plain; charset="iso-8859-1" > >Hello, > >We use mnesia fairly extensively in our application and are interested in >keeping track of table growth. We have one very big table thats already >sharded and want to know well ahead of time if/when others need to be >sharded. > >We started with a fairly simple approach of calling mnesia:table_info(Tab, >memory) on each table on a regular interval. It seems that for >disc_only_tables mnesia defers to dets:info/2 and for disc_copies or >ram_copies mnesia defers to ets:info/2. dets returns the size in bytes and >ets returns the size in words. We noticed that the words returned by ets >didnt match up with the file sizes on disk when converted to bytes. This >got us wondering a little more about the different file types -- DAT for >dets and DCD/DCL for disc_copies. We also noticed that if you called >dets:info(Tab, memory) on a disc_copies table it returned undefined. I was >always under the impression that a disc_copies table used ets and dets >under the hood but, after looking at the mnesia code that doesn't seem >like >the case. > >So my first question is, do tables with a storage type of disc_copies use >dets? If so, are they limited by the same 4GB limit that dets is? If so, >how can I properly measure the size on disk of a disc_copies table. > >Thanks in advance > >-- >Noah From noah.schwartz1@REDACTED Fri Mar 28 14:38:44 2014 From: noah.schwartz1@REDACTED (Noah Schwartz) Date: Fri, 28 Mar 2014 09:38:44 -0400 Subject: [erlang-questions] mnesia storage types In-Reply-To: References: Message-ID: Christopher, awesome. I searched fairly aggressively for the answer to this question. I am surprised I didn't come across that thread. Anyway, this is great to know and answers all of my questions. A few follow ups: - Can/should the mnesia documentation be updated? Am I perhaps just reading it incorrectly? I got the distinct impression from the literature that I read that the limit was 4 GB for disk tables of any sort and that disc_copies tables were implemented using a combination of ets & dets which doesn't seem to be the case. It looks like its ets and some more sophisticated data file with with a private transaction log. - Last week we ran into the 2 GB limit in a fragmented table. Inexplicably, on one of our nodes the 1-th fragment (the fragment thats just the table name without _fragN) grew to 2 GB over an 8 hour period. It was just one shard on one node with no unusual disk activity over that time period. Our guess is that something happened to mnesia_gvar and resulted in the mnesia_frag module defaulting to the plain table name. See: https://github.com/simplegeo/erlang/blob/master/lib/mnesia/src/mnesia_frag.erl#L1213. We didn't see any errors reported at any level until the shard actually reached 2 GB. We stopped the node, removed it from our load balancer, and then restarted it with the intention of debugging but, the restart seemed to cause it to resync with the other nodes and put the shard into a normal state. On Fri, Mar 28, 2014 at 9:06 AM, Phillips, Christopher < Christopher.Phillips@REDACTED> wrote: > I'll defer to?well, any and everyone on the current state of this, but I > know Ulf Wiger answered this a while back on this mailing list (I had the > very same question and so did a fair bit of searching). His answer to > whether 4 GB was the max size - > > > If you keep data in ram_copies or disc_copies, and run a 64-bit VM, tables > can be larger than that. How much data you can have in practice will e.g. > depend on your tolerance for long startup times (disc_copies must be > loaded into RAM at startup). > > Disc_only_copies are in fact limited to 2 GB, and you _really_ don't want > to exceed that, as mnesia doesn't have a nice way of handling errors at > that level - the result will likely be inconsistencies in the database. > And even if you fragment your disc_only_copies tables, Dets repair can > result in unacceptably long restart times. You need to measure and > consider your requirements. > > > > > > On 3/28/14, 7:00 AM, "erlang-questions-request@REDACTED" > wrote: > > > > >Date: Thu, 27 Mar 2014 13:23:40 -0400 > >From: Noah Schwartz > >To: erlang-questions@REDACTED > >Subject: [erlang-questions] mnesia storage types > >Message-ID: > > < > CAMEFtU-u4OHQAR47XOhZWMJVny0ghHQ646D14YkpSROBbWAbyQ@REDACTED> > >Content-Type: text/plain; charset="iso-8859-1" > > > >Hello, > > > >We use mnesia fairly extensively in our application and are interested in > >keeping track of table growth. We have one very big table thats already > >sharded and want to know well ahead of time if/when others need to be > >sharded. > > > >We started with a fairly simple approach of calling mnesia:table_info(Tab, > >memory) on each table on a regular interval. It seems that for > >disc_only_tables mnesia defers to dets:info/2 and for disc_copies or > >ram_copies mnesia defers to ets:info/2. dets returns the size in bytes and > >ets returns the size in words. We noticed that the words returned by ets > >didnt match up with the file sizes on disk when converted to bytes. This > >got us wondering a little more about the different file types -- DAT for > >dets and DCD/DCL for disc_copies. We also noticed that if you called > >dets:info(Tab, memory) on a disc_copies table it returned undefined. I was > >always under the impression that a disc_copies table used ets and dets > >under the hood but, after looking at the mnesia code that doesn't seem > >like > >the case. > > > >So my first question is, do tables with a storage type of disc_copies use > >dets? If so, are they limited by the same 4GB limit that dets is? If so, > >how can I properly measure the size on disk of a disc_copies table. > > > >Thanks in advance > > > >-- > >Noah > > -- Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.nygren@REDACTED Fri Mar 28 15:12:33 2014 From: anders.nygren@REDACTED (Anders Nygren) Date: Fri, 28 Mar 2014 08:12:33 -0600 Subject: [erlang-questions] mnesia can not connect to itself In-Reply-To: References: Message-ID: I found the cause of this error, we are using Ulf's unsplit application and it crashes on bag tables leaving all the tables locked. On Thu, Mar 27, 2014 at 9:31 AM, Anders Nygren wrote: > We have two nodes n@REDACTED and n@REDACTED, on Ubuntu and Erlang R15B01 with > mnesia running on both and all tables have replicas on both nodes. When we > disconnect host1 from the network and wait until we get mnesia down > messages on both nodes, mnesia writes are performed on both nodes during > this time. When we reconnect the network connection on host1, we sometimes > get the following. > > On one node mnesia reports that mnesia on both nodes are running. But on > the other node mnesia reports that mnesia is running on that node, but that > it is stopped on the other node. We also get a large number of the > following > > *=ERROR REPORT==== 27-Mar-2014::06:51:56 ===* > > *Mnesia('n@REDACTED'): ** ERROR ** Mnesia on 'n@REDACTED' could not connect to > node(s) ['n@REDACTED']* > > > Note that it is trying to connect to itself. > > > 1, Is this just an error in the log message? > > 2, or is this a sign of some deeper issue? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah.schwartz1@REDACTED Fri Mar 28 15:52:00 2014 From: noah.schwartz1@REDACTED (Noah Schwartz) Date: Fri, 28 Mar 2014 10:52:00 -0400 Subject: [erlang-questions] mnesia storage types In-Reply-To: References: Message-ID: Sorry to spam -- I didn't really pose a question in that 2nd bullet point. Does it make sense to anyone on this list that mnesia_gvar could have issues causing that code to not pick the correct shard? Why would this happen on only one node? If the frag module started picking the regular table name for writes, wouldn't that table have grown on all nodes? Are we barking up the wrong tree? Should that code at least print an error rather than silently catching exceptions? On Fri, Mar 28, 2014 at 9:38 AM, Noah Schwartz wrote: > Christopher, awesome. I searched fairly aggressively for the answer to > this question. I am surprised I didn't come across that thread. > > Anyway, this is great to know and answers all of my questions. > > A few follow ups: > - Can/should the mnesia documentation be updated? Am I perhaps just > reading it incorrectly? I got the distinct impression from the literature > that I read that the limit was 4 GB for disk tables of any sort and that > disc_copies tables were implemented using a combination of ets & dets which > doesn't seem to be the case. It looks like its ets and some more > sophisticated data file with with a private transaction log. > > - Last week we ran into the 2 GB limit in a fragmented table. > Inexplicably, on one of our nodes the 1-th fragment (the fragment thats > just the table name without _fragN) grew to 2 GB over an 8 hour period. It > was just one shard on one node with no unusual disk activity over that time > period. Our guess is that something happened to mnesia_gvar and resulted in > the mnesia_frag module defaulting to the plain table name. See: > https://github.com/simplegeo/erlang/blob/master/lib/mnesia/src/mnesia_frag.erl#L1213. > We didn't see any errors reported at any level until the shard actually > reached 2 GB. We stopped the node, removed it from our load balancer, and > then restarted it with the intention of debugging but, the restart seemed > to cause it to resync with the other nodes and put the shard into a normal > state. > > > On Fri, Mar 28, 2014 at 9:06 AM, Phillips, Christopher < > Christopher.Phillips@REDACTED> wrote: > >> I'll defer to?well, any and everyone on the current state of this, but I >> know Ulf Wiger answered this a while back on this mailing list (I had the >> very same question and so did a fair bit of searching). His answer to >> whether 4 GB was the max size - >> >> >> If you keep data in ram_copies or disc_copies, and run a 64-bit VM, tables >> can be larger than that. How much data you can have in practice will e.g. >> depend on your tolerance for long startup times (disc_copies must be >> loaded into RAM at startup). >> >> Disc_only_copies are in fact limited to 2 GB, and you _really_ don't want >> to exceed that, as mnesia doesn't have a nice way of handling errors at >> that level - the result will likely be inconsistencies in the database. >> And even if you fragment your disc_only_copies tables, Dets repair can >> result in unacceptably long restart times. You need to measure and >> consider your requirements. >> >> >> >> >> >> On 3/28/14, 7:00 AM, "erlang-questions-request@REDACTED" >> wrote: >> >> > >> >Date: Thu, 27 Mar 2014 13:23:40 -0400 >> >From: Noah Schwartz >> >To: erlang-questions@REDACTED >> >Subject: [erlang-questions] mnesia storage types >> >Message-ID: >> > < >> CAMEFtU-u4OHQAR47XOhZWMJVny0ghHQ646D14YkpSROBbWAbyQ@REDACTED> >> >Content-Type: text/plain; charset="iso-8859-1" >> > >> >Hello, >> > >> >We use mnesia fairly extensively in our application and are interested in >> >keeping track of table growth. We have one very big table thats already >> >sharded and want to know well ahead of time if/when others need to be >> >sharded. >> > >> >We started with a fairly simple approach of calling >> mnesia:table_info(Tab, >> >memory) on each table on a regular interval. It seems that for >> >disc_only_tables mnesia defers to dets:info/2 and for disc_copies or >> >ram_copies mnesia defers to ets:info/2. dets returns the size in bytes >> and >> >ets returns the size in words. We noticed that the words returned by ets >> >didnt match up with the file sizes on disk when converted to bytes. This >> >got us wondering a little more about the different file types -- DAT for >> >dets and DCD/DCL for disc_copies. We also noticed that if you called >> >dets:info(Tab, memory) on a disc_copies table it returned undefined. I >> was >> >always under the impression that a disc_copies table used ets and dets >> >under the hood but, after looking at the mnesia code that doesn't seem >> >like >> >the case. >> > >> >So my first question is, do tables with a storage type of disc_copies use >> >dets? If so, are they limited by the same 4GB limit that dets is? If so, >> >how can I properly measure the size on disk of a disc_copies table. >> > >> >Thanks in advance >> > >> >-- >> >Noah >> >> > > > -- > Noah > -- Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From 06jameskingsbery@REDACTED Fri Mar 28 21:56:28 2014 From: 06jameskingsbery@REDACTED (James Kingsbery) Date: Fri, 28 Mar 2014 16:56:28 -0400 Subject: [erlang-questions] Force rebar to use a different protocol Message-ID: There's a project I'm looking at for work on github. Like most Erlang projects, it uses rebar to build. Most rebar projects specify their dependencies using the "git://github.com/..." format (eg: "git:// github.com/DeadZen/goldrush.git"). However, my company has a firewall that prevents hitting repositories using the git:// protocol (and ssh traffic in general). Downloading the same dependencies (directly with git or via rebar) "https://" works fine. However, changing the rebar.config files doesn't scale well for projects that have lots of transitive dependencies. Is there a way to tell rebar to use the https:// version instead of the "git://" version? Thanks, Jamie -------------- next part -------------- An HTML attachment was scrubbed... URL: From jose.valim@REDACTED Fri Mar 28 22:06:42 2014 From: jose.valim@REDACTED (=?ISO-8859-1?Q?Jos=E9_Valim?=) Date: Fri, 28 Mar 2014 22:06:42 +0100 Subject: [erlang-questions] Force rebar to use a different protocol In-Reply-To: References: Message-ID: You can configure your .gitconfig to rewrite URLs for you: [url "https://github.com/"] insteadOf = git://github.com/ Or do it through the command line: git config --global url.https://github.com/.insteadOf git://github.com/ For more info check the man pages for git-config: http://git-scm.com/docs/git-config *Jos? Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Lead Developer On Fri, Mar 28, 2014 at 9:56 PM, James Kingsbery <06jameskingsbery@REDACTED > wrote: > There's a project I'm looking at for work on github. Like most Erlang > projects, it uses rebar to build. Most rebar projects specify their > dependencies using the "git://github.com/..." format (eg: "git:// > github.com/DeadZen/goldrush.git"). However, my company has a firewall > that prevents hitting repositories using the git:// protocol (and ssh > traffic in general). Downloading the same dependencies (directly with git > or via rebar) "https://" works fine. However, changing the rebar.config > files doesn't scale well for projects that have lots of transitive > dependencies. Is there a way to tell rebar to use the https:// version > instead of the "git://" version? > > Thanks, > Jamie > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Sun Mar 30 10:19:51 2014 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Sun, 30 Mar 2014 10:19:51 +0200 Subject: [erlang-questions] Is there a simple way to catapult an existing app to a remote server? In-Reply-To: References: Message-ID: <1396167591.4651.7.camel@sekic1152.rnd.ki.sw.ericsson.se> Greetings, The slave documentation says: "The slave node should use the same file system at the master." Your use case is saved by the next sentence: "At least, Erlang/OTP should be installed in the same place on both computers and the same version of Erlang should be used.". If you have the right Erlang/OTP in the right place, but not your applications, you have to 1) Find the modules for the applications. 2) Send the modules to the slave. 3) Start the applications. bengt On Fri, 2014-03-28 at 08:48 -0400, Alex Shneyderman wrote: > So, say I start a new node with slave:start[_link]/3 I would like to > start a few things on that node but the node obviously lacking all the > applications that are available on the local node. Is there an > established way to do this sort of teleportation? > > Cheers, > Alex. > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From ddosia@REDACTED Sun Mar 30 14:42:20 2014 From: ddosia@REDACTED (Daniil Churikov) Date: Sun, 30 Mar 2014 05:42:20 -0700 (PDT) Subject: [erlang-questions] [ANN] mekao - SQL constructor library In-Reply-To: References: Message-ID: mekao slowly moves forward. Since announcement several features were added. Also docs now more complete. Dear community, take a look. On Sunday, January 12, 2014 5:47:50 PM UTC+4, Daniil Churikov wrote: > > Hello dear list! > > I would like to announce small library (currently under 500LoC), which > intended to help in SQL queries construction. > The main goal is to cover very basic type of queries, and provide > mechanism to easily extend it if needed. > Note that as one of the key concept is that you use records as db-data > representation, otherwise it may not be useful for you. > > It is early alpha and I share it because it is already covers some of mine > usecases and I want to catch right direction to move on. > > Anyway spend few minutes to check README or read some tests. > > Thanks! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From virtan@REDACTED Sun Mar 30 18:29:17 2014 From: virtan@REDACTED (virtan) Date: Sun, 30 Mar 2014 19:29:17 +0300 Subject: [erlang-questions] [ANN] iSQL: load balancing of mysql requests among multiple connections with pipelining, ibrowse-like interface Message-ID: <35528E74-CDFC-495A-A95F-29516CABE36A@virtan.com> Hi, again. The child of ibrowse and emysql parents: mysql client with load balancing among multiple connections with pipelining. With ibrowse-like interface. https://github.com/virtan/isql Simplified usage: application:start(isql), SQLEntity = #sql_entity{host = "", port = "", ...}, isql:set_max_sessions(SQLEntity, 2), isql:set_max_pipeline_size(SQLEntity, 10), {ok, #result_packet{}} = isql:send_req(SQLEntity, "select 'hello world'"). Alpha version. MIT license. -- virtan / virtan@REDACTED / http://www.virtan.com From lee.sylvester@REDACTED Sun Mar 30 18:58:54 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Sun, 30 Mar 2014 17:58:54 +0100 Subject: [erlang-questions] RiakCS Message-ID: Hi all, I?m running a Riak cluster and a RiakCS cluster. I want to be able to make direct calls to my RiakCS cluster, but the only client I can find for doing this (or examples of) use erlcloud, which seems tightly bound to Amazon?s S3. Is there a preferred way to use RiakCS from Erlang? Thanks, Lee From yoursurrogategod@REDACTED Mon Mar 31 00:45:00 2014 From: yoursurrogategod@REDACTED (Yves S. Garret) Date: Sun, 30 Mar 2014 18:45:00 -0400 Subject: [erlang-questions] Question about ETS documentation Message-ID: Hello, I've been reading this documentation: http://www.erlang.org/doc/man/ets.html#lookup_element-3 What I have a hard time figuring out is what the Pos means. Why would it be needed at all? I'm looking at this code: ... Cx_PId = ets:lookup_element(IdsNPIds, Cx#cortex.id, 2), ... And I have no idea what this and why have it there. I've already specified the element that we're searching for, why the position? Does the position refer to the element that's located inside of the return value? As in, I want the 2nd element from the return value? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rtrlists@REDACTED Mon Mar 31 05:14:31 2014 From: rtrlists@REDACTED (Robert Raschke) Date: Mon, 31 Mar 2014 04:14:31 +0100 Subject: [erlang-questions] Question about ETS documentation In-Reply-To: References: Message-ID: Hi Yves, ets stores tuples (aka 'objects' in the documentation), where by default the first element is taken to be the key. The lookup/2 function will return all objects (ie., tuples) that match the key. Whereas lookup_element/3 will only return the term stored at the requested position on the matching tuples. Hope this helps, Robby On Mar 30, 2014 11:45 PM, "Yves S. Garret" wrote: > Hello, > > I've been reading this documentation: > http://www.erlang.org/doc/man/ets.html#lookup_element-3 > > What I have a hard time figuring out is what the Pos means. Why would it > be needed at all? I'm looking at this code: > > ... > Cx_PId = ets:lookup_element(IdsNPIds, Cx#cortex.id, 2), > ... > > And I have no idea what this and why have it there. I've already > specified the element that we're searching for, why the position? Does the > position refer to the element that's located inside of the return value? > As in, I want the 2nd element from the return value? > > Thanks in advance. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachary.hueras@REDACTED Mon Mar 31 05:14:30 2014 From: zachary.hueras@REDACTED (Soup) Date: Sun, 30 Mar 2014 23:14:30 -0400 Subject: [erlang-questions] Question about ETS documentation In-Reply-To: References: Message-ID: Pos refers to a position in the stored tuple. ets:lookup_element returns only one of the values from the tuple, as opposed to ets:lookup which returns the tuple in its entirety (in a list for compatibility with bag-type tables). One reason you might prefer lookup_element as opposed to lookup is that it's slightly cheaper to copy from the table (as you're not copying as much data), but it's also generally useful as a shorthand for retrieving one piece of the stored tuple so you don't have to bind the entire return value. If I recall correctly, lookup_element, update_element, and update_counter only work with tables of type set or ordered_set. ~Soup On Sun, Mar 30, 2014 at 6:45 PM, Yves S. Garret wrote: > Hello, > > I've been reading this documentation: > http://www.erlang.org/doc/man/ets.html#lookup_element-3 > > What I have a hard time figuring out is what the Pos means. Why would it > be needed at all? I'm looking at this code: > > ... > Cx_PId = ets:lookup_element(IdsNPIds, Cx#cortex.id, 2), > ... > > And I have no idea what this and why have it there. I've already > specified the element that we're searching for, why the position? Does the > position refer to the element that's located inside of the return value? > As in, I want the 2nd element from the return value? > > Thanks in advance. > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From txrev319@REDACTED Mon Mar 31 10:43:03 2014 From: txrev319@REDACTED (t x) Date: Mon, 31 Mar 2014 01:43:03 -0700 Subject: [erlang-questions] de-magic-fying of https://github.com/fycth/webrtcexample Message-ID: Hi, How does https://github.com/fycth/webrtcexample work? I've tested it with both webrtc clients behind a firewall (and thus it should require TURN, not just STUN). Yet: * the two machines could talk to each other * it's not obvious to me where the embedded TURN server is in the above code How does the above work? * does it have a built in TURN server or * does it actually not support TURN? Thanks! From gleber.p@REDACTED Mon Mar 31 14:28:16 2014 From: gleber.p@REDACTED (Gleb Peregud) Date: Mon, 31 Mar 2014 14:28:16 +0200 Subject: [erlang-questions] RiakCS In-Reply-To: References: Message-ID: Hello Lee I am not sure how compatible RiakCS is with Amazon S3 API, but you can specify S3 hostname and port when setting up credentials in erlcloud. Take a look at erlcloud_s3:new/3,4 and erlcloud_s3:configure/3,4. These should tell erlcloud to connect to your RiakCS and you can check if it is actually API-compatible. Hope this helps, Gleb On Sun, Mar 30, 2014 at 6:58 PM, Lee Sylvester wrote: > Hi all, > > I?m running a Riak cluster and a RiakCS cluster. I want to be able to make direct calls to my RiakCS cluster, but the only client I can find for doing this (or examples of) use erlcloud, which seems tightly bound to Amazon?s S3. Is there a preferred way to use RiakCS from Erlang? > > Thanks, > Lee > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From lee.sylvester@REDACTED Mon Mar 31 16:55:39 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Mon, 31 Mar 2014 15:55:39 +0100 Subject: [erlang-questions] RiakCS In-Reply-To: References: Message-ID: Hi Gleb, Thank you for the information. Are there any examples of ErlCloud S3 that I can take a look at? Thanks, Lee > On Mar 31, 2014, at 1:28 PM, Gleb Peregud wrote: > > Hello Lee > > I am not sure how compatible RiakCS is with Amazon S3 API, but you can > specify S3 hostname and port when setting up credentials in erlcloud. > Take a look at erlcloud_s3:new/3,4 and erlcloud_s3:configure/3,4. > > These should tell erlcloud to connect to your RiakCS and you can check > if it is actually API-compatible. > > Hope this helps, > Gleb > >> On Sun, Mar 30, 2014 at 6:58 PM, Lee Sylvester wrote: >> Hi all, >> >> I?m running a Riak cluster and a RiakCS cluster. I want to be able to make direct calls to my RiakCS cluster, but the only client I can find for doing this (or examples of) use erlcloud, which seems tightly bound to Amazon?s S3. Is there a preferred way to use RiakCS from Erlang? >> >> Thanks, >> Lee >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://erlang.org/mailman/listinfo/erlang-questions From gleber.p@REDACTED Mon Mar 31 18:09:36 2014 From: gleber.p@REDACTED (Gleb Peregud) Date: Mon, 31 Mar 2014 18:09:36 +0200 Subject: [erlang-questions] RiakCS In-Reply-To: References: Message-ID: Hey Here is example of using of erlcloud_s3 with LeoFS: https://github.com/leo-project/leofs_docs/blob/master/s3_client.rst#example-usage-6 HTH, Gleb On Mon, Mar 31, 2014 at 4:55 PM, Lee Sylvester wrote: > Hi Gleb, > > Thank you for the information. Are there any examples of ErlCloud S3 that I can take a look at? > > Thanks, > Lee > > > >> On Mar 31, 2014, at 1:28 PM, Gleb Peregud wrote: >> >> Hello Lee >> >> I am not sure how compatible RiakCS is with Amazon S3 API, but you can >> specify S3 hostname and port when setting up credentials in erlcloud. >> Take a look at erlcloud_s3:new/3,4 and erlcloud_s3:configure/3,4. >> >> These should tell erlcloud to connect to your RiakCS and you can check >> if it is actually API-compatible. >> >> Hope this helps, >> Gleb >> >>> On Sun, Mar 30, 2014 at 6:58 PM, Lee Sylvester wrote: >>> Hi all, >>> >>> I?m running a Riak cluster and a RiakCS cluster. I want to be able to make direct calls to my RiakCS cluster, but the only client I can find for doing this (or examples of) use erlcloud, which seems tightly bound to Amazon?s S3. Is there a preferred way to use RiakCS from Erlang? >>> >>> Thanks, >>> Lee >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-questions From lee.sylvester@REDACTED Mon Mar 31 19:41:09 2014 From: lee.sylvester@REDACTED (Lee Sylvester) Date: Mon, 31 Mar 2014 18:41:09 +0100 Subject: [erlang-questions] RiakCS In-Reply-To: References: Message-ID: Thank you, this is very useful. Regards, Lee On 31 Mar 2014, at 17:09, Gleb Peregud wrote: > Hey > > Here is example of using of erlcloud_s3 with LeoFS: > > https://github.com/leo-project/leofs_docs/blob/master/s3_client.rst#example-usage-6 > > HTH, > Gleb > > On Mon, Mar 31, 2014 at 4:55 PM, Lee Sylvester wrote: >> Hi Gleb, >> >> Thank you for the information. Are there any examples of ErlCloud S3 that I can take a look at? >> >> Thanks, >> Lee >> >> >> >>> On Mar 31, 2014, at 1:28 PM, Gleb Peregud wrote: >>> >>> Hello Lee >>> >>> I am not sure how compatible RiakCS is with Amazon S3 API, but you can >>> specify S3 hostname and port when setting up credentials in erlcloud. >>> Take a look at erlcloud_s3:new/3,4 and erlcloud_s3:configure/3,4. >>> >>> These should tell erlcloud to connect to your RiakCS and you can check >>> if it is actually API-compatible. >>> >>> Hope this helps, >>> Gleb >>> >>>> On Sun, Mar 30, 2014 at 6:58 PM, Lee Sylvester wrote: >>>> Hi all, >>>> >>>> I?m running a Riak cluster and a RiakCS cluster. I want to be able to make direct calls to my RiakCS cluster, but the only client I can find for doing this (or examples of) use erlcloud, which seems tightly bound to Amazon?s S3. Is there a preferred way to use RiakCS from Erlang? >>>> >>>> Thanks, >>>> Lee >>>> _______________________________________________ >>>> erlang-questions mailing list >>>> erlang-questions@REDACTED >>>> http://erlang.org/mailman/listinfo/erlang-questions